draft-ietf-bess-dci-evpn-overlay-00.txt   draft-ietf-bess-dci-evpn-overlay-01.txt 
BESS Workgroup J. Rabadan BESS Workgroup J. Rabadan
Internet Draft S. Sathappan Internet Draft S. Sathappan
Intended status: Standards Track W. Henderickx Intended status: Standards Track W. Henderickx
S. Palislamovic S. Palislamovic
R. Shekhar Alcatel-Lucent R. Shekhar Alcatel-Lucent
A. Lohiya A. Lohiya
Juniper F. Balus Juniper
Nuage Networks
A. Sajassi A. Sajassi
D. Cai D. Cai
Cisco Cisco
Expires: July 20, 2015 January 16, 2015 Expires: January 7, 2016 July 6, 2015
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-00 draft-ietf-bess-dci-evpn-overlay-01
Abstract Abstract
This document describes how Network Virtualization Overlay networks This document describes how Network Virtualization Overlay networks
(NVO) can be connected to a Wide Area Network (WAN) in order to (NVO) can be connected to a Wide Area Network (WAN) in order to
extend the layer-2 connectivity required for some tenants. The extend the layer-2 connectivity required for some tenants. The
solution analyzes the interaction between NVO networks running EVPN solution analyzes the interaction between NVO networks running EVPN
and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS
or EVPN/PBB-EVPN, and proposes a solution for the interworking or EVPN/PBB-EVPN, and proposes a solution for the interworking
between both. between both.
skipping to change at page 2, line 4 skipping to change at page 1, line 46
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 20, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 47
3. Integrated Interconnect solution for EVPN overlay networks . . 8 3. Integrated Interconnect solution for EVPN overlay networks . . 8
3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 9 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 9
3.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 10 3.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 10
3.2.1. Control/Data Plane setup procedures on the GWs . . . . 10 3.2.1. Control/Data Plane setup procedures on the GWs . . . . 10
3.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 10 3.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 10
3.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 11 3.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 11
3.3.1. Control/Data Plane setup procedures on the GWs . . . . 11 3.3.1. Control/Data Plane setup procedures on the GWs . . . . 11
3.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 11 3.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 11
3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 12 3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 12
3.4.1. Control Plane setup procedures on the GWs . . . . . . . 12 3.4.1. Control Plane setup procedures on the GWs . . . . . . . 12
3.4.2. Data Plane setup procedures on the GWs . . . . . . . . 13 3.4.2. Data Plane setup procedures on the GWs . . . . . . . . 14
3.4.3. Multi-homing procedures on the GWs . . . . . . . . . . 14 3.4.3. Multi-homing procedures on the GWs . . . . . . . . . . 14
3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 15 3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 15
3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 15 3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 16
3.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 16 3.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 16
3.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 17 3.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 17
3.5.1. Control/Data Plane setup procedures on the GWs . . . . 17 3.5.1. Control/Data Plane setup procedures on the GWs . . . . 17
3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 17 3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 18
3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 18 3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 18
3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 18 3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 18
3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 18 3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 18
3.6.1. Globally unique VNIs in the Interconnect network . . . 19 3.6.1. Globally unique VNIs in the Interconnect network . . . 19
3.6.2. Downstream assigned VNIs in the Interconnect network . 19 3.6.2. Downstream assigned VNIs in the Interconnect network . 20
5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20 5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[EVPN-Overlays] discusses the use of EVPN as the control plane for [EVPN-Overlays] discusses the use of EVPN as the control plane for
Network Virtualization Overlay (NVO) networks, where VXLAN, NVGRE or Network Virtualization Overlay (NVO) networks, where VXLAN, NVGRE or
MPLS over GRE can be used as possible data plane encapsulation MPLS over GRE can be used as possible data plane encapsulation
options. options.
While this model provides a scalable and efficient multi-tenant While this model provides a scalable and efficient multi-tenant
solution within the Data Center, it might not be easily extended to solution within the Data Center, it might not be easily extended to
skipping to change at page 5, line 33 skipping to change at page 5, line 33
between both providers. The disadvantage of this model is the between both providers. The disadvantage of this model is the
provisioning overhead since the service must be mapped to a S/C-TAG provisioning overhead since the service must be mapped to a S/C-TAG
VLAN ID combination at both, GW and WAN Edge routers. VLAN ID combination at both, GW and WAN Edge routers.
In this model, the GW acts as a regular Network Virtualization Edge In this model, the GW acts as a regular Network Virtualization Edge
(NVE) towards the DC. Its control plane, data plane procedures and (NVE) towards the DC. Its control plane, data plane procedures and
interactions are described in [EVPN-Overlays]. interactions are described in [EVPN-Overlays].
The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with
attachment circuits (ACs) to the GWs. Its functions are described in attachment circuits (ACs) to the GWs. Its functions are described in
[RFC4761][RFC4762][RFC6074] or [EVPN][PBB-EVPN]. [RFC4761][RFC4762][RFC6074] or [RFC7432][PBB-EVPN].
2.3. PW-based (Pseudowire-based) hand-off 2.3. PW-based (Pseudowire-based) hand-off
If MPLS can be enabled between the GW and the WAN Edge router, a PW- If MPLS can be enabled between the GW and the WAN Edge router, a PW-
based Interconnect solution can be deployed. In this option the based Interconnect solution can be deployed. In this option the
hand-off between both routers is based on FEC128-based PWs or FEC129- hand-off between both routers is based on FEC128-based PWs or FEC129-
based PWs (for a greater level of network automation). Note that this based PWs (for a greater level of network automation). Note that this
model still provides a clear demarcation boundary between DC and WAN, model still provides a clear demarcation boundary between DC and WAN,
and security/QoS policies may be applied on a per PW basis. This and security/QoS policies may be applied on a per PW basis. This
model provides better scalability than a C-TAG based hand-off and model provides better scalability than a C-TAG based hand-off and
skipping to change at page 6, line 26 skipping to change at page 6, line 26
As already discussed, single-active multi-homing, i.e. per-service As already discussed, single-active multi-homing, i.e. per-service
load-balancing multi-homing MUST be supported in this type of load-balancing multi-homing MUST be supported in this type of
interconnect. All-active multi-homing may be considered in future interconnect. All-active multi-homing may be considered in future
revisions of this document. revisions of this document.
The GWs will be provisioned with a unique ESI per WAN interconnect The GWs will be provisioned with a unique ESI per WAN interconnect
and the hand-off attachment circuits or PWs between the GW and the and the hand-off attachment circuits or PWs between the GW and the
WAN Edge router will be assigned to such ESI. The ESI will be WAN Edge router will be assigned to such ESI. The ESI will be
administratively configured on the GWs according to the procedures in administratively configured on the GWs according to the procedures in
[EVPN]. This Interconnect ESI will be referred as "I-ESI" hereafter. [RFC7432]. This Interconnect ESI will be referred as "I-ESI"
hereafter.
The solution (on the GWs) MUST follow the single-active multi-homing The solution (on the GWs) MUST follow the single-active multi-homing
procedures as described in [EVPN-Overlays] for the provisioned I-ESI, procedures as described in [EVPN-Overlays] for the provisioned I-ESI,
i.e. Ethernet A-D routes per ESI and per EVI will be advertised to i.e. Ethernet A-D routes per ESI and per EVI will be advertised to
the DC NVEs. The MAC addresses learnt (in the data plane) on the the DC NVEs. The MAC addresses learnt (in the data plane) on the
hand-off links will be advertised with the I-ESI encoded in the ESI hand-off links will be advertised with the I-ESI encoded in the ESI
field. field.
2.5. Gateway Optimizations 2.5. Gateway Optimizations
skipping to change at page 7, line 42 skipping to change at page 7, line 43
from the WAN as well as the advertisement of the Unknown MAC route from the WAN as well as the advertisement of the Unknown MAC route
from the DF GW. In cases where all the DC MAC addresses are learnt in from the DF GW. In cases where all the DC MAC addresses are learnt in
the control/management plane, the GW may disable the advertisement of the control/management plane, the GW may disable the advertisement of
WAN MAC addresses. Any frame with unknown destination MAC will be WAN MAC addresses. Any frame with unknown destination MAC will be
exclusively sent to the Unknown MAC route owner(s). exclusively sent to the Unknown MAC route owner(s).
2.5.3. ARP flooding control 2.5.3. ARP flooding control
Another optimization mechanism, naturally provided by EVPN in the Another optimization mechanism, naturally provided by EVPN in the
GWs, is the Proxy ARP/ND function. The GWs SHOULD build a Proxy GWs, is the Proxy ARP/ND function. The GWs SHOULD build a Proxy
ARP/ND cache table as per [EVPN]. When the active GW receives an ARP/ND cache table as per [RFC7432]. When the active GW receives an
ARP/ND request/solicitation coming from the WAN, the GW does a Proxy ARP/ND request/solicitation coming from the WAN, the GW does a Proxy
ARP/ND table lookup and replies as long as the information is ARP/ND table lookup and replies as long as the information is
available in its table. available in its table.
This mechanism is especially recommended on the GWs since it protects This mechanism is especially recommended on the GWs since it protects
the DC network from external ARP/ND-flooding storms. the DC network from external ARP/ND-flooding storms.
2.5.4. Handling failures between GW and WAN Edge routers 2.5.4. Handling failures between GW and WAN Edge routers
Link/PE failures MUST be handled on the GWs as specified in
Link/PE failures MUST be handled on the GWs as specified in [EVPN]. [RFC7432]. The GW detecting the failure will withdraw the EVPN routes
as per [RFC7432].
The GW detecting the failure will withdraw the EVPN routes as per
[EVPN].
Individual AC/PW failures should be detected by OAM mechanisms. For Individual AC/PW failures should be detected by OAM mechanisms. For
instance: instance:
o If the Interconnect solution is based on a VLAN hand-off, o If the Interconnect solution is based on a VLAN hand-off,
802.1ag/Y.1731 Ethernet-CFM MAY be used to detect individual AC 802.1ag/Y.1731 Ethernet-CFM MAY be used to detect individual AC
failures on both, the GW and WAN Edge router. An individual AC failures on both, the GW and WAN Edge router. An individual AC
failure will trigger the withdrawal of the corresponding A-D per failure will trigger the withdrawal of the corresponding A-D per
EVI route as well as the MACs learnt on that AC. EVI route as well as the MACs learnt on that AC.
skipping to change at page 9, line 48 skipping to change at page 9, line 48
technology supported in the WAN, i.e. (PBB-)VPLS or (PBB-)EVPN, as technology supported in the WAN, i.e. (PBB-)VPLS or (PBB-)EVPN, as
depicted in Figure 2. depicted in Figure 2.
o Multi-homing MUST be supported. Single-active multi-homing with o Multi-homing MUST be supported. Single-active multi-homing with
per-service load balancing MUST be implemented. All-active multi- per-service load balancing MUST be implemented. All-active multi-
homing, i.e. per-flow load-balancing, MUST be implemented as long homing, i.e. per-flow load-balancing, MUST be implemented as long
as the technology deployed in the WAN supports it. as the technology deployed in the WAN supports it.
o If EVPN is deployed in the WAN, the MAC Mobility, Static MAC o If EVPN is deployed in the WAN, the MAC Mobility, Static MAC
protection and other procedures (e.g. proxy-arp) described in protection and other procedures (e.g. proxy-arp) described in
[EVPN] must be supported end-to-end. [RFC7432] must be supported end-to-end.
o Any type of inclusive multicast tree MUST be independently o Any type of inclusive multicast tree MUST be independently
supported in the WAN as per [EVPN], and in the DC as per [EVPN- supported in the WAN as per [RFC7432], and in the DC as per [EVPN-
Overlays]. Overlays].
3.2. VPLS Interconnect for EVPN-Overlay networks 3.2. VPLS Interconnect for EVPN-Overlay networks
3.2.1. Control/Data Plane setup procedures on the GWs 3.2.1. Control/Data Plane setup procedures on the GWs
Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN
PEs and RRs as per [RFC4761][RFC4762][RFC6074] and overlay tunnels PEs and RRs as per [RFC4761][RFC4762][RFC6074] and overlay tunnels
and EVPN will be setup as per [EVPN-Overlays]. Note that different and EVPN will be setup as per [EVPN-Overlays]. Note that different
route-targets for the DC and for the WAN are normally required. A route-targets for the DC and for the WAN are normally required. A
single type-1 RD per service can be used. single type-1 RD per service can be used.
In order to support multi-homing, the GWs will be provisioned with an In order to support multi-homing, the GWs will be provisioned with an
I-ESI (see section 2.4), that will be unique per interconnection. All I-ESI (see section 2.4), that will be unique per interconnection. All
the [EVPN] procedures are still followed for the I-ESI, e.g. any MAC the [RFC7432] procedures are still followed for the I-ESI, e.g. any
address learnt from the WAN will be advertised to the DC with the MAC address learnt from the WAN will be advertised to the DC with the
I-ESI in the ESI field. I-ESI in the ESI field.
A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have
two different types of tunnel bindings instantiated in two different two different types of tunnel bindings instantiated in two different
split-horizon-groups: split-horizon-groups:
o VPLS PWs will be instantiated in the "WAN split-horizon-group". o VPLS PWs will be instantiated in the "WAN split-horizon-group".
o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated
in the "DC split-horizon-group". in the "DC split-horizon-group".
skipping to change at page 12, line 14 skipping to change at page 12, line 14
All the single-active multi-homing procedures as described by [EVPN- All the single-active multi-homing procedures as described by [EVPN-
Overlays] will be followed for the I-ESI for each EVI instance Overlays] will be followed for the I-ESI for each EVI instance
connected to B-component. connected to B-component.
3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks 3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks
If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the
WAN, an end-to-end EVPN solution can be deployed. The following WAN, an end-to-end EVPN solution can be deployed. The following
sections describe the proposed solution as well as the impact sections describe the proposed solution as well as the impact
required on the [EVPN] procedures. required on the [RFC7432] procedures.
3.4.1. Control Plane setup procedures on the GWs 3.4.1. Control Plane setup procedures on the GWs
The GWs MUST establish separate BGP sessions for sending/receiving The GWs MUST establish separate BGP sessions for sending/receiving
EVPN routes to/from the DC and to/from the WAN. Normally each GW will EVPN routes to/from the DC and to/from the WAN. Normally each GW will
setup one (two) BGP EVPN session(s) to the DC RR(s) and one(two) setup one (two) BGP EVPN session(s) to the DC RR(s) and one(two)
session(s) to the WAN RR(s). The same route-distinguisher (RD) per session(s) to the WAN RR(s). The same route-distinguisher (RD) per
MAC-VRF can be used for the EVPN routes sent to both, WAN and DC RRs. MAC-VRF can be used for the EVPN service routes sent to both, WAN and
On the contrary, although reusing the same value is possible, DC RRs. On the contrary, although reusing the same value is possible,
different route-targets are expected to be handled for the same EVI different route-targets are expected to be handled for the same EVI
in the WAN and the DC. in the WAN and the DC. Note that the EVPN service routes sent to the
DC RRs will normally include a [RFC5512] BGP encapsulation extended
community with a different tunnel type than the one sent to the WAN
RRs.
As in the other discussed options, an I-ESI will be configured on the As in the other discussed options, an I-ESI will be configured on the
GWs for multi-homing. GWs for multi-homing. This I-ESI represents the WAN to the DC but
also the DC to the WAN.
Received EVPN routes will never be reflected on the GWs but consumed Received EVPN routes will never be reflected on the GWs but consumed
and re-advertised (if needed): and re-advertised (if needed):
o Ethernet A-D routes, ES routes and inclusive multicast routes o Ethernet A-D routes, ES routes and Inclusive Multicast routes
are consumed by the GWs and processed locally for the are consumed by the GWs and processed locally for the
corresponding [EVPN] procedures. corresponding [RFC7432] procedures.
o MAC/IP advertisement routes will be received, imported and if o MAC/IP advertisement routes will be received, imported and if
they become active in the MAC-VRF MAC FIB, the information will they become active in the MAC-VRF MAC FIB, the information will
be re-advertised as new routes with the following fields: be re-advertised as new routes with the following fields:
+ The RD will be the GW's RD for the MAC-VRF. + The RD will be the GW's RD for the MAC-VRF.
+ The ESI will be set to the I-ESI. + The ESI will be set to the I-ESI.
+ The Ethernet-tag will be 0 or a new value. + The Ethernet-tag value will be kept from the received NLRI.
+ The MAC length, MAC address, IP Length and IP address values + The MAC length, MAC address, IP Length and IP address values
will be kept from the received DC NLRI. will be kept from the received NLRI.
+ The MPLS label will be a local value (when sent to the WAN) or + The MPLS label will be a local 20-bit value (when sent to the
a DC-global value (when sent to the DC). WAN) or a DC-global 24-bit value (when sent to the DC).
+ The appropriate Route-Targets (RTs) and [RFC5512] BGP + The appropriate Route-Targets (RTs) and [RFC5512] BGP
Encapsulation extended community will be used according to Encapsulation extended community will be used according to
[EVPN-Overlays]. [EVPN-Overlays].
The GWs will also generate the following local EVPN routes that will The GWs will also generate the following local EVPN routes that will
be sent to the DC and WAN, with their corresponding RTs and [RFC5512] be sent to the DC and WAN, with their corresponding RTs and [RFC5512]
BGP Encapsulation extended community values: BGP Encapsulation extended community values:
o ES route for the I-ESI. o ES route for the I-ESI.
o Ethernet A-D routes per ESI and EVI for the I-ESI. o Ethernet A-D routes per ESI and EVI for the I-ESI. The A-D per-
EVI routes sent to the WAN and the DC will have a consistent
Ethernet-Tag values.
o Inclusive multicast routes with independent tunnel type value o Inclusive Multicast routes with independent tunnel type value
for the WAN and DC. E.g. a P2MP LSP may be used in the WAN for the WAN and DC. E.g. a P2MP LSP may be used in the WAN
whereas ingress replication is used in the DC. whereas ingress replication may be used in the DC. The routes
sent to the WAN and the DC will have a consistent Ethernet-Tag.
o MAC/IP advertisement routes for MAC addresses learnt in local o MAC/IP advertisement routes for MAC addresses learned in local
attachment circuits. Note that these routes will not include the attachment circuits. Note that these routes will not include the
I-ESI, but ESI=0 or different from 0 for local Ethernet Segments I-ESI, but ESI=0 or different from 0 for local Ethernet Segments
(ES). (ES). The routes sent to the WAN and the DC will have a
consistent Ethernet-Tag.
Note that each GW will receive two copies of each of the above routes
generated by the peer GW (one copy for the DC encapsulation and one
copy for the WAN encapsulation). This is the expected behavior on the
GW:
o ES and A-D (per ESI) routes: regular BGP selection will be Assuming GW1 and GW2 are peer GWs of the same DC, each GW will
applied. generate two sets of local service routes: Set-DC will be sent to the
DC RRs and will include A-D per EVI, Inclusive Multicast and MAC/IP
routes for the DC encapsulation and RT. Set-WAN will be sent to the
WAN RRs and will include the same routes but using the WAN RT and
encapsulation. GW1 and GW2 will receive each other's set-DC and set-
WAN. This is the expected behavior on GW1 and GW2 for locally
generated routes:
o Inclusive multicast routes: if the Ethernet Tag ID matches on o Inclusive multicast routes: when setting up the flooding lists
both routes, regular BGP selection applies and only one route for a given MAC-VRF, each GW will include its DC peer GW only in
will be active. It is recommended to influence the BGP selection the EVPN-overlay flooding list (by default) and not the EVPN-
so that the DC route is preferred. If the Ethernet Tag ID does MPLS flooding list. That is, GW2 will import two Inclusive
not match, then BGP will consider them two separate routes. In Multicast routes from GW1 (from set-DC and set-WAN) but will
that case, the MAC-VRF will select the DC route. only consider one of the two, having the set-DC route higher
priority.
o MAC/IP advertisement routes for local attachment circuits: as o MAC/IP advertisement routes for local attachment circuits: as
above, the GW will select only one. The decision will be made at above, the GW will select only one, having the route from the
BGP or MAC-RVRF level, depending on the Ethernet Tags. set-DC a higher priority.
The optimizations procedures described in section 2.5 can also be
applied to this option.
3.4.2. Data Plane setup procedures on the GWs 3.4.2. Data Plane setup procedures on the GWs
The procedure explained at the end of the previous section will make The procedure explained at the end of the previous section will make
sure there are no loops or packet duplication between the GWs of the sure there are no loops or packet duplication between the GWs of the
same DC since only one EVPN binding will be setup in the data plane same DC (for frames generated from local ACs) since only one EVPN
between the two nodes. binding per EVI will be setup in the data plane between the two
nodes. That binding will by default be added to the EVPN-overlay
flooding list.
As for the rest of the EVPN tunnel bindings, two flooding lists will As for the rest of the EVPN tunnel bindings, they will be added to
be setup by each GW for the same MAC-VRF: one of the two flooding lists that each GW sets up for the same MAC-
VRF:
o EVPN-overlay flooding list (composed of bindings to the remote o EVPN-overlay flooding list (composed of bindings to the remote
NVEs or multicast tunnel to the NVEs). NVEs or multicast tunnel to the NVEs).
o EVPN-MPLS flooding list (composed of MP2P and or LSM tunnel to o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the
the remote PEs) remote PEs)
Each flooding list will be part of a separate split-horizon-group. Each flooding list will be part of a separate split-horizon-group:
Traffic generated from a local AC can be flooded to both the WAN split-horizon-group or the DC split-horizon-group. Traffic
generated from a local AC can be flooded to both
split-horizon-groups. Traffic from a binding of a split-horizon-group split-horizon-groups. Traffic from a binding of a split-horizon-group
can be flooded to the other split-horizon-group and local ACs, but can be flooded to the other split-horizon-group and local ACs, but
never to a member of its own split-horizon-group. never to a member of its own split-horizon-group.
When either GW1 or GW2 receive a BUM frame on an overlay tunnel, they
will perform a tunnel IP SA lookup to determine if the packet's
origin is the peer DC GW, i.e. GW2 or GW1 respectively. If the packet
is coming from the peer DC GW, it MUST only be flooded to local
attachment circuits and not to the WAN split-horizon-group (the
assumption is that the peer GW would have sent the BUM packet to the
WAN directly).
3.4.3. Multi-homing procedures on the GWs 3.4.3. Multi-homing procedures on the GWs
Single-active as well as all-active multi-homing MUST be supported. Single-active as well as all-active multi-homing MUST be supported.
All the multi-homing procedures as described by [EVPN] will be All the multi-homing procedures as described by [RFC7432] will be
followed for the DF election for I-ESI, as well as the backup-path followed for the DF election for I-ESI, as well as the backup-path
(single-active) and aliasing (all-active) procedures on the remote (single-active) and aliasing (all-active) procedures on the remote
PEs/NVEs. The following changes are required at the GW with respect PEs/NVEs. The following changes are required at the GW with respect
to the I-ESI: to the I-ESI:
o Single-active multi-homing; assuming a WAN split-horizon-group, o Single-active multi-homing; assuming a WAN split-horizon-group,
a DC split-horizon-group and local ACs on the GWs: a DC split-horizon-group and local ACs on the GWs:
+ Forwarding behavior on the non-DF: the non-DF MUST NOT forward + Forwarding behavior on the non-DF: the non-DF MUST NOT forward
BUM or unicast traffic received from a given split-horizon- BUM or unicast traffic received from a given split-horizon-
group to a member of his own split-horizon group or to the group to a member of its own split-horizon-group or to the
other split-horizon-group. Only forwarding to local ACs is other split-horizon-group. Only forwarding to local ACs is
allowed (as long as they are not part of an ES for which the allowed (as long as they are not part of an ES for which the
node is non-DF). node is non-DF).
+ Forwarding behavior on the DF: the DF MUST NOT forward BUM or + Forwarding behavior on the DF: the DF MUST NOT forward BUM or
unicast traffic received from a given split-horizon-group to a unicast traffic received from a given split-horizon-group to a
member of his own split-horizon group or to the non-DF. member of his own split-horizon group or to the non-DF.
Forwarding to the other split-horizon-group and local ACs is Forwarding to the other split-horizon-group (except the non-
allowed (as long as they are not part of an ES for which the DF) and local ACs is allowed (as long as the ACs are not part
node is non-DF). of an ES for which the node is non-DF).
o All-active multi-homing; assuming a WAN split-horizon-group, a o All-active multi-homing; assuming a WAN split-horizon-group, a
DC split-horizon-group and local ACs on the GWs: DC split-horizon-group and local ACs on the GWs:
+ Forwarding behavior on the non-DF: the non-DF follows the same + Forwarding behavior on the non-DF: the non-DF follows the same
behavior as the non-DF in the single-active case but only for behavior as the non-DF in the single-active case but only for
BUM traffic. Unicast traffic received from a split-horizon- BUM traffic. Unicast traffic received from a split-horizon-
group MUST NOT be forwarded to a member of its own split- group MUST NOT be forwarded to a member of its own split-
horizon-group but can be forwarded normally to the other horizon-group but can be forwarded normally to the other
split-horizon-group and local ACs. If a known unicast packet split-horizon-group and local ACs. If a known unicast packet
skipping to change at page 15, line 34 skipping to change at page 16, line 4
horizon-group) to each other. horizon-group) to each other.
3.4.4. Impact on MAC Mobility procedures 3.4.4. Impact on MAC Mobility procedures
Since the MAC/IP Advertisement routes are not reflected in the GWs Since the MAC/IP Advertisement routes are not reflected in the GWs
but rather consumed and re-advertised if active, the MAC Mobility but rather consumed and re-advertised if active, the MAC Mobility
procedures can be constrained to each domain (DC or WAN) and resolved procedures can be constrained to each domain (DC or WAN) and resolved
within each domain. In other words, if a MAC moves within the DC, the within each domain. In other words, if a MAC moves within the DC, the
GW MUST NOT re-advertise the route to the WAN with a change in the GW MUST NOT re-advertise the route to the WAN with a change in the
sequence number. Only when the MAC moves from the WAN domain to the sequence number. Only when the MAC moves from the WAN domain to the
DC domain, the GW will re-advertise the MAC with a higher sequence DC domain (or from one DC to another) the GW will re-advertise the
number in the MAC Mobility extended community. In respect to the MAC MAC with a higher sequence number in the MAC Mobility extended
Mobility procedures described in [EVPN] the MAC addresses learnt from community. In respect to the MAC Mobility procedures described in
the NVEs in the local DC or on the local ACs will be considered as [RFC7432] the MAC addresses learned from the NVEs in the local DC or
local. on the local ACs will be considered as local.
The sequence numbers MUST NOT be propagated between domains. The The sequence numbers MUST NOT be propagated between domains. The
sticky bit indication in the MAC Mobility extended community MUST be sticky bit indication in the MAC Mobility extended community MUST be
propagated between domains. propagated between domains.
3.4.5. Gateway optimizations 3.4.5. Gateway optimizations
All the Gateway optimizations described in section 2.5 MAY be applied All the Gateway optimizations described in section 2.5 MAY be applied
to the GWs when the Interconnect is based on EVPN-MPLS. to the GWs when the Interconnect is based on EVPN-MPLS.
skipping to change at page 17, line 38 skipping to change at page 18, line 7
plane through EVPN running on the I-component. Remote C-MACs coming plane through EVPN running on the I-component. Remote C-MACs coming
from remote PEs are still learnt in the data plane. B-MACs in the B- from remote PEs are still learnt in the data plane. B-MACs in the B-
component will be assigned and advertised following the procedures component will be assigned and advertised following the procedures
described in [PBB-EVPN]. described in [PBB-EVPN].
An I-ESI will be configured on the GWs for multi-homing, but it will An I-ESI will be configured on the GWs for multi-homing, but it will
only be used in the EVPN control plane for the I-component EVI. No only be used in the EVPN control plane for the I-component EVI. No
non-reserved ESIs will be used in the control plane of the B- non-reserved ESIs will be used in the control plane of the B-
component EVI as per [PBB-EVPN]. component EVI as per [PBB-EVPN].
The rest of the control plane procedures will follow [EVPN] for the The rest of the control plane procedures will follow [RFC7432] for
I-component EVI and [PBB-EVPN] for the B-component EVI. the I-component EVI and [PBB-EVPN] for the B-component EVI.
From the data plane perspective, the I-component and B-component EVPN From the data plane perspective, the I-component and B-component EVPN
bindings established to the same far-end will be compared and the I- bindings established to the same far-end will be compared and the I-
component EVPN-overlay binding will be kept down following the rules component EVPN-overlay binding will be kept down following the rules
described in section 3.3.1. described in section 3.3.1.
3.5.2. Multi-homing procedures on the GWs 3.5.2. Multi-homing procedures on the GWs
Single-active as well as all-active multi-homing MUST be supported. Single-active as well as all-active multi-homing MUST be supported.
The forwarding behavior of the DF and non-DF will be changed based on The forwarding behavior of the DF and non-DF will be changed based on
the description outlined in section 3.4.3, only replacing the "WAN the description outlined in section 3.4.3, only replacing the "WAN
split-horizon-group" for the B-component. split-horizon-group" for the B-component.
3.5.3. Impact on MAC Mobility procedures 3.5.3. Impact on MAC Mobility procedures
C-MACs learnt from the B-component will be advertised in EVPN within C-MACs learnt from the B-component will be advertised in EVPN within
the I-component EVI scope. If the C-MAC was previously known in the the I-component EVI scope. If the C-MAC was previously known in the
I-component database, EVPN would advertise the C-MAC with a higher I-component database, EVPN would advertise the C-MAC with a higher
sequence number, as per [EVPN]. From a Mobility perspective and the sequence number, as per [RFC7432]. From a Mobility perspective and
related procedures described in [EVPN], the C-MACs learnt from the B- the related procedures described in [RFC7432], the C-MACs learnt from
component are considered local. the B-component are considered local.
3.5.4. Gateway optimizations 3.5.4. Gateway optimizations
All the considerations explained in section 3.4.5 are applicable to All the considerations explained in section 3.4.5 are applicable to
the PBB-EVPN Interconnect option. the PBB-EVPN Interconnect option.
3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks 3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks
If EVPN for Overlay tunnels is supported in the WAN and a GW function If EVPN for Overlay tunnels is supported in the WAN and a GW function
is required, an end-to-end EVPN solution can be deployed. This is required, an end-to-end EVPN solution can be deployed. This
section focuses on the specific case of EVPN for VXLAN (EVPN-VXLAN section focuses on the specific case of EVPN for VXLAN (EVPN-VXLAN
hereafter) and the impact on the [EVPN] procedures. hereafter) and the impact on the [RFC7432] procedures.
This use-case assumes that NVEs need to use the VNIs or VSIDs as a This use-case assumes that NVEs need to use the VNIs or VSIDs as a
globally unique identifiers within a data center, and a Gateway needs globally unique identifiers within a data center, and a Gateway needs
to be employed at the edge of the data center network to translate to be employed at the edge of the data center network to translate
the VNI or VSID when crossing the network boundaries. This GW the VNI or VSID when crossing the network boundaries. This GW
function provides VNI and tunnel IP address translation. The use-case function provides VNI and tunnel IP address translation. The use-case
in which local downstream assigned VNIs or VSIDs can be used (like in which local downstream assigned VNIs or VSIDs can be used (like
MPLS labels) is described by [EVPN-Overlays]. MPLS labels) is described by [EVPN-Overlays].
While VNIs are globally significant within each DC, there are two While VNIs are globally significant within each DC, there are two
skipping to change at page 21, line 4 skipping to change at page 21, line 19
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers VNI/VSID: refers to VXLAN/NVGRE virtual identifiers
VSI: Virtual Switch Instance or VPLS instance in a particular PE VSI: Virtual Switch Instance or VPLS instance in a particular PE
6. Security Considerations 6. Security Considerations
This section will be completed in future versions. This section will be completed in future versions.
7. IANA Considerations 7. IANA Considerations
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN [RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN
Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761,
January 2007, <http://www.rfc-editor.org/info/rfc4761>. DOI 10.17487/RFC4761, January 2007, <http://www.rfc-
editor.org/info/rfc4761>.
[RFC4762]Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private [RFC4762]Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007, <http://www.rfc- Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
editor.org/info/rfc4762>. <http://www.rfc-editor.org/info/rfc4762>.
[RFC6074]Rosen, E., Davie, B., Radoaca, V., and W. Luo, [RFC6074]Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual
Private Networks (L2VPNs)", RFC 6074, January 2011, <http://www.rfc- Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January
editor.org/info/rfc6074>. 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC7041]Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., [RFC7041]Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
"Extensions to the Virtual Private LAN Service (VPLS) Provider Edge "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge
(PE) Model for Provider Backbone Bridging", RFC 7041, November 2013, (PE) Model for Provider Backbone Bridging", RFC 7041, DOI
<http://www.rfc-editor.org/info/rfc7041>. 10.17487/RFC7041, November 2013, <http://www.rfc-
editor.org/info/rfc7041>.
8.2. Informative References [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
editor.org/info/rfc7432>.
[EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 8.2. Informative References
l2vpn-evpn-11.txt, work in progress, October, 2014
[PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-07, [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-10,
work in progress, June, 2014 work in progress, May, 2015
[EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-00.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01.txt,
work in progress, November, 2014 work in progress, February, 2015
[EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless [EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless
Integration with (PBB-)VPLS", draft-sajassi-bess-evpn-vpls- Integration with (PBB-)VPLS", draft-ietf-bess-evpn-vpls-integration-
integration-00.txt, work in progress, October, 2014 00.txt, work in progress, February, 2015
9. Acknowledgments 9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. The authors would like to thank Neil Hart for their valuable comments
and feedback.
10. Contributors
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:
Florin Balus
John Drake
11. Authors' Addresses
10. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Alcatel-Lucent Alcatel-Lucent
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@alcatel-lucent.com Email: jorge.rabadan@alcatel-lucent.com
Senthil Sathappan Senthil Sathappan
Alcatel-Lucent Alcatel-Lucent
Email: senthil.sathappan@alcatel-lucent.com Email: senthil.sathappan@alcatel-lucent.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.com
Florin Balus
Nuage Networks
Email: florin@nuagenetworks.net
Senad Palislamovic Senad Palislamovic
Alcatel-Lucent Alcatel-Lucent
Email: senad.palislamovic@alcatel-lucent.com Email: senad.palislamovic@alcatel-lucent.com
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Ravi Shekhar Ravi Shekhar
Juniper Juniper
 End of changes. 60 change blocks. 
107 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/