<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-bgp-srv6-args-10" number="9819" consensus="true" ipr="trust200902" updates="9252">
  <?xml-stylesheet 3type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes" ?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <?rfc compact="yes" ?>

  <?rfc subcompact="no" ?> updates="9252" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

<!-- [rfced] May we update the document title as follows to improve readability?

Original:
  Segment Routing over IPv6 Argument Signaling for BGP Services

Perhaps:
  Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)
-->

  <front>
    <title abbrev="SRv6 Argument Signaling for BGP Services">Segment Routing
    over IPv6 Argument Signaling for BGP Services</title>
    <seriesInfo name="RFC" value="9819"/>
    <author fullname="Ketan Talaulikar" initials="K" surname="Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Kamran Raza" initials="K" surname="Raza">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <country>Canada</country>
        </postal>
        <email>skraza@cisco.com</email>
      </address>
    </author>
    <author fullname="Jorge Rabadan" initials="J" surname="Rabadan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="Wen Lin" initials="W" surname="Lin">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>wlin@juniper.net</email>
      </address>
    </author>
    <date year=""/>

    <area>Routing</area>

    <workgroup>BESS Working Group</workgroup> year="2025" month="July"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>

    <keyword>BGP</keyword>
    <keyword>SRv6</keyword>

    <abstract>
      <t>RFC9252
      <t>RFC 9252 defines procedures and messages for BGP Overlay Services for
      Segment Routing over IPv6 (SRv6) (SRv6), including Layer 3 Virtual Private
      Network,
      Network (L3VPN), Ethernet Virtual Private Network, VPN (EVPN), and Global global Internet Routing. routing.
      This document updates RFC9252 RFC 9252 and provides more detailed specifications
      for the signaling and processing of SRv6 Segment Identifiers Identifier
      advertisements for BGP Overlay Service routes associated with SRv6
      Endpoint Behaviors that support arguments.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>SRv6 refers to Segment Routing instantiated over the IPv6 data plane
      <xref target="RFC8402"/>. target="RFC8402" format="default"/>. An SRv6 Segment Identifier (SID) <xref
      target="RFC8402"/> target="RFC8402" format="default"/> can be associated with one of the service specific service-specific
      SRv6 Endpoint behaviors Behaviors on the advertising Provider Edge (PE) router for
      Layer-3
      Layer 3 Virtual Private Network (L3VPN), Global global Internet Routing, routing, and
      Ethernet Virtual Private Network VPN (EVPN) services as defined in <xref
      target="RFC8986"/>. target="RFC8986" format="default"/>. Such SRv6 SIDs are referred to as SRv6 Service SIDs.
      <xref target="RFC9252"/> target="RFC9252" format="default"/> defines the procedures and messages for the
      signaling of BGP Overlay Services including L3VPN, EVPN, and Internet
      services using SRv6.</t>
      <t>For certain EVPN services, <xref target="RFC8986"/> (section 4.12) target="RFC8986" section="4.12"/>
      introduced the End.DT2M SRv6 Endpoint Behavior, which utilizes arguments
      (i.e., Arg.FE2). <xref target="RFC9252"/> target="RFC9252" format="default"/> subsequently specified the
      encoding and signaling procedures for the SRv6 SID and its associated
      argument via EVPN Route Type 3 and EVPN Route Type 1, respectively.
      However, during implementation and interoperability testing, it was
      observed that the specifications outlined in <xref target="RFC9252"/>
      lacked target="RFC9252" format="default"/>
      lack sufficient detail, leading to ambiguities in interpretation and
      implementation.</t>
      <t>This document updates <xref target="RFC9252"/> target="RFC9252" format="default"/> 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 EVPN Route Types 1 and 3, the procedures
      described herein are also applicable to other similar endpoint behaviors
      with arguments that may be signaled using BGP.</t>

      <t>Section

<!-- [rfced] We updated "with argument" here to "with an argument". Let us
know if it should be "with arguments" instead.

Original:
   Section 6.3 of <xref target="RFC9252"/> [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 argument signaled via Route Type 1 and the SID
   with the 'locator + function' components signaled via Route Type 3.

Updated:
   Section 6.3 of [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 Route Type 1 and the SID
   with the 'Locator + Function' components signaled via Route Type 3.
-->

      <t><xref target="RFC9252" section="6.3"/> 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 Route
      Type 1 and the SID with the 'Locator + Function' components signaled via
      Route Type 3. However, this approach assumes a uniform SID structure
      across all SIDs advertised via EVPN Route Types 1 and 3. This assumption
      is not universally valid, and the procedures in this document remove
      this restriction, ensuring greater flexibility in SRv6 SID
      signaling.</t>
      <t>The descriptions and examples presented in this document do not
      utilize the Transposition Scheme (see section 4 of <xref
      target="RFC9252"/>). target="RFC9252" section="4"/>). 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. routes.
      Implementations are expected to adhere to the procedures and
      recommendations specified in <xref target="RFC9252"/> target="RFC9252" format="default"/> concerning the
      Transposition Scheme.</t>
      <section anchor="REQ" title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
    </section>
    <section anchor="SIDANDARGS"
             title="Advertisement numbered="true" toc="default">
      <name>Advertisement of SRv6 SID and Arguments">
      <t>Section 3.1 of <xref target="RFC8986"/> Arguments</name>
      <t><xref target="RFC8986" section="3.1"/> 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 MUST <bcp14>MUST</bcp14> be set
      to zero, and the argument length MUST Argument Length (AL) <bcp14>MUST</bcp14> be zero.</t>
      <t>Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) support arguments.
      As specified in Section 3.2.1 of <xref target="RFC9252"/>, target="RFC9252" section="3.2.1"/>, the SRv6 SID
      Structure Sub-Sub-TLV MUST <bcp14>MUST</bcp14> be included when signaling an SRv6 SID
      corresponding to an 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>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 source
      node to append the ARG component to the LOC:FUNC portion, thereby
      constructing the complete SRv6 SID (LOC:FUNC:ARG). This fully-formed 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"/>, target="RFC8754" format="default"/>, as required.</t>
      <t>Since arguments may be optional, the SRv6 Endpoint Node endpoint node that owns the
      SID MUST <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 Argument Length (AL) 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 MUST <bcp14>MUST</bcp14> be set to zero.</t>
      <t>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, SID or by another node/mechanism. The advertisement of the ARG
      value MUST <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 REQUIRED.</t> <bcp14>REQUIRED</bcp14>.</t>
    </section>
    <section anchor="EVPNESI"
             title="End.DT2M numbered="true" toc="default">
      <name>End.DT2M Signaling for EVPN ESI Filtering"> Filtering</name>
      <t>As specified in <xref target="RFC9252"/>, target="RFC9252" format="default"/>, the LOC:FUNC portion of the
      SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3
      (Inclusive Multicast Ethernet Tag Route), route), while the Ethernet Segment
      Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in <xref
      target="RFC8986"/>) target="RFC8986" format="default"/>) is signaled via EVPN Route Type 1 (Ethernet
      Auto-Discovery per Ethernet Segment (A-D per ES) Route). route). The following
      subsections provide a more detailed specification of the signaling and
      processing mechanisms compared to <xref target="RFC9252"/>.</t> target="RFC9252" format="default"/>.</t>
      <t>ESI Filtering is a split-horizon mechanism used for Multi-Homing multihoming
      <xref target="RFC7432"/> target="RFC7432" format="default"/> or Ethernet-Tree (E-Tree) procedures <xref
      target="RFC8317"/>. target="RFC8317" format="default"/>. ESI Filtering is not applicable in scenarios
      where:<list style="symbols">
      where:</t>
      <ul spacing="normal">
        <li>
          <t>No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM)
          traffic exists,</t>
        </li>
        <li>
          <t>No multi-homing multihoming is present,</t>
        </li>
        <li>
          <t>No split-horizon mechanism is required, or</t>
        </li>
        <li>
          <t>The local-bias "Local Bias" method (as specified in <xref target="RFC8365"/>) target="RFC8365" format="default"/>)
          is employed.</t>
        </list></t>
        </li>
      </ul>
      <t>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>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="I-D.ietf-spring-srv6-srh-compression"/>. target="RFC9800" format="default"/>.
      In deployments where a mix of compressed and uncompressed SIDs is
      present, the behaviors advertised in the Ethernet Auto-Discovery (A-D)
      per ES Routes routes (EVPN Route Type 1) and Inclusive Multicast Ethernet Tag
      Routes
      routes (EVPN Route Type 3) MAY <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 argument
      length AL
      consistency checks between EVPN Route Type 1 and EVPN Route Type
      3, as described in the following subsections, are satisfied.</t>
      <section anchor="RT1" title="Advertisement numbered="true" toc="default">
        <name>Advertisement of Ethernet A-D per ES Route"> Route</name>
        <t>Ethernet Auto-Discovery (A-D) per ES Routes routes (EVPN Route Type 1), as
        defined in <xref target="RFC7432"/>, target="RFC7432" format="default"/>, are utilized to enable
        split-horizon filtering and fast convergence in multi-homing multihoming
        scenarios. Additionally, A-D per ES Routes routes facilitate egress filtering
        of BUM traffic originating from a Leaf, as specified in <xref
        target="RFC8317"/>.</t> target="RFC8317" format="default"/>.</t>
        <t>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"/>, target="RFC9252" format="default"/>, the advertisement of this route SHOULD <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 MUST <bcp14>MUST</bcp14> be included. As no ARG value is required to be
        signaled in this case, the AL MUST <bcp14>MUST</bcp14> be set to 0.</t>

        <t>Following
        <t>The following is an example representation of the BGP Prefix-SID
        Attribute encoding in this case:</t>
        <figure anchor="RT1NOARG"
                title="EVPN anchor="RT1NOARG">
          <name>EVPN Route Type 1 without Without ARG for ESI Filtering">
          <artwork><![CDATA[ Filtering</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
BGP Prefix SID Attr:
    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>When ESI Filtering is in use, the advertisement of this route MUST <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 MUST <bcp14>MUST</bcp14> be included. Additionally, as a
        non-zero ARG value is being signaled, the Argument Length (AL) MUST AL <bcp14>MUST</bcp14> be
        set to the size of the ARG, and the size SHOULD <bcp14>SHOULD</bcp14> be a multiple of 8 to
        ensure consistency across implementations for ease of operations. The
        SRv6 SID Structure Sub-Sub-TLV MUST <bcp14>MUST</bcp14> set the Locator Block Length
        (LBL), Locator Node Length (LNL),
        LBL, LNL, and Function Length (FL) FL fields with
        values that indicate the offset at which the ARG value is encoded
        within the 128-bit SRv6 SID.</t>
        <t>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"
                title="EVPN anchor="RT1ARG">
          <name>EVPN Route Type 1 with ARG for ESI Filtering">
          <artwork><![CDATA[ Filtering</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
BGP Prefix SID Attr:
    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>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"/>, target="RFC9252" format="default"/>, as further detailed in <xref
        target="BACKWARD"/>.</t> target="BACKWARD" format="default"/>.</t>
        <t>Therefore, it is REQUIRED <bcp14>REQUIRED</bcp14> that the LBL, LNL, and FL values be set
        in accordance with the SID Structure structure for End.DT2M SRv6 Service SIDs,
        ensuring compliance with <xref target="RFC9252"/>.</t> target="RFC9252" format="default"/>.</t>
      </section>
      <section anchor="RT3"
               title="Advertisement numbered="true" toc="default">
        <name>Advertisement of Inclusive Multicast Ethernet Tag Route"> Route</name>
        <t>The Inclusive Multicast Ethernet Tag Route route (EVPN Route Type 3), as
        defined in <xref target="RFC7432"/>, target="RFC7432" format="default"/>, is used to advertise multicast
        traffic reachability information via MP-BGP Multiprotocol BGP (MP-BGP) to all other PE routers
        within a given EVPN instance. When utilizing SRv6 transport, the
        advertisement of this route MUST <bcp14>MUST</bcp14> include the BGP Prefix-SID Attribute
        with an SRv6 L2 Service TLV to indicate the use of SRv6.</t>
        <t>Regardless of whether ESI Filtering is in use, the SRv6 Service SID
        MUST
        <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 MUST <bcp14>MUST</bcp14> be
        included. The LBL, LNL, and FL fields MUST <bcp14>MUST</bcp14> be set to indicate the
        structure of the SRv6 Service SID being advertised.</t>
        <t>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 MUST <bcp14>MUST</bcp14> be set to 0.</t>

        <t>Following
        <t>The following is an example representation of the BGP Prefix-SID
        Attribute encoding in this case:</t>
        <figure anchor="RT3NOARG"
                title="EVPN anchor="RT3NOARG">
          <name>EVPN Route Type 3 without Without ESI Filtering">
          <artwork><![CDATA[ Filtering</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
BGP Prefix SID Attr:
    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>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 MUST <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 MUST <bcp14>MUST</bcp14> use
        the same AL for all local Ethernet Segments with Attachment Circuits attachment circuits
        within the same Broadcast Domain.</t> broadcast domain.</t>
        <t>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" title="EVPN anchor="RT3ARG">
          <name>EVPN Route Type 3 with ESI Filtering">
          <artwork><![CDATA[ Filtering</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
BGP Prefix SID Attr:
    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>When ESI Filtering is in use, the advertising router MUST <bcp14>MUST</bcp14> ensure
        that the AL signaled in the EVPN Route Type 3 is equal to the AL
        signaled in the corresponding EVPN Route Type 1.</t>
      </section>
      <section anchor="PROC" title="Processing numbered="true" toc="default">
        <name>Processing at Ingress PE"> PE</name>
        <t>An ingress PE receives the LOC:FUNC portion of the SRv6 Service SID
        to be used for BUM traffic through EVPN Route Type 3
        advertisements.</t>
        <t>When ESI Filtering is not in use, the SRv6 Service SID to be used
        consists solely of the LOC:FUNC portion received via EVPN Route Type
        3.</t>
        <t>When ESI Filtering is in use, the ESI Filtering ARG of the SRv6
        Service SID is signaled through EVPN Route Type 1 (Ethernet
        Auto-Discovery per Ethernet Segment Route). route). The ARG, in combination
        with the LOC:FUNC portion received via EVPN Route Type 3, forms the
        SRv6 Service SID to be used.</t>
        <t>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
        SHOULD
        <bcp14>SHOULD</bcp14> log a message to facilitate troubleshooting.</t>
        <t>The ingress PE router MUST <bcp14>MUST</bcp14> follow the processing steps outlined
        below when handling SRv6 Service SID advertisements:</t>

        <t><list style="numbers">
        <ol spacing="normal" type="1"><li>
            <t>If AL=0 is signaled via EVPN Route Type 3, 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 MUST
            LBL + LNL + FL <bcp14>MUST</bcp14> be set to zero for encoding on the data path.
            Additionally, the router MUST <bcp14>MUST</bcp14> ignore the SID value and its SID
            structure advertised in the corresponding EVPN Route Type 1.</t>
          </li>
          <li>
            <t>If a non-zero AL is signaled via EVPN Route Type 3, then the
            matching EVPN Route Type 1 for the Ethernet Segment is located and
            the presence of an SRv6 SID advertisement with the End.DT2M
            behavior is verified.<list style="letters"> verified.</t>
            <ol spacing="normal" type="a"><li>
                <t>If the presence of such a SRv6 SID is not verified, or if
                the AL=0 AL is zero in the EVPN Route Type 1, then no usable ARG value is
                available. The SRv6 Service SID MUST <bcp14>MUST</bcp14> be formed as described in
                (1) above.</t>
              </li>
              <li>
                <t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3
                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 MUST NOT <bcp14>MUST NOT</bcp14> be forwarded for such routes from the
                specific Ethernet Segment. Implementations SHOULD <bcp14>SHOULD</bcp14> log an error
                message for troubleshooting this condition.</t>
              </li>
              <li>
                <t>If the AL values in EVPN Route Type 1 and EVPN Route Type 3
                are both non-zero and equal, then the ARG value from EVPN
                Route Type 1 is considered valid. This ARG value MUST <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 EVPN
                Route Type 3. All bits beyond LBL + LNL + FL + AL MUST <bcp14>MUST</bcp14> be set
                to zero.</t>
              </list></t>
          </list></t>
              </li>
            </ol>
          </li>
        </ol>

<!-- [rfced] These sentences may be difficult to follow because of the two
instances of "based on...". How may we update to improve readability?

Original:
   Based on the above procedures, the SRv6 Service SID encoding for the
   data plane without an ESI Filtering ARG, based on the examples in
   Figure 1 and Figure 3, is as follows:
   ...
   Based on the above procedures, the SRv6 Service SID encoding for the
   data plane along with an ESI Filtering ARG, based on the examples in
   Figure 2 and Figure 4, is as follows:

Perhaps:
   Using the procedures above with the examples in Figures 1 and 3, the
   SRv6 Service SID encoding for the
   data plane without an ESI Filtering ARG
   is as follows:
   ...
   Using the procedures above with the examples in Figures 2 and 4, the
   SRv6 Service SID encoding for the
   data plane along with an ESI Filtering ARG
   is as follows:
-->

	<t>Based on the above procedures, the SRv6 Service SID encoding for
        the data plane without an ESI Filtering ARG, based on the examples in Figures
        <xref target="RT1NOARG"/> target="RT1NOARG" format="counter"/> and <xref target="RT3NOARG"/>, target="RT3NOARG" format="counter"/>, is as
        follows:</t>
        <figure anchor="SIDPACKET"
                title="SRv6 anchor="SIDPACKET">
          <name>SRv6 Service SID Encoding for Data Plane without ARG">
          <artwork><![CDATA[ Without ARG</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Route Type 3:
 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>Based on the above procedures, the SRv6 Service SID encoding for
        the data plane along with an ESI Filtering ARG, based on the examples
        in <xref target="RT1ARG"/> target="RT1ARG" format="counter"/> and <xref target="RT3ARG"/>, target="RT3ARG" format="counter"/>, is as
        follows:</t>
        <figure anchor="SIDPACKETARG"
                title="SRv6 anchor="SIDPACKETARG">
          <name>SRv6 Service SID Encoding for Data Plane with ARG">
          <artwork><![CDATA[Route ARG</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Route Type 1:
 SID: ::aaaa:0:0:0
 Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

Route Type 3:
 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><xref target="MULTIBD"/> target="MULTIBD" format="default"/> provides another example that illustrates
        the signaling and processing of multiple bridge domains in a
        deployment design.</t>

        <t><figure anchor="MULTIBD"
            title="Example
        <figure anchor="MULTIBD">
          <name>Example with Multiple Bridge Domains">
            <artwork><![CDATA[ Domains</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                     +--------------------------------+
                     |                                |
                 PE1 |                                |
                 +---------+                          |
  BUM on BD1     | +-----+ |                          |
+----------------> | BD1 |-------------+              |
|                | +-----+ |           |              |
|  BUM on BD2    | +-----+ |           v          PE3 |
| +--------------> | 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 |                               |
                      |                               |
                      |                               |
                      +-------------------------------+

 Route Type 1 ESI-1:
  SID: ::aaaa:0:0:0
  Structure: LBL: 32, LNL: 16, FL: 16, AL: 16

 Route Type 3 from BD1:
  SID: 2001:db8:1:fbd1:fbd1:
  Structure: LBL: 32, LNL: 16, FL: 32, AL: 16

 Route Type 3 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></t>
        </figure>
      </section>
    </section>
    <section anchor="BACKWARD" title="Backward Compatibility"> numbered="true" toc="default">
      <name>Backward Compatibility</name>
      <t>Existing implementations that rely on the bitwise logical-OR
      operation, as specified in Section 6.3 of <xref target="RFC9252"/>, target="RFC9252" section="6.3"/>,
      function correctly only when the SID structures of the two EVPN Route
      Types route
      types are identical.</t>
      <t>Backward compatibility with implementations performing the bitwise
      logical-OR operation is maintained when EVPN Route Type 3 and its
      corresponding EVPN Route Type 1 advertise SIDs with the same SID
      structure, as outlined in Sections <xref target="RT1"/> target="RT1" format="counter"/> and <xref
      target="RT3"/>.</t> target="RT3" format="counter"/>.</t>
      <t>However, when the SID structures of the two route types are not
      identical, the bitwise logical-OR operation specified in <xref
      target="RFC9252"/> target="RFC9252" format="default"/> cannot be applied. Instead, the alternative method
      specified in <xref target="PROC"/> MUST target="PROC" format="default"/> <bcp14>MUST</bcp14> be used to correctly derive the
      SRv6 Service SID in such cases.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not require any action from IANA.</t> has no IANA actions.</t>
    </section>
    <section anchor="SEC" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document only 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 what is those already covered by
      <xref target="RFC9252"/>.</t> target="RFC9252" format="default"/>.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8317.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>

<!-- ietf-spring-srv6-srh-compression published as RFC 9800-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9800.xml"/>
      </references>
    </references>
    <section anchor="ACK" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to acknowledge Jayshree Subramanian, Sonal
      Agarwal, Swadesh Agrawal, Dongling Duan, Luc Andre Burdet, Patrice
      Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will Lockhart,
      and Vinod Prabhu <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 inputs review of the document and
      input on aspects related to the signaling of the End.DT2M SRv6
      Endpoint behavior Behavior that required clarification as also
      for their review of this document. clarification. The authors thank Jeffrey Zhang <contact fullname="Jeffrey Zhang"/>
      for his shepherd review of the document and suggestions for its
      improvements.
      improving the document. The authors would also like to thank Gunter van <contact
      fullname="Gunter Van de Velde Velde"/> for his extensive review and
      suggestions for improving the readability of the document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.8986.xml'?>

      <?rfc include='reference.RFC.9252.xml'?>

      <?rfc include='reference.RFC.7432.xml'?>

      <?rfc include='reference.RFC.2119.xml'?>

      <?rfc include='reference.RFC.8402.xml'?>

      <?rfc include='reference.RFC.8174.xml'?>

      <?rfc include='reference.RFC.8317.xml'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.8365.xml'?>

      <?rfc include='reference.RFC.8754.xml'?>

      <?rfc include='reference.I-D.ietf-spring-srv6-srh-compression'?>
    </references>
  </back>

<!-- [rfced] We have a few question about the text below.

a) The following sentences include the descriptions of EVPN Route Types 1
and/or 3. Note that not all mentions of EVPN Route Types 1 and 3 include the
descriptions. Would removing the descriptions in these sentences improve
readability? If needed, perhaps the descriptions can be added to a Terminology
section (which could be added as a new Section 1.2) or included in the first
instance.

b) Also, several forms are used for the description of EVPN Route Type 1:

  Ethernet Auto-Discovery per Ethernet Segment (A-D per ES)
  Ethernet Auto-Discovery (A-D) per ES
  Ethernet Auto-Discovery per Ethernet Segment Route

Should the definition match what is listed in the IANA registry at
<https://www.iana.org/assignments/evpn>? RFC 7432 and IANA registry define EVPN
Route Type 1 as "Ethernet Auto-discovery", but RFC 7432 also discusses
"Ethernet A-D per ES route" and "Ethernet A-D per EVI route".

Original:
   As specified in [RFC9252], the LOC:FUNC portion of the SRv6 SID with
   End.DT2M behavior is signaled via EVPN Route Type 3 (Inclusive
   Multicast Ethernet Tag Route), while the Ethernet Segment Identifier
   (ESI) Filtering ARG (denoted as Arg.FE2 in [RFC8986]) is signaled via
   EVPN Route Type 1 (Ethernet Auto-Discovery per Ethernet Segment (A-D
   per ES) Route).

   In deployments where a mix of compressed and uncompressed SIDs is
   present, the behaviors advertised in the Ethernet Auto-Discovery
   (A-D) per ES Routes (EVPN Route Type 1) and Inclusive Multicast
   Ethernet Tag Routes (EVPN Route Type 3) MAY consist of a combination
   of compressed and uncompressed End.DT2M behavior flavors.

   Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1), as
   defined in [RFC7432], are utilized to enable split-horizon filtering
   and fast convergence in multi-homing scenarios.

   The Inclusive Multicast Ethernet Tag Route (EVPN Route Type 3), as
   defined in [RFC7432], is used to advertise multicast traffic
   reachability information via MP-BGP to all other PE routers within a
   given EVPN instance.

   When ESI Filtering is in use, the ESI Filtering ARG of the SRv6
   Service SID is signaled through EVPN Route Type 1 (Ethernet Auto-
   Discovery per Ethernet Segment Route).

Perhaps:
   As specified in [RFC9252], the LOC:FUNC portion of the SRv6 SID with
   End.DT2M behavior is signaled via EVPN Route Type 3,
   while the Ethernet Segment Identifier
   (ESI) Filtering ARG (denoted as Arg.FE2 in [RFC8986]) is signaled via
   EVPN Route Type 1.

   In deployments where a mix of compressed and uncompressed SIDs is
   present, the behaviors advertised in
   EVPN Route Type 1 and
   EVPN Route Type 3 MAY consist of a combination
   of compressed and uncompressed End.DT2M behavior flavors.

   EVPN Route Type 1, as
   defined in [RFC7432], is utilized to enable split-horizon filtering
   and fast convergence in multi-homing scenarios.

   EVPN Route Type 3, as
   defined in [RFC7432], is used to advertise multicast traffic
   reachability information via MP-BGP to all other PE routers within a
   given EVPN instance.

   When ESI Filtering is in use, the ESI Filtering ARG of the SRv6
   Service SID is signaled through EVPN Route Type 1.
-->

<!-- [rfced] Terminology

a) We updated two instance of "SRv6 Endpoint behavior" to "SRv6 Endpoint
Behavior" to match usage elsewhere in the document and in RFC 9252. Should the
two instances of "endpoint behavior" in the sentences below also be updated to
"SRv6 Endpoint Behavior" (capitalized and prefaced with "SRv6")? Note that we
did not make any changes to "End.DT2M behavior".

Original:
   As specified in Section 3.2.1 of [RFC9252], the SRv6 SID Structure
   Sub-Sub-TLV MUST be included when signaling an SRv6 SID corresponding
   to an endpoint behavior that supports argument.
   ...
   While the focus is primarily on the signaling of the End.DT2M SRv6
   Endpoint Behavior via EVPN Route Types 1 and 3, the procedures
   described herein are also applicable to other similar endpoint
   behaviors with arguments that may be signaled using BGP.

b) We see that "BGP Prefix SID Attr" is used in the figures. Should this align
with usage in general text? That is, should it be updated to "BGP Prefix-SID
Attribute"?

Also, should "BGP Prefix-SID Attribute" be updated to "BGP Prefix-SID attribute"
(lowercase "attribute")? We see that the lowercase "attribute" is used in
this context in RFC 9252 and other published RFCs.

Current:
  BGP Prefix SID Attr (in figures)
  BGP Prefix-SID Attribute (in text)

Perhaps:
  BGP Prefix-SID attribute

c) We note that "Overlay Service" is capitalized in this document, but it is
lowercase in RFC 9252. Would you like to use the lowercase "overlay service"
for consistency with RFC 9252?

d) We note inconsistencies in the terms below throughout the text. Should
these be uniform? If so, please let us know which form is preferred.

Route Type 1
EVPN Route Type 1

Route Type 3
EVPN Route Type 3

Leaf
leaf

e) We updated the following term as shown below. Let us know any concerns.

Global Internet Routing > global Internet routing
  Note: Per usage in RFCs 9505, 9199, and others.
-->

<!-- [rfced] FYI - We have added expansions for the following abbreviation(s)
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Multiprotocol BGP (MP-BGP)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

<!-- [rfced] Please review each artwork element in the xml file. Specifically,
should the artwork elements in Figures 1-6 be tagged as sourcecode or
another element?
-->

</rfc>