BESS Working Group J. He, Ed. Internet-Draft B. Nie Intended status: Standards Track Ericsson Expires: December 5, 2020 June 3, 2020 EVPN Split Horizon Filtering Enhancement draft-jiang-bess-evpn-split-horizon-enhancement-00 Abstract Ethernet Virtual Private Network (EVPN) multi-homing accommodates load balance, link/node redundancy and fast convergence. The split horizon filtering in EVPN avoids loop happens on multi-homed CE. However, this mechanism brings challenges switching chipsets on data plane. This document describes an approach for the challenges by enhancing current split horizon filtering mechanism. The advantage of this approach is that it simplifies data plane behaviors. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 5, 2020. Copyright Notice Copyright (c) 2020 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 He & Nie Expires December 5, 2020 [Page 1] Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Advertising EVPN VRF Route Import Extended Community . . 4 4.2. Constructing IMET Routes . . . . . . . . . . . . . . . . 4 4.3. Flooding Handling on Data Plane . . . . . . . . . . . . . 5 5. EVPN VRF Route Import Extended Community . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. EVPN VRF Route Import Extended Community . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Ethernet Virtual Private Network (EVPN) multi-homing accommodates load balance, link/node redundancy and fast convergence. The split horizon filtering in EVPN avoids loop happens on multi-homed CE. In particular, there are two split horizon filtering mechanisms to avoid looped frames on the multi-homed CE: ESI Label based [RFC7432] for MPLS based tunnels and Local Bias[RFC8365] for non-MPLS NVO tunnels, E.g. VXLAN tunnels. However, each mechanism introduces challenges for data plane because extra logic is introduced but not available on some typical switching chipsets. ESI Label based mechanism requires ingress PE to push ESI label into MPLS stack to indicate Ethernet Segment Identifier, and requires egress PE to filter out the corresponding port based on ESI label before flooding. Local Bias does not require ingress PE to have extra procedure but still requires egress PE to filter out the corresponding ports based on source IP address before flooding. This document describes an approach towards the challenges, by enhancing current Local Bias split horizon filtering mechanism, for MPLS based tunnels and non-MPLS NVO tunnels. The advantage of this approach is that it simplifies data plane behaviors. 2. 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 He & Nie Expires December 5, 2020 [Page 2] Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. BUM: Broadcast, Unknown unicast and Multicast CE: Customer Edge device, e.g., a host, router, or switch. Ethernet Segment (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'. Ethernet Segment Identifier (ESI): A unique non-zero identifier that identifies an Ethernet segment is called an 'Ethernet Segment Identifier'. EVI: An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN. EVPN: Ethernet Virtual Private Network NVO: Network Virtualization Overlay PE: Provider Edge device. VXLAN: Virtual Extensible LAN NVGRE: Network Virtualization using Generic Routing Encapsulation VNI: VXLAN Network Identifier VSID: Virtual Subnet Identifier (for NVGRE) 3. Approach When the PE advertises Inclusive Multicast Ethernet Tag (IMET) Routes to PEs which share the same multi-homed CE, it allocates unique label for each PE, rather than using the same label for all PEs. To accomplish this, An EVPN VRF Route Import Extended Community is introduced. When the PE receives BUM packet from ingress PE, based on the BUM label encapsulated, it can determine the packet is from PEs which share the same multi-homed CE or not. If yes, the PE can also determine which PE the packet is from. Because the PE has determined the ingress PE, Local Bias based mechanism can be implemented for split horizon filtering without source IP information, but simply based on a single BUM label to determine the flooding scope. He & Nie Expires December 5, 2020 [Page 3] Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020 For NVO solution, this approach requires locally assigned VNIs to be used just like downstream-assigned MPLS labels. Based on this extended mechanism, for MPLS based tunnels, no ESI label encapsulation is required on ingress PE either. 4. Procedures Let's suppose an EVPN network, where CE1 is multi-homed to PE1 and PE2 with all-active mode, CE2 and CE3 are single-homed to PE2 and PE3 separately. +--------------+ /--- PE1 | | CE1 | EVPN | PE3 --- CE3 \--- PE2 | | | +--------------+ CE2 Figure 1: Sample EVPN Multi-homing Scenario 4.1. Advertising EVPN VRF Route Import Extended Community In order to receive IMET route with unique label assigned by multi- homed peer, each VRF on PE1 MUST have an import Route Target Extended Community, and communicate the value to all other multi-homed peers. We refer to this Route Target as the "EVPN IMET Import RT", as this Route Target controls imports of EVPN IMET routes into a particular VRF. To communicate the value to all other multi-homed peers, PE1 when advertising an Ethernet Auto-discovery Route per EVI SHALL carry the EVPN VRF Route Import Extended Community (as defined in Section 5) that has the value of the EVPN IMET Import RT of the VRF associated with the route. 4.2. Constructing IMET Routes Once EVPN routes with EVPN VRF Route Import Extended Community received on PE2, PE2 extracts the value of the EVPN VRF Route Import Extended Community. The value of EVPN IMET Import RT is set to this value. Besides advertising IMET routes to other PEs as usual, PE2 advertises IMET route with unique BUM label to each multi-homed peer (here only PE1) by using EVPN IMET Import RT as route target. It is suggested He & Nie Expires December 5, 2020 [Page 4] Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020 to set a higher LOCAL_PREF for this BGP message, if another general IMET route is sent to PE1 also. Now suppose PE3 receives IMET route with label BUM0 from PE2, and PE1 receives IMET route with label BUM1 from PE2. 4.3. Flooding Handling on Data Plane Once PE2 advertises all IMET routes, including general and unique ones, it sets data plane to handle BUM labels as figure 2 described below (Suppose it is the Designated Forwarder). +-----------+-------------+ | In Label | Out Ports | +-----------+-------------+ (from PE3) -> | BUM0 | CE1, CE2 | +-----------+-------------+ (from PE1) -> | BUM1 | CE2 | +-----------+-------------+ Figure 2: Flooding handling on PE2 Data Plane Now BUM traffic is properly handled, no matter from multi-homed peers (E.g. PE1) or other PEs (E.g. PE3). Unlike ESI Label based or Local Bias which requires two parameters for flooding decision, this flooding behavior requires only one parameter, the single BUM label. 5. EVPN VRF Route Import Extended Community This document defines a new BGP Extended Community called "EVPN VRF Route Import". The EVPN VRF Route Import is an IP-address-specific Extended Community, of an extended type, and is transitive across AS boundaries [RFC4360]. The EVPN VRF Route Import Extended Community has following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type=TBD | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ He & Nie Expires December 5, 2020 [Page 5] Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020 This document expands the definition of EVPN Extended Community [RFC7153]. This Extended Community has a Type field value of 0x06 and the Sub-Type TBD. The Global Administrator field of the EVPN VRF Route Import EC MUST be set to an IP address of the PE. This address SHOULD be common for all the VRFs on the PE (e.g., this address may be the PE's loopback address).The Local Administrator field of the EVPN VRF Route Import EC associated with a given VRF contains a 2-octet number that uniquely identifies that VRF within the PE. For procedures and usage of this attribute, please see Section 4 6. IANA Considerations 6.1. EVPN VRF Route Import Extended Community This document makes the following registrations for EVPN VRF Route Import Extended Community. Type Description ---- ----------- TBD EVPN VRF Route Import Extended Community 7. Security Considerations If BGP is used as a CE-PE routing protocol, then when a PE receives a route from a CE, if this route carries the EVPN VRF Route Import Extended Community, the PE MUST remove this Community from the route before turning it into a VPF. Routes that a PE advertises to a CE MUST NOT carry the EVPN VRF Route Import Extended Community. 8. 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, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, . He & Nie Expires December 5, 2020 [Page 6] Internet-Draft EVPN Split Horizon Filtering Enhancement June 2020 [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . Authors' Addresses Jiang He (editor) Ericsson No. 5, Lize east street, Chaoyang district Beijing 100102 CN Email: jiang.he@ericsson.com Bolin Nie Ericsson No. 5, Lize east street, Chaoyang district Beijing 100102 CN Email: zephyr.nie@ericsson.com He & Nie Expires December 5, 2020 [Page 7]