draft-ietf-bess-dci-evpn-overlay-01.txt   draft-ietf-bess-dci-evpn-overlay-02.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 Nokia
A. Lohiya A. Lohiya
Juniper Juniper
A. Sajassi A. Sajassi
D. Cai D. Cai
Cisco Cisco
Expires: January 7, 2016 July 6, 2015 Expires: September 1, 2016 February 29, 2016
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-01 draft-ietf-bess-dci-evpn-overlay-02
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 6 skipping to change at page 2, line 6
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 January 7, 2016. This Internet-Draft will expire on September 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 36
2. Decoupled Interconnect solution for EVPN overlay networks . . . 3 2. Decoupled Interconnect solution for EVPN overlay networks . . . 3
2.1. Interconnect requirements . . . . . . . . . . . . . . . . . 4 2.1. Interconnect requirements . . . . . . . . . . . . . . . . . 4
2.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 5 2.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 5
2.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 5 2.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 5
2.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 6 2.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 6
2.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 6 2.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 6
2.5.1 Use of the Unknown MAC route to reduce unknown 2.5.1 Use of the Unknown MAC route to reduce unknown
flooding . . . . . . . . . . . . . . . . . . . . . . . . 6 flooding . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.2. MAC address advertisement control . . . . . . . . . . . 7 2.5.2. MAC address advertisement control . . . . . . . . . . . 7
2.5.3. ARP flooding control . . . . . . . . . . . . . . . . . 7 2.5.3. ARP flooding control . . . . . . . . . . . . . . . . . 7
2.5.4. Handling failures between GW and WAN Edge routers . . . 7 2.5.4. Handling failures between GW and WAN Edge routers . . . 8
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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 15 3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 15
3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . 18 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 . 20 3.6.2. Downstream assigned VNIs in the Interconnect network . 19
5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20 5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 3, line 42 skipping to change at page 3, line 42
the WAN in some cases due to the requirements and existing deployed the WAN in some cases due to the requirements and existing deployed
technologies. For instance, a Service Provider might have an already technologies. For instance, a Service Provider might have an already
deployed (PBB-)VPLS or (PBB-)EVPN network that must be used to deployed (PBB-)VPLS or (PBB-)EVPN network that must be used to
interconnect Data Centers and WAN VPN users. A Gateway (GW) function interconnect Data Centers and WAN VPN users. A Gateway (GW) function
is required in these cases. is required in these cases.
This document describes a Interconnect solution for EVPN overlay This document describes a Interconnect solution for EVPN overlay
networks, assuming that the NVO Gateway (GW) and the WAN Edge networks, assuming that the NVO Gateway (GW) and the WAN Edge
functions can be decoupled in two separate systems or integrated into functions can be decoupled in two separate systems or integrated into
the same system. The former option will be referred as "Decoupled the same system. The former option will be referred as "Decoupled
Interconnect solution" throughout the document whereas the latter one Interconnect solution" throughout the document, whereas the latter
will be referred as "Integrated Interconnect solution". one will be referred as "Integrated Interconnect solution".
2. Decoupled Interconnect solution for EVPN overlay networks 2. Decoupled Interconnect solution for EVPN overlay networks
This section describes the interconnect solution when the GW and WAN This section describes the interconnect solution when the GW and WAN
Edge functions are implemented in different systems. Figure 1 depicts Edge functions are implemented in different systems. Figure 1 depicts
the reference model described in this section. the reference model described in this section.
+--+ +--+
|CE| |CE|
+--+ +--+
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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
[RFC7432]. This Interconnect ESI will be referred as "I-ESI" [RFC7432]. This Interconnect ESI will be referred as "I-ESI"
hereafter. 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 learned (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
The following features MAY be supported on the GW in order to The following features MAY be supported on the GW in order to
optimize the control plane and data plane in the DC. optimize the control plane and data plane in the DC.
2.5.1 Use of the Unknown MAC route to reduce unknown flooding 2.5.1 Use of the Unknown MAC route to reduce unknown flooding
The use of EVPN in the NVO networks brings a significant number of The use of EVPN in the NVO networks brings a significant number of
benefits as described in [EVPN-Overlays]. There are however some benefits as described in [EVPN-Overlays]. There are however some
potential issues that SHOULD be addressed when the DC EVIs are potential issues that SHOULD be addressed when the DC EVIs are
connected to the WAN VPN instances. connected to the WAN VPN instances.
The first issue is the additional unknown unicast flooding created in The first issue is the additional unknown unicast flooding created in
the DC due to the unknown MACs existing beyond the GW. In virtualized the DC due to the unknown MACs existing beyond the GW. In virtualized
DCs where all the MAC addresses are learnt in the control/management DCs where all the MAC addresses are learned in the control/management
plane, unknown unicast flooding is significantly reduced. This is no plane, unknown unicast flooding is significantly reduced. This is no
longer true if the GW is connected to a layer-2 domain with data longer true if the GW is connected to a layer-2 domain with data
plane learning. plane learning.
The solution suggested in this document is based on the use of an The solution suggested in this document is based on the use of an
"Unknown MAC route" that is advertised by the Designated Forwarder "Unknown MAC route" that is advertised by the Designated Forwarder
GW. The Unknown MAC route is a regular EVPN MAC/IP Advertisement GW. The Unknown MAC route is a regular EVPN MAC/IP Advertisement
route where the MAC Address Length is set to 48 and the MAC address route where the MAC Address Length is set to 48 and the MAC address
to 00:00:00:00:00:00 (IP length is set to 0). to 00:00:00:00:00:00 (IP length is set to 0).
skipping to change at page 7, line 24 skipping to change at page 7, line 24
MAC route. The NVEs supporting this concept will prune their unknown MAC route. The NVEs supporting this concept will prune their unknown
unicast flooding list and will only send the unknown unicast packets unicast flooding list and will only send the unknown unicast packets
to the owner of the Unknown MAC route. Note that the I-ESI will be to the owner of the Unknown MAC route. Note that the I-ESI will be
encoded in the ESI field of the NLRI so that regular multi-homing encoded in the ESI field of the NLRI so that regular multi-homing
procedures can be applied to this unknown MAC too (e.g. backup-path). procedures can be applied to this unknown MAC too (e.g. backup-path).
2.5.2. MAC address advertisement control 2.5.2. MAC address advertisement control
Another issue derived from the EVI interconnect to the WAN layer-2 Another issue derived from the EVI interconnect to the WAN layer-2
domain is the potential massive MAC advertisement into the DC. All domain is the potential massive MAC advertisement into the DC. All
the MAC addresses learnt from the WAN on the hand-off attachment the MAC addresses learned from the WAN on the hand-off attachment
circuits or PWs must be advertised by BGP EVPN. Even if optimized BGP circuits or PWs must be advertised by BGP EVPN. Even if optimized BGP
techniques like RT-constraint are used, the amount of MAC addresses techniques like RT-constraint are used, the amount of MAC addresses
to advertise or withdraw (in case of failure) from the GWs can be to advertise or withdraw (in case of failure) from the GWs can be
difficult to control and overwhelming for the DC network, especially difficult to control and overwhelming for the DC network, especially
when the NVEs reside in the hypervisors. when the NVEs reside in the hypervisors.
This document proposes the addition of administrative options so that This document proposes the addition of administrative options so that
the user can enable/disable the advertisement of MAC addresses learnt the user can enable/disable the advertisement of MAC addresses
from the WAN as well as the advertisement of the Unknown MAC route learned from the WAN as well as the advertisement of the Unknown MAC
from the DF GW. In cases where all the DC MAC addresses are learnt in route from the DF GW. In cases where all the DC MAC addresses are
the control/management plane, the GW may disable the advertisement of learned in the control/management plane, the GW may disable the
WAN MAC addresses. Any frame with unknown destination MAC will be advertisement of WAN MAC addresses. Any frame with unknown
exclusively sent to the Unknown MAC route owner(s). destination MAC will be 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 [RFC7432]. 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.
skipping to change at page 8, line 15 skipping to change at page 8, line 18
[RFC7432]. The GW detecting the failure will withdraw the EVPN routes [RFC7432]. The GW detecting the failure will withdraw the EVPN routes
as per [RFC7432]. as per [RFC7432].
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 learned on that AC.
o If the Interconnect solution is based on a PW hand-off, the LDP PW o If the Interconnect solution is based on a PW hand-off, the LDP PW
Status bits TLV MAY be used to detect individual PW failures on Status bits TLV MAY be used to detect individual PW failures on
both, the GW and WAN Edge router. both, the GW and WAN Edge router.
3. Integrated Interconnect solution for EVPN overlay networks 3. Integrated Interconnect solution for EVPN overlay networks
When the DC and the WAN are operated by the same administrative When the DC and the WAN are operated by the same administrative
entity, the Service Provider can decide to integrate the GW and WAN entity, the Service Provider can decide to integrate the GW and WAN
Edge PE functions in the same router for obvious CAPEX and OPEX Edge PE functions in the same router for obvious CAPEX and OPEX
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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 may 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 [RFC7432] procedures are still followed for the I-ESI, e.g. any the [RFC7432] procedures are still followed for the I-ESI, e.g. any
MAC address learnt from the WAN will be advertised to the DC with the MAC address learned from the WAN will be advertised to the DC with
I-ESI in the ESI field. the 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 22 skipping to change at page 12, line 22
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 [RFC7432] 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 service routes sent to both, WAN and MAC-VRF MAY be used for the EVPN service routes sent to both, WAN and
DC RRs. 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. Note that the EVPN service routes sent to the 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 DC RRs will normally include a [RFC5512] BGP encapsulation extended
community with a different tunnel type than the one sent to the WAN community with a different tunnel type than the one sent to the WAN
RRs. 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. This I-ESI represents the WAN to the DC but GWs for multi-homing. This I-ESI represents the WAN to the DC but
also the DC to the WAN. also the DC to the WAN.
skipping to change at page 15, line 47 skipping to change at page 15, line 47
identified as a "flooded" packet, the procedures for BUM identified as a "flooded" packet, the procedures for BUM
traffic MUST be followed. traffic MUST be followed.
o No ESI label is required to be signaled for I-ESI for its use by o No ESI label is required to be signaled for I-ESI for its use by
the non-DF in the data path. This is possible because the non-DF the non-DF in the data path. This is possible because the non-DF
and the DF will never forward BUM traffic (coming from a split- and the DF will never forward BUM traffic (coming from a split-
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 MAC Mobility procedures described in [RFC7432] are not modified by
but rather consumed and re-advertised if active, the MAC Mobility this document.
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
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
DC domain (or from one DC to another) the GW will re-advertise the
MAC with a higher sequence number in the MAC Mobility extended
community. In respect to the MAC Mobility procedures described in
[RFC7432] the MAC addresses learned from the NVEs in the local DC or
on the local ACs will be considered as local.
The sequence numbers MUST NOT be propagated between domains. The Note that an intra-DC MAC move still leaves the MAC attached to the
sticky bit indication in the MAC Mobility extended community MUST be same I-ESI, so under the rules of [RFC7432] this is not considered a
propagated between domains. MAC mobility event. Only when the MAC moves from the WAN domain to
the DC domain (or from one DC to another) the MAC will be learned
from a different ES and the MAC Mobility procedures will kick in.
The sticky bit indication in the MAC Mobility extended community MUST
be 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.
In particular, the use of the Unknown MAC route, as described in In particular, the use of the Unknown MAC route, as described in
section 2.5.1, reduces the unknown flooding in the DC but also solves section 2.5.1, reduces the unknown flooding in the DC but also solves
some transient packet duplication issues in cases of all-active some transient packet duplication issues in cases of all-active
multi-homing. This is explained in the following paragraph. multi-homing. This is explained in the following paragraph.
skipping to change at page 17, line 31 skipping to change at page 17, line 28
single label per GW MAC-VRF as opposed to a label per NVE/MAC- single label per GW MAC-VRF as opposed to a label per NVE/MAC-
VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE
would receive only one label for all the routes advertised for a would receive only one label for all the routes advertised for a
given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF. given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF.
o The GW will not propagate MAC mobility for the MACs moving o The GW will not propagate MAC mobility for the MACs moving
within a DC. Mobility intra-DC is solved by all the NVEs in the within a DC. Mobility intra-DC is solved by all the NVEs in the
DC. The MAC Mobility procedures on the GWs are only required in DC. The MAC Mobility procedures on the GWs are only required in
case of mobility across DCs. case of mobility across DCs.
o Proxy-ARP/ND function on the DGWs can be leveraged to reduce o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce
ARP/ND flooding in the DC or/and in the WAN. ARP/ND flooding in the DC or/and in the WAN.
3.5. PBB-EVPN Interconnect for EVPN-Overlay networks 3.5. PBB-EVPN Interconnect for EVPN-Overlay networks
[PBB-EVPN] is yet another Interconnect option. It requires the use of [PBB-EVPN] is yet another Interconnect option. It requires the use of
GWs where I-components and associated B-components are EVI GWs where I-components and associated B-components are EVI
instances. instances.
3.5.1. Control/Data Plane setup procedures on the GWs 3.5.1. Control/Data Plane setup procedures on the GWs
EVPN will run independently in both components, the I-component MAC- EVPN will run independently in both components, the I-component MAC-
VRF and B-component MAC-VRF. Compared to [PBB-EVPN], the DC C-MACs VRF and B-component MAC-VRF. Compared to [PBB-EVPN], the DC C-MACs
are no longer learnt in the data plane on the GW but in the control are no longer learned in the data plane on the GW but in the control
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 learned 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 [RFC7432] for The rest of the control plane procedures will follow [RFC7432] for
the I-component EVI and [PBB-EVPN] for the B-component EVI. the I-component EVI and [PBB-EVPN] for the B-component EVI.
skipping to change at page 18, line 25 skipping to change at page 18, line 23
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 learned 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 [RFC7432]. From a Mobility perspective and sequence number, as per [RFC7432]. From a Mobility perspective and
the related procedures described in [RFC7432], the C-MACs learnt from the related procedures described in [RFC7432], the C-MACs learned
the B-component are considered local. from 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
skipping to change at page 22, line 5 skipping to change at page 21, line 46
"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, DOI (PE) Model for Provider Backbone Bridging", RFC 7041, DOI
10.17487/RFC7041, November 2013, <http://www.rfc- 10.17487/RFC7041, November 2013, <http://www.rfc-
editor.org/info/rfc7041>. editor.org/info/rfc7041>.
[RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
editor.org/info/rfc7432>. editor.org/info/rfc7432>.
8.2. Informative References [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc-
editor.org/info/rfc7623>.
[PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-10, 8.2. Informative References
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-01.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-02.txt,
work in progress, February, 2015 work in progress, October, 2015
[EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless [EVPN-VPLS-INTEGRATION] Sajassi et al., "(PBB-)EVPN Seamless
Integration with (PBB-)VPLS", draft-ietf-bess-evpn-vpls-integration- Integration with (PBB-)VPLS", draft-ietf-bess-evpn-vpls-integration-
00.txt, work in progress, February, 2015 00.txt, work in progress, February, 2015
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Neil Hart for their valuable comments The authors would like to thank Neil Hart for their valuable comments
and feedback. and feedback.
skipping to change at page 22, line 34 skipping to change at page 22, line 32
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
co-authors have also contributed to this document: co-authors have also contributed to this document:
Florin Balus Florin Balus
John Drake John Drake
11. Authors' Addresses 11. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Alcatel-Lucent Nokia
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@nokia.com
Senthil Sathappan Senthil Sathappan
Alcatel-Lucent Nokia
Email: senthil.sathappan@alcatel-lucent.com Email: senthil.sathappan@nokia.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@nokia.com
Senad Palislamovic Senad Palislamovic
Alcatel-Lucent Nokia
Email: senad.palislamovic@alcatel-lucent.com Email: senad.palislamovic@nokia.com
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Ravi Shekhar Ravi Shekhar
Juniper Juniper
Email: rshekhar@juniper.net Email: rshekhar@juniper.net
Anil Lohiya Anil Lohiya
 End of changes. 31 change blocks. 
56 lines changed or deleted 54 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/