diff options
Diffstat (limited to 'doc/rfc/rfc9014.txt')
| -rw-r--r-- | doc/rfc/rfc9014.txt | 1365 |
1 files changed, 1365 insertions, 0 deletions
diff --git a/doc/rfc/rfc9014.txt b/doc/rfc/rfc9014.txt new file mode 100644 index 0000000..c628fba --- /dev/null +++ b/doc/rfc/rfc9014.txt @@ -0,0 +1,1365 @@ + + + + +Internet Engineering Task Force (IETF) J. Rabadan, Ed. +Request for Comments: 9014 S. Sathappan +Category: Standards Track W. Henderickx +ISSN: 2070-1721 Nokia + A. Sajassi + Cisco + J. Drake + Juniper + May 2021 + + + Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks + +Abstract + + This document describes how Network Virtualization Overlays (NVOs) + can be connected to a Wide Area Network (WAN) in order to extend the + Layer 2 connectivity required for some tenants. The solution + analyzes the interaction between NVO networks running Ethernet + Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) + technologies used in the WAN, such as Virtual Private LAN Services + (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), + EVPN, or PBB-EVPN. It also describes how the existing technical + specifications apply to the interconnection and extends the EVPN + procedures needed in some cases. In particular, this document + describes how EVPN routes are processed on Gateways (GWs) that + interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the + Interconnect Ethernet Segment (I-ES), to provide multihoming. This + document also describes the use of the Unknown MAC Route (UMR) to + avoid issues of a Media Access Control (MAC) scale on Data Center + Network Virtualization Edge (NVE) devices. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (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. + + 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 (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions and Terminology + 3. Decoupled Interconnect Solution for EVPN-Overlay Networks + 3.1. Interconnect Requirements + 3.2. VLAN-Based Handoff + 3.3. PW-Based Handoff + 3.4. Multihoming Solution on the GWs + 3.5. Gateway Optimizations + 3.5.1. MAC Address Advertisement Control + 3.5.2. ARP/ND Flooding Control + 3.5.3. Handling Failures between GW and WAN Edge Routers + 4. Integrated Interconnect Solution for EVPN-Overlay Networks + 4.1. Interconnect Requirements + 4.2. VPLS Interconnect for EVPN-Overlay Networks + 4.2.1. Control/Data Plane Setup Procedures on the GWs + 4.2.2. Multihoming Procedures on the GWs + 4.3. PBB-VPLS Interconnect for EVPN-Overlay Networks + 4.3.1. Control/Data Plane Setup Procedures on the GWs + 4.3.2. Multihoming Procedures on the GWs + 4.4. EVPN-MPLS Interconnect for EVPN-Overlay Networks + 4.4.1. Control plane Setup Procedures on the GWs + 4.4.2. Data Plane Setup Procedures on the GWs + 4.4.3. Multihoming Procedure Extensions on the GWs + 4.4.4. Impact on MAC Mobility Procedures + 4.4.5. Gateway Optimizations + 4.4.6. Benefits of the EVPN-MPLS Interconnect Solution + 4.5. PBB-EVPN Interconnect for EVPN-Overlay Networks + 4.5.1. Control/Data Plane Setup Procedures on the GWs + 4.5.2. Multihoming Procedures on the GWs + 4.5.3. Impact on MAC Mobility Procedures + 4.5.4. Gateway Optimizations + 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay Networks + 4.6.1. Globally Unique VNIs in the Interconnect Network + 4.6.2. Downstream-Assigned VNIs in the Interconnect Network + 5. Security Considerations + 6. IANA Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgments + Contributors + Authors' Addresses + +1. Introduction + + [RFC8365] discusses the use of Ethernet Virtual Private Networks + (EVPNs) [RFC7432] as the control plane for Network Virtualization + Overlays (NVOs), 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 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. + + 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". + + The specified procedures are local to the redundant GWs connecting a + DC to the WAN. The document does not preclude any combination across + different DCs for the same tenant. For instance, a "Decoupled" + solution can be used in GW1 and GW2 (for DC1), and an "Integrated" + solution can be used in GW3 and GW4 (for DC2). + + While the Gateways and WAN Provider Edges (PEs) use existing + specifications in some cases, the document also defines extensions + that are specific to DCI. In particular, those extensions are: + + * 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]. + + * The use of the Unknown MAC Route (UMR) in a DCI scenario. + + * The processing of EVPN routes on Gateways with MAC-VRFs connecting + EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN- + Overlay networks. + +2. Conventions and Terminology + + 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. + + AC: Attachment Circuit + + ARP: Address Resolution Protocol + + BUM: Broadcast, Unknown Unicast and Multicast (traffic) + + CE: Customer Equipment + + CFM: Connectivity Fault Management + + DC: Data Center + + DCI: Data Center Interconnect + + DF: Designated Forwarder + + EVI: EVPN Instance + + EVPN: Ethernet Virtual Private Network, as in [RFC7432] + + 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. + + ES: Ethernet Segment + + ESI: Ethernet Segment Identifier + + GW: Gateway or Data Center Gateway + + 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. + + MAC Media Access Control + + MAC-VRF: refers to an EVI instance in a particular node + + MP2P and LSM tunnels: refer to multipoint-to-point and label + switched multicast tunnels + + ND: Neighbor Discovery + + NDF: Non-Designated Forwarder + + NVE: Network Virtualization Edge + + NVGRE: Network Virtualization using Generic Routing Encapsulation + + NVO: Network Virtualization Overlay + + OAM: Operations, Administration, and Maintenance + + PBB: Provider Backbone Bridging + + PE: Provider Edge + + PW: Pseudowire + + RD: Route Distinguisher + + RR: Route Reflector + + RT: Route Target + + S/C-TAG: refers to a combination of Service Tag and Customer Tag in + a 802.1Q frame + + TOR: Top-Of-Rack + + UMR: Unknown MAC Route + + vES: virtual Ethernet Segment + + VNI/VSID: refers to VXLAN/NVGRE virtual identifiers + + VPLS: Virtual Private LAN Service + + VSI: Virtual Switch Instance or VPLS instance in a particular PE + + VXLAN: Virtual eXtensible LAN + +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| + +--+ + | + +----+ + +----| PE |----+ + +---------+ | +----+ | +---------+ + +----+ | +---+ +----+ +----+ +---+ | +----+ + |NVE1|--| | | |WAN | |WAN | | | |--|NVE3| + +----+ | |GW1|--|Edge| |Edge|--|GW3| | +----+ + | +---+ +----+ +----+ +---+ | + | NVO-1 | | WAN | | NVO-2 | + | +---+ +----+ +----+ +---+ | + | | | |WAN | |WAN | | | | + +----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+ + |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| + +----+ +---------+ | | +---------+ +----+ + +--------------+ + + |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| + handoff handoff + + Figure 1: Decoupled Interconnect Model + + The following section describes the interconnect requirements for + this model. + +3.1. Interconnect Requirements + + The decoupled interconnect architecture is intended to be deployed in + networks where the EVPN-Overlay and WAN providers are different + entities and a clear demarcation is needed. This solution solves the + following requirements: + + * A simple connectivity handoff between the EVPN-Overlay network + provider and the WAN provider so that QoS and security enforcement + are easily accomplished. + + * Independence of the L2VPN technology deployed in the WAN. + + * Multihoming between GW and WAN Edge routers, including per-service + load balancing. Per-flow load balancing is not a strong + requirement, since a deterministic path per service is usually + required for an easy QoS and security enforcement. + + * Support of Ethernet OAM and Connectivity Fault Management (CFM) + [IEEE.802.1AG] [Y.1731] functions between the GW and the WAN Edge + router to detect individual AC failures. + + * Support for the following optimizations at the GW: + + - Flooding reduction of unknown unicast traffic sourced from the + DC Network Virtualization Edge (NVE) devices. + + - 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 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 + 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. + + This option provides the best possible demarcation between the DC and + WAN providers, and it does not require control plane interaction + between both providers. The disadvantage of this model is the + 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. + + In this model, the GW acts as a regular Network Virtualization Edge + (NVE) towards the DC. Its control plane, data plane procedures, and + interactions are described in [RFC8365]. + + 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 + [RFC4761], [RFC4762], [RFC6074], [RFC7432], and [RFC7623]. + +3.3. PW-Based Handoff + + 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 + handoff between both routers is based on FEC128-based PWs [RFC4762] + or FEC129-based PWs (for a greater level of network automation) + [RFC6074]. Note that this model still provides a clear demarcation + between DC and WAN (since there is a single PW between each MAC-VRF + and peer VSI), and security/QoS policies may be applied on a per-PW + basis. This model provides better scalability than a C-TAG-based + handoff and less provisioning overhead than a combined C/S-TAG + handoff. The PW-based handoff interconnect is illustrated in + Figure 1 (between the NVO-2 GWs and the WAN Edge routers). + + In this model, besides the usual MPLS procedures between GW and WAN + Edge router [RFC3031], the GW MUST support an interworking function + in each MAC-VRF that requires extension to the WAN: + + * If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI + (WAN Edge), the corresponding Virtual Connection Identifier (VCID) + MUST be provisioned on the MAC-VRF and match the VCID used in the + peer VSI at the WAN Edge router. + + * If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used + 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 + VPLS-ID used in the WAN Edge VSI. + + 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 are treated as service interfaces, defined in [RFC7432]. + +3.4. Multihoming Solution on the GWs + + EVPN single-active multihoming -- i.e., per-service load-balancing + multihoming -- is required in this type of interconnect. + + The GWs will be provisioned with a unique ES for each WAN + interconnect, and the handoff attachment circuits or PWs between the + GW and the WAN Edge router will be assigned an ESI for each such ES. + The ESI will be administratively configured on the GWs according to + the procedures in [RFC7432]. This I-ES will be referred to as "I-ES" + hereafter, and its identifier will be referred to as "I-ESI". + Different ESI types are described in [RFC7432]. The use of Type 0 + for the I-ESI is RECOMMENDED in this document. + + The solution (on the GWs) MUST follow the single-active multihoming + 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 DC NVEs for the multihoming functions, and ES routes will be + advertised so that ES discovery and Designated Forwarder (DF) + procedures can be followed. The MAC addresses learned (in the data + plane) on the handoff links will be advertised with the I-ESI encoded + in the ESI field. + +3.5. Gateway Optimizations + + The following GW features are optional and optimize the control plane + and data plane in the DC. + +3.5.1. MAC Address Advertisement Control + + The use of EVPN in NVO networks brings a significant number of + benefits, as described in [RFC8365]. However, if multiple DCs are + interconnected into a single EVI, each DC will have to import all of + the MAC addresses from each of the other DCs. + + Even if optimized BGP techniques like RT constraint [RFC4684] are + 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 + that DC, particularly when the NVEs reside in the hypervisors. + + The solution specified in this document uses the Unknown MAC Route + (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 + 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-ESI. + + An NVE within that DC that understands and processes the UMR will + send unknown unicast frames to one of the DC's GWs, which will then + forward that packet to the correct egress PE. Note that, because the + ESI is set to the DC GW's I-ESI, all-active multihoming can be + applied to unknown unicast MAC addresses. An NVE that does not + understand the Unknown MAC Route will handle unknown unicast as + described in [RFC7432]. + + This document proposes that local policy determine whether MAC + addresses and/or the UMR are advertised into a given DC. As an + example, when all the DC MAC addresses are learned in the control/ + management plane, it may be appropriate to advertise only the UMR. + Advertising all the DC MAC addresses in the control/management plane + is usually the case when the NVEs reside in hypervisors. Refer to + [RFC8365], Section 7. + + 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-spoke) does not necessarily learn all the MAC addresses pertaining + to hosts in other V-spokes of the same network. The communication + between two V-spokes is done through the Default MAC Gateway (DMG) + until the V-spokes learn each other's MAC addresses. In this + document, two leaf switches in the same DC are recommended for + V-spokes to learn each other's MAC addresses for the same EVI. The + leaf-to-leaf communication is always direct and does not go through + the GW. + +3.5.2. ARP/ND Flooding Control + + Another optimization mechanism, naturally provided by EVPN in the + GWs, is the Proxy ARP/ND function. The GWs should build a Proxy ARP/ + ND cache table, as per [RFC7432]. When the active GW receives an + ARP/ND request/solicitation coming from the WAN, the GW does a Proxy + ARP/ND table lookup and replies as long as the information is + available in its table. + + This mechanism is especially recommended on the GWs, since it + protects the DC network from external ARP/ND-flooding storms. + +3.5.3. Handling Failures between GW and WAN Edge Routers + + Link/PE failures are handled on the GWs as specified in [RFC7432]. + The GW detecting the failure will withdraw the EVPN routes, as per + [RFC7432]. + + Individual AC/PW failures may be detected by OAM mechanisms. For + instance: + + * If the interconnect solution is based on a VLAN handoff, Ethernet- + CFM [IEEE.802.1AG] [Y.1731] may be used to detect individual AC + failures on both the GW and WAN Edge router. An individual AC + failure will trigger the withdrawal of the corresponding A-D per + EVI route as well as the MACs learned on that AC. + + * If the interconnect solution is based on a PW handoff, the Label + Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be + used to detect individual PW failures on both the GW and WAN Edge + router. + +4. Integrated Interconnect Solution for EVPN-Overlay Networks + + When the DC and the WAN are operated by the same administrative + entity, the Service Provider can decide to integrate the GW and WAN + Edge PE functions in the same router for obvious reasons to save as + relates to Capital Expenditure (CAPEX) and Operating Expenses (OPEX). + This is illustrated in Figure 2. Note that this model does not + provide an explicit demarcation link between DC and WAN anymore. + Although not shown in Figure 2, note that the GWs may have local ACs. + + +--+ + |CE| + +--+ + | + +----+ + +----| PE |----+ + +---------+ | +----+ | +---------+ + +----+ | +---+ +---+ | +----+ + |NVE1|--| | | | | |--|NVE3| + +----+ | |GW1| |GW3| | +----+ + | +---+ +---+ | + | NVO-1 | WAN | NVO-2 | + | +---+ +---+ | + | | | | | | + +----+ | |GW2| |GW4| | +----+ + |NVE2|--| +---+ +---+ |--|NVE4| + +----+ +---------+ | | +---------+ +----+ + +--------------+ + + |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->| + |<--PBB-VPLS-->| + Interconnect -> |<-EVPN-MPLS-->| + options |<--EVPN-Ovl-->|* + |<--PBB-EVPN-->| + + * EVPN-Ovl stands for EVPN-Overlay (and it's an interconnect option). + + Figure 2: Integrated Interconnect Model + +4.1. Interconnect Requirements + + The integrated interconnect solution meets the following + requirements: + + * Control plane and data plane interworking between the EVPN-Overlay + network and the L2VPN technology supported in the WAN, + irrespective of the technology choice -- i.e., (PBB-)VPLS or + (PBB-)EVPN, as depicted in Figure 2. + + * Multihoming, including single-active multihoming with per-service + load balancing or all-active multihoming -- i.e., per-flow load- + balancing -- as long as the technology deployed in the WAN + supports it. + + * Support for end-to-end MAC Mobility, Static MAC protection and + other procedures (e.g., proxy-arp) described in [RFC7432] as long + as EVPN-MPLS is the technology of choice in the WAN. + + * Independent inclusive multicast trees in the WAN and in the DC. + That is, the inclusive multicast tree type defined in the WAN does + not need to be the same as in the DC. + +4.2. VPLS Interconnect for EVPN-Overlay Networks + +4.2.1. Control/Data Plane Setup Procedures on the GWs + + Regular MPLS tunnels and Targeted LDP (tLDP) / BGP sessions will be + set up to the WAN PEs and RRs as per [RFC4761], [RFC4762], and + [RFC6074], and overlay tunnels and EVPN will be set up as per + [RFC8365]. Note that different route targets for the DC and the WAN + are normally required (unless [RFC4762] is used in the WAN, in which + case no WAN route target is needed). A single type-1 RD per service + may be used. + + In order to support multihoming, the GWs will be provisioned with an + I-ESI (see Section 3.4), which will be unique for each + interconnection. In this case, the I-ES will represent the group of + PWs to the WAN PEs and GWs. All the [RFC7432] procedures are still + followed for the I-ES -- e.g., any MAC address learned from the WAN + will be advertised to the DC with the I-ESI in the ESI field. + + 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 + split-horizon groups: + + * VPLS PWs will be instantiated in the WAN split-horizon group. + + * Overlay tunnel bindings (e.g., VXLAN, NVGRE) will be instantiated + in the DC split-horizon group. + + 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 + split-horizon groups. + + Traffic received in a given split-horizon group will never be + forwarded to a member of the same split-horizon group. + + As far as BUM flooding is concerned, a flooding list will be composed + of the sublist created by the inclusive multicast routes and the + sublist created for VPLS in the WAN. BUM frames received from a + 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 + 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 + the same far end within the same MAC-VRF, so that loops and packet + 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 + binding will prevail, and the PW will be brought down operationally. + + The optimization procedures described in Section 3.5 can also be + applied to this model. + +4.2.2. Multihoming Procedures on the GWs + + This model supports single-active multihoming on the GWs. All-active + multihoming is not supported by VPLS; therefore, it cannot be used on + the GWs. + + 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 multihoming + procedures as described by [RFC8365] will be followed for the I-ES. + + 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 + traffic. + +4.3. PBB-VPLS Interconnect for EVPN-Overlay Networks + +4.3.1. Control/Data Plane Setup Procedures on the GWs + + In this case, there is no impact on the procedures described in + [RFC7041] for the B-component. However, the I-component instances + become EVI instances with EVPN-Overlay bindings and potentially local + attachment circuits. A number of MAC-VRF instances can be + multiplexed into the same B-component instance. This option provides + 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 PBB-VPLS-based interconnect. + + B-component PWs and I-component EVPN-Overlay bindings established to + the same far end will be compared. The following rules will be + observed: + + * Attempts to set up a PW between the two GWs within the B-component + context will never be blocked. + + * If a PW exists between two GWs for the B-component and an attempt + is made to set up an EVPN binding on an I-component linked to that + B-component, the EVPN binding will be kept down operationally. + Note that the BGP EVPN routes will still be valid but not used. + + * 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 + bindings in the I-components will be brought down before the PW in + the B-component is brought up. + + The optimization procedures described in Section 3.5 can also be + applied to this interconnect option. + +4.3.2. Multihoming Procedures on the GWs + + This model supports single-active multihoming on the GWs. All-active + multihoming is not supported by this scenario. + + The single-active multihoming procedures as described by [RFC8365] + will be followed for the I-ES for each EVI instance connected to the + B-component. Note that in this case, for a given EVI, all the EVPN + bindings in the I-component are assigned to the I-ES. The non-DF GW + for the I-ES will block the transmission and reception of all the + I-component EVPN bindings for BUM and unicast traffic. When learning + MACs from the WAN, the non-DF MUST NOT advertise EVPN MAC/IP routes + for those MACs. + +4.4. EVPN-MPLS Interconnect for EVPN-Overlay Networks + + If EVPN for MPLS tunnels (referred to as "EVPN-MPLS" hereafter) are + supported in the WAN, an end-to-end EVPN solution can be deployed. + The following sections describe the proposed solution as well as its + impact on the procedures from [RFC7432]. + +4.4.1. Control plane Setup Procedures on the GWs + + 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 set up one BGP EVPN session to the DC RR (or two BGP EVPN + sessions if there are redundant DC RRs) and one session to the WAN RR + (or two sessions if there are redundant WAN RRs). + + In order to facilitate separate BGP processes for DC and WAN, EVPN + routes sent to the WAN SHOULD carry a different Route Distinguisher + (RD) than the EVPN routes sent to the DC. In addition, although + 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 + that the EVPN service routes sent to the DC RRs will normally include + a [RFC9012] BGP encapsulation extended community with a different + tunnel type than the one sent to the WAN RRs. + + As in the other discussed options, an I-ES and its assigned I-ESI + 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. Optionally, different I-ESI values are configured for + representing the WAN and the DC. If different EVPN-Overlay networks + are connected to the same group of GWs, each EVPN-Overlay network + MUST get assigned a different I-ESI. + + Received EVPN routes will never be reflected on the GWs but instead + will be consumed and re-advertised (if needed): + + * Ethernet A-D routes, ES routes, and Inclusive Multicast routes are + consumed by the GWs and processed locally for the corresponding + [RFC7432] procedures. + + * MAC/IP advertisement routes will be received and imported, and if + they become active in the MAC-VRF, the information will be re- + advertised as new routes with the following fields: + + - The RD will be the GW's RD for the MAC-VRF. + + - The ESI will be set to the I-ESI. + + - 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 + will be kept from the received NLRI. + + - 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 + encapsulations using a VNI). + + - The appropriate Route Targets (RTs) and [RFC9012] BGP + encapsulation extended community will be used according to + [RFC8365]. + + The GWs will also generate the following local EVPN routes that will + be sent to the DC and WAN, with their corresponding RTs and [RFC9012] + BGP encapsulation extended community values: + + * ES route(s) for the I-ESI(s). + + * Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D per- + EVI routes sent to the WAN and the DC will have consistent + Ethernet-Tag values. + + * Inclusive Multicast routes with independent tunnel-type value for + the WAN and DC. For example, a P2MP Label Switched Path (LSP) may + be used in the WAN, whereas ingress replication may be used in the + DC. The routes sent to the WAN and the DC will have a consistent + Ethernet-Tag. + + * MAC/IP advertisement routes for MAC addresses learned in local + attachment circuits. Note that these routes will not include the + I-ESI value in the ESI field. These routes will include a zero + ESI or a non-zero ESI for local multihomed Ethernet Segments (ES). + The routes sent to the WAN and the DC will have a consistent + Ethernet-Tag. + + 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 + sent to the DC RRs and will include an A-D per EVI, Inclusive + Multicast, and MAC/IP routes for the DC encapsulation and RT. Set- + WAN will be sent to the WAN RRs and will include the same routes but + using the WAN RT and encapsulation. GW1 and GW2 will receive each + other's set-DC and set-WAN. This is the expected behavior on GW1 and + GW2 for locally generated routes: + + * Inclusive multicast routes: When setting up the flooding lists for + a given MAC-VRF, each GW will include its DC peer GW only in the + EVPN-MPLS flooding list (by default) and not the EVPN-Overlay + flooding list. That is, GW2 will import two Inclusive Multicast + routes from GW1 (from set-DC and set-WAN) but will only consider + one of the two, giving the set-WAN route higher priority. An + administrative option MAY change this preference so that the set- + DC route is selected first. + + * MAC/IP advertisement routes for local attachment circuits: As + above, the GW will select only one, giving the route from the set- + WAN a higher priority. As with the Inclusive multicast routes, an + administrative option MAY change this priority. + +4.4.2. Data Plane Setup Procedures on the GWs + + 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 + same EVPN-Overlay network (for frames generated from local ACs), + since only one EVPN binding per EVI (or per Ethernet Tag in the case + of VLAN-aware bundle services) will be set up in the data plane + between the two nodes. That binding will by default be added to the + EVPN-MPLS flooding list. + + 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- + VRF: + + * EVPN-Overlay flooding list (composed of bindings to the remote + NVEs or multicast tunnel to the NVEs). + + * EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the + remote PEs). + + Each flooding list will be part of a separate split-horizon group: + the WAN split-horizon group or the DC split-horizon group. Traffic + generated from a local AC can be flooded to both split-horizon + groups. Traffic from a binding of a split-horizon group can be + flooded to the other split-horizon group and local ACs, but never to + a member of its own split-horizon group. + + 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 + 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 nonzero + ESI). + +4.4.3. Multihoming Procedure Extensions on the GWs + + This model supports single-active as well as all-active multihoming. + + All the [RFC7432] multihoming procedures for the DF election on + I-ES(s), as well as the backup-path (single-active) and aliasing + (all-active) procedures, will be followed on the GWs. Remote PEs in + the EVPN-MPLS network will follow regular [RFC7432] aliasing or + backup-path procedures for MAC/IP routes received from the GWs for + the same I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP + routes received with the same I-ESI. + + As far as the forwarding plane is concerned, by default, the EVPN- + Overlay network will have an analogous behavior to the access ACs in + [RFC7432] multihomed Ethernet Segments. + + The forwarding behavior on the GWs is described below: + + * Single-active multihoming; assuming a WAN split-horizon group + (comprised of EVPN-MPLS bindings), a DC split-horizon group + (comprised of EVPN-Overlay bindings), and local ACs on the GWs: + + - Forwarding behavior on the non-DF: The non-DF MUST block + ingress and egress forwarding on the EVPN-Overlay bindings + associated to the I-ES. The EVPN-MPLS network is considered to + be the core network, and the EVPN-MPLS bindings to the remote + PEs and GWs will be active. + + - Forwarding behavior on the DF: The DF MUST NOT forward BUM or + unicast traffic received from a given split-horizon group to a + member of its own split-horizon group. Forwarding to other + 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 + per [RFC7432] and for split-horizon purposes, when receiving + BUM traffic on the EVPN-Overlay bindings associated to an I-ES, + the DF GW SHOULD add the I-ESI label when forwarding to the + peer GW over EVPN-MPLS. + + - When receiving EVPN MAC/IP routes from the WAN, the non-DF MUST + NOT reoriginate the EVPN routes and advertise them to the DC + peers. In the same way, EVPN MAC/IP routes received from the + DC MUST NOT be advertised to the WAN peers. This is consistent + with [RFC7432] and allows the remote PE/NVEs to know who the + primary GW is, based on the reception of the MAC/IP routes. + + * All-active multihoming; assuming a WAN split-horizon group + (comprised of EVPN-MPLS bindings), a DC split-horizon group + (comprised of EVPN-Overlay bindings), and local ACs on the GWs: + + - 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 + BUM traffic. Unicast traffic received from a split-horizon + group MUST NOT be forwarded to a member of its own split- + horizon group but can be forwarded normally to the other split- + horizon groups and local ACs. If a known unicast packet is + identified as a "flooded" packet, the procedures for BUM + traffic MUST be followed. + + - Forwarding behavior on the DF: The DF follows the same behavior + as the DF in the single-active case, but only for BUM traffic. + Unicast traffic received from a split-horizon group MUST NOT be + forwarded to a member of its own split-horizon group but can be + forwarded normally to the other split-horizon group and local + ACs. If a known unicast packet is identified as a "flooded" + packet, the procedures for BUM traffic MUST be followed. As + per [RFC7432] and for split-horizon purposes, when receiving + BUM traffic on the EVPN-Overlay bindings associated to an I-ES, + the DF GW MUST add the I-ESI label when forwarding to the peer + GW over EVPN-MPLS. + + - Contrary to the single-active multihoming case, both DF and + non-DF reoriginate and advertise MAC/IP routes received from + the WAN/DC peers, adding the corresponding I-ESI so that the + remote PE/NVEs can perform regular aliasing, as per [RFC7432]. + + The example in Figure 3 illustrates the forwarding of BUM traffic + originated from an NVE on a pair of all-active multihoming GWs. + + |<--EVPN-Overlay--->|<--EVPN-MPLS-->| + + +---------+ +--------------+ + +----+ BUM +---+ | + |NVE1+----+----> | +-+-----+ | + +----+ | | DF |GW1| | | | + | | +-+-+ | | ++--+ + | | | | +--> |PE1| + | +--->X +-+-+ | ++--+ + | NDF| | | | + +----+ | |GW2<-+ | + |NVE2+--+ +-+-+ | + +----+ +--------+ | +------------+ + v + +--+ + |CE| + +--+ + + Figure 3: Multihoming BUM Forwarding + + 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 + will include the ESI label for the I-ES. Based on the ESI label, GW2 + identifies the packets as I-ES-generated packets and will only + forward them to local ACs (CE in the example) and not back to the + EVPN-Overlay network. + +4.4.4. Impact on MAC Mobility Procedures + + MAC Mobility procedures described in [RFC7432] are not modified by + this document. + + 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 + MAC Mobility event. Only when the MAC moves from the WAN domain to + 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. + + The sticky-bit indication in the MAC Mobility extended community MUST + be propagated between domains. + +4.4.5. Gateway Optimizations + + All the Gateway optimizations described in Section 3.5 MAY be applied + to the GWs when the interconnect is based on EVPN-MPLS. + + In particular, the use of the Unknown MAC Route, as described in + Section 3.5.1, solves some transient packet-duplication issues in + cases of all-active multihoming, as explained below. + + Consider the diagram in Figure 2 for EVPN-MPLS interconnect and all- + active multihoming, and the following sequence: + + (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 + with I-ESI-2 in the ESI field. + + (c) GW1 and GW2 learn M1 and install GW3/GW4 as next hops following + the EVPN aliasing procedures. + + (d) Before NVE1 learns M1, a packet arrives at NVE1 with destination + M1. If the Unknown MAC Route had not been advertised into the + DC, NVE1 would have flooded the packet throughout the DC, in + particular to both GW1 and GW2. If the same VNI/VSID is used + for both known unicast and BUM traffic, as is typically the + case, there is no indication in the packet that it is a BUM + packet, and both GW1 and GW2 would have forwarded it, creating + packet duplication. However, because the Unknown MAC Route had + been advertised into the DC, NVE1 will unicast the packet to + either GW1 or GW2. + + (e) Since both GW1 and GW2 know M1, the GW receiving the packet will + forward it to either GW3 or GW4. + +4.4.6. Benefits of the EVPN-MPLS Interconnect Solution + + The "DCI using ASBRs" solution described in [RFC8365] and the GW + solution with EVPN-MPLS interconnect may be seen as similar, since + they both retain the EVPN attributes between Data Centers and + throughout the WAN. However, the EVPN-MPLS interconnect solution on + the GWs has significant benefits compared to the "DCI using ASBRs" + solution: + + * As in any of the described GW models, this solution supports the + connectivity of local attachment circuits on the GWs. This is not + possible in a "DCI using ASBRs" solution. + + * Different data plane encapsulations can be supported in the DC and + the WAN, while a uniform encapsulation is needed in the "DCI using + ASBRs" solution. + + * Optimized multicast solution, with independent inclusive multicast + trees in DC and WAN. + + * MPLS label aggregation: For the case where MPLS labels are + signaled from the NVEs for MAC/IP advertisement routes, this + solution provides label aggregation. A remote PE MAY receive a + single label per GW MAC-VRF, as opposed to a label per NVE/MAC-VRF + connected to the GW MAC-VRF. For instance, in Figure 2, PE would + receive only one label for all the routes advertised for a given + MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF. + + * The GW will not propagate MAC Mobility for the MACs moving within + a DC. Mobility intra-DC is solved by all the NVEs in the DC. The + MAC Mobility procedures on the GWs are only required in case of + mobility across DCs. + + * Proxy-ARP/ND function on the DC GWs can be leveraged to reduce + ARP/ND flooding in the DC or/and the WAN. + +4.5. PBB-EVPN Interconnect for EVPN-Overlay Networks + + PBB-EVPN [RFC7623] is yet another interconnect option. It requires + the use of GWs where I-components and associated B-components are + part of EVI instances. + +4.5.1. Control/Data Plane Setup Procedures on the GWs + + EVPN will run independently in both components, the I-component MAC- + VRF and B-component MAC-VRF. Compared to [RFC7623], the DC customer + MACs (C-MACs) are no longer learned in the data plane on the GW but + in the control plane through EVPN running on the I-component. Remote + C-MACs coming from remote PEs are still learned in the data plane. + B-MACs in the B-component will be assigned and advertised following + the procedures described in [RFC7623]. + + 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. + No unreserved ESIs will be used in the control plane of the + B-component EVI, as per [RFC7623]. That is, the I-ES will be + represented to the WAN PBB-EVPN PEs using shared or dedicated B-MACs. + + The rest of the control plane procedures will follow [RFC7432] for + the I-component EVI and [RFC7623] for the B-component EVI. + + 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-component EVPN-Overlay binding will be kept down following the + rules described in Section 4.3.1. + +4.5.2. Multihoming Procedures on the GWs + + 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 description outlined in Section 4.4.3, substituting the WAN + split-horizon group for the B-component, and using [RFC7623] + procedures for the traffic sent or received on the B-component. + +4.5.3. Impact on MAC Mobility Procedures + + 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 + I-component database, EVPN would advertise the C-MAC with a higher + sequence number, as per [RFC7432]. From the perspective of Mobility + and the related procedures described in [RFC7432], the C-MACs learned + from the B-component are considered local. + +4.5.4. Gateway Optimizations + + All the considerations explained in Section 4.4.5 are applicable to + the PBB-EVPN interconnect option. + +4.6. EVPN-VXLAN Interconnect for EVPN-Overlay Networks + + If EVPN for Overlay tunnels is supported in the WAN, and a GW + function is required, an end-to-end EVPN solution can be deployed. + While multiple Overlay tunnel combinations at the WAN and the DC are + possible (MPLSoGRE, NVGRE, etc.), VXLAN is described here, given its + popularity in the industry. This section focuses on the specific + case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the + [RFC7432] procedures. + + The procedures described in Section 4.4 apply to this section, too, + only substituting EVPN-MPLS for EVPN-VXLAN control plane specifics + and using [RFC8365] "Local Bias" procedures instead of Section 4.4.3. + Since there are no ESI labels in VXLAN, GWs need to rely on "Local + Bias" to apply split horizon on packets generated from the I-ES and + sent to the peer GW. + + This use case assumes that NVEs need to use the VNIs or VSIDs as + globally unique identifiers within a Data Center, and a Gateway needs + to be employed at the edge of the Data-Center network to translate + the VNI or VSID when crossing the network boundaries. This GW + function provides VNI and tunnel-IP-address translation. The use + case in which local downstream-assigned VNIs or VSIDs can be used + (like MPLS labels) is described by [RFC8365]. + + While VNIs are globally significant within each DC, there are two + possibilities in the interconnect network: + + 1. Globally unique VNIs in the interconnect network. In this case, + the GWs and PEs in the interconnect network will agree on a + common VNI for a given EVI. The RT to be used in the + interconnect network can be autoderived from the agreed-upon + interconnect VNI. The VNI used inside each DC MAY be the same as + the interconnect VNI. + + 2. Downstream-assigned VNIs in the interconnect network. In this + case, the GWs and PEs MUST use the proper RTs to import/export + the EVPN routes. Note that even if the VNI is downstream + assigned in the interconnect network, and unlike option (a), it + only identifies the <Ethernet Tag, GW> pair and not the <Ethernet + Tag, egress PE> pair. The VNI used inside each DC MAY be the + same as the interconnect VNI. GWs SHOULD support multiple VNI + spaces per EVI (one per interconnect network they are connected + to). + + 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 + multiple VNI spaces. In addition to VNI translation above, the GWs + will provide translation of the tunnel source IP for the packets + 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 + interconnect network. + + The following sections provide more details about these two options. + +4.6.1. Globally Unique VNIs in the Interconnect Network + + 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 + 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- + 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 + 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 + 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-10 to VNI-100 when the packet is received from NVO-1 and the + reverse mapping from VNI-100 to VNI-10 when the packet is received + from the remote NVO-2 network and needs to be forwarded to NVO-1. + + The procedures described in Section 4.4 will be followed, considering + that the VNIs advertised/received by the GWs will be translated + accordingly. + +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 + 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 MUST be translated as in Section 4.6.1. However, in this case, + there is no need to translate to a common interconnect VNI on the + GWs. Each GW can translate the VNI received in an EVPN update to a + locally assigned VNI advertised to the interconnect network. Each GW + can use a different interconnect VNI; hence, this VNI does not need + 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 into + account the considerations above for the VNI translation. + +5. Security Considerations + + This document applies existing specifications to a number of + interconnect models. The security considerations included in those + documents, such as [RFC7432], [RFC8365], [RFC7623], [RFC4761], and + [RFC4762] apply to this document whenever those technologies are + used. + + As discussed, [RFC8365] discusses two main DCI solution groups: "DCI + using GWs" and "DCI using ASBRs". This document specifies the + solutions that correspond to the "DCI using GWs" group. It is + important to note that the use of GWs provides a superior level of + security on a per-tenant basis, compared to the use of ASBRs. This + is due to the fact that GWs need to perform a MAC lookup on the + frames being received from the WAN, and they apply security + procedures, such as filtering of undesired frames, filtering of + frames with a source MAC that matches a protected MAC in the DC, or + application of MAC-duplication procedures defined in [RFC7432]. On + ASBRs, though, traffic is forwarded based on a label or VNI swap, and + there is usually no visibility of the encapsulated frames, which can + carry malicious traffic. + + In addition, the GW optimizations specified in this document provide + additional protection of the DC tenant systems. For instance, the + MAC-address advertisement control and Unknown MAC Route defined in + Section 3.5.1 protect the DC NVEs from being overwhelmed with an + excessive number of MAC/IP routes being learned on the GWs from the + WAN. The ARP/ND flooding control described in Section 3.5.2 can + reduce/suppress broadcast storms being injected from the WAN. + + Finally, the reader should be aware of the potential security + implications of designing a DCI with the decoupled interconnect + solution (Section 3) or the integrated interconnect solution + (Section 4). In the decoupled interconnect solution, the DC is + typically easier to protect from the WAN, since each GW has a single + logical link to one WAN PE, whereas in the Integrated solution, the + GW has logical links to all the WAN PEs that are attached to the + tenant. In either model, proper control plane and data plane + policies should be put in place in the GWs in order to protect the DC + from potential attacks coming from the WAN. + +6. IANA Considerations + + This document has no IANA actions. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, + <https://www.rfc-editor.org/info/rfc4761>. + + [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private + LAN Service (VPLS) Using Label Distribution Protocol (LDP) + Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, + <https://www.rfc-editor.org/info/rfc4762>. + + [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, + "Provisioning, Auto-Discovery, and Signaling in Layer 2 + Virtual Private Networks (L2VPNs)", RFC 6074, + DOI 10.17487/RFC6074, January 2011, + <https://www.rfc-editor.org/info/rfc6074>. + + [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., + "Extensions to the Virtual Private LAN Service (VPLS) + Provider Edge (PE) Model for Provider Backbone Bridging", + RFC 7041, DOI 10.17487/RFC7041, November 2013, + <https://www.rfc-editor.org/info/rfc7041>. + + [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., + Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based + Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February + 2015, <https://www.rfc-editor.org/info/rfc7432>. + + [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, + "Covering Prefixes Outbound Route Filter for BGP-4", + RFC 7543, DOI 10.17487/RFC7543, May 2015, + <https://www.rfc-editor.org/info/rfc7543>. + + [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. + Henderickx, "Provider Backbone Bridging Combined with + Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, + September 2015, <https://www.rfc-editor.org/info/rfc7623>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., + Uttaro, J., and W. Henderickx, "A Network Virtualization + Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, + DOI 10.17487/RFC8365, March 2018, + <https://www.rfc-editor.org/info/rfc8365>. + + [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, + "The BGP Tunnel Encapsulation Attribute", RFC 9012, + DOI 10.17487/RFC9012, April 2021, + <https://www.rfc-editor.org/info/rfc9012>. + +7.2. Informative References + + [IEEE.802.1AG] + IEEE, "IEEE Standard for Local and Metropolitan Area + Networks Virtual Bridged Local Area Networks Amendment 5: + Connectivity Fault Management", IEEE standard 802.1ag- + 2007, January 2008. + + [IEEE.802.1Q] + IEEE, "IEEE Standard for Local and metropolitan area + 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>. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, + DOI 10.17487/RFC3031, January 2001, + <https://www.rfc-editor.org/info/rfc3031>. + + [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., + "Encapsulating MPLS in IP or Generic Routing Encapsulation + (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, + <https://www.rfc-editor.org/info/rfc4023>. + + [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, + R., Patel, K., and J. Guichard, "Constrained Route + Distribution for Border Gateway Protocol/MultiProtocol + Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual + Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, + November 2006, <https://www.rfc-editor.org/info/rfc4684>. + + [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire + Preferential Forwarding Status Bit", RFC 6870, + DOI 10.17487/RFC6870, February 2013, + <https://www.rfc-editor.org/info/rfc6870>. + + [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, + L., Sridhar, T., Bursell, M., and C. Wright, "Virtual + eXtensible Local Area Network (VXLAN): A Framework for + Overlaying Virtualized Layer 2 Networks over Layer 3 + Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, + <https://www.rfc-editor.org/info/rfc7348>. + + [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network + Virtualization Using Generic Routing Encapsulation", + RFC 7637, DOI 10.17487/RFC7637, September 2015, + <https://www.rfc-editor.org/info/rfc7637>. + + [VIRTUAL-ES] + Sajassi, A., Brissette, P., Schell, R., Drake, J. E., and + 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>. + + [Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based + networks", ITU-T Recommendation Y.1731, August 2019. + +Acknowledgments + + The authors would like to thank Neil Hart, Vinod Prabhu, and Kiran + Nagaraj for their valuable comments and feedback. We would also like + to thank Martin Vigoureux and Alvaro Retana for their detailed + reviews and comments. + +Contributors + + In addition to the authors listed on the front page, the following + coauthors have also contributed to this document: + + Ravi Shekhar + Juniper Networks + + + Anil Lohiya + Juniper Networks + + + Wen Lin + Juniper Networks + + + Florin Balus + Cisco + + + Patrice Brissette + Cisco + + + Senad Palislamovic + Nokia + + + Dennis Cai + Alibaba + + +Authors' Addresses + + Jorge Rabadan (editor) + Nokia + 777 E. Middlefield Road + Mountain View, CA 94043 + United States of America + + Email: jorge.rabadan@nokia.com + + + Senthil Sathappan + Nokia + + Email: senthil.sathappan@nokia.com + + + Wim Henderickx + Nokia + + Email: wim.henderickx@nokia.com + + + Ali Sajassi + Cisco + + Email: sajassi@cisco.com + + + John Drake + Juniper + + Email: jdrake@juniper.net |