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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-idr-bgp-ls-sr-policy-17"
     ipr="trust200902"> number="9857" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Advertising SR Policies using Using BGP-LS">Advertisement of
    Segment Routing Policies using Using BGP Link-State</title>
    <seriesInfo name="RFC" value="9857"/>
    <author fullname="Stefano Previdi" initials="S." surname="Previdi">
      <organization>Individual</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>
        <email>stefano@previdi.net</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <code/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author fullname="Hannes Gredler" initials="H." surname="Gredler">
      <organization>RtBrick Inc.</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>
        <email>hannes@rtbrick.com</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
      <organization>Nvidia</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <date year=""/>

    <area>Routing</area>

    <workgroup>Inter-Domain Routing</workgroup> year="2025" month="September"/>
    <area>RTG</area>
    <workgroup>idr</workgroup>

    <keyword>BGP</keyword>
    <keyword>BGP-LS</keyword>
    <keyword>Segment Routing</keyword>
    <keyword>SR</keyword>
    <keyword>SR Policy</keyword>
    <keyword>SR-MPLS</keyword>
    <keyword>SRv6</keyword>
    <keyword>Traffic Engineering</keyword>
    <keyword>BGP SR Policy</keyword>

    <abstract>
      <t>This document describes a mechanism used to collect the Segment Routing (SR)
      Policy information that is locally available in a node and advertise it
      into BGP Link-State (BGP-LS) updates. Such information can be used by
      external components for path computation, re-optimization, reoptimization, service
      placement, network visualization, etc.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>SR Policy architecture details are specified in <xref
      target="RFC9256"/>. target="RFC9256" format="default"/>. An SR Policy comprises one or more candidate paths
      of which at a given time one and only one may be active (i.e., installed
      in forwarding and usable for the steering of traffic). Each candidate path
      in turn may have one or more SID-List SID-Lists of which one or more SID-List SID-Lists may
      be active. When multiple SID-Lists are active then active, traffic is load
      balanced over them. This document covers the advertisement of state
      information at the individual SR Policy candidate path level.</t>
      <t>SR Policies are generally instantiated at the head-end headend and are based
      on either local configuration or controller-based programming of the
      node using various APIs and protocols (e.g., PCEP the Path Computation Element Communication Protocol (PCEP) or BGP).</t>
      <t>In many network environments, the configuration, configuration and state of each SR
      Policy that is available in the network is required by controllers. Such
      controllers, that which are aware of both topology and SR Policy state
      information, allow the network operator to optimize several functions
      and operations in their networks.</t>

<!--[rfced] May we update "PCEP protocol" to simply read "PCEP" to
avoid redundancy? If expanded, "PCEP protocol" would read as "Path
Computation Element Communication Protocol protocol".

Original:
   As illustrated in the figure below, the
   PCC is not an LSR in the routing domain, thus the head-end nodes of
   the SR Policies may not implement the PCEP protocol.

Perhaps:
   As illustrated in the figure below, the
   PCC is not an LSR in the routing domain, thus the head-end nodes of
   the SR Policies may not implement the PCEP.
-->

      <t>One example of a controller is the stateful Path Computation Element
      (PCE) <xref target="RFC8231"/>, target="RFC8231" format="default"/>, which could can provide benefits in path
      optimization. While some extensions are proposed in the Path Computation
      Element Communication Protocol (PCEP) PCEP for the Path Computation Clients
      (PCCs) to report the LSP Label Switched Path (LSP) states to the PCE, this mechanism may not be
      applicable in a management-based PCE architecture as specified in
      section 5.5 of
      <xref target="RFC4655"/>. target="RFC4655" sectionFormat="of" section="5.5"/>. As illustrated in the figure
      below, the PCC is not an LSR a Label Switching Router (LSR) in the routing domain, thus the head-end headend
      nodes of the SR Policies may not implement the PCEP protocol. In this
      case, a general mechanism to collect the SR Policy states from the
      ingress LERs Label Edge Routers (LERs) is needed. This document proposes an SR Policy state
      collection mechanism complementary to the mechanism defined in <xref
      target="RFC8231"/>.<figure>
          <artwork><![CDATA[ target="RFC8231" format="default"/>.</t>

<figure>
  <name>Management-Based PCE Usage</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
                                 -----------
                                |   -----   |
            Service             |  | TED |<-+----------->
            Request             |   -----   |  TED synchronization
               |                |     |     |  mechanism (e.g., the
               v                |     |     |  routing protocol)
         ------------- Request/ |     v     |
        |             | Response|   -----   |
        |     NMS     |<--------+> | PCE |  |
        |             |         |   -----   |
         -------------           -----------
       Service |
       Request |
               v
          ----------  Signaling   ----------
         | Head-End Headend  | Protocol   | Adjacent |
         |  Node    |<---------->|   Node   |
          ----------              ----------

               Figure 1  Management-Based PCE Usage
]]></artwork>
        </figure></t>              ----------]]></artwork>
</figure>
      <t>In networks with composite PCE nodes as specified in section 5.1 of
      <xref target="RFC4655"/>, target="RFC4655" sectionFormat="of" section="5.1"/>, PCE is implemented on several routers in the
      network, and the PCCs in the network can use the mechanism described in
      <xref target="RFC8231"/> target="RFC8231" format="default"/> to report the SR Policy information to the PCE
      nodes. An external component may also need to collect the SR Policy
      information from all the PCEs in the network to obtain a global view of
      the state of all SR Policy paths in the network.</t>
      <t>In multi-area or multi-AS scenarios, each area or AS can have a child
      PCE to collect the SR Policies in its domain, in domain. In addition, a parent PCE
      needs to collect SR Policy information from multiple child PCEs to
      obtain a global view of SR Policy paths inside and across the domains
      involved.</t>
      <t>In another network scenario, a centralized controller is used for
      service placement. Obtaining the SR Policy state information is quite
      important for making appropriate service placement decisions with the
      purpose of both meeting the application's requirements and utilizing
      network resources efficiently.</t>
      <t>The Network Management System (NMS) may need to provide global
      visibility of the SR Policies in the network as part of the network
      visualization function.</t>
      <t>BGP has been extended to distribute link-state and traffic
      engineering Traffic
      Engineering (TE) information to external components <xref target="RFC9552"/>. target="RFC9552" format="default"/>.
      Using the same protocol to collect SR Policy and state information is
      desirable for these external components since this avoids introducing
      multiple protocols for network topology information collection. This
      document describes a mechanism to distribute SR Policy information (both
      SR-MPLS,
      SR-MPLS and SRv6 <xref target="RFC8402"/>) target="RFC8402" format="default"/>) to external components using
      BGP-LS and covers both explicit and dynamic candidate paths. The
      advertisements of a composite candidate path is are outside the scope of this
      document.</t>
      <t>The BGP-LS Producer <xref target="RFC9552"/> target="RFC9552" format="default"/> that is originating the
      advertisement of SR Policy information can be either:<list
          style="symbols">
          <t>a either:</t>
      <ul spacing="normal">
        <li>
          <t>an SR Policy headend node, node or</t>
        </li>
        <li>
          <t>a PCE which that is receiving the SR Policy information from its PCCs
          (i.e., SR Policy headend nodes) via PCEP</t>
        </list></t>
        </li>
      </ul>
      <t>The extensions specified in this document complement the BGP SR
      Policy SAFI <xref target="I-D.ietf-idr-sr-policy-safi"/> and target="RFC9830" format="default"/> <xref
      target="I-D.ietf-idr-bgp-sr-segtypes-ext"/> that target="RFC9831" format="default"/> and are used to advertise
      SR Policies from controllers to the headend routers using BGP by
      enabling the reporting of the operational state of those SR Policies
      back from the headend to the controllers.</t>
      <t>While this document focuses on SR Policies, <xref
      target="I-D.ietf-idr-bgp-ls-te-path"/> target="I-D.ietf-idr-bgp-ls-te-path" format="default"/> introduces further extension extensions to
      support other TE Paths paths such as MPLS-TE LSPs.</t>
      <t>The encodings specified in this document (specifically in Sections <xref
      target="SRPOLICYCP"/> target="SRPOLICYCP" format="counter"/> and <xref target="SRPOLICYTLVS"/>) target="SRPOLICYTLVS" format="counter"/>) make use of
      flags that convey various types of information of the SR Policy. The
      document uses the term "set" to indicate that the value of a flag bit is
      1 and the term "clear" when the value is 0.</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="TEINFOINBGP"
             title="Carrying numbered="true" toc="default">
      <name>Carrying SR Policy Information in BGP"> BGP</name>
      <t>The "Link-State NLRI" Network Layer Reachability Information (NLRI)" defined in <xref target="RFC9552"/> target="RFC9552" format="default"/> is extended
      to carry the SR Policy information. New TLVs carried in the BGP
      Link-State BGP-LS
      Attribute defined in <xref target="RFC9552"/> target="RFC9552" format="default"/> are also
      defined to carry the attributes of an SR Policy in the subsequent
      sections.</t>
      <t>The format of "Link-State NLRI" the Link-State NLRI is defined in <xref
      target="RFC9552"/> target="RFC9552" format="default"/> as follows:<figure> follows:</t>
      <figure>
  <name>BGP-LS NLRI Format</name>
      <artwork align="center"><![CDATA[ align="center" name="" type="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            NLRI Type          |     Total NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Link-State NLRI (variable)                 //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2  BGP-LS NLRI Format

]]></artwork>
        </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
      <t>An additional "NLRI Type" NLRI Type known as SR "SR Policy Candidate Path NLRI NLRI"
      (value 5) is defined for the advertisement of SR Policy Information.</t>
      <t>This SR Policy Candidate Path NLRI is used to report the state
      details of individual SR Policy Candidate paths along with their
      underlying segment lists.</t>
    </section>
    <section anchor="TEPOLICYNLRI" title="SR numbered="true" toc="default">
      <name>SR Policy Candidate Path NLRI Type"> Type</name>
      <t>This document defines the SR Policy Candidate Path NLRI Type with its
      format as shown in the following figure:</t>

      <t><figure>
<figure>
  <name>SR Policy Candidate Path NLRI Format</name>
      <artwork align="center"><![CDATA[ align="center" name="" type="" 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                             |
|                        (64 bits)                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//        Local Node Descriptor Descriptors TLV (for the Headend)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SR Policy Candidate Path Descriptor TLV           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>

<!--[rfced] In Section 3, should the list be formatted as a definition
list for ease of reading and consistency with other sections?

Original:
  Where:

   *  Protocol-ID field specifies the component that owns the SR Policy
      state in the advertising node.  An additional Protocol-ID "Segment
      Routing" (value 9) is introduced by this document that MUST be
      used for advertisement of SR Policies.

   *  "Identifier" is an 8 octet value as defined in section 5.2 of
      [RFC9552].

   *  "Local Node Descriptor" (TLV 256) [RFC9552] is used as specified
      further in this section.

   *  The SR Policy Candidate Path NLRI Format Descriptor TLV is specified in
      Section 4.

Perhaps:
  Where:
]]></artwork>
        </figure><list style="symbols">

   *  Protocol-ID field: Specifies the component that owns the SR Policy
      state in the advertising node. An additional Protocol-ID "Segment
      Routing" (value 9) is introduced by this document that MUST be
      used for the advertisement of SR Policies.

   *  Identifier: 8-octet value as defined in Section 5.2 of [RFC9552].

   *  Local Node Descriptors (TLV 256): Defined in [RFC9552] and used as
      specified further in this section.

   *  SR Policy Candidate Path Descriptor TLV: Specified in Section 4.
-->

      <ul spacing="normal">
        <li>
          <t>Protocol-ID field specifies the component that owns the SR Policy
          state in the advertising node. An additional Protocol-ID "Segment
          Routing" (value 9) is introduced by this document that MUST <bcp14>MUST</bcp14> be used
          for the advertisement of SR Policies.</t>
        </li>
        <li>
          <t>"Identifier" is an 8 octet 8-octet value as defined in section 5.2 of
          <xref target="RFC9552"/>.</t> target="RFC9552" sectionFormat="of" section="5.2"/>.</t>
        </li>
        <li>
          <t>"Local Node Descriptor" Descriptors" (TLV 256) <xref target="RFC9552"/> target="RFC9552" format="default"/> is
          used as specified further in this section.</t>
        </li>
        <li>
          <t>The SR Policy Candidate Path Descriptor TLV is specified in <xref
          target="SRPOLICYCP"/>.</t>
        </list></t> target="SRPOLICYCP" format="default"/>.</t>
        </li>
      </ul>
      <t>The Local Node Descriptor Descriptors TLV carries information that only
      identifies the headend node of the SR Policy irrespective of whether the
      BGP-LS Producer is a headend or a PCE node.</t>
      <t>The Local Node Descriptor Descriptors TLV MUST <bcp14>MUST</bcp14> include at least one of the
      following Node Descriptor TLVs:<list style="symbols"> TLVs:</t>
      <ul spacing="normal">
        <li>
          <t>IPv4 Router-ID of Local Node (TLV 1028) <xref target="RFC9552"/>, target="RFC9552" format="default"/>,
          which identifies the headend node of the SR Policy as specified in
          section 2.1 of
          <xref target="RFC9256"/>.</t> target="RFC9256" sectionFormat="of" section="2.1"/>.</t>
        </li>
        <li>
          <t>IPv6 Router-ID of Local Node (TLV 1029) <xref target="RFC9552"/>, target="RFC9552" format="default"/>,
          which identifies the headend node of the SR Policy as specified in
          section 2.1 of
          <xref target="RFC9256"/>.</t>
        </list></t> target="RFC9256" sectionFormat="of" section="2.1"/>.</t>
        </li>
      </ul>
      <t>The following sub-sections subsections describe the encoding of sub-TLVs within
      the Local Node Descriptor Descriptors TLV depending on which node is the BGP-LS
      Producer.</t>
      <section title="SR numbered="true" toc="default">
        <name>SR Policy Headend as the BGP-LS Producer"> Producer</name>
        <t>The Local Node Descriptor Descriptors TLV MUST <bcp14>MUST</bcp14> include the following Node
        Descriptor TLVs when the headend node is the BGP-LS Producer:<list
            style="symbols"> Producer:</t>
        <ul spacing="normal">
          <li>
            <t>BGP Router-ID (TLV 516) <xref target="RFC9086"/>, target="RFC9086" format="default"/>, which
            contains a valid BGP Identifier of the headend node of the SR
            Policy.</t>

            <t>Autonomous
          </li>
          <li>

<!--[rfced] As shown below, we removed "Number" from "Autonomous
System Number (TLV 512)" per RFC 9552, and we removed "ASN"
following "AS Confederation Identifier" as it is not present in
RFC 5065. Note that this change was also applied to similar text
in Section 3.2. Please let us know of any objections.

 Note that "ASN" was expanded only on the first mention.

Original:
   *  Autonomous System Number (TLV 512) <xref target="RFC9552"/>, [RFC9552], which contains the
      ASN (or AS Confederation Identifier (ASN) [RFC5065], if
      confederations are used) of the headend node of the SR Policy.

Current:
   *  Autonomous System (TLV 512) [RFC9552], which contains the
      Autonomous System Number (ASN) (or AS Confederation Identifier
      [RFC5065], if confederations are used) of the headend node of
      the SR Policy.
-->

            <t>Autonomous System (TLV 512) <xref
            target="RFC5065"/>, target="RFC9552" format="default"/>,
            which contains the Autonomous System Number (ASN) (or AS Confederation Identifier <xref target="RFC5065" format="default"/>, if confederations are used) of the headend
            node of the SR Policy.</t>
          </list></t>
          </li>
        </ul>
        <t>The Local Node Descriptor Descriptors TLV MAY <bcp14>MAY</bcp14> include the following Node
        Descriptor TLVs when the headend node is the BGP-LS Producer:<list
            style="symbols"> Producer:</t>
        <ul spacing="normal">
          <li>
            <t>BGP Confederation Member (TLV 517) <xref target="RFC9086"/>, target="RFC9086" format="default"/>,
            which contains the ASN of the confederation member (i.e. (i.e., Member-AS
            Number),
            Number); if BGP confederations are used, it contains the headend node of the
            SR Policy.</t>
          </li>
          <li>

<!--[rfced] In RFC 9552, we note that "IGP Router-ID" is listed as
both a sub-TLV and a TLV code point. As "sub-TLV" and "TLV" are
not included in the description, how may we update "IGP Router-ID
sub-TLV (TLV 515)" for conciseness? Would "IGP Router-ID
(sub-TLV/TLV 515)" be correct? Note that there are two instances
in the document.

Original:
   The determination of whether the
   IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID
   or a 6-octet ISO System-ID is to be done based on the length of
   that sub-TLV since the Protocol-ID in the NLRI is always going to
   be "Segment Routing".

Perhaps:
   The determination of whether the
   IGP Router-ID (sub-TLV/TLV 515) contains a 4-octet OSPF Router-ID
   or a 6-octet ISO System-ID is to be done based on the length of
   that sub-TLV because the Protocol-ID in the NLRI is always going
   to be "Segment Routing".
-->

            <t>Other Node Descriptors as defined in <xref target="RFC9552"/> target="RFC9552" format="default"/>
            to identify the headend node of the SR Policy. The determination
            of whether the IGP Router-ID sub-TLV (TLV 515) contains a 4-octet
            OSPF Router-ID or a 6-octet ISO System-ID is to be done based on
            the length of that sub-TLV since as the Protocol-ID in the NLRI is
            always going to be "Segment Routing".</t>
          </list></t>
          </li>
        </ul>
      </section>
      <section title="PCE numbered="true" toc="default">
        <name>PCE as the BGP-LS Producer"> Producer</name>
        <t>The PCE node MUST NOT <bcp14>MUST NOT</bcp14> include its identifiers in the Node
        Descriptor TLV in the NLRI as the Node Descriptor TLV MUST <bcp14>MUST</bcp14> only carry
        the identifiers of the SR Policy headend.</t>
        <t>The Local Node Descriptor Descriptors TLV MAY <bcp14>MAY</bcp14> include the following Node
        Descriptor TLVs when the PCE node is the BGP-LS Producer and it has
        this information about the headend (e.g., as part of its topology
        database):<list style="symbols">
        database):</t>
        <ul spacing="normal">
          <li>
            <t>BGP Router-ID (TLV 516) <xref target="RFC9086"/>, target="RFC9086" format="default"/>, which
            contains a valid BGP Identifier of the headend node of the SR
            Policy.</t>
          </li>
          <li>
            <t>Autonomous System Number (TLV 512) <xref target="RFC9552"/>, target="RFC9552" format="default"/>,
            which contains the ASN (or AS Confederation Identifier (ASN) <xref
            target="RFC5065"/>, target="RFC5065" format="default"/>, if confederations are used) of the headend
            node of the SR Policy.</t>
          </li>
          <li>
            <t>BGP Confederation Member (TLV 517) <xref target="RFC9086"/>, target="RFC9086" format="default"/>,
            which contains the ASN of the confederation member (i.e. (i.e., Member-AS
            Number),
            Number); if BGP confederations are used, it contains the headend node of the
            SR Policy.</t>
          </li>
          <li>
            <t>Other Node Descriptors as defined in <xref target="RFC9552"/> target="RFC9552" format="default"/>
            to identify the headend node of the SR Policy.
	    The determination
            of whether the IGP Router-ID sub-TLV (TLV 515) contains a 4-octet
            OSPF Router-ID or a 6-octet ISO System-ID is to be done based on
            the length of that sub-TLV since the Protocol-ID in the NLRI is
            always going to be "Segment Routing".</t>
          </list></t>
          </li>
        </ul>
        <t>When a Path Computation Element (PCE) PCE node is functioning as the
        BGP-LS Producer on behalf of one or more headends, it MAY <bcp14>MAY</bcp14> include its
        own BGP Router-ID (TLV 516), Autonomous System Number (TLV 512), or
        BGP Confederation Member (TLV 517) in the BGP-LS Attribute.</t>
      </section>
    </section>
    <section anchor="SRPOLICYCP" title="SR numbered="true" toc="default">
      <name>SR Policy Candidate Path Descriptor"> Descriptor</name>
      <t>The SR Policy Candidate Path Descriptor TLV identifies a Segment
      Routing an SR Policy candidate path as defined in <xref target="RFC9256"/>. target="RFC9256" format="default"/>. It
      is a mandatory TLV for the SR Policy Candidate Path NLRI type. The TLV has
      the following format: </t>
<figure>
  <name>SR Policy Candidate Path Descriptor Format</name>
      <artwork align="center"><![CDATA[ align="center" name="" type="" 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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol-origin|
|Protocol-Origin|    Flags      |            RESERVED           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Endpoint (4 or 16 octets)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Policy Color (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Originator AS Number (4 octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Originator Address (4 or 16 octets)             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Discriminator (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4  SR Policy Candidate Path Descriptor Format

Where:
]]></artwork>
        </figure><list style="symbols">
          <t>Type: 554</t>

          <t>Length: variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
      <dl spacing="normal" newline="false">
        <dt>Type:</dt><dd>554</dd>
        <dt>Length:</dt><dd>Variable (valid values are 24, 36 36, or 48 octets)</t>

          <t>Protocol-Origin: 1-octet octets)</dd>
        <dt>Protocol-Origin:</dt><dd>1-octet field which that identifies the protocol or
        component which that is responsible for the instantiation of this path as
        specified in section 2.3 of <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of"
        section="2.3"/>. The protocol-origin codepoints code points to be used are listed
        in <xref
          target="PROTOCOLORIGINS"/>.</t>

          <t>Flags: 1-octet target="PROTOCOLORIGINS" format="default"/>.</dd>
        <dt>Flags:</dt><dd><t>1-octet field with the following bit positions
        defined. Other bits MUST <bcp14>MUST</bcp14> be cleared by the originator
        and MUST <bcp14>MUST</bcp14> be ignored by a
          receiver.<figure>
              <artwork><![CDATA[ receiver.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|E|O|           |
   +-+-+-+-+-+-+-+-+

Where:
]]></artwork>
            </figure><list style="symbols">
              <t>E-Flag: Indicates
+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
          <dl spacing="normal" newline="false">
            <dt>E-Flag:</dt><dd>Indicates the encoding of an endpoint as an IPv6
            address when set and an IPv4 address when clear</t>

              <t>O-Flag: Indicates clear.</dd>
            <dt>O-Flag:</dt><dd>Indicates the encoding of the originator address
            as an IPv6 address when set and an IPv4 address when clear</t>
            </list></t>

          <t>Reserved: 2 clear.</dd>
          </dl>
        </dd>
        <dt>Reserved:</dt><dd>2 octets which MUST that <bcp14>MUST</bcp14> be set to 0
        by the originator and
          MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

          <t>Endpoint: 4
        receiver.</dd>
        <dt>Endpoint:</dt><dd>4 or 16 octets (as indicated by the flags)
        containing the address of the endpoint of the SR Policy as specified
        in section
          2.1 of <xref target="RFC9256"/>.</t>

          <t>Color: 4 target="RFC9256" sectionFormat="of" section="2.1"/>.</dd>
        <dt>Policy  Color:</dt><dd>4 octets that indicate the color of the SR Policy
        as specified in section 2.1 of <xref target="RFC9256"/>.</t>

          <t>Originator ASN: 4 target="RFC9256" sectionFormat="of"
        section="2.1"/>.</dd>
        <dt>Originator ASN:</dt><dd>4 octets to carry the 4-byte encoding of
        the ASN of the originator. Refer to section 2.4 of <xref target="RFC9256"/>
          for details.</t>

          <t>Originator Address: 4 target="RFC9256"
        sectionFormat="of" section="2.4"/> for details.</dd>
        <dt>Originator Address:</dt><dd>4 or 16 octets (as indicated by the
        flags) to carry the address of the originator. Refer to section 2.4 of <xref
          target="RFC9256"/>
        target="RFC9256" sectionFormat="of" section="2.4"/> for details.</t>

          <t>Discriminator: 4 details.</dd>
        <dt>Discriminator:</dt><dd>4 octets to carry the discriminator of the
        path.  Refer to section 2.5 of <xref target="RFC9256"/> target="RFC9256" sectionFormat="of"
        section="2.5"/> for details.</t>
        </list></t> details.</dd>
      </dl>
    </section>
    <section anchor="SRPOLICYTLVS" title="SR numbered="true" toc="default">
      <name>SR Policy State TLVs"> TLVs</name>
      <t>This section defines the various TLVs which that enable the headend to
      report the state at the SR Policy candidate path level. These TLVs (and
      their sub-TLVs) are carried in the optional non-transitive BGP-LS
      Attribute defined in <xref target="RFC9552"/> target="RFC9552" format="default"/> and are associated with the SR
      Policy Candidate Path NLRI type.</t>
      <t>The detailed procedures for the advertisement are described in <xref
      target="Procedures"/>.</t> target="Procedures" format="default"/>.</t>
      <section anchor="CPBSID" title="SR numbered="true" toc="default">
        <name>SR Binding SID TLV"> TLV</name>

<!-- [rfced] We note that Section 6.2.3 of RFC 9256 uses
"Specified-BSID-only". Given this, should "Specified BSID" be
updated for consistency?

Original:
   The TLV MAY also optionally contain the Specified BSID value for
   reporting as described in section 6.2.3 of [RFC9256].

Perhaps:
   The TLV MAY also optionally contain the Specified-BSID-only value
   for reporting as described in Section 6.2.3 of [RFC9256].
-->
        <t>The SR Binding SID Segment Identifier (BSID) is an optional TLV that is used to report
        the BSID and its attributes for the SR Policy candidate path. The TLV
        MAY
        <bcp14>MAY</bcp14> also optionally contain the Specified BSID value for reporting as
        described in section 6.2.3 of <xref target="RFC9256"/>. target="RFC9256"  sectionFormat="of" section="6.2.3"/>. Only a single
        instance of this TLV is advertised for a given candidate path. If
        multiple instances are present, then the first valid one (i.e., not
        determined to be malformed as per section 8.2.2 of <xref
        target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and the rest are ignored.</t>
        <t>The TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Binding SID TLV Format</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           BSID Flags          |            RESERVED           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Binding SID (4 or 16 octets)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Specified Binding SID (4 or 16 octets)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 5  SR Binding SID TLV Format

Where:
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>Type: 1201</t>

            <t>Length: variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>1201</dd>
          <dt>Length:</dt><dd>Variable (valid values are 12 or 36 octets)</t>

            <t>BSID Flags: 2-octet octets)</dd>
          <dt>BSID Flags:</dt><dd><t>2-octet field that indicates the attribute and
          status of the Binding SID (BSID) associated with this candidate
          path. The following bit positions are defined defined, and the semantics are
          described in detail in section 6.2 of <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of"
          section="6.2"/>.  Other bits MUST <bcp14>MUST</bcp14> be cleared by the
          originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                <artwork><![CDATA[ receiver.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|B|U|L|F|                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
]]></artwork>
              </figure><list style="symbols">
                <t>D-Flag:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
<dl spacing="normal" newline="false">

<!--[rfced] Please clarify if "BSID" should be singular (option A) or
plural (option B) in the following:

Original:
 D-Flag:  Indicates the dataplane for the BSIDs and if they are
          16 octet SRv6 SID (when set) or are 4 octet SR/MPLS
          label value (when clear).</t>

                <t>B-Flag: clear).

Perhaps A:
 D-Flag:  Indicates the data plane for the BSIDs and if a BSID is
          a 16-octet SRv6 SID (when set) or a 4-octet SR/MPLS
          label value (when clear).

Perhaps B:
 D-Flag:  Indicates the data plane for the BSIDs and if the BSIDs
          are 16-octet SRv6 SIDs (when set) or 4-octet SR/MPLS
          label values (when clear).
-->

              <dt>D-Flag:</dt><dd>Indicates the data plane for the BSIDs and if
              they are 16-octet SRv6 SID (when set) or 4-octet SR/MPLS
              label value (when clear).</dd>
              <dt>B-Flag:</dt><dd>Indicates the allocation of the value in the
              BSID field when set and indicates that BSID is not allocated
              when
                clear.</t>

                <t>U-Flag: Indicates clear.</dd>
              <dt>U-Flag:</dt><dd>Indicates that the specified BSID value is
              unavailable when set. When clear clear, it indicates that this
              candidate path is using the specified BSID. This flag is ignored
              when there is no specified BSID.</t>

                <t>L-Flag: Indicates BSID.</dd>
              <dt>L-Flag:</dt><dd>Indicates that the BSID value is from the Segment
              Routing Local Block (SRLB) of the headend node when set and is
              from the local dynamic label pool when clear.</t>

                <t>F-Flag: Indicates clear.</dd>
              <dt>F-Flag:</dt><dd>Indicates that the BSID value is one allocated
              from a dynamic label pool due to fallback (e.g. (e.g., when a specified
              BSID is unavailable) when set and indicates that there has been
              no fallback for BSID allocation when clear.</t>
              </list></t>

            <t>RESERVED: 2 clear.</dd>
            </dl>
          </dd>
          <dt>RESERVED:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by
          the originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

            <t>Binding SID: It indicates receiver.</dd>
          <dt>Binding SID:</dt><dd>Indicates the operational or allocated
          BSID value based on the status flags.</t>

            <t>Specified BSID: It is used flags.</dd>
          <dt>Specified BSID:</dt><dd>Used to report the explicitly
          specified BSID value regardless of whether it is successfully
          allocated or not. The field is set to value 0 when the BSID has not been
            specified.</t>
          </list></t>
          specified.</dd>
        </dl>
        <t>The BSID fields above depend on the dataplane data plane (SRv6 or MPLS)
        indicated by the D-Flag. If the D-Flag is set (SRv6 dataplane), data plane), then the
        length of the BSID fields is 16 octets. If the D-Flag is clear (MPLS
        dataplane),
        data plane), then the length of the BSID fields is 4 octets. When
        carrying the MPLS Label, as shown in the figure below, the TC, S, and
        TTL (total of 12 bits) are RESERVED and MUST <bcp14>MUST</bcp14> be set to 0 by the
        originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

        <t><figure>
            <artwork><![CDATA[
<figure>
  <name>SR Binding SID Label 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Label                        | TC  |S|       TTL     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 6  SR Binding SID Label Format
]]></artwork>
          </figure></t>
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
        <t>In the case of an SRv6, the SR Binding SID sub-TLV does not have
        the ability to signal the SRv6 Endpoint Behavior behavior <xref
        target="RFC8986"/>
        target="RFC8986" format="default"/> or the structure of the
        SID. Therefore, the SR Binding SID sub-TLV SHOULD NOT <bcp14>SHOULD NOT</bcp14>
        be used for the advertisement of an SRv6 Binding SID. Instead, the
        SRv6 Binding SID TLV defined in <xref
        target="CPBSIDSRV6"/> SHOULD target="CPBSIDSRV6"
        format="default"/> <bcp14>SHOULD</bcp14> be used for the signaling of an
        SRv6 Binding SID. The use of the SR Binding SID sub-TLV for
        advertisement of the SRv6 Binding SID has been deprecated, and it is
        documented here only for backward compatibility with implementations
        that followed early draft versions of this specification.</t>
      </section>
      <section anchor="CPBSIDSRV6" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Binding SID TLV"> TLV</name>
        <t>The SRv6 Binding SID (BSID) is an optional TLV that is used to
        report the SRv6 BSID and its attributes for the SR Policy candidate
        path. The TLV MAY <bcp14>MAY</bcp14> also optionally contain the Specified SRv6 BSID
        value for reporting as described in section 6.2.3 of <xref
        target="RFC9256"/>. target="RFC9256" sectionFormat="of" section="6.2.3"/>. Multiple instances of this TLV may be used to
        report each of the SRv6 BSIDs associated with the candidate path.</t>
        <t>The TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SRv6 Binding SID TLV Format</name>

<!--[rfced] We note that Figures 7 and 19 use "Sub-TLVs" (capitalized),
while Figures 11 and 18 use "sub-TLVs" (lowercased). Should these be
consistent? If yes, which form is preferred?
-->

        <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           BSID Flags          |            RESERVED           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Binding SID (16 octets)                   //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Specified Binding SID (16 octets)             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//   Sub-TLVs (variable)                                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7  SRv6 Binding SID TLV Format

Where:
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>Type: 1212</t>

            <t>Length: variable</t>

            <t>BSID Flags: 2-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>1212</dd>
          <dt>Length:</dt><dd>Variable</dd>
          <dt>BSID Flags:</dt><dd><t>2-octet field that indicates the attribute
          and status of the Binding SID (BSID) BSID associated with this candidate
          path. The following bit positions are defined defined, and the semantics are
          described in detail in section 6.2 of <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of"
          section="6.2"/>.  Other bits MUST <bcp14>MUST</bcp14> be cleared by the
          originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                <artwork><![CDATA[ receiver.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|U|F|                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
]]></artwork>
              </figure><list style="symbols">
                <t>B-Flag: Indicates
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>Where:</t>
            <dl spacing="normal" newline="false">
              <dt>B-Flag:</dt><dd>Indicates the allocation of the value in the
              BSID field when set and indicates that BSID is not allocated
              when
                clear.</t>

                <t>U-Flag: Indicates clear.</dd>
              <dt>U-Flag:</dt><dd>Indicates the specified BSID value is
              unavailable when set. When clear clear, it indicates that this
              candidate path is using the specified BSID. This flag is ignored
              when there is no specified BSID.</t>

                <t>F-Flag: Indicates BSID.</dd>
              <dt>F-Flag:</dt><dd>Indicates that the BSID value is one allocated
              dynamically due to fallback (e.g. (e.g., when the specified BSID is
              unavailable) when set and indicates that there has been no
              fallback for BSID allocation when clear.</t>
              </list></t>

            <t>RESERVED: 2 clear.</dd>
            </dl>
          </dd>
          <dt>RESERVED:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by
          the originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

            <t>Binding SID: It indicates receiver.</dd>
          <dt>Binding SID:</dt><dd>Indicates the operational or allocated
          BSID value based on the status flags.</t>

            <t>Specified BSID: It is used flags.</dd>
          <dt>Specified BSID:</dt><dd>Used to report the explicitly
          specified BSID value regardless of whether it is successfully
          allocated or not. The field is set to value 0 when the BSID has not been
            specified.</t>

            <t>Sub-TLVs: variable
          specified.</dd>
          <dt>Sub-TLVs:</dt><dd>Variable and contains contain any other optional
          attributes associated with the SRv6 BSID.</t>
          </list></t> BSID.</dd>
        </dl>
        <t>The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure
        TLV (1252) MAY <bcp14>MAY</bcp14> optionally be used as sub-TLVs of the SRv6 Binding SID
        TLV to indicate the SRv6 Endpoint behavior and SID structure for the
        Binding SID value in the TLV. <xref target="RFC9514"/> target="RFC9514" format="default"/> defines the SRv6
        Endpoint Behavior TLV And and the SRv6 SID Structure TLV.</t>
      </section>
      <section anchor="CPSTATE" title="SR numbered="true" toc="default">
        <name>SR Candidate Path State TLV"> TLV</name>
        <t>The SR Candidate Path State TLV provides the operational status and
        attributes of the SR Policy at the candidate path level. Only a single
        instance of this TLV is advertised for a given candidate path. If
        multiple instances are present, then the first valid one (i.e., not
        determined to be malformed as per section 8.2.2 of <xref
        target="RFC9552"/>) one target="RFC9552"  sectionFormat="of" section="8.2.2"/>) is used and the rest are ignored.</t>
        <t>The TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Candidate Path State TLV Format</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Priority    |   RESERVED    |              Flags            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Preference (4 octets)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 8  SR Candidate Path State TLV Format

Where:
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>Type: 1202</t>

            <t>Length: 8 octets</t>

            <t>Priority: 1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
        <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1202</dd>
            <dt>Length:</dt><dd>8 octets</dd>
            <dt>Priority:</dt><dd>1-octet value which that indicates the priority of the
            candidate path. Refer Section 2.12 of to <xref
            target="RFC9256"/>.</t>

            <t>RESERVED: 1 target="RFC9256" sectionFormat="of" section="2.12"/>.</dd>
            <dt>RESERVED:</dt><dd>1 octet. MUST <bcp14>MUST</bcp14> be set to 0 by the originator and MUST <bcp14>MUST</bcp14>
            be ignored by a receiver.</t>

            <t>Flags: 2-octet receiver.</dd>
            <dt>Flags:</dt><dd><t>2-octet field that indicates the attribute and status of the
            candidate path. The following bit positions are defined defined, and the
            semantics are described in section 5 of <xref target="RFC9256"/> target="RFC9256" sectionFormat="of" section="5"/>
            unless stated otherwise for individual flags. Other bits MUST <bcp14>MUST</bcp14> be
            cleared by the originator and MUST <bcp14>MUST</bcp14> be ignored by a
            receiver.<figure>
                <artwork><![CDATA[
            receiver.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A|B|E|V|O|D|C|I|T|U|         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
]]></artwork>
              </figure><list style="symbols">
                <t>S-Flag: Indicates
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
            <dl spacing="normal" newline="false">
                <dt>S-Flag:</dt><dd>Indicates that the candidate path is in an
                administrative shut state when set and not in an administrative
                shut state when clear.</t>

                <t>A-Flag: Indicates clear.</dd>
                <dt>A-Flag:</dt><dd>Indicates that the candidate path is the active path
                (i.e.
                (i.e., one provisioned in the forwarding plane as specified in
                section 2.9 of
                <xref target="RFC9256"/>) target="RFC9256" sectionFormat="of" section="2.9"/>) for the SR Policy
                when set and not the active path when clear.</t>

                <t>B-Flag: Indicates clear.</dd>
                <dt>B-Flag:</dt><dd>Indicates that the candidate path is the backup path
                (i.e.
                (i.e., one identified for path protection of the active path as
                specified in section 9.3 of <xref target="RFC9256"/>) target="RFC9256" sectionFormat="of" section="9.3"/>) for the
                SR Policy when set and not the backup path when clear.</t>

                <t>E-Flag: Indicates clear.</dd>
                <dt>E-Flag:</dt><dd>Indicates that the candidate path has been
                evaluated for validity (e.g. (e.g., headend may evaluate candidate
                paths based on their preferences) when set and has not been
                evaluated for validity when clear.</t>

                <t>V-Flag: clear.</dd>
                <dt>V-Flag:</dt><dd>Indicates that the candidate path has at least one valid
                SID-List when set and that no valid SID-List is available
                or evaluated when clear.

<!--[rfced] We note multiple instances of "MUST be set to 0 by the
originator and MUST be ignored by a receiver". Should the one
instance below that contains only one "MUST" be updated
accordingly (see Section 5.3)?

Original:
   V-Flag: Indicates the candidate path has at least one valid SID-List
   when set and indicates no valid SID-List is available or evaluated
   when clear. When the E-Flag is clear (i.e. the candidate path has not
   been evaluated), then this flag MUST be set to 0 by the originator and
   ignored by the receiver.</t>

                <t>O-Flag: receiver.

Perhaps:
   V-Flag: Indicates that the candidate path has at least one valid SID-List
   when set and that no valid SID-List is available or evaluated when clear.
   When the E-Flag is clear (i.e., the candidate path has not been evaluated),
   then this flag MUST be set to 0 by the originator and MUST be ignored by a
   receiver.
-->

		When the E-Flag is clear (i.e., the
                candidate path has not been evaluated), then this flag <bcp14>MUST</bcp14> be
                set to 0 by the originator and ignored by a receiver.</dd>
                <dt>O-Flag:</dt><dd>Indicates that the candidate path was instantiated by
                the headend due to an on-demand nexthop next hop trigger based on a
                local template when set and that the candidate path has not
                been instantiated due to an on-demand nexthop next hop trigger when clear.
                Refer to section 8.5 of <xref target="RFC9256"/> target="RFC9256" sectionFormat="of" section="8.5"/> for
                details.</t>

                <t>D-Flag: Indicates
                details.</dd>
                <dt>D-Flag:</dt><dd>Indicates that the candidate path was delegated for
                computation to a PCE/controller when set and indicates that
                the candidate path has not been delegated for computation when
                clear.</t>

                <t>C-Flag: Indicates
                clear.</dd>
                <dt>C-Flag:</dt><dd>Indicates that the candidate path was provisioned by a
                PCE/controller when set and indicates that the candidate path
                was not provisioned by a PCE/controller when clear.</t>

                <t>I-Flag: Indicates clear.</dd>
                <dt>I-Flag:</dt><dd>Indicates that the candidate path is to perform the
                "drop upon invalid"
                "Drop-Upon-Invalid" behavior when no other valid candidate
                path is available for this SR Policy when the flag is set.
                Refer to section 8.2 of <xref target="RFC9256"/> target="RFC9256" sectionFormat="of" section="8.2"/> for details.
                When clear, it indicates that the candidate path is not
                enabled for the "drop upon invalid" behavior.</t>

                <t>T-Flag: Indicates "Drop-Upon-Invalid" behavior.</dd>
                <dt>T-Flag:</dt><dd>Indicates that the candidate path has been marked as
                eligible for use as a transit policy on the headend when set
                and not eligible for use as a transit policy when clear.
                Transit policy is a policy whose BSID can be used in the
                segment list of another SR Policy. Refer to section 8.3 of
                <xref target="RFC9256"/> target="RFC9256" sectionFormat="of" section="8.3"/> for steering into a transit policy
                using its BSID.</t>

                <t>U-Flag: Indicates BSID.</dd>
                <dt>U-Flag:</dt><dd>Indicates that this the candidate path is reported as
                active and is dropping traffic as a result of the "drop upon
                invalid" "Drop-Upon-Invalid"
                behavior being activated for the SR Policy when set.
                When clear, it indicates that the candidate path is not
                dropping traffic as a result of the "drop upon invalid" "Drop-Upon-Invalid"
                behavior. Refer to section 8.2 of <xref target="RFC9256"/> for
                details.</t>
              </list></t>

            <t>Preference: 4-octet target="RFC9256" sectionFormat="of" section="8.2"/> for
                details.</dd>
            </dl>
	  </dd>
            <dt>Preference:</dt><dd>4-octet value which that indicates the preference of the
            candidate path. Refer to section 2.7 of <xref target="RFC9256"/> target="RFC9256" sectionFormat="of" section="2.7"/>
            for details.</t>
          </list></t> details.</dd>
        </dl>
      </section>
      <section anchor="POLNAME" title="SR numbered="true" toc="default">
        <name>SR Policy Name TLV"> TLV</name>
        <t>The SR Policy Name TLV is an optional TLV that is used to carry the
        symbolic name associated with the SR Policy. Only a single instance of
        this TLV is advertised for a given candidate path. If multiple
        instances are present, then the first valid one (i.e., not determined to
        be malformed as per section 8.2.2 of <xref target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is
        used and the rest are ignored.</t>
        <t>The TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Policy Name TLV Format</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SR Policy Name (variable)                  //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
        <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1213</dd>
            <dt>Length:</dt><dd>Variable</dd>

<!--[rfced] Please review 2 instances of the term "NULL" in this
document. Should "NULL terminator" be "NUL terminator" or "null
terminator" for correctness? We ask per guidance received from a
Gen Art reviewer. Note that RFC 9256 uses "null endpoint",
"Explicit Null Label Policy", and "IPv6 Explicit NULL Label".

Current:
 SR Policy Name TLV Format

Where:
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>Type: 1213</t>

            <t>Length: variable</t>

            <t>SR Policy Name:  Symbolic name for the SR Policy without a NULL
      terminator as specified in section Section 2.1 of [RFC9256].

Candidate Path Name:  Symbolic name for the SR Policy candidate path
      without a NULL terminator as specified in Section 2.6 of
      [RFC9256].
-->

            <dt>SR Policy Name:</dt><dd>Symbolic name for the SR Policy without a NULL
            terminator as specified in <xref
            target="RFC9256"/>. target="RFC9256" sectionFormat="of" section="2.1"/>. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the size of the
            symbolic name be limited to 255 bytes. Implementations MAY <bcp14>MAY</bcp14> choose
            to truncate long names to 255 bytes when signaling via BGP-LS.</t>
          </list></t> BGP-LS.</dd>
        </dl>
      </section>
      <section anchor="CPNAME" title="SR numbered="true" toc="default">
        <name>SR Candidate Path Name TLV"> TLV</name>
        <t>The SR Candidate Path Name TLV is an optional TLV that is used to
        carry the symbolic name associated with the candidate path. Only a
        single instance of this TLV is advertised for a given candidate path.
        If multiple instances are present, then the first valid one (i.e., not
        determined to be malformed as per section 8.2.2 of <xref
        target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and the rest are ignored.</t>
        <t>The TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Candidate Path Name TLV Format</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Candidate Path Name (variable)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 10  SR Candidate
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
        <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1203</dd>
            <dt>Length:</dt><dd>Variable</dd>
            <dt>Candidate Path Name TLV Format

Where:
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>Type: 1203</t>

            <t>Length: variable</t>

            <t>Candidate Path Name: Symbolic Name:</dt><dd>Symbolic name for the SR Policy
            candidate path without a NULL terminator as specified in section 2.6 of <xref target="RFC9256"/>.
            target="RFC9256" sectionFormat="of" section="2.6"/>. It is RECOMMENDED
            <bcp14>RECOMMENDED</bcp14> that the size of the symbolic name be
            limited to 255 bytes. Implementations MAY <bcp14>MAY</bcp14> choose to
            truncate long names to 255 bytes when signaling via BGP-LS.</t>
          </list></t> BGP-LS.</dd>
        </dl>
      </section>
      <section anchor="CPCONSTRAINTS"
               title="SR numbered="true" toc="default">
        <name>SR Candidate Path Constraints TLV"> TLV</name>
        <t>The SR Candidate Path Constraints TLV is an optional TLV that is
        used to report the constraints associated with the candidate path.

<!--[rfced] How may we clarify this "either" sentence. Is the intended
meaning that the dynamic path is computed by the headend or
delegated to a controller (option A)? Or that the dynamic path is
computed by the headend or by delegation to a controller (option B)?

Original:
   The constraints are generally applied to a dynamic candidate path which is
   computed either by the headend or may be delegated to a controller.

Perhaps A:
   The constraints are generally applied to a dynamic candidate path that is
   either computed by the headend or delegated to a controller.

Perhaps B:
   The constraints are generally applied to a dynamic candidate path that is
   computed by either the headend or delegation to a controller.
-->

	The
        constraints are generally applied to a dynamic candidate path that is
        computed either by the headend or may be delegated to a controller.
        The constraints may also be applied to an explicit path where the
        computation entity is expected to validate that the path satisfies the
        specified constraints and constraints; if not not, the path is to be invalidated (e.g.,
        due to topology changes). Only a single instance of this TLV is
        advertised for a given candidate path. If multiple instances are
        present, then the first valid one (i.e., not determined to be malformed as
        per section 8.2.2 of <xref target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and the
        rest are ignored.</t>
        <t>The TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Candidate Path Constraints TLV Format</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |          RESERVED1            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             MTID              |   Algorithm   |   RESERVED2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   sub-TLVs (variable)                                        //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 11  SR Candidate Path Constraints TLV Format

Where:
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>Type: 1204</t>

            <t>Length: variable</t>

            <t>Flags: 2-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
        <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1204</dd>
            <dt>Length:</dt><dd>Variable</dd>
            <dt>Flags:</dt><dd><t>2-octet field that indicates the constraints that are
            being applied to the candidate path. The following bit positions
            are defined defined, and the other bits MUST <bcp14>MUST</bcp14> be cleared by the originator
            and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                <artwork><![CDATA[ receiver.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|P|U|A|T|S|F|H|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
]]></artwork>
              </figure><list style="symbols">
                <t>D-Flag: Indicates
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
            <dl spacing="normal">
                <dt>D-Flag:</dt><dd>Indicates that the candidate path uses an SRv6
                dataplane
                data plane when set and an SR/MPLS dataplane data plane when clear</t>

                <t>P-Flag: Indicates clear.</dd>
                <dt>P-Flag:</dt><dd>Indicates that the candidate path prefers the use
                of only protected SIDs when set and indicates that the
                candidate path does not prefer the use of only protected SIDs
                when clear. This flag is mutually exclusive with the U-Flag
                (i.e., both of these flags cannot be set at the same time).</t>

                <t>U-Flag: Indicates time).</dd>
                <dt>U-Flag:</dt><dd>Indicates that the candidate path prefers the use
                of only unprotected SIDs when set and indicates that the
                candidate path does not prefer the use of only unprotected
                SIDs when clear. This flag is mutually exclusive with the
                P-Flag (i.e., both of these flags cannot be set at the same
                time).</t>

                <t>A-Flag: Indicates
                time).</dd>
                <dt>A-Flag:</dt><dd>Indicates that the candidate path uses only the
                SIDs belonging to the specified SR Algorithm when set and
                indicates
                that the candidate path does not use only the SIDs
                belonging to the specified SR Algorithm when clear.</t>

                <t>T-Flag: Indicates clear.</dd>
                <dt>T-Flag:</dt><dd>Indicates that the candidate path uses only the
                SIDs belonging to the specified topology when set and
                indicates
                that the candidate path does not use only the SIDs
                belonging to the specified topology when clear.</t>

                <t>S-Flag: Indicates clear.</dd>
                <dt>S-Flag:</dt><dd>Indicates that the use of protected (P-Flag) or
                unprotected (U-Flag) SIDs becomes a strict constraint instead
                of a preference when set and indicates that there is no strict
                constraint (and only a preference) when clear.</t>

                <t>F-Flag: Indicates clear.</dd>
                <dt>F-Flag:</dt><dd>Indicates that the candidate path is fixed once
                computed and not modified except on operator intervention and
                indicates
                that the candidate path may be modified as part of
                recomputation when clear.</t>

                <t>H-Flag: Indicates clear.</dd>
                <dt>H-Flag:</dt><dd>Indicates that the candidate path uses only
                adjacency SIDs and traverses hop-by-hop over the links
                corresponding to those adjacency SIDs when set and indicates
                that the candidate path is not restricted to using only
                hop-by-hop adjacency SIDs when clear.</t>
              </list></t>

            <t>RESERVED1: 2 clear.</dd>
            </dl>
	</dd>
            <dt>RESERVED1:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by the originator and
            MUST
            <bcp14>MUST</bcp14> be ignored by a receiver.</t>

            <t>MTID: Indicates receiver.</dd>
            <dt>MTID:</dt><dd>Indicates the multi-topology identifier of the IGP
            topology that is preferred to be used when the path is set up.
            When the T-flag is set set, then the path is strictly using the
            specified topology SIDs only.</t>

            <t>Algorithm: Indicates only.</dd>
            <dt>Algorithm:</dt><dd>Indicates the algorithm that is preferred to be used
            when the path is set up. When the A-flag is set set, then the path is
            strictly using the specified algorithm SIDs only. The algorithm
            values are from IGP the "IGP Algorithm Types Types" IANA registry under the IANA
            Interior
            "Interior Gateway Protocol (IGP) Parameters.</t>

            <t>RESERVED2: 1 Parameters" registry group.</dd>
            <dt>RESERVED2:</dt><dd>1 octet. MUST <bcp14>MUST</bcp14> be set to 0 by the originator and MUST <bcp14>MUST</bcp14>
            be ignored by a receiver.</t>

            <t>sub-TLVs: one receiver.</dd>
            <dt>sub-TLVs:</dt><dd>One or more optional sub-TLVs MAY <bcp14>MAY</bcp14> be included in this
            TLV to describe other constraints. These sub-TLVs are: SR Affinity
            Constraint, SR SRLG Shared Risk Link Group (SRLG) Constraint, SR Bandwidth Constraint, SR
            Disjoint Group Constraint, SR Bidirectional Group Constraint, and
            SR Metric Constraint.</t>
          </list></t> Constraint.</dd>
        </dl>
        <t>These constraint sub-TLVs are defined below.</t>
        <section anchor="CPAFFINITY" title="SR numbered="true" toc="default">
          <name>SR Affinity Constraint Sub-TLV"> Sub-TLV</name>
          <t>The SR Affinity Constraint sub-TLV is an optional sub-TLV of the
          SR Candidate Path Constraints TLV that is used to carry the affinity
          constraints <xref target="RFC2702"/> target="RFC2702" format="default"/> associated with the candidate
          path. The affinity is expressed in terms of an Extended Admin Administrative Group
          (EAG) as defined in <xref target="RFC7308"/>. target="RFC7308" format="default"/>. Only a single instance
          of this sub-TLV is advertised for a given candidate path. If
          multiple instances are present, then the first valid one (i.e., not
          determined to be malformed as per section 8.2.2 of <xref
          target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and the rest are ignored.</t>
          <t>The sub-TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Affinity Constraint Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excl-Any-Size | Incl-Any-Size | Incl-All-Size |    RESERVED   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Exclude-Any EAG (optional, variable)             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-Any EAG (optional, variable)             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-All EAG (optional, variable)             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 12  SR Affinity Constraints Sub-TLV Format

Where:
]]></artwork>
            </figure></t>

          <t><list style="symbols">
              <t>Type: 1208</t>

              <t>Length: variable,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
          <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>1208</dd>
              <dt>Length:</dt><dd>Variable, dependent on the size of the Extended Admin
              Group. MUST EAG.
              <bcp14>MUST</bcp14> be a non-zero multiple of 4 octets.</t>

              <t>Exclude-Any-Size: one octets.</dd>
              <dt>Exclude-Any-Size:</dt><dd>1 octet to indicate the size of
              Exclude-Any EAG bitmask size in multiples of 4 octets. (e.g. octets (e.g.,
              value 0 indicates the Exclude-Any EAG field is skipped, and value 1
              indicates that 4 octets of Exclude-Any EAG is included)</t>

              <t>Include-Any-Size: one are included).</dd>
              <dt>Include-Any-Size:</dt><dd>1 octet to indicate the size of
              Include-Any EAG bitmask size in multiples of 4 octets. (e.g. octets (e.g.,
              value 0 indicates the Include-Any EAG field is skipped, and value 1
              indicates that 4 octets of Include-Any EAG is included)</t>

              <t>Include-All-Size: one are included).</dd>
              <dt>Include-All-Size:</dt><dd>1 octet to indicate the size of
              Include-All EAG bitmask size in multiples of 4 octets. (e.g. octets (e.g.,
              value 0 indicates the Include-All EAG field is skipped, and value 1
              indicates that 4 octets of Include-All EAG is included)</t>

              <t>RESERVED: 1 are included).</dd>
              <dt>RESERVED:</dt><dd>1 octet. MUST <bcp14>MUST</bcp14> be set to 0 by the originator and
              MUST
              <bcp14>MUST</bcp14> be ignored by a receiver.</t>

              <t>Exclude-Any EAG: the receiver.</dd>
              <dt>Exclude-Any EAG:</dt><dd>The bitmask used to represent the affinities
              that have been excluded from the path.</t>

              <t>Include-Any EAG: the path.</dd>
              <dt>Include-Any EAG:</dt><dd>The bitmask used to represent the affinities
              that have been included in the path.</t>

              <t>Include-All EAG: the path.</dd>
              <dt>Include-All EAG:</dt><dd>The bitmask used to represent all the
              affinities that have been included in the path.</t>
            </list></t> path.</dd>
          </dl>
        </section>
        <section anchor="CPSRLG" title="SR numbered="true" toc="default">
          <name>SR SRLG Constraint Sub-TLV"> Sub-TLV</name>
          <t>The SR SRLG Constraint sub-TLV is an optional sub-TLV of the SR
          Candidate Path Constraints TLV that is used to carry the Shared Risk
          Link Group (SRLG) SRLG values <xref target="RFC4202"/> target="RFC4202" format="default"/> that have been
          excluded from the candidate path. Only a single instance of this
          sub-TLV is advertised for a given candidate path. If multiple
          instances are present, then the first valid one (i.e., not determined to
          be malformed as per section 8.2.2 of <xref target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>)
          is used and the rest are ignored.</t>
          <t>The sub-TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR SRLG Constraint Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         SRLG Values (variable, multiples of 4 octets)        //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 13  SR SRLG Constraints Sub-TLV Format

Where:
]]></artwork>
            </figure></t>

          <t><list style="symbols">
              <t>Type: 1209</t>

              <t>Length: variable,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
          <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>1209</dd>
              <dt>Length:</dt><dd>Variable, dependent on the number of SRLGs encoded.
              MUST
              <bcp14>MUST</bcp14> be a non-zero multiple of 4 octets.</t>

              <t>SRLG Values: One octets.</dd>
              <dt>SRLG Values:</dt><dd>One or more SRLG values. Each SRLG value is of 4
              octets.</t>
            </list></t>
              octets.</dd>
	  </dl>
        </section>
        <section anchor="CPBW" title="SR numbered="true" toc="default">
          <name>SR Bandwidth Constraint Sub-TLV"> Sub-TLV</name>
          <t>The SR Bandwidth Constraint sub-TLV is an optional sub-TLV of the
          SR Candidate Path Constraints TLV that is used to indicate the
          bandwidth that has been requested for the candidate path. Only a
          single instance of this sub-TLV is advertised for a given candidate
          path. If multiple instances are present, then the first valid one (i.e.,
          not determined to be malformed as per section 8.2.2 of <xref
          target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and the rest are ignored.</t>
          <t>The sub-TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Bandwidth Constraint Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Bandwidth                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 14  SR Bandwidth Constraints Sub-TLV Format

Where:
]]></artwork>
            </figure></t>

          <t><list style="symbols">
              <t>Type: 1210</t>

              <t>Length: 4 octets</t>

              <t>Bandwidth: 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
          <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>1210</dd>
              <dt>Length:</dt><dd>4 octets</dd>
              <dt>Bandwidth:</dt><dd>4 octets which that specify the desired bandwidth in
              unit of bytes per second in IEEE floating point format <xref
              target="IEEE754"/>.</t>
            </list></t> target="IEEE754" format="default"/>.</dd>
          </dl>
        </section>
        <section anchor="CPDISJOINT"
                 title="SR numbered="true" toc="default">
          <name>SR Disjoint Group Constraint Sub-TLV"> Sub-TLV</name>
          <t>The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV
          of the SR Candidate Path Constraints TLV that is used to carry the
          disjointness constraint associated with the candidate path. The
          disjointness between two SR Policy Candidate Paths is expressed by
          associating them with the same disjoint group identifier and then
          specifying the type of disjointness required between their paths.
          The types of disjointness are described in section 3 of <xref
          target="RFC8800"/> target="RFC8800" sectionFormat="of" section="3"/> where the level of disjointness increases in the
          order: link, node, SRLG, Node + SRLG. The computation is expected to
          achieve the highest level of disjointness requested and requested; when that is
          not possible possible, then fall back to a lesser level progressively based on
          the levels indicated. Only a single instance of this sub-TLV is
          advertised for a given candidate path. If multiple instances are
          present, then the first valid one (i.e., not determined to be malformed
          as per section 8.2.2 of <xref target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and
          the rest are ignored.</t>
          <t>The sub-TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Disjoint Group Constraint Sub-TLV Format</name>

<!--[rfced] We note that Figure 15 uses "Request-Flags" and "Status-Flags"
(hyphenated), while the definitions of these fields use "Request Flags"
and "Status Flags" (unhyphenated). To make these consistent, which form is
preferred?
-->

          <artwork align="left"><![CDATA[ align="left" name="" type="" 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-Flags |  Status-Flags |            RESERVED           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Disjoint Group Identifier (variable)                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 15  SR Disjoint Group Constraints Sub-TLV Format

Where:
]]></artwork>
            </figure></t>

          <t><list style="symbols">
              <t>Type: 1211</t>

              <t>Length: Variable.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
          <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>1211</dd>
              <dt>Length:</dt><dd>Variable. Minimum of 8 octets.</t>

              <t>Request Flags: one octets.</dd>
              <dt>Request Flags:</dt><dd><t>1 octet to indicate the level of
              disjointness requested as specified in the form of flags. The
              following flags are defined defined, and the other bits MUST <bcp14>MUST</bcp14> be cleared
              by the originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                  <artwork><![CDATA[ receiver.</t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|N|L|F|I|     |
   +-+-+-+-+-+-+-+-+

Where:
]]></artwork>
                </figure><list style="symbols">
                  <t>S-Flag: Indicates
+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                  <dt>S-Flag:</dt><dd>Indicates that SRLG disjointness is requested
                  when set and indicates that SRLG disjointness is not
                  requested when clear.</t>

                  <t>N-Flag: Indicates clear.</dd>
                  <dt>N-Flag:</dt><dd>Indicates that node disjointness is requested
                  when set and indicates that node disjointness is not
                  requested when clear.</t>

                  <t>L-Flag: Indicates clear.</dd>
                  <dt>L-Flag:</dt><dd>Indicates that link disjointness is requested
                  when set and indicates that the link disjointness is not
                  requested when clear.</t>

                  <t>F-Flag: Indicates clear.</dd>
                  <dt>F-Flag:</dt><dd>Indicates that the computation may fall back to a
                  lower level of disjointness amongst the ones requested when
                  all cannot be achieved when set and indicates that fallback
                  to a lower level of disjointness is not allowed when
                  clear.</t>

                  <t>I-Flag: Indicates
                  clear.</dd>
                  <dt>I-Flag:</dt><dd>Indicates that the computation may fall back to
                  the default best path (e.g. (e.g., an IGP path) in case of none of the
                  desired disjointness can be achieved when set and indicates
                  that fallback to the default best path is not allowed when
                  clear.</t>
                </list></t>

              <t>Status Flags: one
                  clear.</dd>
              </dl>
            </dd>
            <dt>Status Flags:</dt><dd><t>1 octet to indicate the level of disjointness
              that has been achieved by the computation as specified in the
              form of flags. The following flags are defined defined, and the other
              bits MUST <bcp14>MUST</bcp14> be cleared by the originator and MUST <bcp14>MUST</bcp14> be ignored by a
              receiver.<figure>
                  <artwork><![CDATA[
              receiver.</t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|N|L|F|I|X|   |
   +-+-+-+-+-+-+-+-+

Where:
]]></artwork>
                </figure><list style="symbols">
                  <t>S-Flag: Indicates
+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                  <dt>S-Flag:</dt><dd>Indicates that SRLG disjointness is achieved when
                  set and indicates that SRLG disjointness is not achieved
                  when clear.</t>

                  <t>N-Flag: Indicates clear.</dd>
                  <dt>N-Flag:</dt><dd>Indicates that node disjointness is achieved when
                  set and indicates that node disjointness was not achieved
                  when clear.</t>

                  <t>L-Flag: Indicates clear.</dd>
                  <dt>L-Flag:</dt><dd>Indicates that link disjointness is achieved when
                  set and indicates that link disjointness was not achieved
                  when clear.</t>

                  <t>F-Flag: Indicates clear.</dd>
                  <dt>F-Flag:</dt><dd>Indicates that the computation has fallen back to
                  a lower level of disjointness than requested when set and
                  indicates
                  that there has been no fallback to a lower level
                  of disjointness when clear.</t>

                  <t>I-Flag: Indicates clear.</dd>
                  <dt>I-Flag:</dt><dd>Indicates that the computation has fallen back to
                  the best path (e.g. (e.g., an IGP path) and disjointness has not been
                  achieved when set and indicates that there has been no
                  fallback to the best path when clear.</t>

                  <t>X-Flag : Indicates clear.</dd>
                  <dt>X-Flag:</dt><dd>Indicates that the disjointness constraint could
                  not be achieved and hence the path has been invalidated when set
                  and indicates that the path has not been invalidated due to
                  unmet disjointness constraints when clear.</t>
                </list></t>

              <t>RESERVED: 2 clear.</dd>
                </dl>
              </dd>
              <dt>RESERVED:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by the originator and
              MUST
              <bcp14>MUST</bcp14> be ignored by a receiver.</t>

              <t>Disjoint receiver.</dd>
<!-- [rfced] For consistency, should "Association Object" be updated
to "ASSOCIATION object" per use in Section 6.1 of [RFC8697]? Note
that there are four instances.
-->

              <dt>Disjoint Group Identifier: 4-octet Identifier:</dt><dd>4-octet value that is the group
              identifier for a set of disjoint paths. Alternatively, this
              field MAY <bcp14>MAY</bcp14> contain the entire PCEP Association Object as
              specified in section 6.1 of <xref target="RFC8697"/> target="RFC8697" sectionFormat="of" section="6.1"/> (including
              its optional TLVs) when PCEP is used for the signaling of the SR
              Policy candidate path and where the BGP-LS Producer is unable to
              determine the group identifier that can be accommodated in a
              4-octet value (since PCEP supports multiple methods of encoding
              an association identifier). Note that the parsing of the PCEP
              object is expected to be performed only by the BGP-LS Consumer
              (hence, outside the scope of this document) and not by any BGP
              Speaker as specified in <xref target="RFC9552"/>. target="RFC9552" format="default"/>. If the PCEP
              object size is such that the update for a single SR Policy
              Candidate Path NLRI would exceed the supported BGP message size
              by the implementation, then the PCEP Association Object MUST NOT <bcp14>MUST NOT</bcp14>
              be encoded and this sub-TLV skipped along with an error log.
              Refer section 5.3 of to <xref target="RFC9552"/> target="RFC9552" sectionFormat="of" section="5.3"/> for discussion on
              implications of encoding large sets of information into
              BGP-LS.</t>
            </list></t>
              BGP-LS.</dd>
          </dl>
        </section>
        <section anchor="CPBIDIR"
                 title="SR numbered="true" toc="default">
          <name>SR Bidirectional Group Constraint Sub-TLV"> Sub-TLV</name>
          <t>The SR Bidirectional Group Constraint sub-TLV is an optional
          sub-TLV of the SR Candidate Path Constraints TLV that is used to
          carry the bidirectional constraint associated with the candidate
          path. The bidirectional relationship between two SR Policy Candidate
          Paths is expressed by associating them with the same bidirectional
          group identifier and then specifying the type of bidirectional
          routing required between their paths. Only a single instance of this
          sub-TLV is advertised for a given candidate path. If multiple
          instances are present, then the first valid one (i.e., not determined to
          be malformed as per section 8.2.2 of <xref target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>)
          is used and the rest are ignored.</t>
          <t>The sub-TLV has the following format:<figure align="center"> format:</t>
<figure>
  <name>SR Bidirectional Group Constraint Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Bidirectional Group Identifier (variable)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 16  SR Bidirectional Group Constraints Sub-TLV Format

Where:
]]></artwork>
            </figure></t>

          <t><list style="symbols">
              <t>Type: 1214</t>

              <t>Length: Variable.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
          <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>1214</dd>
              <dt>Length:</dt><dd>Variable. Minimum of 8 octets.</t>

              <t>Flags: two octets.</dd>
              <dt>Flags:</dt><dd><t>2 octets to indicate the bidirectional path setup
              information as specified in the form of flags. The following
              flags are defined defined, and the other bits MUST <bcp14>MUST</bcp14> be cleared by the
              originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                  <artwork><![CDATA[ receiver.</t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|C|                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
]]></artwork>
                </figure><list style="symbols">
                  <t>R-Flag: Indicates
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
              <dl spacing="normal">
                  <dt>R-Flag:</dt><dd>Indicates that this the candidate path of the SR
                  Policy forms the reverse path when the R-Flag is set. If the
                  R-Flag is clear, this the candidate path forms the forward
                  path.</t>

                  <t>C-Flag: Indicates
                  path.</dd>
                  <dt>C-Flag:</dt><dd>Indicates that the bidirectional path is
                  co-routed when set and indicates that the bidirectional path
                  is not co-routed when clear.</t>
                </list></t>

              <t>RESERVED: 2 clear.</dd>
              </dl>
	    </dd>
            <dt>RESERVED:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by
            the originator and
              MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

              <t>Bidirectional
            receiver.</dd>
            <dt>Bidirectional Group Identifier: 4-octet Identifier:</dt><dd>4-octet value that is
            the group identifier for a set of bidirectional paths.
            Alternatively, this field MAY <bcp14>MAY</bcp14> contain the entire
            PCEP Association Object as specified in section 6.1 of <xref
              target="RFC8697"/> target="RFC8697"
            sectionFormat="of" section="6.1"/> (including its optional TLVs)
            when PCEP is used for the signaling of the SR Policy candidate path
            and where the BGP-LS Producer is unable to determine the group
            identifier that can be accommodated in a 4-octet value (since PCEP
            supports multiple methods of encoding an association
            identifier). Note that the parsing of the PCEP object is expected
            to be performed only by the BGP-LS Consumer (hence, outside the
            scope of this document) and not by any BGP Speaker as specified in
            <xref
              target="RFC9552"/>. target="RFC9552" format="default"/>. If the PCEP object size
            is such that the update for a single SR Policy Candidate Path NLRI
            would exceed the supported BGP message size by the implementation,
            then the PCEP Association Object MUST NOT <bcp14>MUST NOT</bcp14> be
            encoded and this sub-TLV skipped along with an error log. Refer section 5.3 of to
            <xref
              target="RFC9552"/> target="RFC9552" sectionFormat="of" section="5.3"/> for
            discussion on implications of encoding large sets of information
            into BGP-LS.</t>
            </list></t> BGP-LS.</dd>
          </dl>
        </section>
        <section anchor="CPMETRIC" title="SR numbered="true" toc="default">
          <name>SR Metric Constraint Sub-TLV"> Sub-TLV</name>
          <t>The SR Metric Constraint sub-TLV is an optional sub-TLV of the SR
          Candidate Path Constraints TLV that is used to report the
          optimization metric of the candidate path. For a dynamic path
          computation, it is used to report the optimization metric used along
          with its parameters. For an explicit path, this sub-TLV MAY <bcp14>MAY</bcp14> be used
          to report the metric margin or is bound to be used for validation
          (i.e., the path is invalidated if the metric is beyond specified
          values). Multiple instances of this sub-TLV may be used to report
          different metric type uses.</t>
          <t>The sub-TLV has the following format: <figure align="center"> </t>
<figure>
  <name>SR Metric Constraint Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Metric Type  |      Flags    |          RESERVED             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metric Margin                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metric Bound                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 17  SR Metric Constraints Sub-TLV Format

Where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 1215</t>

              <t>Length: 12 octets</t>

              <t>Metric Type: 1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
          <dl spacing="normal">
              <dt>Type:</dt><dd>1215</dd>
              <dt>Length:</dt><dd>12 octets</dd>
              <dt>Metric Type:</dt><dd><t>1-octet field which that identifies the type of the
              metric being used.

<!--[rfced] How may we rephrase the text in Section 5.6.6 for clarity?
In the first sentence, we note that Table 1 (Section 5.7.1.1)
does not list references for the types. Should the term
"reference" be replaced with "Segment Descriptor" or other for
conciseness? And may we rephrase the second sentence as shown
below for clarity and to make it parallel?

We also note that Tables 1 and 6 contain the same information. Should
Table 1 be removed and references to Table 1 (in Sections 5.6.6 and
5.7.1.1) be updated to point to Table 6?

Original (Section 5.6.6):
   The Table 1 below lists the metric types introduced by this document
   along with reference for each. Where the references are for IS-IS
   and OSPF specifications, those metric types are defined for a link
   while in the SR Policy context those relate to the candidate path
   or the segment list.

Perhaps:
   Table 6 lists the metric types introduced by this document along
   with a Segment Descriptor for each. Where the Segment Descriptors
   relate to IS-IS and OSPF specifications, the metric types are defined
   for a link. Where the Segment Descriptors relate to the SR Policy,
   the metric types are defined for a candidate path or a segment list.

...
Original (Section 5.7.1.1)
   The following types are currently defined and their mapping to the
   respective segment types defined in [RFC9256]:

Perhaps:
   See Table 6 for the type definitions and their mappings to the
   respective segment types defined in [RFC9256].
-->

	      <xref target="SR_segment_types"/> lists the metric types
              introduced by this document along with reference for each. Where
              the references are for IS-IS and OSPF specifications, those
              metric types are defined for a link while in the SR Policy
              context those relate to the candidate path or the segment list.
              The metric type code points that may be used in this sub-TLV are
              also listed in <xref target="METRICTYPE"/> target="METRICTYPE" format="default"/> of this document.

<!--[rfced] For clarity, should the registry that the metric types are
taken from be listed here instead of only the registry that they are
not listed in?

Original:
   Note that the metric type in this field is not taken from the "IGP
   Metric Type" registry from IANA "IGP Parameters" and is a separate
   registry that includes IGP Metric Types as well as metric types
   specific to SR Policy path computation.

Perhaps:
   Note that the metric types in this field are taken from the
   "BGP-LS SR Policy Metric Types" IANA registry, which includes
   IGP Metric Types as well as metric types specific to SR Policy
   path computation (i.e., the metric types are not from the
   "IGP Metric-Type" registry).
-->

	      Note that the metric type in this field is not taken from the
              "IGP Metric-Type" registry from IANA "IGP Parameters" and is a
              separate registry that includes IGP Metric Types as well as
              metric types specific to SR Policy path computation. Additional
              metric types may be introduced by future documents. This
              document does not make any assumption of assumptions about a smaller metric value
              being better than a higher metric value; that is something
              that is dependent on the semantics of the specific metric type. The This
              document uses the words "best" and "worst" to abstract this
              aspect when referring to metric margins and bounds.<list
                  style="symbols">
                  <t>Type bounds.</t>
              <dl spacing="normal" newline="true">
                <dt>Type 0: IGP: In IS-IS, this IGP:</dt><dd>This is specified in <xref target="RFC5305" sectionFormat="of" section="3"/> for IS-IS and is known as the default
                  metric and metric. This is specified in section 3 of <xref
                  target="RFC5305"/>. This target="RFC2328" format="default"/> for OSPFv2 and in <xref target="RFC5340" format="default"/> for OSPFv3 and is known as the metric in both OSPFv2
                  <xref target="RFC2328"/> and OSPFv3 <xref
                  target="RFC5340"/>.</t>

                  <t>Type both.</dd>
                <dt>Type 1: Min Unidirectional Delay: This Delay:</dt><dd>This is
                specified in
                  section 4.2 of <xref target="RFC8570"/> target="RFC8570" sectionFormat="of"
                section="4.2"/> for IS-IS and in
                  section 4.2 of <xref target="RFC7471"/> target="RFC7471"
                sectionFormat="of" section="4.2"/> for
                  OSPFv2/OSPFv3.</t>

                  <t>Type OSPFv2/OSPFv3.</dd>
                <dt>Type 2: TE: This TE:</dt><dd>This is specified in section 3.7 of <xref
                  target="RFC5305"/>
                target="RFC5305" sectionFormat="of" section="3.7"/> for IS-IS as the TE
                default metric for IS-IS, metric, in
                  section 2.5.5 of <xref target="RFC3630"/> target="RFC3630"
                sectionFormat="of" section="2.5.5"/> for OSPFv2, and in
                  section 4 of <xref target="RFC5329"/>
                target="RFC5329" sectionFormat="of" section="4"/> for OSPFv3.</t>

                  <t>Type
                OSPFv3.</dd>
                <dt>Type 3: Hop Count: This Count:</dt><dd>This is specified in section 7.8 of <xref target="RFC5440"/>.</t>

                  <t>Type
                target="RFC5440" sectionFormat="of" section="7"/>.</dd>
                <dt>Type 4: SID List Length: This Length:</dt><dd>This is specified in section 4.5
                  of
                <xref target="RFC8664"/>.</t>

                  <t>Type target="RFC8664" sectionFormat="of" section="4.5"/>.</dd>
                <dt>Type 5: Bandwidth: This Bandwidth:</dt><dd>This is specified in section 4 of <xref target="I-D.ietf-lsr-flex-algo-bw-con"/>.</t>

                  <t>Type
                target="RFC9843" sectionFormat="of"
                section="4"/>.</dd>

<!--[rfced] In Section 5.6.6, we updated "Average" to "Avg" to
match use in Table 7 and the "BGP-LS SR Policy Metric Types"
registry. If you prefer to update the registry to reflect
"Average" instead of "Avg", please let us know.

Link to registry:
https://www.iana.org/assignments/bgp-ls-parameters/
bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>.

Original:
   Type 6: Average Unidirectional Delay: This

Current:
   Type 6: Avg Unidirectional Delay:
-->

                <dt>Type 6: Avg Unidirectional Delay:</dt><dd>This is
                specified in section 4.1 of <xref target="RFC8570"/> target="RFC8570" sectionFormat="of"
                section="4.1"/> for IS-IS and in
                  section 4.1 of <xref target="RFC7471"/> target="RFC7471"
                sectionFormat="of" section="4.1"/> for
                  OSPFv2/OSPFv3.</t>

                  <t>Type OSPFv2/OSPFv3.</dd>
                <dt>Type 7: Unidirectional Delay Variation: This Variation:</dt><dd>This is
                specified in section 4.3 of <xref target="RFC8570"/> target="RFC8570" sectionFormat="of"
                section="4.3"/> for IS-IS and in
                  section 4.3 of <xref target="RFC7471"/> target="RFC7471"
                sectionFormat="of" section="4.3"/> for
                  OSPFv2/OSPFv3.</t>

                  <t>Type OSPFv2/OSPFv3.</dd>
                <dt>Type 8: Loss: This Loss:</dt><dd>This is specified in section 4.4 of <xref
                  target="RFC8570"/>
                target="RFC8570" sectionFormat="of" section="4.4"/> for IS-IS
                and in section 4.4 of <xref
                  target="RFC7471"/> target="RFC7471" sectionFormat="of"
                section="4.4"/> for OSPFv2/OSPFv3.</t>

                  <t>Types OSPFv2/OSPFv3.</dd>
                <dt>Types 128 to 255 (both inclusive): User Defined: This
                Defined:</dt><dd>This is specified in <xref
                target="RFC9843" sectionFormat="of"
                section="2"/> for IS-IS and OSPF in section 2 of <xref
                  target="I-D.ietf-lsr-flex-algo-bw-con"/>.</t>
                </list></t>

              <t>Flags: 1-octet OSPF.</dd>
              </dl>
            </dd>
            <dt>Flags:</dt><dd><t>1-octet field that indicates the validity of
            the metric fields and their semantics. The following bit positions
            are defined defined, and the other bits MUST <bcp14>MUST</bcp14> be cleared by
            the originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                  <artwork><![CDATA[
            receiver.</t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|O|M|A|B|       |
   +-+-+-+-+-+-+-+-+

Where:
]]></artwork>
                </figure><list style="symbols">
                  <t>O-Flag: Indicates
+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                  <dt>O-Flag:</dt><dd>Indicates that this is the optimization metric
                  being reported for a dynamic candidate path when set and
                  indicates
                  that the metric is not the optimization metric
                  when clear. This bit MUST NOT <bcp14>MUST NOT</bcp14> be set in more than one
                  instance of this TLV for a given candidate path
                  advertisement.</t>

                  <t>M-Flag: Indicates
                  advertisement.</dd>
                  <dt>M-Flag:</dt><dd>Indicates that the metric margin allowed is
                  specified when set and indicates that the metric margin allowed
                  is not specified when clear.</t>

                  <t>A-Flag: Indicates clear.</dd>
                  <dt>A-Flag:</dt><dd>Indicates that the metric margin is specified as
                  an absolute value when set and that the metric margin is expressed as a percentage
                  of the minimum metric when clear.</t>

                  <t>B-Flag: Indicates clear.</dd>
                  <dt>B-Flag:</dt><dd>Indicates that the metric bound allowed for the
                  path is specified when set and indicates that the metric bound
                  is not specified when clear.</t>
                </list></t>

              <t>RESERVED: 2 clear.</dd>
              </dl>
            </dd>
            <dt>RESERVED:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by
            the originator and
              MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

              <t>Metric Margin: 4-octet
            receiver.</dd>
            <dt>Metric Margin:</dt><dd>4-octet value which that indicates the
            metric margin when the M-flag is set. The metric margin is
            specified, depending on the A-flag, as either an absolute value or as
            a percentage of the best computed path metric based on the
            specified constraints for path calculation. The metric margin
            allows for the metric value of the computed path to vary
            (depending on the semantics of the specific metric type) from the
            best metric value possible to optimize optimizing for other factors (that are
            not specified as constraints) such as bandwidth availability,
            minimal SID stack depth, and the maximizing of ECMP for the computed SR path computed.</t>

              <t>Metric Bound: 4-octet path.</dd>
            <dt>Metric Bound:</dt><dd>4-octet value which that indicates the worst
            metric value (depending on the semantics of the specific metric
            type)
              that is allowed when the B-flag is set. If the computed path
            metric crosses the specified bound value value, then the path is
            considered invalid.</t>
            </list></t> invalid.</dd>
          </dl>
          <t>The absolute metric margin and the metric bound values are
          encoded as specified for each metric type. For metric types that are
          smaller than 4 octets in size, the most significant bits are filled
          with zeros. The percentage metric margin is encoded as an unsigned
          integer percentage value.</t>
        </section>
      </section>
      <section anchor="SEGMENTLIST" title="SR numbered="true" toc="default">
        <name>SR Segment List TLV"> TLV</name>
        <t>The SR Segment List TLV is used to report a single SID-List of a
        candidate path. Multiple instances of this TLV may be used to report
        multiple SID-Lists of a candidate path.</t>
        <t>The TLV has the following format: <figure align="center"> </t>
<figure>
  <name>SR Segment List TLV Format</name>

<!--[rfced] We note that Figure 18 contains two "RESERVED" fields.
As these are two distinctly different fields, should they be updated
as "RESERVED1" and "RESERVED2", which would reflect Figure 11?
-->

        <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             MTID              |   Algorithm   |    RESERVED   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Weight (4 octets)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   sub-TLVs (variable)                                        //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 18  SR Segment List TLV Format

Where:
]]></artwork>
          </figure><list style="symbols">
            <t>Type: 1205</t>

            <t>Length: variable</t>

            <t>Flags:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>1205</dd>
          <dt>Length:</dt><dd>Variable</dd>
          <dt>Flags:</dt><dd><t> 2-octet field that indicates the attribute and status of the
            SID-List.The
            SID-List. The following bit positions are defined defined, and the semantics
            are described in detail in <xref target="RFC9256"/>. target="RFC9256" format="default"/>. Other bits
            MUST
            <bcp14>MUST</bcp14> be cleared by the originator and MUST <bcp14>MUST</bcp14> be ignored by a
            receiver.<figure>
                <artwork><![CDATA[
            receiver.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|E|C|V|R|F|A|T|M|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
]]></artwork>
              </figure><list style="symbols">
                <t>D-Flag: Indicates
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
            <dl spacing="normal" newline="false">
              <dt>D-Flag:</dt><dd>Indicates that the SID-List consists of SRv6 SIDs
              when set and indicates it consists of SR/MPLS labels when
                clear.</t>

                <t>E-Flag: Indicates clear.</dd>
              <dt>E-Flag:</dt><dd>Indicates that the SID-List is associated with
              an explicit candidate path when set and with a dynamic candidate
              path when clear. All segment lists of a given candidate path
                MUST
              <bcp14>MUST</bcp14> be either explicit or dynamic and in dynamic. In case of
              inconsistency, the receiver MAY <bcp14>MAY</bcp14> consider them all
              to be
                dynamic.</t>

                <t>C-Flag: Indicates dynamic.</dd>
              <dt>C-Flag:</dt><dd>Indicates that the SID-List has been computed
              for a dynamic path when set. It is always reported as set for
              explicit paths. When clear, it indicates that the SID-List has
              not been computed for a dynamic path.</t>

                <t>V-Flag: Indicates path.</dd>
              <dt>V-Flag:</dt><dd>Indicates that the SID-List has passed
              verification or its verification was not required when set and
              that it failed verification when clear.</t>

                <t>R-Flag: Indicates clear.</dd>
              <dt>R-Flag:</dt><dd>Indicates that the first Segment has been
              resolved when set and that it failed resolution when clear.</t>

                <t>F-Flag: Indicates clear.</dd>
              <dt>F-Flag:</dt><dd>Indicates that the computation for the
              dynamic path failed when set and that it succeeded (or was not required in
              case of an explicit path) when clear.</t>

                <t>A-Flag: Indicates clear.</dd>
              <dt>A-Flag:</dt><dd>Indicates that all the SIDs in the SID-List
              belong to the specified algorithm when set and indicates that
              not all the SIDs belong to the specified algorithm when clear.</t>

                <t>T-Flag: Indicates
              clear.</dd>
              <dt>T-Flag:</dt><dd>Indicates that all the SIDs in the SID-List
              belong to the specified topology (identified by the
              multi-topology ID) when set and indicates that not all the SIDs
              belong to the specified topology when clear.</t>

                <t>M-Flag: Indicates clear.</dd>
              <dt>M-Flag:</dt><dd>Indicates that the SID-list has been removed
              from the forwarding plane due to fault detection by a monitoring
              mechanism (e.g. BFD) (e.g., Bidirectional Forwarding Detection (BFD)) when set and indicates that no fault is detected or
             no monitoring is not being done when clear.</t>
              </list></t>

            <t>RESERVED: 2 clear.</dd>
              </dl>
            </dd>
            <dt>RESERVED:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by
            the originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

            <t>MTID: 2
            receiver.</dd>
            <dt>MTID:</dt><dd>2 octets that indicates indicate the multi-topology identifier of
            the IGP topology that is to be used when the T-flag is set.</t>

            <t>Algorithm: 1 set.</dd>
            <dt>Algorithm:</dt><dd>1 octet that indicates the algorithm of the SIDs
            used in the SID-List when the A-flag is set. The algorithm values
            are from IGP the "IGP Algorithm Types Types" IANA registry under the IANA Interior "Interior
            Gateway Protocol (IGP) Parameters.</t>

            <t>RESERVED: 1 Parameters" registry group.</dd>
            <dt>RESERVED:</dt><dd>1 octet. MUST <bcp14>MUST</bcp14> be set to 0 by
            the originator and MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

            <t>Weight: 4-octet
            receiver.</dd>
            <dt>Weight:</dt><dd>4-octet field that indicates the weight
            associated with the SID-List for weighted load-balancing. load balancing. Refer to section 2.2
            Sections <xref target="RFC9256" sectionFormat="bare"
            section="2.2"/> and
            2.11 <xref target="RFC9256" sectionFormat="bare"
            section="2.11"/> of <xref target="RFC9256"/>.</t>

            <t>Sub-TLVs: variable target="RFC9256" format="default"/>.</dd>
            <dt>Sub-TLVs:</dt><dd>Variable and contains contain the ordered set of Segments and
            any other optional attributes associated with the specific
            SID-List.</t>
          </list></t>
            SID-List.</dd>
          </dl>
        <t>The SR Segment sub-TLV (defined in <xref target="SEGMENTTLV"/>)
        MUST target="SEGMENTTLV" format="default"/>)
        <bcp14>MUST</bcp14> be included as an ordered set of sub-TLVs within the SR Segment
        List TLV when the SID-List is not empty. A SID-List may be empty in
        certain situations (e.g. (e.g., for a dynamic path) where the headend has not
        yet performed the computation and hence not derived the segments
        required for the path. In such cases where the SID-LIST is empty, the
        SR Segment List TLV MUST NOT <bcp14>MUST NOT</bcp14> include any SR Segment sub-TLVs.</t>
        <section anchor="SEGMENTTLV" title="SR numbered="true" toc="default">
          <name>SR Segment Sub-TLV"> Sub-TLV</name>
          <t>The SR Segment sub-TLV describes a single segment in a SID-List.
          One or more instances of this sub-TLV in an ordered manner
          constitute a SID-List for an SR Policy candidate path. It is a
          sub-TLV of the SR Segment List TLV and it has the following format:
          <figure align="center">
          </t>
<figure>
  <name>SR Segment Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Type  |    RESERVED   |             Flags             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SID (4 or 16 octets)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//               Segment Descriptor (variable)                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//   Sub-TLVs (variable)                                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 19  SR Segment Sub-TLV Format

Where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 1206</t>

              <t>Length: variable</t>

              <t>Segment Type: 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
          <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1206</dd>
            <dt>Length:</dt><dd>Variable</dd>
            <dt>Segment Type:</dt><dd>1 octet which that indicates the type of
            segment.  Initial values are specified by this document (see <xref
              target="SEGMENTDESC"/>
            target="SEGMENTDESC" format="default"/> for details). Additional
            segment types are possible, possible but are out of scope for this document.</t>

              <t>RESERVED: 1
            document.</dd>
            <dt>RESERVED:</dt><dd>1 octet. MUST <bcp14>MUST</bcp14> be set to 0 by
            the originator and
              MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

              <t>Flags: 2-octet
            receiver.</dd>
            <dt>Flags:</dt><dd><t>2-octet field that indicates the attribute and
            status of the Segment and its SID. The following bit positions are defined
            defined, and the semantics are described in section 5 of <xref
              target="RFC9256"/>. target="RFC9256"
            sectionFormat="of" section="5"/>. Other bits MUST <bcp14>MUST</bcp14>
            be cleared by the originator and MUST <bcp14>MUST</bcp14> be ignored by
            a receiver.<figure>
                  <artwork><![CDATA[ receiver.</t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|V|R|A|                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
]]></artwork>
                </figure><list style="symbols">
                  <t>S-Flag: Indicates
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>S-Flag:</dt><dd>Indicates the presence of the SID value in the
                SID field when set and that no value is indicated when
                  clear.</t>

                  <t>E-Flag: Indicates
                clear.</dd>
                <dt>E-Flag:</dt><dd>Indicates that the SID value is an explicitly
                provisioned value (locally on headend or via controller/PCE)
                when set and is a dynamically resolved value by headend when
                  clear</t>

                  <t>V-Flag: Indicates
                clear.</dd>
                <dt>V-Flag:</dt><dd>Indicates that the SID has passed verification
                or did not require verification when set. When the V-Flag is
                clear, it indicates the SID has failed verification.</t>

                  <t>R-Flag: Indicates verification.</dd>
                <dt>R-Flag:</dt><dd>Indicates that the SID has been resolved or did
                not require resolution (e.g. (e.g., because it is not the first SID)
                when set. When the R-Flag is clear, it indicates the SID has
                failed resolution.</t>

                  <t>A-Flag: Indicates resolution.</dd>
                <dt>A-Flag:</dt><dd>Indicates that the Algorithm indicated in
                the Segment descriptor is valid when set. When clear, it
                indicates that the headend is unable to determine the
                algorithm of the SID.</t>
                </list></t>

              <t>SID: 4 SID.</dd>
                </dl>
              </dd>
              <dt>SID:</dt><dd><t>4 octets carrying the MPLS Label or 16 octets carrying
              the SRv6 SID based on the Segment Type. When carrying the MPLS
              Label, as shown in the figure below, the TC, S, and TTL (total
              of 12 bits) are RESERVED and MUST <bcp14>MUST</bcp14> be set to 0 by the originator
              and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                  <artwork><![CDATA[ receiver.</t>
              <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label                        | TC  |S|       TTL     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
                </figure></t>

              <t>Segment Descriptor: variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
            </dd>
            <dt>Segment Descriptor:</dt><dd>Variable size Segment descriptor
            based on the type of segment (refer to <xref target="SEGMENTDESC"/> target="SEGMENTDESC"
            format="default"/> for
              details)</t>

              <t>Sub-Sub-TLVs: variable details).</dd>
            <dt>Sub-Sub-TLVs:</dt><dd>Variable and contains contain any other optional
            attributes associated with the specific segment.</t>
            </list></t> segment.</dd>
          </dl>
          <t>The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure
          TLV (1252) defined in <xref target="RFC9514"/> target="RFC9514" format="default"/> are used as
          sub-sub-TLVs of the SR Segment sub-TLV. These two sub-sub-TLVs are
          used to optionally indicate the SRv6 Endpoint behavior and SID
          structure when advertising the SRv6 specific SRv6-specific segment types.</t>
          <section anchor="SEGMENTDESC" title="Segment Descriptors">
            <t>Section 4 of <xref target="RFC9256"/> numbered="true" toc="default">
            <name>Segment Descriptors</name>
            <t><xref target="RFC9256" sectionFormat="of" section="4"/> defines multiple types of
            segments and their description. descriptions. This section defines the encoding
            of the Segment Descriptors for each of those Segment segment types to be
            used in the Segment sub-TLV described previously in <xref
            target="SEGMENTTLV"/>.</t> target="SEGMENTTLV" format="default"/>.</t>
            <t>The following types are currently defined defined, and their mapping mappings to
            the respective segment types are defined in <xref target="RFC9256"/>:
            <figure align="center">
                <artwork align="left"><![CDATA[+------+-------------------------------------------------------------+
| Type |   Segment Description                                       |
+------+-------------------------------------------------------------+
|   1  | (Type target="RFC9256" format="default"/>:
            </t>

<table anchor="SR_segment_types">
  <name>SR Segment Types</name>
  <thead>
    <tr>
      <th>Type</th><th>Segment Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td><td>(Type A) SR-MPLS Label                                      |
|   2  | (Type Label</td>
    </tr>
    <tr>
      <td>2</td><td>(Type B) SRv6 SID as IPv6 address                           |
|   3  | (Type address</td>
    </tr>
    <tr>
      <td>3</td><td>(Type C) SR-MPLS Prefix SID as IPv4 Node Address            |
|   4  | (Type Address</td>
    </tr>
    <tr>
      <td>4</td><td>(Type D) SR-MPLS Prefix SID as IPv6 Node Global Address     |
|   5  | (Type Address</td>
    </tr>
    <tr>
      <td>5</td><td>(Type E) SR-MPLS Adjacency SID as IPv4 Node Address & &amp; Local |
|      | Interface ID                                                |
|   6  | (Type ID</td>
    </tr>
    <tr>
      <td>6</td><td>(Type F) SR-MPLS Adjacency SID as IPv4 Local & &amp; Remote       |
|      | Interface Addresses                                         |
|   7  | (Type Addresses</td>
    </tr>
    <tr>
      <td>7</td><td>(Type G) SR-MPLS Adjacency SID as pair of IPv6 Global       |
|      | Address & &amp; Interface ID for Local & &amp; Remote nodes             |
|   8  | (Type nodes</td>
    </tr>
    <tr>
      <td>8</td><td>(Type H) SR-MPLS Adjacency SID as pair of IPv6 Global       |
|      | Addresses for the Local & &amp; Remote Interface                  |
|   9  | (Type Interface</td>
    </tr>
    <tr>
      <td>9</td><td>(Type I) SRv6 END SID as IPv6 Node Global Address           |
|  10  | (Type Address</td>
    </tr>
    <tr>
      <td>10</td><td>(Type J) SRv6 END.X SID as pair of IPv6 Global Address &    |
|      | &amp; Interface ID for Local & &amp; Remote nodes                       |
|  11  | (Type nodes</td>
    </tr>
    <tr>
      <td>11</td><td>(Type K) SRv6 END.X SID as pair of IPv6 Global Addresses    |
|      | for the Local & &amp; Remote Interface                            |
+------+-------------------------------------------------------------+

                  Table 1  SR Segment Types

]]></artwork>
              </figure></t> Interface</td>
    </tr>
  </tbody>
</table>

            <section anchor="TYPE1" title="Type numbered="true" toc="default">
              <name>Type 1: SR-MPLS Label (Type A)"> A)</name>
              <t>The Segment is an SR-MPLS type and is specified simply as the
              label. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 1 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+

      Figure 20  Type 1 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>Algorithm: 1-octet
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>

              <dl spacing="normal" newline="false">
                <dt>Algorithm:</dt><dd>1-octet value that indicates the
                algorithm used for picking the SID. This is valid only when
                the A-flag has been set in the Segment TLV. The algorithm
                values are from IGP the "IGP Algorithm Types Types" IANA registry under the IANA Interior
                "Interior Gateway Protocol (IGP) Parameters.</t>
                </list></t> Parameters" registry group.</dd>
              </dl>
            </section>
            <section anchor="TYPE2" title="Type numbered="true" toc="default">
              <name>Type 2: SRv6 SID (Type B)"> B)</name>

<!--[rfced] Table 6 (Section 8.5) specifies the SRv6 SID as an "IPv6
address", but Section 5.7.1.1.2 specifies it as an "SRv6 SID address".
Is an update needed in Section 5.7.1.1.2 for consistency with Table 6?

Original:
   The Segment is SRv6 type and is specified simply as the SRv6 SID address.

Perhaps:
   The Segment is an SRv6 type and is specified simply as the IPv6 address.
-->

              <t>The Segment is an SRv6 type and is specified simply as the SRv6
              SID address. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 2 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+

      Figure 21  Type 2 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>Algorithm: 1-octet
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>Algorithm:</dt><dd>1-octet value that indicates the
                algorithm used for picking the SID. This is valid only when
                the A-flag has been set in the Segment TLV. The algorithm
                values are from IGP the "IGP Algorithm Types Types" IANA registry under the IANA Interior
                "Interior Gateway Protocol (IGP) Parameters.</t>
                </list></t> Parameters" registry group.</dd>
              </dl>
            </section>
            <section anchor="TYPE3"
                     title="Type numbered="true" toc="default">
              <name>Type 3: SR-MPLS Prefix SID for IPv4 (Type C)"> C)</name>
              <t>The Segment is an SR-MPLS Prefix SID type and is specified as an
              IPv4 node address. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 3 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 IPv4 Node Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 22  Type 3 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>Algorithm: 1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>Algorithm:</dt><dd>1-octet value that indicates the
                algorithm used for picking the SID. The algorithm values are
                from IGP the "IGP Algorithm Types Types" IANA registry under the IANA Interior "Interior
                Gateway Protocol (IGP) Parameters.</t>

                  <t>IPv4 Parameters" registry group.</dd>
                <dt>IPv4 Node Address: 4-octet Address:</dt><dd>4-octet value which that carries the
                IPv4 address associated with the node</t>
                </list></t> node.</dd>
              </dl>
            </section>
            <section anchor="TYPE4"
                     title="Type numbered="true" toc="default">
              <name>Type 4: SR-MPLS Prefix SID for IPv6 (Type D)"> D)</name>
              <t>The Segment is an SR-MPLS Prefix SID type and is specified as an
              IPv6 node global address. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 4 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv6 Node Global Address (16 octets)                 |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 23  Type 4 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>Algorithm: 1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>Algorithm:</dt><dd>1-octet value that indicates the
                algorithm used for picking the SID. The algorithm values are
                from IGP the "IGP Algorithm Types Types" IANA registry under the IANA Interior "Interior
                Gateway Protocol (IGP) Parameters.</t>

                  <t>IPv6 Parameters" registry group.</dd>
                <dt>IPv6 Node Global Address: 16-octet Address:</dt><dd>16-octet value which that
                carries the IPv6 global address associated with the node</t>
                </list></t> node.</dd>
              </dl>
            </section>
            <section anchor="TYPE5"
                     title="Type numbered="true" toc="default">
              <name>Type 5: SR-MPLS Adjacency SID for IPv4 with an Interface ID (Type E)"> E)</name>
              <t>The Segment is an SR-MPLS Adjacency SID type and is specified as
              an IPv4 node address along with the local interface ID on that
              node. The format of its Segment Descriptor is as follows:<figure
                  align="center"> follows:</t>
<figure>
  <name>Type 5 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 IPv4 Node Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Local Interface ID (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 24  Type 5 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>IPv4 Node Address: 4-octet Address:</dt><dd>4-octet value which that carries the
                IPv4 address associated with the node</t>

                  <t>Local node.</dd>
                <dt>Local Interface ID: 4-octet ID:</dt><dd>4-octet value which that carries
                the local interface ID of the node identified by the Node Address</t>
                </list></t>
                Address.</dd>
              </dl>
            </section>
            <section anchor="TYPE6"
                     title="Type numbered="true" toc="default">
              <name>Type 6: SR-MPLS Adjacency SID for IPv4 with an Interface Address (Type F)"> F)</name>
              <t>The Segment is an SR-MPLS Adjacency SID type and is specified as
              a pair of IPv4 local and remote interface addresses. The format of its
              Segment Descriptor is as follows:<figure align="center"> follows:</t>
	      <figure>

<!--[rfced] In Section 5.7.1.1.6, should "interface" be added to more
closely match Table 6 (the "BGP-LS SR Segment Descriptor Types"
registry)?

Link to registry:
https://www.iana.org/assignments/bgp-ls-parameters/
bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types

Original:
 IPv4 Local Address:
 IPv4 Remote Address:

Perhaps:
 IPv4 Local Interface Address:
 IPv4 Remote Interface Address:

...
Original (Figure 25):
 IPv4 Local Address (4 octets)
 IPv4 Remote Address (4 octets)

Perhaps:
 IPv4 Local Interface Address (4 octets)
 IPv4 Remote Interface Address (4 octets)
-->

  <name>Type 6 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                IPv4 Local Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IPv4 Remote Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 25  Type 6 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>IPv4 Local Address: 4-octet Address:</dt><dd>4-octet value which that carries
                the local IPv4 address associated with the node's interface</t>

                  <t>IPv4
                interface.</dd>
                <dt>IPv4 Remote Address: 4-octet Address:</dt><dd>4-octet value which that carries
                the remote IPv4 address associated with the interface on the
                node's neighbor. This is optional and MAY <bcp14>MAY</bcp14> be
                set to 0 when not used
                  (e.g. (e.g., when identifying point-to-point links).</t>
                </list></t>
                links).</dd>
              </dl>
            </section>
            <section anchor="TYPE7"
                     title="Type numbered="true" toc="default">
              <name>Type 7: SR-MPLS Adjacency SID for IPv6 with an interface Interface ID (Type G)"> G)</name>
              <t>The Segment is an SR-MPLS Adjacency SID type and is specified as
              a pair of IPv6 global address and interface ID for local and
              remote nodes. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 7 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv6 Local Node Global Address (16 octets)           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Local Node Interface ID (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv6 Remote Node Global Address (16 octets)          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Remote Node Interface ID (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 26  Type 7 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>IPv6 Local Node Global Address: Address:</dt><dd> 16-octet value which
                that carries the IPv6 global address associated with the
                local
                  node</t>

                  <t>Local node.</dd>
                <dt>Local Node Interface ID : 4-octet ID:</dt><dd>4-octet value which that
                carries the interface ID of the local node identified by the
                Local Node
                  Address</t>

                  <t>IPv6 Address.</dd>
                <dt>IPv6 Remote Node Global Address: 16-octet Address:</dt><dd>16-octet value which
                that carries the IPv6 global address associated with the
                remote node. This is optional and MAY <bcp14>MAY</bcp14> be set to
                0 when not used
                  (e.g. (e.g., when identifying point-to-point links).</t>

                  <t>Remote
                links).</dd>
                <dt>Remote Node Interface ID: 4-octet ID:</dt><dd>4-octet value which that
                carries the interface ID of the remote node identified by the
                Remote Node Address. This is optional and MAY <bcp14>MAY</bcp14>
                be set to 0 when not used (e.g. (e.g., when identifying
                point-to-point links).</t>
                </list></t> links).</dd>
              </dl>
            </section>
            <section anchor="TYPE8"
                     title="Type numbered="true" toc="default">
              <name>Type 8: SR-MPLS Adjacency SID for IPv6 with an Interface Address (Type H)"> H)</name>
              <t>The Segment is an SR-MPLS Adjacency SID type and is specified as
              a pair of IPv6 Global global addresses for local and remote interface
              addresses. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 8 Segment Descriptor</name>

<!--[rfced] In Sections 5.7.1.1.8 and 5.7.1.1.11, should the following
be updated for consistency with the descriptions in Table 6 (the
"BGP-LS SR Segment Descriptor Types" registry)?

Link to registry:
https://www.iana.org/assignments/bgp-ls-parameters/
bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types?

Original:
  IPv6 Local Address:
  IPv6 Remote Address:

Perhaps:
  IPv6 Local Global Address:
  IPv6 Remote Global Address:

...
Original (Figures 27 and 30):
   Global IPv6 Local Interface Address (16 octets)
   Global IPv6 Remote Interface Address (16 octets)

Perhaps:
   IPv6 Local Interface Global Address (16 octets)
   IPv6 Remote Interface Global Address (16 octets)
-->

              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|        Global IPv6 Local Interface Address (16 octets)        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|        Global IPv6 Remote Interface Address (16 octets)       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 27  Type 8 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>IPv6 Local Address: 16-octet Address:</dt><dd>16-octet value which that carries
                the local IPv6 address associated with the node's interface</t>

                  <t>IPv6
                interface.</dd>
                <dt>IPv6 Remote Address: 16-octet Address:</dt><dd>16-octet value which that carries
                the remote IPv6 address associated with the interface on the
                node's neighbor</t>
                </list></t> neighbor.</dd>
              </dl>
            </section>
            <section anchor="TYPE9"
                     title="Type numbered="true" toc="default">
              <name>Type 9: SRv6 END SID as IPv6 Node Address (Type I)"> I)</name>
              <t>The Segment is an SRv6 END SID type and is specified as an IPv6
              node global address. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 9 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv6 Node Global Address (16 octets)                 |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 28  Type 9 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>Algorithm: 1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>Algorithm:</dt><dd>1-octet value that indicates the
                algorithm used for picking the SID. The algorithm values are
                from IGP the "IGP Algorithm Types Types" IANA registry under the IANA Interior "Interior
                Gateway Protocol (IGP) Parameters.</t>

                  <t>IPv6 Parameters" registry group.</dd>
                <dt>IPv6 Node Global Address: 16-octet Address:</dt><dd>16-octet value which that
                carries the IPv6 global address associated with the node</t>
                </list></t> node.</dd>
              </dl>
            </section>
            <section anchor="TYPE10"
                     title="Type numbered="true" toc="default">
              <name>Type 10: SRv6 END.X SID as an Interface ID (Type J)"> J)</name>
              <t>The Segment is an SRv6 END.X SID type and is specified as a pair
              of IPv6 global address and interface ID for local and remote
              nodes. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 10 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv6 Local Node Global Address (16 octets)           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Local Node Interface ID (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv6 Remote Node Global Address (16 octets)          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Remote Node Interface ID (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 29  Type 10 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>IPv6 Local Node Global Address: 16-octet Address:</dt><dd>16-octet value which
                that carries the IPv6 global address associated with the
                local
                  node</t>

                  <t>Local node.</dd>
                <dt>Local Node Interface ID: 4-octet ID:</dt><dd>4-octet value which that
                carries the interface ID of the local node identified by the
                Local Node
                  Address</t>

                  <t>IPv6 Address.</dd>
                <dt>IPv6 Remote Node Global Address: 16-octet Address:</dt><dd>16-octet value which
                that carries the IPv6 global address associated with the
                remote node. This is optional and MAY <bcp14>MAY</bcp14> be set to
                0 when not used
                  (e.g. (e.g., when identifying point-to-point links).</t>

                  <t>Remote
                links).</dd>
                <dt>Remote Node Interface ID: 4-octet ID:</dt><dd>4-octet value which that
                carries the interface ID of the remote node identified by the
                Remote Node Address. This is optional and MAY <bcp14>MAY</bcp14>
                be set to 0 when not used (e.g. (e.g., when identifying
                point-to-point links).</t>
                </list></t> links).</dd>
              </dl>
            </section>
            <section anchor="TYPE11"
                     title="Type numbered="true" toc="default">
              <name>Type 11: SRv6 END.X SID as an Interface Address (Type K)"> K)</name>
              <t>The Segment is an SRv6 END.X SID type and is specified as a pair
              of IPv6 Global global addresses for local and remote interface
              addresses. The format of its Segment Descriptor is as
              follows:<figure align="center">
              follows:</t>
<figure>
  <name>Type 11 Segment Descriptor</name>
              <artwork align="left"><![CDATA[ align="left" name="" type="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|        Global IPv6 Local Interface Address (16 octets)        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|        Global IPv6 Remote Interface Address (16 octets)       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 30  Type 11 Segment Descriptor

Where:
]]></artwork>
                </figure></t>

              <t><list style="symbols">
                  <t>IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>IPv6 Local Address: 16-octet Address:</dt><dd>16-octet value which that carries
                the local IPv6 address associated with the node's interface</t>

                  <t>IPv6
                interface.</dd>
                <dt>IPv6 Remote Address: 16-octet Address:</dt><dd>16-octet value which that carries
                the remote IPv6 address associated with the interface on the
                node's neighbor</t>
                </list></t> neighbor.</dd>
              </dl>
            </section>
          </section>
        </section>
        <section anchor="SLMETRIC" title="SR numbered="true" toc="default">
          <name>SR Segment List Metric Sub-TLV"> Sub-TLV</name>
          <t>The SR Segment List Metric sub-TLV reports the computed metric of
          the specific SID-List. It is used to report the type of metric and
          its computed value by the computation entity (i.e., either the
          headend or the controller when the path is delegated) when
          available. More than one instance of this sub-TLV may be present in
          the SR Segment List to report metric values of different metric types.
          The metric margin and bound may be optionally reported using this
          sub-TLV when this information is not being reported using the SR
          Metric Constraint sub-TLV (refer to <xref target="CPMETRIC"/>) target="CPMETRIC" format="default"/>) at
          the SR Policy candidate path level.</t>
          <t>It is a sub-TLV of the SR Segment List TLV and has the following
          format: <figure align="center"> </t>
<figure>
  <name>SR Segment List Metric Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Metric Type  |      Flags    |          RESERVED             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metric Margin                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metric Bound                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metric Value                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 31  SR Segment List Metric Sub-TLV Format

Where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 1207</t>

              <t>Length: 16 octets</t>

              <t>Metric Type: 1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
          <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1207</dd>
            <dt>Length:</dt><dd>16 octets</dd>
            <dt>Metric Type:</dt><dd>1-octet field which that identifies the type
            of metric. The semantics are the same as the Metric Type field in
            the SR Metric Constraints Constraint sub-TLV in <xref target="CPMETRIC"/> target="CPMETRIC"
            format="default"/> of this document.</t>

              <t>Flags: 1-octet document.</dd>
            <dt>Flags:</dt><dd><t>1-octet field that indicates the validity of the
              metric fields and their semantics. The following bit positions
              are defined defined, and the other bits MUST <bcp14>MUST</bcp14> be cleared by the originator
              and MUST <bcp14>MUST</bcp14> be ignored by a receiver.<figure>
                  <artwork><![CDATA[ receiver.</t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|A|B|V|       |
   +-+-+-+-+-+-+-+-+

Where:]]></artwork>
                </figure><list style="symbols">
                  <t>M-Flag: Indicates
+-+-+-+-+-+-+-+-+]]></artwork>

<t>Where:</t>
              <dl spacing="normal" newline="false">
                <dt>M-Flag:</dt><dd>Indicates that the metric margin allowed
                for this path computation is specified when set and indicates
                that the metric margin allowed is not specified when clear.</t>

                  <t>A-Flag: Indicates clear.</dd>
                <dt>A-Flag:</dt><dd>Indicates that the metric margin is
                specified as an absolute value when set and that the metric margin is expressed as a
                percentage of the minimum metric when clear.</t>

                  <t>B-Flag: Indicates clear.</dd>
                <dt>B-Flag:</dt><dd>Indicates that the metric bound allowed
                for the path is specified when set and indicates that the metric
                bound is not specified when clear.</t>

                  <t>V-Flag: Indicates clear.</dd>
                <dt>V-Flag:</dt><dd>Indicates that the computed metric value computed
                is being reported when set and indicates that the computed
                metric value is not being reported when clear.</t>
                </list></t>

              <t>RESERVED: 2 clear.</dd>
                </dl>
            </dd>
            <dt>RESERVED:</dt><dd>2 octets. MUST <bcp14>MUST</bcp14> be set to 0 by
            the originator and
              MUST <bcp14>MUST</bcp14> be ignored by a receiver.</t>

              <t>Metric Margin: 4-octet
            receiver.</dd>
            <dt>Metric Margin:</dt><dd>4-octet value which that indicates the
            metric margin value when the M-flag is set. The metric margin is
            specified, depending on the A-flag, as either an absolute value or as
            a percentage of the best computed path metric based on the
            specified constraints for path calculation. The metric margin
            allows for the metric value of the computed path to vary
            (depending on the semantics of the specific metric type) from the
            best metric value possible to optimize optimizing for other factors (that are
            not specified as constraints) such as bandwidth availability,
            minimal SID stack depth, and the maximizing of ECMP for the computed SR path computed.</t>

              <t>Metric Bound: 4-octet path.</dd>
            <dt>Metric Bound:</dt><dd>4-octet value which that indicates the worst
            metric value (depending on the semantics of the specific metric
            type) that is allowed when the B-flag is set. If the computed path
            metric crosses the specified bound value value, then the path is
            considered invalid.</t>

              <t>Metric Value: 4-octet invalid.</dd>
            <dt>Metric Value:</dt><dd>4-octet value which that indicates the metric
            of the computed path when the V-flag is set. This value is
            available and reported when the computation is successful and a
            valid path is available.</t>
            </list></t> available.</dd>
          </dl>
          <t>The absolute metric margin, metric bound, and metric values are
          encoded as specified for each metric type. For metric types that are
          smaller than 4 octets in size, the most significant bits are filled
          with zeros. The percentage metric margin is encoded as an unsigned
          integer percentage value.</t>
        </section>
        <section anchor="SLBW" title="SR numbered="true" toc="default">
          <name>SR Segment List Bandwidth Sub-TLV"> Sub-TLV</name>
          <t>The SR Segment List Bandwidth sub-TLV is an optional sub-TLV used
          to report the bandwidth allocated to the specific SID-List by the
          path computation entity. Only a single instance of this sub-TLV is
          advertised for a given Segment List. If multiple instances are
          present, then the first valid one (i.e., not determined to be malformed
          as per section 8.2.2 of <xref target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and
          the rest are ignored.</t>
          <t>It is a sub-TLV of the SR Segment List TLV and has the following
          format: <figure align="center"> </t>

<figure>
  <name>SR Segment List Bandwidth Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Bandwidth                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 32  SR Segment List Bandwidth Sub-TLV Format

Where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 1216</t>

              <t>Length: 4 octets</t>

              <t>Bandwidth: 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
          <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1216</dd>
            <dt>Length:</dt><dd>4 octets</dd>
            <dt>Bandwidth:</dt><dd>4 octets which that specify the allocated
            bandwidth in unit of bytes per second in IEEE floating point
            format <xref
              target="IEEE754"/>.</t>
            </list></t> target="IEEE754" format="default"/>.</dd>
          </dl>
        </section>
        <section anchor="SLID" title="SR numbered="true" toc="default">
          <name>SR Segment List Identifier Sub-TLV"> Sub-TLV</name>
          <t>The SR Segment List Identifier sub-TLV is an optional sub-TLV
          used to report an identifier associated with the specific SID-List.
          Only a single instance of this sub-TLV is advertised for a given
          Segment List. If multiple instances are present, then the first
          valid one (i.e., not determined to be malformed as per section 8.2.2 of
          <xref target="RFC9552"/>) one target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used and the rest are ignored.</t>
          <t>It is a sub-TLV of the SR Segment List TLV and has the following
          format: <figure align="center"> </t>
<figure>
  <name>SR Segment List Identifier Sub-TLV Format</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Segment List Identifier                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 33  SR Segment List Identifier Sub-TLV Format

Where:
]]></artwork>
            </figure><list style="symbols">
              <t>Type: 1217</t>

              <t>Length: 4 octets</t>

              <t>Segment
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>Where:</t>
          <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>1217</dd>
            <dt>Length:</dt><dd>4 octets</dd>
            <dt>Segment List Identifier: 4 Identifier:</dt><dd>4 octets which that carry a 32-bit
            unsigned non-zero integer that serves as the identifier associated
            with the segment list. A value of 0 indicates that there is no
            identifier associated with the Segment List. The scope of this
            identifier is the SR Policy Candidate path.</t>
            </list></t> path.</dd>
	  </dl>
        </section>
      </section>
    </section>
    <section anchor="Procedures" title="Procedures"> numbered="true" toc="default">
      <name>Procedures</name>
      <t>The BGP-LS advertisements for the SR Policy Candidate Path NLRI type
      are generally originated by the headend node for the SR Policies that
      are instantiated on its local node (i.e., the headend is the BGP-LS
      Producer). The BGP-LS Producer may also be a node (e.g., a PCE) that is
      advertising on behalf of the headend.</t>
      <t>For the reporting of SR Policy Candidate Paths, the NLRI descriptor
      TLV as specified in <xref target="SRPOLICYCP"/> target="SRPOLICYCP" format="default"/> is used. An SR Policy
      candidate path may be instantiated on the headend node via a local
      configuration, PCEP, or BGP SR Policy signaling signaling, and this is indicated
      via the SR Protocol Origin. When a PCE node is the BGP-LS Producer, it
      uses the "in PCEP" variants of the SR Protocol Origin (where available)
      so as to distinguish them from advertisements by headend nodes. The SR
      Policy Candidate Path's state and attributes are encoded in the BGP-LS
      Attribute field as SR Policy State TLVs and sub-TLVs as described in
      <xref target="SRPOLICYTLVS"/>. target="SRPOLICYTLVS" format="default"/>. The SR Candidate Path State TLV as
      defined in <xref target="CPSTATE"/> target="CPSTATE" format="default"/> is included to report the state of
      the candidate path. The SR BSID TLV as defined in Sections <xref
      target="CPBSID"/> or target="CPBSID" format="counter"/> and <xref target="CPBSIDSRV6"/> target="CPBSIDSRV6" format="counter"/> is included to report
      the BSID of the candidate path when one is either specified or allocated
      by the headend. The constraints and the optimization metric for the SR
      Policy Candidate Path are reported using the SR Candidate Path
      Constraints TLV and its sub-TLVs as described in <xref
      target="CPCONSTRAINTS"/>. target="CPCONSTRAINTS" format="default"/>. The SR Segment List TLV is included for each
      of the SID-List(s) associated with the candidate path. Each SR Segment
      List TLV in turn includes an SR Segment sub-TLV(s) to report the segment(s)
      and their its status. The SR Segment List Metric sub-TLV is used to report
      the metric values at an individual SID List level.</t>
    </section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>The Existing existing BGP operational and management procedures apply to this
      document. No new procedures are defined in this document. The
      considerations as specified in <xref target="RFC9552"/> target="RFC9552" format="default"/> apply to this
      document.</t>
      <t>In general, the SR Policy head-end headend nodes are responsible for the
      advertisement of SR Policy state information.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This section describes the code point allocation allocations by IANA for this
      document.</t>
      <section anchor="NLRITYPES" title="BGP-LS NLRI-Types"> numbered="true" toc="default">
        <name>BGP-LS NLRI Types</name>
        <t>IANA maintains a registry called "BGP-LS NLRI-Types" in NLRI Types" under the "Border
        Gateway Protocol - Link State (BGP-LS) Parameters" registry group.</t>
        <t>The following table lists the NLRI Type code points that have point has been allocated
        by IANA:</t>

        <t><figure>
            <artwork><![CDATA[ +------+-------------------------------+---------------+
 | Type | NLRI
	<table>
	  <name>NLRI Type                     |   Reference   |
 +------+-------------------------------+---------------+
 |  5   | SR Code Point</name>
	  <thead><tr><th>Type</th><th>NLRI Type</th><th>Reference</th></tr></thead>
	  <tbody><tr><td>5</td><td>SR Policy Candidate Path NLRI | this document |
 +------+-------------------------------+---------------+

            Table 2  NLRI Type Codepoint
]]></artwork>
          </figure></t> NLRI</td><td>RFC 9857</td></tr></tbody>
	</table>

      </section>
      <section anchor="PROTOCOLIDS" title="BGP-LS Protocol-IDs"> numbered="true" toc="default">
        <name>BGP-LS Protocol-IDs</name>
        <t>IANA maintains a registry called "BGP-LS Protocol-IDs" in under the
        "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry
        group.</t>
        <t>The following Protocol-ID codepoints have code point has been allocated by
        IANA:</t>

        <t><figure>
            <artwork><![CDATA[ +-------------+----------------------------------+---------------+
 | Protocol-ID | NLRI

	<table>
	  <name>Protocol-ID Code Point</name>
	  <thead><tr><th>Protocol-ID</th><th>NLRI information source protocol |   Reference   |
 +-------------+----------------------------------+---------------+
 |     9       |       Segment Routing            | this document |
 +-------------+----------------------------------+---------------+

                  Table 3  Protocol ID Codepoint
]]></artwork>
          </figure></t> protocol</th><th>Reference</th></tr></thead>
	  <tbody><tr><td>9</td><td>Segment Routing</td><td>RFC 9857</td></tr></tbody>
	</table>

      </section>
      <section anchor="BGPLSTLVS" title="BGP-LS TLVs"> numbered="true" toc="default">
        <name>BGP-LS TLVs</name>
        <t>IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs"
        in
        under the "Border Gateway Protocol - Link State (BGP-LS) Parameters"
        registry group.</t>
        <t>The following table lists the TLV code points that have been
        allocated by IANA:</t>

        <t><figure>
            <artwork><![CDATA[+-------+----------------------------------------+---------------+
|
<table>
  <name>NLRI and Attribute TLV Code  |             Description                | Value defined |
| Point |                                        |       in      |
+-------+----------------------------------------+---------------+
|   554 |   SR Points</name>
  <thead>
    <tr>
      <th>TLV Code Point</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>554</td><td>SR Policy Candidate Path Descriptor  | this document |
|  1201 |   SR Descriptor</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1201</td><td>SR Binding SID                       | this document |
|  1202 |   SR SID</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1202</td><td>SR Candidate Path State              | this document |
|  1203 |   SR State</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1203</td><td>SR Candidate Path Name               | this document |
|  1204 |   SR Name</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1204</td><td>SR Candidate Path Constraints        | this document |
|  1205 |   SR Constraints</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1205</td><td>SR Segment List</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1206</td><td>SR Segment</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1207</td><td>SR Segment List                      | this document |
|  1206 |   SR Segment                           | this document |
|  1207 |   SR Segment List Metric               | this document |
|  1208 |   SR Metric</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1208</td><td>SR Affinity Constraint               | this document |
|  1209 |   SR Constraint</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1209</td><td>SR SRLG Constraint                   | this document |
|  1210 |   SR Constraint</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1210</td><td>SR Bandwidth Constraint              | this document |
|  1211 |   SR Constraint</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1211</td><td>SR Disjoint Group Constraint         | this document |
|  1212 |   SRv6 Constraint</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1212</td><td>SRv6 Binding SID                     | this document |
|  1213 |   SR Policy Name                       | this document |
|  1214 |   SR SID</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1213</td><td>SR Policy Name</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1214</td><td>SR Bidirectional Group Constraint    | this document |
|  1215 |   SR Constraint</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1215</td><td>SR Metric Constraint                 | this document |
|  1216 |   SR Constraint</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1216</td><td>SR Segment List Bandwidth            | this document |
|  1217 |   SR Bandwidth</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1217</td><td>SR Segment List Identifier           | this document |
+-------+----------------------------------------+---------------+

        Table 4  NLRI and Attribute TLVs Codepoint
]]></artwork>
          </figure></t> Identifier</td><td>RFC 9857</td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="PROTOCOLORIGINS" title="SR numbered="true" toc="default">
        <name>SR Policy Protocol Origin">
        <t>Note to IANA (RFC editor to remove Origin</name>

<!-- [rfced] Section 4 of this before publication): The
        new registry creation request below is also present in the
        draft-ietf-pce-segment-routing-policy-cp. IANA is requested document as well as RFC 9256 uses
"Protocol-Origin" rather than "Protocol Origin". Are any updates
needed to process the "SR Policy Protocol Origin" registry creation via the first of these name, two documents to reach
        publication stage and the authors
instances of the other document would update
        the IANA considerations suitably. The initial allocations in "SR Protocol Origin", or "Protocol Origin field"?

Original:
   Per this
        document are a super-set of the initial allocations in
        draft-ietf-pce-segment-routing-policy-cp.</t>

        <t>This document requests document, IANA to maintain has created and maintains a new registry
   called "SR Policy Protocol Origin" under the "Segment Routing"
   registry group with the allocation policy of "Expert
        Review" <xref target="RFC8126"/> Expert Review [RFC8126]
   using the guidelines for Designated
        Experts designated experts as specified in <xref target="RFC9256"/>. The
   [RFC9256]. This registry contains the code points allocated to the
   "Protocol Origin" field defined in Section 4.
-->

        <t>Per this document, IANA has created and maintains a new registry is called "SR Policy Protocol Origin" and should have under
        the reference to
        this document. "Segment Routing" registry group with the allocation policy of Expert
        Review <xref target="RFC8126" format="default"/> using the guidelines for designated
        experts as specified in <xref target="RFC9256" format="default"/>. This registry contains the codepoints code points allocated to the
        "Protocol Origin" field defined in <xref target="SRPOLICYCP"/>.</t>

        <t>The registry contains the following codepoints, with initial
        values, to be target="SRPOLICYCP" format="default"/>.</t>
        <t>IANA has assigned by IANA with the reference set to this
        document:<figure>
            <artwork><![CDATA[+---------+--------------------------------------+---------------+
|  Code   |                                      |               |
|  Point  | initial values as follows:</t>
<table>
  <name>SR Policy Protocol Origin                     |   Reference   |
+---------+--------------------------------------+---------------+
|   0     | Reserved (not to be used)            | this document |
|   1     | PCEP                                 | this document |
|   2     | BGP SR Policy                        | this document |
|   3     | Configuration Code Points</name>
  <thead>
    <tr>
      <th>Code Point</th>
      <th>Protocol Origin</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td><td>Reserved</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1</td><td>PCEP</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>2</td><td>BGP SR Policy</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>3</td><td>Configuration (CLI, YANG model via   | this document |
|         | NETCONF, etc.)                       |               |
|   4-9   | Unassigned                           | this document |
|   10    | PCEP (In etc.)</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>4-9</td><td>Unassigned</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>10</td><td>PCEP (in PCEP or when                | this document |
|         | BGP-LS Producer is PCE)              |               |
|  11-19  | Unassigned                           | this document |
|   20    | BGP PCE)</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>11-19</td><td>Unassigned</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>20</td><td>BGP SR Policy (In (in PCEP or when       | this document |
|         | BGP-LS Producer is PCE)              |               |
|  21-29  | Unassigned                           | this document |
|   30    | Configuration PCE)</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>21-29</td><td>Unassigned</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>30</td><td>Configuration (CLI, YANG model via   | this document |
|         | NETCONF, etc.) (In etc. In PCEP or when      |               |
|         | BGP-LS Producer is PCE)              |               |
|  31-250 | Unassigned                           | this document |
| 251-255 | PCE)</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>31-250</td><td>Unassigned</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>251-255</td><td>Reserved for Private Use (not to be assigned by   | this document |
|         | IANA)                                |               |
+---------+--------------------------------------+---------------+

        Table 5  SR Policy Protocol Origin Codepoint
]]></artwork>
          </figure></t> Use</td><td>RFC 9857</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="SEGDESC" title="BGP-LS numbered="true" toc="default">
        <name>BGP-LS SR Segment Descriptors">
        <t>This document requests Descriptors</name>
        <t>Per this document, IANA to create has created a registry called "SR "BGP-LS SR Segment
        Descriptor Types" under the "Border Gateway Protocol - Link State
        (BGP-LS) Parameters" registry group with the allocation policy of
        "Expert Review"
        Expert Review <xref target="RFC8126"/> target="RFC8126" format="default"/> using the guidelines for
        Designated Experts
        designated experts as specified in <xref target="RFC9552"/>. target="RFC9552" format="default"/>. There is
        also an additional guideline to for the Designated Experts designated experts to maintain the
        alignment between the allocations in this registry with those in the
        "Segment Types" registry under the "Segment Routing" registry group.
        This requires that an allocation in the Segment Routing "Segment
        Types" registry is required before allocation can be done in the
        BGP-LS "SR
        "BGP-LS SR Segment Descriptor Types" registry for a new segment type.
        However, this does not mandate that the specification of a new Segment
        Routing Segment Type also requires the specification of its equivalent
        SR Segment Descriptor Type in BGP-LS; that can be done as and when
        required while maintaining alignment.</t>
        <t>This registry contains the codepoints code points allocated to the "Segment
        Type" field defined in <xref target="SEGMENTTLV"/> target="SEGMENTTLV" format="default"/> and described in
        <xref target="SEGMENTDESC"/>. The registry contains target="SEGMENTDESC" format="default"/>. IANA has assigned the following
        codepoints, with initial values, to values as follows:</t>

<!--[rfced] Under the "Segment Descriptor" column in the "BGP-LS SR
Segment Descriptor Types" registry, should the following changes
be assigned by IANA with made to the
        reference set code point descriptions?  That is, add articles,
make names following "pair" plural, and capitalize instances of
"address" and "node", accordingly.

The form to this document:<figure>
            <artwork><![CDATA[+---------+---------------------------------------+---------------+
|  Code  |   Segment Description                  |  Reference    |
|  Point |                                        |               |
+--------+----------------------------------------+---------------+
|    0   | Reserved (not the right of the arrow is suggested. If changes are made,
we will update the running text accordingly (namely the subsections
under Section 5.7.1.1) as well as the IANA registry.

Link to be used)              | this document |
|    1   | (Type A) SR-MPLS Label                 | this document |
|    2   | registry:
<https://www.iana.org/assignments/bgp-ls-parameters/
bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>

  (Type B) SRv6 SID as IPv6 address      | this document |
|    3   | -> (Type B) SRv6 SID as an IPv6 Address

  (Type C) SR-MPLS Prefix SID as         | this document |
|        | IPv4 Node Address                      |               |
|    4   | ->
     (Type C) SR-MPLS Prefix SID as an IPv4 Node Address

  (Type D) SR-MPLS Prefix SID as         | this document |
|        | IPv6 Node Global Address               |               |
|    5   | ->
     (Type D) SR-MPLS Prefix SID as an IPv6 Node Global Address

  (Type E) SR-MPLS Adjacency SID as      | this document |
|        | IPv4 Node Address & Local Interface ID |               |
|    6   | ->
     (Type E) SR-MPLS Adjacency SID as an IPv4 Node Address & a Local Interface ID

(Note: Section 5.7.1.1.6 describes Type F as a "pair"; is that correct to add?)
  (Type F) SR-MPLS Adjacency SID as      | this document |
|        | IPv4 Local & Remote Interface Addresses|               |
|    7   | Addresses ->
     (Type F) SR-MPLS Adjacency SID as a pair of IPv4 Local & Remote
     Interface Addresses

  (Type G) SR-MPLS Adjacency SID as pair | this document |
|        | of IPv6 Global Address & Interface ID  |               |
|        | for
  Local & Remote nodes               |               |
|    8   | ->
     (Type G) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses &
     Interface IDs for Local & Remote Nodes

  (Type H) SR-MPLS Adjacency SID as pair | this document |
|        | of IPv6 Global Addresses for the       |               |
|        |
  Local & Remote Interface               |               |
|    9   | ->
     (Type H) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses for
      Local & Remote Interface Addresses

  (Type I) SRv6 END SID as IPv6 Node     | this document |
|        | Global Address
|   10   | ->
     (Type I) SRv6 END SID as an IPv6 Node Global Address

  (Type J) SRv6 END.X SID as pair of     | this document |
|        | IPv6 Global Address & Interface ID
  for |               |
|        | Local & Remote nodes                   |               |
|   11   | ->
      (Type J) SRv6 END.X SID as a pair of IPv6 Global Addresses & Interface IDs
      for Local & Remote Nodes

  (Type K) SRv6 END.X SID as pair of     | this document |
|        | IPv6 Global Addresses for the          |               |
|        | Local &
  Remote Interface               |               |
| 12-255 | Unassigned                             | this document |
+--------+----------------------------------------+---------------+

            Table 6 ->
      (Type K) SRv6 END.X SID as a pair of IPv6 Global Addresses for Local &
      Remote Interface Addresses
-->

<table>
  <name>BGP-LS SR Segment Descriptor Types Codepoint
]]></artwork>
          </figure></t> Type Code Points</name>
<thead>
  <tr>
    <th>Code Point</th><th>Segment Descriptor</th><th>Reference</th>
  </tr>
</thead>
<tbody>
  <tr>
    <td>0</td><td>Reserved</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>1</td><td>(Type A) SR-MPLS Label</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>2</td><td>(Type B) SRv6 SID as IPv6 address</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>3</td><td>(Type C) SR-MPLS Prefix SID as IPv4 Node Address</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>4</td><td>(Type D) SR-MPLS Prefix SID as IPv6 Node Global Address</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>5</td><td>(Type E) SR-MPLS Adjacency SID as IPv4 Node Address &amp; Local Interface ID</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>6</td><td>(Type F) SR-MPLS Adjacency SID as IPv4 Local &amp; Remote Interface Addresses</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>7</td><td>(Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address &amp; Interface ID for Local &amp; Remote nodes</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>8</td><td>(Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for the Local &amp; Remote Interface</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>9</td><td>(Type I) SRv6 END SID as IPv6 Node Global Address</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>10</td><td>(Type J) SRv6 END.X SID as pair of IPv6 Global Address &amp; Interface ID for Local &amp; Remote nodes</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>11</td><td>(Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for the Local &amp; Remote Interface</td><td>RFC 9857</td>
  </tr>
  <tr>
    <td>12-255</td><td>Unassigned</td><td>RFC 9857</td>
  </tr>
</tbody>
</table>
      </section>
      <section anchor="METRICTYPE" title="BGP-LS numbered="true" toc="default">
        <name>BGP-LS SR Policy Metric Type">
        <t>This document requests Type</name>
        <t>Per this document, IANA to create has created a registry called "BGP-LS SR
        Policy Metric Type" Types" under the "Border Gateway Protocol - Link State
        (BGP-LS) Parameters" registry group with the allocation policy of
        "Expert Review"
        Expert Review <xref target="RFC8126"/> target="RFC8126" format="default"/> using the guidelines for
        Designated Experts
        designated experts as specified in <xref target="RFC9552"/>. target="RFC9552" format="default"/>. This
        registry contains the codepoints code points allocated to the "metric type" "Metric Type" field
        defined in <xref target="SLMETRIC"/>. The registry contains the
        following codepoints, with initial values, to be assigned by target="SLMETRIC" format="default"/>. IANA with has assigned the reference set to this document:<figure>
            <artwork><![CDATA[+---------+--------------------------------+---------------------+
|  Code   |                                |                     |
|  Point  | initial values as follows:</t>
<table>
  <name>SR Policy Metric Type                |  Reference          |
+---------+--------------------------------+---------------------+
|    0    | IGP                            | this document       |
|    1    | Min Code Point</name>
  <thead>
    <tr><th>Code Point</th><th>Metric Type</th><th>Reference</th></tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td><td>IGP</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>1</td><td>Min Unidirectional Delay       | this document       |
|    2    | TE                             | this document       |
|    3    | Hop Count                      | this document       |
|    4    | SID Delay</td><td>RFC 9857</td>
    </tr>
    <tr>
    <td>2</td><td>TE</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>3</td><td>Hop Count</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>4</td><td>SID List Length                | this document       |
|    5    | Bandwidth                      | this document       |
|    6    | Avg Length</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>5</td><td>Bandwidth</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>6</td><td>Avg Unidirectional Delay</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>7</td><td>Unidirectional Delay       | this document       |
|    7    | Unidirectional Delay Variation | this document       |
|    8    | Loss                           | this document       |
|  9-127  | Unassigned                     | this document       |
| 128-255 | User Defined                   | this document       |
+---------+--------------------------------+---------------------+

            Table 7  SR Policy Metric Type Codepoint
]]></artwork>
          </figure></t> Variation</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>8</td><td>Loss</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>9-127</td><td>Unassigned</td><td>RFC 9857</td>
    </tr>
    <tr>
      <td>128-255</td><td>User Defined</td><td>RFC 9857</td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Procedures and protocol extensions defined in this document do not
      affect the base BGP security model. See <xref target="RFC6952"/> target="RFC6952" format="default"/> for
      details. The security considerations of the base BGP-LS specification as
      described in <xref target="RFC9552"/> target="RFC9552" format="default"/> also apply.</t>
      <t>The BGP-LS SR Policy extensions specified in this document enable
      traffic engineering
      TE and service programming use-cases use cases within an SR
      domain as described in <xref target="RFC9256"/>. target="RFC9256" format="default"/>. SR operates within a
      trusted SR domain <xref target="RFC8402"/> target="RFC8402" format="default"/>, and its security
      considerations also apply to BGP sessions when carrying SR Policy
      information. The SR Policies advertised to controllers and other
      applications via BGP-LS are expected to be used entirely within this
      trusted SR domain, i.e., within a single AS or between multiple
      ASes/domains within a single provider network. Therefore, precaution is
      necessary to ensure that the SR Policy information advertised via BGP
      sessions is limited to nodes and/or controllers/applications in a secure
      manner within this trusted SR domain. The general guidance for BGP-LS
      with respect to isolation of BGP-LS sessions from BGP sessions for other
      address-families (refer to the security considerations of <xref
      target="RFC9552"/>) target="RFC9552" format="default"/>) may be used to ensure that the SR Policy information
      is not advertised by accident or error to an EBGP External BGP (EBGP) peering session
      outside the SR domain.</t> domain by accident or error.</t>
      <t>Additionally, it may be considered that the export of SR Policy
      information, as described in this document, constitutes a risk to
      the confidentiality of mission-critical or commercially sensitive
      information about the network (more specifically specifically, endpoint/node
      addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not
      automatic and require configuration. Thus, it is the responsibility of
      the network operator to ensure that only trusted nodes (that include
      both routers and controller applications) within the SR domain are
      configured to receive such information.</t>
    </section>

    <section anchor="Contributors" title="Contributors">
      <t>The following people have substantially contributed
  </middle>
  <back>

    <displayreference target="I-D.ietf-idr-bgp-ls-te-path" to="BGP-LS-TE-PATH"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.2328.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- [RFC9843]
draft-ietf-lsr-flex-algo-bw-con-22 companion doc RFC-to-be 9843 in AUTH48 as
of 08/18/25.
-->

<reference anchor="RFC9843" target="https://www.rfc-editor.org/info/rfc9843">
  <front>
     <title>IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints</title>
      <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
         <organization>Juniper Networks Inc.</organization>
      </author>
      <author initials="W." surname="Britto" fullname="William Britto">
         <organization>Juniper Networks Inc.</organization>
      </author>
      <author initials="R." surname="Shetty" fullname="Rajesh Shetty">
         <organization>Juniper Networks Inc.</organization>
      </author>
      <author initials="B." surname="Decraene" fullname="Bruno Decraene">
         <organization>Orange</organization>
      </author>
      <author initials="P." surname="Psenak" fullname="Peter Psenak">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="T." surname="Li" fullname="Tony Li">
         <organization>Juniper Networks Inc.</organization>
      </author>
    <date month='September' year='2025'/>
  </front>
  <seriesInfo name="RFC" value="9843"/>
  <seriesInfo name="DOI" value="10.17487/RFC9843"/>
</reference>

        <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.5305.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.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.9514.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>

<!-- [RFC9830] [I-D.ietf-idr-sr-policy-safi]
draft-ietf-idr-sr-policy-safi-13
IESG State: in AUTH48-DONE (RFC 9830) as of 08/05/25 but is waiting for companion docs to the editing finish EDIT->AUTH48 prior to PUB <https://www.rfc-editor.org/cluster_info.php?cid=C534>)
-->
<reference anchor="RFC9830" target="https://www.rfc-editor.org/info/rfc9830">
   <front>
      <title>Advertising Segment Routing Policies in BGP</title>
      <author initials="S." surname="Previdi" fullname="Stefano Previdi">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="P." surname="Mattes" fullname="Paul Mattes">
         <organization>Microsoft</organization>
      </author>
      <author initials="D." surname="Jain" fullname="Dhanendra Jain">
         <organization>Google</organization>
      </author>
      <date month="September" year="2025" />
   </front>
  <seriesInfo name="RFC" value="9830"/>
  <seriesInfo name="DOI" value="10.17487/RFC9830"/>
</reference>

<!-- [RFC 9831] [I-D.ietf-idr-bgp-sr-segtypes-ext]
draft-ietf-idr-bgp-sr-segtypes-ext-08
IESG State: in AUTH48-DONE (RFC 9831) as of
      this document:</t>

      <t><figure>
          <artwork><![CDATA[Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com

]]></artwork>
        </figure><figure>
          <artwork><![CDATA[Mach (Guoyi) Chen
Huawei Technologies
Email: mach.chen@huawei.com

]]></artwork>
        </figure></t>
    </section> 09/04/25
-->

<reference anchor="RFC9831" target="https://www.rfc-editor.org/info/rfc9831">
   <front>
      <title>Segment Type Extensions for BGP Segment Routing (SR) Policy</title>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="S." surname="Previdi" fullname="Stefano Previdi">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="P." surname="Mattes" fullname="Paul Mattes">
         <organization>Microsoft</organization>
      </author>
      <author initials="D." surname="Jain" fullname="Dhanendra Jain">
         <organization>Google</organization>
      </author>
      <date month="September" year="2025"/>
   </front>
  <seriesInfo name="RFC" value="9831"/>
  <seriesInfo name="DOI" value="10.17487/RFC9831"/>
</reference>

<!-- [I-D.ietf-idr-bgp-ls-te-path]
draft-ietf-idr-bgp-ls-te-path-02
IESG State: Expired as of 08/06/25.
-->
<reference anchor="I-D.ietf-idr-bgp-ls-te-path" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-te-path-02">
   <front>
      <title>Advertisement of Traffic Engineering Paths using BGP Link-State</title>
      <author initials="S." surname="Previdi" fullname="Stefano Previdi">
         <organization>Individual</organization>
      </author>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="J." surname="Dong" fullname="Jie Dong">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="H." surname="Gredler" fullname="Hannes Gredler">
         <organization>RtBrick Inc.</organization>
      </author>
      <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
         <organization>Nvidia</organization>
      </author>
      <date month="November" day="11" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-te-path-02" />

</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2702.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5065.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8800.xml"/>
<!-- [IEEE754] -->
        <reference anchor="IEEE754" target="https://ieeexplore.ieee.org/document/8766229">
          <front>
            <title>IEEE Standard for Floating-Point Arithmetic</title>
            <author>
              <organization abbrev="IEEE">Institute of Electrical and Electronics
            Engineers</organization>
            </author>
            <date day="22" month="July" year="2019"/>
          </front>
          <seriesInfo name="IEEE Std" value="754-2019"/>
          <seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/>
        </reference>
      </references>
    </references>
      <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Dhruv Dhody, Mohammed <contact fullname="Dhruv Dhody"/>,
      <contact fullname="Mohammed Abdul Aziz
      Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah,
      Dhanendra Jain, Francois Clad, Zafar Ali, Stephane Litkowski, Aravind Khalid"/>, <contact fullname="Lou
      Berger"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Siva
      Sivabalan"/>, <contact fullname="Arjun Sreekantiah"/>, <contact
      fullname="Dhanendra Jain"/>, <contact fullname="Francois Clad"/>,
      <contact fullname="Zafar Ali"/>, <contact fullname="Stephane
      Litkowski"/>, <contact fullname="Aravind Babu Mahendra Babu, Geetanjalli Bhalla, Ahmed Bashandy, Mike Koldychev,
      Samuel Sidor, Alex Tokar, Rajesh Babu"/>, <contact
      fullname="Geetanjalli Bhalla"/>, <contact fullname="Ahmed Bashandy"/>,
      <contact fullname="Mike Koldychev"/>, <contact fullname="Samuel
      Sidor"/>, <contact fullname="Alex Tokar"/>, <contact fullname="Rajesh
      Melarcode Venkatesswaran, Lin
      Changwang, Liu Yao, Joel Halpern, and Ned Smith Venkatesswaran"/>, <contact fullname="Lin Changwang"/>,
      <contact fullname="Liu Yao"/>, <contact fullname="Joel Halpern"/>, and
      <contact fullname="Ned Smith"/> for their review reviews and valuable
      comments. The authors would also like to thank Susan Hares <contact fullname="Susan
      Hares"/> for her shepherd review of the document and helpful comments to
      improve this document. The authors would like to thank John Scudder <contact
      fullname="John Scudder"/> for his AD review and helpful suggestions to
      improve this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.2328'?>

      <?rfc include='reference.RFC.3630'?>

      <?rfc include='reference.RFC.5329'?>

      <?rfc include='reference.RFC.5340'?>

      <?rfc include='reference.RFC.7471'?>

      <?rfc include='reference.RFC.5440'?>

      <?rfc include='reference.RFC.9552'?>

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

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

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

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

      <?rfc include='reference.RFC.5305'?>

      <?rfc include='reference.RFC.8570'?>

      <?rfc include='reference.RFC.8697'?>

      <?rfc include='reference.RFC.8664'?>

      <?rfc include='reference.RFC.9256'?>

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

      <?rfc include='reference.RFC.9514'?>

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

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

      <?rfc include='reference.I-D.ietf-idr-sr-policy-safi'?>

      <?rfc include='reference.I-D.ietf-idr-bgp-sr-segtypes-ext'?>

      <?rfc include='reference.I-D.ietf-idr-bgp-ls-te-path'?>

      <?rfc include='reference.RFC.2702'?>

      <?rfc include='reference.RFC.4202'?>

      <?rfc include='reference.RFC.7308'?>

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

      <?rfc include='reference.RFC.8231'?>

      <?rfc include='reference.RFC.5065'?>

      <?rfc include='reference.RFC.8800'?>

      <reference anchor="IEEE754">
        <front>
          <title>IEEE Standard
    <section anchor="Contributors" numbered="false" toc="default">

<!--[rfced] FYI: In the Contributors section, we updated the lead-in
text as follows to indicate that the individuals listed are
coauthors.

Original:
   The following people have substantially contributed to the editing of
   this document:

Current:
   The following people have contributed substantially to the
   content of this document and should be considered coauthors:
-->

      <name>Contributors</name>
      <t>The following people have contributed substantially to the content of
      this document and should be considered coauthors:</t>

    <contact fullname="Clarence Filsfils">
      <organization>Cisco Systems</organization>
      <address>
        <email>cfilsfil@cisco.com</email>
      </address>
    </contact>

    <contact fullname="Mach(Guoyi) Chen">
      <organization>Huawei Technologies</organization>
      <address>
        <email>mach.chen@huawei.com</email>
      </address>
    </contact>
    </section>

<!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

 -Flag vs. -flag
   (e.g., "D-Flag" vs. "A-flag" in the running text)
 Metric Type field vs. "metric type" field
   (Note: the companion document uses "metric type field" with no quote marks)
 Segment Descriptor vs. Segment descriptor
 Segment List vs. segment list
 SID-List vs. SID-list vs. SID-LIST vs. SID List
 SR Policy Candidate Path NLRI Type vs. SR Policy Candidate Path NLRI type
 SR Policy Candidate Path vs. SR Policy Candidate path vs. SR Policy candidate path

b) We updated the following terms for Floating-Point Arithmetic</title>

          <author>
            <organization>Institute consistency. Please let us know of Electrical any objections.

 codepoint -> code point (per IANA registries)
 dataplane -> data plane
 drop upon invalid -> Drop-Upon-Invalid (per RFC 9256)
 Global address -> global address (2 instances in the running text)
 head-end -> headend
 nexthop -> next hop
 traffic engineering -> Traffic Engineering (per RFC 9552 and Electronics
            Engineers</organization>
          </author>

          <date day="22" month="July" year="2019"/>
        </front>

        <seriesInfo name="IEEE" value="754-2019"/>

        <seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/>

        <format target="https://ieeexplore.ieee.org/document/8766229"
                type="HTML"/>
      </reference>
    </references> the companion document)

c) FYI: We made "Constraints" in the following sub-TLV names singular for consistency
with Table 4.

 SR Affinity Constraints Sub-TLV -> SR Affinity Constraint Sub-TLV (Figure 12)
 SR Bandwidth Constraints Sub-TLV -> SR Bandwidth Constraint Sub-TLV (Figure 14)

 SR Bidirectional Group Constraints Sub-TLV ->
    SR Bidirectional Group Constraint Sub-TLV (Figure 16)

 SR Disjoint Group Constraints Sub-TLV -> SR Disjoint Group Constraint Sub-TLV (Figure 15)
 SR Metric Constraints Sub-TLV -> SR Metric Constraint Sub-TLV (Figure 17 and Section 5.7.2)
 SR SRLG Constraints Sub-TLV -> SR SRLG Constraint Sub-TLV (Figure 13)

d) FYI: We updated 7 instances of "Descriptor" to "Descriptors"
for TLV 256 per RFC 9552.

 Local Node Descriptor (TLV 256) -> Local Node Descriptors (TLV 256)
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

 Autonomous System Number (ASN)
 Bidirectional Forwarding Detection (BFD)
 External BGP (EBGP)
 Label Edge Routers (LERs)
 Label Switched Path (LSP)
 Label Switching Router (LSR)
 Network Layer Reachability Information (NLRI)
 Path Computation Element Communication Protocol (PCEP)

b) To reflect more common usage in previously published RFCs, may we update
the expansion of "BGP-LS" from "BGP Link-State" to "BGP - Link State"? If yes,
note that the title of this document would also be updated accordingly.

Original:
   Advertisement of Segment Routing Policies using BGP Link-State
   ...
   This document describes a mechanism to collect the Segment Routing
   Policy information that is locally available in a node and advertise
   it into BGP Link-State (BGP-LS) updates.

Perhaps:
   Advertisement of Segment Routing Policies using BGP - Link State
   ...
   This document describes a mechanism to collect the Segment Routing
   Policy information that is locally available in a node and advertise
   it into BGP - Link State (BGP-LS) updates.
-->

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

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

  </back>
</rfc>