<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-li-lsvr-bgp-spf-srv6-00" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.27.0 -->
  <front>
    <title abbrev="BGP-SPF SRv6">Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF</title>
    <seriesInfo name="Internet-Draft" value="draft-li-lsvr-bgp-spf-srv6-00"/>
    <author initials="L." surname="Zhang" fullname="Li Zhang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No. 156 Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhangli344@huawei.com</email>
      </address>
    </author>
    <author initials="J." surname="Dong" fullname="Jie Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No. 156 Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <date year="2025" month="February" day="25"/>
    <area>Routing</area>
    <workgroup>LSVR</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 41?>

<t>For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI.</t>
    </abstract>
  </front>
  <middle>
    <?line 45?>

<section anchor="intro">
      <name>Introduction</name>
      <t>For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol <xref target="RFC4271"/> and BGP-LS protocol extensions <xref target="RFC9552"/>, with the extensions to BGP-LS attribute and new NLRI selection rules defined in <xref target="I-D.ietf-lsvr-bgp-spf"/>.</t>
      <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 called "segments". SRv6 provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain.</t>
      <t>In networks where BGP-LS-SPF is used as the underlay routing protocol, it may be useful to enable SRv6 based source routing mechanism for traffic engineering and optimization. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI, and discusses which SRv6 extensions can be applied to BGP-LS-SPF SAFI.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="srv6-node-attribute-tlvs">
      <name>SRv6 Node Attribute TLVs</name>
      <t>Based on <xref target="RFC9514"/>, the following SRv6 Node Attributes TLV <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF.</t>
      <table anchor="ref-to-tab4">
        <name>Node Attribute TLVs for SRv6 with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1138</td>
            <td align="left">SRv6 Capabilities TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">266</td>
            <td align="left">Node MSD TLV</td>
            <td align="left">RFC 8814</td>
          </tr>
          <tr>
            <td align="left">1035</td>
            <td align="left">SR Algorithm TLV</td>
            <td align="left">RFC 9085</td>
          </tr>
        </tbody>
      </table>
      <section anchor="srv6-capabilities-tlv">
        <name>SRv6 Capabilities TLV</name>
        <t>The SRv6 Capabilities TLV defined in <xref target="RFC9514"/> 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.</t>
        <t>For BGP-LS-SPF, it <bcp14>SHOULD</bcp14> support this TLV to announce the SRv6 capabilities of BGP-LS-SPF nodes. A single instance of this TLV <bcp14>MUST</bcp14> be included in the BGP-SPF Node Attribute for each SRv6-capable node. <xref target="RFC9514"/> defines the value of this TLV is copied from the ISIS SRv6 Capabilities sub-TLV or from the OSPFv3 SRv6 Capabilities TLV, but both of them have the same flag definition, therefore, the flags format of SRv6 Capabilities TLV of BGP-LS-SPF is consistent with that in ISIS SRv6 Capabilities sub-TLV and OSPFv3 SRv6 Capabilities TLV.</t>
      </section>
      <section anchor="srv6-node-msd-types">
        <name>SRv6 Node MSD Types</name>
        <t>The Node MSD TLV defined in <xref target="RFC8814"/> is used to advertise the limits and the Segment Routing Header (SRH) operations supported by the SRv6-capable node.</t>
        <t>For BGP-LS-SPF, it <bcp14>SHOULD</bcp14> support this TLV to advertise the limits and operations supported by BGP-LS-SPF node to enable segment routing. The SRv6 MSD types specified in <xref section="4" sectionFormat="of" target="RFC9352"/> are also used with the BGP-LS-SPF Node MSD TLV.</t>
        <t>The SRv6 Node MSD TLV is an optional TLV, for a specific MSD type, if the advertised value is zero or no value is advertised, then the headend can apply an SR Policy that only contains one segment without inserting any SRH header.</t>
      </section>
      <section anchor="sr-algorithm-tlv">
        <name>SR-Algorithm TLV</name>
        <t><xref target="RFC9514"/> specifies that the algorithm support for SRv6 is advertised via the SR-Algorithm TLV specified in <xref target="RFC9085"/>. The SR-Algorithm is used to advertise the SR algorithms supported by the node.</t>
        <t>This TLV is a basic TLV of SR and <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF. The format of Algorithm fields in this TLV is consistent with that in ISIS, as defined in <xref section="3.2" sectionFormat="of" target="RFC8667"/>.</t>
        <t>The SR-Algorithm TLV is an optional TLV, when the originating router does not advertise the SR-Algorithm TLV, it implies that algorithm 0 is the only algorithm supported by the router.</t>
      </section>
    </section>
    <section anchor="srv6-link-attribute-tlvs">
      <name>SRv6 Link Attribute TLVs</name>
      <t>Based on <xref target="RFC9514"/> and <xref target="RFC9085"/>, the following Link Attributes <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF.</t>
      <table anchor="ref-to-tab5">
        <name>Link Attribute TLVs for SRv6 with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1106</td>
            <td align="left">SRv6 End.X SID TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">1106</td>
            <td align="left">L2 Bundle Member Attributes TLV</td>
            <td align="left">RFC 9085</td>
          </tr>
          <tr>
            <td align="left">267</td>
            <td align="left">SRv6 Link MSD TLV</td>
            <td align="left">RFC 8814</td>
          </tr>
        </tbody>
      </table>
      <section anchor="srv6-endx-sid-tlv">
        <name>SRv6 End.X SID TLV</name>
        <t>The SRv6 End.X SID TLV defined in <xref target="RFC9514"/> 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. It 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"/>.</t>
        <t>BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to advertise the SRv6 SIDs correspond to a point-to-point or adjacency of the node running the BGP-LS-SPF.</t>
      </section>
      <section anchor="l2-bundele-member-attributes-tlv">
        <name>L2 Bundele Member Attributes TLV</name>
        <t>The L2 Bundle Member Attributes TLV is defined in <xref target="RFC9085"/>, it identifies an L2 Bundle Member link, which in turn is associated with a parent L3 link. The TLV <bcp14>MAY</bcp14> include sub-TLVs that describe attributes associated with the bundle member.</t>
        <t>The network deployed BGP-LS-SPF may include trunk links. Therefore, BGP-LS-SPF <bcp14>MAY</bcp14> support this TLV to advertise L2 bundle member link attributes.</t>
      </section>
      <section anchor="srv6-link-msd-types">
        <name>SRv6 Link MSD Types</name>
        <t>The Link MSD TLV defined in <xref target="RFC8814"/> is used to advertise the limits and the SRH operations supported on the specific link by the SRv6-capable node. BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to advertise the limits and operations supported on the specific link to enable segment routing. The SRv6 MSD types specified in <xref section="4" sectionFormat="of" target="RFC9352"/> are also used with the BGP-LS-SPF Link MSD TLV.</t>
        <t>The SRv6 Link MSD TLV is an optional TLV, for a specific MSD type, if the advertised value is zero or no value is advertised, then the headend can apply an SR Policy that only contains one segment without inserting any SRH header.</t>
      </section>
    </section>
    <section anchor="srv6-prefix-attribute-tlvs">
      <name>SRv6 Prefix Attribute TLVs</name>
      <t>Based on <xref target="RFC9514"/>, the BGP-LS SRv6 Prefix Attributes only includes the SRv6 Locator TLV. This TLV <bcp14>SHOULD</bcp14> be supported by BGP-LS-SPF.</t>
      <table anchor="ref-to-tab6">
        <name>Prefix Attribute TLVs for SRv6 with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1162</td>
            <td align="left">SRv6 Locator TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
        </tbody>
      </table>
      <section anchor="srv6-locator-tlv">
        <name>SRv6 Locator TLV</name>
        <t>The SRv6 Locator TLV defined in <xref target="RFC9514"/> is used to advertise the locators supported by each node. Each locator is advertised in a SRv6 Locator TLV. Locator is the key component of SRv6 SID, BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to enable segment routing.</t>
        <t>The flags fields of this TLV in BGP-LS-SPF is not used and <bcp14>MUST</bcp14> be set to zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt.</t>
      </section>
    </section>
    <section anchor="srv6-sid-nlri">
      <name>SRv6 SID NLRI</name>
      <t>The SRv6 SID NLRI defined in <xref target="RFC9514"/> is used to carry the SRv6 SID information. When SRv6 SIDs need to be advertised in BGP-SPF, the following NLRI type and attributes TLV for SRv6 SID <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF SAFI:</t>
      <table anchor="ref-to-tab7">
        <name>SRv6 SID NLRI with BGP-LS-SPF</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">NLRI Type</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">6</td>
            <td align="left">SRv6 SID NLRI</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">518</td>
            <td align="left">SRv6 SID Information TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">1250</td>
            <td align="left">SRv6 Endpoint Behavior TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
          <tr>
            <td align="left">1252</td>
            <td align="left">SRv6 SID Structure TLV</td>
            <td align="left">RFC 9514</td>
          </tr>
        </tbody>
      </table>
      <t>The format of local node descriptors in this NLRI is consistent with BGP-LS local node descriptors <xref section="5.2.1.2" sectionFormat="of" target="RFC9552"/>, which <bcp14>MAY</bcp14> contain the Autonomous System and BGP-LS Identifier sub-TLV.</t>
      <section anchor="srv6-sid-information-tlv">
        <name>SRv6 SID Information TLV</name>
        <t>The SRv6 SID Information TLV is used to carry the SRv6 SID associated with a node in a SRv6 SID NLRI. This TLV <bcp14>SHOULD</bcp14> be supported in BGP-LS-SPF to advertise SRv6 SIDs.</t>
      </section>
      <section anchor="srv6-endpoint-behavior-tlv">
        <name>SRv6 Endpoint Behavior TLV</name>
        <t>The Endpoint Behavior TLV defined in <xref target="RFC9514"/> is a mandatory TLV included in the BGP-LS Attribute, used to advertise the behaviors associated with a SID. The BGP-LS-SPF <bcp14>SHOULD</bcp14> support this TLV to enable advertisement of behaviors associated with a SRv6 SID.</t>
      </section>
      <section anchor="srv6-sid-structure-tlv">
        <name>SRv6 SID Structure TLV</name>
        <t>The SRv6 SID Structure TLV defined in <xref target="RFC9514"/> is used to advertise the length of each individual part of the SRv6 SID as defined in <xref target="RFC8986"/>. It is an optional TLV in the BGP-LS Attribute for SRv6 SID NLRI and a sub-TLV of the SRv6 End.X SID. BGP-LS-SPF <bcp14>MAY</bcp14> support this TLV to indicate the length of each individual part of the SRv6 SID of BGP-LS-SPF especially in some scenarios using compressed SID.</t>
      </section>
    </section>
    <section anchor="operational-considerations">
      <name>Operational Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document introduces no additional security vulnerabilities in addition to the ones as described in <xref target="RFC9552"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC9552" target="https://www.rfc-editor.org/info/rfc9552" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml">
          <front>
            <title>Distribution of Link-State and Traffic Engineering Information Using BGP</title>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <date month="December" year="2023"/>
            <abstract>
              <t>In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.</t>
              <t>This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.</t>
              <t>Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
              <t>This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9552"/>
          <seriesInfo name="DOI" value="10.17487/RFC9552"/>
        </reference>
        <reference anchor="I-D.ietf-lsvr-bgp-spf" target="https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf-51" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsvr-bgp-spf.xml">
          <front>
            <title>BGP Link-State Shortest Path First (SPF) Routing</title>
            <author fullname="Keyur Patel" initials="K." surname="Patel">
              <organization>Arrcus, Inc.</organization>
            </author>
            <author fullname="Acee Lindem" initials="A." surname="Lindem">
              <organization>LabN Consulting, LLC</organization>
            </author>
            <author fullname="Shawn Zandi" initials="S." surname="Zandi">
              <organization>LinkedIn</organization>
            </author>
            <author fullname="Wim Henderickx" initials="W." surname="Henderickx">
              <organization>Nokia</organization>
            </author>
            <date day="23" month="January" year="2025"/>
            <abstract>
              <t>Many Massively Scaled Data Centers (MSDCs) have converged on simplified L3 (Layer 3) routing. Furthermore, requirements for operational simplicity has led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lsvr-bgp-spf-51"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9514" target="https://www.rfc-editor.org/info/rfc9514" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9514.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)</title>
            <author fullname="G. Dawra" initials="G." surname="Dawra"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <author fullname="D. Bernier" initials="D." surname="Bernier"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <date month="December" year="2023"/>
            <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 called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3.</t>
              <t>This document defines extensions to BGP - 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, which is defined in RFC 9085.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9514"/>
          <seriesInfo name="DOI" value="10.17487/RFC9514"/>
        </reference>
        <reference anchor="RFC8814" target="https://www.rfc-editor.org/info/rfc8814" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8814.xml">
          <front>
            <title>Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State</title>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
            <author fullname="K. Talaulikar" initials="K." surname="Talaulikar"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="N. Triantafillis" initials="N." surname="Triantafillis"/>
            <date month="August" year="2020"/>
            <abstract>
              <t>This document defines a way for a Border Gateway Protocol - Link
State (BGP-LS) speaker to advertise multiple types of supported
Maximum SID Depths (MSDs) at node and/or link granularity.</t>
              <t>Such advertisements allow entities (e.g., centralized controllers) to
determine whether a particular Segment Identifier (SID) stack can be
supported in a given network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8814"/>
          <seriesInfo name="DOI" value="10.17487/RFC8814"/>
        </reference>
        <reference anchor="RFC9352" target="https://www.rfc-editor.org/info/rfc9352" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9352.xml">
          <front>
            <title>IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <date month="February" year="2023"/>
            <abstract>
              <t>The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.</t>
              <t>This document updates RFC 7370 by modifying an existing registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9352"/>
          <seriesInfo name="DOI" value="10.17487/RFC9352"/>
        </reference>
        <reference anchor="RFC9085" target="https://www.rfc-editor.org/info/rfc9085" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9085.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.</t>
              <t>This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9085"/>
          <seriesInfo name="DOI" value="10.17487/RFC9085"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8667" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8667.xml">
          <front>
            <title>IS-IS Extensions for Segment Routing</title>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <date month="December" year="2019"/>
            <abstract>
              <t>Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t>
              <t>This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8667"/>
          <seriesInfo name="DOI" value="10.17487/RFC8667"/>
        </reference>
        <reference anchor="RFC9086" target="https://www.rfc-editor.org/info/rfc9086" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9086.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="S. Ray" initials="S." surname="Ray"/>
            <author fullname="J. Dong" initials="J." surname="Dong"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain.</t>
              <t>This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9086"/>
          <seriesInfo name="DOI" value="10.17487/RFC9086"/>
        </reference>
        <reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
      </references>
    </references>
    <?line 213?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Va63LbNhb+rxm/A9b+E7emxvJFcTRts/IljTryZS2nu92d
/QGRkISGIliClKskfpd9ln2yPecAIAmJip0ms5euZzySSODcL98BGQTBViuX
eSx6rJ+m8VImU3b6/U0wHLGRmM5FkrNbVeR4WS1ExgY3i+6z0e2iu8sufs1F
oqVKNMuV3RSMbl5ttfh4nIlFj67BBYbrt1qRChM+B0ZRxid5EMsg1ossGE/T
QKeTQGeLbrC/v9VSY61ikQvd22oVacTNN/yEjxA+pipb9pjOo62WLsZzqVGI
u2UKpAcXd8B/qyXTrMfyrND5wf7+i/0DkCkTvOd02Wrdq+ztNFNF2mPD0Y+3
W623YgnXIiCR5CJLRB6co5hIjBf5TGXAPGBsq8VkomFTm/11xpESM0oNZXlB
ZVOeyHc8B7F67HXB74VkdyKcJSpWUyk0rBFzLuMee4dbYnl4dPTHGa1rh2oO
t3WeCZH32JVqs85xl50K+Qv64FZx0JqFMgcLwMWfSRkWqiLJ0ShnM5lwlDlw
gv7QZueqJucPUrgLnyDnz1K0I9j1haVMVDYH9gv0LDgtmXi/2+02qRIEjI+B
Fw/JHa9UxsA/6EGmQ5HwTCrNdBHOGNfskkM4LES8ZKOQxyJi5zzn7EygVzV7
djk6P9O7exiaTGomMIYjWAWcwYXJ22CUQ4SxZ8PRLoskMJXjAu3DeBKxfCbY
CEIBIjJnNzyfsVcyg6/PIMh3GY8hMGU+m7Mx10AS2IdFTNZt19KDxQISiU+F
JnpzsDd4Qc81UxM2VkAUZUszlatQxcTXJmR5TZSZ196cpcymKexayAi4caZV
kYWCZXZpyRoE4TnIH6t7XDaBT0zpMSwVaIIwB3XgAlBIRSgnMoRfKQUJKMlS
sMQeu5/JGNThMsnhH+mnIguIliabqgScAnxQa7gNpDVLVCSe6V0kTsYFiVmk
kEgbEhEEngvna73HZA70lyhXocWkiHEb+H8c253G7pu1VFMBXDJ2L42VrUfa
7G4GsQD1qSBTgsVSpQWVNdAmU1EB9FA+9Ew9SgyN3ZpDKJBIGKtSzfGj/qtB
GdFzGUWxwF87WHKICQXa+x3i+fD/F+rv3//h9tXZ0cHzzsPDI3Fv1744Pj54
eNgzDkUWoqEnQcwZ3QQRTcQ9uxreDpgWsTAmz4oYRIzERCagjEyQ+iA4b0uR
T7wm9fBA/ttqPZp1NpnQ1phQ4leJUUosJPEEC4A7glwF8EEppEkN4L5ANxe6
zDGQbbyE1aGKKK1oLfhfi18KuCrInPWEBKaTIiHd4Bf0yMDsgXsYJtvaSK+3
2yZUayXiv7wmoO2hLriSAAxE5uUYBHqBEclNyBUQ8VkMNcNVAxdLn11M0LPQ
kiaouEimEDkiwxUYYirN5dw21n9ncdkj7pDLYaGRBZgfKgVtqBEJeYJac4B7
0viwqUbt7LBbiC+ZCQoVNgSgUkAq4707YA14iSFg0mz78s3obnvPfLKra/p+
e/GnN4Pbi3P8PnrdHw7LLy27YvT6+s3wvPpW7Ty7vry8uDo3m+Eq8y61ti/7
P20bVbevb+4G11f94TZmbe4ZGgCfDViJBTHNRE5x0YJAD6EemEw/Pbv55z86
R7aeHHQ6L6D2mB8nnedH8ANCLDHcKFjNTzD+sgUWFDxDKpAmYNZU5jyGNoWp
OVP3CcPgbLdaX/0NLfP3HvtmHKado+/sBVTYu+hs5l0km61fWdtsjNhwqYFN
aU3v+oqlfXn7P3m/nd1rF795GUMSsKBz8vK7lulrFHlXkM6sX5bgu+GPGu+e
UnqppKzknSOs5BjVE4VVB5OpgYBGCsyqBs7VRZpimzLerHo68mAfvqW/r7/d
+Ld66wPuYjhMwMc5RUpK9dr7+wC5MQHnQvE1vz+DV6dzeAIfpOoZT/lYxtAh
rJ6G16szhvZhFa+A/r4ONv6t3jK8DrpdJEgWBXjgWNT1Al4nJ1+CV2f/8Jj0
Yv0SLVT8rFb7J8efyel9j+1kYoKNNOfjI0bD7LfbDVFXVc8V/Lf9YAteow9c
wWt2kA8aykAu+xB2yCSBwccWeaIS1qlg74Yb2PWgjsCMVaEZi19IF4IsWIVk
EkmcgnVFz+YAogRHyrRKxI+VntTzbOa4LVQzUZEnCVprFMgExo8+05CoMRZZ
6Oi4mfSxRKnMUQUO4yIyZnKKIZEVL6GDBLctKyDmsVPHs66xurHAgseFzxU+
QpVib5tkak6LBqPBqMGDCI1wBwImt/QaBFscNrt7j4GcBrkat83ZjC+MwTSM
1wCT+LSG8qieQXSqTNjSBvcpEGHMRRLNQeVbmtSB3q1zbGs2OGA72PIRtTBc
PqZOux73VVGA4qdd1HulYi3YsVKsBHsESDiX2tgkBhgE2KEcKFZQ82vBAZ4h
ZH69C6AJRoWcEEpV021EN8TDbwjvTaJt4rwS7TWAaAG0g4WI8WzGoKlyNKCD
xc5cIztrHKF3KZQPcXYhmAKoQRkLrqR+lSTWBW2vGnnOkagMQU9C/RStZvwo
AboTDixlik5pksimERB5JzKFCZGo6lq1jsLYJPEMvZdEhCcRTC6RP5T7GxXL
cGlilCATRC/Cf6ggSWU61BSsh3UDSRNyhkH29rWhm1WxGXj9Ay97tcDZWRuO
pFa5wcVBWfo9ZdhCchtfPpNV5xE76FUw/1lX19ZvjH6wRSlJQ1BXcXxXq1wc
Bw/wla0DSANs/DjeIbmqwlKJB1rEgNIdPi4L5OaKQgjWy3UXvIftAyT+ElO/
231ux+E1i2wKx3sXOrAOJiZObsccgiIQKYGjX75mQ58uJbmc4+ii3Yjqbu8j
UyJPU+VqEFSWNyzbNZCKc9dTQSo5pB4Tq6jVJ6Z/X2B1v+vA6kUStf/CRoPz
dVj3RcCq4TU8YKcwxUPRvRTzMQSKPwnUcOTnAePnzOlF7ltBx18MGPtw9djB
1Yb4ewSuVo3b84PXH3wPPQWqruQe0IDdeNikVSh57joUZPbg+xvWj37mIcTV
kniMBWAhiccimJahyjKhU5XYU6JUwRiOatMXbDDllXkR59JcjtEO2LRKynV4
nBUJHSIZRBcA9oGlFuC4gx3ApIOcqk/ZVMtWvq4inrlc3FywG4GR5alTml8l
Fb6LCXbyenc364LLG6BPpn1pCkMXmwUVkdrpylPRSWX6x+34uK3qbcJGjk0r
sSmvXBw9kn5o6PW4slURKzUghNx0Z4iZNWLo7j17TIUNqsgSct1quLEUYBJo
OzykLabZ0YDR/8kNFw712rbgTnmq0991umibsRFoTgKV7cwdukcijdVSRHU8
hqeGjmcOZn5LMmkSymH92nIU8eMOB7N4UpgsqOT2YHpVneow3atZnw3TAYQ1
YmKXCQ5PkpybIfpvCfzHYHmjCP8hYF43ug/MPXf8HoF5CZxuIOLlr592vufe
L2jar41kNr9qZxxDFfIctEdbsxIwN0Erb3L7X4JW3YMSglTKrpzNfQFo5UOQ
roMgjZ584plZTV4/D2p6fDL8iM3mlcmJzodMfbnAr3bVymCHZ/INcTOsFuf2
GUao5tBcMfDdcQy03b0n1q5NVccZwR73mAnMO6JKVk54cPIxD64gcd2xmRY5
cjGJn+DjpkTb1128dXKaQNehbMtEKCBS67MNghk8PfQ84y4+xS0hz7KlB0tY
+aoGPuD6MxaeCrEkwmwbixWP2FO/1XGJxMDqRzpxH1+U8YdcHx2k6PFV74kp
v3LXy3iSib6v/9WT/mkJ38ipa2j53ljjVKb809J95a7hdNw58TgNKuc1PWT4
DE6dg+P92nhoIOqpmwuI1wZOHz7KqX635HRQ12kESCwE/CiqmvklOPm18rmr
lb7TGkujfxyDVSo2wDyyzQQrmzuUITINpzK2U27YXWGX4/ZBu1OdzZSvRRCw
RgBqOz1lXr/IVaLm+IbBaAnM5vV3LQYOsGcOT0MpwdfednY2BtBaYVkNsI/X
knW0T5pWJdwZ+pG+71cCr52UxamcfzaHqNOmOX4/Ui45TAZJhP1laWv8+kMP
sHDZYPc29D03RzfNQaCDwbSf1J9K+nPb5z7KwtrKmzrWUmzN534CfnqzF8nU
PFWhBo8PuRYyKuhNkix3k20tZnwWdCL5wszcdvz3IfcmJ/gNpnzIxqtHQzXO
5XlK+ykDnntQ91v0858ACRoUeEzA2LwUV70NVuADOIIx+PYMGKT0Hbt2ExSw
OcPSErmJitx3em5RggiLTObLpjXeKxXl+yqIV8CBkXSvGDkKiyJOYH/5kAmT
2C5z76woe4LivYZRf53LCj/oX/UbJMJb/fBtou5jEU3Nyyk1baBsszEP3+L3
fwHOIyC83SwAAA==

-->

</rfc>
