BESS Working Group A. Sajassi Internet Draft S. Salam Category: Standard Track P. Brissette Cisco L. Jalil Verizon Expires: January 2, 2018 July 2, 2017 (PBB-)EVPN Integration with (PBB-)VPLS in All-Active Mode draft-sajassi-bess-evpn-vpls-all-active-00 Abstract This draft discusses the backward compatibility of the (PBB-)EVPN solution with (PBB-)VPLS in all-active redundancy mode. 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 Copyright and License Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Sajassi et al. Expires January 2, 2018 [Page 1] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Solution for MAC Flip-Flopping . . . . . . . . . . . . . . . . . 4 3.1 Load-Balancing . . . . . . . . . . . . . . . . . . . . . . . 5 4 Changes on EVPN PEs . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Control Plane Changes . . . . . . . . . . . . . . . . . . . 5 4.2 Data Plane Changes . . . . . . . . . . . . . . . . . . . . . 6 4.2.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . 6 4.2.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . 6 5 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . 7 6 EVPN-VPWS termination onto multi-homing EVPN PEs . . . . . . . . 7 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Sajassi et al. Expires January 2, 2018 [Page 2] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 1 Introduction VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many SPs who are looking at adopting EVPN and PBB-EVPN want to preserve their investment in the (PBB-)VPLS networks. Hence, it is required to provide mechanisms by which (PBB-)EVPN technology can be introduced into existing L2VPN networks without requiring a fork-lift upgrade. [EVPN-VPLS] discusses mechanisms for the seamless integration of the two technologies in the same MPLS/IP network, however, operation is limited to single-active redundancy mode. In this document, we extend the solution to support all-active redundancy. Section 2 provides the limitations in the current (PBB-)EVPN/(PBB- )VPLS interoperability solution. Section 3 discusses the solution for addressing those limitations. Section 4 describes the required control and data plane changes to support all-active redundancy. Section 5 covers the failure handling. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 Limitations [EVPN-VPLS] defines mechanisms for (PBB-)EVPN seamless interoperability with (PBB-)VPLS. The solution defined in [EVPN-VPLS] suffers from a major limitation that hinders brown-field deployment of EVPN solution: It provides support for all-active redundancy only for VPN instances confined to (PBB-)EVPN PEs. For VPN instances that span both (PBB-)EVPN as well as (PBB-)VPLS PEs only single-active redundancy mode is supported. This eliminates one of the key value propositions of inserting EVPN solution in existing networks. The reason why this capability is not currently supported is due to the issue of MAC address flip-flopping on the VPLS PEs. This is best explained with an example: Consider the example network of Figure 1 below. Assume that CE1 is connected over an all-active link aggregation group (LAG) to EVPN-capable PEs (PE2 and PE3). For traffic destined from CE1 to CE2, different flows from the same source MAC address MAC-A will be load-balanced over the LAG to PE2 and PE3. PE2 will forward the traffic over its own pseudowire (call it PW-Blue) to PE5, whereas PE3 will forward the traffic over its own pseudowire (call it PW-Red) to PE5. As such, VPLS PE (PE5) will learn the same MAC address (MAC-A) over both PW-Red and PW-Blue, depending on the load-balancing. This MAC flip-flopping will continue Sajassi et al. Expires January 2, 2018 [Page 3] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 indefinitely depending on traffic patterns. VPLS PE +---+ |PE1| +---+ / EVPN/VPLS PE +---------------+ VPLS PE +---+ | | +---+ +---+ |PE4|----| MPLS/IP |---|PE5|----|CE2| MAC-D +---+ | Core | +---+ +---+ | | +---------------+ / \ +---+ +---+ |PE2| |PE3| +---+ +---+ EVPN/VPLS PE EVPN/VPLS PE \ / \ / \ / +---+ |CE1| MAC-A +---+ Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS The focus of this draft is on providing a solution that addresses the above limitation, thereby enabling the support of all-active redundancy in mixed (PBB-)EVPN/(PBB-)VPLS deployments. 3 Solution for MAC Flip-Flopping In order to address the MAC flip-flopping problem on the VPLS PEs, these PEs must learn the traffic originating from a given source MAC address over the same pseudowire consistently, regardless of which remote EVPN-capable PE forwarded the traffic in a given multi-homed setup. To that end, every multi-homed EVPN-capable PE must maintain, in addition to its own pseudowires, a set of shadow or "alias" pseudowires for each of its peers in a given Redundancy Group (RG). For instance, in the example network of Figure 1, PE2 maintains its own pseudowire towards PE5 in addition to an "alias" pseudowire corresponding to the pseudowire between PE3 and PE5. When traffic arrives from a multi-homed CE over a multi-chassis LAG, the EVPN-capable PE then examines whether or not it is the Designated Forwarder (DF) for the Ethernet Segment (ES) in question. In the case Sajassi et al. Expires January 2, 2018 [Page 4] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 where the PE is the DF for the ES, it would use its own pseudowire label to forward traffic towards a remote VPLS PE. However, in the case where the PE is not the DF for the ES, it would then use the "alias" pseudowire label associated with the DF PE in order to forward traffic towards the remote VPLS PE. To illustrate this using the example of Figure 1, consider that PE3 is the DF for the ES associated with CE1. Furthermore, assume that the pseudowire labels from PE2 and PE3 to PE5 are Label-Blue and Label-Red, respectively. When CE1 load-balances traffic destined to CE2 towards PE3, the latter will use its own pseudowire label (Label-Red) to forward traffic to PE5. Whereas, when CE1 forwards traffic destined to CE2 towards PE2, it will use the alias pseudowire label (Label-Red) instead of its own pseudowire label to forward traffic towards PE5. This is because PE2 is not the DF for the Ethernet Segment associated with CE1. 3.1 Load-Balancing For traffic flowing from the EVPN-capable PEs towards the MPLS network, the load-balancing is on a per-flow granularity, regardless of whether the traffic is destined towards remote EVPN or VPLS PEs. For traffic flowing from the VPLS PEs towards the EVPN-capable PEs, the load-balancing is on a per-VLAN per destination site granularity. That is, the traffic for a given VLAN in a destination site is sent to only one of the multi-homed EVPN-capable PEs. This is because all the EVPN-capable PEs in a given redundancy group will use the the pseudowire label associated with the DF to forward traffic towards remote VPLS PEs (recall, also, that EVPN DF election is per VLAN per ES). 4 Changes on EVPN PEs The changes to support the mechanisms of this draft are confined to the EVPN-capable PEs. In the following two sub-sections we cover both the control plane as well as data plane changes required. 4.1 Control Plane Changes In order for the EVPN-capable PEs to maintain the alias pseudowires, it is required to synchronize the VPLS pseudowire labels among the PEs in the same Redundancy Group. For VPLS-BGP [RFC4761], this is straight-forward to achieve because the VE-IDs and label blocks associated with all PEs are advertised in BGP. Hence, a PE in an EVPN RG can easily extract the alias pseudowire labels associated with its peers in the same RG. For VPLS-LDP [RFC4762], protocol message extensions are required but are outside the scope of the current document. Sajassi et al. Expires January 2, 2018 [Page 5] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 Another control plane extension that is required is to synchronize the MAC addresses learnt over the active pseudowire at DF EVPN PEs to the non-DF EVPN PEs with alias pseudowire using BGP. This can be done using the existing EVPN MAC Advertisement route. The identity of the pseudowire over which the address was learnt is encoded in the ESI field. This can be done using a Type 4 ESI, where the Router ID holds the IP address of the remote pseudowire endpoint IP address (i.e. VPLS PE address) and the high-order 2 octets of the Local Discriminator encode the VE-ID of the remote pseudowire endpoint (i.e. EVPN-capable PE that is the DF). 4.2 Data Plane Changes 4.2.1 Known Unicast Traffic After DF election is complete, the EVPN-capable PE programs its data plane based on the outcome of DF election as follows: If known unicast traffic is received by the PE from an Ethernet Segment for which it is the DF, then it uses its own pseudowire label in the label stack when forwarding traffic to remote VPLS PEs. If known unicast traffic is received by the PE from an Ethernet Segment for which is non-DF, then it uses the alias pseudowire label (associated with the DF) instead of its own pseudowire label in the label stack when forwarding traffic to remote VPLS PEs. In other words, the EVPN-capable PE must use the DF/non-DF status of the incoming attachment circuit interface in order to choose the correct label stack for VPLS forwarding. 4.2.2 BUM Traffic The EVPN-capable PEs must maintain two replication lists: one that uses their own pseudowires, and another that uses the alias pseudowires. When BUM traffic is received from the attachment circuit, the PE examines the DF status of the incoming interface to identify which of the two replication lists to use: If the PE is the DF, then it uses the replication list which encompasses its own pseudowires. Whereas, if the PE is non-DF, then it uses the replication list encompassing the alias pseudowires. BUM traffic received over a VPLS pseudowire is handled as follows: Broadcast and multicast traffic is identified as such by inspecting the destination MAC address, and is handled as usual per EVPN MPLS ingress flooding mechanisms. At egress to the attachment circuit, all broadcast and multicast VPLS traffic is subjected to DF filtering Sajassi et al. Expires January 2, 2018 [Page 6] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 procedures per existing EVPN procedures. Unknown unicast traffic cannot be identified as such by the disposition PE on egress from the pseudowire, since nothing in the Ethernet frame or the MPLS label stack (unlike EVPN) distinguishes this traffic from known unicast. Furthermore, the disposition PE cannot rely on its own MAC forwarding table to infer whether the frame was flooded or not - i.e., an unknown MAC address on the imposition PE cannot be known to the disposition PE. Due to this, the egress (disposition) PE will treat unicast MAC addresses based on its own local forwarding state - i.e., if the MAC address is known locally, then it is treated as such and if the MAC address is unknown locally, then it is treated as BUM traffic and will apply DF filtering. This can lead to a side-effect for a very specific scenario where the MAC-DA is unknown at the ingress PE but it is known to the egress multi-homing PEs (i.e., there is no issue when MAC-DA is known at the ingress and unknown at the egress, or MAC-DA is unknown at both the ingress and egress PEs). In such a specific scenario, a multi-homed CE will experience duplicate packets for an interim period of time until the remote VPLS PE learns the MAC address from reverse traffic. The CE's application layer will handle the discard of transient duplicate frames. While it is acknowledged that this behavior deviates from classical Ethernet, which guarantees the absence of packet duplication, the side-effect occurs in very specific scenario and it is both short-lived and confined in scope to the PE/CE links. Hence, it is a reasonable trade-off to accept in favor of enabling all-active redundancy in the solution. 5 Failure Handling Failure handling follows standard EVPN and VPLS procedures: For link failure on DF EVPN-capable PE, the PE sends a mass withdraw indication using per ES Ethernet A-D route to other EVPN PEs, causing them to update their forwarding entries to point to only the non-DF PE. The DF PE also sends VPLS MAC address flush message to remote VPLS PEs, causing them to flush their entries. The non-DF EVPN PE takes over and assumes the DF role. It uses its own VPLS pseudowire labels for sending traffic towards the VPLS PEs. For link failure on non-DF EVPN PE, the PE sends mass withdraw per ES Ethernet A-D route to other EVPN PEs, causing them to update their forwarding entries to point to only the DF PE. Nothing is done with respect to the VPLS PEs, as this failure is transparent to them. 6 EVPN-VPWS termination onto multi-homing EVPN PEs This section will be added in the future revision to describe how the MAC synchroniation Sajassi et al. Expires January 2, 2018 [Page 7] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 mechanism over PW described above can be used for this scenario. 7 Security Considerations 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 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [EVPN-VPLS] Sajassi, A., Salam, S., Del Regno, N., and Rabadan, J., "(PBB-)EVPN Seamless Integration with (PBB-)VPLS", draft- ietf-bess-evpn-vpls-seamless-integ-00, work in progress, February 2015, . 9.2 Informative References Authors' Addresses Ali Sajassi Cisco 170 West Tasman Drive Sajassi et al. Expires January 2, 2018 [Page 8] INTERNET DRAFT draft-sajassi-bess-evpn-vpls-all-active July 2, 2017 San Jose, CA 95134, US Email: sajassi@cisco.com Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1, Canada Email: ssalam@cisco.com Patrice Brissette Cisco Email: pbrisset@cisco.com Luay Jalil Cisco Email: luay.jalil@verizon.com Sajassi et al. Expires January 2, 2018 [Page 9]