<?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 xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-idr-bgpls-srv6-ext-14"
     ipr="trust200902">
  <?xml-stylesheet type='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="9514" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

<!-- xml2rfc v2v3 conversion 3.17.4 -->

  <front>
    <title abbrev="BGP-LS Extensions for SRv6">BGP SRv6">Border Gateway Protocol - Link State (BGP-LS) Extensions for
    SRv6</title>
    Segment Routing over IPv6 (SRv6)</title>
    <seriesInfo name="RFC" value="9514"/>
    <author fullname="Gaurav Dawra" initials="G" 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="Clarence Filsfils" initials="C" surname="Filsfils">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.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="Mach fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street/>
          <country>China</country>
        </postal>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>
    <author fullname="Daniel Bernier " initials="D." surname="Bernier">
      <organization>Bell Canada</organization>
      <address>
        <postal>
          <street/>
          <country>Canada</country>
        </postal>
        <email>daniel.bernier@bell.ca</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>
    <date year=""/>

    <area>Routing</area>

    <workgroup>Inter-Domain Routing</workgroup> year="2023" month="November"/>
    <area>rtg</area>
    <workgroup>idr</workgroup>
    <keyword>BGP</keyword>
    <keyword>BGP-LS</keyword>
    <keyword>Segment Routing</keyword>
    <keyword>SRv6</keyword>
    <abstract>
      <t>Segment Routing over IPv6 (SRv6) allows for a flexible definition of
      end-to-end paths within various topologies by encoding paths as
      sequences of topological or functional sub-paths, sub-paths called "segments".
      These segments are advertised by various protocols such as BGP, IS-IS IS-IS,
      and OSPFv3.</t>

      <t>This document defines extensions to BGP Link-state - Link State (BGP-LS) to
      advertise SRv6 segments along with their behaviors and other attributes
      via BGP. The BGP-LS address-family solution for SRv6 described in this
      document is similar to BGP-LS for SR for the MPLS data-plane data plane, which is defined in
      a separate document.</t>
      RFC 9085.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTROLSSRV6" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>SRv6 refers to Segment Routing instantiated on the IPv6 data-plane data plane
      <xref target="RFC8402"/>. target="RFC8402" format="default"/>. An SRv6 Segment segment is often referred to by its
      SRv6 Segment Identifier (SID).</t>
      <t>The network programming paradigm <xref target="RFC8986"/> target="RFC8986" format="default"/> is central
      to SRv6. It describes how different behaviors can be bound to SIDs and
      how a network program can be expressed as a combination of SIDs.</t>
      <t>An SRv6-capable node maintains all the SRv6 segments explicitly
      instantiated locally.</t>
      <t>The IS-IS and OSPFv3 link-state routing protocols have been extended
      to advertise some of these SRv6 SIDs and SRv6-related information <xref
      target="I-D.ietf-lsr-isis-srv6-extensions"/>, target="RFC9352" format="default"/> <xref
      target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>. target="RFC9513" format="default"/>. Other SRv6 SIDs may be
      instantiated on a node via other mechanisms for topological or service
      functionalities.</t>

<t>The advertisement of SR related SR-related information along with the topology is specified in <xref target="RFC9085" format="default"/>
      for the MPLS data-plane data plane instantiation (SR-MPLS) is specified and in <xref
      target="RFC9085"/> and target="RFC9086" format="default"/> for the BGP Egress Peer Engineering (EPE) is
      specified in <xref target="RFC9086"/>. (EPE). On similar lines, introducing the
      SRv6 related
      SRv6-related information in BGP-LS allows consumer applications that
      require topological visibility to also receive the SRv6 SIDs from nodes
      across an IGP domain or even across Autonomous Systems (AS), (ASes) as
      required. This allows applications to leverage the SRv6 capabilities for
      network programming.</t>
      <t>The identifying key of each Link-State link-state object, namely a node, link,
      or prefix, is encoded in the Network-Layer Network Layer Reachability Information
      (NLRI)
      (NLRI), and the properties of the object are encoded in the BGP-LS
      Attribute <xref target="RFC7752"/>.</t> target="RFC7752" format="default"/>.</t>
      <t>This document describes extensions to BGP-LS to advertise the SRv6
      SIDs and other SRv6 information from all the SRv6 capable SRv6-capable nodes in the
      IGP domain when sourced from link-state routing protocols and directly
      from individual SRv6 capable SRv6-capable nodes (e.g. (e.g., when sourced from BGP for
      EPE).</t>
      <section 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="BGP-LS-SRv6" title="BGP-LS numbered="true" toc="default">
      <name>BGP-LS Extensions for SRv6"> SRv6</name>
      <t>BGP-LS <xref target="RFC7752"/> target="RFC7752" format="default"/> defines the Node, Link, and Prefix
      Link-State Network Layer Reachability Information (NLRI) NLRI types and the
      advertisement of their attributes via BGP.</t>
      <t>When a BGP-LS router advertises topology information that it sources
      from the underlying link-state routing protocol, then it derives the
      corresponding SRv6 information from the SRv6 extensions for IS-IS <xref
      target="I-D.ietf-lsr-isis-srv6-extensions"/> target="RFC9352" format="default"/> or OSPFv3 <xref
      target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>, target="RFC9513" format="default"/> as applicable. In
      practice, this derivation comprises a simple copy of the relevant fields
      from the IS-IS/OSPFv3 IS-IS or OSPFv3 TLV/sub-TLV into the fields of the corresponding
      BGP-LS TLV/sub-TLV.

When a BGP-LS router advertises topology information
      from the BGP routing protocol (e.g., for EPE) or when it advertises SRv6
      SIDs associated with a node using Direct as the Protocol-ID, then it
      derives the SRv6 information from the local node. Such information is
      advertised only on behalf of the local router, in contrast to the
      advertisement of information from all nodes of an IGP domain when
      sourced from a link-state routing protocol.</t>

<t>The SRv6 information pertaining to a node is advertised via the
      BGP-LS Node NLRI and using the BGP-LS Attribute TLVs as follows:</t>

      <t><list style="symbols">
          <t>SRv6 Capabilities
      <ul spacing="normal">
        <li>The SRv6 capabilities of the node are advertised via the SRv6
          Capabilities TLV (<xref target="SRCAPATTR"/>).</t>

          <t>Maximum target="SRCAPATTR" format="default"/>).</li>
        <li>Maximum SID Depth (MSD) types introduced for SRv6 are advertised
          (<xref target="SRNODEMSD"/>) target="SRNODEMSD" format="default"/>) using the Node MSD TLV specified in
          <xref target="RFC8814"/></t>

          <t>Algorithm target="RFC8814" format="default"/>.</li>
        <li>Algorithm support for SRv6 is advertised via the SR-Algorithm TLV
          specified in <xref target="RFC9085"/>.</t>
        </list></t> target="RFC9085" format="default"/>.</li>
      </ul>
      <t>The SRv6 information pertaining to a link is advertised via the
      BGP-LS Link NLRI and using the BGP-LS Attribute TLVs as follows:</t>

      <t><list style="symbols">
          <t>SRv6
      <ul spacing="normal">
        <li>The SRv6 SID of the IGP Adjacency SID or the BGP EPE Peer Adjacency
          SID <xref target="RFC8402"/> target="RFC8402" format="default"/> is advertised via the SRv6 End.X SID
          TLV introduced in this document (<xref target="SRENDXTLV"/>).</t>

          <t>SRv6 target="SRENDXTLV" format="default"/>).</li>
        <li>The SRv6 SID of the IGP Adjacency SID to a non-Designated Router (DR)
          or non-Designated Intermediate-System Intermediate System (DIS) <xref target="RFC8402"/> target="RFC8402" format="default"/>
          is advertised via the SRv6 LAN End.X SID TLV introduced in this
          document (<xref target="SRLANENDXTLV"/>).</t>

          <t>MSD target="SRLANENDXTLV" format="default"/>).</li>
        <li>MSD types introduced for SRv6 are advertised (<xref
          target="SRLINKMSD"/>) target="SRLINKMSD" format="default"/>) using the Link MSD TLV specified in <xref
          target="RFC8814"/>.</t>
        </list></t> target="RFC8814" format="default"/>.</li>
      </ul>
      <t>The SRv6 information pertaining to a prefix is advertised via the
      BGP-LS Prefix NLRI and using the BGP-LS Attribute TLVs as follows:</t>

      <t><list style="symbols">
          <t>SRv6
      <ul spacing="normal">
        <li>The SRv6 Locator is advertised via the SRv6 Locator TLV introduced in
          this document (<xref target="SRLOCTLV"/>).</t>

          <t>The target="SRLOCTLV" format="default"/>).</li>
        <li>The attributes of the SRv6 Locator are advertised via the Prefix
          Attribute Flags TLV specified in <xref target="RFC9085"/>.</t>
        </list></t> target="RFC9085" format="default"/>.</li>
      </ul>
      <t>The SRv6 SIDs associated with the node are advertised using the
      BGP-LS SRv6 SID NLRI introduced in this document (<xref
      target="SRSIDNLRI"/>). target="SRSIDNLRI" format="default"/>).
This enables the BGP-LS encoding to scale to
      cover a potentially large set of SRv6 SIDs instantiated on a node with
      the granularity of individual SIDs and without affecting the size and
      scalability of the BGP-LS updates. Had
If the SRv6 SIDs had been advertised
      within the BGP-LS Link Attribute associated with the existing Node NLRI,
      the BGP-LS update would have grown rather large with the increase in
      SRv6 SIDs on the node and would have also required a large update
      message to be generated for any change, even a change to even a single SRv6 SID. BGP-LS
      Attribute TLVs for the SRv6 SID NLRI are introduced in this document as follows:</t>

      <t><list style="symbols">
          <t>The endpoint
      <ul spacing="normal">
        <li>The Endpoint behavior of the SRv6 SID is advertised via the SRv6
          Endpoint Behavior TLV (<xref target="SRFUNCTLV"/>).</t>

          <t>The target="SRFUNCTLV" format="default"/>).</li>
        <li>The BGP EPE Peer Node context for a PeerNode SID, SID and the Peer
          Set context for a PeerSet SID <xref target="RFC8402"/> target="RFC8402" format="default"/> are
          advertised via the SRv6 BGP EPE Peer Node PeerNode SID TLV (<xref
          target="SRPEERTLV"/>),</t>
        </list></t> target="SRPEERTLV" format="default"/>).</li>
      </ul>
      <t>Subsequent sections of this document specify the encoding and usage
      of these extensions. All the TLVs introduced follow the formats and
      common field definitions provided in <xref target="RFC7752"/>.</t> target="RFC7752" format="default"/>.</t>
    </section>
    <section anchor="SRNODEATTR" title="SRv6 numbered="true" toc="default">
      <name>SRv6 Node Attributes"> Attributes</name>
      <t>The SRv6 attributes of a node are advertised using the BGP-LS
      Attribute TLVs defined in this section and associated with the BGP-LS
      Node NLRI.</t>
      <section anchor="SRCAPATTR" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Capabilities TLV"> TLV</name>
        <t>This BGP-LS Attribute TLV is used to announce the SRv6 capabilities
        of the node along with the BGP-LS Node NLRI and indicates the SRv6
        support by the node. A single instance of this TLV MUST <bcp14>MUST</bcp14>
        be included in the BGP-LS attribute Attribute for each SRv6 capable SRv6-capable node. The
        IS-IS SRv6 Capabilities sub-TLV <xref
        target="I-D.ietf-lsr-isis-srv6-extensions"/> target="RFC9352"
        format="default"/> and the OSPFv3 SRv6 Capabilities TLV <xref target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>
        target="RFC9513" format="default"/> that map to this BGP-LS TLV are
        specified with the ability to carry optional sub-sub-TLVs/sub-TLVs.
        sub-sub-TLVs and sub-TLVs. However, no such extensions are currently
        defined. Moreover, the SRv6 Capabilities TLV defined below is not
        extensible. As a result, it is expected that any extensions will be
        introduced as top-level TLVs in the BGP-LS Attribute.</t>

        <t><figure anchor="SRCAPTLVFIG" title="SRv6 Attribute.
The SRv6 Capabilities
	TLV Format">
            <artwork><![CDATA[ has the following format:</t>

        <figure anchor="SRCAPTLVFIG">
          <name>SRv6 Capabilities TLV Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Flags             |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure> Where:<list style="symbols">
            <t>Type: 1038</t>

            <t>Length : 4.</t>

            <t>Flags: 2 octet

    <t>where:</t>

        <dl newline="false" spacing="normal">
            <dt>Type:</dt> <dd>1038</dd>
            <dt>Length:</dt> <dd>4</dd>
            <dt>Flags:</dt> <dd>2-octet field. The flags are copied from the IS-IS SRv6
            Capabilities sub-TLV (section 2 of <xref
            target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="2"/>) or from the OSPFv3
            SRv6 Capabilities TLV (section 2 of <xref
            target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="2"/>) in the case of
            IS-IS or OSPFv3 respectively.</t>

            <t>Reserved: 2 octet OSPFv3, respectively.</dd>
<dt>Reserved:</dt><dd>2-octet field that MUST <bcp14>MUST</bcp14> be set to 0 when originated and
            ignored on receipt.</t>
          </list></t> receipt.</dd>
       </dl>
      </section>
      <section anchor="SRNODEMSD" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Node MSD Types"> Types</name>
        <t>The Node MSD TLV <xref target="RFC8814"/> target="RFC8814" format="default"/> of the BGP-LS Attribute
        of the Node NLRI is also used to advertise the limits and the Segment
        Routing Header (SRH) <xref target="RFC8754"/> target="RFC8754" format="default"/> operations supported by
        the SRv6 capable SRv6-capable node. The SRv6 MSD Types types specified in section 4 of
        <xref target="I-D.ietf-lsr-isis-srv6-extensions"/> target="RFC9352" sectionFormat="of" section="4"/> are also used with
        the BGP-LS Node MSD TLV TLV, as these code points are shared between the IS-IS,
        OSPF
        OSPF, and BGP-LS protocols. The description and semantics of these new
        MSD-types
        MSD types for BGP-LS are identical as to those specified in <xref
        target="I-D.ietf-lsr-isis-srv6-extensions"/>.</t> target="RFC9352" format="default"/>.</t>
        <t>Each MSD-type MSD type is encoded in the BGP-LS Node MSD TLV as a one-octet
        type followed by a one-octet value as derived from the IS-IS or OSPFv3
        Node MSD advertisements as specified in <xref target="RFC8814"/>.</t> target="RFC8814" format="default"/>.</t>
      </section>
    </section>
    <section anchor="SRLINKATTR" title="SRv6 numbered="true" toc="default">
      <name>SRv6 Link Attributes"> Attributes</name>
      <t>SRv6 attributes and SIDs associated with a link or adjacency are
      advertised using the BGP-LS Attribute TLVs defined in this section and
      associated with the BGP-LS Link NLRI.</t>
      <section anchor="SRENDXTLV" title="SRv6 numbered="true" toc="default">
        <name>SRv6 End.X SID TLV"> TLV</name>
        <t>The SRv6 End.X SID TLV is used to advertise the SRv6 SIDs
        associated with an IGP Adjacency SID behavior that correspond to a
        point-to-point or point-to-multipoint link or adjacency of the node
        running the IS-IS or OSPFv3 protocols. The information advertised via
        this TLV is derived from the IS-IS SRv6 End.X SID sub-TLV (section 8.1
        of <xref target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="8.1"/>) or the OSPFv3
        SRv6 End.X SID sub-TLV (section 9.1 of <xref
        target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="9.1"/>) in the case of IS-IS
        or OSPFv3 OSPFv3, respectively. This TLV can also be used to advertise the
        SRv6 SID corresponding to the underlying layer-2 Layer 2 member links for a
        layer-3
        Layer 3 bundle interface as a sub-TLV of the L2 Bundle Member
        Attribute TLV <xref target="RFC9085"/>.</t> target="RFC9085" format="default"/>.</t>
        <t>This TLV is also used by BGP-LS to advertise the BGP EPE Peer
        Adjacency SID for SRv6 on the same lines as specified for SR-MPLS in
        <xref target="RFC9086"/>. target="RFC9086" format="default"/>. The SRv6 SID for the BGP Peer Adjacency
        using End.X behaviors (viz. End.X, (viz.&nbsp;End.X, End.X with PSP, End.X with USP, and
        End.X with PSP &amp; USP) <xref target="RFC8986"/> target="RFC8986" format="default"/> indicates the
        cross-connect to a specific layer-3 Layer 3 link to the specific BGP session
        peer (neighbor).</t>
        <t>More than one instance of this TLV (one for each SRv6 End.X SID) can be included in the BGP-LS
        Attribute; one for each SRv6 End.X SID.</t>
        Attribute.</t>
        <t>The TLV has the following format:</t>

        <t><figure anchor="ENDXTLV" title="SRv6
        <figure anchor="ENDXTLV">
          <name>SRv6 End.X SID TLV Format">
            <artwork><![CDATA[ Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Endpoint Behavior      |      Flags    |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Weight    |   Reserved    |  SID (16 octets) ...          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)             | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:<list>
            <t>Type: 1106</t>

            <t>Length: variable</t>

            <t>Endpoint Behavior: 2 octet
        </figure>

        <t>where:</t>

	  <dl newline="false" spacing="normal">
          <dt>Type:</dt><dd>1106</dd>
          <dt>Length:</dt><dd>variable</dd>
          <dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint Behavior behavior code
            point for this SRv6 SID as defined in section 10.2 of <xref
            target="RFC8986"/>.</t>

            <t>Flags: 1 target="RFC8986" sectionFormat="of" section="10.2"/>.</dd>
          <dt>Flags:</dt><dd>1 octet of flags. The flags are copied from the
          IS-IS SRv6 End.X SID sub-TLV (section 8.1 of <xref
            target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352"
          sectionFormat="of" section="8.1"/>) or the OSPFv3 SRv6 End.X SID
          sub-TLV (section 9.1 of <xref
            target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="9.1"/>)
          in the case of IS-IS or OSPFv3 OSPFv3, respectively. In the case of the BGP EPE
          Peer Adjacency SID, the flags are as defined in <xref
            target="SRPEERTLV"/>.</t>

            <t>Algorithm: 1 octet
          target="SRPEERTLV" format="default"/>.</dd>
          <dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
            SID.</t>

            <t>Weight: 1 octet
            SID.</dd>
          <dt>Weight:</dt><dd>1-octet field. The value represents the weight of the
            SID for the purpose of load balancing. The use of the weight is
            defined in <xref target="RFC8402"/>.</t>

            <t>Reserved: 1 octet target="RFC8402" format="default"/>.</dd>
          <dt>Reserved:</dt><dd>1-octet field that MUST <bcp14>MUST</bcp14> be set to 0 when originated
            and ignored on receipt.</t>

            <t>SID: 16 octet receipt.</dd>
          <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv6 SID
            as 128 bit value.</t>

            <t>Sub-TLVs : Used a 128-bit value.</dd>
          <dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide additional
            attributes for the specific SRv6 SID. This document defines one in
            <xref target="SRSTRUCTTLV"/>.</t>
          </list></t> target="SRSTRUCTTLV" format="default"/>.</dd>
        </dl>
      </section>
      <section anchor="SRLANENDXTLV" title="SRv6 numbered="true" toc="default">
        <name>SRv6 LAN End.X SID TLV "> TLV</name>

        <t>For a LAN interface, an IGP node ordinarily announces only its
        adjacency to the IS-IS pseudo-node pseudonode (or the equivalent OSPF DR). The
        information advertised via this TLV is derived from the IS-IS SRv6 LAN
        End.X SID sub-TLV (section 8.2 of <xref
        target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="8.2"/>) or the OSPFv3 SRv6 LAN
        End.X SID sub-TLV (section 9.2 of <xref
        target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="9.2"/>) in the case of IS-IS
        or OSPFv3 OSPFv3, respectively. The SRv6 LAN End.X SID TLV allows a node to
        announce the SRv6 SID corresponding to its adjacencies to all other
        (i.e., non-DIS or non-DR) nodes attached to the LAN in a single
        instance of the BGP-LS Link NLRI. Without this TLV, multiple BGP-LS
        Link NLRIs would need to be originated, one for each neighbor, to
        advertise the SRv6 End.X SID TLVs for those non-DIS/non-DR neighbors.
        The SRv6 SID for these IGP adjacencies using the End.X behaviors (viz.
        End.X, (viz.&nbsp;End.X, End.X with PSP, End.X with USP, and End.X with PSP &amp; USP)
        <xref target="RFC8986"/> target="RFC8986" format="default"/> are advertised using the SRv6 LAN End.X SID
        TLV.</t>
        <t>More than one instance of this TLV (one for each SRv6 LAN End.X SID) can be included in the BGP-LS
        Attribute; one for each SRv6 LAN End.X SID.</t>
        Attribute.</t>
        <t>The BGP-LS IS-IS SRv6 LAN End.X SID and BGP-LS OSPFv3 SRv6 LAN
        End.X SID TLVs have the following format:</t>

        <t><figure anchor="ENDLXTLV" title="SRv6
        <figure anchor="ENDLXTLV">
          <name>SRv6 LAN End.X SID TLV Format">
            <artwork><![CDATA[ Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Endpoint Behavior       |      Flags    |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Weight    |   Reserved    |   Neighbor ID -               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
| IS-IS System-ID (6 octets) or OSPFv3 Router-ID (4 octets)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (16 octets) ...                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:<list style="symbols">
            <t>Type: 1107 in case of
        </figure>

        <t>where:</t>

	  <dl newline="false" spacing="normal">
          <dt>Type:</dt><dd>1107 for IS-IS and 1108 in case of OSPFv3</t>

            <t>Length: variable</t>

            <t>Endpoint Behavior: 2 octet for OSPFv3</dd>
          <dt>Length:</dt><dd>variable</dd>
          <dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint Behavior behavior code
            point for this SRv6 SID as defined in section 10.2 of <xref
            target="RFC8986"/>.</t>

            <t>Flags: 1 target="RFC8986" sectionFormat="of" section="10.2"/>.</dd>
          <dt>Flags:</dt><dd>1 octet of flags. The flags are copied from the IS-IS
            SRv6 LAN End.X SID sub-TLV (section 8.2 of <xref
            target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="8.2"/>) or the OSPFv3 SRv6
            LAN End.X SID sub-TLV (section 9.2 of <xref
            target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="9.2"/>) in the case of
            IS-IS or OSPFv3 respectively.</t>

            <t>Algorithm: 1 octet OSPFv3, respectively.</dd>
          <dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
            SID.</t>

            <t>Weight: 1 octet
            SID.</dd>
          <dt>Weight:</dt><dd>1-octet field. The value represents the weight of the
            SID for the purpose of load balancing.</t>

            <t>Reserved: 1 octet balancing.</dd>
          <dt>Reserved:</dt><dd>1-octet field that MUST <bcp14>MUST</bcp14> be set to 0 when originated
            and ignored on receipt.</t>

            <t>Neighbor ID : 6 receipt.</dd>
          <dt>Neighbor ID:</dt><dd>6 octets of Neighbor System-ID in the IS-IS SRv6 LAN
            End.X SID TLV or 4 octets of Neighbor Router-id Router-ID in the OSPFv3 SRv6
            LAN End.X SID TLV.</t>

            <t>SID: 16 octet TLV.</dd>
          <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv6 SID
            as 128 bit value.</t>

            <t>Sub-TLVs : Used a 128-bit value.</dd>
          <dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide additional
            attributes for the specific SRv6 SID. This document defines one in
            <xref target="SRSTRUCTTLV"/>.</t>
          </list></t> target="SRSTRUCTTLV" format="default"/>.</dd>
        </dl>

      </section>
      <section anchor="SRLINKMSD" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Link MSD Types"> Types</name>
        <t>The Link MSD TLV <xref target="RFC8814"/> target="RFC8814" format="default"/> of the BGP-LS Attribute
        of the Link NLRI is also used to advertise the limits and the SRH
        operations supported on the specific link by the SRv6 capable SRv6-capable node.
        The SRv6 MSD Types types specified in section 4 of<xref
        target="I-D.ietf-lsr-isis-srv6-extensions"> <xref target="RFC9352" sectionFormat="of" section="4"> </xref> are also used with
        the BGP-LS Link MSD TLV TLV, as these code points are shared between the IS-IS,
        OSPF, and BGP-LS protocols. The description and semantics of these new
        MSD types for BGP-LS are identical as specified in <xref
        target="I-D.ietf-lsr-isis-srv6-extensions"/>.</t> target="RFC9352" format="default"/>.</t>
        <t>Each MSD-type MSD type is encoded in the BGP-LS Link MSD TLV as a one-octet
        type followed by a one-octet value as derived from the IS-IS or OSPFv3
        Link MSD advertisements as specified in <xref target="RFC8814"/>.</t> target="RFC8814" format="default"/>.</t>
      </section>
    </section>
    <section anchor="SRPFXATTR" title="SRv6 numbered="true" toc="default">
      <name>SRv6 Prefix Attributes"> Attributes</name>
      <t>SRv6 attributes with an IPv6 prefix are advertised using the BGP-LS
      Attribute TLVs defined in this section and associated with the BGP-LS
      Prefix NLRI.</t>
      <section anchor="SRLOCTLV" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Locator TLV"> TLV</name>
        <t>As specified in <xref target="RFC8986"/>, target="RFC8986" format="default"/>, an SRv6 SID comprises
        Locator, Function
        locator, function, and Argument argument parts.</t>
        <t>A node is provisioned with one or more Locators locators supported by that
        node. Locators are covering prefixes for the set of SIDs provisioned
        on that node. Each Locator locator is advertised as a BGP-LS Prefix NLRI
        object along with the SRv6 Locator TLV in its BGP-LS Attribute.</t>
        <t>The information advertised via this TLV is derived from the IS-IS
        SRv6 Locator TLV (section 7.1 of <xref
        target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="7.1"/>) or the OSPFv3 SRv6
        Locator TLV (section 7.1 of <xref
        target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="7.1"/>) in the case of IS-IS
        or OSPFv3 OSPFv3, respectively.</t>
        <t>The IPv6 Prefix matching the Locator locator may be also be advertised as
        prefix reachability by the underlying routing protocol. In this case,
        the Prefix NLRI would be also be associated with the Prefix Metric TLV
        <xref target="RFC7752"/> target="RFC7752" format="default"/> that carries the routing metric for this
        prefix. A Prefix NLRI, NLRI that has been advertised with a SRv6 Locator
        TLV,
        TLV is also considered a normal routing prefix (i.e., prefix
        reachability) only when there is also an IGP metric Metric TLV (TLV 1095)
        associated it. Otherwise, it is considered only as considered an SRv6 Locator
        advertisement.</t>
        <t>The SRv6 Locator TLV has the following format: </t>
        <figure
            anchor="SRV6LOCFIG" title="SRv6 anchor="SRV6LOCFIG">
          <name>SRv6 Locator TLV Format">
            <artwork><![CDATA[ Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Flags    |   Algorithm   |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:<list>
            <t>Type: 1162</t>

            <t>Length: variable</t>

            <t>Flags: 1
        </figure>

  <t>where:</t>

        <dl newline="false">
          <dt>Type:</dt><dd>1162</dd>
          <dt>Length:</dt><dd>variable</dd>
          <dt>Flags:</dt><dd>1 octet of flags. The flags are copied from the IS-IS
            SRv6 Locator TLV (section 7.1 of <xref
            target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="7.1"/>) or the OSPFv3 SRv6
            Locator TLV (section 7.1 of <xref
            target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="7.1"/>) in the case of
            IS-IS or OSPFv3 respectively.</t>

            <t>Algorithm: 1 octet OSPFv3, respectively.</dd>
          <dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
            SID.</t>

            <t>Reserved: 2 octet
            SID.</dd>
          <dt>Reserved:</dt><dd>2-octet field. The value MUST <bcp14>MUST</bcp14> be set to 0 when
            originated and ignored on receipt.</t>

            <t>Metric: 4 octet receipt.</dd>
          <dt>Metric:</dt><dd>4-octet field. The value of the metric for the Locator locator
            copied from the IS-IS SRv6 Locator TLV (section 7.1 of <xref
            target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="7.1"/>) or the OSPFv3 SRv6
            Locator TLV (section 7.1 of <xref
            target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="7.1"/>) in the case of
            IS-IS or OSPFv3 respectively.</t>

            <t>Sub-TLVs : Used OSPFv3, respectively.</dd>
          <dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide additional
            attributes for the given SRv6 Locator. Currently, none are
            defined.</t>
          </list></t>
            defined.</dd>
        </dl>

      </section>
    </section>
    <section anchor="SRSIDNLRI" title="SRv6 numbered="true" toc="default">
      <name>SRv6 SID NLRI"> NLRI</name>
      <t>The "Link-State NLRI" Link-State NLRI defined in <xref target="RFC7752"/> target="RFC7752" format="default"/> is extended
      to carry the SRv6 SID information.</t>

      <t>A
      <t>This document defines the following new "Link-State Link-State NLRI Type" is defined type for SRv6 SID information as
      follows:</t>

      <t><list style="symbols">
          <t>Link-State NLRI Type: information: SRv6 SID NLRI (value 6).</t>
        </list></t> (type 6).
      </t>
      <t>The SRv6 SIDs associated with the node are advertised using the
      BGP-LS SRv6 SID NLRI.</t>

      <t>The format of this
<t>This new NLRI type is as shown in has the following
      figure:</t>

      <t><figure anchor="SRSIDNLRIFIG" title="SRv6 format:</t>
      <figure anchor="SRSIDNLRIFIG">
        <name>SRv6 SID NLRI Format">
          <artwork><![CDATA[ Format</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
+-+-+-+-+-+-+-+-+
|  Protocol-ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Identifier                             |
|                        (8 octets)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Local Node Descriptors (variable)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               SRv6 SID Descriptors (variable)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>Where:<list style="symbols">
          <t>Protocol-ID: 1-octet
      </figure>

      <t>where:</t>

<dl newline="false" spacing="normal">
        <dt>Protocol-ID:</dt><dd>1-octet field that specifies the information source
          protocol <xref target="RFC7752"/>.</t>

          <t>Identifier: 8 octet target="RFC7752" format="default"/>.</dd>
        <dt>Identifier:</dt><dd>8-octet value as defined in <xref
          target="RFC7752"/>.</t>

          <t>Local target="RFC7752" format="default"/>.</dd>
        <dt>Local Node Descriptors TLV: set TLV:</dt><dd>Set of Node Descriptor TLVs for the
          local node, node as defined in <xref target="RFC7752"/> target="RFC7752" format="default"/> for IGPs, direct, the Direct Protocol-ID,
      and static the Static configuration Protocol-ID or as defined in <xref target="RFC9086"/> target="RFC9086" format="default"/>
          for BGP protocol.</t>

          <t>SRv6 BGP.</dd>
        <dt>SRv6 SID Descriptors: set Descriptors:</dt><dd>Set of SRv6 SID Descriptor TLVs. This field
          MUST
          <bcp14>MUST</bcp14> contain a single SRv6 SID Information TLV (<xref
          target="SRSIDINFO"/>) target="SRSIDINFO" format="default"/>) and MAY <bcp14>MAY</bcp14> contain the Multi-Topology Identifier
          TLV <xref target="RFC7752"/>.</t>
        </list></t> target="RFC7752" format="default"/>.</dd>
      </dl>

      <t>New TLVs for advertisement within the BGP-LS Attribute <xref
      target="RFC7752"/> target="RFC7752" format="default"/> are defined in <xref target="SRSIDATTR"/> target="SRSIDATTR" format="default"/> to carry
      the attributes of an SRv6 SID.</t>
      <section anchor="SRSIDINFO" title="SRv6 numbered="true" toc="default">
        <name>SRv6 SID Information TLV"> TLV</name>
        <t>An SRv6 SID that is associated with the node and advertised using
        the SRv6 SID NLRI is encoded using the SRv6 SID Information TLV.</t>
        <t>When advertising the SRv6 SIDs from the IGPs, the SID information
        is derived from the IS-IS SRv6 End SID sub-TLV (section 7.2 of <xref
        target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="7.2"/>) or the OSPFv3 SRv6 End
        SID sub-TLV (section 8 of <xref
        target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="8"/>) in the case of IS-IS
        or OSPFv3 OSPFv3, respectively.</t>
        <t>The TLV carries the SRv6 SIDs corresponding to the BGP PeerNode and
        PeerSet SID SIDs <xref target="RFC8402"/> target="RFC8402" format="default"/> when SRv6 BGP EPE functionality
        is enabled in BGP.</t>
        <t>The TLV has the following format: </t>
        <figure anchor="SRV6SIDDESC"
            title="SRv6 anchor="SRV6SIDDESC">
          <name>SRv6 SID Information TLV Format">
            <artwork><![CDATA[ Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (16 octets) ...                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SID (cont ...)                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:<list>
            <t>Type: 518</t>

            <t>Length: 16.</t>

            <t>SID: 16 octet
        </figure>

        <t>where:</t>

	  <dl newline="false" spacing="normal">
          <dt>Type:</dt><dd>518</dd>
          <dt>Length:</dt><dd>16</dd>
          <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv6 SID
            as 128 bit value.</t>
          </list></t> a 128-bit value.</dd>
        </dl>

      </section>
    </section>
    <section anchor="SRSIDATTR" title="SRv6 numbered="true" toc="default">
      <name>SRv6 SID Attributes"> Attributes</name>
      <t>This section specifies the TLVs to be carried in the BGP Link State
      Attribute associated with the BGP-LS SRv6 SID NLRI.</t>
      <section anchor="SRFUNCTLV" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Endpoint Behavior TLV"> TLV</name>
        <t>Each SRv6 SID instantiated on an SRv6 capable SRv6-capable node has specific
        instructions (called behavior) "behavior") bound to it. <xref target="RFC8986"/> target="RFC8986" format="default"/>
        describes how behaviors are bound to a SID and also defines the
        initial set of well-known behaviors.</t>
        <t>The SRv6 Endpoint Behavior TLV is a mandatory TLV that MUST <bcp14>MUST</bcp14> be
        included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID
        NLRI.</t>
        <t>When advertising the SRv6 SIDs from the IGPs, the Endpoint
        behavior, Flags, and Algorithm are derived from the IS-IS SRv6 End SID
        sub-TLV (section 7.2 of <xref
        target="I-D.ietf-lsr-isis-srv6-extensions"/>) (<xref target="RFC9352" sectionFormat="of" section="7.2"/>) or the OSPFv3 SRv6 End
        SID sub-TLV (section 8 of <xref
        target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="8"/>) in the case of IS-IS
        or OSPFv3 OSPFv3, respectively.</t>
        <t>When advertising the SRv6 SIDs corresponding to the BGP EPE
        functionality, the Endpoint Behavior behavior corresponds to End.X and similar
        behaviors. When advertising the SRv6 SIDs that are locally
        instantiated on the node using Direct as the Protoocl-ID, The Protocol-ID, the Endpoint
        Behavior
        behavior corresponds to any SRv6 Endpoint Behavior behavior associated with the
        node. Flags are currently not defined. The algorithm value MUST <bcp14>MUST</bcp14> be 0
        unless an algorithm is associated locally with the SRv6 Locator from
        which the SID is allocated.</t>
        <t>The TLV has the following format:</t>

        <t><figure anchor="SRENDFUNC" title="SRv6
        <figure anchor="SRENDFUNC">
          <name>SRv6 Endpoint Behavior TLV">
            <artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Endpoint Behavior      |      Flags    |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:<list>
            <t>Type: 1250</t>

            <t>Length: 4.</t>

            <t>Endpoint Behavior: 2 octet
        </figure>

        <t>where:</t>

<dl newline="false" spacing="normal">
          <dt>Type:</dt><dd>1250</dd>
          <dt>Length:</dt><dd>4</dd>
          <dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint Behavior behavior code
            point for this SRv6 SID. Support values Values are those from the "SRv6
            Endpoint Behaviors" IANA registry (as established via section 10.2
            of <xref target="RFC8986"/>).</t>

            <t>Flags: 1 (<xref target="RFC8986" sectionFormat="of" section="10.2"/>).</dd>

            <dt>Flags:</dt><dd>1 octet of flags. The flags map to the IS-IS or
            OSPFv3 encodings when advertising SRv6 SIDs corresponding to IGPs. For
            No flags are currently defined for SRv6 SIDs corresponding to BGP
            EPE and when advertising or for advertisement of a SRv6 SID using Direct Protocol-ID, none are defined currently and they MUST as the
            Protocol-ID. Undefined flags <bcp14>MUST</bcp14> be set to 0 when originated originating and ignored on receipt.</t>

            <t>Algorithm: 1 octet
            receipt. </dd>
          <dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
            SID.</t>
          </list></t>
            SID.</dd>
        </dl>

      </section>
      <section anchor="SRPEERTLV" title="SRv6 numbered="true" toc="default">
        <name>SRv6 BGP Peer Node PeerNode SID TLV"> TLV</name>
        <t>The BGP PeerNode SID and PeerSet SID SIDs for SR-MPLS are specified in
        <xref target="RFC9086"/>. target="RFC9086" format="default"/>. Similar Peer Node and Peer Set functionality
        can be realized with SRv6 using SIDs with END.X behavior. Refer to
        <xref target="BGPEPE"/> target="BGPEPE" format="default"/> for some differences between the signaling of
        these SIDs in SR-MPLS and SRv6. The SRv6 BGP Peer Node PeerNode SID TLV is a
        mandatory TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI
        advertised by BGP for the EPE functionality. This TLV MUST <bcp14>MUST</bcp14> be included
        along with SRv6 SIDs that are associated with the BGP PeerNode or
        PeerSet functionality.</t>
        <t>The TLV has the following format:</t>

        <t><figure anchor="SRPEERTLVFIG"
            title="SRv6
        <figure anchor="SRPEERTLVFIG">
          <name>SRv6 BGP Peer Node PeerNode SID TLV Format">
            <artwork><![CDATA[ Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Flags    |     Weight    |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Peer AS Number                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Peer BGP Identifier                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:<list style="symbols">
            <t>Type: 1251</t>

            <t>Length: 12</t>

            <t>Flags: 1
        </figure>

        <t>where:</t>

<dl newline="false" spacing="normal">
          <dt>Type:</dt><dd>1251</dd>
          <dt>Length:</dt><dd>12</dd>
          <dt>Flags:</dt><dd><t>1 octet of flags with the following definition: definitions:</t>

            <figure
                anchor="ENDXBGPFLAGS" title="SRv6 anchor="ENDXBGPFLAGS">
              <name>SRv6 BGP EPE SID Flags Format"> Format</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P|         |
+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure><list style="symbols">
                <t>B-Flag: Backup
            </figure>

<dl newline="false" spacing="normal">
              <dt>B-Flag:</dt><dd>Backup Flag. If set, the SID is eligible to
              be protected using fast reroute Fast Reroute (FRR). The computation of the
              backup forwarding path and its association with the forwarding
              entry for the Peer BGP Identifier is are implementation
                specific.</t>

                <t>S-Flag: Set specific.</dd>
              <dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates that the
                SID refers to a set of BGP peering sessions (i.e., BGP Peer
                Set SID functionality) and therefore MAY <bcp14>MAY</bcp14> be assigned to one or
                more End.X SIDs associated with BGP peer sessions.</t>

                <t>P-Flag: Persistent Flag: peering sessions.</dd>
              <dt>P-Flag:</dt><dd>Persistent Flag. When set, the P-Flag indicates
                that the SID is persistently allocated, i.e., the value
                remains consistent across router restart and/or session
                flap.</t>

                <t>Other
                flap.</dd>
              <dt>Other bits are reserved for future use and MUST
              <bcp14>MUST</bcp14> be set to 0 when originated and ignored on receipt.</t>
              </list>
              receipt.  The flags defined above are also used with the SRv6
              End.X SID TLV when advertising  the SRv6 BGP Peer Adjacency SID
              (<xref
            target="SRENDXTLV"/>).</t>

            <t>Weight: 1 octet target="SRENDXTLV" format="default"/>).</dt><dd></dd>
</dl></dd>

          <dt>Weight:</dt><dd>1-octet field. The value represents the weight of the
            SID for the purpose of load balancing. The use of the weight is
            defined in <xref target="RFC8402"/>.</t>

            <t>Reserved: 2 octet target="RFC8402" format="default"/>.</dd>
          <dt>Reserved:</dt><dd>2-octet field. The value MUST <bcp14>MUST</bcp14> be set to 0 when
            originated and ignored on receipt.</t>

            <t>Peer receipt.</dd>
          <dt>Peer AS Number : 4 Number:</dt><dd>4 octets of the BGP AS number of the peer
            router.</t>

            <t>Peer
            router.</dd>
          <dt>Peer BGP Identifier : 4 Identifier:</dt><dd>4 octets of the BGP Identifier (BGP
            Router-ID) of the peer router.</t>
          </list></t> router.</dd>
        </dl>

        <t>For an SRv6 BGP EPE Peer Node PeerNode SID, one instance of this TLV is
        associated with the SRv6 SID. For an SRv6 BGP EPE Peer Set PeerSet SID, multiple
        instances of this TLV (one for each peer in the &ldquo;peer
        set&rdquo;) "peer
        set") are associated with the SRv6 SID and the S-Flag is
        SET.</t>
        set.</t>
      </section>
    </section>
    <section anchor="SRSTRUCTTLV" title="SRv6 numbered="true" toc="default">
      <name>SRv6 SID Structure TLV"> TLV</name>
      <t>The SRv6 SID Structure TLV is used to advertise the length of each
      individual part of the SRv6 SID as defined in <xref target="RFC8986"/>. target="RFC8986" format="default"/>.
      It is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID
      NLRI and as a sub-TLV of the SRv6 End.X SID, IS-IS SRv6 LAN End.X SID,
      and OSPFv3 SRv6 LAN End.X SID TLVs.</t>
      <t>When advertising SRv6 SIDs from the IGPs, the SRv6 SID Structure
      information is derived from the IS-IS SRv6 SID Structure sub-sub-TLV
      (section 9 of <xref target="I-D.ietf-lsr-isis-srv6-extensions"/>)
      (<xref target="RFC9352" sectionFormat="of" section="9"/>) or the
      OSPFv3 SRv6 SID Structure sub-TLV (section 10 of <xref
      target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) (<xref target="RFC9513" sectionFormat="of" section="10"/>) in the case of IS-IS or
      OSPFv3
      OSPFv3, respectively.</t>
      <t>When advertising the SRv6 SIDs corresponding to the BGP EPE
      functionality or for advertising SRv6 SIDs using Direct as the Protocol-ID, the
      SRv6 SID Structure information is derived from the locally provisioned
      SRv6 SID.</t>
      <t>The TLV has the following format:</t>

      <t><figure anchor="SRSIDSTRUCT" title="SRv6
      <figure anchor="SRSIDSTRUCT">
        <name>SRv6 SID Structure TLV">
          <artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    LB Length  |  LN Length    | Fun. Length   |  Arg. Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>Where:<list>
          <t>Type: 1252</t>

          <t>Length: 4</t>

          <t>LB Length: 1 octet
      </figure>

      <t>where:</t>

<dl newline="false" spacing="normal">
        <dt>Type:</dt><dd>1252</dd>
        <dt>Length:</dt><dd>4</dd>
        <dt>LB Length:</dt><dd>1-octet field. SRv6 SID Locator Block length in
          bits.</t>

          <t>LN Length: 1 octet
          bits.</dd>
        <dt>LN Length:</dt><dd>1-octet field. SRv6 SID Locator Node length in
          bits.</t>

          <t>Fun. Length: 1 octet
          bits.</dd>
        <dt>Fun. Length:</dt><dd>1-octet field. SRv6 SID Function length in bits.</t>

          <t>Arg. Length: 1 octet bits.</dd>
        <dt>Arg. Length:</dt><dd>1-octet field. SRv6 SID Argument length in bits.</t>
        </list></t> bits.</dd>
      </dl>

      <t>The sum of the LB Length, LN Length, Func. Fun. Length, and Arg. Length
      MUST
      <bcp14>MUST</bcp14> be less than or equal to 128.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests assigning numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>Per this document, IANA has allocated code points from in the IANA "Border
      Gateway Protocol - Link State (BGP-LS) Parameters" registry group group, as
      described in the subsections below.</t>
      <section anchor="NLRITYPES" title="BGP-LS NLRI-Types">
        <t>The numbered="true" toc="default">
        <name>BGP-LS NLRI Types</name>
        <t>IANA has assigned the following code points have been assigned by IANA from in the
        registry called
         "BGP-LS NLRI-Types":</t>

        <t><figure anchor="IANANLRI" title="SRv6 SID NLRI Type Code Point">
            <artwork><![CDATA[ +------+----------------------------+---------------+
 | Type | NLRI Type                  |   Reference   |
 +------+----------------------------+---------------+
 |  6   | SRv6 SID Types" registry:</t>
<table anchor="IANANLRI">
  <name>Addition to BGP-LS NLRI              | this document |
 +------+----------------------------+---------------+
]]></artwork>
          </figure></t> Types Registry</name>
  <thead>
    <tr>
      <th>Type</th>
      <th>NLRI Type</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>6</td>
      <td>SRv6 SID NLRI</td>
      <td>RFC 9514</td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="BGPLSTLVS" title="BGP-LS TLVs">
        <t>The numbered="true" toc="default">
        <name>BGP-LS NLRI and Attribute TLVs</name>
        <t>IANA has assigned the following TLV code points have been assigned by IANA from in the
        registry called "BGP-LS Node Descriptor, Link Descriptor, Prefix
        Descriptor, NLRI and Attribute TLVs":</t>

        <t><figure anchor="ATTRTYPES"
            title="SRv6 TLVs" registry:</t>
<table anchor="ATTRTYPES">
  <name>Additions to BGP-LS NLRI and Attribute TLV Code Points">
            <artwork><![CDATA[+----------+----------------------------------------+---------------+
| TLV TLVs Registry</name>
  <thead>
    <tr>
      <th>TLV Code |             Description                | Value defined |
|  Point   |                                        |       in      |
+----------+----------------------------------------+---------------+
|   518    |   SRv6 SID Information                 | this document |
|  1038    |   SRv6 Capabilities                    | this document |
|  1106    |   SRv6 End.X SID                       | this document |
|  1107    |   IS-IS Point</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>518</td>
      <td>SRv6 SID Information</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>1038</td>
      <td>SRv6 Capabilities</td>
      <td>RFC 9514</td>
</tr>
    <tr>
      <td>1106</td>
      <td>SRv6 End.X SID</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>1107</td>
      <td>IS-IS SRv6 LAN End.X SID             | this document |
|  1108    |   OSPFv3 SID</td>
      <td>RFC 9514</td>
</tr>
    <tr>
      <td>1108</td>
      <td>OSPFv3 SRv6 LAN End.X SID            | this document |
|  1162    |   SRv6 Locator                         | this document |
|  1250    |   SRv6 SID</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>1162</td>
      <td>SRv6 Locator</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>1250</td>
      <td>SRv6 Endpoint Behavior               | this document |
|  1251    |   SRv6 Behavior</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>1251</td>
      <td>SRv6 BGP Peer Node SID               | this document |
|  1252    |   SRv6 SID Structure                   | this document |
+----------+----------------------------------------+---------------+]]></artwork>
          </figure></t> PeerNode SID</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>1252</td>
      <td>SRv6 SID Structure</td>
      <td>RFC 9514</td>
</tr>
  </tbody>
</table>
      </section>
      <section anchor="BGPEPEFLAGS" title="SRv6 numbered="true" toc="default">
        <name>SRv6 BGP EPE SID Flags">
        <t>This document requests the creation of Flags</name>
        <t>Per this document, IANA has created a new registry called "SRv6
        BGP EPE SID Flags" under the "Border Gateway Protocol - Link State
        (BGP-LS) Parameters" registry group. The allocation policy of this
        registry is "Standards Action" according to <xref
        target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>The following flags initial contents of the registry are defined: <figure anchor="EPEFLAGS"
            title="SRv6 as follows:</t>
<table anchor="EPEFLAGS">
  <name>New SRv6 BGP EPE SID Flags">
            <artwork align="center"><![CDATA[ Bit     Description                   Reference
---------------------------------------------------
   0     Backup Flags Registry</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Backup Flag (B-Flag)        This document
   1     Set (B-Flag)</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Set Flag (S-Flag)           This document
   2     Persistent (S-Flag)</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Persistent Flag (P-Flag)    This document
 3-7     Unassigned                              ]]></artwork>
          </figure></t> (P-Flag)</td>
      <td>RFC 9514</td>
    </tr>
    <tr>
      <td>3-7</td>
      <td>Unassigned</td>
      <td></td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>This section is structured as recommended in <xref
      target="RFC5706"/>.</t> target="RFC5706" format="default"/>.</t>
      <t>The new protocol extensions introduced in this document augment the
      existing IGP topology information that is distributed via <xref
      target="RFC7752"/>. target="RFC7752" format="default"/>. Procedures and protocol extensions defined in this
      document do not affect the BGP protocol operations and management other
      than as discussed in the Manageability Considerations section Section <xref target="RFC7752" sectionFormat="bare" section="6">Manageability Considerations</xref> of <xref target="RFC7752"/>. Specifically, the malformed attribute tests for
      syntactic checks in the Fault Management section Section <xref target="RFC7752" sectionFormat="bare" section="6.2.2">Fault Management</xref> of <xref target="RFC7752"/> now encompass the new BGP-LS extensions defined in
      this document. The semantic or content checking for the TLVs specified
      in this document and their association with the BGP-LS NLRI types or
      their BGP-LS Attribute is are left to the consumer of the BGP-LS information
      (e.g., an application or a controller) and not the BGP protocol.</t> BGP.</t>
      <t>The SR information introduced in BGP-LS by this specification may be
      used by BGP-LS consumer applications like an SR path computation engine Path Computation Engine
      (PCE) to learn the SRv6 capabilities of the nodes in the topology and the
      mapping of SRv6 segments to those nodes. This can enable the SR PCE
      to perform path computations based on SR for traffic engineering
      use-cases traffic-engineering
      use cases and to steer traffic on paths different from the underlying
      IGP based
      IGP-based distributed best path computation. Errors in the encoding or
      decoding of the SRv6 information may result in the unavailability of
      such information to the SR PCE or incorrect information being made
      available to it. This may result in the SR PCE not being able to perform
      the desired SR-based optimization functionality or to perform performing it in an
      unexpected or inconsistent manner. The handling of such errors by
      applications like SR PCE may be implementation-specific implementation specific and out of the
      scope of this document.</t>
      <t>The manageability considerations related to BGP EPE functionality are
      discussed in <xref target="RFC9086"/> target="RFC9086" format="default"/> in the context of SR-MPLS and SR-MPLS; they
      also apply to this document in the context of SRv6.</t>
      <t>The extensions, extensions specified in this document, document do not introduce any new
      configuration or monitoring aspects in BGP or BGP-LS other than as
      discussed in <xref target="RFC7752"/>. target="RFC7752" format="default"/>. The manageability aspects of the
      underlying SRv6 features are covered by <xref
      target="I-D.ietf-spring-srv6-yang"/>.</t> target="I-D.ietf-spring-srv6-yang" format="default"/>.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The new protocol extensions introduced in this document augment the
      existing IGP topology information that is distributed via <xref
      target="RFC7752"/>.
      target="RFC7752" format="default"/>. The advertisement of the SRv6
      link-state information defined in this document presents a similar risk
      as associated with the existing set of link-state information as described in
      <xref
      target="RFC7752"/>. The Security Considerations section target="RFC7752" format="default"/>.  Section <xref target="RFC7752"
      sectionFormat="bare" section="8">Security Considerations</xref> of <xref target="RFC7752"/> also applies to these extensions. The
      procedures and new TLVs defined in this document, by themselves, do not
      affect the BGP-LS security model discussed in <xref target="RFC7752"/>.</t> target="RFC7752"
      format="default"/>.</t>
      <t>The extensions introduced in this document are used to propagate IGP
      defined
      IGP-defined information (<xref target="I-D.ietf-lsr-isis-srv6-extensions"/>
      and <xref target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>). target="RFC9352" format="default"/> <xref
      target="RFC9513" format="default"/>. These extensions represent the
      advertisement of SRv6 information associated with the IGP node, link,
      and prefix. The IGP instances originating these TLVs are assumed to
      support all the required security and authentication mechanisms (as
      described in <xref
      target="I-D.ietf-lsr-isis-srv6-extensions"/> target="RFC9352" format="default"/> and <xref
      target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>).</t>
      target="RFC9513" format="default"/>).</t>
      <t>The security considerations related to BGP EPE functionality are
      discussed in <xref target="RFC9086"/> target="RFC9086" format="default"/> in the context of SR-MPLS SR-MPLS, and they
      also apply to this document in the context of SRv6.</t>
      <t>BGP-LS SRv6 extensions enable traffic engineering use-cases traffic-engineering use cases within
      the Segment Routing SR domain. SR operates within a trusted domain <xref
      target="RFC8402"/> target="RFC8402" format="default"/>, and its security considerations also apply to BGP-LS
      sessions when carrying SR information. The SR traffic engineering traffic-engineering
      policies using the SIDs advertised via BGP-LS are expected to be used
      entirely within this trusted SR domain (e.g., between multiple AS or IGP
      domains within a single provider network). Therefore, precaution is
      necessary to ensure that the link-state information (including SRv6
      information) advertised via BGP-LS sessions is securely limited to
      consumers within this trusted SR domain. BGP peering sessions for
      address-families
      address families other than Link-State Link State may be set up to routers outside
      the SR domain. The isolation of BGP-LS peering sessions is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
      to ensure that BGP-LS topology information (including the newly added SR
      information) is not advertised to an external BGP peering session
      outside the SR domain.</t>
    </section>

    <section title="Contributors">
      <figure>
        <artwork><![CDATA[James Uttaro
AT&T
USA
Email: ju1738@att.com
]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Hani Elmalky
Ericsson
USA
Email: hani.elmalky@gmail.com
]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Arjun Sreekantiah
Individual
USA
Email: arjunhrs@gmail.com
]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Les Ginsberg
Cisco Systems
USA
Email: ginsberg@cisco.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Shunwan Zhuang
Huawei
China
Email: zhuangshunwan@huawei.com]]></artwork>
      </figure>

      <t/>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Peter Psenak, Arun Babu, Pablo
      Camarillo, Francois Clad, Peng Shaofu, Cheng Li, Dhruv Dhody, Tom Petch,
      and Dan Romascanu for their review
  </middle>
  <back>

<displayreference target="I-D.ietf-spring-srv6-yang" to="SRV6-YANG"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9352.xml"/>

<!-- [I-D.ietf-lsr-ospfv3-srv6-extensions] in EDIT state as of this 07/07/23; companion document and their comments.
      The authors would also like to thank Susan Hares for her shepherd review
      and Adrian Farrel RFC 9513 -->
<reference anchor="RFC9513" target="https://www.rfc-editor.org/info/rfc9513">
<front>
<title>OSPFv3 Extensions for his detailed Segment Routing Directorate review.</t>
    </section>
  </middle>

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

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

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

      <?rfc include='reference.I-D.ietf-lsr-isis-srv6-extensions.xml'?>

      <?rfc include='reference.I-D.ietf-lsr-ospfv3-srv6-extensions.xml'?>

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

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

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

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

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

      <?rfc include='reference.RFC.8814.xml'?> over IPv6 (SRv6)</title>
<author initials="Z." surname="Li" fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="Z." surname="Hu" fullname="Zhibo Hu">
<organization>Huawei Technologies</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Psenak" fullname="Peter Psenak">
<organization>Cisco Systems</organization>
</author>
<date month="November" year="2023"/>
</front>
<seriesInfo name="RFC" value="9513"/>
<seriesInfo name="DOI" value="10.17487/RFC9513"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9085.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8814.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5706.xml"/>

<!-- [I-D.ietf-spring-srv6-yang] IESG state Expired -->
<reference anchor="I-D.ietf-spring-srv6-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-yang-02">
<front>
<title>YANG Data Model for SRv6 Base and Static</title>
<author fullname="Syed Raza" initials="S." surname="Raza">
<organization>Cisco Systems</organization>
</author>
<author fullname="Sonal Agarwal" initials="S." surname="Agarwal">
<organization>Cisco Systems</organization>
</author>
<author fullname="Xufeng Liu" initials="X." surname="Liu">
<organization>Volta Networks</organization>
</author>
<author fullname="Zhibo Hu" initials="Z." surname="Hu">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Iftekhar Hussain" initials="I." surname="Hussain">
<organization>Infinera Corporation</organization>
</author>
<author fullname="Himanshu C. Shah" initials="H. C." surname="Shah">
<organization>Ciena Corporation</organization>
</author>
<author fullname="Daniel Voyer" initials="D." surname="Voyer">
<organization>Bell Canada</organization>
</author>
<author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
<organization>SoftBank</organization>
</author>
<author fullname="Katsuhiro Horiba" initials="K." surname="Horiba">
<organization>SoftBank</organization>
</author>
<author fullname="Jaganbabu Rajamanickam" initials="J." surname="Rajamanickam">
<organization>Cisco Systems</organization>
</author>
<author fullname="Ahmed Abdelsalam" initials="A." surname="Abdelsalam">
<organization>Cisco Systems</organization>
</author>
<date day="23" month="September" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-yang-02"/>
</reference>
      </references>

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

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

      <?rfc include='reference.I-D.ietf-spring-srv6-yang.xml'?>
    </references>
    <section anchor="BGPEPE" title="Differences numbered="true" toc="default">
      <name>Differences with BGP-EPE for SR-MPLS"> SR-MPLS</name>
      <t>The signaling of SRv6 SIDs corresponding to BGP-EPE functionality as
      defined in this document differ differs from the signaling of SR-MPLS BGP-EPE
      SIDs as specified in <xref target="RFC9086"/>. target="RFC9086" format="default"/>. This section provides a
      high-level overview of the same.</t>
      <t>There is no difference in the advertisement of the BGP Peer Adjacency
      SID in both SR-MPLS and SRv6 SRv6, and it is advertised as an attribute of the
      Link NLRI NLRI, which identifies a specific Layer 3 interface on the BGP
      Speaker. The difference is in the advertisement of the BGP Peer Node PeerNode and
      Peer Set
      PeerSet SIDs.</t>
      <t>In the case of SR-MPLS, an additional Link NLRI is required to be
      advertised corresponding to each BGP Peering peering session on the node. Note
      that,
      that this is not the same Link NLRI associated with the actual layer Layer 3
      interface even when the peering is set up using the interface IP
      addresses. These BGP-LS Link NLRIs are not really links in the
      conventional link-state routing data model but instead identify BGP
      peering sessions. The BGP Peer Node PeerNode and/or Peer Set PeerSet SIDs associated with
      that peering session are advertised as attributes associated with this
      peering Link NLRI. In the case of SRv6, each BGP Peer Node PeerNode or Peer Set PeerSet
      SID is considered to be associated with the BGP Speaker node Node and is
      advertised using the BGP-LS SRv6 SID NLRI NLRI, while the peering session
      information is advertised as attributes associated with it.</t>
      <t>The advertisement of the BGP Peer Set PeerSet SID for SR-MPLS is done by
      including that SID as an attribute in all the Link NLRIs corresponding
      to the peering sessions that are part of the "set". The advertisement of
      the BGP Peer Set PeerSet SID for SRv6 is advertised using a single SRv6 SID NLRI NLRI,
      and all the peers associated with that "set" are indicated as attributes
      associated with the NLRI.</t>

      <t/>
    </section>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Peter Psenak"/>,
      <contact fullname="Arun Babu"/>, <contact fullname="Pablo Camarillo"/>,
      <contact fullname="Francois Clad"/>, <contact fullname="Peng Shaofu"/>,
      <contact fullname="Cheng Li"/>, <contact fullname="Dhruv Dhody"/>,
      <contact fullname="Tom Petch"/>, and <contact fullname="Dan Romascanu"/>
      for their review of this document and their comments.  The authors would
      also like to thank <contact fullname="Susan Hares"/> for her shepherd
      review and <contact fullname="Adrian Farrel"/> for his detailed Routing Area
      Directorate review.</t>
    </section>
    <section numbered="false" toc="default">
      <name>Contributors</name>
      <contact fullname="James Uttaro" >
        <organization>AT&amp;T</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>ju1738@att.com</email>
        </address>
      </contact>

      <contact fullname="Hani Elmalky">
        <organization>Ericsson</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>hani.elmalky@gmail.com</email>
        </address>
      </contact>

      <contact fullname="Arjun Sreekantiah">
        <organization>Individual</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>arjunhrs@gmail.com</email>
        </address>
      </contact>

      <contact fullname="Les Ginsberg">
        <organization>Cisco Systems</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>ginsberg@cisco.com</email>
        </address>
      </contact>
      <contact fullname="Shunwan Zhuang">
        <organization>Huawei</organization>
        <address>
          <postal>
            <country>China</country>
          </postal>
          <email>zhuangshunwan@huawei.com</email>
        </address>
      </contact>
    </section>
  </back>
</rfc>