draft-ietf-bess-dci-evpn-overlay-07.txt   draft-ietf-bess-dci-evpn-overlay-08.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet Draft S. Sathappan Internet Draft S. Sathappan
Intended status: Standards Track W. Henderickx Intended status: Standards Track W. Henderickx
Nokia Nokia
A. Sajassi A. Sajassi
Cisco Cisco
J. Drake J. Drake
Juniper Juniper
Expires: August 2, 2018 January 29, 2018 Expires: August 12, 2018 February 8, 2018
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-07 draft-ietf-bess-dci-evpn-overlay-08
Abstract Abstract
This document describes how Network Virtualization Overlays (NVO) can This document describes how Network Virtualization Overlays (NVO) can
be connected to a Wide Area Network (WAN) in order to extend the be connected to a Wide Area Network (WAN) in order to extend the
layer-2 connectivity required for some tenants. The solution analyzes layer-2 connectivity required for some tenants. The solution analyzes
the interaction between NVO networks running Ethernet Virtual Private the interaction between NVO networks running Ethernet Virtual Private
Networks (EVPN) and other L2VPN technologies used in the WAN, such as Networks (EVPN) and other L2VPN technologies used in the WAN, such as
Virtual Private LAN Services (VPLS), VPLS extensions for Provider Virtual Private LAN Services (VPLS), VPLS extensions for Provider
Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 August 2, 2018. This Internet-Draft will expire on August 12, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Decoupled Interconnect solution for EVPN overlay networks . . . 5 3. Decoupled Interconnect solution for EVPN overlay networks . . . 6
3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 6 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 6
3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 7 3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 7
3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 7 3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 8
3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 8 3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 8
3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 8 3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 9
3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 8 3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 9
3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 9 3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 9
3.5.3. Handling failures between GW and WAN Edge routers . . . 9 3.5.3. Handling failures between GW and WAN Edge routers . . . 10
4. Integrated Interconnect solution for EVPN overlay networks . . 10 4. Integrated Interconnect solution for EVPN overlay networks . . 10
4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 10 4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 11
4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 11 4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 12
4.2.1. Control/Data Plane setup procedures on the GWs . . . . 11 4.2.1. Control/Data Plane setup procedures on the GWs . . . . 12
4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 12 4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 13
4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 12 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 13
4.3.1. Control/Data Plane setup procedures on the GWs . . . . 12 4.3.1. Control/Data Plane setup procedures on the GWs . . . . 13
4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 13 4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 14
4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 13 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 14
4.4.1. Control Plane setup procedures on the GWs . . . . . . . 13 4.4.1. Control Plane setup procedures on the GWs . . . . . . . 14
4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 15 4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 16
4.4.3. Multi-homing procedure extensions on the GWs . . . . . 16 4.4.3. Multi-homing procedure extensions on the GWs . . . . . 17
4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 18 4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 19
4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 18 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 19
4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 19 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 20
4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 20 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 21
4.5.1. Control/Data Plane setup procedures on the GWs . . . . 20 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 21
4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 20 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 21
4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 21 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 22
4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 21 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 22
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 21 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 22
4.6.1. Globally unique VNIs in the Interconnect network . . . 22 4.6.1. Globally unique VNIs in the Interconnect network . . . 23
4.6.2. Downstream assigned VNIs in the Interconnect network . 22 4.6.2. Downstream assigned VNIs in the Interconnect network . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 26
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
1. Conventions and Terminology 1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
AC: Attachment Circuit. AC: Attachment Circuit.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
CFM: Connectivity Fault Management. CFM: Connectivity Fault Management.
DC and DCI: Data Center and Data Center Interconnect. DC and DCI: Data Center and Data Center Interconnect.
DC RR(s) and WAN RR(s): it refers to the Data Center and Wide Area DC RR(s) and WAN RR(s): it refers to the Data Center and Wide Area
Network Route Reflectors, respectively. Network Route Reflectors, respectively.
DF and NDF: Designated Forwarder and Non-Designated Forwarder. DF and NDF: Designated Forwarder and Non-Designated Forwarder.
EVPN: Ethernet Virtual Private Network, as in [RFC7432].
EVI: EVPN Instance. EVI: EVPN Instance.
EVPN Tunnel binding: it refers to a tunnel to a remote PE/NVE for a
given EVI. Ethernet packets in these bindings are encapsulated with
the Overlay or MPLS encapsulation and the EVPN label at the bottom of
the stack.
ES: Ethernet Segment. ES: Ethernet Segment.
ESI: Ethernet Segment Identifier. ESI: Ethernet Segment Identifier.
GW: Gateway or Data Center Gateway. GW: Gateway or Data Center Gateway.
I-ESI: Interconnect ESI defined on the GWs for multi-homing to/from I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect
the WAN. Ethernet Segment Identifier. An I-ES is defined on the GWs for multi-
homing to/from the WAN.
MAC-VRF: it refers to an EVI instance in a particular node. MAC-VRF: it refers to an EVI instance in a particular node.
MP2P and LSM tunnels: it refers to Multi-Point to Point and Label MP2P and LSM tunnels: it refers to Multi-Point to Point and Label
Switched Multicast tunnels. Switched Multicast tunnels.
ND: Neighbor Discovery protocol. ND: Neighbor Discovery protocol.
NVE: Network Virtualization Edge. NVE: Network Virtualization Edge.
skipping to change at page 5, line 34 skipping to change at page 5, line 42
refers to the architectures described in this document as "DCI using refers to the architectures described in this document as "DCI using
GWs". GWs".
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 Interconnect solution" throughout the document, whereas the latter
one will be referred as "Integrated Interconnect solution". one will be referred as "Integrated Interconnect solution".
The specified procedures are local to the redundant GWs connecting a
DC to the WAN. The document does not preclude any combination across
different DCs for the same tenant. For instance, a "Decoupled"
solution can be used in GW1 and GW2 (for DC1) and an "Integrated"
solution can be used in GW3 and GW4 (for DC2).
While the Gateways and WAN PEs use existing Technical Specifications While the Gateways and WAN PEs use existing Technical Specifications
in some cases, the document also defines extensions to these in some cases, the document also defines extensions to these
Technical Specifications so that the requirements of the Technical Specifications so that the requirements of the
Interconnection can be met. In particular, the following EVPN Interconnection can be met. In particular, the following EVPN
extensions are described: extensions are described:
o The Interconnect Ethernet Segment (I-ES). o The Interconnect Ethernet Segment (I-ES).
o The use of the Unknown MAC route in a DCI scenario. o The use of the Unknown MAC route in a DCI scenario.
skipping to change at page 7, line 6 skipping to change at page 7, line 19
o Independence of the Layer Two VPN (L2VPN) technology deployed in o Independence of the Layer Two VPN (L2VPN) technology deployed in
the WAN. the WAN.
o Multi-homing between GW and WAN Edge routers, including per-service o Multi-homing between GW and WAN Edge routers, including per-service
load balancing. Per-flow load balancing is not a strong requirement load balancing. Per-flow load balancing is not a strong requirement
since a deterministic path per service is usually required for an since a deterministic path per service is usually required for an
easy QoS and security enforcement. easy QoS and security enforcement.
o Support of Ethernet OAM and Connectivity Fault Management (CFM) o Support of Ethernet OAM and Connectivity Fault Management (CFM)
[802.1AG][Y.1731] functions between the EVPN-Overlay network and [802.1AG][Y.1731] functions between the GW and the WAN Edge router
the WAN network. to detect individual AC failures.
o Support for the following optimizations at the GW: o Support for the following optimizations at the GW:
+ Flooding reduction of unknown unicast traffic sourced from the DC + Flooding reduction of unknown unicast traffic sourced from the DC
Network Virtualization Edge devices (NVEs). Network Virtualization Edge devices (NVEs).
+ Control of the WAN MAC addresses advertised to the DC. + Control of the WAN MAC addresses advertised to the DC.
+ Address Resolution Protocol (ARP) and Neighbor Discovery (ND) + Address Resolution Protocol (ARP) and Neighbor Discovery (ND)
flooding control for the requests coming from the WAN. flooding control for the requests coming from the WAN.
3.2. VLAN-based hand-off 3.2. VLAN-based hand-off
skipping to change at page 8, line 20 skipping to change at page 8, line 34
(WAN Edge), the corresponding VCID MUST be provisioned on the MAC- (WAN Edge), the corresponding VCID MUST be provisioned on the MAC-
VRF and match the VCID used in the peer VSI at the WAN Edge router. VRF and match the VCID used in the peer VSI at the WAN Edge router.
o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used
between the GW MAC-VRF and the WAN Edge VSI, the provisioning of between the GW MAC-VRF and the WAN Edge VSI, the provisioning of
the VPLS-ID MUST be supported on the MAC-VRF and MUST match the the VPLS-ID MUST be supported on the MAC-VRF and MUST match the
VPLS-ID used in the WAN Edge VSI. VPLS-ID used in the WAN Edge VSI.
3.4. Multi-homing solution on the GWs 3.4. Multi-homing solution on the GWs
Single-active multi-homing, i.e. per-service load-balancing multi- EVPN single-active multi-homing, i.e. per-service load-balancing
homing is required in this type of interconnect. multi-homing is required in this type of interconnect.
The GWs will be provisioned with a unique ESI per WAN interconnect The GWs will be provisioned with a unique ES 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 an ESI for such ES. 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 ES will be referred as "I-ES" hereafter,
hereafter. and its identifier will be referred as "I-ESI". [RFC7432] describes
different ESI Types. The use of Type 0 for the I-ESI is RECOMMENDED
in this document.
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 ES and per EVI will be advertised to the
the DC NVEs for the multi-homing functions, ES routes will be DC NVEs for the multi-homing functions, ES routes will be advertised
advertised so that ES discovery and Designated Forwarder (DF) so that ES discovery and Designated Forwarder (DF) procedures can be
procedures can be followed. The MAC addresses learned (in the data followed. The MAC addresses learned (in the data plane) on the hand-
plane) on the hand-off links will be advertised with the I-ESI off links will be advertised with the I-ESI encoded in the ESI field.
encoded in the ESI field.
3.5. Gateway Optimizations 3.5. Gateway Optimizations
The following GW features are optional and optimize the control plane The following GW features are optional and optimize the control plane
and data plane in the DC. and data plane in the DC.
3.5.1. MAC Address Advertisement Control 3.5.1. MAC Address Advertisement Control
The use of EVPN in NVO networks brings a significant number of The use of EVPN in NVO networks brings a significant number of
benefits as described in [EVPN-Overlays]. However, if multiple DCs benefits as described in [EVPN-Overlays]. However, if multiple DCs
skipping to change at page 9, line 18 skipping to change at page 9, line 33
which is advertised into a given DC by each of the DC's GWs. This which is advertised into a given DC by each of the DC's GWs. This
route is a regular EVPN MAC/IP Advertisement route in which the MAC route is a regular EVPN MAC/IP Advertisement route in which the MAC
Address Length is set to 48, the MAC address is set to Address Length is set to 48, the MAC address is set to
00:00:00:00:00:00, the IP length is set to 0, and the ESI field is 00:00:00:00:00:00, the IP length is set to 0, and the ESI field is
set to the DC GW's I-ESI. set to the DC GW's I-ESI.
An NVE within that DC that understands and process the Unknown MAC An NVE within that DC that understands and process the Unknown MAC
route will send unknown unicast frames to one of the DCs GWs, which route will send unknown unicast frames to one of the DCs GWs, which
will then forward that packet to the correct egress PE. Note that, will then forward that packet to the correct egress PE. Note that,
because the ESI is set to the DC GW's I-ESI, all-active multi-homing because the ESI is set to the DC GW's I-ESI, all-active multi-homing
can be applied to unknown unicast MAC addresses. can be applied to unknown unicast MAC addresses. An NVE that does not
understand the Unknown MAC route will handle unknown unicast as
described in [RFC7432].
This document proposes that local policy determines whether MAC This document proposes that local policy determines whether MAC
addresses and/or the Unknown MAC route are advertised into a given addresses and/or the Unknown MAC route are advertised into a given
DC. As an example, when all the DC MAC addresses are learned in the DC. As an example, when all the DC MAC addresses are learned in the
control/management plane, it may be appropriate to advertise only the control/management plane, it may be appropriate to advertise only the
Unknown MAC route. Advertising all the DC MAC addresses in the Unknown MAC route. Advertising all the DC MAC addresses in the
control/management plane is usually the case when the NVEs reside in control/management plane is usually the case when the NVEs reside in
hypervisors. Refer to [EVPN-Overlays] section 7. hypervisors. Refer to [EVPN-Overlays] section 7.
3.5.2. ARP/ND flooding control 3.5.2. ARP/ND flooding control
skipping to change at page 11, line 37 skipping to change at page 12, line 21
4.2.1. Control/Data Plane setup procedures on the GWs 4.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 PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay
tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that
different route-targets for the DC and for the WAN are normally different route-targets for the DC and for the WAN are normally
required. A single type-1 RD per service may be used. required. A 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 3.4), that will be unique per interconnection. All I-ESI (see section 3.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-ES, e.g. any
MAC address learned from the WAN will be advertised to the DC with MAC address learned from the WAN will be advertised to the DC with
the 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
skipping to change at page 12, line 30 skipping to change at page 13, line 14
The optimizations procedures described in section 3.5 can also be The optimizations procedures described in section 3.5 can also be
applied to this model. applied to this model.
4.2.2. Multi-homing procedures on the GWs 4.2.2. Multi-homing procedures on the GWs
This model supports single-active multi-homing on the GWs. All-active This model supports single-active multi-homing on the GWs. All-active
multi-homing is not supported by VPLS, therefore it cannot be used on multi-homing is not supported by VPLS, therefore it cannot be used on
the GWs. the GWs.
All the single-active multi-homing procedures as described by [EVPN- In this case, for a given EVI, all the PWs in the WAN split-horizon-
Overlays] will be followed for the I-ESI. group are assigned to I-ES. All the single-active multi-homing
procedures as described by [EVPN-Overlays] will be followed for the
I-ES.
The non-DF GW for the I-ESI will block the transmission and reception The non-DF GW for the I-ES will block the transmission and reception
of all the bindings in the "WAN split-horizon-group" for BUM and of all the PWs in the "WAN split-horizon-group" for BUM and unicast
unicast traffic. traffic.
4.3. PBB-VPLS Interconnect for EVPN-Overlay networks 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks
4.3.1. Control/Data Plane setup procedures on the GWs 4.3.1. Control/Data Plane setup procedures on the GWs
In this case, there is no impact on the procedures described in In this case, there is no impact on the procedures described in
[RFC7041] for the B-component. However the I-component instances [RFC7041] for the B-component. However the I-component instances
become EVI instances with EVPN-Overlay bindings and potentially local become EVI instances with EVPN-Overlay bindings and potentially local
attachment circuits. A number of MAC-VRF instances can be multiplexed attachment circuits. A number of MAC-VRF instances can be multiplexed
into the same B-component instance. This option provides significant into the same B-component instance. This option provides significant
skipping to change at page 13, line 29 skipping to change at page 14, line 15
the B-component is brought up. the B-component is brought up.
The optimizations procedures described in section 3.5 can also be The optimizations procedures described in section 3.5 can also be
applied to this Interconnect option. applied to this Interconnect option.
4.3.2. Multi-homing procedures on the GWs 4.3.2. Multi-homing procedures on the GWs
This model supports single-active multi-homing on the GWs. All-active This model supports single-active multi-homing on the GWs. All-active
multi-homing is not supported by this scenario. multi-homing is not supported by this scenario.
All the single-active multi-homing procedures as described by [EVPN- 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-ES for each EVI instance
connected to B-component. connected to the B-component. Note that in this case, for a given
EVI, all the EVPN bindings in the I-component are assigned to the I-
ES. The non-DF GW for the I-ES will block the transmission and
reception of all the I-component EVPN bindings for BUM and unicast
traffic. When learning MACs from the WAN, the non-DF MUST NOT
advertise EVPN MAC/IP routes for those MACs.
4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks 4.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 [RFC7432] procedures. required on the [RFC7432] procedures.
4.4.1. Control Plane setup procedures on the GWs 4.4.1. Control Plane setup procedures on the GWs
skipping to change at page 14, line 9 skipping to change at page 14, line 48
In order to facilitate separate BGP processes for DC and WAN, EVPN In order to facilitate separate BGP processes for DC and WAN, EVPN
routes sent to the WAN SHOULD carry a different route-distinguisher routes sent to the WAN SHOULD carry a different route-distinguisher
(RD) than the EVPN routes sent to the DC. In addition, although (RD) than the EVPN routes sent to the DC. In addition, although
reusing the same value is possible, different route-targets are reusing the same value is possible, different route-targets are
expected to be handled for the same EVI in the WAN and the DC. Note expected to be handled for the same EVI in the WAN and the DC. Note
that the EVPN service routes sent to the DC RRs will normally include that the EVPN service routes sent to the DC RRs will normally include
a [TUNNEL-ENCAP] BGP encapsulation extended community with a a [TUNNEL-ENCAP] BGP encapsulation extended community with a
different tunnel type than the one sent to the WAN RRs. 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-ES and its assigned I-ESI
GWs for multi-homing. This I-ESI represents the WAN to the DC but will be configured on the GWs for multi-homing. This I-ES represents
also the DC to the WAN. Optionally, different I-ESI values are the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to
configured for representing the WAN and the DC. If different EVPN- the WAN. Optionally, different I-ESI values are configured for
Overlay networks are connected to the same group of GWs, each EVPN- representing the WAN and the DC. If different EVPN-Overlay networks
Overlay network MUST get assigned a different I-ESI. are connected to the same group of GWs, each EVPN-Overlay network
MUST get assigned a different I-ESI.
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 [RFC7432] 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, the information will be re- they become active in the MAC-VRF, the information will be re-
skipping to change at page 14, line 37 skipping to change at page 15, line 30
+ 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 value will be kept from the received NLRI. + 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 NLRI. will be kept from the received NLRI.
+ The MPLS label will be a local 20-bit value (when sent to the + The MPLS label will be a local 20-bit value (when sent to the
WAN) or a DC-global 24-bit value (when sent to the DC). WAN) or a DC-global 24-bit value (when sent to the DC for
encapsulations using a VNI).
+ The appropriate Route-Targets (RTs) and [TUNNEL-ENCAP] BGP + The appropriate Route-Targets (RTs) and [TUNNEL-ENCAP] 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 [TUNNEL- be sent to the DC and WAN, with their corresponding RTs and [TUNNEL-
ENCAP] BGP Encapsulation extended community values: ENCAP] BGP Encapsulation extended community values:
o ES route(s) for the I-ESI(s). o ES route(s) for the I-ESI(s).
o Ethernet A-D routes per ESI and EVI for the I-ESI(s). The A-D o Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D
per-EVI routes sent to the WAN and the DC will have consistent per-EVI routes sent to the WAN and the DC will have consistent
Ethernet-Tag values. 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 may be used in the DC. The routes whereas ingress replication may be used in the DC. The routes
sent to the WAN and the DC will have a consistent Ethernet-Tag. sent to the WAN and the DC will have a consistent Ethernet-Tag.
o MAC/IP advertisement routes for MAC addresses learned 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 multi-homed I-ESI, but ESI=0 or different from 0 for local multi-homed
Ethernet Segments (ES). The routes sent to the WAN and the DC Ethernet Segments (ES). The routes sent to the WAN and the DC
will have a consistent Ethernet-Tag. will have a consistent Ethernet-Tag.
Assuming GW1 and GW2 are peer GWs of the same DC, each GW will Assuming GW1 and GW2 are peer GWs of the same DC, each GW will
generate two sets of local service routes: Set-DC will be sent to the generate two sets of the above local service routes: Set-DC will be
DC RRs and will include A-D per EVI, Inclusive Multicast and MAC/IP sent to the DC RRs and will include A-D per EVI, Inclusive Multicast
routes for the DC encapsulation and RT. Set-WAN will be sent to the and MAC/IP routes for the DC encapsulation and RT. Set-WAN will be
WAN RRs and will include the same routes but using the WAN RT and sent to the WAN RRs and will include the same routes but using the
encapsulation. GW1 and GW2 will receive each other's set-DC and set- WAN RT and encapsulation. GW1 and GW2 will receive each other's set-
WAN. This is the expected behavior on GW1 and GW2 for locally DC and set-WAN. This is the expected behavior on GW1 and GW2 for
generated routes: locally generated routes:
o Inclusive multicast routes: when setting up the flooding lists o Inclusive multicast routes: when setting up the flooding lists
for a given MAC-VRF, each GW will include its DC peer GW only in for a given MAC-VRF, each GW will include its DC peer GW only in
the EVPN-MPLS flooding list (by default) and not the EVPN- the EVPN-MPLS flooding list (by default) and not the EVPN-
Overlay flooding list. That is, GW2 will import two Inclusive Overlay flooding list. That is, GW2 will import two Inclusive
Multicast routes from GW1 (from set-DC and set-WAN) but will Multicast routes from GW1 (from set-DC and set-WAN) but will
only consider one of the two, having the set-WAN route higher only consider one of the two, having the set-WAN route higher
priority. An administrative option MAY change this preference so priority. An administrative option MAY change this preference so
that the set-DC route is selected first. that the set-DC route is selected first.
skipping to change at page 16, line 29 skipping to change at page 17, line 23
including an ESI label at the bottom of the stack, they will perform including an ESI label at the bottom of the stack, they will perform
an ESI label lookup and split-horizon filtering as per [RFC7432] in an ESI label lookup and split-horizon filtering as per [RFC7432] in
case the ESI label identifies a local ESI (I-ESI or any other non- case the ESI label identifies a local ESI (I-ESI or any other non-
zero ESI). zero ESI).
4.4.3. Multi-homing procedure extensions on the GWs 4.4.3. Multi-homing procedure extensions on the GWs
This model supports single-active as well as all-active multi-homing. This model supports single-active as well as all-active multi-homing.
All the [RFC7432] multi-homing procedures for the DF election on I- All the [RFC7432] multi-homing procedures for the DF election on I-
ESI(s) as well as the backup-path (single-active) and aliasing (all- ES(s) as well as the backup-path (single-active) and aliasing (all-
active) procedures will be followed on the GWs. Remote PEs in the active) procedures will be followed on the GWs. Remote PEs in the
EVPN-MPLS network will follow regular [RFC7432] aliasing or backup- EVPN-MPLS network will follow regular [RFC7432] aliasing or backup-
path procedures for MAC/IP routes received from the GWs for the same path procedures for MAC/IP routes received from the GWs for the same
I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes
received with the same I-ESI. received with the same I-ESI.
As far as the forwarding plane is concerned, by default, the EVPN- As far as the forwarding plane is concerned, by default, the EVPN-
Overlay network will have an analogous behavior to the access ACs in Overlay network will have an analogous behavior to the access ACs in
[RFC7432] multi-homed Ethernet Segments. [RFC7432] multi-homed Ethernet Segments.
The forwarding behavior on the GWs is described below: The forwarding behavior on the GWs is described below:
o Single-active multi-homing; assuming a WAN split-horizon-group o Single-active multi-homing; assuming a WAN split-horizon-group
(comprised of EVPN-MPLS bindings), a DC split-horizon-group (comprised of EVPN-MPLS bindings), a DC split-horizon-group
(comprised of EVPN-Overlay bindings) and local ACs on the GWs: (comprised of EVPN-Overlay bindings) and local ACs on the GWs:
+ Forwarding behavior on the non-DF: the non-DF MUST block + Forwarding behavior on the non-DF: the non-DF MUST block
ingress and egress forwarding on the EVPN-Overlay bindings ingress and egress forwarding on the EVPN-Overlay bindings
associated to the I-ESI. The EVPN-MPLS network is considered associated to the I-ES. The EVPN-MPLS network is considered to
to be the core network and the EVPN-MPLS bindings to the be the core network and the EVPN-MPLS bindings to the remote
remote PEs and GWs will be active. PEs and GWs will be active.
+ 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. Forwarding to other member of his own split-horizon group. Forwarding to other
split-horizon-groups and local ACs is allowed (as long as the split-horizon-groups and local ACs is allowed (as long as the
ACs are not part of an ES for which the node is non-DF). As ACs are not part of an ES for which the node is non-DF). As
per [RFC7432] and for split-horizon purposes, when receiving per [RFC7432] and for split-horizon purposes, when receiving
BUM traffic on the EVPN-Overlay bindings associated to an I- BUM traffic on the EVPN-Overlay bindings associated to an I-
ESI, the DF GW SHOULD add the I-ESI label when forwarding to ES, the DF GW SHOULD add the I-ESI label when forwarding to
the peer GW over EVPN-MPLS. the peer GW over EVPN-MPLS.
+ When receiving EVPN MAC/IP routes from the WAN, the non-DF + When receiving EVPN MAC/IP routes from the WAN, the non-DF
MUST NOT re-originate the EVPN routes and advertise them to MUST NOT re-originate the EVPN routes and advertise them to
the DC peers. In the same way, EVPN MAC/IP routes received the DC peers. In the same way, EVPN MAC/IP routes received
from the DC MUST NOT be advertised to the WAN peers. This is from the DC MUST NOT be advertised to the WAN peers. This is
consistent with [RFC7432] and allows the remote PE/NVEs know consistent with [RFC7432] and allows the remote PE/NVEs know
who the primary GW is, based on the reception of the MAC/IP who the primary GW is, based on the reception of the MAC/IP
routes. routes.
skipping to change at page 17, line 45 skipping to change at page 18, line 38
+ Forwarding behavior on the DF: the DF follows the same + Forwarding behavior on the DF: the DF follows the same
behavior as the DF in the single-active case but only for BUM behavior as the DF in the single-active case but only for BUM
traffic. Unicast traffic received from a split-horizon-group traffic. Unicast traffic received from a split-horizon-group
MUST NOT be forwarded to a member of its own split-horizon- MUST NOT be forwarded to a member of its own split-horizon-
group but can be forwarded normally to the other split- group but can be forwarded normally to the other split-
horizon-group and local ACs. If a known unicast packet is horizon-group and local ACs. If a known unicast packet is
identified as a "flooded" packet, the procedures for BUM identified as a "flooded" packet, the procedures for BUM
traffic MUST be followed. As per [RFC7432] and for split- traffic MUST be followed. As per [RFC7432] and for split-
horizon purposes, when receiving BUM traffic on the EVPN- horizon purposes, when receiving BUM traffic on the EVPN-
Overlay bindings associated to an I-ESI, the DF GW MUST add Overlay bindings associated to an I-ES, the DF GW MUST add the
the I-ESI label when forwarding to the peer GW over EVPN-MPLS. I-ESI label when forwarding to the peer GW over EVPN-MPLS.
+ Contrary to the single-active multi-homing case, both DF and + Contrary to the single-active multi-homing case, both DF and
non-DF re-originate and advertise MAC/IP routes received from non-DF re-originate and advertise MAC/IP routes received from
the WAN/DC peers, adding the corresponding I-ESI so that the the WAN/DC peers, adding the corresponding I-ESI so that the
remote PE/NVEs can perform regular aliasing as per [RFC7432]. remote PE/NVEs can perform regular aliasing as per [RFC7432].
The example in Figure 3 illustrates the forwarding of BUM traffic The example in Figure 3 illustrates the forwarding of BUM traffic
originated from an NVE on a pair of all-active multi-homing GWs. originated from an NVE on a pair of all-active multi-homing GWs.
|<--EVPN-Overlay--->|<--EVPN-MPLS-->| |<--EVPN-Overlay--->|<--EVPN-MPLS-->|
skipping to change at page 18, line 28 skipping to change at page 19, line 25
+----+ | |GW2<-+ | +----+ | |GW2<-+ |
|NVE2+--+ +-+-+ | |NVE2+--+ +-+-+ |
+----+ +--------+ | +------------+ +----+ +--------+ | +------------+
v v
+--+ +--+
|CE| |CE|
+--+ +--+
Figure 3 Multi-homing BUM forwarding Figure 3 Multi-homing BUM forwarding
GW2 is the non-DF for the I-ESI and blocks the BUM forwarding. GW1 is GW2 is the non-DF for the I-ES and blocks the BUM forwarding. GW1 is
the DF and forwards the traffic to PE1 and GW2. GW2 will only forward the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2
the packets to local ACs (CE in the example). will include the ESI-label for the I-ES. Based on the ESI-label, GW2
identifies the packets as I-ES-generated packets and will only
forward them to local ACs (CE in the example) and not back to the
EVPN-Overlay network.
4.4.4. Impact on MAC Mobility procedures 4.4.4. Impact on MAC Mobility procedures
MAC Mobility procedures described in [RFC7432] are not modified by MAC Mobility procedures described in [RFC7432] are not modified by
this document. this document.
Note that an intra-DC MAC move still leaves the MAC attached to the Note that an intra-DC MAC move still leaves the MAC attached to the
same I-ESI, so under the rules of [RFC7432] this is not considered a same I-ES, so under the rules of [RFC7432] this is not considered a
MAC mobility event. Only when the MAC moves from the WAN domain to 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 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. from a different ES and the MAC Mobility procedures will kick in.
The sticky bit indication in the MAC Mobility extended community MUST The sticky bit indication in the MAC Mobility extended community MUST
be propagated between domains. be propagated between domains.
4.4.5. Gateway optimizations 4.4.5. Gateway optimizations
All the Gateway optimizations described in section 3.5 MAY be applied All the Gateway optimizations described in section 3.5 MAY be applied
skipping to change at page 19, line 21 skipping to change at page 20, line 21
b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN
with I-ESI-2 in the ESI field. with I-ESI-2 in the ESI field.
c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following
the EVPN aliasing procedures. the EVPN aliasing procedures.
d) Before NVE1 learns M1, a packet arrives at NVE1 with d) Before NVE1 learns M1, a packet arrives at NVE1 with
destination M1. If the Unknown MAC route had not been destination M1. If the Unknown MAC route had not been
advertised into the DC, NVE1 would have flooded the packet advertised into the DC, NVE1 would have flooded the packet
throughout the DC, in particular to both GW1 and GW2. If the throughout the DC, in particular to both GW1 and GW2. If the
same VNI/VSID is used for both known unicast and BUM traffic, same VNI/VSID is used for both known unicast and BUM traffic,
as is typically the case, there is no indication in the packet as is typically the case, there is no indication in the packet
that it is a BUM packet and both GW1 and GW2 would have that it is a BUM packet and both GW1 and GW2 would have
forwarded it. However, because the Unknown MAC route had been forwarded it, creating packet duplication. However, because the
advertised into the DC, NVE1 will unicast the packet to either Unknown MAC route had been advertised into the DC, NVE1 will
GW1 or GW2. unicast the packet to either GW1 or GW2.
e) Since both GW1 and GW2 know M1, the GW receiving the packet e) Since both GW1 and GW2 know M1, the GW receiving the packet
will forward it to either GW3 or GW4. will forward it to either GW3 or GW4.
4.4.6. Benefits of the EVPN-MPLS Interconnect solution 4.4.6. Benefits of the EVPN-MPLS Interconnect solution
Besides retaining the EVPN attributes between Data Centers and Besides retaining the EVPN attributes between Data Centers and
throughout the WAN, the EVPN-MPLS Interconnect solution on the GWs throughout the WAN, the EVPN-MPLS Interconnect solution on the GWs
has some benefits compared to pure BGP EVPN RR or Inter-AS model B has some benefits compared to pure BGP EVPN RR or Inter-AS model B
solutions without a gateway: solutions without a gateway:
skipping to change at page 20, line 32 skipping to change at page 21, line 33
4.5.1. Control/Data Plane setup procedures on the GWs 4.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 [RFC7623], the DC C-MACs are VRF and B-component MAC-VRF. Compared to [RFC7623], the DC C-MACs are
no longer learned in the data plane on the GW but in the control 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 learned 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 [RFC7623]. described in [RFC7623].
An I-ESI will be configured on the GWs for multi-homing, but it will An I-ES will be configured on the GWs for multi-homing, but its I-ESI
only be used in the EVPN control plane for the I-component EVI. No will only be used in the EVPN control plane for the I-component EVI.
non-reserved ESIs will be used in the control plane of the B- No non-reserved ESIs will be used in the control plane of the B-
component EVI as per [RFC7623]. component EVI as per [RFC7623], that is, the I-ES will be represented
to the WAN PBB-EVPN PEs using shared or dedicated B-MACs.
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 [RFC7623] for the B-component EVI. the I-component EVI and [RFC7623] 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 4.3.1. described in section 4.3.1.
4.5.2. Multi-homing procedures on the GWs 4.5.2. Multi-homing procedures on the GWs
This model supports single-active as well as all-active multi-homing. This model supports single-active as well as all-active multi-homing.
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 4.4.3, only replacing the "WAN the description outlined in section 4.4.3, only replacing the "WAN
split-horizon-group" for the B-component. split-horizon-group" for the B-component, and using [RFC7623]
procedures for the traffic sent or received on the B-component.
4.5.3. Impact on MAC Mobility procedures 4.5.3. Impact on MAC Mobility procedures
C-MACs learned 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 learned the related procedures described in [RFC7432], the C-MACs learned
from the B-component are considered local. from the B-component are considered local.
skipping to change at page 21, line 26 skipping to change at page 22, line 31
All the considerations explained in section 4.4.5 are applicable to All the considerations explained in section 4.4.5 are applicable to
the PBB-EVPN Interconnect option. the PBB-EVPN Interconnect option.
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks 4.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 [RFC7432] procedures. hereafter) and the impact on the [RFC7432] procedures.
The procedures described in section 4.4 apply to this section too,
only replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and
using [EVPN-Overlays] "Local Bias" procedures instead of section
4.4.3. Since there are no ESI-labels in VXLAN, GWs need to rely on
"Local Bias" to apply split-horizon on packets generated from the I-
ES and sent to the peer GW.
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
possibilities in the Interconnect network: possibilities in the Interconnect network:
 End of changes. 38 change blocks. 
99 lines changed or deleted 137 lines changed or added

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