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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-srv6-services-15"
     ipr="trust200902">
  <?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" ?> number="9252" submissionType="IETF" category="std" consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.2 -->

  <front>
    <title abbrev="SRv6 abbrev="SRv6-Based BGP based Overlay Services">SRv6 BGP based Services">BGP Overlay
    Services</title> Services Based on Segment Routing over IPv6 (SRv6)</title>
    <seriesInfo name="RFC" value="9252"/>
    <author fullname="Gaurav Dawra" initials="G" role="editor" surname="Dawra">
      <organization>LinkedIn</organization>
      <address>
        <postal>
          <street/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>gdawra.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K" role="editor" surname="Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Robert Raszuk" initials="R" surname="Raszuk">
      <organization>NTT Network Innovations</organization>
      <address>
        <postal>
          <street>940 Stewart Dr</street> Dr.</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94085</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>robert@raszuk.net</email>
      </address>
    </author>
    <author fullname="Bruno Decraene" initials="B" surname="Decraene">
      <organization>Orange</organization>
      <address>
        <postal>
          <street/>
          <country>France</country>
        </postal>
        <email>bruno.decraene@orange.com</email>
      </address>
    </author>
    <author fullname="Shunwan Zhuang" initials="S" surname="Zhuang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>
          <country>China</country>
        </postal>
        <email>zhuangshunwan@huawei.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>
<date year=""/>

    <area>Routing</area>

    <workgroup>BESS Working Group</workgroup> year="2022" month="July"/>
    <area>RTG</area>
    <workgroup>BESS</workgroup>
    <keyword>BGP</keyword>
    <keyword>SRv6</keyword>
    <abstract>

      <t>This document defines procedures and messages for SRv6-based BGP
      services
      services, including L3VPN, EVPN, Layer 3 Virtual Private Network (L3VPN),
      Ethernet VPN (EVPN), and Internet services. It builds on
      RFC4364 &ldquo;BGP/MPLS
      "BGP/MPLS IP Virtual Private Networks (VPNs)&rdquo; (VPNs)" (RFC 4364) and
      RFC7432 &ldquo;BGP
      "BGP MPLS-Based Ethernet VPN&rdquo;.</t> VPN" (RFC 7432).</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>SRv6 refers to Segment Routing instantiated on the IPv6 dataplane data plane
      <xref target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
      <t>BGP is used to advertise the reachability of prefixes of a particular
      service from an egress PE Provider Edge (PE) to ingress PE nodes.</t>

      <t>SRv6 based
      <t>SRv6-based BGP services refers refer to the Layer-3 Layer 3 (L3) and Layer-2 Layer 2 (L2) overlay
      services with BGP as the control plane and SRv6 as dataplane. the data plane. This document
      defines procedures and messages for SRv6-based BGP services services, including
      L3VPN, EVPN, and Internet services. It builds on <xref
      target="RFC4364"/> &ldquo;BGP/MPLS "BGP/MPLS IP Virtual
      Private Networks
      (VPNs)&rdquo; and (VPNs)" <xref target="RFC7432"/> &ldquo;BGP target="RFC4364" format="default"/> and
      "BGP MPLS-Based Ethernet VPN&rdquo;.</t> VPN" <xref target="RFC7432" format="default"/>.</t>
      <t>SRv6 SID refers to an SRv6 Segment Identifier Identifier, as defined in <xref
      target="RFC8402"/>.</t>
      target="RFC8402" format="default"/>.</t>

      <t>SRv6 Service SID refers to an SRv6 SID associated with one of the
      service-specific SRv6 Endpoint behaviors Behaviors on the advertising Provider
      Edge (PE)
      PE router, such as (but not limited to), to) End.DT (Table lookup (look up in
      a VRF) the
      Virtual Routing and Forwarding (VRF) table) or End.DX (cross-connect to a nexthop)
      next hop) behaviors in the case of
      Layer-3 Virtual Private Network (L3VPN) service
      L3VPN service, as defined in <xref
      target="RFC8986"/>.
      target="RFC8986" format="default"/>. This document describes how existing
      BGP messages between PEs may carry SRv6 Service SIDs to interconnect PEs
      and form VPNs.</t>
      <t>To provide SRv6 service with best-effort connectivity, the egress PE
      signals an SRv6 Service SID with the BGP overlay service route. The
      ingress PE encapsulates the payload in an outer IPv6 header where the
      destination address is the SRv6 Service SID provided by the egress
      Provider Edge (PE).
      PE. The underlay between the PEs only needs to support
      plain IPv6 forwarding <xref target="RFC8200"/>.</t> target="RFC8200" format="default"/>.</t>
      <t>To provide SRv6 service in conjunction with an underlay SLA Service Level Agreement (SLA) from the
      ingress PE to the egress PE, the egress PE colors the overlay service
      route with a Color Extended Community <xref
      target="I-D.ietf-idr-segment-routing-te-policy"/> target="RFC9012" format="default"/> for steering of flows
      for those routes routes, as specified in section 8 of <xref
      target="I-D.ietf-spring-segment-routing-policy"/>. target="I-D.ietf-spring-segment-routing-policy" section="8" sectionFormat="of" format="default"/>. The ingress PE
      encapsulates the payload packet in an outer IPv6 header with the
      SR Policy segment list of SR policy associated with the related SLA along with the SRv6
      Service SID associated with the route using the Segment Routing Header
      (SRH) <xref target="RFC8754"/>. target="RFC8754" format="default"/>. The underlay nodes whose SRv6
      SID&rsquo;s
      SIDs are part of the SRH segment list MUST <bcp14>MUST</bcp14> support the SRv6 data
      plane.</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="SIDTLV" title="SRv6 numbered="true" toc="default">
      <name>SRv6 Services TLVs "> TLVs</name>
      <t>This document extends the use of the BGP Prefix-SID attribute <xref
      target="RFC8669"/> target="RFC8669" format="default"/> to carry SRv6 SIDs and their associated information
      with the BGP address-families address families that are listed further in this
      section.</t>
      <t>The SRv6 Service TLVs are defined as two new TLVs of the BGP
      Prefix-SID Attribute attribute to achieve signaling of SRv6 SIDs for L3 and L2
      services.</t>

      <t><list style="symbols">
          <t>SRv6
      <dl newline="true" spacing="normal">
        <dt>SRv6 L3 Service TLV: This TLV:</dt>
	<dd>This TLV encodes Service SID information for
          SRv6 based
          SRv6-based L3 services. It corresponds to the equivalent
          functionality provided by an MPLS Label label when received with a Layer 3
          service route route, as defined in <xref target="RFC4364"/> target="RFC4364" format="default"/>, <xref
          target="RFC4659"/> target="RFC4659" format="default"/>, <xref target="RFC8950"/> target="RFC8950" format="default"/>, and <xref
          target="RFC9136"/>. target="RFC9136" format="default"/>. Some SRv6 Endpoint behaviors which Behaviors that may be
          encoded,
          encoded are, but not limited to, are End.DX4, End.DT4, End.DX6, End.DT6,
          and End.DT46.</t>

          <t>SRv6 End.DT46.</dd>
          <dt>SRv6 L2 Service TLV: This TLV:</dt>
	  <dd>This TLV encodes Service SID information for
          SRv6 based
          SRv6-based L2 services. It corresponds to the equivalent
          functionality provided by an MPLS Label1 label for Ethernet VPN (EVPN)
          Route-Types
          Route Types for Layer 2 services, as defined in <xref target="RFC7432"/>.
	  target="RFC7432" format="default"/>. Some SRv6
          Endpoint behaviors which Behaviors that may be encoded, encoded are, but not limited to, are
          End.DX2, End.DX2V, End.DT2U, and End.DT2M.</t>
        </list></t> End.DT2M.</dd>
      </dl>
      <t>When an egress PE is enabled for BGP Services over the SRv6 data-plane, data plane,
      it signals one or more SRv6 Service SIDs enclosed in an SRv6 Service TLV(s)
      within the BGP Prefix-SID Attribute attribute attached to MP-BGP NLRIs Multiprotocol BGP (MP-BGP) Network Layer Reachability Information (NLRI) defined in
      <xref target="RFC4760"/> target="RFC4760" format="default"/>, <xref target="RFC4659"/> target="RFC4659" format="default"/>, <xref
      target="RFC8950"/> target="RFC8950" format="default"/>, <xref target="RFC7432"/> target="RFC7432" format="default"/>, <xref target="RFC4364"/> target="RFC4364" format="default"/>, and
        <xref target="RFC9136"/> target="RFC9136" format="default"/>, where applicable applicable, as described in Sections <xref
      target="L3BGP"/> target="L3BGP" format="counter"/> and <xref target="EVPNBGP"/>.</t> target="EVPNBGP" format="counter"/>.</t>
      <t>The support for BGP Multicast VPN (MVPN) Services <xref
      target="RFC6513"/> target="RFC6513" format="default"/> with SRv6 is outside the scope of this document.</t>
      <t>The following depicts the SRv6 Service TLVs encoded in the BGP
      Prefix-SID Attribute:</t> attribute:</t>
      <figure anchor="SRV6SVCTLV" title="SRv6 anchor="SRV6SVCTLV">
        <name>SRv6 Service TLVs">
        <artwork><![CDATA[ TLVs</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TLV Type    |         TLV Length            |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SRv6 Service Sub-TLVs                                      //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t><list style="symbols">
          <t>TLV
      <dl newline="true" spacing="normal">
        <dt>TLV Type (1 octet): This octet):</dt>
	<dd>This field is assigned values a value from the IANA
          registry IANA's
          "BGP Prefix-SID TLV Types". Types" subregistry. It is set to 5 for the SRv6 L3
          Service TLV. It is set to 6 for the SRv6 L2 Service TLV.</t>

          <t>TLV TLV.</dd>
          <dt>TLV Length (2 octets): Specifies octets):</dt>
	  <dd>This field specifies the total length, in octets, of
          the TLV Value.</t>

          <t>RESERVED Value.</dd>
          <dt>RESERVED (1 octet): This octet):</dt>
	  <dd>This field is reserved; it MUST <bcp14>MUST</bcp14> be set to 0
          by the sender and ignored by the receiver.</t>

          <t>SRv6 receiver.</dd>
          <dt>SRv6 Service Sub-TLVs (variable): This (variable):</dt>
	  <dd>This field contains SRv6
          Service related
          service-related information and is encoded as an unordered list of
          Sub-TLVs whose format is described below.</t>
        </list></t> below.</dd>
      </dl>
      <t>A BGP speaker receiving a route containing the BGP Prefix-SID Attribute attribute
      with one or more SRv6 Service TLVs observes the following rules when
      advertising the received route to other peers:<list style="symbols">
          <t>if peers:</t>
      <ul spacing="normal">
        <li>If the nexthop BGP next hop is unchanged during the advertisement, the SRv6
          Service TLVs, including any unrecognized Types of Sub-TLV and
          Sub-Sub-TLV, SHOULD <bcp14>SHOULD</bcp14> be propagated further. In addition, all Reserved
          fields in the TLV or Sub-TLV TLV, Sub-TLV, or Sub-Sub-TLV MUST <bcp14>MUST</bcp14> be propagated
          unchanged.</t>

          <t>if
          unchanged.</li>
        <li>If the nexthop BGP next hop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs
          SHOULD
          <bcp14>SHOULD</bcp14> be updated with the locally allocated SRv6 SID information.
          Any unrecognized received Sub-TLVs and Sub-Sub-TLVs MUST that are unrecognized <bcp14>MUST</bcp14> be
          removed.</t>
        </list></t>
          removed.</li>
      </ul>
    </section>
    <section anchor="SRv6-TLV" title="SRv6 numbered="true" toc="default">
      <name>SRv6 Service Sub-TLVs"> Sub-TLVs</name>
      <t>The format of a single SRv6 Service Sub-TLV is depicted below:</t>
      <figure anchor="SRV6SVCSTLV" title="SRv6 anchor="SRV6SVCSTLV">
        <name>SRv6 Service Sub-TLVs">
        <artwork><![CDATA[ Sub-TLVs</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service  |    SRv6 Service               | SRv6 Service //
| Sub-TLV       |    Sub-TLV                    | Sub-TLV      //
| Type          |    Length                     | value Value        //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t><list style="symbols">
          <t>SRv6
      <dl newline="true" spacing="normal">
        <dt>SRv6 Service Sub-TLV Type (1 octet): Identifies octet):</dt>
	<dd>This field identifies the type of SRv6
          service information. It is assigned values a value from the IANA Registry IANA's
          "SRv6 Service Sub-TLV Types".</t>

          <t>SRv6 Types" subregistry.</dd>
          <dt>SRv6 Service Sub-TLV Length (2 octets): Specifies octets):</dt>
	  <dd>This field specifies the total
          length, in octets, of the Sub-TLV Value field.</t>

          <t>SRv6 field.</dd>
          <dt>SRv6 Service Sub-TLV Value (variable): Contains (variable):</dt>
	  <dd>This field contains data specific to
          the Sub-TLV Type. In addition to fixed-length data, it contains
          other properties of the SRv6 Service service encoded as a set of SRv6
          Service Data Sub-Sub-TLVs whose format is described in <xref
          target="SID-SERVICE-DATA-TLV"/> below.</t>
        </list></t>
	  target="SID-SERVICE-DATA-TLV" format="default"/> below.</dd>
      </dl>
      <section anchor="SRv6-SID-INFO" title="SRv6 numbered="true" toc="default">
        <name>SRv6 SID Information Sub-TLV"> Sub-TLV</name>
        <t>SRv6 Service Sub-TLV Type 1 is assigned for the SRv6 SID Information
        Sub-TLV. This Sub-TLV contains a single SRv6 SID along with its
        properties. Its encoding is depicted below:</t>
        <figure anchor="SRV6SIDINFO" title="SRv6 anchor="SRV6SIDINFO">
          <name>SRv6 SID Information Sub-TLV">
          <artwork><![CDATA[ Sub-TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service  |    SRv6 Service               |               |
| Sub-TLV       |    Sub-TLV                    |               |
| Type=1        |    Length                     |  RESERVED1    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SRv6 SID Value (16 octets)                                  //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Svc SID Flags |   SRv6 Endpoint Behavior      |   RESERVED2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SRv6 Service Data Sub-Sub-TLVs                              //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>SRv6
        <dl newline="true" spacing="normal">
          <dt>SRv6 Service Sub-TLV Type (1 octet): This octet):</dt>
	  <dd>This field is set to 1 to
            represent the SRv6 SID Information Sub-TLV.</t>

            <t>SRv6 Sub-TLV.</dd>
            <dt>SRv6 Service Sub-TLV Length (2 octets): This octets):</dt>
	    <dd>This field contains the
            total length, in octets, of the Value field of the Sub-TLV.</t>

            <t>RESERVED1 Sub-TLV.</dd>
            <dt>RESERVED1 (1 octet): MUST octet):</dt>
	    <dd>This field <bcp14>MUST</bcp14> be set to 0 by the sender and ignored
            by the receiver.</t>

            <t>SRv6 receiver.</dd>
            <dt>SRv6 SID Value (16 octets): Encodes octets):</dt>
	    <dd>This field encodes an SRv6 SID SID, as defined in
            <xref target="RFC8986"/></t>

            <t>SRv6 target="RFC8986" format="default"/>.</dd>
            <dt>SRv6 Service SID Flags (1 octet): Encodes octet):</dt>
	    <dd>This field encodes SRv6 Service SID
            Flags - -- none are currently defined. SHOULD It <bcp14>MUST</bcp14> be set to 0 by the
            sender and any unknown flags MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>

            <t>SRv6 receiver.</dd>
            <dt>SRv6 Endpoint Behavior (2 octets): Encodes octets):</dt>
	    <dd>This field encodes the SRv6 Endpoint
            behavior
            Behavior codepoint value that is associated with the SRv6 SID. The
            codepoints used are from the IANA's "SRv6 Endpoint Behavior" registry Behaviors" subregistry
            under the IANA "Segment Routing" parameters registry that was
            introduced by <xref target="RFC8986"/>. target="RFC8986" format="default"/>. The opaque endpoint
            behavior SRv6 Endpoint
            Behavior (i.e., value 0xFFFF) MAY <bcp14>MAY</bcp14> be used when the advertising
            router wishes to abstract the actual behavior of it's its locally
            instantiated SRv6 SID.</t>

            <t>RESERVED2 SID.</dd>
            <dt>RESERVED2 (1 octet): MUST octet):</dt>
	    <dd>This field <bcp14>MUST</bcp14> be set to 0 by the sender and ignored
            by the receiver.</t>

            <t>SRv6 receiver.</dd>
            <dt>SRv6 Service Data Sub-Sub-TLV Value (variable): Used (variable):</dt>
	    <dd>This field is used to
            advertise properties of the SRv6 SID. It is encoded as a set of
            SRv6 Service Data Sub-Sub-TLVs.</t>
          </list></t> Sub-Sub-TLVs.</dd>
        </dl>
        <t>The choice of SRv6 Endpoint behavior Behavior of the SRv6 SID is entirely up
        to the originator of the advertisement. While Sections <xref target="L3BGP"/> target="L3BGP"
	format="counter"/> and <xref target="EVPNBGP"/> target="EVPNBGP" format="counter"/> list the
	SRv6 Endpoint Behaviors that are
        normally expected to be used by the specific route advertisements, the
        reception of other SRv6 Endpoint behaviors Behaviors (e.g., new behaviors that
        may be introduced in the future) is not considered an error. An
        unrecognized endpoint behavior MUST NOT SRv6 Endpoint Behavior <bcp14>MUST NOT</bcp14> be considered invalid by the
        receiver
        receiver, except for behaviors that involve the use of arguments (refer
        to <xref target="SRv6-SID-STRUCTURE"/> target="SRv6-SID-STRUCTURE" format="default"/> for details on argument
        validation). An implementation MAY <bcp14>MAY</bcp14> log a rate-limited warning when it
        receives an unexpected behavior.</t>
        <t>When multiple SRv6 SID Information Sub-TLVs are present, the
        ingress PE SHOULD <bcp14>SHOULD</bcp14> use the SRv6 SID from the first instance of the
        Sub-TLV. An implementation MAY <bcp14>MAY</bcp14> provide a local policy to override this
        selection.</t>
      </section>
      <section anchor="SID-SERVICE-DATA-TLV"
               title="SRv6 numbered="true" toc="default">
        <name>SRv6 Service Data Sub-Sub-TLVs"> Sub-Sub-TLVs</name>
        <t>The format of the SRv6 Service Data Sub-Sub-TLV is depicted
        below:</t>
        <figure anchor="SRV6SVCDATASTLV"
                title="SRv6 anchor="SRV6SVCDATASTLV">
          <name>SRv6 Service Data Sub-Sub-TLVs">
          <artwork><![CDATA[ Sub-Sub-TLVs</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Data |  Sub-Sub-TLV Length               |Sub-Sub TLV //
| Sub-Sub-TLV  |                                   |  Value     //
| Type         |                                   |            //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>SRv6
        <dl newline="true" spacing="normal">
          <dt>SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies octet):</dt>
	  <dd>This field identifies the
            type of Sub-Sub-TLV. It is assigned values a value from the IANA Registry IANA's
            "SRv6 Service Data Sub-Sub-TLVs".</t>

            <t>SRv6 Sub-Sub-TLV Types" subregistry.</dd>
            <dt>SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies octets):</dt>
	    <dd>This field specifies the
            total length, in octets, of the Sub-Sub-TLV Value field.</t>

            <t>SRv6 field.</dd>
            <dt>SRv6 Service Data Sub-Sub-TLV Value (variable): Contains (variable):</dt>
	    <dd>This field contains data
            specific to the Sub-Sub-TLV Type.</t>
          </list></t> Type.</dd>
        </dl>
        <section anchor="SRv6-SID-STRUCTURE"
                 title="SRv6 numbered="true" toc="default">
          <name>SRv6 SID Structure Sub-Sub-TLV"> Sub-Sub-TLV</name>
          <t>SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for the SRv6 SID
          structure
          Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV is used to
          advertise the lengths of the individual parts of the SRv6 SID SID, as
          defined in <xref target="RFC8986"/>. target="RFC8986" format="default"/>. The terms Locator Block and
          Locator Node correspond to the B and N parts respectively parts, respectively, of the
          SRv6 Locator that are is defined in section 3.1 of <xref
          target="RFC8986"/>. target="RFC8986"
	  section="3.1" sectionFormat="of" format="default"/>. It is
	  carried as Sub-Sub-TLV in the SRv6 SID Information Sub-TLV</t> Sub-TLV.</t>
          <figure anchor="SRV6SIDSTRUCT"
                  title="SRv6 anchor="SRV6SIDSTRUCT">
            <name>SRv6 SID Structure Sub-Sub-TLV">
            <artwork><![CDATA[ Sub-Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service  |    SRv6 Service               | Locator Block |
| Data Sub-Sub  |    Data Sub-Sub-TLV           | Length        |
| -TLV Type=1   |    Length                     |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Node  | Function      | Argument      | Transposition |
| Length        | Length        | Length        | Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transposition |
| Offset        |
    +-+-+-+-+-+-+-+-+]]></artwork>
+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>

          <t><list style="symbols">
              <t>SRv6
          <dl newline="true" spacing="normal">
            <dt>SRv6 Service Data Sub-Sub-TLV Type (1 octet): This octet):</dt>
	    <dd>This field is set to 1 to represent the SRv6 SID Structure Sub-Sub-TLV.</t>

              <t>SRv6 Sub-Sub-TLV.</dd>
            <dt>SRv6 Service Data Sub-Sub-TLV Length (2 octets): This octets):</dt>
	    <dd>This field contains a total length of 6 octets.</t>

              <t>Locator octets.</dd>
            <dt>Locator Block Length (1 octet): Contains octet):</dt>
	    <dd>This field contains the length of the SRv6 SID Locator Block in bits.</t>

              <t>Locator bits.</dd>
            <dt>Locator Node Length (1 octet): Contains octet):</dt>
	    <dd>This field contains the length of the SRv6 SID Locator Node in bits.</t>

              <t>Function bits.</dd>
            <dt>Function Length (1 octet): Contains octet):</dt>
	    <dd>This field contains the length of the SRv6 SID Function in bits.</t>

              <t>Argument bits.</dd>
            <dt>Argument Length (1 octet): Contains octet):</dt>
	    <dd>This field contains the length of the SRv6 SID Argument in bits.</t>

              <t>Transposition bits.</dd>
            <dt>Transposition Length (1 octet): Size octet):</dt>
	    <dd>This field is the size in bits for the part of the
            SID that has been transposed (or shifted) into a an MPLS label
              field</t>

              <t>Transposition Label
            field.</dd>
            <dt>Transposition Offset (1 octet): The octet):</dt>
	    <dd>This field is the offset position in bits
              for the part of the SID that has been transposed (or shifted) into a an
              MPLS label field.</t>
            </list></t> Label field.</dd>
          </dl>
          <t><xref target="SIDENCODE"/> target="SIDENCODE" format="default"/> describes mechanisms for the signaling of
          the SRv6 Service SID by transposing a variable part of the SRv6 SID
          value and carrying them this variable part in existing MPLS label Label fields to achieve
          more efficient packing of those service prefix NLRIs in BGP update
          messages. The SRv6 SID Structure Sub-Sub-TLV contains appropriate
          length fields when the SRv6 Service SID is signaled in split parts
          to enable the receiver to put together the SID accurately.</t>
          <t>Transposition Offset indicates the bit position position, and Transposition
          Length indicates the number of bits that are being taken out of the
          SRv6 SID value and put into high order bits of encoded in the MPLS label Label field. The
          bits that have been shifted out MUST <bcp14>MUST</bcp14> be set to 0 in the SID
          value.</t>

          <t>Transposition
          <t>A Transposition Length of 0 indicates nothing is transposed and
          that the entire SRv6 SID value is encoded in the SID Information
          Sub-TLV. In this case, the Transposition Offset MUST <bcp14>MUST</bcp14> be set to
          0.</t>
          <t>The size of the MPLS label Label field limits the bits transposed from
          the SRv6 SID value into it. E.g., For example, the size of the MPLS label Label field in
          <xref target="RFC4364"/> <xref target="RFC8277"/> is 20 bits while in
          <xref target="RFC7432"/> target="RFC4364" format="default"/> and <xref target="RFC8277"
	  format="default"/>, and the size is 24 bits.</t> bits in <xref target="RFC7432" format="default"/>.</t>
          <t>As defined in <xref target="RFC8986"/>, target="RFC8986" format="default"/>, the sum of the Locator
          Block Length (LBL), Locator Node Length (LNL), Function Length (FL),
          and Argument Length (AL) fields MUST <bcp14>MUST</bcp14> be less than or equal to 128
          and greater than the sum of Transposition Offset and Transposition
          Length.</t>
          <t>As an example, consider that the sum of the Locator Block and the
          Locator Node parts is 64. For an SRv6 SID where the entire Function
          part of size 16 bits is transposed, then the transposition offset is
          set to 64 and the transposition length is set to 16. While for an
          SRv6 SID where for which the Function length FL is 24 bits and only the lower
          order 20 bits are transposed (e.g. (e.g., due to the limit of the MPLS
          label
          Label field size), then the transposition offset is set to 68 and
          the transposition length is set to 20.</t>
          <t>BGP speakers that do not support this specification may
          misinterpret, on the reception of an SRv6-based BGP service route
          update, the part of the SRv6 SID encoded in an MPLS label Label field(s) as
          MPLS label values for MPLS-based services. Implementations
          supporting this specification MUST <bcp14>MUST</bcp14> provide a mechanism to control
          the advertisement of SRv6-based BGP service routes on a per-neighbor
          and per-service basis. The details of deployment designs and
          implementation options are outside the scope of this document.</t>
          <t>Arguments may be generally applicable for SIDs of only specific
          SRv6 Endpoint behaviors Behaviors (e.g., End.DT2M) and therefore End.DT2M); therefore, the Argument
          length MUST AL
          <bcp14>MUST</bcp14> be set to 0 for SIDs where the Argument is not
          applicable. A receiver is unable to validate the applicability of
          arguments for SRv6 Endpoint behaviors Behaviors that are unknown to it and
          hence MUST <bcp14>MUST</bcp14> ignore SRv6 SIDs with arguments (indicated by a non-zero
          argument length)
          AL) with unknown endpoint behaviors. SRv6 Endpoint Behaviors. For SIDs
          corresponding to an endpoint behavior SRv6 Endpoint Behavior that is known, a receiver MUST <bcp14>MUST</bcp14>
          validate that the consistency of the argument length AL with the
          specific endpoint behavior SRv6 Endpoint Behavior definition.</t>
        </section>
      </section>
    </section>
    <section anchor="SIDENCODE" title="Encoding numbered="true" toc="default">
      <name>Encoding SRv6 SID Information"> Information</name>
      <t>The SRv6 Service SID(s) for a BGP Service Prefix are service prefix is carried in the
      SRv6 Services TLVs of the BGP Prefix-SID Attribute.</t> attribute.</t>
      <t>For certain types of BGP Services Services, like L3VPN where a per-VRF SID
      allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID is
      shared across multiple NLRIs NLRIs, thus providing efficient packing. However,
      for certain other types of BGP Services Services, like EVPN VPWS Virtual Private Wire
      Service (VPWS) where a per-PW
      SID allocation is required (i.e., End.DX2 behavior), each NLRI would
      have its own unique SID SID, thereby resulting in inefficient packing.</t>

      <t>To
      <t> To achieve efficient packing, this document allows either 1) the
      encoding of the SRv6 Service SID either as a whole in the SRv6 Services
      TLVs or 2) the encoding of only the common part of the SRv6 SID (e.g.,
      Locator) in the SRv6 Services TLVs and the encoding of the variable
      (e.g., Function or Argument parts) in the existing label fields
      specific to that service encoding.
      This later form of encoding is referred to as the Transposition Scheme Scheme,
      where the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the
      parts of the SRv6 SID and also indicates the offset of the variable part
      along with its length in the SRv6 SID value. The use of the Transposition
      Scheme is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for the specific service encodings that allow it it,
      as described further in Sections <xref target="L3BGP"/> target="L3BGP" format="counter"/> and <xref
      target="EVPNBGP"/>.</t> target="EVPNBGP" format="counter"/>.</t>
      <t>As an example, for the EVPN VPWS service prefix described further in
      <xref target="PEREVI"/>, target="PEREVI" format="default"/>, the Function part of the SRv6 SID is encoded in
      the MPLS Label field of the NLRI NLRI, and the SID value in the SRv6 Services
      TLV carries only the Locator part with the SRv6 SID Structure
      Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of
      Locator Block, Locator Node, and Function parts (Arguments are not
      applicable for the End.DX2 behavior). Transposition Offset indicates the
      bit position position, and Transposition Length indicates the number of bits that
      are being taken out of the SID and put into the label field.</t>
      <t>In yet another example, for the EVPN Ethernet A-D Auto-Discovery (A-D) per Ethernet
      Segment (ES) route described further in <xref target="PERES"/>, target="PERES" format="default"/>, only the
      Argument of the SID needs to be signaled. This Argument part of the SRv6
      SID MAY <bcp14>MAY</bcp14> be transposed in the Ethernet Segment Identifier (ESI) Label
      field of the ESI Label Extended Community extended community, and the SID value in the SRv6
      Services TLV is set to 0 along with the inclusion of the SRv6 SID Structure
      Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of
      Locator Block, Locator Node, Function Function, and Argument parts. The offset and
      length of the Argument part SID value moved to the label field is set in
      transposition offset and length of the SID structure Structure TLV. The receiving
      router is then able to put together the entire SRv6 Service SID (e.g.,
      for the End.DT2M behavior) behavior), placing the label value received in the ESI
      Label field of the Ethernet A-D per ES route into the correct
      transposition offset and length in the SRv6 SID with the End.DT2M
      behavior received for an EVPN Route Type 3 value.</t>
    </section>
    <section anchor="L3BGP" title="BGP based numbered="true" toc="default">
      <name>BGP-Based L3 Service over SRv6"> SRv6</name>
      <t>BGP egress nodes (egress PEs) advertise a set of reachable prefixes.
      Standard BGP update propagation schemes <xref target="RFC4271"/>, target="RFC4271" format="default"/>, which
      may make use of route reflectors <xref target="RFC4456"/>, target="RFC4456" format="default"/>, are used to
      propagate these prefixes. BGP ingress nodes (ingress PEs) receive these
      advertisements and may add the prefix to the RIB in an appropriate
      VRF.</t>
      <t>Egress PEs which supports SRv6 based that support SRv6-based L3 services advertises advertise overlay
      service prefixes along with a Service SID enclosed in an SRv6 L3 Service
      TLV within the BGP Prefix-SID Attribute. attribute. This TLV serves two purposes - --
      first, it indicates that the egress PE supports SRv6 overlay overlay, and the BGP
      ingress PE receiving this route MUST <bcp14>MUST</bcp14> perform IPv6 encapsulation and
      insert an SRH <xref target="RFC8754"/> target="RFC8754" format="default"/> when required; second, it
      indicates the value of the Service SID to be used in the
      encapsulation.</t>

      <t>The
      <t>Thus, the Service SID thus signaled only has local significance at the
      egress PE, where it may be allocated or configured on a per-CE per-Customer-Edge (CE) or
      per-VRF basis. In practice, the SID may encode a cross-connect to a
      specific Address Family address family table (End.DT) or next-hop/interface (End.DX) next hop / interface (End.DX), as
      defined in <xref target="RFC8986"/>.</t> target="RFC8986" format="default"/>.</t>
      <t>The SRv6 Service SID SHOULD <bcp14>SHOULD</bcp14> be routable (refer section 3.3 of to <xref
      target="RFC8986"/>) target="RFC8986" section="3.3" sectionFormat="of" format="default"/>) within the AS Autonomous System (AS) of the egress PE and serves the dual
      purpose of providing reachability between ingress PE and egress PE while
      also encoding the SRv6 Endpoint behavior.</t> Behavior.</t>
      <t>When steering for SRv6 services is based on shortest path forwarding
      (e.g., best-effort best effort or IGP Flexible Algorithm <xref
      target="I-D.ietf-lsr-flex-algo"/>) target="I-D.ietf-lsr-flex-algo" format="default"/>) to the egress PE, the ingress PE
      encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header
      (using H.Encaps or H.Encaps.Red flavors specified in <xref
      target="RFC8986"/>) target="RFC8986" format="default"/>), where the destination address is the SRv6 Service
      SID associated with the related BGP route update. Therefore, the ingress
      PE MUST <bcp14>MUST</bcp14> perform a resolvability check for the SRv6 Service SID before
      considering the received prefix for the BGP best path computation. The
      resolvability is evaluated as per <xref target="RFC4271"/>. target="RFC4271" format="default"/>. If the SRv6
      SID is reachable via more than one forwarding table, local policy is
      used to determine which table to use. The result of an SRv6 Service SID
      resolvability (e.g., when provided via IGP Flexible Algorithm) can be
      ignored if the ingress PE has a local policy that allows an alternate
      steering mechanism to reach the egress PE. The details of such steering
      mechanisms are outside the scope of this document.</t>
      <t>For service over SRv6 core, the egress PE sets the next-hop BGP next hop to one of
      its IPv6 addresses. Such an address MAY <bcp14>MAY</bcp14> be covered by the SRv6 Locator
      from which the SRv6 Service SID is allocated. The next-hop BGP next hop is used for
      tracking the reachability of the egress PE based on existing BGP
      procedures.</t>
      <t>When the BGP route is received at an ingress PE is colored with a
      Color Extended community Community and a valid SRv6 Policy is available, the
      steering for service flows is performed as described in Section 8 of <xref target="I-D.ietf-spring-segment-routing-policy"/>. target="I-D.ietf-spring-segment-routing-policy" section="8" sectionFormat="of" format="default"/>. When the
      ingress PE determines (with the help of the SRv6 SID Structure) that the
      Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of
      the egress PE) in the SR Policy segment list, it MAY <bcp14>MAY</bcp14> exclude that last
      SRv6 SID when steering the service flow. For example, the effective
      segment list of the SRv6 Policy associated with SID list &lt;S1, S2,
      S3&gt; would be &lt;S1, S2, S3-Service-SID&gt;.</t>
      <section anchor="L3BGPVPNv4" title="IPv4 numbered="true" toc="default">
        <name>IPv4 VPN Over over SRv6 Core"> Core</name>
	<t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
        Over
   unicast over IPv6 Core core defined in <xref target="RFC8950"/>.</t>

        <t>Label target="RFC8950" format="default"/>.</t>
        <t>The label field of IPv4-VPN NLRI is encoded as specified in <xref
        target="RFC8277"/> target="RFC8277" format="default"/> with the 20-bit Label Value set to the whole or a
        portion of the Function part of the SRv6 SID when the Transposition
        Scheme of encoding (<xref target="SIDENCODE"/>) target="SIDENCODE" format="default"/>) is used; otherwise,
        it is used and otherwise set to Implicit NULL. When using the Transposition Scheme, the
        Transposition Length MUST <bcp14>MUST</bcp14> be less than or equal to 20 and less than or
        equal to the Function Length.</t>

        <t>SRv6 FL.</t>
        <t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
        SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX4, End.DT4, or
        End.DT46.</t>
      </section>
      <section anchor="L3BGPVPNv6" title="IPv6 numbered="true" toc="default">
        <name>IPv6 VPN Over over SRv6 Core "> Core</name>
        <t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN
        over IPv6 Core is core, as defined in <xref target="RFC4659"/>.</t>

        <t>Label target="RFC4659" format="default"/>.</t>
        <t>The label field of the IPv6-VPN NLRI is encoded as specified in <xref
        target="RFC8277"/> target="RFC8277" format="default"/> with the 20-bit Label Value set to the whole or a
        portion of the Function part of the SRv6 SID when the Transposition
        Scheme of encoding (<xref target="SIDENCODE"/>) target="SIDENCODE" format="default"/>) is used; otherwise,
        it is used and otherwise set to Implicit NULL. When using the Transposition Scheme, the
        Transposition Length MUST <bcp14>MUST</bcp14> be less than or equal to 20 and less than or
        equal to the Function Length.</t>

        <t>SRv6 FL.</t>
        <t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
        SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX6, End.DT6, or
        End.DT46.</t>
      </section>
      <section anchor="L3BGPINTv4" title="Global numbered="true" toc="default">
        <name>Global IPv4 over SRv6 Core"> Core</name>
        <t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over
        IPv6 Core is core, as defined in <xref target="RFC8950"/>.</t> target="RFC8950" format="default"/>.</t>
        <t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
        SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX4, End.DT4, or
        End.DT46.</t>
      </section>
      <section anchor="L3BGPINTv6" title="Global numbered="true" toc="default">
        <name>Global IPv6 over SRv6 Core"> Core</name>
        <t>The MP_REACH_NLRI over SRv6 core is encoded according to <xref
        target="RFC2545"> </xref></t>

        <t>SRv6 target="RFC2545" format="default"> </xref>.</t>
        <t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
        SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX6, End.DT6, or
        End.DT46.</t>
      </section>
    </section>
    <section anchor="EVPNBGP" title="BGP based numbered="true" toc="default">
      <name>BGP-Based Ethernet VPN (EVPN) over SRv6"> SRv6</name>
      <t><xref target="RFC7432"/> target="RFC7432" format="default"/> provides an extendable method of building an
      Ethernet VPN (EVPN)
      EVPN overlay. It primarily focuses on MPLS based EVPNs MPLS-based EVPNs,
      and <xref target="RFC8365"/> target="RFC8365" format="default"/> extends to IP-based EVPN overlays. <xref
      target="RFC7432"/> target="RFC7432" format="default"/> defines Route Types 1, 2, and 3 3, which carry prefixes
      and MPLS Label fields; the Label fields have a specific use for MPLS
      encapsulation of EVPN traffic. Route Type 5 carrying MPLS label
      information (and thus encapsulation information) for an EVPN is defined in
      <xref target="RFC9136"/>. target="RFC9136" format="default"/>. Route Types 6, 7, and 8 are defined in <xref
      target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>.<list style="symbols">
          <t>Ethernet Auto-discovery Route target="RFC9251" format="default"/>.</t>
      <ul spacing="normal">
        <li>Ethernet Auto-Discovery (A-D) route (Route Type 1)</t>

          <t>MAC/IP 1)</li>
        <li>MAC/IP Advertisement Route route (Route Type 2)</t>

          <t>Inclusive 2)</li>
        <li>Inclusive Multicast Ethernet Tag Route route (Route Type 3)</t>

          <t>Ethernet 3)</li>
        <li>Ethernet Segment route (Route Type 4)</t>

          <t>IP prefix 4)</li>
        <li>IP Prefix route (Route Type 5)</t>

          <t>Selective 5)</li>
        <li>Selective Multicast Ethernet Tag route (Route Type 6)</t>

          <t>Multicast 6)</li>
        <li>Multicast Membership Report Synch route (Route Type 7)</t>

          <t>Multicast 7)</li>
        <li>Multicast Leave Synch route (Route Type 8)</t>
        </list></t> 8)</li>
      </ul>
      <t>The specifications for other EVPN Route Types are outside the scope
      of this document.</t>
      <t>To support SRv6 based SRv6-based EVPN overlays, one or more SRv6 Service SIDs
      are advertised with Route Type Types 1, 2, 3, and 5. The SRv6 Service SID(s)
      per Route Type are is advertised in SRv6 L3/L2 Service TLVs within the BGP
      Prefix-SID Attribute. attribute. Signaling of the SRv6 Service SID(s) serves two
      purposes - -- first, it indicates that the BGP egress device supports SRv6
      overlay
      overlay, and the BGP ingress device receiving this route MUST <bcp14>MUST</bcp14> perform
      IPv6 encapsulation and insert an SRH <xref target="RFC8754"/> target="RFC8754" format="default"/> when
      required; second, it indicates the value of the Service SID(s) to be
      used in the encapsulation.</t>
      <t>The SRv6 Service SID SHOULD <bcp14>SHOULD</bcp14> be routable (refer section 3.3 of to <xref
      target="RFC8986"/>) target="RFC8986" section="3.3" sectionFormat="of" format="default"/>) within the AS of the egress PE and serves the dual
      purpose of providing reachability between the ingress PE and egress PE while
      also encoding the SRv6 Endpoint behavior.</t> Behavior.</t>
      <t>When steering for SRv6 services is based on shortest path forwarding
      (e.g., best-effort best effort or IGP Flexible Algorithm <xref
      target="I-D.ietf-lsr-flex-algo"/>) target="I-D.ietf-lsr-flex-algo" format="default"/>) to the egress PE, the ingress PE
      encapsulates the customer Layer 2 Ethernet packet in an outer IPv6
      header (using H.Encaps.L2 or H.Encaps.L2.Red flavors specified in <xref
      target="RFC8986"/>) target="RFC8986" format="default"/>) where the destination address is the SRv6 Service
      SID associated with the related BGP route update. Therefore, the ingress
      PE MUST <bcp14>MUST</bcp14> perform a resolvability check for the SRv6 Service SID before
      considering the received prefix for the BGP best path computation. The
      resolvability is evaluated as per <xref target="RFC4271"/>. target="RFC4271" format="default"/>. If the SRv6
      SID is reachable via more than one forwarding table, local policy is
      used to determine which table to use. The result of an SRv6 Service SID
      resolvability (e.g., when provided via IGP Flexible Algorithm) can be
      ignored if the ingress PE has a local policy that allows an alternate
      steering mechanism to reach the egress PE. The details of such steering
      mechanisms are outside the scope of this document.</t>
      <t>For service over SRv6 core, the egress PE sets the next-hop BGP next hop to one
      of its IPv6 addresses. Such an address MAY <bcp14>MAY</bcp14> be covered by
      the SRv6 Locator
      from which the SRv6 Service SID is allocated. The next-hop BGP next hop is used for
      tracking the reachability of the egress PE based on existing BGP
      procedures.</t>
      <t>When the BGP route is received at an ingress PE is colored with a
      Color Extended community Community and a valid SRv6 Policy is available, the
      steering for service flows is performed as described in Section 8 of <xref target="I-D.ietf-spring-segment-routing-policy"/>. target="I-D.ietf-spring-segment-routing-policy" section="8" sectionFormat="of" format="default"/>. When the
      ingress PE determines (with the help of the SRv6 SID Structure) that the
      Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of
      the egress PE) in the SR Policy segment list, it MAY <bcp14>MAY</bcp14> exclude that last
      SRv6 SID when steering the service flow. For example, the effective
      segment list of the SRv6 Policy associated with SID list &lt;S1, S2,
      S3&gt; would be &lt;S1, S2, S3-Service-SID&gt;.</t>
      <section anchor="RT1"
               title="Ethernet Auto-discovery numbered="true" toc="default">
        <name>Ethernet Auto-Discovery Route over SRv6 Core "> Core</name>
        <t>Ethernet Auto-Discovery (A-D) A-D routes are Route Type 1 1, as defined in
        <xref target="RFC7432"/> target="RFC7432" format="default"/>, and may be used to achieve
	split-horizon filtering, fast convergence, and aliasing.
        EVPN Route Type 1 is also used in EVPN- VPWS EVPN-VPWS as well as in EVPN flexible cross-connect; EVPN-flexible
	cross-connect, mainly
        used to advertise point-to-point services ID.</t> service IDs.</t>
        <t>As a reminder, EVPN Route Type 1 is encoded as follows:</t>
        <figure anchor="EVPNRT1" title="EVPN anchor="EVPNRT1">
          <name>EVPN Route Type 1">
          <artwork><![CDATA[
                +---------------------------------------+ 1</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                +-----------------------------------------+
                |  RD (8 octets)                          |
                +---------------------------------------+
                |Ethernet
                +-----------------------------------------+
                |  Ethernet Segment Identifier (10 octets)|
                +---------------------------------------+
                +-----------------------------------------+
                |  Ethernet Tag ID (4 octets)             |
                +---------------------------------------+
                +-----------------------------------------+
                |  MPLS label (3 octets)                  |
                +---------------------------------------+
                +-----------------------------------------+
]]></artwork>
        </figure>
        <section anchor="PERES" title="Ethernet numbered="true" toc="default">
          <name>Ethernet A-D per ES Route"> Route</name>
          <t>Ethernet A-D per ES route NLRI encoding over SRv6 core is as per
          <xref target="RFC7432"/>.</t> target="RFC7432" format="default"/>.</t>
          <t>The 24-bit ESI label Label field of the ESI label Label extended community
          carries the whole or a portion of the Argument part of the SRv6 SID
          when the ESI filtering approach is used along with the Transposition
          Scheme of encoding (<xref target="SIDENCODE"/>) and otherwise target="SIDENCODE" format="default"/>);
	  otherwise, it is set to Implicit NULL value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high
          order 20 bits (e.g., as 0x000030 in the case of Implicit NULL). 24 bits. When
          using the Transposition Scheme, the Transposition Length MUST <bcp14>MUST</bcp14> be
          less than or equal to 24 and less than or equal to the Argument
          Length.</t> AL.</t>
          <t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
          Prefix-SID attribute is advertised along with the A-D route. The
          SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be End.DT2M. When the ESI filtering
          approach is used, the Service SID is used to signal the Arg.FE2 SID
          Argument for applicable End.DT2M behavior <xref target="RFC8986"/>. target="RFC8986" format="default"/>.
          When the local-bias approach <xref target="RFC8365"/> target="RFC8365" format="default"/> is used, the
          Service SID MAY <bcp14>MAY</bcp14> be of value 0.</t>
        </section>
        <section anchor="PEREVI" title="Ethernet numbered="true" toc="default">
          <name>Ethernet A-D per EVI Route"> Route</name>
          <t>Ethernet A-D per EVI EVPN Instance (EVI) route NLRI encoding over SRv6 core is
          similar to what is described in <xref target="RFC7432"/> target="RFC7432" format="default"/> and <xref target="RFC8214"/> target="RFC8214" format="default"/>
          with the following change:</t>

          <t><list style="symbols">
              <t>MPLS Label:
          <dl newline="true" spacing="normal">
            <dt>MPLS Label:</dt>
	    <dd>The 24-bit field carries the whole or a portion of
              the Function part of the SRv6 SID when the Transposition Scheme
              of encoding (<xref target="SIDENCODE"/>) target="SIDENCODE" format="default"/>) is used;
	      otherwise,  it is used and otherwise set to Implicit NULL value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high order 20 bits (e.g., as 0x000030 in the case of
              Implicit NULL). 24 bits. When using the Transposition Scheme, the
              Transposition Length MUST <bcp14>MUST</bcp14> be less than or equal to 24 and less
              than or equal to the Function Length.</t>
            </list></t> FL.</dd>
          </dl>
          <t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
          Prefix-SID attribute is advertised along with the A-D route. The
          SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX2, End.DX2V, or
          End.DT2U.</t>
        </section>
      </section>
      <section anchor="RT2" title="MAC/IP numbered="true" toc="default">
        <name>MAC/IP Advertisement Route over SRv6 Core"> Core</name>
        <t>EVPN Route Type 2 is used to advertise unicast traffic MAC+IP Media Access Control (MAC)
	+ IP address reachability through MP-BGP to all other PEs in a given EVPN
        instance.</t>
        <t>As a reminder, EVPN Route Type 2 is encoded as follows:</t>
        <figure anchor="EVPNRT2" title="EVPN anchor="EVPNRT2">
          <name>EVPN Route Type 2">
          <artwork><![CDATA[
                +---------------------------------------+ 2</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                +-----------------------------------------+
                |  RD (8 octets)                          |
                +---------------------------------------+
                |Ethernet
                +-----------------------------------------+
                |  Ethernet Segment Identifier (10 octets)|
                +---------------------------------------+
                +-----------------------------------------+
                |  Ethernet Tag ID (4 octets)             |
                +---------------------------------------+
                +-----------------------------------------+
                |  MAC Address Length (1 octet)           |
                +---------------------------------------+
                +-----------------------------------------+
                |  MAC Address (6 octets)                 |
                +---------------------------------------+
                +-----------------------------------------+
                |  IP Address Length (1 octet)            |
                +---------------------------------------+
                +-----------------------------------------+
                |  IP Address (0, 4, or 16 octets)        |
                +---------------------------------------+
                +-----------------------------------------+
                |  MPLS Label1 (3 octets)                 |
                +---------------------------------------+
                +-----------------------------------------+
                |  MPLS Label2 (0 or 3 octets)            |
                +---------------------------------------+
                +-----------------------------------------+
]]></artwork>
        </figure>
        <t>NLRI encoding over SRv6 core is similar to what is described in <xref target="RFC7432"/> target="RFC7432"
	format="default"/> with the following changes:</t>

        <t><list style="symbols">
            <t>MPLS Label1: Is
        <dl newline="true" spacing="normal">
          <dt>MPLS Label1:</dt>
	  <dd>This is associated with the SRv6 L2 Service TLV. This
            24-bit field carries the whole or a portion of the Function part
            of the SRv6 SID when the Transposition Scheme of encoding (<xref
            target="SIDENCODE"/>) target="SIDENCODE" format="default"/>) is used; otherwise, it is used and otherwise set to Implicit NULL
            value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high order 20 bits
            (e.g., as 0x000030 in the case of Implicit NULL). 24 bits. When using the
            Transposition Scheme, the Transposition Length MUST <bcp14>MUST</bcp14> be less than
            or equal to 24 and less than or equal to the Function Length.</t>

            <t>MPLS Label2: Is FL.</dd>
            <dt>MPLS Label2:</dt>
	    <dd>This is associated with the SRv6 L3 Service TLV. This
            24-bit field carries the whole or a portion of the Function part
            of the SRv6 SID when the Transposition Scheme of encoding (<xref
            target="SIDENCODE"/>) target="SIDENCODE" format="default"/>) is used; otherwise, it is used and otherwise set to Implicit NULL
            value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high order 20 bits
            (e.g., as 0x000030 in the case of Implicit NULL). 24 bits. When using the
            Transposition Scheme, the Transposition Length MUST <bcp14>MUST</bcp14> be less than
            or equal to 24 and less than or equal to the Function Length.</t>
          </list></t> FL.</dd>
        </dl>
        <t>Service SIDs enclosed in the SRv6 L2 Service TLV and optionally in the SRv6
        L3 Service TLV within the BGP Prefix-SID attribute is are advertised along
        with the MAC/IP Advertisement route.</t>
        <t>Described below are different types of Route Type 2
        advertisements.</t>
        <section title="MAC/IP numbered="true" toc="default">
          <name>MAC/IP Advertisement Route with MAC Only">
          <t><list style="symbols">
              <t>MPLS Label1: Is Only</name>
          <dl newline="true" spacing="normal">
            <dt>MPLS Label1:</dt>
	    <dd>This is associated with the SRv6 L2 Service TLV. This
              24-bit field carries the whole or a portion of the Function part
              of the SRv6 SID when the Transposition Scheme of encoding (<xref
              target="SIDENCODE"/>) target="SIDENCODE" format="default"/>) is used; otherwise, it is used and otherwise set to Implicit NULL
              value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high order 20
              bits (e.g., as 0x000030 in the case of Implicit NULL). 24 bits. When
              using the Transposition Scheme, the Transposition Length MUST <bcp14>MUST</bcp14> be
              less than or equal to 24 and less than or equal to the Function
              Length.</t>
            </list></t> FL.</dd>
          </dl>
          <t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
          Prefix-SID attribute is advertised along with the route. The SRv6
          Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX2, End.DX2 or End.DT2U.</t>
        </section>
        <section title="MAC/IP numbered="true" toc="default">
          <name>MAC/IP Advertisement Route with MAC+IP">
          <t><list style="symbols">
              <t>MPLS Label1: Is MAC+IP</name>
          <dl newline="true" spacing="normal">
            <dt>MPLS Label1:</dt>
	    <dd>This is associated with the SRv6 L2 Service TLV. This
              24-bit field carries the whole or a portion of the Function part
              of the SRv6 SID when the Transposition Scheme of encoding (<xref
              target="SIDENCODE"/>)
	      target="SIDENCODE" format="default"/>) is used; otherwise, it is used and otherwise set to Implicit NULL
              value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high order 20
              bits (e.g., as 0x000030 in the case of Implicit NULL). 24 bits. When
              using the Transposition Scheme, the Transposition Length MUST <bcp14>MUST</bcp14> be
              less than or equal to 24 and less than or equal to the Function
              Length.</t>

              <t>MPLS Label2: Is FL.</dd>
              <dt>MPLS Label2:</dt>
	      <dd>This is associated with the SRv6 L3 Service TLV. This
              24-bit field carries the whole or a portion of the Function part
              of the SRv6 SID when the Transposition Scheme of encoding (<xref
              target="SIDENCODE"/>)
	      target="SIDENCODE" format="default"/>) is used; otherwise, it is used and otherwise set to Implicit NULL
              value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high order 20
              bits (e.g., as 0x000030 in the case of Implicit NULL). 24 bits. When
              using the Transposition Scheme, the Transposition Length MUST <bcp14>MUST</bcp14> be
              less than or equal to 24 and less than or equal to the Function
              Length.</t>
            </list></t> FL.</dd>
          </dl>
          <t>An L2 Service SID enclosed in an SRv6 L2 Service TLV within the
          BGP Prefix-SID attribute is advertised along with the route. In
          addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV
          within the BGP Prefix-SID attribute MAY <bcp14>MAY</bcp14> also be advertised along
          with the route. The SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these:
          for the L2 Service SID - End.DX2, End.DT2U; SID, End.DX2 or End.DT2U and for the L3 Service SID - SID,
          End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6.</t>
        </section>
      </section>
      <section anchor="RT3"
               title="Inclusive numbered="true" toc="default">
        <name>Inclusive Multicast Ethernet Tag Route over SRv6 Core"> Core</name>
        <t>EVPN Route Type 3 is used to advertise multicast traffic
        reachability information through MP-BGP to all other PEs in a given
        EVPN instance.</t>
        <t>As a reminder, EVPN Route Type 3 is encoded as follows:</t>

        <t><figure anchor="EVPNRT3" title="EVPN
        <figure anchor="EVPNRT3">
          <name>EVPN Route Type 3">
            <artwork><![CDATA[ 3</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
               +---------------------------------------+
               |  RD (8 octets)                        |
               +---------------------------------------+
               |  Ethernet Tag ID (4 octets)           |
               +---------------------------------------+
               |  IP Address Length (1 octet)          |
               +---------------------------------------+
               |  Originating Router's IP Address      |
               |          (4 or 16 octets)             |
               +---------------------------------------+
]]></artwork>
          </figure></t>
        </figure>
        <t>NLRI encoding over SRv6 core is similar to what is described in <xref
        target="RFC7432"/>.</t>

        <t>PMSI target="RFC7432" format="default"/>.</t>
        <t>The P-Multicast Service Interface (PMSI) Tunnel Attribute <xref target="RFC6514"/> target="RFC6514" format="default"/> is used to identify
        the P-tunnel Provider tunnel (P-tunnel) used for sending broadcast, unknown unicast, Broadcast, Unknown Unicast, or multicast Multicast
        (BUM) traffic. The format of the PMSI Tunnel Attribute is encoded as
        follows over SRv6 Core: core: </t>
        <figure anchor="PMSITA"
            title="PMSI anchor="PMSITA">
          <name>PMSI Tunnel Attribute">
            <artwork><![CDATA[ Attribute</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
	       +---------------------------------------+
               |  Flag (1 octet)                       |
               +---------------------------------------+
               |  Tunnel Type (1 octet)                |
               +---------------------------------------+
               |  MPLS label (3 octet) octets)                 |
               +---------------------------------------+
               |  Tunnel Identifier (variable)         |
               +---------------------------------------+
]]></artwork>
          </figure><list style="symbols">
            <t>Flag: zero
        </figure>
        <dl newline="true" spacing="normal">
          <dt>Flag:</dt>
	  <dd>This field has a value of 0, as defined per <xref target="RFC7432"/></t>

            <t>Tunnel Type: target="RFC7432"
	  format="default"/>.</dd>
          <dt>Tunnel Type:</dt>
	  <dd>This field is defined per <xref target="RFC6514"/></t>

            <t>MPLS label: This target="RFC6514" format="default"/>.</dd>
          <dt>MPLS label:</dt>
	  <dd>This 24-bit field carries the whole or a portion of
            the Function part of the SRv6 SID when ingress replication is used
            and the Transposition Scheme of encoding (<xref
            target="SIDENCODE"/>) target="SIDENCODE"
	    format="default"/>) is used and used; otherwise, it is set as defined
            in <xref target="RFC6514"/>. target="RFC6514" format="default"/>. When using the Transposition Scheme,
            the Transposition Length MUST <bcp14>MUST</bcp14> be less than or equal to 24 and less
            than or equal to the Function Length.</t>

            <t>Tunnel Identifier: FL.</dd>
            <dt>Tunnel Identifier:</dt>
	    <dd>This field is the IP address of egress PE</t>
          </list>A PE.</dd>
        </dl>
        <t>A Service SID enclosed in an SRv6 L2 Service TLV within the
        BGP Prefix-SID attribute is advertised along with the route. The SRv6
        Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be End.DT2M.<list style="symbols">
            <t>When End.DT2M.</t>
        <ul spacing="normal">

          <li>When ESI-based filtering is used for Multi-Homing multihoming or E-Tree Ethernet Tree (E-Tree)
            procedures, the ESI Filtering Argument (the Arg.FE2 notation
            introduced in <xref target="RFC8986"/>) target="RFC8986" format="default"/>) of the Service SID carried
            along with EVPN Route Type 1 route SHOULD <bcp14>SHOULD</bcp14> be merged with the
            applicable End.DT2M SID of Route Type 3 route advertised by the remote PE by
            doing a bit-wise bitwise logical-OR operation to create a single SID on
            the ingress PE. Details of split-horizon split-horizon, ESI-based filtering
            mechanisms for multihoming are described in <xref
            target="RFC7432"/>. target="RFC7432" format="default"/>. Details of filtering mechanisms for
            Leaf-originated BUM traffic in EVPN E-Tree services are provided
            in <xref target="RFC8317"/>.</t>

            <t>When &ldquo;local-bias&rdquo; target="RFC8317" format="default"/>.</li>
          <li>When "local-bias" is used as the Multi-Homing multihoming
            split-horizon method, the ESI Filtering Argument SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
            merged with the corresponding End.DT2M SID on the ingress PE.
            Details of the &ldquo;local-bias&rdquo; local-bias procedures are described
            in <xref target="RFC8365"/>.</t>
          </list></t> target="RFC8365" format="default"/>.</li>
        </ul>
        <t>Usage of multicast trees as P-tunnels is outside the scope of this
        document.</t>
      </section>
      <section anchor="RT4" title="Ethernet numbered="true" toc="default">
        <name>Ethernet Segment Route over SRv6 Core"> Core</name>
        <t>As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4)
        is encoded as follows: </t>
        <figure anchor="EVPNRT4"
            title="EVPN anchor="EVPNRT4">
          <name>EVPN Route Type 4">
            <artwork><![CDATA[ 4</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
               +---------------------------------------+
               |  RD (8 octets)                        |
               +---------------------------------------+
               |  Ethernet Tag ID (4 octets)           |
               +---------------------------------------+
               |  IP Address Length (1 octet)          |
               +---------------------------------------+
               |  Originating Router's IP Address      |
               |          (4 or 16 octets)             |
               +---------------------------------------+
]]></artwork>
          </figure></t>
        </figure>
        <t>NLRI encoding over SRv6 core is similar to what is described in <xref
        target="RFC7432"/>.</t> target="RFC7432" format="default"/>.</t>
        <t>SRv6 Service TLVs within the BGP Prefix-SID attribute are not
        advertised along with this route. The processing of the route has not
        changed - -- it remains as described in <xref target="RFC7432"/>.</t> target="RFC7432" format="default"/>.</t>
      </section>
      <section anchor="RT5" title="IP numbered="true" toc="default">
        <name>IP Prefix Route over SRv6 Core"> Core</name>
        <t>EVPN Route Type 5 is used to advertise IP address reachability
        through MP-BGP to all other PEs in a given EVPN instance. The IP
        address may include a host IP prefix or any specific subnet.</t>
        <t>As a reminder, EVPN Route Type 5 is encoded as follows: </t>
        <figure
            anchor="EVPNRT5" title="EVPN anchor="EVPNRT5">
          <name>EVPN Route Type 5">
            <artwork><![CDATA[
               +---------------------------------------+ 5</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
               +-----------------------------------------+
               |  RD (8 octets)                          |
               +---------------------------------------+
               |Ethernet
               +-----------------------------------------+
               |  Ethernet Segment Identifier (10 octets)|
               +---------------------------------------+
               +-----------------------------------------+
               |  Ethernet Tag ID (4 octets)             |
               +---------------------------------------+
               +-----------------------------------------+
               |  IP Prefix Length (1 octet)             |
               +---------------------------------------+
               +-----------------------------------------+
               |  IP Prefix (4 or 16 octets)             |
               +---------------------------------------+
               +-----------------------------------------+
               |  GW IP Address (4 or 16 octets)         |
               +---------------------------------------+
               +-----------------------------------------+
               |  MPLS Label (3 octets)                  |
               +---------------------------------------+
               +-----------------------------------------+
]]></artwork>
          </figure></t>
        </figure>
        <t>NLRI encoding over SRv6 core is similar to what is described in <xref target="RFC9136"/> target="RFC9136" format="default"/>
        with the following change:</t>

        <t><list style="symbols">
            <t>MPLS Label: This
        <dl newline="true" spacing="normal">
          <dt>MPLS Label:</dt>
	  <dd>This 24-bit field carries the whole or a portion of
            the Function part of the SRv6 SID when the Transposition Scheme of
            encoding (<xref target="SIDENCODE"/>) target="SIDENCODE" format="default"/>) is used;
	    otherwise, it is used and otherwise set to Implicit NULL value. in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the high
            order 20 bits (e.g., as 0x000030 in the case of Implicit NULL). 24 bits.
            When using the Transposition Scheme, the Transposition Length MUST <bcp14>MUST</bcp14>
            be less than or equal to 24 and less than or equal to the Function
            Length.</t>
          </list></t>

        <t>SRv6 FL.</dd>
        </dl>
        <t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
        SRv6 Endpoint behavior SHOULD Behavior <bcp14>SHOULD</bcp14> be one of these: End.DT4, End.DT6,
        End.DT46, End.DX4, or End.DX6.</t>
      </section>
      <section anchor="RT678"
               title="EVPN numbered="true" toc="default">
        <name>EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6 Core"> Core</name>
        <t>These routes do not require the advertisement of SRv6 Service TLVs
        along with them. Similar to EVPN Route Type 4, the BGP Nexthop next hop is
        equal to the IPv6 address of egress PE.</t>
      </section>
    </section>
    <section anchor="IMPL" title="Implementation Status">
      <t>[Note to RFC Editor: This section needs to be removed before
      publication as RFC.]</t>

      <t>The <xref target="I-D.matsushima-spring-srv6-deployment-status"/>
      describes the current deployment and implementation status of SRv6 which
      also includes the BGP services over SRv6 as specified in this
      document.</t>
    </section>

    <section anchor="ERROR" title="Error Handling"> numbered="true" toc="default">
      <name>Error Handling</name>
      <t>In case of any errors encountered while processing SRv6 Service TLVs,
      the details of the error SHOULD <bcp14>SHOULD</bcp14> be logged for further analysis.</t>
      <t>If multiple instances of the SRv6 L3 Service TLV are encountered, all but
      the first instance MUST <bcp14>MUST</bcp14> be ignored.</t>
      <t>If multiple instances of the SRv6 L2 Service TLV are encountered, all but
      the first instance MUST <bcp14>MUST</bcp14> be ignored.</t>
      <t>An SRv6 Service TLV is considered malformed in the following cases:
      <list style="symbols">
          <t>the cases:</t>
      <ul spacing="normal">
        <li>The TLV Length is less than 1</t>

          <t>the 1.</li>
        <li>The TLV Length is inconsistent with the length of the BGP Prefix-SID
          attribute</t>

          <t>at
          attribute.</li>
        <li>At least one of the constituent Sub-TLVs is malformed</t>
        </list></t> malformed.</li>
      </ul>
      <t>An SRv6 Service Sub-TLV is considered malformed in the following
      cases: <list style="symbols">
          <t>the
      case:</t>
      <ul spacing="normal">
        <li>The Sub-TLV Length is inconsistent with the length of the
          enclosing SRv6 Service TLV</t>
        </list></t> TLV.</li>
      </ul>
      <t>An SRv6 SID Information Sub-TLV is considered malformed in the
      following cases:<list>
          <t><list style="symbols">
              <t>the cases:</t>
          <ul spacing="normal">
            <li>The Sub-TLV Length is less than 21</t>

              <t>the 21.</li>
            <li>The Sub-TLV Length is inconsistent with the length of the
              enclosing SRv6 Service TLV</t>

              <t>at TLV.</li>
            <li>At least one of the constituent Sub-Sub-TLVs is malformed</t>
            </list></t>
        </list></t> malformed.</li>
          </ul>
      <t>An SRv6 Service Data Sub-Sub-TLV is considered malformed in the
      following cases:</t>

      <t><list style="symbols">
          <t>the case:</t>
      <ul spacing="normal">
        <li>The Sub-Sub-TLV Length is inconsistent with the length of the
          enclosing SRv6 service Sub-TLV</t>
        </list></t> Sub-TLV.</li>
      </ul>
      <t>Any TLV or Sub-TLV TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
      its Type is unrecognized.</t>
      <t>Any TLV or Sub-TLV TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
      of failing any semantic validation of its Value field.</t>

      <t>SRv6
      <t>The SRv6 overlay service requires the Service SID for forwarding. The
      treat-as-withdraw action <xref target="RFC7606"/> MUST target="RFC7606" format="default"/> <bcp14>MUST</bcp14> be performed when
      at least one malformed SRV6 SRv6 Service TLV is present in the BGP Prefix-SID
      attribute.</t>

      <t>SRv6
      <t>The SRv6 SID value in the SRv6 SID Information Sub-TLV is invalid when the SID
      Structure Sub-Sub-TLV transposition length is greater than the number of
      bits of the label field or if any of the conditions for the fields of
      the sub-sub-TLV Sub-Sub-TLV, as specified in <xref target="SRv6-SID-STRUCTURE"/> target="SRv6-SID-STRUCTURE" format="default"/>, is
      not met. The transposition offset and length MUST <bcp14>MUST</bcp14> be 0 when the
      Sub-Sub-TLV is advertised along with routes where transposition scheme the Transposition Scheme
      is not applicable (e.g., for Global global IPv6 Service service <xref
      target="RFC2545"/> target="RFC2545" format="default"/> where there is no label field). The path having any such
      Prefix-SID Attribute attribute without any valid SRv6 SID information MUST <bcp14>MUST</bcp14> be
      considered ineligible during the selection of the best path for the
      corresponding prefix.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="BGP numbered="true" toc="default">
    <name>BGP Prefix-SID TLV Types Registry"> Registry</name>
        <t>This document introduces two new TLV Types of the BGP Prefix-SID
        attribute. IANA has assigned Type values in the registry "BGP
        Prefix-SID TLV Types" subregistry as follows: <figure </t>
        <table anchor="IANAPFXSIDTYPES"
            title="BGP align="center">
          <name>BGP Prefix-SID TLV Types">
            <artwork><![CDATA[    Value     Type                    Reference
    --------------------------------------------
    4       Deprecated              <this document>
    5       SRv6 Types Subregistry</name>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>Type</th>
              <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>4</td>
	      <td>Deprecated</td>
              <td>RFC 9252</td>
	    </tr>
	    <tr>
	      <td>5</td>
	      <td>SRv6 L3 Service TLV     <this document>
    6       SRv6 TLV</td>
	      <td>RFC 9252</td>
	    </tr>
	    <tr>
	      <td>6</td>
	      <td>SRv6 L2 Service TLV     <this document>]]></artwork>
          </figure></t>

        <t>The value TLV</td>
	      <td>RFC 9252</td>
	    </tr>
	  </tbody>
        </table>
        <t>Value 4 previously corresponded to the SRv6-VPN SID TLV, which
        was specified in previous earlier draft versions of this document and used by early
        implementations of this specification. It was deprecated and replaced
        by the SRv6 L3 Service and SRv6 L2 Service TLVs.</t>
      </section>
      <section title="SRv6 numbered="true" toc="default">
        <name>SRv6 Service Sub-TLV Types Registry"> Registry</name>
        <t>IANA is requested to create has created and maintain now maintains a new registry subregistry called
        "SRv6 Service Sub-TLV Types" under the "Border Gateway Protocol (BGP)
        Parameters" registry. The allocation policy registration procedures, per <xref target="RFC8126"/>, for this registry is:
        <figure subregistry are according to <xref target="IANASRV6SVCTYPESAP"/>.
        </t>
        <table anchor="IANASRV6SVCTYPESAP"
            title="SRv6 align="center">
          <name>SRv6 Service Sub-TLV Types Allocation Policy">
            <artwork><![CDATA[   0 : Reserved
   1-127 : IETF Review
   128-254 : First Subregistry Registration Procedures</name>
	  <thead>
	    <tr>
	      <th>Range</th>
	      <th>Registration Procedures</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>1-127</td>
	      <td>IETF Review</td>
	    </tr>
	    <tr>
	      <td>128-254</td>
	      <td>First Come First Served
   255 : Reserved]]></artwork>
          </figure></t>

        <t>The following Served</td>
	    </tr>
	    <tr>
	      <td>255</td>
	      <td>IETF Review</td>
	    </tr>
	  </tbody>
	</table>
        <t>IANA has populated this subregistry as follows. Note that the SRv6 SID Information Sub-TLV Type
	is defined in this document: <figure </t>
        <table anchor="IANASRV6DATATYPES" title="SRv6 align="center">
          <name>SRv6 Service Sub-TLV Types">
            <artwork><![CDATA[   Value     Type                            Reference
    ----------------------------------------------------
    1         SRv6 Types Subregistry Initial Contents</name>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>Type</th>
              <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>0</td>
              <td>Reserved</td>
	      <td>RFC 9252</td>
	    </tr>
	    <tr>
	      <td>1</td>
              <td>SRv6 SID Information Sub-TLV    <this document>]]></artwork>
          </figure></t> Sub-TLV</td>
	      <td>RFC 9252</td>
	    </tr>
            <tr>
	      <td>255</td>
              <td>Reserved</td>
	      <td>RFC 9252</td>
	    </tr>
	  </tbody>
	</table>
      </section>
      <section title="SRv6 numbered="true" toc="default">
        <name>SRv6 Service Data Sub-Sub-TLV Types Registry"> Registry</name>
        <t>IANA is requested to create has created and maintain now maintains a new registry subregistry called
        "SRv6 Service Data Sub-Sub-TLV Types" under the "Border Gateway
        Protocol (BGP) Parameters" registry. The allocation policy registration procedures for this
        registry is: <figure
        subregistry are according to <xref target="IANASRV6DATASSTYPESAP"/>. </t>
        <table anchor="IANASRV6DATASSTYPESAP"
            title="SRv6 align="center">
          <name>SRv6 Service Data Sub-Sub-TLV Types Allocation Policy">
            <artwork><![CDATA[   0 : Reserved
   1-127 : IETF Review
   128-254 : First Subregistry Registration Procedures</name>
	  <thead>
	    <tr>
	      <th>Range</th>
	      <th>Registration Procedure</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>1-127</td>
	      <td>IETF Review</td>
	    </tr>
	    <tr>
	      <td>128-254</td>
	      <td>First Come First Served
   255 : Reserved]]></artwork>
          </figure></t> Served</td>
	    </tr>
	    <tr>
	      <td>255</td>
	      <td>IETF Review</td>
	    </tr>
	  </tbody>
	</table>
        <t>The following Sub-Sub-TLV Type is defined in this document: <figure </t>
        <table anchor="IANASRV6DATASSTYPES"
            title="SRv6 align="center">
          <name>SRv6 Service Data Sub-Sub-TLV Types">
            <artwork><![CDATA[   Value     Type                              Reference
    ----------------------------------------------------
    1         SRv6 Types Subregistry Initial Contents</name>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>Type</th>
              <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	      <tr>
	      <td>0</td>
              <td>Reserved</td>
	      <td>RFC 9252</td>
	    </tr>
	    <tr>
	      <td>1</td>
              <td>SRv6 SID Structure Sub-Sub-TLV    <this document>]]></artwork>
          </figure></t> Sub-Sub-TLV</td>
	      <td>RFC 9252</td>
	    </tr>
	    <tr>
	      <td>255</td>
              <td>Reserved</td>
	      <td>RFC 9252</td>
	    </tr>
	  </tbody>
        </table>
      </section>
      <section title="BGP numbered="true" toc="default">
        <name>BGP SRv6 Service SID Flags Registry"> Registry</name>
        <t>IANA is requested to create has created and maintain now maintains a new registry subregistry called "BGP
        SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP)
        Parameters" registry. The allocation policy registration procedure for this registry subregistry is IETF
        Review
        Review, and all 8 bit 8-bit positions of the flags are currently
        unassigned.</t>
      </section>
      <section title="Subsequent Address Family Identifiers (SAFI) Parameters Registry"> numbered="true" toc="default">
        <name>SAFI Values Registry</name>
        <t>IANA is requested to add has added this document as a reference for value 128
   ("MPLS-labeled VPN address") in the "SAFI Values" subregistry
   under the "Subsequent Address Family Identifiers
   (SAFI) Parameters" registry.</t>
      </section>
    </section>
    <section anchor="SEC" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document specifies extensions to the BGP protocol for the signaling
      of services for SRv6. These specifications leverage existing BGP
      protocol mechanisms for the signaling of various types of services. It
      also builds upon existing elements of the SR architecture (more
      specifically
      specifically, SRv6). As such, this section largely provides pointers (as
      a reminder) to the security considerations of those existing
      specifications while also covering certain certain, newer security aspects for
      the specifications newly introduced by this document.</t>
      <section anchor="SECSESS" title="BGP Session numbered="true" toc="default">
        <name>Considerations Related Considerations"> to BGP Sessions</name>
        <t>Techniques related to authentication of BGP sessions for securing
        messages between BGP peers peers, as discussed in the BGP specification <xref
        target="RFC4271"/> and, target="RFC4271" format="default"/> and in the security analysis for BGP <xref
        target="RFC4272"/> target="RFC4272" format="default"/>, apply. The discussion of the use of the TCP
        Authentication option Option to protect BGP sessions is found in <xref
        target="RFC5925"/>, target="RFC5925" format="default"/>, while <xref target="RFC6952"/> target="RFC6952" format="default"/> includes an
        analysis of BGP keying and authentication issues. This document does
        not introduce any additional BGP session security considerations.</t>
      </section>
      <section anchor="SECSVC" title="BGP Services numbered="true" toc="default">
        <name>Considerations Related Considerations"> to BGP Services</name>
        <t>This document does not introduce new services or BGP NLRI types but
        extends the signaling of existing ones for SRv6. Therefore, the
        security considerations for the respective BGP services services, such as <xref
        target="RFC8950">BGP target="RFC8950" format="default">BGP IPv4 over IPv6 NH</xref>, <xref
        target="RFC4659">BGP target="RFC4659" format="default">BGP IPv6 L3VPN</xref>, <xref target="RFC2545">BGP target="RFC2545" format="default">BGP
        IPv6</xref>, <xref target="RFC7432">BGP EVPN</xref> target="RFC7432" format="default">BGP EVPN</xref>, and <xref
        target="RFC9136">IP EVPN</xref> target="RFC9136" format="default">IP EVPN</xref>, apply as discussed in their respective
        documents.
	<xref target="RFC8669"/> target="RFC8669" format="default"/> discusses mechanisms to prevent
        the leaking of the BGP Prefix-SID attribute, that which carries SR information,
        outside the SR domain.</t>
        <t>As a reminder, several of the BGP services (i.e., the AFI/SAFI used
        for their signaling) were initially introduced for one encapsulation
        mechanism and later extended for others others, e.g., EVPN MPLS <xref
        target="RFC7432"/> target="RFC7432" format="default"/> was extended for VXLAN/NVGRE Virtual eXtensible Local Area Network (VXLAN) encapsulation and Network Virtualization Using Generic Routing Encapsulation (NVGRE) <xref
        target="RFC8365"/>. target="RFC8365" format="default"/>. <xref target="RFC9012"/> target="RFC9012" format="default"/> enables the use of
        various IP encapsulation mechanisms along with different BGP SAFIs for
        their respective services. The existing filtering mechanisms for
        preventing the leak of the encapsulation information (carried in BGP
        attributes) and to prevent preventing the advertisement of prefixes from the
        provider's internal address space (especially the SRv6 Block Block, as
        discussed in <xref target="RFC8986"/>) target="RFC8986" format="default"/>) to external peers (or into the
        Internet) also apply in the case of SRv6.</t>
        <t>Specific to SRv6, a misconfig misconfiguration or error in the above mentioned BGP
        filtering mechanisms mentioned above may result in exposing information information, such as SRv6
        Service SIDs to external peers or other unauthorized entities.
        However, an attempt to exploit this information or to raise an attack
        by injecting packets into the network (e.g. (e.g., customer networks in case
        of VPN services) is mitigated by the existing SRv6 data plane security
        mechanisms
        mechanisms, as described in the next section.</t>
      </section>
      <section anchor="SECSRV6"
               title="SR numbered="true" toc="default">
        <name>Considerations Related to SR over IPv6 Data Plane Related Considerations"> Plane</name>
        <t>This section provides a brief reminder and an overview of the
        security considerations related to SRv6 with pointers to existing
        specifications. This document introduces no new security
        considerations of its own from the SRv6 data plane perspective.</t>
        <t>SRv6 operates within a trusted SR domain. The data packets
        corresponding to service flows between PE routers are encapsulated
        (using SRv6 SIDs advertised via BGP) and carried within this trusted
        SR domain (e.g., within a single AS or between multiple ASes within a
        single provider network).</t>
        <t>The security considerations of the Segment Routing SR architecture are
        covered by <xref target="RFC8402"/>. target="RFC8402" format="default"/>. More detailed security
        considerations
        considerations, specifically of SRv6 and SRH SRH, are covered by <xref
        target="RFC8754"/> target="RFC8754" format="default"/> as they relate to SR Attacks (section 7.1), (Section <xref target="RFC8754" section="7.1" sectionFormat="bare"/>), Service
        Theft (section 7.2) (Section <xref target="RFC8754" section="7.2" sectionFormat="bare"/>), and Topology Disclosure (section 7.3). (Section <xref target="RFC8754" section="7.3" sectionFormat="bare"/>).

	As such such, an
        operator deploying SRv6 MUST <bcp14>MUST</bcp14> follow the considerations described in
        <xref target="RFC8754"/> section 7 target="RFC8754" section="7" sectionFormat="of" format="default"/> to implement the infrastructure
        ACLs,
        Access Control Lists (ACLs) and the recommendations described in <xref target="RFC2827">BCP target="RFC2827" format="default">BCP 38</xref> and <xref
        target="RFC3704">BCP 84</xref> recommendations.</t> target="RFC3704" format="default">BCP 84</xref>.</t>
        <t>The SRv6 deployment and SID allocation guidelines guidelines, as described in
        <xref target="RFC8986"/> target="RFC8986" format="default"/>, simplify the deployment of the ACL filters
        (e.g., a single ACL corresponding to the SRv6 Block applied to the
        external interfaces on border nodes is sufficient to block packets
        destined to any SRv6 SID in the domain from external/unauthorized
        networks). While there is an assumed trust model within a an SR domain domain,
        such that any node sending a packet to an SRv6 SID is assumed to be
        allowed to do so, there is also the option of using an SRH HMAC Hashed Message Authentication
	Code (HMAC) TLV <xref
        target="RFC8754"/> target="RFC8754" format="default"/>, as described in <xref target="RFC8986"/>
	target="RFC8986" format="default"/>, for validation.</t>

        <t>The
        <t>   The SRv6 SID Endpoint behaviors Behaviors implementing the services signalled signaled
   in this document are defined in <xref target="RFC8986"/> and hence target="RFC8986" format="default"/>; hence, the security
   considerations of that document apply. These considerations
        are independent of the protocol used for service deployment, i.e. i.e.,
        independent of BGP signaling of SRv6 services.</t>
        <t>These considerations help protect transit traffic as well as
        services, such as VPNs, to avoid service theft or injection of traffic
        into customer VPN.</t> VPNs.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-spring-segment-routing-policy" to="SEGMENT-ROUTING-POLICY"/>
    <displayreference target="I-D.ietf-lsr-flex-algo" to="IGP-FLEX-ALGO"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8669.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8950.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4659.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8317.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8214.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"/>
      </references>
      <references>
        <name>Informative References</name>

<reference anchor="I-D.ietf-spring-segment-routing-policy">
   <front>
      <title>Segment Routing Policy Architecture</title>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="D." surname="Voyer" fullname="Daniel Voyer">
         <organization>Bell Canada</organization>
      </author>
      <author initials="A." surname="Bogdanov" fullname="Alex Bogdanov">
         <organization>British Telecom</organization>
      </author>
      <author initials="P." surname="Mattes" fullname="Paul Mattes">
         <organization>Microsoft</organization>
      </author>
      <date month="March" day="22" year="2022" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-spring-segment-routing-policy-22" />
</reference>

<reference anchor="I-D.ietf-lsr-flex-algo">
   <front>
      <title>IGP Flexible Algorithm</title>
      <author initials="P" surname="Psenak" fullname="Peter Psenak" role="editor">
	 <organization>Cisco Systems</organization>
      </author>
      <author initials="S" surname="Hegde" fullname="Shraddha Hegde">
	 <organization>Juniper Networks</organization>
      </author>
      <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
	 <organization>Cisco Systems</organization>
      </author>
      <author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar">
	 <organization>Arrcus, Inc</organization>
      </author>
      <author initials="A" surname="Gulko" fullname="Arkadiy Gulko">
	 <organization>Edward Jones</organization>
      </author>
      <date month="May" day="18" year="2022" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-lsr-flex-algo-20"/>
</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
    </references>
        <section anchor="ACK" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors of this document would like to thank Stephane Litkowski,
      Rishabh Parekh, Xiejingrong, Rajesh M, Mustapha Aissaoui, Alexander
      Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron Bonica,
      and Joel Halpern <contact fullname="Stephane
      Litkowski"/>, <contact fullname="Rishabh Parekh"/>, <contact fullname="Xiejingrong"/>,
      <contact fullname="Rajesh M."/>, <contact fullname="Mustapha Aissaoui"/>,
      <contact fullname="Alexander Vainshtein"/>, <contact fullname="Eduard Metz"/>,
      <contact fullname="Shraddha Hegde"/>, <contact fullname="Eduard Vasilenko"/>,
      <contact fullname="Ron Bonica"/>, and <contact fullname="Joel Halpern"/>
      for their comments and review of this document. The
      authors would also like to thank Matthew Bocci Document Shepherd <contact fullname="Matthew Bocci"/> for his document shepherd review and Martin Vigoureux AD <contact fullname="Martin Vigoureux"/> for his AD review that
      resulted in helpful comments for improving this document.</t>
    </section>
    <section title="Contributors">
      <figure>
        <artwork><![CDATA[Clarence Filsfils
Cisco

Email: cfilsfil@cisco.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Satoru Matsushima
SoftBank

Email: satoru.matsushima@g.softbank.co.jp
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Dirk Steinberg
Steinberg Consulting

Email: dirk@lapishills.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Daniel Bernier
Bell Canada

Email: daniel.bernier@bell.ca
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Daniel Voyer
Bell Canada

Email: daniel.voyer@bell.ca
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Jonn Leddy
Individual

Email: john@leddy.net
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Swadesh Agrawal
Cisco

Email: swaagraw@cisco.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Patrice Brissette
Cisco

Email: pbrisset@cisco.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Ali Sajassi
Cisco

Email: sajassi@cisco.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Bart Peirens
Proximus
Belgium

Email: bart.peirens@proximus.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Darren Dukes
Cisco

Email: ddukes@cisco.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Pablo Camarilo
Cisco

Email: pcamaril@cisco.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Shyam Sethuram
Cisco

Email: shyam.ioml@gmail.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Zafar Ali
Cisco

Email: zali@cisco.com

]]></artwork>
      </figure> numbered="false" toc="default">
      <name>Contributors</name>
      <contact fullname="Clarence Filsfils">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>cfilsfil@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Satoru Matsushima">
	<organization>SoftBank</organization>
	<address>
	  <postal/>
	  <email>satoru.matsushima@g.softbank.co.jp</email>
	</address>
      </contact>

      <contact fullname="Dirk Steinberg">
	<organization>Steinberg Consulting</organization>
	<address>
	  <postal/>
	  <email>dirk@lapishills.com</email>
	</address>
      </contact>

      <contact fullname="Daniel Bernier">
	<organization>Bell Canada</organization>
	<address>
	  <postal/>
	  <email>daniel.bernier@bell.ca</email>
	</address>
      </contact>

      <contact fullname="Daniel Voyer">
	<organization>Bell Canada</organization>
	<address>
	  <postal/>
	  <email> daniel.voyer@bell.ca</email>
	</address>
      </contact>

      <contact fullname="Jonn Leddy">
	<organization>Individual</organization>
	<address>
	  <postal/>
	  <email>john@leddy.net</email>
	</address>
      </contact>

      <contact fullname="Swadesh Agrawal">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>swaagraw@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Patrice Brissette">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>pbrisset@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Ali Sajassi">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>sajassi@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Bart Peirens">
	<organization>Proximus</organization>
	<address>
	  <postal>
	    <country>Belgium</country>
	  </postal>
	  <email>bart.peirens@proximus.com</email>
	</address>
      </contact>

      <contact fullname="Darren Dukes">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>ddukes@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Pablo Camarilo">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>pcamaril@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Shyam Sethuram">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>shyam.ioml@gmail.com</email>
	</address>
      </contact>

      <contact fullname="Zafar Ali">
	<organization>Cisco</organization>
	<address>
	  <postal/>
	  <email>zali@cisco.com</email>
	</address>
      </contact>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-bess-evpn-igmp-mld-proxy.xml' ?>

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

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

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

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

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

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.I-D.matsushima-spring-srv6-deployment-status'?>

      <?rfc include='reference.I-D.ietf-idr-segment-routing-te-policy'?>

      <?rfc include='reference.I-D.ietf-spring-segment-routing-policy.xml'?>

      <?rfc include='reference.I-D.ietf-lsr-flex-algo.xml'?>

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

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

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

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

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

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

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