diff options
Diffstat (limited to 'doc/rfc/rfc8560.txt')
| -rw-r--r-- | doc/rfc/rfc8560.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc8560.txt b/doc/rfc/rfc8560.txt new file mode 100644 index 0000000..41435d3 --- /dev/null +++ b/doc/rfc/rfc8560.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Sajassi, Ed. +Request for Comments: 8560 S. Salam +Category: Standards Track Cisco +ISSN: 2070-1721 N. Del Regno + Verizon + J. Rabadan + Nokia + May 2019 + + + Seamless Integration of Ethernet VPN (EVPN) with + Virtual Private LAN Service (VPLS) and + Their Provider Backbone Bridge (PBB) Equivalents + +Abstract + + This document specifies mechanisms for backward compatibility of + Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN + (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and + Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides + mechanisms for the seamless integration of these two technologies in + the same MPLS/IP network on a per-VPN-instance basis. Implementation + of this document enables service providers to introduce EVPN/PBB-EVPN + Provider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS + networks. This document specifies the control-plane and forwarding + behavior needed for the auto-discovery of the following: 1) a VPN + instance, 2) multicast and unicast operation, and 3) a Media Access + Control (MAC) mobility operation. This enables seamless integration + between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN + PEs. + +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/rfc8560. + + + + + + + +Sajassi, et al. Standards Track [Page 1] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + +Copyright Notice + + Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 + 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 + 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. VPLS Integration with EVPN . . . . . . . . . . . . . . . . . 7 + 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . 7 + 3.2. Forwarding Setup and Unicast Operation . . . . . . . . . 8 + 3.3. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Multicast Operation . . . . . . . . . . . . . . . . . . . 10 + 3.4.1. Ingress Replication . . . . . . . . . . . . . . . . . 10 + 3.4.2. P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . 10 + 4. PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . 10 + 4.1. Capability Discovery . . . . . . . . . . . . . . . . . . 11 + 4.2. Forwarding Setup and Unicast Operation . . . . . . . . . 11 + 4.3. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 12 + 4.4. Multicast Operation . . . . . . . . . . . . . . . . . . . 12 + 4.4.1. Ingress Replication . . . . . . . . . . . . . . . . . 12 + 4.4.2. P2MP Tunnel: Inclusive Tree . . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 7.2. Informative References . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + +Sajassi, et al. Standards Track [Page 2] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + +1. Introduction + + Virtual Private LAN Service (VPLS) and Provider Backbone Bridging + VPLS (PBB-VPLS) are widely deployed Layer 2 VPN (L2VPN) technologies. + Many service providers who are looking at adopting Ethernet VPN + (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to + preserve their investments in the VPLS and PBB-VPLS networks. Hence, + they require mechanisms by which EVPN and PBB-EVPN technologies can + be introduced into their brownfield VPLS and PBB-VPLS networks + without requiring any upgrades (software or hardware) to these + networks. This document specifies procedures for the seamless + integration of the two technologies in the same MPLS/IP network. + Throughout this document, we use the term "(PBB-)EVPN" to correspond + to both EVPN and PBB-EVPN, and we use the term "(PBB-)VPLS" to + correspond to both VPLS and PBB-VPLS. This document specifies the + control-plane and forwarding behavior needed for 1) auto-discovery of + a VPN instance, 2) multicast and unicast operations, and 3) a MAC + mobility operation. This enables seamless integration between + (PBB-)EVPN Provider Edge (PE) devices and (PBB-)VPLS PEs. + + VPLS PE + +---+ + |PE1| + +---+ + / + EVPN/VPLS PE +---------------+ EVPN/VPLS PE + +---+ | | +---+ + |PE4|----| MPLS/IP |---|PE5| + +---+ | Core | +---+ + | | + +---------------+ + / \ + +---+ +---+ + |PE2| |PE3| + +---+ +---+ + VPLS PE VPLS PE + + Figure 1: Seamless Integration of (PBB-)EVPN and (PBB-)VPLS + + Section 2 provides the details of the requirements. Section 3 + specifies procedures for the seamless integration of VPLS and EVPN + networks. Section 4 specifies procedures for the seamless + integration of PBB-VPLS and PBB-EVPN networks. + + It should be noted that the scenarios for both PBB-VPLS integration + with EVPN and VPLS integration with PBB-EVPN are not covered in this + document because there haven't been any requirements from service + providers for these scenarios; deployments that employ PBB-VPLS + + + +Sajassi, et al. Standards Track [Page 3] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + typically require PBB encapsulation for various reasons. Hence, it + is expected that for those deployments, the evolution path would move + from PBB-VPLS towards PBB-EVPN. Furthermore, the evolution path from + VPLS is expected to move towards EVPN. + + The seamless integration solution described in this document has the + following attributes: + + - When ingress replication is used for multi-destination traffic + delivery, the solution reduces the scope of MMRP (which is a soft- + state protocol defined in Clause 10 of [IEEE.802.1Q]) to only that + of existing VPLS PEs and uses the more robust BGP-based mechanism + for multicast pruning among new EVPN PEs. + + - It is completely backward compatible. + + - New PEs can leverage the extensive multihoming mechanisms and + provisioning simplifications of (PBB-)EVPN: + + (a) Auto-sensing of Multihomed Networks (MHNs) / Multihomed + Devices (MHDs) + + (b) Auto-discovery of redundancy groups + + (c) Auto-provisioning of Designated Forwarder election and VLAN + carving + +1.1. Specification of Requirements + + 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. + +1.2. Abbreviations + + B-MAC: Backbone MAC, e.g., the PE's MAC address + + C-MAC: Customer MAC, e.g., a host or CE's MAC address + + CE: A Customer Edge device, e.g., a host, router, or switch + + ES: Ethernet Segment -- refers to the set of Ethernet links + that connects a customer site (device or network) to one + or more PEs + + FEC: Forwarding Equivalence Class + + + +Sajassi, et al. Standards Track [Page 4] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + FIB: Forwarding Information Base -- an instantiation of a + forwarding table on a MAC-VRF + + I-SID: Service Instance Identifier + + LSP: Label Switched Path + + MAC: Media Access Control + + MAC-VRF: A Virtual Routing and Forwarding table for Media Access + Control (MAC) addresses on an EVPN PE + + MHD: Multihomed Device + + MHN: Multihomed Network + + MP2P: Multipoint to Point -- an MP2P LSP typically refers to an + LSP for unicast traffic as the result of a downstream- + assigned label + + P2MP: Point to Multipoint -- a P2MP LSP typically refers to an + LSP for multicast traffic + + PBB: Provider Backbone Bridge + + (PBB-)EVPN: Both PBB-EVPN and EVPN -- this document uses this + abbreviation when a given description applies to both + technologies + + (PBB-)VPLS: Both PBB-VPLS and VPLS -- this document uses this + abbreviation when a given description applies to both + technologies + + PE: Provider Edge device + + PW: Pseudowire + + RIB: Routing Information Base -- an instantiation of a routing + table on a MAC-VRF + + VSI: Virtual Switch Instance + + VPLS: Virtual Private LAN Service + + VPLS A-D: Virtual Private LAN Service with BGP-based auto-discovery + as in [RFC6074] + + + + + +Sajassi, et al. Standards Track [Page 5] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + +1.3. Terminology + + All-Active redundancy mode: When all PEs attached to an Ethernet + segment are allowed to forward known unicast traffic to/from that + Ethernet segment for a given VLAN, then the Ethernet segment is + defined as operating in All-Active redundancy mode. + + Bridge table: An instantiation of a broadcast domain on a MAC-VRF + (VPN Routing and Forwarding). + + Broadcast domain: In a bridged network, the broadcast domain + corresponds to a Virtual LAN (VLAN), where a VLAN is typically + represented by a single VLAN ID (VID) but can be represented by + several VIDs where Shared VLAN Learning (SVL) is used, per + [IEEE.802.1Q]. + + Ethernet Tag: An Ethernet Tag identifies a particular broadcast + domain, e.g., a VLAN. An EVPN instance consists of one or more + broadcast domains. + + Single-Active redundancy mode: When only a single PE, among all the + PEs attached to an Ethernet segment, is allowed to forward traffic + to/from that Ethernet segment for a given VLAN, then the Ethernet + segment is defined as operating in Single-Active redundancy mode. + +2. Requirements + + The following are the key requirements for backward compatibility + between (PBB-)EVPN and (PBB-)VPLS: + + 1. The solution must allow for staged migration towards (PBB-)EVPN + on a site-by-site basis per VPN instance, e.g., new EVPN sites to + be provisioned on (PBB-)EVPN Provider Edge devices (PEs). + + 2. The solution must not require any changes to existing VPLS or + PBB-VPLS PEs, not even a software upgrade. + + 3. The solution must allow for the coexistence of PE devices running + (PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single- + homed segments. + + 4. The solution must support single-active redundancy of multihomed + networks and multihomed devices for (PBB-)EVPN PEs. + + 5. In cases of single-active redundancy, the participant VPN + instances may span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs + as long as the MHD or MHN is connected to (PBB-)EVPN PEs. + + + + +Sajassi, et al. Standards Track [Page 6] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + 6. Support of the All-Active redundancy mode across both (PBB-)EVPN + PEs and (PBB-)VPLS PEs is outside the scope of this document. + All-Active redundancy is not applicable to VPLS and PBB-VPLS. + Therefore, when EVPN (or PBB-EVPN) PEs need to operate seamlessly + with VPLS (or PBB-VPLS) PEs, they MUST use a redundancy mode that + is applicable to VPLS (or PBB-VPLS). This redundancy mode is + Single-Active. + + These requirements collectively allow for the seamless insertion of + (PBB-)EVPN technology into brownfield (PBB-)VPLS deployments. + +3. VPLS Integration with EVPN + + In order to support seamless integration with VPLS PEs, this document + requires that VPLS PEs support VPLS A-D per [RFC6074], and it + requires EVPN PEs to support both BGP EVPN routes per [RFC7432] and + VPLS A-D per [RFC6074]. All the logic for seamless integration shall + reside on the EVPN PEs. If a VPLS instance is set up without the use + of VPLS A-D, it is still possible (but cumbersome) for EVPN PEs to + integrate that VPLS instance by manually configuring pseudowires + (PWs) to all the VPLS PEs in that instance (i.e., the integration is + no longer seamless). + +3.1. Capability Discovery + + The EVPN PEs MUST advertise both the BGP VPLS auto-discovery (A-D) + route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) + route for a given VPN instance. The VPLS PEs only advertise the BGP + VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762] + and [RFC6074]. The operator may decide to use the same Route Target + (RT) to identify a VPN on both EVPN and VPLS networks. In this case, + when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the + basis that it belongs to an unknown Subsequent Address Family + Identifier (SAFI). However, the operator may choose to use two RTs + -- one to identify the VPN on the VPLS network and another for the + EVPN network -- and employ RT Constrain mechanisms [RFC4684] in order + to prevent BGP EVPN routes from reaching the VPLS PEs. + + When an EVPN PE receives both a VPLS A-D route as well as an EVPN + IMET route from a given remote PE for the same VPN instance, it MUST + give preference to the EVPN route for the purpose of discovery. This + ensures that, at the end of the route exchanges, all EVPN-capable PEs + discover other EVPN-capable PEs in addition to the VPLS-only PEs for + that VPN instance. Furthermore, all the VPLS-only PEs will discover + the EVPN PEs as if they were standard VPLS PEs. In other words, when + the discovery phase is complete, the EVPN PEs will have discovered + all the PEs in the VPN instance along with their associated + + + + +Sajassi, et al. Standards Track [Page 7] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + capability (EVPN or VPLS-only), whereas the VPLS PEs will have + discovered all the PEs in the VPN instance as if they were all VPLS- + only PEs. + +3.2. Forwarding Setup and Unicast Operation + + The procedures for the forwarding state setup and unicast operation + on the VPLS PE are per [RFC8077], [RFC4761], and [RFC4762]. + + The procedures for forwarding state setup and unicast operation on + the EVPN PE are as follows: + + - The EVPN PE MUST establish a PW to each remote PE from which it + has received only a VPLS A-D route for the corresponding VPN + instance and MUST set up the label stack corresponding to the PW + FEC. For seamless integration between EVPN and VPLS PEs, the PW + that is set up between a pair of VPLS and EVPN PEs is between the + VSI of the VPLS PE and the MAC-VRF of the EVPN PE. + + - The EVPN PE MUST set up the label stack corresponding to the MP2P + VPN unicast FEC to any remote PE that has advertised an EVPN IMET + route. + + - If an EVPN PE receives a VPLS A-D route from a given PE, it sets + up a PW to that PE. If it then receives an EVPN IMET route from + the same PE, the EVPN PE MUST bring that PW operationally down. + + - If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D + route from the same PE, then the EVPN PE will set up the PW but + MUST keep it operationally down. + + - In case VPLS A-D is not used in some VPLS PEs, the EVPN PEs need + to be provisioned manually with PWs to those remote VPLS PEs for + each VPN instance. In that case, if an EVPN PE receives an EVPN + IMET route from a PE to which a PW exists, the EVPN PE MUST bring + the PW operationally down. + + When the EVPN PE receives traffic over the VPLS PWs, it learns the + associated C-MAC addresses in the data plane. The C-MAC addresses + learned over these PWs MUST be injected into the bridge table of the + associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY + also be injected into the RIB/FIB tables of the associated MAC-VRF on + that EVPN PE. For seamless integration between EVPN and VPLS PEs, + because these PWs belong to the same split-horizon group (see + [RFC4761] and [RFC4762]) as the MP2P EVPN service tunnels, the C-MAC + addresses learned and associated with the PWs MUST NOT be advertised + in the control plane to any remote EVPN PEs. This is because every + + + + +Sajassi, et al. Standards Track [Page 8] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + EVPN PE can send and receive traffic directly to/from every VPLS PE + belonging to the same VPN instance; thus, every EVPN PE can learn the + C-MAC addresses over the corresponding PWs directly. + + The C-MAC addresses learned over local Attachment Circuits (ACs) by + an EVPN PE are learned in the data plane. For EVPN PEs, these C-MAC + addresses MUST be injected into the corresponding MAC-VRF and + advertised in the control plane using BGP EVPN routes. Furthermore, + the C-MAC addresses learned in the control plane via the BGP EVPN + routes sent by remote EVPN PEs are injected into the corresponding + MAC-VRF table. + + In case of a link failure in a single-active Ethernet segment, the + EVPN PEs MUST perform both of the following tasks: + + 1. send a BGP mass withdraw to the EVPN peers + + 2. follow existing VPLS MAC Flush procedures with the VPLS peers + +3.3. MAC Mobility + + In EVPN, host addresses (C-MAC addresses) can move around among EVPN + PEs or even between EVPN and VPLS PEs. + + When a C-MAC address moves from an EVPN PE to a VPLS PE, as soon as + Broadcast, Unknown Unicast, and Multicast (BUM) traffic is initiated + from that MAC address, it is flooded to all other PEs (both VPLS and + EVPN PEs), and the receiving PEs update their MAC tables (VSI or + MAC-VRF). The EVPN PEs do not advertise the C-MAC addresses learned + over the PW to each other because every EVPN PE learns them directly + over its associated PW to that VPLS PE. If only known unicast + traffic is initiated from the moved C-MAC address toward a known + C-MAC, the result can be the black-holing of traffic destined to the + C-MAC that has moved until there is BUM traffic that has been + originated with the moved C-MAC address as the source MAC address + (e.g., as a result of the MAC age-out timer expiring). Such + black-holing happens for traffic destined to the moved C-MAC from + both EVPN and VPLS PEs and is typical for VPLS PEs. + + When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon + as any traffic is initiated from that C-MAC address, the C-MAC is + learned and advertised in the BGP to other EVPN PEs, and the MAC + mobility procedure is performed among EVPN PEs. For BUM traffic, + both EVPN and VPLS PEs learn the new location of the moved C-MAC + address; however, if there is only known unicast traffic, then only + EVPN PEs learn the new location of the C-MAC that has moved and not + VPLS PEs. This can result in the black-holing of traffic sent from + VPLS PEs destined to the C-MAC that has moved until there is BUM + + + +Sajassi, et al. Standards Track [Page 9] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + traffic originated with the moved C-MAC address as the source MAC + address (e.g., as a result of the MAC age-out timer expiring). Such + black-holing happens for traffic destined to the moved C-MAC for only + VPLS PEs but not for EVPN PEs and is typical for VPLS PEs. + +3.4. Multicast Operation + +3.4.1. Ingress Replication + + The procedures for multicast operation on the VPLS PE using ingress + replication are per [RFC4761], [RFC4762], and [RFC7080]. + + The procedures for multicast operation on the EVPN PE for ingress + replication are as follows: + + - The EVPN PE builds a replication sub-list to all the remote EVPN + PEs per EVPN instance as the result of the exchange of the EVPN + IMET routes per [RFC7432]. This will be referred to as sub-list + A. It comprises MP2P service tunnels (for ingress replication) + used for delivering EVPN BUM traffic [RFC7432]. + + - The EVPN PE builds a replication sub-list per VPLS instance to all + the remote VPLS PEs. This will be referred to as sub-list B. It + comprises PWs from the EVPN PE in question to all the remote VPLS + PEs in the same VPLS instance. + + The replication list, maintained per VPN instance, on a given EVPN PE + will be the union of sub-list A and sub-list B. The EVPN PE MUST + enable split horizon over all the entries in the replication list + across both PWs and MP2P service tunnels. + +3.4.2. P2MP Tunnel + + The procedures for multicast operation on the EVPN PEs using P2MP + tunnels are outside of the scope of this document. + +4. PBB-VPLS Integration with PBB-EVPN + + In order to support seamless integration between PBB-VPLS and + PBB-EVPN PEs, this document requires that PBB-VPLS PEs support VPLS + A-D per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per + [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this + seamless integration shall reside on the PBB-EVPN PEs. + + + + + + + + +Sajassi, et al. Standards Track [Page 10] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + +4.1. Capability Discovery + + The procedures for capability discovery are per Section 3.1. + +4.2. Forwarding Setup and Unicast Operation + + The procedures for forwarding state setup and unicast operation on + the PBB-VPLS PE are per [RFC8077] and [RFC7080]. + + The procedures for forwarding state setup and unicast operation on + the PBB-EVPN PE are as follows: + + - The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE + from which it has received only a VPLS A-D route for the + corresponding VPN instance and MUST set up the label stack + corresponding to the PW FEC. For seamless integration between + PBB-EVPN and PBB-VPLS PEs, the PW that is set up between a pair of + PBB-VPLS and PBB-EVPN PEs is between the B-components of PBB-EVPN + PE and PBB-VPLS PE per Section 4 of [RFC7041]. + + - The PBB-EVPN PE MUST set up the label stack corresponding to the + MP2P VPN unicast FEC to any remote PBB-EVPN PE that has advertised + an EVPN IMET route. + + - If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it + sets up a PW to that PE. If it then receives an EVPN IMET route + from the same PE, the PBB-EVPN PE MUST bring that PW operationally + down. + + - If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS + A-D route from the same PE, then the PBB-EVPN PE will set up the + PW but MUST keep it operationally down. + + - In case VPLS A-D is not used in some PBB-VPLS PEs, the PBB-EVPN + PEs need to be provisioned manually with PWs to those remote + PBB-VPLS PEs for each VPN instance. In that case, if a PBB-EVPN + PE receives an EVPN IMET route from a PE to which a PW exists, the + PBB-EVPN PE MUST bring the PW operationally down. + + - When the PBB-EVPN PE receives traffic over the PBB-VPLS PWs, it + learns the associated B-MAC addresses in the data plane. The + B-MAC addresses learned over these PWs MUST be injected into the + bridge table of the associated MAC-VRF on that PBB-EVPN PE. The + learned B-MAC addresses MAY also be injected into the RIB/FIB + tables of the associated MAC-VRF on that BPP-EVPN PE. For + seamless integration between PBB-EVPN and PBB-VPLS PEs, since + these PWs belong to the same split-horizon group as the MP2P EVPN + service tunnels, the B-MAC addresses learned and associated with + + + +Sajassi, et al. Standards Track [Page 11] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + the PWs MUST NOT be advertised in the control plane to any remote + PBB-EVPN PEs. This is because every PBB-EVPN PE can send and + receive traffic directly to/from every PBB-VPLS PE belonging to + the same VPN instance. + + - The C-MAC addresses learned over local Attachment Circuits (ACs) + by a PBB-EVPN PE are learned in the data plane. For PBB-EVPN PEs, + these C-MAC addresses are learned in the I-component of PBB-EVPN + PEs and are not advertised in the control plane, per [RFC7623]. + + - The B-MAC addresses learned in the control plane via the BGP EVPN + routes sent by remote PBB-EVPN PEs are injected into the + corresponding MAC-VRF table. + + In case of a link failure in a single-active Ethernet segment, the + PBB-EVPN PEs MUST perform both of the following tasks: + + 1. send a BGP B-MAC withdraw message to the PBB-EVPN peers *or* MAC + advertisement with the MAC Mobility extended community + + 2. follow existing VPLS MAC Flush procedures with the PBB-VPLS peers + +4.3. MAC Mobility + + In PBB-EVPN, a given B-MAC address can be learned either over the BGP + control plane from a remote PBB-EVPN PE or in the data plane over a + PW from a remote PBB-VPLS PE. There is no mobility associated with + B-MAC addresses in this context. Hence, when the same B-MAC address + shows up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, + the local PE can deduce that it is an anomaly and SHOULD notify the + operator. + +4.4. Multicast Operation + +4.4.1. Ingress Replication + + The procedures for multicast operation on the PBB-VPLS PE using + ingress replication are per [RFC7041] and [RFC7080]. + + The procedures for multicast operation on the PBB-EVPN PE for ingress + replication are as follows: + + - The PBB-EVPN PE builds a replication sub-list per I-SID to all the + remote PBB-EVPN PEs in a given VPN instance as a result of the + exchange of the EVPN IMET routes, as described in [RFC7623]. This + will be referred to as sub-list A. It comprises MP2P service + tunnels used for delivering PBB-EVPN BUM traffic. + + + + +Sajassi, et al. Standards Track [Page 12] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + - The PBB-EVPN PE builds a replication sub-list per VPN instance to + all the remote PBB-VPLS PEs. This will be referred to as sub-list + B. It comprises PWs from the PBB-EVPN PE in question to all the + remote PBB-VPLS PEs in the same VPN instance. + + - The PBB-EVPN PE may further prune sub-list B on a per-I-SID basis + by running MMRP (see Clause 10 of [IEEE.802.1Q]) over the PBB-VPLS + network. This will be referred to as sub-list C. This list + comprises a pruned set of the PWs in sub-list B. + + The replication list maintained per I-SID on a given PBB-EVPN PE will + be the union of sub-list A and sub-list B if MMRP is not used and the + union of sub-list A and sub-list C if MMRP is used. Note that the PE + MUST enable split horizon over all the entries in the replication + list, across both pseudowires and MP2P service tunnels. + +4.4.2. P2MP Tunnel: Inclusive Tree + + The procedures for multicast operation on the PBB-EVPN PEs using P2MP + tunnels are outside of the scope of this document. + +5. Security Considerations + + All the security considerations in [RFC4761], [RFC4762], [RFC7080], + [RFC7432], and [RFC7623] apply directly to this document because it + leverages the control-plane and data-plane procedures described in + those RFCs. + + This document does not introduce any new security considerations + beyond those of the above RFCs because the advertisements and + processing of MAC addresses in BGP follow [RFC7432], and the + processing of MAC addresses learned over PWs follows [RFC4761], + [RFC4762], and [RFC7080]. + +6. IANA Considerations + + This document has no IANA actions. + + + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 13] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + +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>. + + [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>. + + [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and + Maintenance Using the Label Distribution Protocol (LDP)", + STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, + <https://www.rfc-editor.org/info/rfc8077>. + + + + + + +Sajassi, et al. Standards Track [Page 14] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + + [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>. + +7.2. Informative References + + [IEEE.802.1Q] + IEEE, "IEEE Standard for Local and Metropolitan Area + Network -- Bridges and Bridged Networks", IEEE + Standard 802.1Q, DOI 10.1109/IEEESTD.2018.8403927, July + 2018. + + [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>. + + [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual + Private LAN Service (VPLS) Interoperability with Provider + Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080, + December 2013, <https://www.rfc-editor.org/info/rfc7080>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 15] + +RFC 8560 (PBB-)EVPN and (PBB-)VPLS Integration May 2019 + + +Authors' Addresses + + Ali Sajassi (editor) + Cisco + + Email: sajassi@cisco.com + + + Samer Salam + Cisco + + Email: ssalam@cisco.com + + + Nick Del Regno + Verizon + + Email: nick.delregno@verizon.com + + + Jorge Rabadan + Nokia + + Email: jorge.rabadan@nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 16] + |