BESS Workgroup J. Rabadan, Ed. Internet-Draft K. Nagaraj Updates: 8365, 7432 (if approved) Nokia Intended status: Standards Track W. Lin Expires: 17 February 2025 Juniper A. Sajassi Cisco 16 August 2024 BGP EVPN Multi-Homing Extensions for Split Horizon Filtering draft-ietf-bess-evpn-mh-split-horizon-11 Abstract Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The multi-homing procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multi-homing Split Horizon procedures designed to prevent looped frames on multi-homed Customer Edge (CE) devices: the ESI Label-based procedure and the Local Bias procedure. The ESI Label-based Split Horizon is applied to MPLS-based tunnels, such as MPLSoUDP, while the Local Bias procedure is used for other tunnels, such as VXLAN. Current specifications do not allow operators to choose which Split Horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoGRE, MPLSoUDP, GENEVE, and SRv6. This document updates the EVPN multi-homing procedures described in RFC 8365 and RFC 7432, enabling operators to select the Split Horizon procedure that meets their specific requirements. 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." Rabadan, et al. Expires 17 February 2025 [Page 1] Internet-Draft EVPN MH Split Horizon Extensions August 2024 This Internet-Draft will expire on 17 February 2025. Copyright Notice Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 1.2. Split Horizon Filtering and Tunnel Encapsulations . . . . 5 2. BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . . 9 2.1. The Split Horizon Type . . . . . . . . . . . . . . . . . 9 2.2. Use of the Split Horizon Type In A-D Per ES Routes . . . 10 2.3. ESI Label Value In A-D Per ES Routes . . . . . . . . . . 12 2.4. Backwards Compatibility With RFC8365 NVEs . . . . . . . . 12 3. Procedures for NVEs Supporting Multiple Encapsulations . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Ethernet Virtual Private Networks (EVPN) are commonly used with the following tunnel encapsulations: * Network Virtualization Overlay (NVO) tunnels, where the EVPN procedures are specified in [RFC8365]. MPLSoGRE [RFC4023], MPLSoUDP [RFC7510], GENEVE [RFC8926] or VXLAN [RFC7348] tunnels are considered NVO tunnels. * MPLS and Segment Routing with MPLS data plane (SR-MPLS), where the relevant EVPN procedures are specified in [RFC7432]. Segment Routing with MPLS data plane tunneling is specified in [RFC8660]. Rabadan, et al. Expires 17 February 2025 [Page 2] Internet-Draft EVPN MH Split Horizon Extensions August 2024 * Segment Routing with IPv6 data plane (SRv6), where the relevant EVPN procedures are specified in [RFC9252]. SRv6 is specified in [RFC8402][RFC8754]. Split Horizon, in this document, follows the definition in [RFC7432]. Split Horizon refers to the EVPN multihoming procedure that prevents a PE from sending a frame back to a multihomed Customer Edge (CE) when that CE originated the frame in the first place. EVPN multihoming procedures may vary depending on the type of tunnel utilized within the EVPN Broadcast Domain. Specifically, there are two multihoming Split Horizon procedures employed to prevent looped frames on multihomed CE devices: the ESI Label-based procedure and the Local Bias procedure. The ESI Label-based Split Horizon procedure is used for MPLS or MPLS- over-X (MPLSoX) tunnels, such as MPLS-over-UDP, and its procedures are detailed in [RFC7432]. Conversely, the Local Bias procedure is used for IP-based tunnels, such as VXLAN tunnels, and it is described in [RFC8365]. 1.1. 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. * A-D per ES route: refers to the EVPN Ethernet Auto-Discovery per ES route defined in [RFC7432]. * Arg.FE2: refers to the ESI filtering argument used for Split Horizon as specified in [RFC9252]. * Broadcast Domain (BD): an emulated Ethernet, such that two systems on the same BD will receive each other's broadcast, unknown and multicast traffic. In this document, BD also refers to the instantiation of a Broadcast Domain on an EVPN PE. An EVPN PE can be attached to one or multiple BDs of the same tenant. * BUM: Broadcast, Unknown unicast and Multicast traffic. * Designated Forwarder (DF): as defined in [RFC7432], an ES may be multihomed (attached to more than one PE). An ES may also contain multiple BDs, of one or more EVIs. For each such EVI, one of the Rabadan, et al. Expires 17 February 2025 [Page 3] Internet-Draft EVPN MH Split Horizon Extensions August 2024 PEs attached to the segment becomes that EVI's DF for that segment. Since a BD may belong to only one EVI, we can speak unambiguously of the BD's DF for a given segment. * ES and ESI: Ethernet Segment and Ethernet Segment Identifier. * EVI: EVPN Instance * EVI-RT: EVI Route Target. A group of NVEs attached to the same EVI will share the same EVI-RT. * GENEVE: Generic Network Virtualization Encapsulation, [RFC8926] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 19). * MPLS tunnels and non-MPLS NVO tunnels: refer to Multi-Protocol Label Switching (or the absence of it) Network Virtualization Overlay tunnels. Network Virtualization Overlay tunnels use an IP encapsulation for overlay frames, where the source IP address identifies the ingress NVE and the destination IP address the egress NVE. * MPLSoUDP: Multi-Protocol Label Switching over User Datagram Protocol, [RFC7510] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 13). * MPLSoGRE: Multi-Protocol Label Switching over Generic Network Encapsulation, [RFC4023] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 11). * MPLSoX: refers to MPLS over any IP encapsulation. Examples are MPLS-over-UDP or MPLS-over-GRE. * NVE: Network Virtualization Edge device. * NVGRE: Network Virtualization Using Generic Routing Encapsulation, [RFC7637] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 9). * VXLAN: Virtual eXtensible Local Area Network, [RFC7348] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 8). * VXLAN-GPE: VXLAN Generic Protocol Extension, [I-D.ietf-nvo3-vxlan-gpe] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 12). * SHT: Split Horizon Type, it refers to the Split Horizon method that a PE intends to use and advertises in an A-D per ES route. * SRv6: Segment Routing with an IPv6 data plane, [RFC8402][RFC8754]. Rabadan, et al. Expires 17 February 2025 [Page 4] Internet-Draft EVPN MH Split Horizon Extensions August 2024 This document also assumes familiarity with the terminology of [RFC7432] and [RFC8365]. 1.2. Split Horizon Filtering and Tunnel Encapsulations EVPN supports two Split Horizon Filtering mechanisms: * ESI Label based Split Horizon filtering [RFC7432] When EVPN is employed for MPLS transport tunnels, an MPLS label facilitates Split Horizon filtering to support All-Active multihoming. The ingress Network Virtualization Edge (NVE) device appends a label corresponding to the source Ethernet Segment Identifier (ESI label) during packet encapsulation. The egress NVE verifies the ESI label when attempting to forward a multi- destination frame through a local Ethernet Segment (ES) interface. If the ESI label matches the site identifier (ESI) associated with that ES interface, the packet is not forwarded. This mechanism effectively prevents forwarding loops for BUM traffic. The ESI Label Split Horizon filtering should also be utilized with Single-Active multihoming to prevent transient loops for in-flight packets when the egress NVE assumes the role of Designated Forwarder for an ES. * Local Bias [RFC8365] Since IP tunnels, such as VXLAN or NVGRE, do not support the ESI label or any MPLS label, an alternative Split Horizon filtering procedure must be implemented for All-Active multihoming. This mechanism, known as Local Bias, relies on the source IP address of the tunnel to determine whether to forward BUM traffic to a local Ethernet Segment (ES) interface at the egress Network Virtualization Edge (NVE). In summary and as specified in [RFC8365], each NVE tracks the IP address(es) of other NVEs with which it shares multihomed ESs. Upon receiving a BUM frame encapsulated in an IP tunnel, the egress NVE inspects the source IP address in the tunnel header, which identifies the ingress NVE. The egress NVE then filters out the frame on all local interfaces connected to ESs that are shared with the ingress NVE. Rabadan, et al. Expires 17 February 2025 [Page 5] Internet-Draft EVPN MH Split Horizon Extensions August 2024 Due to this behavior at the egress NVE, the ingress NVE is required to perform local replication to all directly attached ESs, regardless of the Designated Forwarder election state, for all BUM traffic ingressing from the access Attachment Circuits (ACs). This local replication at the ingress NVE is the basis for the term Local Bias. Local Bias is not suitable for Single-Active multihoming, as the ingress NVE deactivates the ACs for which it is not the Designated Forwarder. Consequently, local replication to non-Designated Forwarder ACs cannot occur, leading to transient in-flight BUM packets to be looped back to the originating site by newly elected Designated Forwarder egress NVEs. [RFC8365] specifies that Local Bias is exclusively utilized for IP tunnels, while ESI Label-based Split Horizon is employed for IP-based MPLS tunnels. However, IP-based MPLS tunnels, such as MPLS over GRE (MPLSoGRE) or MPLS over UDP (MPLSoUDP), are also categorized as IP tunnels and have the potential to support both procedures. These tunnels are capable of carrying ESI labels and also utilize a tunnel IP header in which the source IP address identifies the ingress Network Virtualization Edge (NVE). Similarly, certain IP tunnels - that include an identifier for the source Ethernet Segment (ES) in the tunnel header - may also potentially support either procedure. Examples of such tunnels include GENEVE and SRv6.: * In a GENEVE tunnel, the source IP address identifies the ingress NVE therefore local bias is possible. Also, [I-D.ietf-bess-evpn-geneve] section 4.1 defines an Ethernet option TLV (Type Length Value) to encode an ESI label value. * In an SRv6 tunnel, the source IP address identifies the ingress NVE. By default, and as outlined in [RFC9252], the ingress PE adds specific information to the SRv6 packet to enable the egress PE to identify the source ES of the BUM packet. This information is the ESI filtering argument (Arg.FE2) [RFC9252] (section 6.1.1) [RFC8986] (section 4.12) of the service Segment Identifier (SID) received on an A-D per ES route from the egress PE. Rabadan, et al. Expires 17 February 2025 [Page 6] Internet-Draft EVPN MH Split Horizon Extensions August 2024 Table 1 presents various tunnel encapsulations along with their supported and default Split Horizon methods. For GENEVE, the default Split Horizon Type (SHT) is contingent upon the negotiation of the Ethernet Option with the Source ID TLV. In the case of SRv6, the default SHT is specified as ESI Label filtering in the table, as its behavior is analogous to that of ESI Label filtering. In this document, ESI Label filtering refers to the Split Horizon filtering based on the presence of a source Ethernet Segment (ES) identifier in the tunnel header. This document classifies the tunnel encapsulations used by EVPN into: 1. IP-based MPLS tunnels 2. (SR-)MPLS tunnels, that is, MPLS and Segment Routing with MPLS data plane tunnels 3. IP tunnels 4. SRv6 tunnels Table 1 lists the encapsulations supported by this document. Any tunnel encapsulation not listed in Table 1) is out of scope. Tunnel encapsulations used by EVPN can be categorized into one of the four encapsulation groups mentioned above and support Split Horizon filtering based on the following rules: * IP-based MPLS tunnels and SRv6 tunnels are capable of supporting both Split Horizon filtering methods. * (SR-)MPLS tunnels only support ESI Label-based Split Horizon filtering * IP tunnels support Local Bias Split Horizon filtering and may also support ESI Label-based Split Horizon filtering, provided they incorporate a mechanism to identify the source ESI in the header. Rabadan, et al. Expires 17 February 2025 [Page 7] Internet-Draft EVPN MH Split Horizon Extensions August 2024 +===============+=========================+============+===========+ | Tunnel | Default Split Horizon | Supports | Supports | | Encapsulation | Type (SHT) | Local Bias | ESI Label | +===============+=========================+============+===========+ | MPLSoGRE (IP- | ESI Label filtering | Yes | Yes | | based MPLS) | | | | +---------------+-------------------------+------------+-----------+ | MPLSoUDP (IP- | ESI Label filtering | Yes | Yes | | based MPLS) | | | | +---------------+-------------------------+------------+-----------+ | (SR-)MPLS | ESI Label filtering | No | Yes | +---------------+-------------------------+------------+-----------+ | VXLAN (IP | Local Bias | Yes | No | | tunnels) | | | | +---------------+-------------------------+------------+-----------+ | NVGRE (IP | Local Bias | Yes | No | | tunnels) | | | | +---------------+-------------------------+------------+-----------+ | VXLAN-GPE (IP | Local Bias | Yes | No | | tunnels) | | | | +---------------+-------------------------+------------+-----------+ | GENEVE (IP | Local Bias (no ESI Lb), | Yes | Yes | | tunnels) | ESI Label (if ESI lb) | | | +---------------+-------------------------+------------+-----------+ | SRv6 | ESI Label filtering | Yes | Yes | +---------------+-------------------------+------------+-----------+ Table 1: Tunnel Encapsulations and Split Horizon Types The ESI Label method is applicable for both All-Active and Single- Active configurations, whereas the Local Bias method is suitable only for All-Active configurations. Moreover, the ESI Label method is effective across different network domains, while Local Bias is constrained to networks where there is no change in the next hop between the NVEs attached to the same ES. Nonetheless, some operators favor the Local Bias method due to its simplification of the encapsulation process, reduced resource consumption on NVEs, and the fact that the ingress NVE always forwards traffic locally to other interfaces, thereby decreasing the delay in reaching multihomed hosts. This document extends the EVPN multihoming procedures to allow operators to select the preferred Split Horizon method for a given NVO tunnel according to their specific requirements. The choice between Local Bias and ESI Label Split Horizon is now allowed (by configuration) for tunnel encapsulations that support both methods, and this selection is advertised along with the EVPN A-D per ES route. IP tunnels that do not support both methods, such as VXLAN or Rabadan, et al. Expires 17 February 2025 [Page 8] Internet-Draft EVPN MH Split Horizon Extensions August 2024 NVGRE, will continue to adhere to the procedures specified in [RFC8365]. Note that this document does not modify the Local Bias or the ESI Label Split Horizon procedures themselves, just focuses on the signaling and selection of the Split Horizon method to apply by the multihomed NVEs. 2. BGP EVPN Extensions Extensions to EVPN are required to enable NVEs to advertise their preferred Split Horizon method for a given ES. Figure 1 illustrates the ESI Label extended community ([RFC7432] Section 7.5), which is consistently advertised alongside the EVPN A-D per ES route. All NVEs connected to an ES advertise an A-D per ES route for that ES, including the extended community, which communicates information regarding the multihoming mode (either All-Active or Single-Active) and, if necessary, specifies the ESI Label to be utilized. 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=0x01 | Flags(1 octet)| Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved=0 | ESI Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ESI Label extended community [RFC7432] defines the low-order bit of the Flags octet (bit 0) as the "Single-Active" bit: * A value of 0 means that the multihomed ES is operating in All- Active multihoming redundancy mode. * A value of 1 means that the multihomed ES is operating in Single- Active multihoming redundancy mode. Section 5 establishes a registry for the Flags octet, designating the "Single-Active" bit as the low-order bit of the newly defined multihoming redundancy mode field. 2.1. The Split Horizon Type [RFC8365] does not include any explicit indication regarding the Split Horizon method in the A-D per Ethernet Segment (ES) route. In this document, the Split Horizon procedure defined in [RFC8365] (section 8.3.1) is considered the default behavior, presuming that Local Bias is employed exclusively for IP tunnels, while ESI Label- based Split Horizon is used for IP-based MPLS tunnels. This document Rabadan, et al. Expires 17 February 2025 [Page 9] Internet-Draft EVPN MH Split Horizon Extensions August 2024 specifies that the two high-order bits in the Flags octet (bits 6 and 7) constitute the "Split Horizon Type" (SHT) field, where: 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ |SHT| |RED| +-+-+-+-+-+-+-+-+ RED = "Multihoming Redundancy Mode" field (section 5) SHT bit 7 6 ----------- 0 0 --> Default SHT Backwards compatible with [RFC8365] and [RFC7432] 0 1 --> Local Bias 1 0 --> ESI Label based filtering 1 1 --> reserved for future use * SHT = 00 is backwards compatible with [RFC8365] and [RFC7432], and indicates that the advertising NVE intends to use the default or built-in SHT. The default SHT is shown in Table 1 for each encapsulation. An egress NVE that follows the [RFC8365] behavior and does not support this specification will ignore the SHT bits (which is equivalent to process them as value of 00). * SHT = 01 indicates that the advertising NVE intends to use Local Bias procedures in the ES for which the AD per-ES route is advertised. * SHT = 10 indicates that the advertising NVE intends to use the ESI Label based Split Horizon method procedures in the ES for which the AD per-ES route is advertised. * SHT = 11 is a reserved value, for future use. 2.2. Use of the Split Horizon Type In A-D Per ES Routes The following behavior is observed: * An SHT value of 01 or 10 MUST NOT be used with encapsulations that support only one SHT in Table 1, and MAY be used by encapsulations that support the two SHTs in Table 1. * An SHT value different from 00 expresses the intent to use a specific Split Horizon method, but does not reflect the actual operational SHT used by the advertising NVE, unless all the NVEs attached to the ES advertise the same SHT. Rabadan, et al. Expires 17 February 2025 [Page 10] Internet-Draft EVPN MH Split Horizon Extensions August 2024 * In case of inconsistency in the SHT value advertised by the NVEs attached to the same ES for a given EVI, all the NVEs MUST revert to the [RFC8365] behavior, and use the default SHT in Table 1, irrespective of the advertised SHT. * An SHT different from 00 MUST NOT be set if the Single-Active bit is set. A received A-D per ES route where Single-Active and SHT bits are different from zero MUST follow the treat-as-withdraw behavior [RFC7606]. * The SHT MUST have the same value in each Ethernet A-D per ES route that an NVE advertises for a given ES and a given encapsulation (see Section 3 for NVEs supporting multiple encapsulations). As an example, egress NVEs that support IP-based MPLS tunnels, such as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES along with the BGP Encapsulation extended community, as defined in [RFC9012]. This extended community indicates the encapsulation type (MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to signify the intent to use Local Bias or ESI Label, respectively. An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with [RFC9012] Tunnel encapsulation types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP tunnel encapsulation extended community at all. In all these cases, it is presumed that there is no choice for the Split Horizon method; therefore, the SHT value MUST be set to 00. If a route with any of the mentioned encapsulation options is received and has an SHT value different from 00, it SHOULD apply the treat-as-withdraw behavior, per [RFC7606]. An egress NVE advertising A-D per ES route(s) for an ES with GENEVE encapsulation ([RFC9012], Tunnel encapsulation type 19, [I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or 10. A value of 01 indicates the intent to use Local Bias, regardless of the presence of an Ethernet option TLV with a non-zero Source-ID, as described in [I-D.ietf-bess-evpn-geneve]. A value of 10 indicates the intent to use ESI Label-based Split Horizon, and it is only valid if an Ethernet option TLV with non-zero Source-ID is present. A value of 00 indicates the default behavior outlined in Table 1, which is to use Local Bias if: a) no ESI-Label is present in the Ethernet option TLV, or b) if there is no Ethernet option TLV. Otherwise, the ESI Label Split Horizon method is applied. These procedures assume a single encapsulation supported in the egress NVE. Section 3 describes additional procedures for NVEs supporting multiple encapsulations. Rabadan, et al. Expires 17 February 2025 [Page 11] Internet-Draft EVPN MH Split Horizon Extensions August 2024 2.3. ESI Label Value In A-D Per ES Routes This document also updates [RFC8365] regarding the value that is advertised in the ESI Label field of the ESI Label extended community, as follows: * The A-D per ES route(s) for an ES MAY have an ESI Label value of zero if the SHT value is 01. Section 2.2 specifies the scenarios where the SHT can be 01. An ESI Label value of zero eliminates the need to allocate labels in cases where they are not utilized, such as in the Local Bias method. * The A-D per ES route(s) for an ES MAY have an ESI Label value of zero for VXLAN or NVGRE encapsulations. 2.4. Backwards Compatibility With RFC8365 NVEs As discussed in Section 2.2 this specification is backwards compatible with the Split Horizon filtering behavior in [RFC8365] and a non-upgraded NVE can be attached to the same ES as other NVEs supporting this specification. An NVE maintains an administrative SHT value for an Ethernet Segment (ES), which is advertised alongside the A-D per ES route, and an operational SHT value, which is the one actually used regardless of what the NVE has advertised. The administrative SHT matches the operational SHT if all the NVEs attached to the ES have the same administrative SHT. This document assumes that an implementation of [RFC7432] or [RFC8365] that does not support the specifications in this document will ignore the values of all the Flags in the ESI Label extended community, except for the Single-Active bit. Based on this assumption, a non-upgraded NVE will disregard any SHT value other than 00. If an upgraded NVE receives at least one A-D per ES route for the ES with an SHT value of 00, it MUST revert its operational SHT to the default Split Horizon method, as described in Table 1, irrespective of its administrative SHT. For instance, consider an NVE attached to ES N that receives two A-D per ES routes for N from different NVEs, NVE1 and NVE2. If the route from NVE1 has an SHT value of 00 and the one from NVE2 has an SHT value of 01, the NVE MUST use the default Split Horizon method specified in Table 1 as its operational SHT, regardless of its administrative SHT. Rabadan, et al. Expires 17 February 2025 [Page 12] Internet-Draft EVPN MH Split Horizon Extensions August 2024 All NVEs attached to an ES with an operational SHT value of 10 MUST advertise a valid, non-zero ESI Label. If the operational SHT value is 01, the ESI Label MAY be zero. If the operational SHT value is 00, the ESI Label may be zero only if the default encapsulation supports Local Bias exclusively, and the NVEs do not require the presence of a valid, non-zero ESI Label. If an NVE changes its operational SHT value from 01 (Local Bias) to 00 (Default SHT) due to the presence of a new non-upgraded NVE in the ES, and it previously advertised a zero ESI Label, it MUST send an update with a valid, non-zero ESI Label, unless all the non-upgraded NVEs in the ES support only Local Bias. For example, consider NVE1 and NVE2 using MPLSoUDP as encapsulation, attached to the same Ethernet Segment ES1, and advertising an SHT value of 01 (Local Bias) with a zero ESI Label value. Suppose NVE3, which does not support this specification, joins ES1 and advertises an SHT value of 00 (default). Upon receiving NVE3's A-D per ES route, NVE1 and NVE2 MUST update their A-D per ES routes for ES1 to include a valid, non- zero ESI Label value. The assumption here is that NVE3 only supports the default ESI Label-based Split Horizon filtering. 3. Procedures for NVEs Supporting Multiple Encapsulations As specified in [RFC8365], an NVE that supports multiple data plane encapsulations (e.g., VXLAN, NVGRE, MPLS, MPLSoUDP, GENEVE) must indicate all supported encapsulations using BGP Encapsulation extended communities as defined in [RFC9012] for all EVPN routes. This section provides clarification on the multihoming Split Horizon behavior for NVEs that advertise and receive multiple BGP Encapsulation extended communities along with the A-D per ES routes. This section uses the notation {x, y} (more than two encapsulations is possible too) to denote the encapsulations advertised in BGP Encapsulation extended communities (or BGP Tunnel Encapsulation Attribute), where x and y represent different encapsulation values. When GENEVE is one of the encapsulations, the tunnel type is indicated in either a BGP Encapsulation extended community or a BGP Tunnel Encapsulation Attribute. It is important to note that an NVE MAY advertise multiple A-D per ES routes for the same ES, rather than a single route, with each route conveying a set of Route Targets (RT). The total set of Route Targets associated with a given ES is referred to as the RT-set for that ES. Each of the EVIs represented in the RT-set will have its RT included in one, and only one, A-D per ES route for the ES. When multiple A-D per ES routes are advertised for the same ES, each route must have a distinct Route Distinguisher. Rabadan, et al. Expires 17 February 2025 [Page 13] Internet-Draft EVPN MH Split Horizon Extensions August 2024 As per [RFC8365], an NVE that advertises multiple encapsulations in the A-D per ES route(s) for an ES MUST advertise encapsulations that use the same Split Horizon filtering method in the same route. For example: * An A-D per ES route for ES-x may be advertised with {VXLAN, NVGRE} encapsulations. * An A-D per ES route for ES-y may be advertised with {MPLS, MPLSoUDP, MPLSoGRE} encapsulations (or a subset). * But an A-D per ES route for ES-z MUST NOT be advertised with {MPLS, VXLAN} encapsulations. This document extends the described behavior as follows: a. An A-D per ES route for ES-x may be advertised with multiple encapsulations, some of which support a single Split Horizon method. In this case, the Split Horizon Type (SHT) value MUST be 00. For instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN, GENEVE}, or {MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In all these cases, the SHT value MUST be 00 and the behavior treat-as-withdraw [RFC7606] is applied in case of any other value. b. An A-D per ES route for ES-y may be advertised with multiple encapsulations that all support both Split Horizon methods. In this case, the SHT value MAY be 01 if the preferred method is Local Bias, or 10 if the ESI Label-based method is desired. For example, encapsulations such as {MPLSoGRE, MPLSoUDP, GENEVE} (or a subset) MAY be advertised in an A-D per ES route with an SHT value of 01. The ESI Label value in this case MAY be zero. c. If ES-z with RT-set composed of (RT1, RT2, RT3.. RTn) supports multiple encapsulations requiring different Split Horizon methods, a distinct A-D per ES route (or group of routes) per Split Horizon method MUST be advertised. For example, consider an ES-z with n Route Targets (RTs) where: * the EVIs corresponding to (RT1..RTi) support VXLAN, * the ones for (RTi+1..RTm) (with i. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [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, . Rabadan, et al. Expires 17 February 2025 [Page 17] Internet-Draft EVPN MH Split Horizon Extensions August 2024 [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, . [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, . 7.2. Informative References [I-D.ietf-bess-evpn-geneve] Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S. Aldrin, "EVPN control plane for Geneve", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-geneve-08, 5 July 2024, . [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, . [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, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", RFC 8926, DOI 10.17487/RFC8926, November 2020, . Rabadan, et al. Expires 17 February 2025 [Page 18] Internet-Draft EVPN MH Split Horizon Extensions August 2024 [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, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [I-D.ietf-nvo3-vxlan-gpe] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November 2023, . [IANA-BGP-TUNNEL-ENCAP] IANA, "Border Gateway Protocol (BGP) Tunnel Encapsulation", . Authors' Addresses Rabadan, et al. Expires 17 February 2025 [Page 19] Internet-Draft EVPN MH Split Horizon Extensions August 2024 Jorge Rabadan (editor) Nokia 520 Almanor Avenue Sunnyvale, CA 94085 United States of America Email: jorge.rabadan@nokia.com Kiran Nagaraj Nokia 520 Almanor Avenue Sunnyvale, CA 94085 United States of America Email: kiran.nagaraj@nokia.com Wen Lin Juniper Networks Email: wlin@juniper.net Ali Sajassi Cisco Systems, Inc. Email: sajassi@cisco.com Rabadan, et al. Expires 17 February 2025 [Page 20]