rfc9014.original   rfc9014.txt 
BESS Workgroup J. Rabadan (Ed.) Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Internet Draft S. Sathappan Request for Comments: 9014 S. Sathappan
Intended status: Standards Track W. Henderickx Category: Standards Track W. Henderickx
Nokia ISSN: 2070-1721 Nokia
A. Sajassi A. Sajassi
Cisco Cisco
J. Drake J. Drake
Juniper Juniper
May 2021
Expires: September 3, 2018 March 2, 2018 Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks
Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-10
Abstract Abstract
This document describes how Network Virtualization Overlays (NVO) can This document describes how Network Virtualization Overlays (NVOs)
be connected to a Wide Area Network (WAN) in order to extend the can 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
the interaction between NVO networks running Ethernet Virtual Private analyzes the interaction between NVO networks running Ethernet
Networks (EVPN) and other L2VPN technologies used in the WAN, such as Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN)
Virtual Private LAN Services (VPLS), VPLS extensions for Provider technologies used in the WAN, such as Virtual Private LAN Services
Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS),
the existing technical specifications apply to the Interconnection EVPN, or PBB-EVPN. It also describes how the existing technical
and extends the EVPN procedures needed in some cases. In particular, specifications apply to the Interconnection and extends the EVPN
this document describes how EVPN routes are processed on Gateways procedures needed in some cases. In particular, this document
(GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well describes how EVPN routes are processed on Gateways (GWs) that
as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the
and the use of the Unknown MAC route to avoid MAC scale issues on Interconnect Ethernet Segment (I-ES), to provide multihoming. This
Data Center Network Virtualization Edge (NVE) devices. document also describes the use of the Unknown MAC Route (UMR) to
avoid issues of a Media Access Control (MAC) scale on Data Center
Status of this Memo Network Virtualization Edge (NVE) devices.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 3, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9014.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://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. Introduction
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology
3. Decoupled Interconnect solution for EVPN overlay networks . . . 6 3. Decoupled Interconnect Solution for EVPN-Overlay Networks
3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 7 3.1. Interconnect Requirements
3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 8 3.2. VLAN-Based Handoff
3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 8 3.3. PW-Based Handoff
3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 9 3.4. Multihoming Solution on the GWs
3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 9 3.5. Gateway Optimizations
3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 9 3.5.1. MAC Address Advertisement Control
3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 10 3.5.2. ARP/ND Flooding Control
3.5.3. Handling failures between GW and WAN Edge routers . . . 11 3.5.3. Handling Failures between GW and WAN Edge Routers
4. Integrated Interconnect solution for EVPN overlay networks . . 11 4. Integrated Interconnect Solution for EVPN-Overlay Networks
4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 12 4.1. Interconnect Requirements
4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 13 4.2. VPLS Interconnect for EVPN-Overlay Networks
4.2.1. Control/Data Plane setup procedures on the GWs . . . . 13 4.2.1. Control/Data Plane Setup Procedures on the GWs
4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 14 4.2.2. Multihoming Procedures on the GWs
4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 14 4.3. PBB-VPLS Interconnect for EVPN-Overlay Networks
4.3.1. Control/Data Plane setup procedures on the GWs . . . . 14 4.3.1. Control/Data Plane Setup Procedures on the GWs
4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 15 4.3.2. Multihoming Procedures on the GWs
4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 15 4.4. EVPN-MPLS Interconnect for EVPN-Overlay Networks
4.4.1. Control Plane setup procedures on the GWs . . . . . . . 15 4.4.1. Control plane Setup Procedures on the GWs
4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 17 4.4.2. Data Plane Setup Procedures on the GWs
4.4.3. Multi-homing procedure extensions on the GWs . . . . . 18 4.4.3. Multihoming Procedure Extensions on the GWs
4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 20 4.4.4. Impact on MAC Mobility Procedures
4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 20 4.4.5. Gateway Optimizations
4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 21 4.4.6. Benefits of the EVPN-MPLS Interconnect Solution
4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 22 4.5. PBB-EVPN Interconnect for EVPN-Overlay Networks
4.5.1. Control/Data Plane setup procedures on the GWs . . . . 22 4.5.1. Control/Data Plane Setup Procedures on the GWs
4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 22 4.5.2. Multihoming Procedures on the GWs
4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 23 4.5.3. Impact on MAC Mobility Procedures
4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 23 4.5.4. Gateway Optimizations
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 23 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay Networks
4.6.1. Globally unique VNIs in the Interconnect network . . . 24 4.6.1. Globally Unique VNIs in the Interconnect Network
4.6.2. Downstream assigned VNIs in the Interconnect network . 24 4.6.2. Downstream-Assigned VNIs in the Interconnect Network
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . . 27 7.2. Informative References
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 Acknowledgments
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 Contributors
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses
1. Conventions and Terminology 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", [RFC8365] discusses the use of Ethernet Virtual Private Networks
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and (EVPNs) [RFC7432] as the control plane for Network Virtualization
"OPTIONAL" in this document are to be interpreted as described in BCP Overlays (NVOs), where VXLAN [RFC7348], NVGRE [RFC7637], or MPLS over
14 [RFC2119] [RFC8174] when, and only when, they appear in all GRE [RFC4023] can be used as possible data plane encapsulation
capitals, as shown here. options.
AC: Attachment Circuit. While this model provides a scalable and efficient multitenant
solution within the Data Center, it might not be easily extended to
the Wide Area Network (WAN) in some cases, due to the requirements
and existing deployed technologies. For instance, a Service Provider
might have an already deployed Virtual Private LAN Service (VPLS)
[RFC4761] [RFC4762], VPLS extensions for Provider Backbone Bridging
(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. In fact,
[RFC8365] discusses two main Data Center Interconnect (DCI) solution
groups: "DCI using GWs" and "DCI using ASBRs". This document
specifies the solutions that correspond to the "DCI using GWs" group.
ARP: Address Resolution Protocol. It is assumed that the NVO GW and the WAN Edge functions can be
decoupled into two separate systems or integrated into the same
system. The former option will be referred to as "Decoupled
Interconnect solution" throughout the document, whereas the latter
one will be referred to as "Integrated Interconnect solution".
BUM: refers to Broadcast, Unknown unicast and Multicast traffic. 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).
CE: Customer Equipment. While the Gateways and WAN Provider Edges (PEs) use existing
specifications in some cases, the document also defines extensions
that are specific to DCI. In particular, those extensions are:
CFM: Connectivity Fault Management. * The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that
can be associated to a set of pseudowires (PWs) or other tunnels.
The I-ES defined in this document is not associated with a set of
Ethernet links, as per [RFC7432], but rather with a set of virtual
tunnels (e.g., a set of PWs). This set of virtual tunnels is
referred to as vES [VIRTUAL-ES].
DC and DCI: Data Center and Data Center Interconnect. * The use of the Unknown MAC Route (UMR) in a DCI scenario.
DC RR(s) and WAN RR(s): refers to the Data Center and Wide Area * The processing of EVPN routes on Gateways with MAC-VRFs connecting
Network Route Reflectors, respectively. EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-
Overlay networks.
DF and NDF: Designated Forwarder and Non-Designated Forwarder. 2. Conventions and Terminology
EVPN: Ethernet Virtual Private Network, as in [RFC7432]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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.
EVI: EVPN Instance. AC: Attachment Circuit
EVPN Tunnel binding: refers to a tunnel to a remote PE/NVE for a ARP: Address Resolution Protocol
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 and vES: Ethernet Segment and virtual Ethernet Segment. BUM: Broadcast, Unknown Unicast and Multicast (traffic)
ESI: Ethernet Segment Identifier. CE: Customer Equipment
GW: Gateway or Data Center Gateway. CFM: Connectivity Fault Management
I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect DC: Data Center
Ethernet Segment Identifier. An I-ES is defined on the GWs for multi-
homing to/from the WAN.
MAC-VRF: refers to an EVI instance in a particular node. DCI: Data Center Interconnect
MP2P and LSM tunnels: refer to Multi-Point to Point and Label DF and NDF: Designated Forwarder
Switched Multicast tunnels.
ND: Neighbor Discovery protocol. EVI: EVPN Instance
NVE: Network Virtualization Edge. EVPN: Ethernet Virtual Private Network, as in [RFC7432]
NVGRE: Network Virtualization using Generic Routing Encapsulation. EVPN Tunnel binding: 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.
NVO: refers to Network Virtualization Overlays. ES: Ethernet Segment
OAM: Operations and Maintenance. ESI: Ethernet Segment Identifier
PBB: Provider Backbone Bridging. GW: Gateway or Data Center Gateway
PE: Provider Edge. I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect
Ethernet Segment Identifier. An I-ES is defined on the GWs for
multihoming to/from the WAN.
PW: Pseudowire. MAC Media Access Control
RD: Route-Distinguisher. MAC-VRF: refers to an EVI instance in a particular node
RT: Route-Target. MP2P and LSM tunnels: refer to multipoint-to-point and label
switched multicast tunnels
S/C-TAG: refers to a combination of Service Tag and Customer Tag in a ND: Neighbor Discovery
802.1Q frame.
TOR: Top-Of-Rack switch. NDF: Non-Designated Forwarder
UMR: Unknown MAC Route. NVE: Network Virtualization Edge
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers. NVGRE: Network Virtualization using Generic Routing Encapsulation
VPLS: Virtual Private LAN Service. NVO: Network Virtualization Overlay
VSI: Virtual Switch Instance or VPLS instance in a particular PE. OAM: Operations, Administration, and Maintenance
VXLAN: Virtual eXtensible LAN. PBB: Provider Backbone Bridging
2. Introduction PE: Provider Edge
[EVPN-Overlays] discusses the use of Ethernet Virtual Private PW: Pseudowire
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 RD: Route Distinguisher
solution within the Data Center, it might not be easily extended to
the Wide Area Network (WAN) in some cases due to the requirements and
existing deployed technologies. For instance, a Service Provider
might have an already deployed Virtual Private LAN Service (VPLS)
[RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging
(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. In fact, [EVPN-
Overlays] discusses two main Data Center Interconnect solution
groups: "DCI using GWs" and "DCI using ASBRs". This document
specifies the solutions that correspond to the "DCI using GWs" group.
It is assumed that the NVO Gateway (GW) and the WAN Edge functions RR: Route Reflector
can be decoupled in two separate systems or integrated into the same
system. The former option will be referred as "Decoupled Interconnect
solution" throughout the document, whereas the latter one will be
referred as "Integrated Interconnect solution".
The specified procedures are local to the redundant GWs connecting a RT: Route Target
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 specifications in some S/C-TAG: refers to a combination of Service Tag and Customer Tag in
cases, the document also defines extensions that are specific to DCI. a 802.1Q frame
In particular, those extensions are:
o The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that TOR: Top-Of-Rack
can be associated to a set of PWs or other tunnels. I-ES defined in
this document is not associated with a set of Ethernet links, as
per [RFC7432], but rather with a set of virtual tunnels (e.g., a
set of PWs). This set of virtual tunnels is referred to as vES
[VIRTUAL-ES].
o The use of the Unknown MAC route in a DCI scenario. UMR: Unknown MAC Route
o The processing of EVPN routes on Gateways with MAC-VRFs connecting vES: virtual Ethernet Segment
EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-
Overlay networks.
3. Decoupled Interconnect solution for EVPN overlay networks VNI/VSID: refers to VXLAN/NVGRE virtual identifiers
This section describes the interconnect solution when the GW and WAN VPLS: Virtual Private LAN Service
Edge functions are implemented in different systems. Figure 1 depicts
the reference model described in this section. Note that, although VSI: Virtual Switch Instance or VPLS instance in a particular PE
not shown in Figure 1, GWs may have local ACs (Attachment Circuits).
VXLAN: Virtual eXtensible LAN
3. Decoupled Interconnect Solution for EVPN-Overlay Networks
This section describes the Interconnect solution when the GW and WAN
Edge functions are implemented in different systems. Figure 1
depicts the reference model described in this section. Note that,
although not shown in Figure 1, GWs may have local Attachment
Circuits (ACs).
+--+ +--+
|CE| |CE|
+--+ +--+
| |
+----+ +----+
+----| PE |----+ +----| PE |----+
+---------+ | +----+ | +---------+ +---------+ | +----+ | +---------+
+----+ | +---+ +----+ +----+ +---+ | +----+ +----+ | +---+ +----+ +----+ +---+ | +----+
|NVE1|--| | | |WAN | |WAN | | | |--|NVE3| |NVE1|--| | | |WAN | |WAN | | | |--|NVE3|
skipping to change at page 7, line 25 skipping to change at line 276
| +---+ +----+ +----+ +---+ | | +---+ +----+ +----+ +---+ |
| NVO-1 | | WAN | | NVO-2 | | NVO-1 | | WAN | | NVO-2 |
| +---+ +----+ +----+ +---+ | | +---+ +----+ +----+ +---+ |
| | | |WAN | |WAN | | | | | | | |WAN | |WAN | | | |
+----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+ +----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+
|NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4|
+----+ +---------+ | | +---------+ +----+ +----+ +---------+ | | +---------+ +----+
+--------------+ +--------------+
|<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->|
hand-off hand-off handoff handoff
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.
3.1. Interconnect requirements 3.1. Interconnect Requirements
The Decoupled Interconnect architecture is intended to be 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. This solution solves the entities and a clear demarcation is needed. This solution solves the
following requirements: following requirements:
o A simple connectivity hand-off between the EVPN-Overlay network * A simple connectivity handoff between the EVPN-Overlay network
provider and the WAN provider so that QoS and security enforcement provider and the WAN provider so that QoS and security enforcement
is easily accomplished. are easily accomplished.
o Independence of the Layer Two VPN (L2VPN) technology deployed in * Independence of the L2VPN technology deployed in the WAN.
the WAN.
o Multi-homing between GW and WAN Edge routers, including per-service * Multihoming 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
since a deterministic path per service is usually required for an requirement, since a deterministic path per service is usually
easy QoS and security enforcement. required for an easy QoS and security enforcement.
o Support of Ethernet OAM and Connectivity Fault Management (CFM) * Support of Ethernet OAM and Connectivity Fault Management (CFM)
[802.1AG][Y.1731] functions between the GW and the WAN Edge router [IEEE.802.1AG] [Y.1731] functions between the GW and the WAN Edge
to detect individual AC failures. router to detect individual AC failures.
o Support for the following optimizations at the GW: * Support for the following optimizations at the GW:
+ Flooding reduction of unknown unicast traffic sourced from the DC
Network Virtualization Edge devices (NVEs).
+ Control of the WAN MAC addresses advertised to the DC.
+ Address Resolution Protocol (ARP) and Neighbor Discovery (ND)
flooding control for the requests coming from the WAN.
3.2. VLAN-based hand-off - Flooding reduction of unknown unicast traffic sourced from the
DC Network Virtualization Edge (NVE) devices.
In this option, the hand-off between the GWs and the WAN Edge routers - Control of the WAN MAC addresses advertised to the DC.
is based on VLANs [802.1Q-2014]. This is illustrated in Figure 1
(between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in - Address Resolution Protocol (ARP) and Neighbor Discovery (ND)
flooding control for the requests coming from the WAN.
3.2. VLAN-Based Handoff
In this option, the handoff between the GWs and the WAN Edge routers
is based on VLANs [IEEE.802.1Q]. This is illustrated in Figure 1
(between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in
the GW is connected to a different VSI/MAC-VRF instance in the WAN the GW is connected to a different VSI/MAC-VRF instance in the WAN
Edge router by using a different C-TAG VLAN ID or a different Edge router by using a different C-TAG VLAN ID or a different
combination of 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 [RFC8365].
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].
3.3. PW-based (Pseudowire-based) hand-off 3.3. PW-Based Handoff
If MPLS between the GW and the WAN Edge router is an option, 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 [RFC4762] handoff between both routers is based on FEC128-based PWs [RFC4762]
or FEC129-based PWs (for a greater level of network automation) or FEC129-based PWs (for a greater level of network automation)
[RFC6074]. Note that this model still provides a clear demarcation [RFC6074]. Note that this model still provides a clear demarcation
boundary between DC and WAN (since there is a single PW between each between DC and WAN (since there is a single PW between each MAC-VRF
MAC-VRF and peer VSI), and security/QoS policies may be applied on a and peer VSI), and security/QoS policies may be applied on a per-PW
per PW basis. This model provides better scalability than a C-TAG basis. This model provides better scalability than a C-TAG-based
based hand-off and less provisioning overhead than a combined C/S-TAG handoff and less provisioning overhead than a combined C/S-TAG
hand-off. The PW-based hand-off interconnect is illustrated in Figure handoff. The PW-based handoff interconnect is illustrated in
1 (between the NVO-2 GWs and the WAN Edge routers). Figure 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 [RFC3031], the GW MUST support an interworking function Edge router [RFC3031], the GW MUST support an interworking function
in each 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 * If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI
(WAN Edge), the corresponding VCID MUST be provisioned on the MAC- (WAN Edge), the corresponding Virtual Connection Identifier (VCID)
VRF and match the VCID used in the peer VSI at the WAN Edge router. MUST be provisioned on the MAC-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 * 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.
If a PW-based handoff is used, the GW's AC (or point of attachment to If a PW-based handoff is used, the GW's AC (or point of attachment to
the EVPN Instance) uses a combination of a PW label and VLAN IDs. PWs the EVPN instance) uses a combination of a PW label and VLAN IDs.
are treated as service interfaces defined in [RFC7432]. PWs are treated as service interfaces, defined in [RFC7432].
3.4. Multi-homing solution on the GWs 3.4. Multihoming Solution on the GWs
EVPN single-active multi-homing, i.e. per-service load-balancing EVPN single-active multihoming -- i.e., per-service load-balancing
multi-homing is required in this type of interconnect. multihoming -- is required in this type of interconnect.
The GWs will be provisioned with a unique ES per WAN interconnect, The GWs will be provisioned with a unique ES for each WAN
and the hand-off attachment circuits or PWs between the GW and the interconnect, and the handoff attachment circuits or PWs between the
WAN Edge router will be assigned an ESI for such ES. The ESI will be GW and the WAN Edge router will be assigned an ESI for such ES. The
administratively configured on the GWs according to the procedures in ESI will be administratively configured on the GWs according to the
[RFC7432]. This Interconnect ES will be referred as "I-ES" hereafter, procedures in [RFC7432]. This Interconnect ES will be referred to as
and its identifier will be referred as "I-ESI". [RFC7432] describes "I-ES" hereafter, and its identifier will be referred to as "I-ESI".
different ESI Types. The use of Type 0 for the I-ESI is RECOMMENDED Different ESI types are described in [RFC7432]. The use of Type 0
in this document. 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 multihoming
procedures as described in [EVPN-Overlays] for the provisioned I-ESI, procedures as described in [RFC8365] for the provisioned I-ESI --
i.e. Ethernet A-D routes per ES and per EVI will be advertised to the i.e., Ethernet A-D routes per ES and per EVI will be advertised to
DC NVEs for the multi-homing functions, ES routes will be advertised the DC NVEs for the multihoming functions, and ES routes will be
so that ES discovery and Designated Forwarder (DF) procedures can be advertised so that ES discovery and Designated Forwarder (DF)
followed. The MAC addresses learned (in the data plane) on the hand- procedures can be followed. The MAC addresses learned (in the data
off links will be advertised with the I-ESI encoded in the ESI field. plane) on the handoff links will be advertised with the I-ESI 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 [RFC8365]. However, if multiple DCs are
are interconnected into a single EVI, each DC will have to import all interconnected into a single EVI, each DC will have to import all of
of the MAC addresses from each of the other DCs. the MAC addresses from each of the other DCs.
Even if optimized BGP techniques like RT-constraint [RFC4684] are Even if optimized BGP techniques like RT constraint [RFC4684] are
used, the number of MAC addresses to advertise or withdraw (in case used, the number of MAC addresses to advertise or withdraw (in case
of failure) by the GWs of a given DC could overwhelm the NVEs within of failure) by the GWs of a given DC could overwhelm the NVEs within
that DC, 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
(UMR) which is advertised into a given DC by each of the DC's GWs. (UMR) that is advertised into a given DC by each of the DC's GWs.
This route is defined in [RFC7543] and is a regular EVPN MAC/IP This route is defined in [RFC7543] and is a regular EVPN MAC/IP
Advertisement route in which the MAC Address Length is set to 48, the Advertisement route in which the MAC Address Length is set to 48, the
MAC address is set to 0, and the ESI field is set to the DC GW's I- MAC address is set to 0, and the ESI field is set to the DC GW's
ESI. I-ESI.
An NVE within that DC that understands and process the UMR will send An NVE within that DC that understands and processes the UMR will
unknown unicast frames to one of the DCs GWs, which will then forward send unknown unicast frames to one of the DC's GWs, which will then
that packet to the correct egress PE. Note that, because the ESI is forward that packet to the correct egress PE. Note that, because the
set to the DC GW's I-ESI, all-active multi-homing can be applied to ESI is set to the DC GW's I-ESI, all-active multihoming can be
unknown unicast MAC addresses. An NVE that does not understand the applied to unknown unicast MAC addresses. An NVE that does not
Unknown MAC route will handle unknown unicast as described in understand the Unknown MAC Route will handle unknown unicast as
[RFC7432]. described in [RFC7432].
This document proposes that local policy determines whether MAC This document proposes that local policy determine whether MAC
addresses and/or the UMR are advertised into a given DC. As an addresses and/or the UMR are advertised into a given DC. As an
example, when all the DC MAC addresses are learned in the example, when all the DC MAC addresses are learned in the control/
control/management plane, it may be appropriate to advertise only the management plane, it may be appropriate to advertise only the UMR.
UMR. Advertising all the DC MAC addresses in the control/management Advertising all the DC MAC addresses in the control/management plane
plane is usually the case when the NVEs reside in hypervisors. Refer is usually the case when the NVEs reside in hypervisors. Refer to
to [EVPN-Overlays] section 7. [RFC8365], Section 7.
It is worth noting that the UMR usage in [RFC7543] and the UMR usage It is worth noting that the UMR usage in [RFC7543] and the UMR usage
in this document are different. In the former, a Virtual Spoke (V- in this document are different. In the former, a Virtual Spoke
spoke) does not necessarily learn all the MAC addresses pertaining to (V-spoke) does not necessarily learn all the MAC addresses pertaining
hosts in other V-spokes of the same network. The communication to hosts in other V-spokes of the same network. The communication
between two V-spokes is done through the DMG, until the V-spokes between two V-spokes is done through the Default MAC Gateway (DMG)
learn each other's MAC addresses. In this document, two leaf switches until the V-spokes learn each other's MAC addresses. In this
in the same DC are recommended to learn each other's MAC addresses document, two leaf switches in the same DC are recommended for
for the same EVI. The leaf to leaf communication is always direct and V-spokes to learn each other's MAC addresses for the same EVI. The
does not go through the GW. leaf-to-leaf communication is always direct and does not go through
the GW.
3.5.2. ARP/ND 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/
ARP/ND cache table as per [RFC7432]. When the active GW receives an 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 This mechanism is especially recommended on the GWs, since it
protects the DC network from external ARP/ND-flooding storms. protects the DC network from external ARP/ND-flooding storms.
3.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, Ethernet- * If the Interconnect solution is based on a VLAN handoff, Ethernet-
CFM [802.1AG][Y.1731] may be used to detect individual AC failures CFM [IEEE.802.1AG] [Y.1731] may be used to detect individual AC
on both, the GW and WAN Edge router. An individual AC failure will failures on both the GW and WAN Edge router. An individual AC
trigger the withdrawal of the corresponding A-D per EVI route as failure will trigger the withdrawal of the corresponding A-D per
well as the MACs learned on that AC. EVI route as well as the MACs learned on that AC.
o If the Interconnect solution is based on a PW hand-off, the Label * If the Interconnect solution is based on a PW handoff, the Label
Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be
used to detect individual PW failures on both, the GW and WAN Edge used to detect individual PW failures on both the GW and WAN Edge
router. router.
4. 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 reasons to save as
saving reasons. This is illustrated in Figure 2. Note that this model relates to Capital Expenditure (CAPEX) and Operating Expenses (OPEX).
does not provide an explicit demarcation link between DC and WAN This is illustrated in Figure 2. Note that this model does not
anymore. Although not shown in Figure 2, note that the GWs may have provide an explicit demarcation link between DC and WAN anymore.
local ACs. Although not shown in Figure 2, note that the GWs may have local ACs.
+--+ +--+
|CE| |CE|
+--+ +--+
| |
+----+ +----+
+----| PE |----+ +----| PE |----+
+---------+ | +----+ | +---------+ +---------+ | +----+ | +---------+
+----+ | +---+ +---+ | +----+ +----+ | +---+ +---+ | +----+
|NVE1|--| | | | | |--|NVE3| |NVE1|--| | | | | |--|NVE3|
skipping to change at page 12, line 30 skipping to change at line 511
|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
* EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option). * EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option).
4.1. Interconnect requirements Figure 2: Integrated Interconnect Model
4.1. Interconnect Requirements
The Integrated Interconnect solution meets the following The Integrated Interconnect solution meets the following
requirements: requirements:
o Control plane and data plane interworking between the EVPN-overlay * Control plane and data plane interworking between the EVPN-Overlay
network and the L2VPN technology supported in the WAN, irrespective network and the L2VPN technology supported in the WAN,
of the technology choice, i.e. (PBB-)VPLS or (PBB-)EVPN, as irrespective of the technology choice -- i.e., (PBB-)VPLS or
depicted in Figure 2. (PBB-)EVPN, as depicted in Figure 2.
o Multi-homing, including single-active multi-homing with per-service * Multihoming, including single-active multihoming with per-service
load balancing or all-active multi-homing, i.e. per-flow load- load balancing or all-active multihoming -- i.e., per-flow load-
balancing, as long as the technology deployed in the WAN supports balancing -- as long as the technology deployed in the WAN
it. supports it.
o Support for end-to-end MAC Mobility, Static MAC protection and * Support for end-to-end MAC Mobility, Static MAC protection and
other procedures (e.g. proxy-arp) described in [RFC7432] as long as other procedures (e.g., proxy-arp) described in [RFC7432] as long
EVPN-MPLS is the technology of choice in the WAN. as EVPN-MPLS is the technology of choice in the WAN.
o Independent inclusive multicast trees in the WAN and in the DC. * Independent inclusive multicast trees in the WAN and in the DC.
That is, the inclusive multicast tree type defined in the WAN does That is, the inclusive multicast tree type defined in the WAN does
not need to be the same as in the DC. not need to be the same as in the DC.
4.2. VPLS Interconnect for EVPN-Overlay networks 4.2. VPLS Interconnect for EVPN-Overlay Networks
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 Targeted LDP (tLDP) / BGP sessions will be
PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay set up to the WAN PEs and RRs as per [RFC4761], [RFC4762], and
tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that [RFC6074], and overlay tunnels and EVPN will be set up as per
different route-targets for the DC and for the WAN are normally [RFC8365]. Note that different route targets for the DC and the WAN
required (unless [RFC4762] is used in the WAN, in which case no WAN are normally required (unless [RFC4762] is used in the WAN, in which
route-target is needed). A single type-1 RD per service may be used. case no WAN route target is needed). 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 multihoming, the GWs will be provisioned with an
I-ESI (see section 3.4), that will be unique per interconnection. The I-ESI (see Section 3.4), which will be unique for each
I-ES in this case will represent the group of PWs to the WAN PEs and interconnection. In this case, the I-ES will represent the group of
GWs. All the [RFC7432] procedures are still followed for the I-ES, PWs to the WAN PEs and GWs. All the [RFC7432] procedures are still
e.g. any MAC address learned from the WAN will be advertised to the followed for the I-ES -- e.g., any MAC address learned from the WAN
DC with the I-ESI in the ESI field. will be advertised to the DC with 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". * VPLS PWs will be instantiated in the WAN split-horizon group.
o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated * 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 (although Attachment circuits are also supported on the same MAC-VRF (although
not shown in Figure 2), but they will not be part of any of the above not shown in Figure 2), but they will not be part of any of the above
split-horizon-groups. 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 composed As far as BUM flooding is concerned, a flooding list will be composed
of the sub-list created by the inclusive multicast routes and the of the sublist created by the inclusive multicast routes and the
sub-list created for VPLS in the WAN. BUM frames received from a sublist created for VPLS in the WAN. BUM frames received from a
local Attachment Circuit (AC) will be forwarded to the flooding list. local Attachment Circuit (AC) will be forwarded to the flooding list.
BUM 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, so that loops and packet the same far end within the same MAC-VRF, so that loops and packet
duplication are avoided. In case a GW can successfully establish duplication are avoided. In case a GW can successfully establish
both, an EVPN binding and a PW to the same far-end PE, the EVPN 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. binding will prevail, and the PW will be brought down operationally.
The optimizations procedures described in section 3.5 can also be The optimization 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. Multihoming Procedures on the GWs
This model supports single-active multi-homing on the GWs. All-active This model supports single-active multihoming on the GWs. All-active
multi-homing is not supported by VPLS, therefore it cannot be used on multihoming is not supported by VPLS; therefore, it cannot be used on
the GWs. the GWs.
In this case, for a given EVI, all the PWs in the WAN split-horizon- In this case, for a given EVI, all the PWs in the WAN split-horizon
group are assigned to I-ES. All the single-active multi-homing group are assigned to I-ES. All the single-active multihoming
procedures as described by [EVPN-Overlays] will be followed for the procedures as described by [RFC8365] will be followed for the I-ES.
I-ES.
The non-DF GW for the I-ES will block the transmission and reception The non-DF GW for the I-ES will block the transmission and reception
of all the PWs in the "WAN split-horizon-group" for BUM and unicast of all the PWs in the WAN split-horizon group for BUM and 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
into the same B-component instance. This option provides significant multiplexed into the same B-component instance. This option provides
savings in terms of PWs to be maintained in the WAN. significant savings in terms of PWs to be maintained in the WAN.
The I-ESI concept described in section 4.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- * Attempts to set up a PW between the two GWs within the B-component
component context will never be blocked. context will never be blocked.
o If a PW exists between two GWs for the B-component and an * If a PW exists between two GWs for the B-component and an attempt
attempt is made to setup an EVPN binding on an I-component linked is made to set up an EVPN binding on an I-component linked to that
to that B-component, the EVPN binding will be kept operationally B-component, the EVPN binding will be kept down operationally.
down. Note that the BGP EVPN routes will still be valid but not 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 * 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 3.5 can also be The optimization 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. Multihoming Procedures on the GWs
This model supports single-active multi-homing on the GWs. All-active This model supports single-active multihoming on the GWs. All-active
multi-homing is not supported by this scenario. multihoming is not supported by this scenario.
The single-active multi-homing procedures as described by [EVPN- The single-active multihoming procedures as described by [RFC8365]
Overlays] will be followed for the I-ES for each EVI instance will be followed for the I-ES for each EVI instance connected to the
connected to the B-component. Note that in this case, for a given B-component. Note that in this case, for a given EVI, all the EVPN
EVI, all the EVPN bindings in the I-component are assigned to the I- bindings in the I-component are assigned to the I-ES. The non-DF GW
ES. The non-DF GW for the I-ES will block the transmission and for the I-ES will block the transmission and reception of all the
reception of all the I-component EVPN bindings for BUM and unicast I-component EVPN bindings for BUM and unicast traffic. When learning
traffic. When learning MACs from the WAN, the non-DF MUST NOT MACs from the WAN, the non-DF MUST NOT advertise EVPN MAC/IP routes
advertise EVPN MAC/IP routes for those MACs. 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 (referred to as "EVPN-MPLS" hereafter) are
WAN, an end-to-end EVPN solution can be deployed. The following supported in the WAN, an end-to-end EVPN solution can be deployed.
sections describe the proposed solution as well as the impact The following sections describe the proposed solution as well as its
required on the [RFC7432] procedures. impact on the procedures from [RFC7432].
4.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
setup one BGP EVPN session to the DC RR (or two BGP EVPN sessions if will set up one BGP EVPN session to the DC RR (or two BGP EVPN
there are redundant DC RRs) and one session to the WAN RR (or two sessions if there are redundant DC RRs) and one session to the WAN RR
sessions if there are redundant WAN RRs). (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 [TUNNEL-ENCAP] BGP encapsulation extended community with a a [RFC9012] BGP encapsulation extended community with a different
different tunnel type than the one sent to the WAN RRs. tunnel type than the one sent to the WAN RRs.
As in the other discussed options, an I-ES and its assigned I-ESI As in the other discussed options, an I-ES and its assigned I-ESI
will be configured on the GWs for multi-homing. This I-ES represents will be configured on the GWs for multihoming. This I-ES represents
the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to
the WAN. Optionally, different I-ESI values are configured for the WAN. Optionally, different I-ESI values are configured for
representing the WAN and the DC. If different EVPN-Overlay networks representing the WAN and the DC. If different EVPN-Overlay networks
are connected to the same group of GWs, each EVPN-Overlay network are connected to the same group of GWs, each EVPN-Overlay network
MUST get assigned a different I-ESI. 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 instead
and re-advertised (if needed): will be consumed and re-advertised (if needed):
o Ethernet A-D routes, ES routes and Inclusive Multicast routes * Ethernet A-D routes, ES routes, and Inclusive Multicast routes are
are consumed by the GWs and processed locally for the consumed by the GWs and processed locally for the corresponding
corresponding [RFC7432] procedures. [RFC7432] procedures.
o MAC/IP advertisement routes will be received, imported and if * MAC/IP advertisement routes will be received and 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-
advertised as new routes with the following fields: advertised as new routes with the following fields:
+ The RD will be the GW's RD for the MAC-VRF. - The RD will be the GW's RD for the MAC-VRF.
+ The ESI will be set to the I-ESI. - The ESI will be set to the I-ESI.
+ The Ethernet-tag value will be kept from the received NLRI. - The Ethernet-tag value will be kept from the received NLRI 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 for WAN) or a DC-global 24-bit value (when sent to the DC for
encapsulations using a VNI). encapsulations using a VNI).
+ The appropriate Route-Targets (RTs) and [TUNNEL-ENCAP] BGP - The appropriate Route Targets (RTs) and [RFC9012] BGP
Encapsulation extended community will be used according to encapsulation extended community will be used according to
[EVPN-Overlays]. [RFC8365].
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 [RFC9012]
ENCAP] BGP Encapsulation extended community values: BGP encapsulation extended community values:
o ES route(s) for the I-ESI(s). * ES route(s) for the I-ESI(s).
o Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D * Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D per-
per-EVI routes sent to the WAN and the DC will have consistent 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 * Inclusive Multicast routes with independent tunnel-type value for
for the WAN and DC. E.g. a P2MP LSP may be used in the WAN the WAN and DC. For example, a P2MP Label Switched Path (LSP) may
whereas ingress replication may be used in the DC. The routes be used in the WAN, whereas ingress replication may be used in the
sent to the WAN and the DC will have a consistent Ethernet-Tag. DC. The routes sent to the WAN and the DC will have a consistent
Ethernet-Tag.
o MAC/IP advertisement routes for MAC addresses learned in local * 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 multihomed Ethernet
Ethernet Segments (ES). The routes sent to the WAN and the DC Segments (ES). The routes sent to the WAN and the DC will have a
will have a consistent Ethernet-Tag. 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 the above local service routes: Set-DC will be generate two sets of the above local service routes: set-DC will be
sent to the DC RRs and will include A-D per EVI, Inclusive Multicast sent to the DC RRs and will include an A-D per EVI, Inclusive
and MAC/IP routes for the DC encapsulation and RT. Set-WAN will be Multicast, and MAC/IP routes for the DC encapsulation and RT. Set-
sent to the WAN RRs and will include the same routes but using the WAN will be sent to the WAN RRs and will include the same routes but
WAN RT and encapsulation. GW1 and GW2 will receive each other's set- using the WAN RT and encapsulation. GW1 and GW2 will receive each
DC and set-WAN. This is the expected behavior on GW1 and GW2 for other's set-DC and set-WAN. This is the expected behavior on GW1 and
locally generated routes: GW2 for locally generated routes:
o Inclusive multicast routes: when setting up the flooding lists * Inclusive multicast routes: When setting up the flooding lists for
for a given MAC-VRF, each GW will include its DC peer GW only in a given MAC-VRF, each GW will include its DC peer GW only in the
the EVPN-MPLS flooding list (by default) and not the EVPN- EVPN-MPLS flooding list (by default) and not the EVPN-Overlay
Overlay flooding list. That is, GW2 will import two Inclusive flooding list. That is, GW2 will import two Inclusive Multicast
Multicast routes from GW1 (from set-DC and set-WAN) but will routes from GW1 (from set-DC and set-WAN) but will only consider
only consider one of the two, having the set-WAN route higher one of the two, giving the set-WAN route higher priority. An
priority. An administrative option MAY change this preference so administrative option MAY change this preference so that the set-
that the set-DC route is selected first. DC route is selected first.
o MAC/IP advertisement routes for local attachment circuits: as * 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, giving the route from the set-
set-WAN a higher priority. As with the Inclusive multicast WAN a higher priority. As with the Inclusive multicast routes, an
routes, an administrative option MAY change this priority. administrative option MAY change this priority.
4.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),
only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN- since only one EVPN binding per EVI (or per Ethernet Tag in the case
aware bundle services) will be setup in the data plane between the of VLAN-aware bundle services) will be set up in the data plane
two nodes. That binding will by default be added to the EVPN-MPLS between the two nodes. That binding will by default be added to the
flooding list. EVPN-MPLS 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
one of the two flooding lists that each GW sets up for the same MAC- one of the two flooding lists that each GW sets up for the same MAC-
VRF: VRF:
o EVPN-overlay flooding list (composed of bindings to the remote * EVPN-Overlay flooding list (composed of bindings to the remote
NVEs or multicast tunnel to the NVEs). NVEs or multicast tunnel to the NVEs).
o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the * EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the
remote PEs) remote PEs).
Each flooding list will be part of a separate split-horizon-group: Each flooding list will be part of a separate split-horizon group:
the WAN split-horizon-group or the DC split-horizon-group. Traffic the WAN split-horizon group or the DC split-horizon group. Traffic
generated from a local AC can be flooded to both generated from a local AC can be flooded to both split-horizon
split-horizon-groups. Traffic from a binding of a split-horizon-group groups. Traffic from a binding of a split-horizon group can be
can be flooded to the other split-horizon-group and local ACs, but flooded to the other split-horizon group and local ACs, but never to
never to a member of its own split-horizon-group. 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 receives 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 nonzero
zero ESI). ESI).
4.4.3. Multi-homing procedure extensions on the GWs 4.4.3. Multihoming 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 multihoming.
All the [RFC7432] multi-homing procedures for the DF election on I- All the [RFC7432] multihoming procedures for the DF election on
ES(s) as well as the backup-path (single-active) and aliasing (all- I-ES(s), as well as the backup-path (single-active) and aliasing
active) procedures will be followed on the GWs. Remote PEs in the (all-active) procedures, will be followed on the GWs. Remote PEs in
EVPN-MPLS network will follow regular [RFC7432] aliasing or backup- the EVPN-MPLS network will follow regular [RFC7432] aliasing or
path procedures for MAC/IP routes received from the GWs for the same backup-path procedures for MAC/IP routes received from the GWs for
I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes the same I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP
received with the same I-ESI. routes 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] multihomed 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 * Single-active multihoming; 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-ES. The EVPN-MPLS network is considered to associated to the I-ES. The EVPN-MPLS network is considered to
be the core network and the EVPN-MPLS bindings to the remote be the core network, and the EVPN-MPLS bindings to the 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 its 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-ES,
ES, the DF GW SHOULD add the I-ESI label when forwarding to the DF GW SHOULD add the I-ESI label when forwarding to the
the peer GW over EVPN-MPLS. 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
MUST NOT re-originate the EVPN routes and advertise them to NOT reoriginate the EVPN routes and advertise them to the DC
the DC peers. In the same way, EVPN MAC/IP routes received peers. In the same way, EVPN MAC/IP routes received from the
from the DC MUST NOT be advertised to the WAN peers. This is DC MUST NOT be advertised to the WAN peers. This is consistent
consistent with [RFC7432] and allows the remote PE/NVEs know with [RFC7432] and allows the remote PE/NVEs to know who the
who the primary GW is, based on the reception of the MAC/IP primary GW is, based on the reception of the MAC/IP routes.
routes.
o All-active multi-homing; assuming a WAN split-horizon-group * All-active multihoming; 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 follows the same - Forwarding behavior on the non-DF: The non-DF follows the same
behavior as the non-DF in the single-active case but only for behavior as the non-DF in the single-active case, but only for
BUM traffic. Unicast traffic received from a split-horizon- BUM traffic. Unicast traffic received from a split-horizon
group MUST NOT be forwarded to a member of its own split- group MUST NOT be forwarded to a member of its own split-
horizon-group but can be forwarded normally to the other horizon group but can be forwarded normally to the other split-
split-horizon-groups and local ACs. If a known unicast packet horizon groups and local ACs. If a known unicast packet is
is identified as a "flooded" packet, the procedures for BUM identified as a "flooded" packet, the procedures for BUM
traffic MUST be followed. traffic MUST be followed.
+ Forwarding behavior on the DF: the DF follows the same - Forwarding behavior on the DF: The DF follows the same behavior
behavior as the DF in the single-active case but only for BUM as the DF in the single-active case, but only for BUM traffic.
traffic. Unicast traffic received from a split-horizon-group Unicast traffic received from a split-horizon group MUST NOT be
MUST NOT be forwarded to a member of its own split-horizon- forwarded to a member of its own split-horizon group but can be
group but can be forwarded normally to the other split- forwarded normally to the other split-horizon group and local
horizon-group and local ACs. If a known unicast packet is ACs. If a known unicast packet is identified as a "flooded"
identified as a "flooded" packet, the procedures for BUM packet, the procedures for BUM traffic MUST be followed. As
traffic MUST be followed. As per [RFC7432] and for split- per [RFC7432] and for split-horizon purposes, when receiving
horizon purposes, when receiving BUM traffic on the EVPN- BUM traffic on the EVPN-Overlay bindings associated to an I-ES,
Overlay bindings associated to an I-ES, the DF GW MUST add the the DF GW MUST add the I-ESI label when forwarding to the peer
I-ESI label when forwarding to the peer GW over EVPN-MPLS. GW over EVPN-MPLS.
+ Contrary to the single-active multi-homing case, both DF and - Contrary to the single-active multihoming case, both DF and
non-DF re-originate and advertise MAC/IP routes received from non-DF reoriginate 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 multihoming GWs.
|<--EVPN-Overlay--->|<--EVPN-MPLS-->| |<--EVPN-Overlay--->|<--EVPN-MPLS-->|
+---------+ +--------------+ +---------+ +--------------+
+----+ BUM +---+ | +----+ BUM +---+ |
|NVE1+----+----> | +-+-----+ | |NVE1+----+----> | +-+-----+ |
+----+ | | DF |GW1| | | | +----+ | | DF |GW1| | | |
| | +-+-+ | | ++--+ | | +-+-+ | | ++--+
| | | | +--> |PE1| | | | | +--> |PE1|
| +--->X +-+-+ | ++--+ | +--->X +-+-+ | ++--+
| NDF| | | | | NDF| | | |
+----+ | |GW2<-+ | +----+ | |GW2<-+ |
|NVE2+--+ +-+-+ | |NVE2+--+ +-+-+ |
+----+ +--------+ | +------------+ +----+ +--------+ | +------------+
v v
+--+ +--+
|CE| |CE|
+--+ +--+
Figure 3 Multi-homing BUM forwarding Figure 3: Multihoming BUM Forwarding
GW2 is the non-DF for the I-ES 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. Packets sent to GW2 the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2
will include the ESI-label for the I-ES. Based on the ESI-label, GW2 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 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 forward them to local ACs (CE in the example) and not back to the
EVPN-Overlay network. 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-ES, 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) will the MAC 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
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 3.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 multihoming, 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 multihoming, 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.
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
destination M1. If the Unknown MAC Route had not been M1. If the Unknown MAC Route had not been advertised into the
advertised into the DC, NVE1 would have flooded the packet DC, NVE1 would have flooded the packet throughout the DC, in
throughout the DC, in particular to both GW1 and GW2. If the particular to both GW1 and GW2. If the same VNI/VSID is used
same VNI/VSID is used for both known unicast and BUM traffic, for both known unicast and BUM traffic, as is typically the
as is typically the case, there is no indication in the packet case, there is no indication in the packet that it is a BUM
that it is a BUM packet and both GW1 and GW2 would have packet, and both GW1 and GW2 would have forwarded it, creating
forwarded it, creating packet duplication. However, because the packet duplication. However, because the Unknown MAC Route had
Unknown MAC Route had been advertised into the DC, NVE1 will been advertised into the DC, NVE1 will unicast the packet to
unicast the packet to either GW1 or GW2. 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
will forward it to either GW3 or GW4. 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
The [EVPN-Overlays] "DCI using ASBRs" solution and the GW solution The "DCI using ASBRs" solution described in [RFC8365] and the GW
with EVPN-MPLS Interconnect may be seen similar since they both solution with EVPN-MPLS Interconnect may be seen as similar, since
retain the EVPN attributes between Data Centers and throughout the they both retain the EVPN attributes between Data Centers and
WAN. However the EVPN-MPLS Interconnect solution on the GWs has throughout the WAN. However, the EVPN-MPLS Interconnect solution on
significant benefits compared to the "DCI using ASBRs" solution: the GWs has significant benefits compared to the "DCI using ASBRs"
solution:
o As in any of the described GW models, this solution supports the * As in any of the described GW models, this solution supports the
connectivity of local attachment circuits on the GWs. This is connectivity of local attachment circuits on the GWs. This is not
not possible in a "DCI using ASBRs" solution. possible in a "DCI using ASBRs" solution.
o Different data plane encapsulations can be supported in the DC * Different data plane encapsulations can be supported in the DC and
and the WAN, while a uniform encapsulation is needed in the "DCI the WAN, while a uniform encapsulation is needed in the "DCI using
using ASBRs" solution. ASBRs" solution.
o Optimized multicast solution, with independent inclusive * Optimized multicast solution, with independent inclusive multicast
multicast trees in DC and WAN. trees in DC and WAN.
o MPLS Label aggregation: for the case where MPLS labels are * MPLS label aggregation: For the case where MPLS labels are
signaled from the NVEs for MAC/IP Advertisement routes, this signaled from the NVEs for MAC/IP advertisement routes, this
solution provides label aggregation. A remote PE MAY receive a solution provides label aggregation. A remote PE MAY receive a
single label per GW MAC-VRF as opposed to a label per NVE/MAC- single label per GW MAC-VRF, as opposed to a label per NVE/MAC-VRF
VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE connected to the GW MAC-VRF. For instance, in Figure 2, PE would
would receive only one label for all the routes advertised for a receive only one label for all the routes advertised for a given
given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF. 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 * The GW will not propagate MAC Mobility for the MACs moving within
within a DC. Mobility intra-DC is solved by all the NVEs in the a DC. Mobility intra-DC is solved by all the NVEs in the DC. The
DC. The MAC Mobility procedures on the GWs are only required in MAC Mobility procedures on the GWs are only required in case of
case of mobility across DCs. mobility across DCs.
o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce * 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 the WAN.
4.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.
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 customer
no longer learned in the data plane on the GW but in the control MACs (C-MACs) are no longer learned in the data plane on the GW but
plane through EVPN running on the I-component. Remote C-MACs coming in the control plane through EVPN running on the I-component. Remote
from remote PEs are still learned in the data plane. B-MACs in the B- C-MACs coming from remote PEs are still learned in the data plane.
component will be assigned and advertised following the procedures B-MACs in the B-component will be assigned and advertised following
described in [RFC7623]. the procedures described in [RFC7623].
An I-ES will be configured on the GWs for multi-homing, but its I-ESI An I-ES will be configured on the GWs for multihoming, but its I-ESI
will only be used in the EVPN control plane for the I-component EVI. will 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- No unreserved ESIs will be used in the control plane of the
component EVI as per [RFC7623], that is, the I-ES will be represented B-component EVI, as per [RFC7623]. That is, the I-ES will be
to the WAN PBB-EVPN PEs using shared or dedicated B-MACs. 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
component EVPN-overlay binding will be kept down following the rules I-component EVPN-Overlay binding will be kept down following the
described in section 4.3.1. rules described in Section 4.3.1.
4.5.2. Multi-homing procedures on the GWs 4.5.2. Multihoming 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 multihoming.
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, substituting the WAN
split-horizon-group" for the B-component, and using [RFC7623] split-horizon group for the B-component, and using [RFC7623]
procedures for the traffic sent or received on the B-component. 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 the perspective of Mobility
the related procedures described in [RFC7432], the C-MACs learned and the related procedures described in [RFC7432], the C-MACs learned
from the B-component are considered local. from the B-component are considered local.
4.5.4. Gateway optimizations 4.5.4. Gateway Optimizations
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
is required, an end-to-end EVPN solution can be deployed. While function is required, an end-to-end EVPN solution can be deployed.
multiple Overlay tunnel combinations at the WAN and the DC are While multiple Overlay tunnel combinations at the WAN and the DC are
possible (MPLSoGRE, nvGRE, etc.), VXLAN is described here, given its possible (MPLSoGRE, NVGRE, etc.), VXLAN is described here, given its
popularity in the industry. This section focuses on the specific case popularity in the industry. This section focuses on the specific
of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the
[RFC7432] procedures. [RFC7432] procedures.
The procedures described in section 4.4 apply to this section too, The procedures described in Section 4.4 apply to this section, too,
only replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and only substituting EVPN-MPLS for EVPN-VXLAN control plane specifics
using [EVPN-Overlays] "Local Bias" procedures instead of section and using [RFC8365] "Local Bias" procedures instead of Section 4.4.3.
4.4.3. Since there are no ESI-labels in VXLAN, GWs need to rely on Since there are no ESI labels in VXLAN, GWs need to rely on "Local
"Local Bias" to apply split-horizon on packets generated from the I- Bias" to apply split horizon on packets generated from the I-ES and
ES and sent to the peer GW. 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
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
in which local downstream assigned VNIs or VSIDs can be used (like case in which local downstream-assigned VNIs or VSIDs can be used
MPLS labels) is described by [EVPN-Overlays]. (like MPLS labels) is described by [RFC8365].
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:
a) Globally unique VNIs in the Interconnect network: 1. Globally unique VNIs in the Interconnect network. In this case,
In this case, the GWs and PEs in the Interconnect network will the GWs and PEs in the Interconnect network will agree on a
agree on a common VNI for a given EVI. The RT to be used in the common VNI for a given EVI. The RT to be used in the
Interconnect network can be auto-derived from the agreed Interconnect network can be autoderived from the agreed-upon
Interconnect VNI. The VNI used inside each DC MAY be the same Interconnect VNI. The VNI used inside each DC MAY be the same as
as the Interconnect VNI. the Interconnect VNI.
b) Downstream assigned VNIs in the Interconnect network. 2. Downstream-assigned VNIs in the Interconnect network. In this
In this case, the GWs and PEs MUST use the proper RTs to case, the GWs and PEs MUST use the proper RTs to import/export
import/export the EVPN routes. Note that even if the VNI is the EVPN routes. Note that even if the VNI is downstream
downstream assigned in the Interconnect network, and unlike assigned in the Interconnect network, and unlike option (a), it
option (a), it only identifies the <Ethernet Tag, GW> pair and only identifies the <Ethernet Tag, GW> pair and not the <Ethernet
not the <Ethernet Tag, egress PE> pair. The VNI used inside Tag, egress PE> pair. The VNI used inside each DC MAY be the
each DC MAY be the same as the Interconnect VNI. GWs SHOULD same as the Interconnect VNI. GWs SHOULD support multiple VNI
support multiple VNI spaces per EVI (one per Interconnect spaces per EVI (one per Interconnect network they are connected
network they are connected to). to).
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.
4.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,
10 to VNI-100 when the packet is received from NVO-1 and the reverse VNI-10 to VNI-100 when the packet is received from NVO-1 and the
mapping from VNI-100 to VNI-10 when the packet is received from the reverse mapping from VNI-100 to VNI-10 when the packet is received
remote NVO-2 network and needs to be forwarded to NVO-1. from the remote NVO-2 network and needs to be forwarded to NVO-1.
The procedures described in section 4.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.
4.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
MUST be translated as in section 4.6.1. However, in this case, there VNIs MUST be translated as in Section 4.6.1. However, in this case,
is no need to translate to a common Interconnect VNI on the GWs. Each there is no need to translate to a common Interconnect VNI on the
GW can translate the VNI received in an EVPN update to a locally GWs. Each GW can translate the VNI received in an EVPN update to a
assigned VNI advertised to the Interconnect network. Each GW can use locally assigned VNI advertised to the Interconnect network. Each GW
a different Interconnect VNI, hence this VNI does not need to be can use a different Interconnect VNI; hence, this VNI does not need
agreed on all the GWs and PEs of the Interconnect network. to be agreed upon on all the GWs and PEs of the Interconnect network.
The procedures described in section 4.4 will be followed, taking the The procedures described in Section 4.4 will be followed, taking into
considerations above for the VNI translation. account the considerations above for the VNI translation.
5. Security Considerations 5. Security Considerations
This document applies existing specifications to a number of This document applies existing specifications to a number of
Interconnect models. The Security Considerations included in those Interconnect models. The security considerations included in those
documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761] documents, such as [RFC7432], [RFC8365], [RFC7623], [RFC4761], and
and [RFC4762] apply to this document whenever those technologies are [RFC4762] apply to this document whenever those technologies are
used. used.
As discussed, [EVPN-Overlays] discusses two main DCI solution groups: As discussed, [RFC8365] discusses two main DCI solution groups: "DCI
"DCI using GWs" and "DCI using ASBRs". This document specifies the using GWs" and "DCI using ASBRs". This document specifies the
solutions that correspond to the "DCI using GWs" group. It is solutions that correspond to the "DCI using GWs" group. It is
important to note that the use of GWs provide a superior level of important to note that the use of GWs provides a superior level of
security on a per tenant basis, compared to the use of ASBRs. This is security on a per-tenant basis, compared to the use of ASBRs. This
due to the fact that GWs need to perform a MAC lookup on the frames is due to the fact that GWs need to perform a MAC lookup on the
being received from the WAN, and they apply security procedures, such frames being received from the WAN, and they apply security
as filtering of undesired frames, filtering of frames with a source procedures, such as filtering of undesired frames, filtering of
MAC that matches a protected MAC in the DC or application of MAC frames with a source MAC that matches a protected MAC in the DC, or
duplication procedures defined in [RFC7432]. On ASBRs though, traffic application of MAC-duplication procedures defined in [RFC7432]. On
is forwarded based on a label or VNI swap and there is usually no ASBRs, though, traffic is forwarded based on a label or VNI swap, and
visibility of the encapsulated frames, which can carry malicious there is usually no visibility of the encapsulated frames, which can
traffic. carry malicious traffic.
In addition, the GW optimizations specified in this document, provide In addition, the GW optimizations specified in this document provide
additional protection of the DC Tenant Systems. For instance, the MAC additional protection of the DC tenant systems. For instance, the
address advertisement control and Unknown MAC Route defined in MAC-address advertisement control and Unknown MAC Route defined in
section 3.5.1 protect the DC NVEs from being overwhelmed with an 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. excessive number of MAC/IP routes being learned on the GWs from the
The ARP/ND flooding control described in 3.5.2 can reduce/suppress WAN. The ARP/ND flooding control described in Section 3.5.2 can
broadcast storms being injected from the WAN. reduce/suppress broadcast storms being injected from the WAN.
Finally, the reader should be aware of the potential security Finally, the reader should be aware of the potential security
implications of designing a DCI with the Decoupled Interconnect implications of designing a DCI with the Decoupled Interconnect
solution (section 3) or the Integrated Interconnect solution (section solution (Section 3) or the Integrated Interconnect solution
4). In the Decoupled Interconnect solution the DC is typically easier (Section 4). In the Decoupled Interconnect solution, the DC is
to protect from the WAN, since each GW has a single logical link to typically easier to protect from the WAN, since each GW has a single
one WAN PE, whereas in the Integrated solution, the GW has logical logical link to one WAN PE, whereas in the Integrated solution, the
links to all the WAN PEs that are attached to the tenant. In either GW has logical links to all the WAN PEs that are attached to the
model, proper control plane and data plane policies should be put in tenant. In either model, proper control plane and data plane
place in the GWs in order to protect the DC from potential attacks policies should be put in place in the GWs in order to protect the DC
coming from the WAN. from potential attacks coming from the WAN.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", LAN Service (VPLS) Using BGP for Auto-Discovery and
RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc- Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
editor.org/info/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>. <https://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
Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January Virtual Private Networks (L2VPNs)", RFC 6074,
2011, <http://www.rfc-editor.org/info/rfc6074>. DOI 10.17487/RFC6074, January 2011,
<https://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)
(PE) Model for Provider Backbone Bridging", RFC 7041, DOI Provider Edge (PE) Model for Provider Backbone Bridging",
10.17487/RFC7041, November 2013, <http://www.rfc- RFC 7041, DOI 10.17487/RFC7041, November 2013,
editor.org/info/rfc7041>. <https://www.rfc-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
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
editor.org/info/rfc7432>. 2015, <https://www.rfc-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,
1997, <http://www.rfc-editor.org/info/rfc2119>. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
<http://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress, "The BGP Tunnel Encapsulation Attribute", RFC 9012,
January 11, 2018. DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc- Henderickx, "Provider Backbone Bridging Combined with
editor.org/info/rfc7623>. Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt, Uttaro, J., and W. Henderickx, "A Network Virtualization
work in progress, January 2018. Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong,
"Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI "Covering Prefixes Outbound Route Filter for BGP-4",
10.17487/RFC7543, May 2015, <https://www.rfc- RFC 7543, DOI 10.17487/RFC7543, May 2015,
editor.org/info/rfc7543>. <https://www.rfc-editor.org/info/rfc7543>.
7.2. Informative References 7.2. Informative References
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route Distribution for R., Patel, K., and J. Guichard, "Constrained Route
Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Distribution for Border Gateway Protocol/MultiProtocol
Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
DOI 10.17487/RFC4684, November 2006, <http://www.rfc- Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
editor.org/info/rfc4684>. November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
Local Area Network (VXLAN): A Framework for Overlaying Virtualized eXtensible Local Area Network (VXLAN): A Framework for
Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI Overlaying Virtualized Layer 2 Networks over Layer 3
10.17487/RFC7348, August 2014, <http://www.rfc- Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Generic Routing Encapsulation", RFC 7637, September, 2015 Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", "Encapsulating MPLS in IP or Generic Routing Encapsulation
RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc- (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
editor.org/info/rfc4023>. <https://www.rfc-editor.org/info/rfc4023>.
[Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms [Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based
for Ethernet based networks", July 2011. networks", ITU-T Recommendation Y.1731, August 2019.
[802.1AG] IEEE 802.1AG_2007, "IEEE Standard for Local and [IEEE.802.1AG]
Metropolitan Area Networks - Virtual Bridged Local Area Networks IEEE, "IEEE Standard for Local and Metropolitan Area
Amendment 5: Connectivity Fault Management", January 2008. Networks Virtual Bridged Local Area Networks Amendment 5:
Connectivity Fault Management", IEEE standard 802.1ag-
2007, January 2008.
[802.1Q-2014] IEEE 802.1Q-2014, "IEEE Standard for Local and [IEEE.802.1Q]
metropolitan area networks--Bridges and Bridged Networks", December IEEE, "IEEE Standard for Local and metropolitan area
2014. networks--Bridges and Bridged Networks", IEEE standard
802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December
2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
[RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, Preferential Forwarding Status Bit", RFC 6870,
February 2013, <http://www.rfc-editor.org/info/rfc6870>. DOI 10.17487/RFC6870, February 2013,
<https://www.rfc-editor.org/info/rfc6870>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, Label Switching Architecture", RFC 3031,
January 2001, <http://www.rfc-editor.org/info/rfc3031>. DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[VIRTUAL-ES] Sajassi et al., "EVPN Virtual Ethernet Segment", draft- [VIRTUAL-ES]
sajassi-bess-evpn-virtual-eth-segment-03, work in progress, February Sajassi, A., Brissette, P., Schell, R., Drake, J. E., and
2018. J. Rabadan, "EVPN Virtual Ethernet Segment", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
eth-segment-06, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-
eth-segment-06>.
8. Acknowledgments 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. We would also like Nagaraj for their valuable comments and feedback. We would also like
to thank Martin Vigoureux and Alvaro Retana for his detailed review to thank Martin Vigoureux and Alvaro Retana for their detailed
and comments. reviews and comments.
9. Contributors 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: coauthors have also contributed to this document:
Ravi Shekhar Ravi Shekhar
Juniper Networks
Anil Lohiya Anil Lohiya
Juniper Networks
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Florin Balus Florin Balus
Cisco
Patrice Brissette Patrice Brissette
Cisco Cisco
Senad Palislamovic Senad Palislamovic
Nokia Nokia
Dennis Cai Dennis Cai
Alibaba Alibaba
10. Authors' Addresses Authors' Addresses
Jorge Rabadan Jorge Rabadan (editor)
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043
United States of America
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
Wim Henderickx Wim Henderickx
Nokia Nokia
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
John Drake John Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 283 change blocks. 
814 lines changed or deleted 850 lines changed or added

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