INTERNET-DRAFT Ali Sajassi Intended Status: Standard Track Samer Salam Cisco Nick Del Regno Verizon Jorge Rabadan Alcatel-Lucent Expires: September 29, 2018 March 29, 2018 (PBB-)EVPN Seamless Integration with (PBB-)VPLS draft-ietf-bess-evpn-vpls-seamless-integ-02 Abstract This draft specifies procedures for backward compatibility of the (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for seamless integration of the two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce (PBB-)EVPN PEs in their brownfield deployments of (PBB-)VPLS networks. Status of this Memo This Internet-Draft is submitted to IETF 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 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 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Sajassi et al. Expires September 29, 2018 [Page 1] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 Copyright and License Notice Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 7 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 3.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 8 3.3.2 P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . . 9 4 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 9 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 9 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 9 4.2.1 MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 10 4.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 10 4.3.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 10 5 VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . . . 10 5.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 10 5.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 11 5.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 11 5.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 11 5.3.2 P2MP Tunnel - Inclusive Tree . . . . . . . . . . . . . . 11 6 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 11 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12 9.2 Informative References . . . . . . . . . . . . . . . . . . 12 Sajassi et al. Expires September 29, 2018 [Page 2] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Sajassi et al. Expires September 29, 2018 [Page 3] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 1 Introduction VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many Service Providers (SPs) who are looking at adopting EVPN and PBB-EVPN want to preserve their investment in the (PBB-)VPLS networks. Hence, they require procedures by which (PBB-)EVPN technology can be introduced into their brownfield (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. 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 PEs & (PBB-)VPLS Section 2 provides the details of the requirements. Section 3 specifies procedures for the seamless integration of PBB-VPLS and PBB-EVPN networks. Section 4 specifies procedures for the seamless integration of VPLS and EVPN networks. Section 5 specifies procedures for the seamless integration of VPLS and PBB-EVPN networks, and finally Section 6 discusses the solution advantages. It is worth noting that the scenario where PBB-VPLS is integrated with EVPN, is not covered in this draft because there hasn't been any requirement from service providers for such integration. The reason for that is that deployments which employ PBB-VPLS typically require PBB encapsulation for various reasons. Hence, it is expected that for those deployments the evolution path would be from PBB-VPLS towards PBB-EVPN, rather than EVPN. 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Sajassi et al. Expires September 29, 2018 [Page 4] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 "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. Terms and Abbreviations B-MAC: Backbone MAC B-VID: Backbone VLAN ID 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.1ah]. Bridge Table: An instantiation of a broadcast domain on a MAC-VRF. CE: A Customer Edge device, e.g., a host, router, or switch. EVI: An EVPN Instance spanning the Provider Edge (PE) devices participating in that EVPN. MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on an EVPN PE. MAC address: Media Access Control address ES: When a customer site (device or network) is connected to one or more PEs via a set of Ethernet links, then that set of links is referred to as an "Ethernet Segment". ESI: An Ethernet Segment Identifier is a unique non-zero identifier that identifies an ES Ethernet Tag: An Ethernet Tag identifies a particular broadcast domain, e.g., a VLAN. An EVPN instance consists of one or more broadcast domains P2MP: Point-to-Multipoint PBB: Provider Backbone Bridge PE: Provider Edge device VSI: Virtual Switch Instance Sajassi et al. Expires September 29, 2018 [Page 5] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 VPLS: Virtual Private LAN Service 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 to be operating in Single-Active redundancy mode. 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 to be operating in All-Active redundancy mode. 2. Requirements 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 PEs. 2. The solution MUST require no changes to existing VPLS or PBB-VPLS PEs, not even a software upgrade. 3. The solution MUST allow for the coexistence of PEs running (PBB- )EVPN and (PBB-)VPLS for the same VPN instance and single-homed segments. 4. The solution MUST support single-active redundancy of multi-homed networks and multi-homed devices for (PBB-)EVPN PEs. 5. In case of single-active redundancy, the participant VPN instances MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as single-active redundancy is employed by (PBB-)EVPN PEs. In case of an ES link failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN peers OR MAC advertisement with MAC Mobility extended community for PBB-EVPN AND an LDP MAC withdrawal to the VPLS peers. 6. The solution SHOULD support All-Active redundancy mode of multi- homed networks and multi-homed devices for (PBB-)EVPN PEs. In case of All-Active redundancy mode, the participant VPN instances SHOULD be confined to (PBB-)EVPN PEs only. These requirements collectively allow for the seamless insertion of the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. Sajassi et al. Expires September 29, 2018 [Page 6] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 3 PBB-VPLS Integration with PBB-EVPN In order to support seamless integration with (PBB-)VPLS PEs, the (PBB-)EVPN PEs MUST support EVPN BGP routes (EVPN SAFI) and VPLS AD route (VPLS SAFI). All the logic for this seamless integration SHALL reside on the (PBB-)EVPN PEs. However, if a VPLS instance is setup without the use of BGP auto-discovery, it is still possible (but cumbersome) for (PBB-)EVPN PEs to integrate into that VPLS instance. 3.1 Capability Discovery The (PBB-)EVPN PEs MUST advertise both the BGP VPLS auto-discovery (AD) route as well as the BGP EVPN Inclusive Multicast route for a given VPN instance. The (PBB-)VPLS PEs only advertise the BGP VPLS AD route, per current standard procedures specified in [RFC4761] and [RFC6074]. The operator may decide to use the same BGP RT to identify a VPN on both (PBB-)EVPN and (PBB-)VPLS networks. In this case, when a (PBB-)VPLS PE receives the EVPN Inclusive Multicast route, it will ignore it on the basis that it belongs to an unknown SAFI. However, the operator may choose to use two RTs - one to identify the VPN on (PBB-)VPLS network and another for (PBB-)EVPN network and employ RT- constraint in order to prevent EVPN BGP routes from reaching the (PBB-)VPLS PEs. When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN Inclusive Multicast 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 (PBB-)EVPN capable PEs discover other (PBB-)EVPN capable PEs in addition to the (PBB-)VPLS-only PEs for that VPN instance. Furthermore, all the (PBB-)VPLS-only PEs would discover the (PBB- )EVPN PEs as if they were standard (PBB-)VPLS PEs. In other words, when the discovery phase is complete, the (PBB-)EVPN PEs would have discovered all the PEs in the VPN instance along with their associated capability: (PBB-)EVPN or VPLS-only. Whereas the (PBB- )VPLS PEs would 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 forwarding 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 pseudowire to a remote PE from Sajassi et al. Expires September 29, 2018 [Page 7] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 which it has received only a VPLS AD route for the corresponding VPN instance, and MUST set up the label stack corresponding to the pseudowire FEC. For seamless integration between PBB-EVPN and PBB- VPLS PEs, this PW is between 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 PE that has advertised EVPN AD route. - If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD route from the same PE and a pseudowire is setup to that PE, then the (PBB-)EVPN MUST bring that pseudowire operationally down. - If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD route from the same PE, then the (PBB-)EVPN PE will setup the pseudowire but MUST keep it operationally down. When the (PBB-)EVPN PE receives traffic over the pseudowires, it learns the associated MAC addresses in the data-plane. This is analogous to dynamic learning in IEEE bridges. The MAC addresses learned over PWs are not injected into (PBB-)EVPN MAC-VRF tables but rather they are injected into their corresponding (PBB-)VPLS VSI table. If the core-facing PW belongs to the same split-horizon group as the core-facing MP2P EVPN service tunnels, then the MAC addresses learned and associated to the PW will NOT be advertised in the control plane to any remote (PBB-)EVPN PE. 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 MAC addresses learned over local Attachment Circuits (ACs) by a (PBB-)EVPN PE are advertised in control plane using BGP EVPN routes to other (PBB-)EVPN PEs. Furthermore, the 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. This is analogous to static learning in IEEE bridges. In PBB-EVPN, a given B- MAC address can be learnt either over the BGP control-plane from a remote PBB-EVPN PE, or in the data-plane over a pseudowire 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 notify the operator. 3.3 Multicast Operation 3.3.1 Ingress Replication The procedures for multicast operation on the (PBB-)VPLS PE, using ingress replication, are per [RFC4761], [RFC4762], and [RFC7080]. Sajassi et al. Expires September 29, 2018 [Page 8] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 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 Inclusive multicast 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 [RFC7432]. - The PBB-EVPN PE builds a replication sub-list per VPN instance to all the remote PBB-VPLS PEs , as a result of the exchange of the VPLS AD routes. This will be referred to as sub-list B. It comprises pseudowires 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, if [MMRP] is run over the PBB-VPLS network. This will be referred to as sub-list C. This list comprises a pruned set of the pseudowires 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. 3.3.2 P2MP Tunnel The procedures for multicast operation on the PBB-EVPN PEs using P2MP tunnels are outside of the scope of this document. 4 VPLS Integration with EVPN 4.1 Capability Discovery The procedures for capability discovery are per Section 3.1 above. 4.2 Forwarding Setup and Unicast Operation The operation here is largely similar to that of PBB-EVPN integration with PBB-VPLS, with one major exception in handling MAC mobility that is described in the next section. - For seamless integration among EVPN and VPLS PEs, the PW that is setup between a pair of VPLS and EVPN PEs is between VSI of VPLS PE and MAC-VRF of EVPN PE. 4.2.1 MAC Mobility Sajassi et al. Expires September 29, 2018 [Page 9] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 Contrary to PBB-EVPN, where the association between a B-MAC and a PBB-EVPN PE is fixed and thus there is no B-MAC mobility, in EVPN, host addresses (C-MAC addresses) can move around among EVPN PEs or even between EVPN and VPLS PEs. When a MAC address moves from an EVPN PE to a VPLS PE, then as soon as 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 MAC address learned over PW to each other because every EVPN PE learns it directly over its associated PW to that VPLS PE. If only known-unicast traffic is initiated from the moved MAC address toward a known MAC, then this can result in black-holing of traffic destined to the MAC that has moved until the MAC age-out timer expires but this is the typical behavior of VPLS PEs. When a host MAC address moves from a VPLS PE to an EVPN PE, then as soon as BUM or known-unicast traffic is initiated from that MAC address, the MAC is learned and advertised in BGP to other EVPN PEs and MAC mobility procedure is exercised among EVPN PEs. For BUM traffic, both EVPN and VPLS PES learn the new location of the moved MAC address; however, if there is only known-unicast traffic, then only EVPN PEs learn the new location of the MAC that has moved but not VPLS PEs. This can result in black-holing of traffic sent from VPLS PEs destined to the MAC that has moved until the MAC age-out timer expires but this is the typical behavior of VPLS PEs. 4.3 Multicast Operation 4.3.1 Ingress Replication The operation is per the procedures of Section 3.3.1 above for the scenario WITHOUT [MMRP]. The replication list is maintained per VPN instance rather than per I-SID. 4.3.2 P2MP Tunnel - Inclusive Tree The procedures for multicast operation on the EVPN PEs using P2MP tunnels are outside of the scope of this document. 5 VPLS Integration with PBB-EVPN 5.1 Capability Discovery The procedures for capability discovery are per Section 3.1 above. Sajassi et al. Expires September 29, 2018 [Page 10] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 5.2 Forwarding Setup and Unicast Operation The operation here is largely similar to that of PBB-EVPN integration with PBB-VPLS, with a few exceptions listed below: - When a PW is setup between a PBB-EVPN PE and a VPLS PE, it gets setup between the I-component of PBB-EVPN PE and the VSI of VPLS PE. - The MAC mobility aspect is the same as that of VPLS network or PBB- VPLS network since in both cases the host MAC (C-MAC) learning over MPLS/IP core is done via data-plane learning. 5.3 Multicast Operation 5.3.1 Ingress Replication The operation is per the procedures of Section 3.3.1 above for the scenario WITHOUT [MMRP]. The replication list is maintained per I-SID on the PBB-EVPN PEs and per VPN instance on the VPLS PEs. 5.3.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. 6 Solution Advantages The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS has the following advantages: - When ingress replication is used for multi-destination traffic delivery, the solution reduces the scope of [MMRP] (which is a soft- state protocol) 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 multi-homing mechanisms and provisioning simplifications of PBB-EVPN: a. Auto-sensing of MHN / MHD b. Auto-discovery of redundancy group c. Auto-provisioning in DF election and VLAN carving 7 Security Considerations Sajassi et al. Expires September 29, 2018 [Page 11] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 No new security considerations beyond those for VPLS and EVPN. 8 IANA Considerations This document has no actions for IANA. 9 References 9.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 . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8077] Martini, et al., "Pseudowire Setup and Maintenance using the Label Distribution Protocol", RFC 8077, February 2017. [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, February, 2015. [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015. [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007, . [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, . [RFC6074] Rosen et al., "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. 9.2 Informative References Sajassi et al. Expires September 29, 2018 [Page 12] INTERNET DRAFT draft-ietf-bess-evpn-vpls-seamless-integ March 29, 2018 [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2013. [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider Backbone Bridging", RFC 7041, November 2013. [RFC7080] Sajassi et al., "VPLS Interoperability with Provider Backbone Bridges", RFC 7080, December, 2013. [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146. Authors' Addresses Ali Sajassi 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. Expires September 29, 2018 [Page 13]