<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">zwsp "​"> <!ENTITYRFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">nbhy "‑"> <!ENTITYRFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"> <!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"> <!ENTITY I-D.ietf-bess-evpn-geneve SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-geneve.xml"> <!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"> <!ENTITY RFC5512 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5512.xml"> <!ENTITY RFC4023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4023.xml"> <!ENTITY RFC7637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"> <!ENTITY RFC7510 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml"> <!ENTITY RFC8926 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"> <!ENTITY RFC9012 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"> <!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"> <!ENTITY RFC8660 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"> <!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"> <!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"> <!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"> <!ENTITY RFC9252 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"> <!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"> <!ENTITY I-D.ietf-nvo3-vxlan-gpe SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-vxlan-gpe.xml">wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><!-- sortRefs set to false in submitted XML file. --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-evpn-mh-split-horizon-11" number="9746" ipr="trust200902" consensus="true" submissionType="IETF"updates="8365, 7432"> <!--Generated by id2xml 1.5.0 on 2020-07-31T12:56:54Z --> <?rfc strict="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc sortrefs="no"?> <?rfc text-list-symbols="oo*+-"?> <?rfc toc="yes"?>updates="7432, 8365" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="false" version="3"> <front> <title abbrev="EVPN MH Split Horizon Extensions">BGP EVPNMulti-HomingMultihoming Extensions for Split Horizon Filtering</title> <seriesInfo name="RFC" value="9746"/> <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabadan"> <organization>Nokia</organization> <address> <postal> <street>520 Almanor Avenue</street> <city>Sunnyvale</city> <region>CA</region> <code>94085</code><country>USA</country><country>United States of America</country> </postal> <email>jorge.rabadan@nokia.com</email> </address> </author> <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj"> <organization>Nokia</organization> <address> <postal> <street>520 Almanor Avenue</street> <city>Sunnyvale</city> <region>CA</region> <code>94085</code><country>USA</country><country>United States of America</country> </postal> <email>kiran.nagaraj@nokia.com</email> </address> </author> <author fullname="Wen Lin" initials="W." surname="Lin"> <organization abbrev="Juniper">Juniper Networks</organization> <address> <email>wlin@juniper.net</email> </address> </author> <author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <organization abbrev="Cisco">Cisco Systems, Inc.</organization> <address> <email>sajassi@cisco.com</email> </address> </author> <dateday="16" month="August" year="2024"/> <workgroup>BESS Workgroup</workgroup>month="February" year="2025"/> <area>RTG</area> <workgroup>bess</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><t>Ethernet<t>An Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO)tunnels,tunnels as well as with MPLS and Segment Routing (SR) tunnels. Themulti-homingmultihoming procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are twomulti-homingmultihoming Split Horizon procedures designed to prevent looped frames onmulti-homedmultihomed Customer Edge (CE) devices: theESIEthernet Segment Identifier (ESI) Label-based procedure and the Local Bias procedure. The ESI Label-based Split Horizon procedure is applied to MPLS-basedtunnels,tunnels such asMPLSoUDP,MPLS over UDP (MPLSoUDP), while the Local Bias procedure is used for othertunnels,tunnels such asVXLAN.</t>Virtual eXtensible Local Area Network (VXLAN) tunnels.</t> <t>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 includeMPLSoGRE,MPLSoUDP,GENEVE,MPLS over GRE (MPLSoGRE), Generic Network Virtualization Encapsulation (GENEVE), andSRv6.Segment Routing over IPv6 (SRv6) tunnels. This document updates the EVPNmulti-homingmultihoming procedures described inRFC 8365RFCs 7432 andRFC 7432,8365, enabling operators to select the Split Horizon procedure that meets their specific requirements.</t> </abstract> </front> <middle> <section anchor="sect-1"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Ethernet Virtual Private Networks(EVPN)(EVPNs) are commonly used with the following tunnel encapsulations:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Network Virtualization Overlay (NVO) tunnels, where the EVPN procedures are specified in <xreftarget="RFC8365"/>.target="RFC8365" format="default"/>. MPLSoGRE <xreftarget="RFC4023"/>,target="RFC4023" format="default"/>, MPLSoUDP <xreftarget="RFC7510"/>,target="RFC7510" format="default"/>, GENEVE <xreftarget="RFC8926"/>target="RFC8926" format="default"/>, or VXLAN <xreftarget="RFC7348"/>target="RFC7348" format="default"/> tunnels are considered NVO tunnels.</t> </li> <li> <t>MPLS and Segment Routingwithover MPLSdata plane (SR-MPLS),(SR-MPLS) tunnels, where the relevant EVPN procedures are specified in <xreftarget="RFC7432"/>. Segment Routing with MPLS data planetarget="RFC7432" format="default"/>. SR-MPLS tunneling is specified in <xreftarget="RFC8660"/>.</t>target="RFC8660" format="default"/>.</t> </li> <li> <t>Segment Routingwithover IPv6data plane (SRv6),(SRv6) tunnels, where the relevant EVPN procedures are specified in <xreftarget="RFC9252"/>.target="RFC9252" format="default"/>. SRv6 is specified in <xreftarget="RFC8402"/><xref target="RFC8754"/>.</t> </list></t> <t>Split Horizon,target="RFC8402" format="default"/> and <xref target="RFC8754" format="default"/>.</t> </li> </ul> <!-- [rfced] We see the following terms used in various ways in the RFC Series. This document was consistent in their use of the capitalziation for the terms below. Is this the preferred form for future documents related to this subject? a) RFC 7432 uses "split-horizon" (lowercase and hyphenated) when acting as an adjective appearing before the noun, while this document uses the initial-capitalized form without a hyphen consistently. Examples from this document: Split Horizon procedure Split Horizon filtering Split Horizon method Split Horizon behavior Split Horizon Type (SHT) b) "Local Bias" (this document) vs "local-bias" per RFCs 8365 and 9252 c) "GENEVE" (this document) vs "Geneve" per RFC 8926 --> <t>In this document, the term "Split Horizon" follows the definition in <xreftarget="RFC7432"/>.target="RFC7432" format="default"/>. Split Horizon refers to the EVPN multihoming procedure that prevents aPEProvider Edge (PE) from sending a frame back to a multihomed Customer Edge (CE) when that CE originated the frame in the first place.</t> <t>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.</t> <t>The ESI Label-based Split Horizon procedure is used for MPLS orMPLS-over-XMPLS over X (MPLSoX) tunnels, such asMPLS-over-UDP,MPLSoUDP, and its procedures are detailed in <xreftarget="RFC7432"/>.target="RFC7432" format="default"/>. Conversely, the Local Bias procedure is used for IP-based tunnels, such as VXLAN tunnels, and it is described in <xreftarget="RFC8365"/>. </t>target="RFC8365" format="default"/>.</t> <section anchor="sect-1.1"title="Conventionsnumbered="true" toc="default"> <name>Conventions andTerminology"> <t>TheTerminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <t><list style="symbols"> <t>AC: Attachment Circuit.</t> <t>A-Dhere. </t> <!-- [rfced] Please review the following questions and changes regarding the terminology list in Section 1.1. a.) We have made some adjustments for readability and to demonstrate 1:1 relationships between abbreviations and their expansions. Please carefully review and let us know any objections. b.) We were unable to find the "EVPN Ethernet Auto-Discovery per ES route" explicitly mentioned in RFC 7432. May we update this item as follows for accuracy and concision? Original: * A-D per ES route: refers to the EVPN Ethernet Auto-Discovery per ES route defined in<xref target="RFC7432"/>.</t> <t>Arg.FE2:[RFC7432]. Perhaps: A-D per ES route: Auto-Discovery per Ethernet Segment route (as defined in [RFC7432]). c.) Arg.FE2 is mentioned in RFC 9252; however, RFC 9252 says that "the Arg.FE2 notation [is] introduced in [RFC8986]". Would you like to update the citation below to RFC 8986? Original: * Arg.FE2: refers to the ESI filtering argument used for Split Horizon as specified in [RFC9252]. d.) Several abbreviations appear in this document but are not included in this terminology list (see some examples below). Please review and let us know if you would like to add these or any additional terms to this list. Type-Length-Value (TLV) Route Targets (RTs) Provider Edge (PE) Customer Edge (CE) --> <dl spacing="normal"> <dt>AC:</dt> <dd>Attachment Circuit</dd> <dt>A-D per ES route:</dt> <dd>Auto-Discovery per Ethernet Segment route. Refers to the EVPN Ethernet Auto-Discovery per ES route defined in <xref target="RFC7432" format="default"/>.</dd> <dt>Arg.FE2:</dt> <dd>Refers to the ESI filtering argument used for Split Horizon as specified in <xreftarget="RFC9252"/>.</t> <t>Broadcast Domain (BD):target="RFC9252" format="default"/>.</dd> <dt>BD:</dt> <dd>Broadcast Domain. Refers to an emulated Ethernet, such that two systems on the same BD will receive each other'sbroadcast, unknown and multicastBUM traffic. In this document, BD also refers to the instantiation of aBroadcast DomainBD on an EVPN PE. An EVPN PE can be attached to one or multiple BDs of the sametenant.</t> <t>BUM: Broadcast,tenant.</dd> <dt>BUM:</dt> <dd>Broadcast, UnknownunicastUnicast, andMulticast traffic.</t> <t>Designated Forwarder (DF): asMulticast</dd> <dt>DF:</dt> <dd>Designated Forwarder. As defined in <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, an ES may be multihomed (attached to more than one PE). An ES may also contain multipleBDs,BDs of one or more EVIs. For each such EVI, one of the 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 givensegment.</t> <t>ES and ESI: Ethernet Segment and Ethernetsegment.</dd> <dt>ES:</dt> <dd>Ethernet Segment</dd> <dt>ESI:</dt> <dd>Ethernet SegmentIdentifier.</t> <t>EVI: EVPN Instance</t> <t>EVI-RT: EVIIdentifier</dd> <dt>EVI:</dt> <dd>EVPN Instance</dd> <dt>EVI-RT:</dt><dd>EVI Route Target.ARefers to a group of NVEs attached to the same EVI that will share the sameEVI-RT.</t> <t>GENEVE: GenericEVI-RT.</dd> <dt>GENEVE:</dt><dd>Generic Network VirtualizationEncapsulation,Encapsulation <xreftarget="RFC8926"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/>target="RFC8926" format="default"/> (see tunnel type19).</t> <t>MPLS19 in <xref target="TUNNEL-ENCAP" format="default"/>).</dd> <dt>MPLS tunnels and non-MPLS NVOtunnels: refertunnels:</dt><dd>Refers toMulti-ProtocolMultiprotocol Label Switching (or the absence of it) Network Virtualization Overlay tunnels.Network Virtualization OverlayNVO tunnels use an IP encapsulation for overlay frames, where the source IP address identifies the ingress NVE and the destination IP address identifies the egressNVE.</t> <t>MPLSoUDP: Multi-ProtocolNVE.</dd> <dt>MPLSoUDP:</dt><dd>Multiprotocol Label Switching over User DatagramProtocol,Protocol <xreftarget="RFC7510"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/>target="RFC7510" format="default"/> (see tunnel type13).</t> <t>MPLSoGRE: Multi-Protocol13 in <xref target="TUNNEL-ENCAP" format="default"/>).</dd> <dt>MPLSoGRE:</dt><dd>Multiprotocol Label Switching over Generic NetworkEncapsulation,Encapsulation <xreftarget="RFC4023"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/>target="RFC4023" format="default"/> (see tunnel type11).</t> <t>MPLSoX: refers11 in <xref target="TUNNEL-ENCAP" format="default"/>).</dd> <dt>MPLSoX:</dt><dd>Refers to MPLS over any IPencapsulation. Examples are MPLS-over-UDPencapsulation, for example, MPLSoUDP orMPLS-over-GRE.</t> <t>NVE: NetworkMPLSoGRE.</dd> <dt>NVE:</dt><dd>Network VirtualizationEdge device.</t> <t>NVGRE: NetworkEdge</dd> <dt>NVGRE:</dt><dd>Network Virtualization Using Generic RoutingEncapsulation,Encapsulation <xreftarget="RFC7637"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/>target="RFC7637" format="default"/> (see tunnel type9).</t> <t>VXLAN: Virtual9 in <xref target="TUNNEL-ENCAP" format="default"/>).</dd> <dt>VXLAN:</dt><dd>Virtual eXtensible Local AreaNetwork,Network <xreftarget="RFC7348"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/>target="RFC7348" format="default"/> (see tunnel type8).</t> <t>VXLAN-GPE: VXLAN8 in <xref target="TUNNEL-ENCAP" format="default"/>).</dd> <dt>VXLAN-GPE:</dt><dd>VXLAN Generic ProtocolExtension,Extension <xreftarget="I-D.ietf-nvo3-vxlan-gpe"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/>target="I-D.ietf-nvo3-vxlan-gpe" format="default"/> (see tunnel type12).</t> <t>SHT: Split12 in <xref target="TUNNEL-ENCAP" format="default"/>).</dd> <dt>SHT:</dt><dd>Split HorizonType, it refersType. Refers to the Split Horizon method that a PE intends to use and advertises in an A-D per ESroute.</t> <t>SRv6: Segmentroute.</dd> <dt>SRv6:</dt><dd>Segment Routingwith anover IPv6data plane,(see <xreftarget="RFC8402"/><xref target="RFC8754"/>.</t> </list></t>target="RFC8402" format="default"/> and <xref target="RFC8754" format="default"/>).</dd> </dl> <t>This document also assumes familiarity with the terminology of <xreftarget="RFC7432"/>target="RFC7432" format="default"/> and <xreftarget="RFC8365"/>.</t>target="RFC8365" format="default"/>.</t> </section> <sectiontitle="Splitnumbered="true" toc="default"> <name>Split Horizon Filtering and TunnelEncapsulations">Encapsulations</name> <t>EVPN supports two Split HorizonFilteringfiltering mechanisms:</t><t><list style="symbols"><ol type="1" spacing="normal"> <li> <t>ESILabel basedLabel-based Split Horizon filtering <xreftarget="RFC7432"/><vspace blankLines="1"/>Whentarget="RFC7432" format="default"/>:</t> <!-- [rfced] The parentheses in the text below seem to contain a mixture of abbreviations and additional context. For clarity and readability, may we update as follows? Original: 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... Perhaps: The ingress NVE device appends a label corresponding to the source ESI (the ESI label) during packet encapsulation. The egress NVE verifies the ESI label when attempting to forward a multi-destination frame through a local ES interface. If the ESI label matches the site identifier (the ESI) associated with that ES interface, then the packet is not forwarded... --> <t>When EVPN is employed for MPLS transport tunnels, an MPLS label facilitates Split Horizon filtering to support All-Active multihoming. The ingressNetwork Virtualization Edge (NVE)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, then the packet is not forwarded. This mechanism effectively prevents forwarding loops for BUM traffic.<vspace blankLines="1"/>The ESI</t> <t>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 ofDesignated ForwarderDF for an ES.</t> </li> <li> <t>Local Bias filtering <xreftarget="RFC8365"/><vspace blankLines="1"/>Sincetarget="RFC8365" format="default"/>:</t> <t>Since IPtunnels,tunnels such as VXLAN orNVGRE,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 localEthernet Segment (ES)ES interface at the egressNetwork Virtualization Edge (NVE). <vspace blankLines="1"/>InNVE.</t> <t>In summary and as specified in <xreftarget="RFC8365"/>,target="RFC8365" format="default"/>, 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 ingressNVE. <vspace blankLines="1"/>DueNVE.</t> <t>Due to this behavior at the egress NVE, the ingress NVE is required to perform local replication to all directly attached ESs, regardless of theDesignated ForwarderDF election state, for all BUM traffic ingressing from the accessAttachment Circuits (ACs).ACs. This local replication at the ingress NVE is the basis for the termLocal Bias. <vspace blankLines="1"/>Local"Local Bias".</t> <t>Local Bias is not suitable for Single-Active multihoming, as the ingress NVE deactivates the ACs for which it is not theDesignated Forwarder.DF. Consequently, local replication tonon-Designated Forwardernon-DF ACs cannot occur, leading to transient in-flight BUM packetsto bebeing looped back to the originating site by newly electedDesignated ForwarderDF egress NVEs.</t></list></t></li> </ol> <t><xreftarget="RFC8365"/>target="RFC8365" format="default"/> 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 MPLStunnels,tunnels such asMPLS over GRE (MPLSoGRE)MPLSoGRE orMPLS over UDP (MPLSoUDP),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 ingressNetwork Virtualization Edge (NVE).</t>NVE.</t> <t>Similarly, certain IP tunnels-(those that include an identifier for the sourceEthernet Segment (ES)ES in the tunnelheader -header) may also potentially support either procedure. Examples of such tunnels include GENEVE andSRv6.:</t> <t><list style="symbols">SRv6:</t> <ul spacing="normal"> <li> <t>In a GENEVE tunnel, the source IP address identifies the ingressNVE therefore local biasNVE; therefore, Local Bias is possible. Also,<xref target="I-D.ietf-bess-evpn-geneve"/> sectionSection 4.1 of <xref target="I-D.ietf-bess-evpn-geneve" format="default"/> defines an Ethernet optionTLV (Type Length Value)Type-Length-Value (TLV) to encode an ESI label value.</t> </li> <li> <t>In an SRv6 tunnel, the source IP address identifies the ingress NVE. By default, and as outlined in <xreftarget="RFC9252"/>,target="RFC9252" format="default"/>, 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) (see <xreftarget="RFC9252"/> (section 6.1.1)target="RFC9252" sectionFormat="of" section="6.1.1"/> and <xreftarget="RFC8986"/> (section 4.12)target="RFC8986" sectionFormat="of" section="4.12"/>) of the service Segment Identifier (SID) received on an A-D per ES route from the egress PE.</t></list></t></li> </ul> <t><xreftarget="Tunnel"/>target="Tunnel" format="default"/> presents various tunnel encapsulations along with their supported and default Split Horizon methods. For GENEVE, the defaultSplit Horizon Type (SHT)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"ESI Labelfilteringfiltering" refers to the Split Horizon filtering based on the presence of a sourceEthernet Segment (ES)ES identifier in the tunnel header.</t> <t>This document classifies the tunnel encapsulations used by EVPNinto:<list style="numbers">into:</t> <!-- [rfced] For clarity and consistency with other list items, may we adjust the term "(SR-)MPLS" as seen below? Original: 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 Perhaps: This document classifies the tunnel encapsulations used by EVPN into: 1. IP-based MPLS tunnels 2. MPLS and SR-MPLS tunnels 3. IP tunnels 4. SRv6 tunnels b.) "(SR-)MPLS" also appears in the instances below. For ease of the reader, may we update these instances similarly? Originals: * (SR-)MPLS tunnels only support ESI Label-based Split Horizon filtering | (SR-)MPLS | ESI Label filtering | No | Yes | --> <ol spacing="normal" type="1"><li> <t>IP-based MPLS tunnels</t> </li> <li> <t>(SR-)MPLS tunnels, that is, MPLS and Segment Routing with MPLS data plane tunnels</t> </li> <li> <t>IP tunnels</t> </li> <li> <t>SRv6 tunnels</t></list></t></li> </ol> <t><xreftarget="Tunnel"/>target="Tunnel" format="default"/> lists the encapsulations supported by this document. Any tunnel encapsulation not listed in <xreftarget="Tunnel"/>)target="Tunnel" format="default"/> 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:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>IP-based MPLS tunnels and SRv6 tunnels are capable of supporting both Split Horizon filtering methods.</t> </li> <li> <t>(SR-)MPLS tunnels only support ESI Label-based Split Horizonfiltering</t>filtering.</t> </li> <li> <t>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.</t></list></t> <texttable</li> </ul> <table align="left"anchor="Tunnel" style="all" title="Tunnelanchor="Tunnel"> <name>Tunnel Encapsulations and Split HorizonTypes"> <ttcol>Tunnel Encapsulation</ttcol> <ttcol>DefaultTypes</name> <thead> <tr> <th align="left">Tunnel Encapsulation</th> <th align="left">Default Split Horizon Type(SHT)</ttcol> <ttcol>Supports(SHT)</th> <th align="left">Supports LocalBias</ttcol> <ttcol>Supports ESI Label</ttcol> <c>MPLSoGREBias</th> <th align="left">Supports ESI Label</th> </tr> </thead> <tbody> <tr> <td align="left">MPLSoGRE (IP-basedMPLS)</c> <c>ESI Label filtering</c> <c>Yes</c> <c>Yes</c> <c>MPLSoUDPMPLS)</td> <td align="left">ESI Label filtering</td> <td align="left">Yes</td> <td align="left">Yes</td> </tr> <tr> <td align="left">MPLSoUDP (IP-basedMPLS)</c> <c>ESI Label filtering</c> <c>Yes</c> <c>Yes</c> <c>(SR-)MPLS</c> <c>ESI Label filtering</c> <c>No</c> <c>Yes</c> <c>VXLANMPLS)</td> <td align="left">ESI Label filtering</td> <td align="left">Yes</td> <td align="left">Yes</td> </tr> <tr> <td align="left">(SR-)MPLS</td> <td align="left">ESI Label filtering</td> <td align="left">No</td> <td align="left">Yes</td> </tr> <tr> <td align="left">VXLAN (IPtunnels)</c> <c>Local Bias</c> <c>Yes</c> <c>No</c> <c>NVGREtunnels)</td> <td align="left">Local Bias</td> <td align="left">Yes</td> <td align="left">No</td> </tr> <tr> <td align="left">NVGRE (IPtunnels)</c> <c>Local Bias</c> <c>Yes</c> <c>No</c> <c>VXLAN-GPEtunnels)</td> <td align="left">Local Bias</td> <td align="left">Yes</td> <td align="left">No</td> </tr> <tr> <td align="left">VXLAN-GPE (IPtunnels)</c> <c>Local Bias</c> <c>Yes</c> <c>No</c> <c>GENEVEtunnels)</td> <td align="left">Local Bias</td> <td align="left">Yes</td> <td align="left">No</td> </tr> <tr> <td align="left">GENEVE (IPtunnels)</c> <c>Localtunnels)</td> <td align="left">Local Bias(no(if no ESI Lb), ESI Label (if ESIlb)</c> <c>Yes</c> <c>Yes</c> <c>SRv6</c> <c>ESI Label filtering</c> <c>Yes</c> <c>Yes</c> </texttable>lb)</td> <td align="left">Yes</td> <td align="left">Yes</td> </tr> <tr> <td align="left">SRv6</td> <td align="left">ESI Label filtering</td> <td align="left">Yes</td> <td align="left">Yes</td> </tr> </tbody> </table> <t>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.</t> <t>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 NVGRE, will continue to adhere to the procedures specified in <xreftarget="RFC8365"/>.target="RFC8365" format="default"/>. 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. </t> </section> </section> <section anchor="sect-2"title="BGPnumbered="true" toc="default"> <name>BGP EVPNExtensions">Extensions</name> <t>Extensions to EVPN are required to enable NVEs to advertise their preferred Split Horizon method for a given ES. <xreftarget="esi-label-extended-community"/>target="esi-label-extended-community" format="default"/> illustrates the ESI Label extended community (<xreftarget="RFC7432"/> Section 7.5),target="RFC7432" sectionFormat="of" 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.</t> <figureanchor="esi-label-extended-community" title="ESIanchor="esi-label-extended-community"> <name>ESI Labelextended community"> <artwork><![CDATA[Extended Community</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t><xreftarget="RFC7432"/>target="RFC7432" format="default"/> defines the low-order bit of the Flags octet (bit 0) as the "Single-Active" bit:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>A value of 0 means that the multihomed ES is operating in All-Active multihoming redundancy mode.</t> </li> <li> <t>A value of 1 means that the multihomed ES is operating in Single-Active multihoming redundancy mode.</t></list><xref target="sect-5"/></li> </ul> <t><xref target="sect-5" format="default"/> establishes a registry for the Flags octet, designating the "Single-Active" bit as the low-order bit of the newly definedmultihoming redundancy modeMultihoming Redundancy Mode field.</t> <section anchor="sect-2.1"title="Thenumbered="true" toc="default"> <name>The Split HorizonType">Type</name> <t><xreftarget="RFC8365"/>target="RFC8365" format="default"/> does not include any explicit indication regarding the Split Horizon method in the A-D perEthernet Segment (ES)ES route. In this document, the Split Horizon procedure defined in <xreftarget="RFC8365"/> (section 8.3.1)target="RFC8365" sectionFormat="of" 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 specifies that the two high-order bits in the Flags octet (bits 6 and 7) constitute the "Split Horizon Type"(SHT)or "SHT" field, where:</t><figure> <artwork><![CDATA[<!-- [rfced] Please review the artwork in Section 2.1 and let us know what "Section 5" refers to and if any other updates are needed. Perhaps this refers to Table 3? Original: RED = "Multihoming Redundancy Mode" field (section 5) --> <!-- [rfced] The figure in Section 2.1 indicates that value 11 is "reserved for future use". However, table 3 (and the IANA registry) indicates the value is unassigned. "Reserved" and "Unassigned" have distinct meanings. Please review "Well-Known Registration Status Terminology" in RFC 8126 <https://www.rfc-editor.org/rfc/rfc8126.html#section-6> and let us know which is correct. Section 2.1 (double hyphen changed to single hyphen so this comment appears correctly in the XML file: 1 1 -> reserved for future use Table 3: | 11 | Unassigned | | --> <artwork name="" type="" align="left" alt=""> <![CDATA[ 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 --> ESILabel basedLabel-based filtering 1 1 --> reserved for future use ]]></artwork></figure> <t><list style="symbols"><ul spacing="normal"> <li> <t>SHT = 00 is backwards compatible with <xreftarget="RFC8365"/>target="RFC8365" format="default"/> and <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, and indicates that the advertising NVE intends to use the default or built-in SHT. The default SHT is shown in <xreftarget="Tunnel"/>target="Tunnel" format="default"/> for each encapsulation. An egress NVE that follows the <xreftarget="RFC8365"/>target="RFC8365" format="default"/> behavior and does not support this specification will ignore the SHT bits (which is equivalent toprocessprocessing them as a value of 00).</t> </li> <li> <t>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.</t> </li> <li> <t>SHT = 10 indicates that the advertising NVE intends to use the ESILabel basedLabel-based Split Horizon method procedures in the ES for which the AD per-ES route is advertised.</t> </li> <li> <t>SHT = 11 is a reserved value, for future use.</t></list></t></li> </ul> </section> <section anchor="sect-2.2"title="Usenumbered="true" toc="default"> <name>Use of the Split Horizon TypeInin A-DPerper ESRoutes">Routes</name> <t>The following behavior is observed:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>An SHT value of 01 or 10MUST NOT<bcp14>MUST NOT</bcp14> be used with encapsulations that support only one SHT in <xreftarget="Tunnel"/>,target="Tunnel" format="default"/>, andMAY<bcp14>MAY</bcp14> be used by encapsulations that support the two SHTs in <xreftarget="Tunnel"/>.</t>target="Tunnel" format="default"/>.</t> </li> <li> <t>An SHT value differentfromthan 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.</t> </li> <li> <t>In case of an inconsistency in the SHT value advertised by the NVEs attached to the same ES for a given EVI, all the NVEsMUST<bcp14>MUST</bcp14> revert to the behavior in <xreftarget="RFC8365"/> behavior,target="RFC8365" format="default"/> and use the default SHT in <xreftarget="Tunnel"/>,target="Tunnel" format="default"/>, irrespective of the advertised SHT.</t> </li> <li> <t>An SHT differentfromthan 00MUST NOT<bcp14>MUST NOT</bcp14> be set if theSingle-Active"Single-Active" bit is set. A received A-D per ES route whereSingle-Activethe "Single-Active" and SHT bits are differentfromthan zeroMUST<bcp14>MUST</bcp14> follow the treat-as-withdraw behavior in <xreftarget="RFC7606"/>.</t>target="RFC7606" format="default"/>.</t> </li> <li> <t>The SHTMUST<bcp14>MUST</bcp14> 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 <xreftarget="sect-3"/>target="sect-3" format="default"/> for NVEs supporting multiple encapsulations).</t></list></t></li> </ul> <t>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 Encapsulationextended community,Extended Community, as defined in <xreftarget="RFC9012"/>.target="RFC9012" format="default"/>. 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 the ESI Label, respectively.</t><t>An<!-- [rfced] How may we adjust the text below to avoid using an RFC as an adjective? Original: An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with<xref target="RFC9012"/>[RFC9012] Tunnel encapsulation types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP tunnel encapsulation extended community at all. Perhaps: An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with the following tunnel encapsulation types from [RFC9012]: VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP Tunnel Encapsulation Extended Community at all. --> <t>An egress NVE <bcp14>MUST NOT</bcp14> use an SHT value other than 00 when advertising an A-D per ES route with <xref target="RFC9012" format="default"/> 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 valueMUST<bcp14>MUST</bcp14> be set to 00. If a route with any of the mentioned encapsulation options is received and has an SHT value differentfromthan 00, itSHOULD<bcp14>SHOULD</bcp14> apply the treat-as-withdraw behavior, per <xreftarget="RFC7606"/>.</t>target="RFC7606" format="default"/>.</t> <!-- [rfced] How may we update the citations in the text below? We were unable to find either "Tunnel encapsulation type 19" or "GENEVE" encapsulation in [RFC9012]. We note that the IANA entry refers to RFC 8926 (19 Geneve Encapsulation). Original: 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. Perhaps: An egress NVE advertising A-D per ES route(s) for an ES with GENEVE encapsulation [RFC9012] (and tunnel encapsulation type 19 [EVPN-GENEVE]) MAY use an SHT value of 01 or 10. --> <t>An egress NVE advertising A-D per ES route(s) for an ES with GENEVE encapsulation (<xreftarget="RFC9012"/>,target="RFC9012" format="default"/>, Tunnel encapsulation type 19, <xreftarget="I-D.ietf-bess-evpn-geneve"/>) MAYtarget="I-D.ietf-bess-evpn-geneve" format="default"/>) <bcp14>MAY</bcp14> 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 <xreftarget="I-D.ietf-bess-evpn-geneve"/>.target="I-D.ietf-bess-evpn-geneve" format="default"/>. 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 a non-zero Source-ID is present. A value of 00 indicates the default behavior outlined in <xreftarget="Tunnel"/>,target="Tunnel" format="default"/>, which is to use Local Biasif: a) no ESI-Labelif:</t> <ol type="a"> <li>no ESI Label is present in the Ethernet option TLV, orb) if there</li> <li>there is no Ethernet optionTLV. Otherwise,TLV.</li> </ol> <t>Otherwise, the ESI Label Split Horizon method is applied.</t> <t>These procedures assume a single encapsulation supported in the egress NVE. <xreftarget="sect-3"/>target="sect-3" format="default"/> describes additional procedures for NVEs supporting multiple encapsulations.</t> </section> <section anchor="sect-2.3"title="ESInumbered="true" toc="default"> <name>The ESI Label ValueInin A-DPerper ESRoutes">Routes</name> <t>This document also updates <xreftarget="RFC8365"/>target="RFC8365" format="default"/> regarding the value that is advertised in the ESI Label field of the ESI Label extended community, as follows:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>The A-D per ES route(s) for an ESMAY<bcp14>MAY</bcp14> have an ESI Label value of zero if the SHT value is 01. <xreftarget="sect-2.2"/>target="sect-2.2" format="default"/> 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.</t> </li> <li> <t>The A-D per ES route(s) for an ESMAY<bcp14>MAY</bcp14> have an ESI Label value of zero for VXLAN or NVGRE encapsulations.</t></list></t></li> </ul> </section><section anchor="sect-2.4" title="Backwards<!-- [rfced] How may we rephrase the title of this section to avoid using an RFC as an adjective? Original: 2.4. Backwards Compatibility With RFC8365NVEs">NVEs Perhaps (no RFC mentioned): 2.4. Backwards Compatibility with NVEs Perhaps (RFC mentioned): 2.4. Backwards Compatibility with NVEs from RFC 8365 --> <section anchor="sect-2.4" numbered="true" toc="default"> <name>Backwards Compatibility with RFC 8365 NVEs</name> <t>As discussed in <xreftarget="sect-2.2"/>target="sect-2.2" format="default"/>, this specification is backwards compatible with the Split Horizon filtering behavior in <xreftarget="RFC8365"/>target="RFC8365" format="default"/> and a non-upgraded NVE can be attached to the same ES as other NVEs supporting this specification.</t> <t>An NVE maintains an administrative SHT value for anEthernet Segment (ES),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.</t> <t>This document assumes that an implementation of <xreftarget="RFC7432"/>target="RFC7432" format="default"/> or <xreftarget="RFC8365"/>target="RFC8365" format="default"/> 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 theSingle-Active"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, itMUST<bcp14>MUST</bcp14> revert its operational SHT to the default Split Horizon method, as described in <xreftarget="Tunnel"/>,target="Tunnel" format="default"/>, irrespective of its administrative SHT.</t> <t>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 NVEMUST<bcp14>MUST</bcp14> use the default Split Horizon method specified in <xreftarget="Tunnel"/>target="Tunnel" format="default"/> as its operational SHT, regardless of its administrative SHT.</t> <t>All NVEs attached to an ES with an operational SHT value of 10MUST<bcp14>MUST</bcp14> advertise a valid, non-zero ESI Label. If the operational SHT value is 01, the ESI LabelMAY<bcp14>MAY</bcp14> 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.</t> <t>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, itMUST<bcp14>MUST</bcp14> 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 NVE2MUST<bcp14>MUST</bcp14> 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.</t> </section> </section> <section anchor="sect-3"title="Proceduresnumbered="true" toc="default"> <name>Procedures for NVEs Supporting MultipleEncapsulations">Encapsulations</name> <t>As specified in <xreftarget="RFC8365"/>,target="RFC8365" format="default"/>, 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 <xreftarget="RFC9012"/>target="RFC9012" format="default"/> 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 the 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 EncapsulationAttribute. </t>Attribute.</t> <t>It is important to note that an NVEMAY<bcp14>MAY</bcp14> 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).(RTs). The total set ofRoute TargetsRTs 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.</t> <t>As per <xreftarget="RFC8365"/>,target="RFC8365" format="default"/>, an NVE that advertises multiple encapsulations in the A-D per ES route(s) for an ESMUST<bcp14>MUST</bcp14> advertise encapsulations that use the same Split Horizon filtering method in the same route. For example:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>An A-D per ES route for ES-x may be advertised with {VXLAN, NVGRE} encapsulations.</t> </li> <li> <t>An A-D per ES route for ES-y may be advertised with {MPLS, MPLSoUDP, MPLSoGRE} encapsulations (or a subset).</t><t>But</li> <li> <t>However, an A-D per ES route for ES-zMUST NOT<bcp14>MUST NOT</bcp14> be advertised with {MPLS, VXLAN} encapsulations.</t></list></t></li> </ul> <t>This document extends the described behavior as follows:</t><t><list style="letters"><ol spacing="normal" type="a"><li> <t>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, theSplit Horizon Type (SHT)SHT valueMUST<bcp14>MUST</bcp14> 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 valueMUST<bcp14>MUST</bcp14> be 00 and thebehaviortreat-as-withdraw behavior <xreftarget="RFC7606"/>target="RFC7606" format="default"/> is applied in case of any other value.</t> </li> <li> <t>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 valueMAY<bcp14>MAY</bcp14> 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<bcp14>MAY</bcp14> be advertised in an A-D per ES route with an SHT value of 01. The ESI Label value in this caseMAY<bcp14>MAY</bcp14> be zero.</t> </li> <li> <t>If ES-z with an 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 methodMUST<bcp14>MUST</bcp14> be advertised. For example, consider an ES-z with nRoute Targets (RTs) where:<list style="symbols">RTs, where:</t> <ul spacing="normal"> <li> <t>the EVIs corresponding to (RT1..RTi) support VXLAN,</t> </li> <li> <t>the ones for (RTi+1..RTm) (with i<m) support MPLSoUDP with LocalBias,</t> <t>and theBias, and</t> </li> <li> <t>the ones for (RTm+1..RTn) (with m<n) support GENEVE with ESILabel basedLabel-based Split Horizon.</t></list>In</li> </ul> <t>In this scenario, three groups of A-D per ES routesMUST<bcp14>MUST</bcp14> be advertised forES-z:<list style="symbols">ES-z:</t> <ul spacing="normal"> <li> <t>A-D per ES route group 1, including(RT1..RTi),(RT1..RTi) with encapsulation{VXLAN},{VXLAN} and an SHT value of 00. The ESI LabelMAY<bcp14>MAY</bcp14> be zero.</t> </li> <li> <t>A-D per ES route group 2, including(RTi+1..RTm),(RTi+1..RTm) with encapsulation{MPLSoUDP},{MPLSoUDP} and an SHT value of 01. The ESI LabelMAY<bcp14>MAY</bcp14> be zero.</t> </li> <li> <t>A-D per ES route group 3, including(RTm+1..RTn),(RTm+1..RTn) with encapsulation{GENEVE},{GENEVE} and an SHT value of 10. The ESI LabelMUST<bcp14>MUST</bcp14> have a valid, non-zero value, and the Ethernet option as defined in <xreftarget="RFC8926"/> MUSTtarget="RFC8926" format="default"/> <bcp14>MUST</bcp14> be advertised.</t></list></t> </list></t></li> </ul> </li> </ol> <t>As per <xreftarget="RFC8365"/>,target="RFC8365" format="default"/>, it is the responsibility of the operator of a given EVI to ensure that all of the NVEs within that EVI support a common encapsulation. Failure to meet this condition may result in service disruption or failure.</t> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>All the security considerations described in <xreftarget="RFC7432"/>target="RFC7432" format="default"/> are applicable to this document.</t> <t>Additionally, this document modifies the procedures for Split Horizon filtering as outlined in <xreftarget="RFC8365"/>,target="RFC8365" format="default"/>, offering operators a choice between Local Bias and ESI Label-based filtering for tunnels that support both methods. Misconfiguration of the desiredSplit Horizon Type (SHT)SHT could lead to forwarding behaviors that differ from the intended configuration. Apart from this risk, this document describes procedures to ensure that allProvider Edge (PE)PE devices orNetwork Virtualization Edges (NVEs)NVEs connected to the sameEthernet Segment (ES)ES agree on a common SHT method, with a fallback to a default behavior in case of a mismatch in the SHT bits being advertised by any two PEs or NVEs in theEthernet Segment.ES. Consequently, unauthorized changes to the SHT configuration by an attacker on a single PE or NVE of theEthernet SegmentES should not cause traffic disruption (as long as the SHT value is valid as per this document) but may result in alterations to forwarding behavior.</t> </section> <section anchor="sect-5"title="IANA Considerations"> <t>This document creates a registry callednumbered="true" toc="default"> <name>IANA Considerations</name> <t>Per this document, IANA has created the "EVPN ESI Label Extended Community Flags" registry for the 1-octet Flags field in the ESI Label Extended Community <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, as follows:</t><texttable> <ttcol>Bit Position</ttcol> <ttcol>Name</ttcol> <ttcol>Reference</ttcol> <c>0-1</c> <c>Multihoming<table align="center"> <thead> <tr> <th align="left">Bit Position</th> <th align="left">Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">0-1</td> <td align="left">Multihoming RedundancyMode</c> <c><xref target="RFC7432"/></c> <c>2-5</c> <c>Unassigned</c> <c/> <c>6-7</c> <c>Split Horizon Type</c> <c>This Document</c> </texttable> <t>This document also creates aMode</td> <td align="left"> <xref target="RFC7432" format="default"/></td> </tr> <tr> <td align="left">2-5</td> <td align="left">Unassigned</td> <td align="left"/> </tr> <tr> <td align="left">6-7</td> <td align="left">Split Horizon Type</td> <td align="left">RFC 9746</td> </tr> </tbody> </table> <!-- [rfced] May we make these registryfortitles plural? Multihoming Redundancy Mode -> Multihoming Redundancy Modes Split Horizon Type -> Split Horizon Types --> <!-- [rfced] Because "mode" is part of the registry and column titles, does "mode" need to appear in description? From Table 3 and the IANA registry [1]: +=======+=============================+===========+ | Value | Multihoming redundancy mode | Reference | +=======+=============================+===========+ | 00 | All-Active mode | [RFC7432] | | 01 | Single-Active mode | [RFC7432] | [1] https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#multihoming-redundancy-mode --> <t>IANA has also created the "Multihoming Redundancy Mode" registry for the related field of theEVPN"EVPN ESI Label Extended CommunityFlags. ThisFlags". The registryis called "Multihominghas been populated with the following initial values: </t> <table align="center"> <thead> <tr> <th align="left">Value</th> <th align="left">Multihoming RedundancyMode" and is initialized as follows:</t> <texttable> <ttcol>Value</ttcol> <ttcol>Multihoming redundancy mode</ttcol> <ttcol>Reference</ttcol> <c>00</c> <c>All-Active mode</c> <c><xref target="RFC7432"/></c> <c>01</c> <c>Single-Active mode</c> <c><xref target="RFC7432"/></c> <c>10</c> <c>Unassigned</c> <c/> <c>11</c> <c>Unassigned</c> <c/> </texttable>Mode</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">00</td> <td align="left">All-Active mode</td> <td align="left"> <xref target="RFC7432" format="default"/></td> </tr> <tr> <td align="left">01</td> <td align="left">Single-Active mode</td> <td align="left"> <xref target="RFC7432" format="default"/></td> </tr> <tr> <td align="left">10</td> <td align="left">Unassigned</td> <td align="left"/> </tr> <tr> <td align="left">11</td> <td align="left">Unassigned</td> <td align="left"/> </tr> </tbody> </table> <t>Finally,a third registry forIANA has created the "Split Horizon Type" registry for the related field of theEVPN"EVPN ESI Label Extended CommunityFlags is created by this document too. ThisFlags". The registryis called "Split Horizon Type" and is initialized as follows:</t> <texttable> <ttcol>Value</ttcol> <ttcol>Splithas been populated with the following initial values:</t> <table align="center"> <thead> <tr> <th align="left">Value</th> <th align="left">Split Horizon Typevalue</ttcol> <ttcol>Reference</ttcol> <c>00</c> <c>Default SHT</c> <c>This document</c> <c>01</c> <c>Local Bias</c> <c>This document</c> <c>10</c> <c>ESI Label based filtering</c> <c>This document</c> <c>11</c> <c>Unassigned</c> <c/> </texttable>Value</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">00</td> <td align="left">Default SHT</td> <td align="left">RFC 9746</td> </tr> <tr> <td align="left">01</td> <td align="left">Local Bias</td> <td align="left">RFC 9746</td> </tr> <tr> <td align="left">10</td> <td align="left">ESI Label-based filtering</td> <td align="left">RFC 9746</td> </tr> <tr> <td align="left">11</td> <td align="left">Unassigned</td> <td align="left"/> </tr> </tbody> </table> <t>New registrations in the "EVPN ESI Label Extended Community Flags", "Multihoming Redundancy Mode", and "Split Horizon Type" registries will be made through the "IETF Review" procedure defined in <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. These registries are located in the "Border Gateway Protocol (BGP) Extended Communities" registry group.</t> </section> </middle> <back> <displayreference target="I-D.ietf-bess-evpn-geneve" to="EVPN-GENEVE"/> <displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="VXLAN-GPE"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"/> </references> <references> <name>Informative References</name> <!-- [I-D.ietf-bess-evpn-geneve] IESG state: I-D Exists as of 09/05/24--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-bess-evpn-geneve.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4023.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <!-- [I-D.ietf-nvo3-vxlan-gpe] IESG state: Expired as of 09/05/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-nvo3-vxlan-gpe.xml"/> <!-- [IANA-BGP-TUNNEL-ENCAP] --> <reference anchor="TUNNEL-ENCAP" target="https://www.iana.org/assignments/bgp-tunnel-encapsulation"> <front> <title>Border Gateway Protocol (BGP) Tunnel Encapsulation</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> </references> </references> <sectionanchor="sect-6" title="Acknowledgments">anchor="Acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to thankAnoop Ghanwani, Gyan Mishra and Jeffrey Zhang<contact fullname="Anoop Ghanwani"/>, <contact fullname="Gyan Mishra"/>, and <contact fullname="Jeffrey Zhang"/> for their review and useful comments. Thanks toGunter van<contact fullname="Gunter Van deVeldeVelde"/> andSue Hares<contact fullname="Sue Hares"/> as well, for their thorough review.</t> </section></middle> <back> <references title="Normative References"> &RFC2119; &RFC8174; &RFC8126; &RFC7432; &RFC8365; &RFC9252; </references> <references title="Informative References"> &I-D.ietf-bess-evpn-geneve; &RFC7348; &RFC4023; &RFC7637; &RFC7510; &RFC8926; &RFC9012; &RFC7606; &RFC8660; &RFC8986; &RFC8402; &RFC8754; &I-D.ietf-nvo3-vxlan-gpe; <reference anchor="IANA-BGP-TUNNEL-ENCAP" target="https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-types"> <front> <title>Border Gateway Protocol (BGP) Tunnel Encapsulation</title> <author fullname="IANA"> <organization/> </author> <date/> </front> </reference> </references><!-- [rfced] Please review the following questions and changes regarding the terminology used in this document: a.) We note that the term "MPLSoX" does not appear in this document after it is introduced in Section 1. May we remove this term from the terminology list? Original: * MPLSoX: refers to MPLS over any IP encapsulation. Examples are MPLS-over-UDP or MPLS-over-GRE. b.) FYI - For consistency with RFCs 8402, 8986, and 9252, we have updated the terms below as follows. Please review and let us know any objections. Original: Segment Routing with MPLS data plane (SR-MPLS) Segment Routing with IPv6 data plane (SRv6) Current: SR over MPLS (SR-MPLS) Segment Routing over IPv6 (SRv6) --> <!-- [rfced] The references in this document do not appear to be sorted. Would you like to order them alphanumerically? --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>