<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-bess-bgp-srv6-args-10" number="9819" consensus="true" ipr="trust200902" updates="9252" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2025-07-19T10:02:30" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9819" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SRv6 Argument Signaling for BGP Services">Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)</title>
    <seriesInfo name="RFC" value="9819" stream="IETF"/>
    <author fullname="Ketan Talaulikar" initials="K" surname="Talaulikar">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Kamran Raza" initials="K" surname="Raza">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <country>Canada</country>
        </postal>
        <email>skraza@cisco.com</email>
      </address>
    </author>
    <author fullname="Jorge Rabadan" initials="J" surname="Rabadan">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="Wen Lin" initials="W" surname="Lin">
      <organization showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>wlin@juniper.net</email>
      </address>
    </author>
    <date month="07" year="2025"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>
    <keyword>BGP</keyword>
    <keyword>SRv6</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">RFC 9252 defines procedures and messages for BGP overlay services for
      Segment Routing over IPv6 (SRv6), including Layer 3 Virtual Private
      Network (L3VPN), Ethernet VPN (EVPN), and global Internet routing.
      This document updates RFC 9252 and provides more detailed specifications
      for the signaling and processing of SRv6 Segment Identifier
      advertisements for BGP overlay service routes associated with SRv6
      Endpoint Behaviors that support arguments.</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/rfc9819" 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-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" 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-advertisement-of-srv6-sid-a">Advertisement of SRv6 SID and Arguments</xref></t>
          </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-enddt2m-signaling-for-evpn-">End.DT2M Signaling for EVPN ESI Filtering</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advertisement-of-ethernet-a">Advertisement of Ethernet A-D per ES Route</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advertisement-of-inclusive-">Advertisement of Inclusive Multicast Ethernet Tag Route</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-processing-at-ingress-pe">Processing at Ingress PE</xref></t>
              </li>
            </ul>
          </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-backward-compatibility">Backward Compatibility</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-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <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.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </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.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.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="INTRO" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">SRv6 refers to Segment Routing instantiated over the IPv6 data plane
      <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>. An SRv6 Segment Identifier (SID) <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> can be associated with one of the service-specific
      SRv6 Endpoint Behaviors on the advertising Provider Edge (PE) router for
      Layer 3 Virtual Private Network (L3VPN), global Internet routing, and
      Ethernet VPN (EVPN) services as defined in <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>. Such SRv6 SIDs are referred to as SRv6 Service SIDs.
      <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/> defines the procedures and messages for the
      signaling of BGP overlay services including L3VPN, EVPN, and Internet
      services using SRv6.</t>
      <t indent="0" pn="section-1-2">For certain EVPN services, <xref target="RFC8986" section="4.12" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8986#section-4.12" derivedContent="RFC8986"/>
      introduced the End.DT2M SRv6 Endpoint Behavior, which utilizes arguments
      (i.e., Arg.FE2). <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/> subsequently specified the
      encoding and signaling procedures for the SRv6 SID and its associated
      argument via the Inclusive Multicast Ethernet Tag route (EVPN Route Type 3) and the Ethernet A-D (Auto-Discovery) per ES route (EVPN Route Type 1), respectively.
      However, during implementation and interoperability testing, it was
      observed that the specifications outlined in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>
      lack sufficient detail, leading to ambiguities in interpretation and
      implementation.</t>
      <t indent="0" pn="section-1-3">This document updates <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/> by providing
      additional details and clarifications regarding the signaling of SRv6
      Service SIDs associated with SRv6 Endpoint Behaviors that utilize
      arguments. While the focus is primarily on the signaling of the End.DT2M
      SRv6 Endpoint Behavior via the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route, the procedures
      described herein are also applicable to other similar SRv6 Endpoint Behaviors
      with arguments that may be signaled using BGP.</t>
      <t indent="0" pn="section-1-4"><xref target="RFC9252" section="6.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9252#section-6.3" derivedContent="RFC9252"/> specifies that the SRv6
      Service SID used in the data plane is derived by applying a bitwise
      logical-OR operation between the SID with an argument signaled via the Ethernet A-D per ES route
      and the SID with the 'Locator + Function' components signaled via the
      Inclusive Multicast Ethernet Tag route. However, this approach assumes a uniform SID structure
      across all SIDs advertised via the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route. This assumption
      is not universally valid, and the procedures in this document remove
      this restriction, ensuring greater flexibility in SRv6 SID
      signaling.</t>
      <t indent="0" pn="section-1-5">The descriptions and examples presented in this document do not
      utilize the Transposition Scheme (see <xref target="RFC9252" section="4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9252#section-4" derivedContent="RFC9252"/>). Consequently, the Transposition Offset (TPOS-O) and
      Transposition Length (TPOS-L) are set to zero, and references to MPLS
      label fields where the function or argument portions may be transposed
      are omitted. However, the same examples could be applied with the
      Transposition Scheme. This document does not introduce any modifications
      to the use of the Transposition Scheme in the signaling of EVPN routes.
      Implementations are expected to adhere to the procedures and
      recommendations specified in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/> concerning the
      Transposition Scheme.</t>
      <section anchor="REQ" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</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>
      </section>
    </section>
    <section anchor="SIDANDARGS" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-advertisement-of-srv6-sid-a">Advertisement of SRv6 SID and Arguments</name>
      <t indent="0" pn="section-2-1"><xref target="RFC8986" section="3.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8986#section-3.1" derivedContent="RFC8986"/> defines the format of an SRv6
      SID as consisting of three components: Locator (LOC), Function (FUNC),
      and Argument (ARG). For SRv6 SIDs associated with SRv6 Endpoint
      Behaviors that do not support arguments, the ARG component is not
      present. Consequently, all bits following the FUNC portion <bcp14>MUST</bcp14> be set
      to zero, and the Argument Length (AL) <bcp14>MUST</bcp14> be zero.</t>
      <t indent="0" pn="section-2-2">Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) support arguments.
      As specified in <xref target="RFC9252" section="3.2.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9252#section-3.2.1" derivedContent="RFC9252"/>, the SRv6 SID
      Structure Sub-Sub-TLV <bcp14>MUST</bcp14> be included when signaling an SRv6 SID
      corresponding to an SRv6 Endpoint Behavior that supports argument. This
      ensures that the receiving router can perform consistency verification
      of the argument and correctly encode the ARG value within the SRv6
      SID.</t>
      <t indent="0" pn="section-2-3">In certain use cases, the SRv6 SID can be signaled as a complete
      structure, with the LOC:FUNC:ARG components fully encoded within the
      SID. However, there are scenarios where the SRv6 SID, consisting only of
      the LOC:FUNC portion, is signaled in one advertisement, while the ARG
      value is either signaled through a separate advertisement or learned via
      an alternative mechanism. It is the responsibility of the SRv6 source
      node to append the ARG component to the LOC:FUNC portion, thereby
      constructing the complete SRv6 SID (LOC:FUNC:ARG). This fully formed SID
      can then be utilized in the data plane, either as the IPv6 destination
      address of a packet or as a segment within the Segment Routing Header
      (SRH) <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>, as required.</t>
      <t indent="0" pn="section-2-4">Since arguments may be optional, the SRv6 endpoint node that owns the
      SID <bcp14>MUST</bcp14> advertise the SRv6 SID Structure Sub-Sub-TLV along with the
      LOC:FUNC portion of the SRv6 SID to indicate whether arguments are
      supported for that specific SID. A zero AL value
      indicates that the node does not accept an argument for the given SRv6
      SID. Conversely, a non-zero AL value specifies the size of the supported
      argument, along with the Locator Block Length (LBL), Locator Node Length
      (LNL), and Function Length (FL) parameters, which define the offset from
      which the node expects the ARG to be encoded. All bits beyond LBL + LNL
      + FL + AL <bcp14>MUST</bcp14> be set to zero.</t>
      <t indent="0" pn="section-2-5">The advertisement of the ARG value may be performed either by the
      node that owns the SRv6 SID and is advertising the LOC:FUNC portion of
      that SID or by another node/mechanism. The advertisement of the ARG
      value <bcp14>MUST</bcp14> specify the size of the argument, its value, and the
      associated SRv6 Endpoint Behavior of the SID. Additionally, the
      specification of the association of the ARG advertisement with the
      corresponding SID(s) for which the argument applies is <bcp14>REQUIRED</bcp14>.</t>
    </section>
    <section anchor="EVPNESI" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-enddt2m-signaling-for-evpn-">End.DT2M Signaling for EVPN ESI Filtering</name>
      <t indent="0" pn="section-3-1">As specified in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>, the
      LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via the
      Inclusive Multicast Ethernet Tag route, while the Ethernet Segment
      Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>) 
      is signaled via the Ethernet A-D per ES route. The
      following subsections provide a more detailed specification of the
      signaling and processing mechanisms compared to <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>.</t>
      <t indent="0" pn="section-3-2">ESI Filtering is a split-horizon mechanism used for multihoming
      <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> or Ethernet-Tree (E-Tree) procedures <xref target="RFC8317" format="default" sectionFormat="of" derivedContent="RFC8317"/>. ESI Filtering is not applicable in scenarios
      where:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-3">
        <li pn="section-3-3.1">
          <t indent="0" pn="section-3-3.1.1">No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM)
          traffic exists,</t>
        </li>
        <li pn="section-3-3.2">
          <t indent="0" pn="section-3-3.2.1">No multihoming is present,</t>
        </li>
        <li pn="section-3-3.3">
          <t indent="0" pn="section-3-3.3.1">No split-horizon mechanism is required, or</t>
        </li>
        <li pn="section-3-3.4">
          <t indent="0" pn="section-3-3.4.1">The "Local Bias" method (as specified in <xref target="RFC8365" format="default" sectionFormat="of" derivedContent="RFC8365"/>)
          is employed.</t>
        </li>
      </ul>
      <t indent="0" pn="section-3-4">In this document, "ESI Filtering" is used as a general reference to
      the procedure performed by the disposition Provider Edge (PE) router to
      prevent forwarding of BUM traffic to local Ethernet Segments or local
      leaf attachment circuits, based on the presence of the ESI Filtering
      ARG.</t>
      <t indent="0" pn="section-3-5">The signaling and processing descriptions outlined in the following
      sections also apply to End.DT2M behavior flavors designed for SRv6 SID
      list compression <xref target="RFC9800" format="default" sectionFormat="of" derivedContent="RFC9800"/>.  In
      deployments where a mix of compressed and uncompressed SIDs is present,
      the behaviors advertised in the Ethernet A-D per ES routes and Inclusive
      Multicast Ethernet Tag routes <bcp14>MAY</bcp14> consist of a
      combination of compressed and uncompressed End.DT2M behavior flavors.
      The procedures in this document remain valid for such deployments
      provided that the AL consistency checks between the Ethernet A-D per ES route and
      Inclusive Multicast Ethernet Tag route, as described in the following subsections, are
      satisfied.</t>
      <section anchor="RT1" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-advertisement-of-ethernet-a">Advertisement of Ethernet A-D per ES Route</name>
        <t indent="0" pn="section-3.1-1">Ethernet A-D per ES routes, as 
        defined in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, are utilized to enable
        split-horizon filtering and fast convergence in multihoming
        scenarios. Additionally, Ethernet A-D per ES routes facilitate egress filtering
        of BUM traffic originating from a leaf, as specified in <xref target="RFC8317" format="default" sectionFormat="of" derivedContent="RFC8317"/>.</t>
        <t indent="0" pn="section-3.1-2">When ESI Filtering is not in use, no ESI Filtering ARG is required
        to be conveyed. However, for backward compatibility and consistency
        with <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>, the advertisement of this route <bcp14>SHOULD</bcp14>
        include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV
        carrying an SRv6 Service SID set to ::0 in the SRv6 SID Information
        Sub-TLV, with the SRv6 Endpoint Behavior set to End.DT2M. Since the
        End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure
        Sub-Sub-TLV <bcp14>MUST</bcp14> be included. As no ARG value is required to be
        signaled in this case, the AL <bcp14>MUST</bcp14> be set to 0.</t>
        <t indent="0" pn="section-3.1-3">The following is an example representation of the BGP Prefix-SID
        attribute encoding in this case:</t>
        <figure anchor="RT1NOARG" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-ethernet-a-d-per-es-route-w">Ethernet A-D per ES Route Without ARG for ESI Filtering</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.1-4.1">
BGP Prefix-SID attribute:
    SRv6 L2 Service TLV:
        SRv6 SID Information Sub-TLV:
            SID: ::
            Behavior: End.DT2M
            SRv6 SID Structure Sub-Sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
</artwork>
        </figure>
        <t indent="0" pn="section-3.1-5">When ESI Filtering is in use, the advertisement of this route <bcp14>MUST</bcp14>
        include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV
        carrying the SRv6 Service SID that contains the ESI Filtering ARG
        value within the SRv6 SID Information Sub-TLV (when not using the
        Transposition Scheme), with the SRv6 Endpoint Behavior set to
        End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an
        SRv6 SID Structure Sub-Sub-TLV <bcp14>MUST</bcp14> be included. Additionally, as a
        non-zero ARG value is being signaled, the AL <bcp14>MUST</bcp14> be
        set to the size of the ARG, and the size <bcp14>SHOULD</bcp14> be a multiple of 8 to
        ensure consistency across implementations for ease of operations. The
        SRv6 SID Structure Sub-Sub-TLV <bcp14>MUST</bcp14> set the 
        LBL, LNL, and FL fields with
        values that indicate the offset at which the ARG value is encoded
        within the 128-bit SRv6 SID.</t>
        <t indent="0" pn="section-3.1-6">The following is an example representation of the BGP Prefix-SID
        attribute encoding in this scenario for a 16-bit argument value of
        'aaaa':</t>
        <figure anchor="RT1ARG" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-ethernet-a-d-per-es-route-wi">Ethernet A-D per ES Route with ARG for ESI Filtering</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.1-7.1">
BGP Prefix-SID attribute:
    SRv6 L2 Service TLV:
        SRv6 SID Information Sub-TLV:
            SID: ::aaaa:0:0:0
            Behavior: End.DT2M
            SRv6 SID Structure Sub-Sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
</artwork>
        </figure>
        <t indent="0" pn="section-3.1-8">In the examples above, it would have been possible to set the LBL,
        LNL, and FL values to 0 and to encode the SRv6 SID as either ::0 or
        aaaa::. However, such an encoding would not be backward compatible
        with <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>, as further detailed in <xref target="BACKWARD" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
        <t indent="0" pn="section-3.1-9">Therefore, it is <bcp14>REQUIRED</bcp14> that the LBL, LNL, and FL values be set
        in accordance with the SID structure for End.DT2M SRv6 Service SIDs,
        ensuring compliance with <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>.</t>
      </section>
      <section anchor="RT3" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-advertisement-of-inclusive-">Advertisement of Inclusive Multicast Ethernet Tag Route</name>
        <t indent="0" pn="section-3.2-1">The Inclusive Multicast Ethernet Tag route, as
        defined in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, is used to advertise multicast
        traffic reachability information via Multiprotocol BGP (MP-BGP) to all other PE routers
        within a given EVPN instance. When utilizing SRv6 transport, the
        advertisement of this route <bcp14>MUST</bcp14> include the BGP Prefix-SID attribute
        with an SRv6 L2 Service TLV to indicate the use of SRv6.</t>
        <t indent="0" pn="section-3.2-2">Regardless of whether ESI Filtering is in use, the SRv6 Service SID
        <bcp14>MUST</bcp14> include only the LOC:FUNC portion within the SRv6 SID Information
        Sub-TLV (when not utilizing the Transposition Scheme), with the SRv6
        Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior
        supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLV <bcp14>MUST</bcp14> be
        included. The LBL, LNL, and FL fields <bcp14>MUST</bcp14> be set to indicate the
        structure of the SRv6 Service SID being advertised.</t>
        <t indent="0" pn="section-3.2-3">When ESI Filtering is not in use, no ARG is expected to be received
        by the router along with the advertised SRv6 Service SID. Therefore,
        the AL <bcp14>MUST</bcp14> be set to 0.</t>
        <t indent="0" pn="section-3.2-4">The following is an example representation of the BGP Prefix-SID
        attribute encoding in this case:</t>
        <figure anchor="RT3NOARG" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-inclusive-multicast-etherne">Inclusive Multicast Ethernet Tag Route Without ESI Filtering</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.2-5.1">
BGP Prefix-SID attribute:
    SRv6 L2 Service TLV:
        SRv6 SID Information Sub-TLV:
            SID: 2001:db8:1:fbd1::
            Behavior: End.DT2M
            SRv6 SID Structure Sub-Sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
</artwork>
        </figure>
        <t indent="0" pn="section-3.2-6">When ESI Filtering is in use, the router expects to receive traffic
        in the data path to the SRv6 Service SID that it has signaled along
        with the ARG portion embedded in it. Consequently, the AL <bcp14>MUST</bcp14> be set
        to the size of the ARG supported by the advertising router for the
        specific SRv6 Service SID. The AL value is unique per End.DT2M
        behavior signaled by the egress PE. Therefore, the egress PE <bcp14>MUST</bcp14> use
        the same AL for all local Ethernet Segments with attachment circuits
        within the same broadcast domain.</t>
        <t indent="0" pn="section-3.2-7">The following is an example representation of the BGP Prefix-SID
        attribute encoding for this scenario with a 16-bit argument:</t>
        <figure anchor="RT3ARG" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-inclusive-multicast-ethernet">Inclusive Multicast Ethernet Tag Route with ESI Filtering</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.2-8.1">
BGP Prefix-SID attribute:
    SRv6 L2 Service TLV:
        SRv6 SID Information Sub-TLV:
            SID: 2001:db8:1:fbd1::
            Behavior: End.DT2M
            SRv6 SID Structure Sub-Sub-TLV:
                LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
</artwork>
        </figure>
        <t indent="0" pn="section-3.2-9">When ESI Filtering is in use, the advertising router <bcp14>MUST</bcp14> ensure
        that the AL signaled in the Inclusive Multicast Ethernet Tag route is equal to the AL
        signaled in the corresponding Ethernet A-D per ES route.</t>
      </section>
      <section anchor="PROC" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-processing-at-ingress-pe">Processing at Ingress PE</name>
        <t indent="0" pn="section-3.3-1">An ingress PE receives the LOC:FUNC portion of the SRv6 Service SID
        to be used for BUM traffic through Inclusive Multicast Ethernet Tag route
        advertisements.</t>
        <t indent="0" pn="section-3.3-2">When ESI Filtering is not in use, the SRv6 Service SID to be used
        consists solely of the LOC:FUNC portion received via the Inclusive Multicast Ethernet Tag route.
        </t>
        <t indent="0" pn="section-3.3-3">When ESI Filtering is in use, the ESI Filtering ARG of the SRv6
        Service SID is signaled through the Ethernet A-D per ES route. 
        The ARG, in combination
        with the LOC:FUNC portion received via the Inclusive Multicast Ethernet Tag route, forms the
        SRv6 Service SID to be used.</t>
        <t indent="0" pn="section-3.3-4">Since the LOC:FUNC and ARG portions of the SRv6 Service SID are
        signaled via different route advertisements, there may be cases where
        the ingress PE receives inconsistent AL values from the two route
        types. If the ingress PE expects ESI Filtering to be in use (i.e.,
        when forwarding BUM traffic to other PEs attached to a shared Ethernet
        Segment) but does not receive a usable ARG value during processing, it
        <bcp14>SHOULD</bcp14> log a message to facilitate troubleshooting.</t>
        <t indent="0" pn="section-3.3-5">The ingress PE router <bcp14>MUST</bcp14> follow the processing steps outlined
        below when handling SRv6 Service SID advertisements:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.3-6"><li pn="section-3.3-6.1" derivedCounter="1.">
            <t indent="0" pn="section-3.3-6.1.1">If AL=0 is signaled via the Inclusive Multicast Ethernet Tag route, then the egress PE
            either does not support ESI Filtering or does not require an ESI
            Filtering ARG for the specific SID. In this case, the SRv6 Service
            SID is formed using only the LOC:FUNC portion, and all bits after
            LBL + LNL + FL <bcp14>MUST</bcp14> be set to zero for encoding on the data path.
            Additionally, the router <bcp14>MUST</bcp14> ignore the SID value and its SID
            structure advertised in the corresponding Ethernet A-D per ES route.</t>
          </li>
          <li pn="section-3.3-6.2" derivedCounter="2.">
            <t indent="0" pn="section-3.3-6.2.1">If a non-zero AL is signaled via the Inclusive Multicast Ethernet Tag route, then the
            matching Ethernet A-D per ES route for the Ethernet Segment is located and
            the presence of an SRv6 SID advertisement with the End.DT2M
            behavior is verified.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-3.3-6.2.2"><li pn="section-3.3-6.2.2.1" derivedCounter="a.">
                <t indent="0" pn="section-3.3-6.2.2.1.1">If the presence of such a SRv6 SID is not verified, or if
                the AL is zero in the Ethernet A-D per ES route, then no usable ARG value is
                available. The SRv6 Service SID <bcp14>MUST</bcp14> be formed as described in
                (1) above.</t>
              </li>
              <li pn="section-3.3-6.2.2.2" derivedCounter="b.">
                <t indent="0" pn="section-3.3-6.2.2.2.1">If the AL values in the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route
                are both non-zero but not equal, then no usable ARG value is
                available. This inconsistency in signaling from the egress PE
                indicates a configuration error. To prevent potential looping,
                BUM traffic <bcp14>MUST NOT</bcp14> be forwarded for such routes from the
                specific Ethernet Segment. Implementations <bcp14>SHOULD</bcp14> log an error
                message for troubleshooting this condition.</t>
              </li>
              <li pn="section-3.3-6.2.2.3" derivedCounter="c.">
                <t indent="0" pn="section-3.3-6.2.2.3.1">If the AL values in the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route
                are both non-zero and equal, then the ARG value from the
                Ethernet A-D per ES route is considered valid. This ARG value <bcp14>MUST</bcp14> be
                encoded within the SRv6 SID (LOC:FUNC) at the ARG offset as
                specified in the SID structure (i.e., LBL + LNL + FL) in the
                Inclusive Multicast Ethernet Tag route. All bits beyond LBL + LNL + FL + AL <bcp14>MUST</bcp14> be set
                to zero.</t>
              </li>
            </ol>
          </li>
        </ol>
        <t indent="0" pn="section-3.3-7">Using the procedures above with the examples in Figures
        <xref target="RT1NOARG" format="counter" sectionFormat="of" derivedContent="1"/> and <xref target="RT3NOARG" format="counter" sectionFormat="of" derivedContent="3"/>, the
   SRv6 Service SID encoding for the
   data plane without an ESI Filtering ARG
   is as follows:
        </t>
        <figure anchor="SIDPACKET" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-srv6-service-sid-encoding-f">SRv6 Service SID Encoding for Data Plane Without ARG</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.3-8.1">
Inclusive Multicast Ethernet Tag route:
 SID: 2001:db8:1:fbd1::
 Structure: LBL: 32, LNL: 16, FL: 16, AL: 0

SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1::
</artwork>
        </figure>
        <t indent="0" pn="section-3.3-9">Using the procedures above with the examples in 
        Figures <xref target="RT1ARG" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="RT3ARG" format="counter" sectionFormat="of" derivedContent="4"/>, the
   SRv6 Service SID encoding for the
   data plane along with an ESI Filtering ARG
   is as follows:
        </t>
        <figure anchor="SIDPACKETARG" align="left" suppress-title="false" pn="figure-6">
          <name slugifiedName="name-srv6-service-sid-encoding-fo">SRv6 Service SID Encoding for Data Plane with ARG</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.3-10.1">
Ethernet A-D per ES route:
 SID: ::aaaa:0:0:0
 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

Inclusive Multicast Ethernet Tag route:
 SID: 2001:db8:1:fbd1::
 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:aaaa::
</artwork>
        </figure>
        <t indent="0" pn="section-3.3-11"><xref target="MULTIBD" format="default" sectionFormat="of" derivedContent="Figure 7"/> provides another example that illustrates
        the signaling and processing of multiple bridge domains in a
        deployment design.</t>
        <figure anchor="MULTIBD" align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-example-with-multiple-bridg">Example with Multiple Bridge Domains</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.3-12.1">
                     +--------------------------------+
                     |                                |
                 PE1 |                                |
                 +---------+                          |
  BUM on BD1     | +-----+ |                          |
+----------------&gt; | BD1 |-------------+              |
|                | +-----+ |           |              |
|  BUM on BD2    | +-----+ |           v          PE3 |
| +--------------&gt; | BD2 |-------+             +---------+
| |        +-----| +-----+ |     |             | +-----+ |
+----+     |     +---------+     v     ^       | | BD1 |-----CE31
|    |     |         |                 |       | +-----+ |
|CE12|-----+ ESI-1   |           ^     |       | +-----+ |
|    |-----+         |           |     |       | | BD2 |-----CE32
+----+     |     +---------+ ^   RT3   RT3     | +-----+ |
           +-----| +-----+ | |   dt2m  dt2m    +---------+
                 | | BD1 | | |   BD2   BD1            |
                 | +-----+ | |   FL:16 FL:32          |
                 | +-----+ | RT1                      |
                 | | BD2 | | ESI-1                    |
                 | +-----+ | AL:16                    |
                 +---------+                          |
                  PE2 |                               |
                      |                               |
                      |                               |
                      +-------------------------------+
 
 Ethernet A-D per ES route for ESI-1:
  SID: ::aaaa:0:0:0
  Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
 
 Inclusive Multicast Ethernet Tag route from BD1:
  SID: 2001:db8:1:fbd1:fbd1:
  Structure: LBL: 32, LNL: 16, FL: 32, AL: 16
 
 Inclusive Multicast Ethernet Tag route from BD2:
  SID: 2001:db8:1:fbd2::
  Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
 
 SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD1:
  2001:db8:1:fbd1:fbd1:aaaa::
 SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD2:
  2001:db8:1:fbd2:aaaa::
</artwork>
        </figure>
      </section>
    </section>
    <section anchor="BACKWARD" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-backward-compatibility">Backward Compatibility</name>
      <t indent="0" pn="section-4-1">Existing implementations that rely on the bitwise logical-OR
      operation, as specified in <xref target="RFC9252" section="6.3" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9252#section-6.3" derivedContent="RFC9252"/>,
      function correctly only when the SID structures of the two EVPN route
      types are identical.</t>
      <t indent="0" pn="section-4-2">Backward compatibility with implementations performing the bitwise
      logical-OR operation is maintained when the Inclusive Multicast Ethernet Tag route and its
      corresponding Ethernet A-D per ES route advertise SIDs with the same SID
      structure, as outlined in Sections <xref target="RT1" format="counter" sectionFormat="of" derivedContent="3.1"/> and <xref target="RT3" format="counter" sectionFormat="of" derivedContent="3.2"/>.</t>
      <t indent="0" pn="section-4-3">However, when the SID structures of the two route types are not
      identical, the bitwise logical-OR operation specified in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/> cannot be applied. Instead, the alternative method
      specified in <xref target="PROC" format="default" sectionFormat="of" derivedContent="Section 3.3"/> <bcp14>MUST</bcp14> be used to correctly derive the
      SRv6 Service SID in such cases.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">This document has no IANA actions.</t>
    </section>
    <section anchor="SEC" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">This document provides a more detailed specification related to
      the signaling and processing of SRv6 SID advertisements for SRv6
      Endpoint Behaviors with arguments. As such, it does not introduce any
      new security considerations over and above those already covered by
      <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="RFC9252"/>.</t>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.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="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="RFC8317" target="https://www.rfc-editor.org/info/rfc8317" quoteTitle="true" derivedAnchor="RFC8317">
          <front>
            <title>Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="S. Salam" initials="S." surname="Salam"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="S. Boutros" initials="S." surname="Boutros"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="January" year="2018"/>
            <abstract>
              <t indent="0">The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8317"/>
          <seriesInfo name="DOI" value="10.17487/RFC8317"/>
        </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="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="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-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <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="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="RFC9800" target="https://www.rfc-editor.org/info/rfc9800" quoteTitle="true" derivedAnchor="RFC9800">
          <front>
            <title>Compressed SRv6 Segment List Encoding</title>
            <author fullname="W. Cheng" initials="W." role="editor" surname="Cheng"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="F. Clad" initials="F." role="editor" surname="Clad"/>
            <date month="June" year="2025"/>
            <abstract>
              <t indent="0">Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists.</t>
              <t indent="0">This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9800"/>
          <seriesInfo name="DOI" value="10.17487/RFC9800"/>
        </reference>
      </references>
    </references>
    <section anchor="ACK" 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 acknowledge <contact fullname="Jayshree       Subramanian"/>, <contact fullname="Sonal Agarwal"/>, <contact fullname="Swadesh Agrawal"/>, <contact fullname="Dongling Duan"/>,
      <contact fullname="Luc André Burdet"/>, <contact fullname="Patrice       Brissette"/>, <contact fullname="Senthil Sathappan"/>, <contact fullname="Erel Ortacdag"/>, <contact fullname="Neil Hart"/>, <contact fullname="Will Lockhart"/>, and <contact fullname="Vinod Prabhu"/> for their review of the document and
      input on aspects related to the signaling of the End.DT2M SRv6
      Endpoint Behavior that required clarification. The authors thank <contact fullname="Jeffrey Zhang"/>
      for his shepherd review and suggestions for 
      improving the document. The authors would also like to thank <contact fullname="Gunter Van de Velde"/> for his extensive review and
      suggestions for improving the readability of the document.</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="Ketan Talaulikar" initials="K" surname="Talaulikar">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <country>India</country>
          </postal>
          <email>ketant.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Kamran Raza" initials="K" surname="Raza">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <country>Canada</country>
          </postal>
          <email>skraza@cisco.com</email>
        </address>
      </author>
      <author fullname="Jorge Rabadan" initials="J" surname="Rabadan">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>jorge.rabadan@nokia.com</email>
        </address>
      </author>
      <author fullname="Wen Lin" initials="W" surname="Lin">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>wlin@juniper.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
