<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-bess-evpn-mh-split-horizon-11" number="9746" ipr="trust200902" consensus="true" submissionType="IETF" updates="7432, 8365" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2025-03-06T11:41:44" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon-11" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9746" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="EVPN MH Split-Horizon Extensions">BGP EVPN Multihoming Extensions for Split-Horizon Filtering</title>
    <seriesInfo name="RFC" value="9746" stream="IETF"/>
    <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabadan">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <street>520 Almanor Avenue</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94085</code>
          <country>United States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <street>520 Almanor Avenue</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94085</code>
          <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" showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <email>wlin@juniper.net</email>
      </address>
    </author>
    <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>
    <keyword>EVPN Multihoming</keyword>
    <keyword>split-horizon filtering</keyword>
    <keyword>split horizon filtering</keyword>
    <keyword>local bias</keyword>
    <keyword>ESI</keyword>
    <keyword>encapsulations</keyword>
    <keyword>SHT</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">An Ethernet Virtual Private Network (EVPN) is commonly used with
      Network Virtualization Overlay (NVO) tunnels as well as with MPLS and
      Segment Routing (SR) tunnels. The multihoming procedures in EVPN may
      vary based on the type of tunnel used within the EVPN Broadcast
      Domain. Specifically, there are two multihoming split-horizon procedures
      designed to prevent looped frames on multihomed Customer Edge (CE)
      devices: the Ethernet Segment Identifier (ESI) Label-based procedure and
      the local-bias procedure. The ESI Label-based split-horizon procedure is
      applied to MPLS-based tunnels such as MPLS over UDP (MPLSoUDP), while
      the local-bias procedure is used for other tunnels such as Virtual
      eXtensible Local Area Network (VXLAN) tunnels.</t>
      <t indent="0" pn="section-abstract-2">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
      MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network Virtualization
      Encapsulation (Geneve), and Segment Routing over IPv6 (SRv6)
      tunnels. This document updates the EVPN multihoming procedures described
      in RFCs 7432 and 8365, enabling operators to select the split-horizon
      procedure that meets their specific requirements.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9746" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-terminology">Conventions and Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-split-horizon-filtering-and">Split-Horizon Filtering and Tunnel Encapsulations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bgp-evpn-extensions">BGP EVPN Extensions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-split-horizon-type">The Split-Horizon Type</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-the-split-horizon-ty">Use of the Split-Horizon Type in A-D per ES Routes</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-esi-label-value-in-a-d-">The ESI Label Value in A-D per ES Routes</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-compatibility-wit">Backwards Compatibility with NVEs from RFC 8365</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-procedures-for-nves-support">Procedures for NVEs Supporting Multiple Encapsulations</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Ethernet Virtual Private Networks (EVPNs) are commonly used with the
      following tunnel encapsulations:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-2">
        <li pn="section-1-2.1">
          <t indent="0" pn="section-1-2.1.1">Network Virtualization Overlay (NVO) tunnels, where the EVPN
          procedures are specified in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>.  MPLSoGRE <xref target="RFC4023" format="default" sectionFormat="of" derivedContent="RFC4023"/>, MPLSoUDP <xref target="RFC7510" format="default" sectionFormat="of" derivedContent="RFC7510"/>, Geneve <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/>,
          or VXLAN <xref target="RFC7348" format="default" sectionFormat="of" derivedContent="RFC7348"/> tunnels are
          considered NVO tunnels.</t>
        </li>
        <li pn="section-1-2.2">
          <t indent="0" pn="section-1-2.2.1">MPLS and Segment Routing over MPLS (SR-MPLS) tunnels, where the
          relevant EVPN procedures are specified in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>. SR-MPLS tunneling is specified in <xref target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>.</t>
        </li>
        <li pn="section-1-2.3">
          <t indent="0" pn="section-1-2.3.1">Segment Routing over IPv6 (SRv6) tunnels, where the relevant EVPN
          procedures are specified in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>. SRv6 is specified in <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> and <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-3">In this document, the term "split horizon" follows the definition in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>. Split horizon refers to the EVPN
      multihoming procedure that prevents a Provider 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 indent="0" pn="section-1-4">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 indent="0" pn="section-1-5">The ESI Label-based split-horizon procedure is used for MPLS or
      MPLS over X (MPLSoX) tunnels, such as MPLSoUDP, and its procedures
      are detailed in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>. Conversely, the local-bias
      procedure is used for IP-based tunnels, such as VXLAN tunnels, and it is
      described in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>.</t>
      <section anchor="sect-1.1" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-conventions-and-terminology">Conventions and Terminology</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
        <dl spacing="normal" indent="3" newline="false" pn="section-1.1-2">
          <dt pn="section-1.1-2.1">AC:</dt>
          <dd pn="section-1.1-2.2">Attachment Circuit</dd>
          <dt pn="section-1.1-2.3">A-D per ES route:</dt>
          <dd pn="section-1.1-2.4">Auto-Discovery per Ethernet Segment
            route (as defined in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>).</dd>
          <dt pn="section-1.1-2.5">Arg.FE2:</dt>
          <dd pn="section-1.1-2.6">Refers to the ESI filtering argument used for split horizon as
	    specified in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>.</dd>
          <dt pn="section-1.1-2.7">BD:</dt>
          <dd pn="section-1.1-2.8">Broadcast Domain. Refers to an emulated Ethernet, such that
	    two systems on the same BD will receive each other's BUM
	    traffic. In this document, BD also refers to the instantiation of
	    a BD on an EVPN PE. An EVPN PE can be attached to one or multiple
	    BDs of the same tenant.</dd>
          <dt pn="section-1.1-2.9">BUM:</dt>
          <dd pn="section-1.1-2.10">Broadcast, Unknown Unicast, and Multicast</dd>
          <dt pn="section-1.1-2.11">CE:</dt>
          <dd pn="section-1.1-2.12">Customer Edge</dd>
          <dt pn="section-1.1-2.13">DF:</dt>
          <dd pn="section-1.1-2.14">Designated Forwarder. As defined in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="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 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.</dd>
          <dt pn="section-1.1-2.15">ES:</dt>
          <dd pn="section-1.1-2.16">Ethernet Segment</dd>
          <dt pn="section-1.1-2.17">ESI:</dt>
          <dd pn="section-1.1-2.18">Ethernet Segment Identifier</dd>
          <dt pn="section-1.1-2.19">EVI:</dt>
          <dd pn="section-1.1-2.20">EVPN Instance</dd>
          <dt pn="section-1.1-2.21">EVI-RT:</dt>
          <dd pn="section-1.1-2.22">EVI Route Target. Refers to a group of NVEs attached to the same
            EVI that will share the same EVI-RT.</dd>
          <dt pn="section-1.1-2.23">Geneve:</dt>
          <dd pn="section-1.1-2.24">Generic Network Virtualization Encapsulation
            <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/> (see tunnel type 19 in <xref target="TUNNEL-ENCAP" format="default" sectionFormat="of" derivedContent="TUNNEL-ENCAP"/>).</dd>
          <dt pn="section-1.1-2.25">MPLS tunnels and non-MPLS NVO tunnels:</dt>
          <dd pn="section-1.1-2.26">Refers to
            Multiprotocol Label Switching (or the absence of it) Network
            Virtualization Overlay tunnels. NVO tunnels use an IP
            encapsulation for overlay frames, where the source IP address
            identifies the ingress NVE and the destination IP address identifies the
            egress NVE.</dd>
          <dt pn="section-1.1-2.27">MPLSoUDP:</dt>
          <dd pn="section-1.1-2.28">Multiprotocol Label Switching over User
            Datagram Protocol <xref target="RFC7510" format="default" sectionFormat="of" derivedContent="RFC7510"/> (see
            tunnel type 13 in <xref target="TUNNEL-ENCAP" format="default" sectionFormat="of" derivedContent="TUNNEL-ENCAP"/>).</dd>
          <dt pn="section-1.1-2.29">MPLSoGRE:</dt>
          <dd pn="section-1.1-2.30">Multiprotocol Label Switching over Generic
            Network Encapsulation <xref target="RFC4023" format="default" sectionFormat="of" derivedContent="RFC4023"/>
            (see tunnel type 11 in <xref target="TUNNEL-ENCAP" format="default" sectionFormat="of" derivedContent="TUNNEL-ENCAP"/>).</dd>
          <dt pn="section-1.1-2.31">MPLSoX:</dt>
          <dd pn="section-1.1-2.32">Refers to MPLS over any IP encapsulation, for
            example, MPLSoUDP or MPLSoGRE.</dd>
          <dt pn="section-1.1-2.33">NVE:</dt>
          <dd pn="section-1.1-2.34">Network Virtualization Edge</dd>
          <dt pn="section-1.1-2.35">NVGRE:</dt>
          <dd pn="section-1.1-2.36">Network Virtualization Using Generic Routing
            Encapsulation <xref target="RFC7637" format="default" sectionFormat="of" derivedContent="RFC7637"/> (see
            tunnel type 9 in <xref target="TUNNEL-ENCAP" format="default" sectionFormat="of" derivedContent="TUNNEL-ENCAP"/>).</dd>
          <dt pn="section-1.1-2.37">PE:</dt>
          <dd pn="section-1.1-2.38">Provider Edge</dd>
          <dt pn="section-1.1-2.39">RTs:</dt>
          <dd pn="section-1.1-2.40">Route Targets</dd>
          <dt pn="section-1.1-2.41">VXLAN:</dt>
          <dd pn="section-1.1-2.42">Virtual eXtensible Local Area Network <xref target="RFC7348" format="default" sectionFormat="of" derivedContent="RFC7348"/> (see tunnel type 8 in <xref target="TUNNEL-ENCAP" format="default" sectionFormat="of" derivedContent="TUNNEL-ENCAP"/>).</dd>
          <dt pn="section-1.1-2.43">VXLAN-GPE:</dt>
          <dd pn="section-1.1-2.44">VXLAN Generic Protocol Extension <xref target="I-D.ietf-nvo3-vxlan-gpe" format="default" sectionFormat="of" derivedContent="VXLAN-GPE"/> (see tunnel
            type 12 in <xref target="TUNNEL-ENCAP" format="default" sectionFormat="of" derivedContent="TUNNEL-ENCAP"/>).</dd>
          <dt pn="section-1.1-2.45">SHT:</dt>
          <dd pn="section-1.1-2.46">Split-Horizon Type. Refers to the split-horizon method
            that a PE intends to use and advertises in an A-D per ES
            route.</dd>
          <dt pn="section-1.1-2.47">SRv6:</dt>
          <dd pn="section-1.1-2.48">Segment Routing over IPv6 (see <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> and <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>).</dd>
          <dt pn="section-1.1-2.49">TLV:</dt>
          <dd pn="section-1.1-2.50">Type-Length-Value</dd>
        </dl>
        <t indent="0" pn="section-1.1-3">This document also assumes familiarity with the terminology of
        <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-split-horizon-filtering-and">Split-Horizon Filtering and Tunnel Encapsulations</name>
        <t indent="0" pn="section-1.2-1">EVPN supports two split-horizon filtering mechanisms:</t>
        <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-1.2-2">
          <li pn="section-1.2-2.1" derivedCounter="1.">
            <t indent="0" pn="section-1.2-2.1.1">ESI Label-based split-horizon filtering <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>:</t>
            <t indent="0" pn="section-1.2-2.1.2">When EVPN is employed for MPLS transport tunnels, an MPLS label
	   facilitates split-horizon filtering to support All-Active
	   multihoming. 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. This mechanism effectively prevents forwarding loops for BUM traffic. </t>
            <t indent="0" pn="section-1.2-2.1.3">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 DF for an ES.</t>
          </li>
          <li pn="section-1.2-2.2" derivedCounter="2.">
            <t indent="0" pn="section-1.2-2.2.1">Local-bias filtering <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>:</t>
            <t indent="0" pn="section-1.2-2.2.2">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 ES interface at the
            egress NVE.</t>
            <t indent="0" pn="section-1.2-2.2.3">In summary and as specified in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="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.</t>
            <t indent="0" pn="section-1.2-2.2.4">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 DF election state, for all BUM traffic
            ingressing from the access ACs. This local replication at the
            ingress NVE is the basis for the term "local bias".</t>
            <t indent="0" pn="section-1.2-2.2.5">Local bias is not suitable for Single-Active multihoming, as
            the ingress NVE deactivates the ACs for which it is not the
            DF. Consequently, local replication to non-DF ACs cannot occur,
            leading to transient in-flight BUM packets being looped back to
            the originating site by newly elected DF egress NVEs.</t>
          </li>
        </ol>
        <t indent="0" pn="section-1.2-3"><xref target="RFC8365" format="default" sectionFormat="of" derivedContent="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 MPLSoGRE or 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
        NVE.</t>
        <t indent="0" pn="section-1.2-4">Similarly, certain IP tunnels (those that include an identifier for
        the source ES in the tunnel header) may also potentially support either
        procedure. Examples of such tunnels include Geneve and SRv6:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.2-5">
          <li pn="section-1.2-5.1">
            <t indent="0" pn="section-1.2-5.1.1">In a Geneve tunnel, the source IP address identifies the
            ingress NVE; therefore, local bias is possible. Also, Section 4.1
            of <xref target="I-D.ietf-bess-evpn-geneve" format="default" sectionFormat="of" derivedContent="EVPN-GENEVE"/>
            defines an Ethernet option Type-Length-Value (TLV) to encode an
            ESI label value.</t>
          </li>
          <li pn="section-1.2-5.2">
            <t indent="0" pn="section-1.2-5.2.1">In an SRv6 tunnel, the source IP address identifies the ingress
            NVE. By default, and as outlined in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="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) (see <xref target="RFC9252" sectionFormat="of" section="6.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9252#section-6.1.1" derivedContent="RFC9252"/> and <xref target="RFC8986" sectionFormat="of" section="4.12" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8986#section-4.12" derivedContent="RFC8986"/>) of the service Segment Identifier (SID) received
            on an A-D per ES route from the egress PE.</t>
          </li>
        </ul>
        <t indent="0" pn="section-1.2-6"><xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/> presents various tunnel
        encapsulations along with their supported and default split-horizon
        methods. For Geneve, the default 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 ES
        identifier in the tunnel header.</t>
        <t indent="0" pn="section-1.2-7">This document classifies the tunnel encapsulations used by EVPN
        into:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1.2-8"><li pn="section-1.2-8.1" derivedCounter="1.">
            <t indent="0" pn="section-1.2-8.1.1">IP-based MPLS tunnels</t>
          </li>
          <li pn="section-1.2-8.2" derivedCounter="2.">
            <t indent="0" pn="section-1.2-8.2.1">MPLS and SR-MPLS tunnels</t>
          </li>
          <li pn="section-1.2-8.3" derivedCounter="3.">
            <t indent="0" pn="section-1.2-8.3.1">IP tunnels</t>
          </li>
          <li pn="section-1.2-8.4" derivedCounter="4.">
            <t indent="0" pn="section-1.2-8.4.1">SRv6 tunnels</t>
          </li>
        </ol>
        <t indent="0" pn="section-1.2-9"><xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/> lists the encapsulations
        supported by this document. Any tunnel encapsulation not listed in
        <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.2-10">
          <li pn="section-1.2-10.1">
            <t indent="0" pn="section-1.2-10.1.1">IP-based MPLS tunnels and SRv6 tunnels are capable of
            supporting both split-horizon filtering methods.</t>
          </li>
          <li pn="section-1.2-10.2">
            <t indent="0" pn="section-1.2-10.2.1">MPLS and SR-MPLS tunnels only support ESI Label-based split-horizon filtering.</t>
          </li>
          <li pn="section-1.2-10.3">
            <t indent="0" pn="section-1.2-10.3.1">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>
          </li>
        </ul>
        <table align="left" anchor="Tunnel" pn="table-1">
          <name slugifiedName="name-tunnel-encapsulations-and-s">Tunnel Encapsulations and Split-Horizon Types</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Tunnel Encapsulation</th>
              <th align="left" colspan="1" rowspan="1">Default Split-Horizon Type (SHT)</th>
              <th align="left" colspan="1" rowspan="1">Supports Local Bias</th>
              <th align="left" colspan="1" rowspan="1">Supports ESI Label</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">MPLSoGRE (IP-based MPLS)</td>
              <td align="left" colspan="1" rowspan="1">ESI Label filtering</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MPLSoUDP (IP-based MPLS)</td>
              <td align="left" colspan="1" rowspan="1">ESI Label filtering</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MPLS and SR-MPLS</td>
              <td align="left" colspan="1" rowspan="1">ESI Label filtering</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">VXLAN (IP tunnels)</td>
              <td align="left" colspan="1" rowspan="1">Local Bias</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">No</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">NVGRE (IP tunnels)</td>
              <td align="left" colspan="1" rowspan="1">Local Bias</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">No</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">VXLAN-GPE (IP tunnels)</td>
              <td align="left" colspan="1" rowspan="1">Local Bias</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">No</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Geneve (IP tunnels)</td>
              <td align="left" colspan="1" rowspan="1">Local Bias (if no ESI Lb), ESI Label (if ESI lb)</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">SRv6</td>
              <td align="left" colspan="1" rowspan="1">ESI Label filtering</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-1.2-12">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 indent="0" pn="section-1.2-13">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 <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="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. </t>
      </section>
    </section>
    <section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-bgp-evpn-extensions">BGP EVPN Extensions</name>
      <t indent="0" pn="section-2-1">Extensions to EVPN are required to enable NVEs to advertise their
      preferred split-horizon method for a given ES. <xref target="esi-label-extended-community" format="default" sectionFormat="of" derivedContent="Figure 1"/> illustrates the
      ESI Label extended community (<xref target="RFC7432" sectionFormat="of" section="7.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7432#section-7.5" derivedContent="RFC7432"/>), 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>
      <figure anchor="esi-label-extended-community" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-esi-label-extended-communit">ESI Label Extended Community</name>
        <artwork name="" type="" align="left" alt="" pn="section-2-2.1">
                     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 indent="0" pn="section-2-3"><xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> defines the low-order bit
      of the Flags octet (bit 0) as the "Single-Active" bit:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-4">
        <li pn="section-2-4.1">
          <t indent="0" pn="section-2-4.1.1">A value of 0 means that the multihomed ES is operating in
          All-Active multihoming redundancy mode.</t>
        </li>
        <li pn="section-2-4.2">
          <t indent="0" pn="section-2-4.2.1">A value of 1 means that the multihomed ES is operating in
          Single-Active multihoming redundancy mode.</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-5"><xref target="sect-5" format="default" sectionFormat="of" derivedContent="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.</t>
      <section anchor="sect-2.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-the-split-horizon-type">The Split-Horizon Type</name>
        <t indent="0" pn="section-2.1-1"><xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> does not include any
        explicit indication regarding the split-horizon method in the A-D per
        ES route. In this document, the split-horizon procedure defined in
        <xref target="RFC8365" sectionFormat="of" section="8.3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8365#section-8.3.1" derivedContent="RFC8365"/> 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" or "SHT"
        field, where:</t>
        <artwork name="" type="" align="left" alt="" pn="section-2.1-2">

 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|SHT|       |RED|
+-+-+-+-+-+-+-+-+
RED = "Multihoming Redundancy Mode" field (see Table 2)

SHT bit 7 6
-----------
        0 0  --&gt; Default SHT 
                 Backwards compatible with [RFC8365] and [RFC7432]
        0 1  --&gt; Local Bias
        1 0  --&gt; ESI Label-based filtering
        1 1  --&gt; Unassigned
</artwork>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1-3">
          <li pn="section-2.1-3.1">
            <t indent="0" pn="section-2.1-3.1.1">SHT = 00 is backwards compatible with <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>
            and <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, and indicates that the advertising
            NVE intends to use the default or built-in SHT. The default SHT is
            shown in <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/> for each encapsulation. An egress
            NVE that follows the <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> behavior and does
            not support this specification will ignore the SHT bits (which is
            equivalent to processing them as a value of 00).</t>
          </li>
          <li pn="section-2.1-3.2">
            <t indent="0" pn="section-2.1-3.2.1">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 pn="section-2.1-3.3">
            <t indent="0" pn="section-2.1-3.3.1">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.</t>
          </li>
          <li pn="section-2.1-3.4">
            <t indent="0" pn="section-2.1-3.4.1">SHT = 11 is Unassigned.</t>
          </li>
        </ul>
      </section>
      <section anchor="sect-2.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-use-of-the-split-horizon-ty">Use of the Split-Horizon Type in A-D per ES Routes</name>
        <t indent="0" pn="section-2.2-1">The following behavior is observed:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-2">
          <li pn="section-2.2-2.1">
            <t indent="0" pn="section-2.2-2.1.1">An SHT value of 01 or 10 <bcp14>MUST NOT</bcp14> be used with
            encapsulations that support only one SHT in <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/>, and <bcp14>MAY</bcp14> be used by
            encapsulations that support the two SHTs in <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t>
          </li>
          <li pn="section-2.2-2.2">
            <t indent="0" pn="section-2.2-2.2.1">An SHT value different than 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 pn="section-2.2-2.3">
            <t indent="0" pn="section-2.2-2.3.1">In case of an inconsistency in the SHT value advertised by the
            NVEs attached to the same ES for a given EVI, all the NVEs <bcp14>MUST</bcp14>
            revert to the behavior in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> and use the
            default SHT in <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/>, irrespective of the
            advertised SHT.</t>
          </li>
          <li pn="section-2.2-2.4">
            <t indent="0" pn="section-2.2-2.4.1">An SHT different than 00 <bcp14>MUST NOT</bcp14> be set if the "Single-Active"
            bit is set. A received A-D per ES route where the "Single-Active" and
            SHT bits are different than zero <bcp14>MUST</bcp14> follow the treat-as-withdraw
            behavior in <xref target="RFC7606" format="default" sectionFormat="of" derivedContent="RFC7606"/>.</t>
          </li>
          <li pn="section-2.2-2.5">
            <t indent="0" pn="section-2.2-2.5.1">The SHT <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 <xref target="sect-3" format="default" sectionFormat="of" derivedContent="Section 3"/> for NVEs supporting
            multiple encapsulations).</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.2-3">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
        <xref target="RFC9012" format="default" sectionFormat="of" derivedContent="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 the ESI Label,
        respectively.</t>
        <t indent="0" pn="section-2.2-4">An egress NVE <bcp14>MUST NOT</bcp14> use an SHT value other than 00 when
        advertising an A-D per ES route with the following tunnel encapsulation types from <xref target="RFC9012" format="default" sectionFormat="of" derivedContent="RFC9012"/>: 
        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 <bcp14>MUST</bcp14> be set to 00. If a route with
        any of the mentioned encapsulation options is received and has an SHT
        value different than 00, it <bcp14>SHOULD</bcp14> apply the treat-as-withdraw
        behavior, per <xref target="RFC7606" format="default" sectionFormat="of" derivedContent="RFC7606"/>.</t>
        <t indent="0" pn="section-2.2-5">An egress NVE advertising A-D per ES route(s) for an ES with Geneve
        encapsulation (tunnel encapsulation type 19 in  the BGP Tunnel Encapsulation attribute <xref target="RFC9012" format="default" sectionFormat="of" derivedContent="RFC9012"/>) <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 <xref target="I-D.ietf-bess-evpn-geneve" format="default" sectionFormat="of" derivedContent="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 a non-zero Source-ID is present. A value of 00 indicates the
        default behavior outlined in <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/>,
        which is to use local bias if:</t>
        <ol type="a" indent="adaptive" spacing="normal" start="1" pn="section-2.2-6">
	  <li pn="section-2.2-6.1" derivedCounter="a.">no ESI Label is present in the Ethernet option TLV, or </li>
          <li pn="section-2.2-6.2" derivedCounter="b.">there is no Ethernet option TLV.</li>
        </ol>
        <t indent="0" pn="section-2.2-7">Otherwise, the ESI Label split-horizon method is applied.</t>
        <t indent="0" pn="section-2.2-8">These procedures assume a single encapsulation supported in the
        egress NVE. <xref target="sect-3" format="default" sectionFormat="of" derivedContent="Section 3"/> describes additional procedures
        for NVEs supporting multiple encapsulations.</t>
      </section>
      <section anchor="sect-2.3" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-the-esi-label-value-in-a-d-">The ESI Label Value in A-D per ES Routes</name>
        <t indent="0" pn="section-2.3-1">This document also updates <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> regarding the
        value that is advertised in the ESI Label field of the ESI Label
        extended community, as follows:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-2">
          <li pn="section-2.3-2.1">
            <t indent="0" pn="section-2.3-2.1.1">The A-D per ES route(s) for an ES <bcp14>MAY</bcp14> have an ESI Label value
            of zero if the SHT value is 01. <xref target="sect-2.2" format="default" sectionFormat="of" derivedContent="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.</t>
          </li>
          <li pn="section-2.3-2.2">
            <t indent="0" pn="section-2.3-2.2.1">The A-D per ES route(s) for an ES <bcp14>MAY</bcp14> have an ESI Label value
            of zero for VXLAN or NVGRE encapsulations.</t>
          </li>
        </ul>
      </section>
      <section anchor="sect-2.4" numbered="true" toc="include" removeInRFC="false" pn="section-2.4">
        <name slugifiedName="name-backwards-compatibility-wit">Backwards Compatibility with NVEs from RFC 8365</name>
        <t indent="0" pn="section-2.4-1">As discussed in <xref target="sect-2.2" format="default" sectionFormat="of" derivedContent="Section 2.2"/>, this
        specification is backwards compatible with the split-horizon filtering
        behavior in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/> and a
        non-upgraded NVE can be attached to the same ES as other NVEs
        supporting this specification.</t>
        <t indent="0" pn="section-2.4-2">An NVE maintains an administrative SHT value for an 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 indent="0" pn="section-2.4-3">This document assumes that an implementation of <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> or <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="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 <bcp14>MUST</bcp14>
        revert its operational SHT to the default split-horizon method, as
        described in <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/>, irrespective of its
        administrative SHT.</t>
        <t indent="0" pn="section-2.4-4">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 <bcp14>MUST</bcp14> use the default split-horizon method
        specified in <xref target="Tunnel" format="default" sectionFormat="of" derivedContent="Table 1"/> as its operational SHT,
        regardless of its administrative SHT.</t>
        <t indent="0" pn="section-2.4-5">All NVEs attached to an ES with an operational SHT value of 10 <bcp14>MUST</bcp14>
        advertise a valid, non-zero ESI Label. If the operational SHT value is
        01, the ESI Label <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 indent="0" pn="section-2.4-6">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 <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 NVE2 <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" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-procedures-for-nves-support">Procedures for NVEs Supporting Multiple Encapsulations</name>
      <t indent="0" pn="section-3-1">As specified in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="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 <xref target="RFC9012" format="default" sectionFormat="of" derivedContent="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 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 Encapsulation
      Attribute.</t>
      <t indent="0" pn="section-3-2">It is important to note that an NVE <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 (RTs). The total set of RTs
      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 indent="0" pn="section-3-3">As per <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>, an NVE that advertises multiple
      encapsulations in the A-D per ES route(s) for an ES <bcp14>MUST</bcp14> advertise
      encapsulations that use the same split-horizon filtering method in the
      same route. For example:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-4">
        <li pn="section-3-4.1">
          <t indent="0" pn="section-3-4.1.1">An A-D per ES route for ES-x may be advertised with {VXLAN,
          NVGRE} encapsulations.</t>
        </li>
        <li pn="section-3-4.2">
          <t indent="0" pn="section-3-4.2.1">An A-D per ES route for ES-y may be advertised with {MPLS,
          MPLSoUDP, MPLSoGRE} encapsulations (or a subset).</t>
        </li>
        <li pn="section-3-4.3">
          <t indent="0" pn="section-3-4.3.1">However, an A-D per ES route for ES-z <bcp14>MUST NOT</bcp14> be advertised with
          {MPLS, VXLAN} encapsulations.</t>
        </li>
      </ul>
      <t indent="0" pn="section-3-5">This document extends the described behavior as follows:</t>
      <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-3-6"><li pn="section-3-6.1" derivedCounter="a.">
          <t indent="0" pn="section-3-6.1.1">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 SHT value <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 value <bcp14>MUST</bcp14> be 00 and the
          treat-as-withdraw behavior <xref target="RFC7606" format="default" sectionFormat="of" derivedContent="RFC7606"/>
          is applied in case of any other value.</t>
        </li>
        <li pn="section-3-6.2" derivedCounter="b.">
          <t indent="0" pn="section-3-6.2.1">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 <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)
          <bcp14>MAY</bcp14> be advertised in an A-D per ES route with an SHT value of 01.
          The ESI Label value in this case <bcp14>MAY</bcp14> be zero.</t>
        </li>
        <li pn="section-3-6.3" derivedCounter="c.">
          <t indent="0" pn="section-3-6.3.1">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
          method <bcp14>MUST</bcp14> be advertised. For example, consider an ES-z with n RTs, where:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-6.3.2">
            <li pn="section-3-6.3.2.1">
              <t indent="0" pn="section-3-6.3.2.1.1">the EVIs corresponding to (RT1..RTi) support VXLAN,</t>
            </li>
            <li pn="section-3-6.3.2.2">
              <t indent="0" pn="section-3-6.3.2.2.1">the ones for (RTi+1..RTm) (with i&lt;m) support MPLSoUDP with
              local bias, and</t>
            </li>
            <li pn="section-3-6.3.2.3">
              <t indent="0" pn="section-3-6.3.2.3.1">the ones for (RTm+1..RTn) (with m&lt;n) support Geneve
              with ESI Label-based split horizon.</t>
            </li>
          </ul>
          <t indent="0" pn="section-3-6.3.3">In this scenario, three groups of A-D per ES routes <bcp14>MUST</bcp14> be
          advertised for ES-z:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-6.3.4">
            <li pn="section-3-6.3.4.1">
              <t indent="0" pn="section-3-6.3.4.1.1">A-D per ES route group 1, including (RT1..RTi) with
              encapsulation {VXLAN} and an SHT value of 00. The ESI Label <bcp14>MAY</bcp14>
              be zero.</t>
            </li>
            <li pn="section-3-6.3.4.2">
              <t indent="0" pn="section-3-6.3.4.2.1">A-D per ES route group 2, including (RTi+1..RTm) with
              encapsulation {MPLSoUDP} and an SHT value of 01. The ESI Label
              <bcp14>MAY</bcp14> be zero.</t>
            </li>
            <li pn="section-3-6.3.4.3">
              <t indent="0" pn="section-3-6.3.4.3.1">A-D per ES route group 3, including (RTm+1..RTn) with
              encapsulation {Geneve} and an SHT value of 10. The ESI Label
              <bcp14>MUST</bcp14> have a valid, non-zero value, and the Ethernet option as
              defined in <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/> <bcp14>MUST</bcp14> be advertised.</t>
            </li>
          </ul>
        </li>
      </ol>
      <t indent="0" pn="section-3-7">As per <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>, 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>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-4-1">All the security considerations described in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>
      are applicable to this document.</t>
      <t indent="0" pn="section-4-2">Additionally, this document modifies the procedures for split-horizon
      filtering as outlined in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>,
      offering operators a choice between local bias and ESI Label-based
      filtering for tunnels that support both methods. Misconfiguration of the
      desired SHT could lead to forwarding behaviors that differ from the
      intended configuration. Apart from this risk, this document describes
      procedures to ensure that all PE devices or NVEs connected to the same
      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 the ES. Consequently, unauthorized changes to the SHT
      configuration by an attacker on a single PE or NVE of the ES 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" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">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 <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, as follows:</t>
      <table align="center" pn="table-2">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Bit Position</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0-1</td>
            <td align="left" colspan="1" rowspan="1">Multihoming Redundancy Mode</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">2-5</td>
            <td align="left" colspan="1" rowspan="1">Unassigned</td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">6-7</td>
            <td align="left" colspan="1" rowspan="1">Split-Horizon Type</td>
            <td align="left" colspan="1" rowspan="1">RFC 9746</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-5-3">IANA has also created the "Multihoming Redundancy
      Mode" registry for the related field of the "EVPN ESI Label Extended Community Flags". The registry has been populated with the following initial values: 
      </t>
      <table align="center" pn="table-3">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Multihoming Redundancy Mode</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">00</td>
            <td align="left" colspan="1" rowspan="1">All-Active</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">01</td>
            <td align="left" colspan="1" rowspan="1">Single-Active</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">10</td>
            <td align="left" colspan="1" rowspan="1">Unassigned</td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">11</td>
            <td align="left" colspan="1" rowspan="1">Unassigned</td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-5-5">Finally, IANA has created the "Split-Horizon Type" registry for the related field of the
      "EVPN ESI Label Extended Community Flags". The registry has been populated with the following initial values:</t>
      <table align="center" pn="table-4">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Split-Horizon Type Value</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">00</td>
            <td align="left" colspan="1" rowspan="1">Default SHT</td>
            <td align="left" colspan="1" rowspan="1">RFC 9746</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">01</td>
            <td align="left" colspan="1" rowspan="1">Local Bias</td>
            <td align="left" colspan="1" rowspan="1">RFC 9746</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">10</td>
            <td align="left" colspan="1" rowspan="1">ESI Label-based filtering</td>
            <td align="left" colspan="1" rowspan="1">RFC 9746</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">11</td>
            <td align="left" colspan="1" rowspan="1">Unassigned</td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-5-7">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 <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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 pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7432" target="https://www.rfc-editor.org/info/rfc7432" quoteTitle="true" derivedAnchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="February" year="2015"/>
            <abstract>
              <t indent="0">This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8365" target="https://www.rfc-editor.org/info/rfc8365" quoteTitle="true" derivedAnchor="RFC8365">
          <front>
            <title>A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="R. Shekhar" initials="R." surname="Shekhar"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8365"/>
          <seriesInfo name="DOI" value="10.17487/RFC8365"/>
        </reference>
        <reference anchor="RFC9252" target="https://www.rfc-editor.org/info/rfc9252" quoteTitle="true" derivedAnchor="RFC9252">
          <front>
            <title>BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)</title>
            <author fullname="G. Dawra" initials="G." role="editor" surname="Dawra"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9252"/>
          <seriesInfo name="DOI" value="10.17487/RFC9252"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-bess-evpn-geneve" target="https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-08" quoteTitle="true" derivedAnchor="EVPN-GENEVE">
          <front>
            <title>EVPN control plane for Geneve</title>
            <author initials="S." surname="Boutros" fullname="Sami Boutros">
              <organization showOnFrontPage="true">Ciena</organization>
            </author>
            <author initials="A." surname="Sajassi" fullname="Ali Sajassi">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="J." surname="Drake" fullname="John Drake">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <author initials="S." surname="Aldrin" fullname="Sam Aldrin">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <date month="July" day="5" year="2024"/>
            <abstract>
              <t indent="0">   This document describes how Ethernet VPN (EVPN) control plane can be
   used with Network Virtualization Overlay over Layer 3 (NVO3) Generic
   Network Virtualization Encapsulation (Geneve) encapsulation for NVO3
   solutions.

   EVPN control plane can also be used by Network Virtualization Edges
   (NVEs) to express Geneve tunnel option TLV(s) supported in the
   transmission and/or reception of Geneve encapsulated data packets.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-geneve-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC4023" target="https://www.rfc-editor.org/info/rfc4023" quoteTitle="true" derivedAnchor="RFC4023">
          <front>
            <title>Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)</title>
            <author fullname="T. Worster" initials="T." surname="Worster"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4023"/>
          <seriesInfo name="DOI" value="10.17487/RFC4023"/>
        </reference>
        <reference anchor="RFC7348" target="https://www.rfc-editor.org/info/rfc7348" quoteTitle="true" derivedAnchor="RFC7348">
          <front>
            <title>Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
            <author fullname="M. Mahalingam" initials="M." surname="Mahalingam"/>
            <author fullname="D. Dutt" initials="D." surname="Dutt"/>
            <author fullname="K. Duda" initials="K." surname="Duda"/>
            <author fullname="P. Agarwal" initials="P." surname="Agarwal"/>
            <author fullname="L. Kreeger" initials="L." surname="Kreeger"/>
            <author fullname="T. Sridhar" initials="T." surname="Sridhar"/>
            <author fullname="M. Bursell" initials="M." surname="Bursell"/>
            <author fullname="C. Wright" initials="C." surname="Wright"/>
            <date month="August" year="2014"/>
            <abstract>
              <t indent="0">This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7348"/>
          <seriesInfo name="DOI" value="10.17487/RFC7348"/>
        </reference>
        <reference anchor="RFC7510" target="https://www.rfc-editor.org/info/rfc7510" quoteTitle="true" derivedAnchor="RFC7510">
          <front>
            <title>Encapsulating MPLS in UDP</title>
            <author fullname="X. Xu" initials="X." surname="Xu"/>
            <author fullname="N. Sheth" initials="N." surname="Sheth"/>
            <author fullname="L. Yong" initials="L." surname="Yong"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="April" year="2015"/>
            <abstract>
              <t indent="0">This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7510"/>
          <seriesInfo name="DOI" value="10.17487/RFC7510"/>
        </reference>
        <reference anchor="RFC7606" target="https://www.rfc-editor.org/info/rfc7606" quoteTitle="true" derivedAnchor="RFC7606">
          <front>
            <title>Revised Error Handling for BGP UPDATE Messages</title>
            <author fullname="E. Chen" initials="E." role="editor" surname="Chen"/>
            <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"/>
            <author fullname="P. Mohapatra" initials="P." surname="Mohapatra"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <date month="August" year="2015"/>
            <abstract>
              <t indent="0">According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.</t>
              <t indent="0">This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7606"/>
          <seriesInfo name="DOI" value="10.17487/RFC7606"/>
        </reference>
        <reference anchor="RFC7637" target="https://www.rfc-editor.org/info/rfc7637" quoteTitle="true" derivedAnchor="RFC7637">
          <front>
            <title>NVGRE: Network Virtualization Using Generic Routing Encapsulation</title>
            <author fullname="P. Garg" initials="P." role="editor" surname="Garg"/>
            <author fullname="Y. Wang" initials="Y." role="editor" surname="Wang"/>
            <date month="September" year="2015"/>
            <abstract>
              <t indent="0">This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7637"/>
          <seriesInfo name="DOI" value="10.17487/RFC7637"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t indent="0">SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660" quoteTitle="true" derivedAnchor="RFC8660">
          <front>
            <title>Segment Routing with the MPLS Data Plane</title>
            <author fullname="A. Bashandy" initials="A." role="editor" surname="Bashandy"/>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="December" year="2019"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8660"/>
          <seriesInfo name="DOI" value="10.17487/RFC8660"/>
        </reference>
        <reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8754" quoteTitle="true" derivedAnchor="RFC8754">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8754"/>
          <seriesInfo name="DOI" value="10.17487/RFC8754"/>
        </reference>
        <reference anchor="RFC8926" target="https://www.rfc-editor.org/info/rfc8926" quoteTitle="true" derivedAnchor="RFC8926">
          <front>
            <title>Geneve: Generic Network Virtualization Encapsulation</title>
            <author fullname="J. Gross" initials="J." role="editor" surname="Gross"/>
            <author fullname="I. Ganga" initials="I." role="editor" surname="Ganga"/>
            <author fullname="T. Sridhar" initials="T." role="editor" surname="Sridhar"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8926"/>
          <seriesInfo name="DOI" value="10.17487/RFC8926"/>
        </reference>
        <reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986" quoteTitle="true" derivedAnchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t indent="0">The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t indent="0">Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t indent="0">This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC9012" target="https://www.rfc-editor.org/info/rfc9012" quoteTitle="true" derivedAnchor="RFC9012">
          <front>
            <title>The BGP Tunnel Encapsulation Attribute</title>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="G. Van de Velde" initials="G." surname="Van de Velde"/>
            <author fullname="S. Sangli" initials="S." surname="Sangli"/>
            <author fullname="J. Scudder" initials="J." surname="Scudder"/>
            <date month="April" year="2021"/>
            <abstract>
              <t indent="0">This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.</t>
              <t indent="0">This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9012"/>
          <seriesInfo name="DOI" value="10.17487/RFC9012"/>
        </reference>
        <reference anchor="TUNNEL-ENCAP" target="https://www.iana.org/assignments/bgp-tunnel-encapsulation" quoteTitle="true" derivedAnchor="TUNNEL-ENCAP">
          <front>
            <title>Border Gateway Protocol (BGP) Tunnel Encapsulation</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-nvo3-vxlan-gpe" target="https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-13" quoteTitle="true" derivedAnchor="VXLAN-GPE">
          <front>
            <title>Generic Protocol Extension for VXLAN (VXLAN-GPE)</title>
            <author initials="F." surname="Maino" fullname="Fabio Maino">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="L." surname="Kreeger" fullname="Larry Kreeger">
              <organization showOnFrontPage="true">Arrcus</organization>
            </author>
            <author initials="U." surname="Elzur" fullname="Uri Elzur">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <date month="November" day="4" year="2023"/>
            <abstract>
              <t indent="0">   This document describes extending Virtual eXtensible Local Area
   Network (VXLAN), via changes to the VXLAN header, with four new
   capabilities: support for multi-protocol encapsulation, support for
   operations, administration and maintenance (OAM) signaling, support
   for ingress-replicated BUM Traffic (i.e.  Broadcast, Unknown unicast,
   or Multicast), and explicit versioning.  New protocol capabilities
   can be introduced via shim headers.


              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-vxlan-gpe-13"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Anoop Ghanwani"/>,
      <contact fullname="Gyan Mishra"/>, and <contact fullname="Jeffrey       Zhang"/> for their review and useful comments. Thanks to <contact fullname="Gunter Van de Velde"/> and <contact fullname="Sue Hares"/> as
      well, for their thorough review.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabadan">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <street>520 Almanor Avenue</street>
            <city>Sunnyvale</city>
            <region>CA</region>
            <code>94085</code>
            <country>United States of America</country>
          </postal>
          <email>jorge.rabadan@nokia.com</email>
        </address>
      </author>
      <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <street>520 Almanor Avenue</street>
            <city>Sunnyvale</city>
            <region>CA</region>
            <code>94085</code>
            <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" showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <email>wlin@juniper.net</email>
        </address>
      </author>
      <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
        <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <email>sajassi@cisco.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
