draft-ietf-bess-dci-evpn-overlay-05.txt   draft-ietf-bess-dci-evpn-overlay-06.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: January 19, 2018 July 18, 2017 Expires: July 26, 2018 January 22, 2018
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-05 draft-ietf-bess-dci-evpn-overlay-06
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 EVPN and other L2VPN the interaction between NVO networks running Ethernet Virtual Private
technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN, Networks (EVPN) and other L2VPN technologies used in the WAN, such as
and proposes a solution for the interworking between both. Virtual Private LAN Services (VPLS), VPLS extensions for Provider
Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how
the existing Technical Specifications apply to the Interconnection
and extends the EVPN procedures needed in some cases. In particular,
this document describes how EVPN routes are processed on Gateways
(GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well
as the Interconnect Ethernet Segment (I-ES) to provide multi-homing,
and the use of the Unknown MAC route to avoid MAC scale issues on
Data Center Network Virtualization Edge (NVE) devices.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 6 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 January 19, 2018. This Internet-Draft will expire on July 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
2. Decoupled Interconnect solution for EVPN overlay networks . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Interconnect requirements . . . . . . . . . . . . . . . . . 4 3. Decoupled Interconnect solution for EVPN overlay networks . . . 5
2.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 5 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 6
2.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 5 3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 7
2.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 6 3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 7
2.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 6 3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 8
2.5.1. MAC Address Advertisement Control . . . . . . . . . . . 6 3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 8
2.5.2. ARP flooding control . . . . . . . . . . . . . . . . . 7 3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 8
2.5.3. Handling failures between GW and WAN Edge routers . . . 7 3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 9
3. Integrated Interconnect solution for EVPN overlay networks . . 8 3.5.3. Handling failures between GW and WAN Edge routers . . . 9
3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 8 4. Integrated Interconnect solution for EVPN overlay networks . . 10
3.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 9 4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 10
3.2.1. Control/Data Plane setup procedures on the GWs . . . . 9 4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 11
3.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 10 4.2.1. Control/Data Plane setup procedures on the GWs . . . . 11
3.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 10 4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 12
3.3.1. Control/Data Plane setup procedures on the GWs . . . . 10 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 12
3.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 11 4.3.1. Control/Data Plane setup procedures on the GWs . . . . 12
3.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 11 4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 13
3.4.1. Control Plane setup procedures on the GWs . . . . . . . 11 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 13
3.4.2. Data Plane setup procedures on the GWs . . . . . . . . 13 4.4.1. Control Plane setup procedures on the GWs . . . . . . . 13
3.4.3. Multi-homing procedure extensions on the GWs . . . . . 14 4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 15
3.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 16 4.4.3. Multi-homing procedure extensions on the GWs . . . . . 16
3.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 16 4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 18
3.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 17 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 18
3.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 18 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 19
3.5.1. Control/Data Plane setup procedures on the GWs . . . . 18 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 20
3.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 18 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 20
3.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 18 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 20
3.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 19 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 21
3.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 19 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 21
3.6.1. Globally unique VNIs in the Interconnect network . . . 20 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 21
3.6.2. Downstream assigned VNIs in the Interconnect network . 20 4.6.1. Globally unique VNIs in the Interconnect network . . . 22
5. Conventions and Terminology . . . . . . . . . . . . . . . . . . 20 4.6.2. Downstream assigned VNIs in the Interconnect network . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Conventions and Terminology
[EVPN-Overlays] discusses the use of EVPN as the control plane for The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Network Virtualization Overlays (NVO), where VXLAN, NVGRE or MPLS "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
over GRE can be used as possible data plane encapsulation options. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
AC: Attachment Circuit.
ARP: Address Resolution Protocol.
BUM: it refers to the Broadcast, Unknown unicast and Multicast
traffic.
CFM: Connectivity Fault Management.
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
Network Route Reflectors, respectively.
DF and NDF: Designated Forwarder and Non-Designated Forwarder.
EVI: EVPN Instance.
ES: Ethernet Segment.
ESI: Ethernet Segment Identifier.
GW: Gateway or Data Center Gateway.
I-ESI: Interconnect ESI defined on the GWs for multi-homing to/from
the WAN.
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
Switched Multicast tunnels.
ND: Neighbor Discovery protocol.
NVE: Network Virtualization Edge.
NVGRE: Network Virtualization using Generic Routing Encapsulation.
NVO: refers to Network Virtualization Overlays.
OAM: Operations and Maintenance.
PBB: Provider Backbone Bridging.
PW: Pseudowire.
RD: Route-Distinguisher.
RT: Route-Target.
S/C-TAG: It refers to a combination of Service Tag and Customer Tag
in a 802.1Q frame.
TOR: Top-Of-Rack switch.
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers.
VPLS: Virtual Private LAN Service.
VSI: Virtual Switch Instance or VPLS instance in a particular PE.
VXLAN: Virtual eXtensible LAN.
2. Introduction
[EVPN-Overlays] discusses the use of Ethernet Virtual Private
Networks (EVPN) [RFC7432] as the control plane for Network
Virtualization Overlays (NVO), where VXLAN [RFC7348], NVGRE [RFC7637]
or MPLS over GRE [RFC4023] can be used as possible data plane
encapsulation 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
the WAN in some cases due to the requirements and existing deployed the Wide Area Network (WAN) in some cases due to the requirements and
technologies. For instance, a Service Provider might have an already existing deployed technologies. For instance, a Service Provider
deployed (PBB-)VPLS or (PBB-)EVPN network that has to be used to might have an already deployed Virtual Private LAN Service (VPLS)
interconnect Data Centers and WAN VPN users. A Gateway (GW) function [RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging
is required in these cases. (PBB-VPLS) [RFC7041], EVPN [RFC7432] or PBB-EVPN [RFC7623] network
that has to be used to interconnect Data Centers and WAN VPN users. A
Gateway (GW) function is required in these cases. [EVPN-Overlays]
refers to the architectures described in this document as "DCI using
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".
2. Decoupled Interconnect solution for EVPN overlay networks While the Gateways and WAN PEs use existing Technical Specifications
in some cases, the document also defines extensions to these
Technical Specifications so that the requirements of the
Interconnection can be met. In particular, the following EVPN
extensions are described:
o The Interconnect Ethernet Segment (I-ES).
o The use of the Unknown MAC route in a DCI scenario.
o The processing of EVPN routes on Gateways with MAC-VRFs connecting
EVPN-Overlay to EVPN-MPLS networks.
3. 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 4, line 32 skipping to change at page 6, line 33
+--------------+ +--------------+
|<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->|
hand-off hand-off hand-off hand-off
Figure 1 Decoupled Interconnect model Figure 1 Decoupled Interconnect model
The following section describes the interconnect requirements for The following section describes the interconnect requirements for
this model. this model.
2.1. Interconnect requirements 3.1. Interconnect requirements
This proposed Interconnect architecture will be normally deployed in The Decoupled Interconnect architecture is intended to be deployed in
networks where the EVPN-Overlay and WAN providers are different networks where the EVPN-Overlay and WAN providers are different
entities and a clear demarcation is needed. The solution needs to entities and a clear demarcation is needed. This solution solves the
observe the following requirements: following requirements:
o A simple connectivity hand-off needs to be provided between the o A simple connectivity hand-off between the EVPN-Overlay network
EVPN-Overlay network provider and the WAN provider so that QoS and provider and the WAN provider so that QoS and security enforcement
security enforcements are easily accomplished. is easily accomplished.
o The solution has to be independent of the L2VPN technology deployed o Independence of the Layer Two VPN (L2VPN) technology deployed in
in the WAN. the WAN.
o Multi-homing between GW and WAN Edge routers is required. Per- o Multi-homing between GW and WAN Edge routers, including per-service
service load balancing MUST be supported. Per-flow load balancing load balancing. Per-flow load balancing is not a strong requirement
MAY be supported but it is not a strong requirement since a since a deterministic path per service is usually required for an
deterministic path per service is usually required for an easy QoS easy QoS and security enforcement.
and security enforcement.
o Ethernet OAM and Connectivity Fault Management (CFM) functions o Support of Ethernet OAM and Connectivity Fault Management (CFM)
needs to be supported between the EVPN-Overlay network and the WAN [802.1AG][Y.1731] functions between the EVPN-Overlay network and
network. the WAN network.
o The following optimizations MAY be supported 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.
+ ARP flooding control for the requests coming from the WAN. + Address Resolution Protocol (ARP) and Neighbor Discovery (ND)
flooding control for the requests coming from the WAN.
2.2. VLAN-based hand-off 3.2. VLAN-based hand-off
In this option, the hand-off between the GWs and the WAN Edge routers In this option, the hand-off between the GWs and the WAN Edge routers
is based on 802.1Q VLANs. This is illustrated in Figure 1 (between is based on VLANs [802.1Q-2014]. This is illustrated in Figure 1
the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in the GW is (between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in
connected to a different VSI/MAC-VRF instance in the WAN Edge router the GW is connected to a different VSI/MAC-VRF instance in the WAN
by using a different C-TAG VLAN ID or a different combination of Edge router by using a different C-TAG VLAN ID or a different
S/C-TAG VLAN IDs that matches at both sides. combination of S/C-TAG VLAN IDs that matches at both sides.
This option provides the best possible demarcation between the DC and This option provides the best possible demarcation between the DC and
WAN providers and it does not require control plane interaction WAN providers and it does not require control plane interaction
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 has to be mapped to a C-TAG provisioning overhead since the service has to be mapped to a C-TAG
or S/C-TAG VLAN ID combination at both GW and WAN Edge routers. or S/C-TAG 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 [RFC7432], [RFC7623]. [RFC4761], [RFC4762], [RFC6074] or [RFC7432], [RFC7623].
2.3. PW-based (Pseudowire-based) hand-off 3.3. PW-based (Pseudowire-based) hand-off
If MPLS can be enabled between the GW and the WAN Edge router, a PW- If MPLS between the GW and the WAN Edge router is an option, 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 [RFC4762]
based PWs (for a greater level of network automation). Note that this or FEC129-based PWs (for a greater level of network automation)
model still provides a clear demarcation boundary between DC and WAN [RFC6074]. Note that this model still provides a clear demarcation
(since there is a single PW between each MAC-VRF and peer VSI), and boundary between DC and WAN (since there is a single PW between each
security/QoS policies may be applied on a per PW basis. This model MAC-VRF and peer VSI), and security/QoS policies may be applied on a
provides better scalability than a C-TAG based hand-off and less per PW basis. This model provides better scalability than a C-TAG
provisioning overhead than a combined C/S-TAG hand-off. The PW-based based hand-off and less provisioning overhead than a combined C/S-TAG
hand-off interconnect is illustrated in Figure 1 (between the NVO-2 hand-off. The PW-based hand-off interconnect is illustrated in Figure
GWs and the WAN Edge routers). 1 (between the NVO-2 GWs and the WAN Edge routers).
In this model, besides the usual MPLS procedures between GW and WAN In this model, besides the usual MPLS procedures between GW and WAN
Edge router, the GW MUST support an interworking function in each Edge router [RFC3031], the GW MUST support an interworking function
MAC-VRF that requires extension to the WAN: in each MAC-VRF that requires extension to the WAN:
o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI
(WAN Edge), the provisioning of the VCID for such PW MUST be (WAN Edge), the corresponding VCID MUST be provisioned on the MAC-
supported on the MAC-VRF and MUST match the VCID used in the peer VRF and match the VCID used in the peer VSI at the WAN Edge router.
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.
2.4. Multi-homing solution on the GWs 3.4. Multi-homing solution on the GWs
As already discussed, single-active multi-homing, i.e. per-service Single-active multi-homing, i.e. per-service load-balancing multi-
load-balancing multi-homing MUST be supported in this type of homing is required in this type of interconnect.
interconnect.
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 learned (in the data plane) on the the DC NVEs for the multi-homing functions, ES routes will be
hand-off links will be advertised with the I-ESI encoded in the ESI advertised so that ES discovery and Designated Forwarder (DF)
field. procedures can be followed. The MAC addresses learned (in the data
plane) on the hand-off links will be advertised with the I-ESI
encoded in the ESI field.
2.5. Gateway Optimizations 3.5. Gateway Optimizations
The following features MAY be supported on the GW in order to The following GW features are optional and optimize the control plane
optimize the control plane and data plane in the DC. and data plane in the DC.
2.5.1. MAC Address Advertisement Control 3.5.1. MAC Address Advertisement Control
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]. However, if multiple DCs benefits as described in [EVPN-Overlays]. However, if multiple DCs
are interconnected into a single EVI, each DC will have to import all are interconnected into a single EVI, each DC will have to import all
of the MAC addresses from each of the other DCs. of the MAC addresses from each of the other DCs.
Even if optimized BGP techniques like RT-constraint are used, the Even if optimized BGP techniques like RT-constraint [RFC4684] are
number of MAC addresses to advertise or withdraw (in case of failure) used, the number of MAC addresses to advertise or withdraw (in case
by the GWs of a given DC could overwhelm the NVEs within that DC, of failure) by the GWs of a given DC could overwhelm the NVEs within
particularly when the NVEs reside in the hypervisors. that DC, particularly when the NVEs reside in the hypervisors.
The solution specified in this document uses the 'Unknown MAC' route The solution specified in this document uses the 'Unknown MAC' route
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 the Unknown MAC route will An NVE within that DC that understands and process the Unknown MAC
send (unicast) a packet with an unknown unicast MAC address to one of route will send unknown unicast frames to one of the DCs GWs, which
the DCs GWs which will then forward that packet to the correct egress will then forward that packet to the correct egress PE. Note that,
PE. I.e., because the ESI is set to the DC GW's I-ESI, all-active because the ESI is set to the DC GW's I-ESI, all-active multi-homing
multi-homing can be applied to unknown unicast MAC addresses. can be applied to unknown unicast MAC addresses.
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. Unknown MAC route.
2.5.2. ARP flooding control 3.5.2. ARP/ND 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.
This mechanism is especially recommended on the GWs since it protects This mechanism is especially recommended on the GWs, since it
the DC network from external ARP/ND-flooding storms. protects the DC network from external ARP/ND-flooding storms.
2.5.3. Handling failures between GW and WAN Edge routers 3.5.3. Handling failures between GW and WAN Edge routers
Link/PE failures are handled on the GWs as specified in [RFC7432]. Link/PE failures are handled on the GWs as specified in [RFC7432].
The GW detecting the failure will withdraw the EVPN routes as per The GW detecting the failure will withdraw the EVPN routes as per
[RFC7432]. [RFC7432].
Individual AC/PW failures MAY be detected by OAM mechanisms. For Individual AC/PW failures may 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, Ethernet-
802.1ag/Y.1731 Ethernet-CFM MAY be used to detect individual AC CFM [802.1AG][Y.1731] may be used to detect individual AC failures
failures on both, the GW and WAN Edge router. An individual AC on both, the GW and WAN Edge router. An individual AC failure will
failure will trigger the withdrawal of the corresponding A-D per trigger the withdrawal of the corresponding A-D per EVI route as
EVI route as well as the MACs learned on that AC. 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 Label
Status bits TLV MAY be used to detect individual PW failures on Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be
both, the GW and WAN Edge router. used to detect individual PW failures on both, the GW and WAN Edge
router.
3. Integrated Interconnect solution for EVPN overlay networks 4. 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
saving reasons. This is illustrated in Figure 2. Note that this model saving reasons. This is illustrated in Figure 2. Note that this model
does not provide an explicit demarcation link between DC and WAN does not provide an explicit demarcation link between DC and WAN
anymore. anymore.
+--+ +--+
|CE| |CE|
skipping to change at page 8, line 37 skipping to change at page 10, line 41
| +---+ +---+ | | +---+ +---+ |
| | | | | | | | | | | |
+----+ | |GW2| |GW4| | +----+ +----+ | |GW2| |GW4| | +----+
|NVE2|--| +---+ +---+ |--|NVE4| |NVE2|--| +---+ +---+ |--|NVE4|
+----+ +---------+ | | +---------+ +----+ +----+ +---------+ | | +---------+ +----+
+--------------+ +--------------+
|<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->| |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->|
|<--PBB-VPLS-->| |<--PBB-VPLS-->|
Interconnect -> |<-EVPN-MPLS-->| Interconnect -> |<-EVPN-MPLS-->|
options |<--EVPN-Ovl-->| options |<--EVPN-Ovl-->|*
|<--PBB-EVPN-->| |<--PBB-EVPN-->|
Figure 2 Integrated Interconnect model Figure 2 Integrated Interconnect model
3.1. Interconnect requirements * EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option).
The solution needs to observe the following requirements: 4.1. Interconnect requirements
o The GW function MUST provide control plane and data plane The Integrated Interconnect solution meets the following
interworking between the EVPN-overlay network and the L2VPN requirements:
technology supported in the WAN, i.e. (PBB-)VPLS or (PBB-)EVPN, as
o Control plane and data plane interworking between the EVPN-overlay
network and the L2VPN technology supported in the WAN, irrespective
of the technology choice, 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, including single-active multi-homing with per-service
per-service load balancing MUST be implemented. All-active multi- load balancing or all-active multi-homing, i.e. per-flow load-
homing, i.e. per-flow load-balancing, SHOULD be implemented as long balancing, as long as the technology deployed in the WAN supports
as the technology deployed in the WAN supports it. it.
o If EVPN is deployed in the WAN, the MAC Mobility, Static MAC o Support for end-to-end MAC Mobility, Static MAC protection and
protection and other procedures (e.g. proxy-arp) described in other procedures (e.g. proxy-arp) described in [RFC7432] as long as
[RFC7432] MUST be supported end-to-end. EVPN-MPLS is the technology of choice in the WAN.
o Any type of inclusive multicast tree MUST be independently o Independent inclusive multicast trees in the WAN and in the DC.
supported in the WAN as per [RFC7432], and in the DC as per [EVPN- That is, the inclusive multicast tree type defined in the WAN does
Overlays]. not need to be the same as in the DC.
3.2. VPLS Interconnect for EVPN-Overlay networks 4.2. VPLS Interconnect for EVPN-Overlay networks
3.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 2.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-ESI, 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
in the "DC split-horizon-group". in the "DC split-horizon-group".
Attachment circuits are also supported on the same MAC-VRF, but they Attachment circuits are also supported on the same MAC-VRF, but they
will not be part of any of the above split-horizon-groups. will not be part of any of the above split-horizon-groups.
Traffic received in a given split-horizon-group will never be Traffic received in a given split-horizon-group will never be
forwarded to a member of the same split-horizon-group. forwarded to a member of the same split-horizon-group.
As far as BUM flooding is concerned, a flooding list will be created As far as BUM flooding is concerned, a flooding list will be composed
with the sub-list created by the inclusive multicast routes and the of the sub-list created by the inclusive multicast routes and the
sub-list created for VPLS in the WAN. BUM frames received from a sub-list created for VPLS in the WAN. BUM frames received from a
local attachment circuit will be forwarded to the flooding list. BUM local Attachment Circuit (AC) will be forwarded to the flooding list.
frames received from the DC or the WAN will be forwarded to the BUM frames received from the DC or the WAN will be forwarded to the
flooding list observing the split-horizon-group rule described above. flooding list observing the split-horizon-group rule described above.
Note that the GWs are not allowed to have an EVPN binding and a PW to Note that the GWs are not allowed to have an EVPN binding and a PW to
the same far-end within the same MAC-VRF in order to avoid loops and the same far-end within the same MAC-VRF in order to avoid loops and
packet duplication. This is described in [EVPN-VPLS-INTEGRATION]. packet duplication. This is described in [EVPN-VPLS-INTEGRATION] and,
in case a GW can successfully establish both, an EVPN binding and a
PW to the same far-end PE, the EVPN binding will prevail and the PW
will be brought operationally down.
The optimizations procedures described in section 2.5 can also be The optimizations procedures described in section 3.5 can also be
applied to this model. applied to this model.
3.2.2. Multi-homing procedures on the GWs 4.2.2. Multi-homing procedures on the GWs
Single-active multi-homing MUST be supported on the GWs. All-active This model supports single-active multi-homing on the GWs. All-active
multi-homing is not supported by VPLS. multi-homing is not supported by VPLS, therefore it cannot be used on
the GWs.
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. Overlays] will be followed for the I-ESI.
The non-DF GW for the I-ESI will block the transmission and reception The non-DF GW for the I-ESI will block the transmission and reception
of all the bindings in the "WAN split-horizon-group" for BUM and of all the bindings in the "WAN split-horizon-group" for BUM and
unicast traffic. unicast traffic.
3.3. PBB-VPLS Interconnect for EVPN-Overlay networks 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks
3.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
savings in terms of PWs to be maintained in the WAN. savings in terms of PWs to be maintained in the WAN.
The I-ESI concept described in section 3.2.1 will also be used for The I-ESI concept described in section 4.2.1 will also be used for
the PBB-VPLS-based Interconnect. the PBB-VPLS-based Interconnect.
B-component PWs and I-component EVPN-overlay bindings established to B-component PWs and I-component EVPN-overlay bindings established to
the same far-end will be compared. The following rules will be the same far-end will be compared. The following rules will be
observed: observed:
o Attempts to setup a PW between the two GWs within the B- o Attempts to setup a PW between the two GWs within the B-
component context will never be blocked. component context will never be blocked.
o If a PW exists between two GWs for the B-component and an o If a PW exists between two GWs for the B-component and an
attempt is made to setup an EVPN binding on an I-component linked attempt is made to setup an EVPN binding on an I-component linked
to that B-component, the EVPN binding will be kept operationally to that B-component, the EVPN binding will be kept operationally
down. Note that the BGP EVPN routes will still be valid but not down. Note that the BGP EVPN routes will still be valid but not
used. used.
o The EVPN binding will only be up and used as long as there is no o The EVPN binding will only be up and used as long as there is no
PW to the same far-end in the corresponding B-component. The EVPN PW to the same far-end in the corresponding B-component. The EVPN
bindings in the I-components will be brought down before the PW in bindings in the I-components will be brought down before the PW in
the B-component is brought up. the B-component is brought up.
The optimizations procedures described in section 2.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.
3.3.2. Multi-homing procedures on the GWs 4.3.2. Multi-homing procedures on the GWs
Single-active multi-homing MUST be supported 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- 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 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.
3.4.1. Control Plane setup procedures on the GWs 4.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 BGP EVPN session to the DC RR (or two BGP EVPN sessions if
session(s) to the WAN RR(s). there are redundant DC RRs) and one session to the WAN RR (or two
sessions if there are redundant WAN RRs).
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 [RFC5512] BGP encapsulation extended community with a different a [TUNNEL-ENCAP] BGP encapsulation extended community with a
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-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. Optionally, different I-ESI values MAY be also the DC to the WAN. Optionally, different I-ESI values are
configured for representing the WAN and the DC. If different EVPN- configured for representing the WAN and the DC. If different EVPN-
Overlay networks are connected to the same group of GWs, each EVPN- Overlay networks are connected to the same group of GWs, each EVPN-
Overlay network MUST get assigned a different I-ESI. 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.
skipping to change at page 12, line 26 skipping to change at page 14, line 36
+ 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).
+ The appropriate Route-Targets (RTs) and [RFC5512] 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 [RFC5512] be sent to the DC and WAN, with their corresponding RTs and [TUNNEL-
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 ESI 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
skipping to change at page 13, line 23 skipping to change at page 15, line 33
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.
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, having the route from the above, the GW will select only one, having the route from the
set-WAN a higher priority. As for the Inclusive multicast set-WAN a higher priority. As with the Inclusive multicast
routes, an administrative option MAY change this priority. routes, an administrative option MAY change this priority.
Note that, irrespective of the encapsulation, EVPN routes always have Note that, irrespective of the encapsulation, EVPN routes always have
higher priority than VPLS AD routes as per [EVPN-VPLS-INTEGRATION]. higher priority than VPLS AD routes as indicated in [EVPN-VPLS-
INTEGRATION].
3.4.2. Data Plane setup procedures on the GWs 4.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 EVPN-Overlay network (for frames generated from local ACs) since same EVPN-Overlay network (for frames generated from local ACs) since
only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN- only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN-
aware bundle services) will be setup in the data plane between the aware bundle services) will be setup in the data plane between the
two nodes. That binding will by default be added to the EVPN-MPLS two nodes. That binding will by default be added to the EVPN-MPLS
flooding list. flooding list.
As for the rest of the EVPN tunnel bindings, they will be added to As for the rest of the EVPN tunnel bindings, they will be added to
skipping to change at page 14, line 14 skipping to change at page 16, line 25
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 MPLS tunnel When either GW1 or GW2 receive a BUM frame on an MPLS tunnel
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).
3.4.3. Multi-homing procedure extensions on the GWs 4.4.3. Multi-homing procedure extensions on the GWs
Single-active as well as all-active multi-homing MUST be supported. 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- ESI(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-
skipping to change at page 16, line 29 skipping to change at page 18, line 33
+--+ +--+
|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-ESI 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. GW2 will only forward
the packets to local ACs (CE in the example). the packets to local ACs (CE in the example).
3.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-ESI, 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.
3.4.5. Gateway optimizations 4.4.5. Gateway optimizations
All the Gateway optimizations described in section 2.5 MAY be applied All the Gateway optimizations described in section 3.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, solves some transient packet duplication issues in section 3.5.1, solves some transient packet duplication issues in
cases of all-active multi-homing, as explained below. cases of all-active multi-homing, as explained below.
Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all- Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all-
active multi-homing, and the following sequence: active multi-homing, and the following sequence:
a) MAC Address M1 is advertised from NVE3 in EVI-1. a) MAC Address M1 is advertised from NVE3 in EVI-1.
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.
skipping to change at page 17, line 28 skipping to change at page 19, line 34
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. However, because the Unknown MAC route had been
advertised into the DC, NVE1 will unicast the packet to either advertised into the DC, NVE1 will unicast the packet to either
GW1 or GW2. 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.
3.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:
o The solution supports the connectivity of local attachment o The solution supports the connectivity of local attachment
circuits on the GWs. circuits on the GWs.
o Different data plane encapsulations can be supported in the DC o Different data plane encapsulations can be supported in the DC
skipping to change at page 18, line 13 skipping to change at page 20, line 17
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 DC GWs 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 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks
PBB-EVPN [RFC7623] is yet another Interconnect option. It requires PBB-EVPN [RFC7623] is yet another Interconnect option. It requires
the use of GWs where I-components and associated B-components are the use of GWs where I-components and associated B-components are
part of EVI instances. part of EVI instances.
3.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-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 [RFC7623]. component EVI as per [RFC7623].
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 3.3.1. described in section 4.3.1.
3.5.2. Multi-homing procedures on the GWs 4.5.2. Multi-homing procedures on the GWs
Single-active as well as all-active multi-homing MUST be supported. 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 3.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.
3.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.
3.5.4. Gateway optimizations 4.5.4. Gateway optimizations
All the considerations explained in section 3.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.
3.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.
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
skipping to change at page 20, line 12 skipping to change at page 22, line 17
In both options, NVEs inside a DC only have to be aware of a single In both options, NVEs inside a DC only have to be aware of a single
VNI space, and only GWs will handle the complexity of managing VNI space, and only GWs will handle the complexity of managing
multiple VNI spaces. In addition to VNI translation above, the GWs multiple VNI spaces. In addition to VNI translation above, the GWs
will provide translation of the tunnel source IP for the packets will provide translation of the tunnel source IP for the packets
generated from the NVEs, using their own IP address. GWs will use generated from the NVEs, using their own IP address. GWs will use
that IP address as the BGP next-hop in all the EVPN updates to the that IP address as the BGP next-hop in all the EVPN updates to the
Interconnect network. Interconnect network.
The following sections provide more details about these two options. The following sections provide more details about these two options.
3.6.1. Globally unique VNIs in the Interconnect network 4.6.1. Globally unique VNIs in the Interconnect network
Considering Figure 2, if a host H1 in NVO-1 needs to communicate with Considering Figure 2, if a host H1 in NVO-1 needs to communicate with
a host H2 in NVO-2, and assuming that different VNIs are used in each a host H2 in NVO-2, and assuming that different VNIs are used in each
DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then
the VNIs MUST be translated to a common Interconnect VNI (e.g. VNI- the VNIs MUST be translated to a common Interconnect VNI (e.g. VNI-
100) on the GWs. Each GW is provisioned with a VNI translation 100) on the GWs. Each GW is provisioned with a VNI translation
mapping so that it can translate the VNI in the control plane when mapping so that it can translate the VNI in the control plane when
sending BGP EVPN route updates to the Interconnect network. In other sending BGP EVPN route updates to the Interconnect network. In other
words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the
BGP update messages for H1's MAC route. This mapping is also used to BGP update messages for H1's MAC route. This mapping is also used to
translate the VNI in the data plane in both directions, that is, VNI- translate the VNI in the data plane in both directions, that is, VNI-
10 to VNI-100 when the packet is received from NVO-1 and the reverse 10 to VNI-100 when the packet is received from NVO-1 and the reverse
mapping from VNI-100 to VNI-10 when the packet is received from the mapping from VNI-100 to VNI-10 when the packet is received from the
remote NVO-2 network and needs to be forwarded to NVO-1. remote NVO-2 network and needs to be forwarded to NVO-1.
The procedures described in section 3.4 will be followed, considering The procedures described in section 4.4 will be followed, considering
that the VNIs advertised/received by the GWs will be translated that the VNIs advertised/received by the GWs will be translated
accordingly. accordingly.
3.6.2. Downstream assigned VNIs in the Interconnect network 4.6.2. Downstream assigned VNIs in the Interconnect network
In this case, if a host H1 in NVO-1 needs to communicate with a host In this case, if a host H1 in NVO-1 needs to communicate with a host
H2 in NVO-2, and assuming that different VNIs are used in each DC for H2 in NVO-2, and assuming that different VNIs are used in each DC for
the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs
MUST be translated as in section 3.6.1. However, in this case, there MUST be translated as in section 4.6.1. However, in this case, there
is no need to translate to a common Interconnect VNI on the GWs. Each is no need to translate to a common Interconnect VNI on the GWs. Each
GW can translate the VNI received in an EVPN update to a locally GW can translate the VNI received in an EVPN update to a locally
assigned VNI advertised to the Interconnect network. Each GW can use assigned VNI advertised to the Interconnect network. Each GW can use
a different Interconnect VNI, hence this VNI does not need to be a different Interconnect VNI, hence this VNI does not need to be
agreed on all the GWs and PEs of the Interconnect network. agreed on all the GWs and PEs of the Interconnect network.
The procedures described in section 3.4 will be followed, taking the The procedures described in section 4.4 will be followed, taking the
considerations above for the VNI translation. considerations above for the VNI translation.
5. Conventions and Terminology 5. Security Considerations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
AC: Attachment Circuit
BUM: it refers to the Broadcast, Unknown unicast and Multicast
traffic
DF: Designated Forwarder
GW: Gateway or Data Center Gateway
DCI: Data Center Interconnect
ES: Ethernet Segment
ESI: Ethernet Segment Identifier
I-ESI: Interconnect ESI defined on the GWs for multi-homing to/from
the WAN
EVI: EVPN Instance
MAC-VRF: it refers to an EVI instance in a particular node
NVE: Network Virtualization Edge
PW: Pseudowire
RD: Route-Distinguisher
RT: Route-Target
TOR: Top-Of-Rack switch This document applies existing Technical Specifications to a number
of Interconnect models. The Security Considerations included in those
documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761]
and [RFC4762] apply to this document whenever those technologies are
used.
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers [EVPN-Overlays] discusses two main DCI solution groups: "DCI using
GWs" and "DCI using ASBRs". This document specifies the solutions
that correspond to the "DCI using GWs" group. It is important to note
that use of GWs provide a superior level of security on a per tenant
basis, compared to the use of ASBRs. This is due to the fact that GWs
need to perform a MAC lookup on the frames being received from the
WAN, and they apply security procedures, such as filtering of
undesired frames, filtering of frames with a source MAC that matches
a protected MAC in the DC or application of MAC duplication
procedures defined in [RFC7432]. On ASBRs though, traffic is
forwarded based on a label or VNI swap and there is usually no
visibility of the encapsulated frames, which can carry malicious
traffic.
VSI: Virtual Switch Instance or VPLS instance in a particular PE In addition, the GW optimizations specified in this document, provide
additional protection of the DC Tenant Systems. For instance, the MAC
address advertisement control and Unknown MAC route defined in
section 3.5.1 protect the DC NVEs from being overwhelmed with an
excessive number MAC/IP routes being learned on the GWs from the WAN.
The ARP/ND flooding control described in 3.5.2 can reduce/suppress
broadcast storms being injected from the WAN.
6. Security Considerations Finally, the reader should be aware of the potential security
implications of designing a DCI with the Decoupled Interconnect
solution (section 2) or the Integrated Interconnect solution (section
3). In the Decoupled Interconnect solution the DC is typically easier
to protect from the WAN, since each GW has a single logical link to
one WAN PE, whereas in the Integrated solution, the GW has logical
links to all the WAN PEs that are attached to the tenant. In either
model, proper control plane and data plane policies should be put in
place in the GWs in order to protect the DC from potential attacks
coming from the WAN.
Security considerations included in [RFC7432], [RFC4761] and 6. IANA Considerations
[RFC4762] apply to this document.
7. IANA Considerations This document has no IANA actions.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling",
DOI 10.17487/RFC4761, January 2007, <http://www.rfc- RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-
editor.org/info/rfc4761>. 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, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-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, DOI 10.17487/RFC6074, January Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January
2011, <http://www.rfc-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, 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>.
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <http://www.rfc-editor.org/info/rfc2119>. 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC5512]Mohapatra, P. and E. Rosen, "The BGP Encapsulation [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress,
Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, January 11, 2018.
<http://www.rfc-editor.org/info/rfc5512>.
[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc- Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc-
editor.org/info/rfc7623>. editor.org/info/rfc7623>.
8.2. Informative References [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt,
work in progress, January, 2018
[EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization 7.2. Informative References
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-08.txt,
work in progress, March, 2017
[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 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
DOI 10.17487/RFC4684, November 2006, <http://www.rfc-
editor.org/info/rfc4684>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible
Local Area Network (VXLAN): A Framework for Overlaying Virtualized
Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI
10.17487/RFC7348, August 2014, <http://www.rfc-
editor.org/info/rfc7348>.
[RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using
Generic Routing Encapsulation", RFC 7637, September, 2015
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-
editor.org/info/rfc4023>.
[Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms
for Ethernet based networks", July 2011.
[802.1AG] IEEE 802.1AG_2007, "IEEE Standard for Local and
Metropolitan Area Networks - Virtual Bridged Local Area Networks
Amendment 5: Connectivity Fault Management", January 2008.
[802.1Q-2014] IEEE 802.1Q-2014, "IEEE Standard for Local and
metropolitan area networks--Bridges and Bridged Networks", December
2014.
[RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870,
February 2013, <http://www.rfc-editor.org/info/rfc6870>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031,
January 2001, <http://www.rfc-editor.org/info/rfc3031>.
8. Acknowledgments
The authors would like to thank Neil Hart, Vinod Prabhu and Kiran The authors would like to thank Neil Hart, Vinod Prabhu and Kiran
Nagaraj for their valuable comments and feedback. Nagaraj for their valuable comments and feedback. We would also like
to thank Martin Vigoureux for his detailed review and comments.
10. Contributors 9. Contributors
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:
Ravi Shekhar Ravi Shekhar
Anil Lohiya Anil Lohiya
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Florin Balus Florin Balus
Patrice Brissette Patrice Brissette
Cisco Cisco
Senad Palislamovic Senad Palislamovic
Nokia Nokia
Dennis Cai Dennis Cai
Alibaba Alibaba
11. Authors' Addresses 10. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
Nokia Nokia
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
 End of changes. 122 change blocks. 
272 lines changed or deleted 416 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/