<?xml version="1.0" encoding="US-ASCII"?>
<!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"?>
<rfc category="std" docName="draft-ietf-idr-bgp-ls-sr-policy-07"
     ipr="trust200902">
  <front>
    <title abbrev="Advertising SR Policies using BGP-LS">Advertisement of
    Segment Routing Policies using BGP Link-State</title>

    <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>

    <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 to collect the Segment Routing
      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, service
      placement, network visualization, etc.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>SR Policy architecture details are specified in <xref
      target="RFC9256"/>. An SR Policy comprises one or more candidate paths
      (CP) of which at a given time one and only one may be active (i.e.,
      installed in forwarding and usable for steering of traffic). Each CP in
      turn may have one or more SID-List of which one or more SID-List may be
      active. When multiple SID-Lists are active then traffic is load balanced
      over them. This document covers the advertisement of state information
      at the individual SR Policy CP level.</t>

      <t>SR Policies are generally instantiated at the head-end and are based
      on either local configuration or controller-based programming of the
      node using various APIs and protocols (e.g., PCEP or BGP).</t>

      <t>In many network environments, the configuration, and state of each SR
      Policy that is available in the network is required by controllers. Such
      controllers, that are aware of both topology and SR Policy state
      information, allow the network operator to optimize several functions
      and operations in their networks.</t>

      <t>One example of a controller is the stateful Path Computation Element
      (PCE) <xref target="RFC8231"/>, which could provide benefits in path
      optimization. While some extensions are proposed in the Path Computation
      Element Communication Protocol (PCEP) for the Path Computation Clients
      (PCCs) to report the 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"/>. 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. In this
      case, a general mechanism to collect the SR Policy states from the
      ingress LERs is needed. This document proposes a SR Policy state
      collection mechanism complementary to the mechanism defined in <xref
      target="RFC8231"/>.<figure>
          <artwork><![CDATA[                                 -----------
                                |   -----   |
            Service             |  | TED |<-+----------->
            Request             |   -----   |  TED synchronization
               |                |     |     |  mechanism (e.g.,
               v                |     |     |  routing protocol)
         ------------- Request/ |     v     |
        |             | Response|   -----   |
        |     NMS     |<--------+> | PCE |  |
        |             |         |   -----   |
         -------------           -----------
       Service |
       Request |
               v
          ----------  Signaling   ----------
         | Head-End | Protocol   | Adjacent |
         |  Node    |<---------->|   Node   |
          ----------              ----------

               Figure 1.  Management-Based PCE Usage
]]></artwork>
        </figure></t>

      <t>In networks with composite PCE nodes as specified in section 5.1 of
      <xref target="RFC4655"/>, PCE is implemented on several routers in the
      network, and the PCCs in the network can use the mechanism described in
      <xref target="RFC8231"/> 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 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 information to external components <xref target="RFC9552"/>.
      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, and SRv6 <xref target="RFC8402"/>) to external components using
      BGP-LS and covers both explicit and dynamic candidate paths. The
      advertisements of composite candidate path is outside the scope of this
      document. While this document focuses on SR Policies, <xref
      target="I-D.ietf-idr-bgp-ls-te-path"/> introduces further extension to
      support other TE Paths such as MPLS-TE LSPs.</t>

      <t>This extensions specified in this document complement the BGP SR
      Policy SAFI <xref target="I-D.ietf-idr-sr-policy-safi"/> that is 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>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section anchor="TEINFOINBGP"
             title="Carrying SR Policy Information in BGP">
      <t>The "Link-State NLRI" defined in <xref target="RFC9552"/> is extended
      to carry the SR Policy information. New TLVs carried in the BGP
      Link-State Attribute defined in <xref target="RFC9552"/> are also
      defined to carry the attributes of a SR Policy in the subsequent
      sections.</t>

      <t>The format of "Link-State NLRI" is defined in <xref
      target="RFC9552"/> as follows:<figure>
          <artwork align="center"><![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)                 //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t>An additional "NLRI Type" known as SR Policy Candidate Path 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 Policy Candidate Path NLRI Type">
      <t>This document defines SR Policy Candidate Path NLRI Type with its
      format as shown in the following figure:</t>

      <t><figure>
          <artwork align="center"><![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 TLV (for the Headend)          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SR Policy Candidate Path Descriptor TLV           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:]]></artwork>
        </figure><list style="symbols">
          <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 to be used for
          advertisement of SR Policies.</t>

          <t>"Identifier" is an 8 octet value as defined in <xref
          target="RFC9552"/>.</t>

          <t>"Local Node Descriptor" (TLV 256) <xref target="RFC9552"/> is
          used as specified further in this section.</t>

          <t>The SR Policy Candidate Path Descriptor TLV is specified in <xref
          target="SRPOLICYCP"/>.</t>
        </list></t>

      <t>The Local Node Descriptor TLV MUST include the following Node
      Descriptor TLVs only when the headend node is the BGP-LS Producer:<list
          style="symbols">
          <t>BGP Router-ID (TLV 516) <xref target="RFC9086"/>, which contains
          a valid BGP Identifier of the headend node of the SR Policy.</t>

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

      <t>The Local Node Descriptor TLV MUST include at least one of the
      following Node Descriptor TLVs:<list style="symbols">
          <t>IPv4 Router-ID of Local Node (TLV 1028) <xref target="RFC9552"/>,
          which identifies the headend node of the SR Policy as specified in
          section 2.1 of <xref target="RFC9256"/>.</t>

          <t>IPv6 Router-ID of Local Node (TLV 1029) <xref target="RFC9552"/>,
          which identifies the headend node of the SR Policy as specified in
          section 2.1 of <xref target="RFC9256"/>.</t>
        </list></t>

      <t>The Local Node Descriptor TLV MAY include the following Node
      Descriptor TLVs only when the headend node is the BGP-LS Producer:<list
          style="symbols">
          <t>BGP Confederation Member (TLV 517) <xref target="RFC9086"/>,
          which contains the ASN of the confederation member (i.e. Member-AS
          Number), if BGP confederations are used, the headend node of the SR
          Policy.</t>

          <t>Other Node Descriptors as defined in <xref target="RFC9552"/> 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 shall
          always be "Segment Routing".</t>
        </list></t>

      <t>When a Path Computation Element (PCE) node is functioning as the
      BGP-LS Producer on behalf of one or more headends, it MAY include its
      own BGP Router-ID (TLV 516), Autonomous System Number (TLV 512), or BGP
      Confederation Member (TLV 517) in the BGP-LS Attribute. The PCE node
      MUST NOT include its identifiers in the Node Descriptor TLV in the NLRI
      as the Node Descriptor TLV MUST only carry the identifiers of the SR
      Policy headend.</t>
    </section>

    <section anchor="SRPOLICYCP" title="SR Policy Candidate Path Descriptor">
      <t>The SR Policy Candidate Path Descriptor TLV identifies a Segment
      Routing Policy Candidate Path (CP) as defined in <xref
      target="RFC9256"/>. It is used with the Protocol-ID set to Segment
      Routing to advertise the SR Policy Candidate Path NLRI Type. It is a
      mandatory TLV for SR Policy Candidate Path NLRI type. The TLV has the
      following format: <figure>
          <artwork align="center"><![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|    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)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

          <t>Length: variable (valid values are 24, 36 or 48 octets)</t>

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

          <t>Flags: 1-octet field with following bit positions defined. Other
          bits MUST be cleared by the originator and MUST be ignored by a
          receiver.<figure>
              <artwork><![CDATA[    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |E|O|           |
   +-+-+-+-+-+-+-+-+

where:]]></artwork>
            </figure><list style="symbols">
              <t>E-Flag: Indicates the encoding of endpoint as IPv6 address
              when set and IPv4 address when clear</t>

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

          <t>Reserved: 2 octets which MUST be set to 0 by the originator and
          MUST be ignored by a receiver.</t>

          <t>Endpoint: 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 octets that indicate the color of the SR Policy as
          specified in section 2.1 of <xref target="RFC9256"/>.</t>

          <t>Originator ASN: 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 or 16 octets (as indicated by the flags) to
          carry the address of the originator. Refer to section 2.4 of <xref
          target="RFC9256"/> for details.</t>

          <t>Discriminator: 4 octets to carry the discriminator of the path.
          Refer to section 2.5 of <xref target="RFC9256"/> for details.</t>
        </list></t>
    </section>

    <section anchor="SRPOLICYTLVS" title="SR Policy State TLVs">
      <t>This section defines the various TLVs which enable the headend to
      report the state at the SR Policy CP level. These TLVs (and their
      sub-TLVs) are carried in the optional non-transitive BGP-LS Attribute
      defined in <xref target="RFC9552"/> associated with the SR Policy CP
      NLRI type.</t>

      <t>The detailed procedures for the advertisement are described in <xref
      target="Procedures"/>.</t>

      <section anchor="CPBSID" title="SR Binding SID TLV">
        <t>The SR Binding SID (BSID) is an optional TLV that is used to report
        the BSID and its attributes for the SR Policy CP. The TLV MAY also
        optionally contain the Specified BSID value for reporting as described
        in section 6.2.3 of <xref target="RFC9256"/>. Only a single instance
        of this TLV is advertised for a given CP. If multiple instances are
        present, then the first one is considered valid and the rest are
        ignored.</t>

        <t>The TLV has the following format:<figure align="center">
            <artwork align="left"><![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)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

            <t>Length: variable (valid values are 12 or 36 octets)</t>

            <t>BSID Flags: 2-octet field that indicates attribute and status
            of the Binding SID (BSID) associated with this CP. The following
            bit positions are defined and the semantics are described in
            detail in section 6.2 of <xref target="RFC9256"/>. Other bits MUST
            be cleared by the originator and MUST be ignored by a
            receiver.<figure>
                <artwork><![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: Indicates the dataplane for the BSIDs and if they
                are 16 octet SRv6 SID when set and are 4 octet SR/MPLS label
                value when clear.</t>

                <t>B-Flag: 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 the specified BSID value is unavailable
                when set. When clear it indicates that this CP is using the
                specified BSID. This flag is ignored when there is no
                specified BSID.</t>

                <t>L-Flag: Indicates 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 the BSID value is one allocated from
                dynamic label pool due to fallback (e.g. when 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 octets. MUST be set to 0 by the originator and MUST
            be ignored by a receiver.</t>

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

            <t>Specified BSID: It is 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 BSID has not been
            specified.</t>
          </list></t>

        <t>The BSID fields above depend on the dataplane (SRv6 or MPLS)
        indicated by the D-Flag. If D-Flag set (SRv6 dataplane), then the
        length of the BSID fields is 16 octets. If the D-Flag is clear (MPLS
        dataplane), 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 be set to 0 by the
        originator and MUST be ignored by a receiver.</t>

        <t><figure>
            <artwork><![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>In the case of an SRv6, the SR Binding SID sub-TLV does not have
        the ability to signal the SRv6 Endpoint Behavior <xref
        target="RFC8986"/> or the structure of the SID. Therefore, the SR
        Binding SID sub-TLV SHOULD NOT be used for the advertisement of an
        SRv6 Binding SID. Instead, the SRv6 Binding SID TLV defined in <xref
        target="CPBSIDSRV6"/> SHOULD be used for signaling of an SRv6 Binding
        SID. The use of the SR Binding SID sub-TLV for advertisement of the
        SRv6 Binding SID is supported only for backward compatibility with
        implementations that followed early versions of this
        specification.</t>
      </section>

      <section anchor="CPBSIDSRV6" title="SRv6 Binding SID TLV">
        <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 CP. The TLV
        MAY also optionally contain the Specified SRv6 BSID value for
        reporting as described in section 6.2.3 of <xref target="RFC9256"/>.
        Multiple instances of this TLV may be used to report each of the SRv6
        BSIDs associated with the CP.</t>

        <t>The TLV has the following format:<figure align="center">
            <artwork align="left"><![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)                                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

            <t>Length: variable</t>

            <t>BSID Flags: 2-octet field that indicates attribute and status
            of the Binding SID (BSID) associated with this CP. The following
            bit positions are defined and the semantics are described in
            detail in section 6.2 of <xref target="RFC9256"/>. Other bits MUST
            be cleared by the originator and MUST be ignored by a
            receiver.<figure>
                <artwork><![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 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 the specified BSID value is unavailable
                when set. When clear it indicates that this CP is using the
                specified BSID. This flag is ignored when there is no
                specified BSID.</t>

                <t>F-Flag: Indicates the BSID value is one allocated
                dynamically due to fallback (e.g. when 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 octets. MUST be set to 0 by the originator and MUST
            be ignored by a receiver.</t>

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

            <t>Specified BSID: It is 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 BSID has not been
            specified.</t>

            <t>Sub-TLVs: variable and contains any other optional attributes
            associated with the SRv6 BSID.</t>
          </list></t>

        <t>The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure
        TLV (1252) MAY 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"/> defines SRv6
        Endpoint Behavior TLV And SRv6 SID Structure TLV.</t>
      </section>

      <section anchor="CPSTATE" title="SR Candidate Path State TLV">
        <t>The SR Candidate Path (CP) State TLV provides the operational
        status and attributes of the SR Policy at the CP level. Only a single
        instance of this TLV is advertised for a given CP. If multiple
        instances are present, then the first one is considered valid and the
        rest are ignored.</t>

        <t>The TLV has the following format:<figure align="center">
            <artwork align="left"><![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)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

            <t>Length: 8 octets</t>

            <t>Priority: 1-octet value which indicates the priority of the CP.
            Refer Section 2.12 of <xref target="RFC9256"/>.</t>

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

            <t>Flags: 2-octet field that indicates attribute and status of the
            CP. The following bit positions are defined and the semantics are
            described in section 5 of <xref target="RFC9256"/> unless stated
            otherwise for individual flags. Other bits MUST be cleared by the
            originator and MUST be ignored by a receiver.<figure>
                <artwork><![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 the CP is in an administrative shut state
                when set and not in administrative shut state when clear.</t>

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

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

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

                <t>V-Flag: Indicates the CP 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 CP
                has not been evaluated), then this flag MUST be set to 0 by
                the originator and ignored by the receiver.</t>

                <t>O-Flag: Indicates the CP was instantiated by the headend
                due to an on-demand nexthop trigger based on a local template
                when set and that the CP has not been instantiated due to
                on-demand nexthop trigger when clear. Refer to section 8.5 of
                <xref target="RFC9256"/> for details.</t>

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

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

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

                <t>T-Flag: Indicates the CP 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. Refer to
                section 8.3 of <xref target="RFC9256"/>.</t>

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

            <t>Preference: 4-octet value which indicates the preference of the
            CP. Refer to section 2.7 of <xref target="RFC9256"/> for
            details.</t>
          </list></t>
      </section>

      <section anchor="POLNAME" title="SR Policy Name TLV">
        <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 CP. If multiple instances are
        present, then the first one is considered valid and the rest are
        ignored.</t>

        <t>The TLV has the following format:<figure align="center">
            <artwork align="left"><![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)                  //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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 2.1 of <xref
            target="RFC9256"/>. It is RECOMMENDED that the size of the
            symbolic name be limited to 255 bytes. Implementations MAY choose
            to truncate long names to 255 bytes when signaling via BGP-LS.</t>
          </list></t>
      </section>

      <section anchor="CPNAME" title="SR Candidate Path Name TLV">
        <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 CP. If multiple
        instances are present, then the first one is considered valid and the
        rest are ignored.</t>

        <t>The TLV has the following format:<figure align="center">
            <artwork align="left"><![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)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

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

            <t>Length: variable</t>

            <t>Candidate Path Name: Symbolic name for the SR Policy candidate
            path without a NULL terminator as specified in section 2.6 of
            <xref target="RFC9256"/>. It is RECOMMENDED that the size of the
            symbolic name be limited to 255 bytes. Implementations MAY choose
            to truncate long names to 255 bytes when signaling via BGP-LS.</t>
          </list></t>
      </section>

      <section anchor="CPCONSTRAINTS"
               title="SR Candidate Path Constraints TLV">
        <t>The SR Candidate Path Constraints TLV is an optional TLV that is
        used to report the constraints associated with the candidate path. The
        constraints are generally applied to a dynamic candidate path which 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 if 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 CP. If multiple instances are present, then the
        first one is considered valid and the rest are ignored.</t>

        <t>The TLV has the following format:<figure align="center">
            <artwork align="left"><![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)                                        //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

            <t>Length: variable</t>

            <t>Flags: 2-octet field that indicates the constraints that are
            being applied to the CP. The following bit positions are defined
            and the other bits MUST be cleared by the originator and MUST be
            ignored by a receiver.<figure>
                <artwork><![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 that the CP uses SRv6 dataplane when set
                and SR/MPLS dataplane when clear</t>

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

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

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

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

                <t>S-Flag: 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 that the CP is fixed once computed and
                not modified except on operator intervention and indicates
                that the CP may be modified as part of recomputation when
                clear.</t>

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

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

            <t>MTID: 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 then the path is strictly using the
            specified topology SIDs only.</t>

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

            <t>RESERVED2: 1 octet. MUST be set to 0 by the originator and MUST
            be ignored by a receiver.</t>

            <t>sub-TLVs: one or more optional sub-TLVs MAY be included in this
            TLV to describe other constraints. These sub-TLVs are: SR Affinity
            Constraint, SR SRLG Constraint, SR Bandwidth Constraint, SR
            Disjoint Group Constraint, SR Bidirectional Group Constraint, and
            SR Metric Constraint.</t>
          </list></t>

        <t>These constraint sub-TLVs are defined below.</t>

        <section anchor="CPAFFINITY" title="SR Affinity Constraint Sub-TLV">
          <t>The SR Affinity Constraint sub-TLV is an optional sub-TLV of the
          SR CP Constraints TLV that is used to carry the affinity constraints
          <xref target="RFC2702"/> associated with the candidate path. The
          affinity is expressed in terms of Extended Admin Group (EAG) as
          defined in <xref target="RFC7308"/>. Only a single instance of this
          sub-TLV is advertised for a given CP. If multiple instances are
          present, then the first one is considered valid and the rest are
          ignored.</t>

          <t>The sub-TLV has the following format:<figure align="center">
              <artwork align="left"><![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)             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

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

              <t>Length: variable, dependent on the size of the Extended Admin
              Group. MUST be a multiple of 4 octets.</t>

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

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

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

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

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

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

              <t>Include-All EAG: the bitmask used to represent all the
              affinities that have been included in the path.</t>
            </list></t>
        </section>

        <section anchor="CPSRLG" title="SR SRLG Constraint Sub-TLV">
          <t>The SR SRLG Constraint sub-TLV is an optional sub-TLV of the SR
          CP Constraints TLV that is used to carry the Shared Risk Link Group
          (SRLG) values <xref target="RFC4202"/> that have been excluded from
          the candidate path. Only a single instance of this sub-TLV is
          advertised for a given CP. If multiple instances are present, then
          the first one is considered valid and the rest are ignored.</t>

          <t>The sub-TLV has the following format:<figure align="center">
              <artwork align="left"><![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)        //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

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

              <t>Length: variable, dependent on the number of SRLGs encoded.
              MUST be a multiple of 4 octets.</t>

              <t>SRLG Values: One or more SRLG values. Each SRLG value is of 4
              octets.</t>
            </list></t>
        </section>

        <section anchor="CPBW" title="SR Bandwidth Constraint Sub-TLV">
          <t>The SR Bandwidth Constraint sub-TLV is an optional sub-TLV of the
          SR CP 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 CP. If multiple instances are
          present, then the first one is considered valid and the rest are
          ignored.</t>

          <t>The sub-TLV has the following format:<figure align="center">
              <artwork align="left"><![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                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

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

              <t>Length: 4 octets</t>

              <t>Bandwidth: 4 octets which specify the desired bandwidth in
              unit of bytes per second in IEEE floating point format.</t>
            </list></t>
        </section>

        <section anchor="CPDISJOINT"
                 title="SR Disjoint Group Constraint Sub-TLV">
          <t>The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV
          of the SR CP 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 computation
          is expected to achieve the highest level of disjointness requested
          and when that is not possible then fallback to a lesser level
          progressively based on the levels indicated. Only a single instance
          of this sub-TLV is advertised for a given CP. If multiple instances
          are present, then the first one is considered valid and the rest are
          ignored.</t>

          <t>The sub-TLV has the following format:<figure align="center">
              <artwork align="left"><![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)                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

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

              <t>Length: Variable. Minimum of 8 octets.</t>

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

where:]]></artwork>
                </figure><list style="symbols">
                  <t>S-Flag: Indicates that SRLG disjointness is requested
                  when set and indicates that SRLG disjointness is not
                  requested when clear.</t>

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

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

                  <t>F-Flag: Indicates that the computation may fallback 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 that the computation may fallback to
                  the default best path (e.g. 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 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 and the other
              bits MUST be cleared by the originator and MUST be ignored by a
              receiver.<figure>
                  <artwork><![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 that SRLG disjointness is achieved when
                  set and indicates that SRLG disjointness is not achieved
                  when clear.</t>

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

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

                  <t>F-Flag: 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 that the computation has fallen back to
                  the best path (e.g. IGP path) and disjointness has not been
                  achieved when set and indicates that there has been no
                  fallback to best path when clear.</t>

                  <t>X-Flag : Indicates that the disjointness constraint could
                  not be achieved and hence 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 octets. MUST be set to 0 by the originator and
              MUST be ignored by a receiver.</t>

              <t>Disjointness Group Identifier: 4-octet value that is the
              group identifier for a set of disjoint paths. A PCEP Association
              Object <xref target="RFC8697"/> (including its optional TLVs)
              MAY also be advertised to convey the disjoint group
              identifier.</t>
            </list></t>
        </section>

        <section anchor="CPBIDIR"
                 title="SR Bidirectional Group Constraint Sub-TLV">
          <t>The SR Bidirectional Group Constraint sub-TLV is an optional
          sub-TLV of the SR CP 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 CP. If multiple instances are present,
          then the first one is considered valid and the rest are ignored.</t>

          <t>The sub-TLV has the following format:<figure align="center">
              <artwork align="left"><![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)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

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

              <t>Length: Variable. Minimum of 8 octets.</t>

              <t>Flags: two octets to indicate the bidirectional path setup
              information as specified in the form of flags. The following
              flags are defined and the other bits MUST be cleared by the
              originator and MUST be ignored by a receiver.<figure>
                  <artwork><![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 that this CP of the SR Policy forms the
                  reverse path when the R-Flag is set. If the R-Flag is clear,
                  this CP forms the forward path.</t>

                  <t>C-Flag: 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 octets. MUST be set to 0 by the originator and
              MUST be ignored by a receiver.</t>

              <t>Bidirectional Group Identifier: 4-octet value that is the
              group identifier for a set of bidirectional paths. A PCEP
              Association Object <xref target="RFC8697"/> (including its
              optional TLVs) MAY also be advertised to convey the
              bidirectional group identifier. The PCEP Association Object MUST
              NOT be encoded and this sub-TLV skipped along with an error log,
              if the object size is such that the update for a single SR
              Policy CP NLRI would exceed the supported BGP message size by
              the implementation. Refer section 5.3 of <xref
              target="RFC9552"/> for discussion on implications of encoding
              large sets of information into BGP-LS.</t>
            </list></t>
        </section>

        <section anchor="CPMETRIC" title="SR Metric Constraint Sub-TLV">
          <t>The SR Metric Constraint sub-TLV is an optional sub-TLV of the SR
          CP Constraints TLV that is used to report the optimization metric of
          the CP. 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 be used to report the metric margin or 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">
              <artwork align="left"><![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                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

              <t>Length: 12 octets</t>

              <t>Metric Type: 1-octet field which identifies the type of the
              metric being used. The metric type code points are listed in
              <xref target="METRICTYPE"/> of this document.</t>

              <t>Flags: 1-octet field that indicates the validity of the
              metric fields and their semantics. The following bit positions
              are defined and the other bits MUST be cleared by the originator
              and MUST be ignored by a receiver.<figure>
                  <artwork><![CDATA[
    0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+
   |O|M|A|B|       |
   +-+-+-+-+-+-+-+-+

where:]]></artwork>
                </figure><list style="symbols">
                  <t>O-Flag: Indicates that this is the optimization metric
                  being reported for a dynamic CP when set and indicates that
                  the metric is not the optimization metric when clear. This
                  bit MUST NOT be set in more than one instance of this TLV
                  for a given CP advertisement.</t>

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

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

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

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

              <t>Metric Margin: 4-octet value which indicates the metric
              margin when the M-flag is set. The metric margin is specified as
              either an absolute value or as a percentage of the minimum
              computed path metric based on the A-flag. The metric margin
              loosens the criteria for minimum metric path calculation up to
              the specified metric to accommodate for other factors such as
              bandwidth availability, minimal SID stack depth, and maximizing
              of ECMP for the SR path computed.</t>

              <t>Metric Bound: 4-octet value which indicates the maximum
              metric that is allowed when the B-flag is set. If the computed
              path metric crosses the specified bound value then the path is
              considered invalid.</t>
            </list></t>
        </section>
      </section>

      <section anchor="SEGMENTLIST" title="SR Segment List TLV">
        <t>The SR Segment List TLV is used to report a single SID-List of a
        CP. Multiple instances of this TLV may be used to report multiple
        SID-Lists of a CP.</t>

        <t>The TLV has the following format: <figure align="center">
            <artwork align="left"><![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)                                        //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t>Length: variable</t>

            <t>Flags: 2-octet field that indicates attribute and status of the
            SID-List.The following bit positions are defined and the semantics
            are described in detail in <xref target="RFC9256"/>. Other bits
            MUST be cleared by the originator and MUST be ignored by a
            receiver.<figure>
                <artwork><![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 the SID-List is comprised of SRv6 SIDs
                when set and indicates it is comprised of SR/MPLS labels when
                clear.</t>

                <t>E-Flag: Indicates that 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 be either explicit or dynamic and in case of
                inconsistency, the receiver MAY consider them all to be
                dynamic.</t>

                <t>C-Flag: Indicates that 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 the SID-List has passed verification or
                its verification was not required when set and failed
                verification when clear.</t>

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

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

                <t>A-Flag: 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 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 that the SID-list has been removed from
                the forwarding plane due to fault detection by a monitoring
                mechanism (e.g. BFD) when set and indicates no fault detected
                or monitoring is not being done when clear.</t>
              </list></t>

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

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

            <t>Algorithm: 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 Algorithm Types registry under the IANA Interior
            Gateway Protocol (IGP) Parameters.</t>

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

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

            <t>Sub-TLVs: variable and contains the ordered set of Segments and
            any other optional attributes associated with the specific
            SID-List.</t>
          </list></t>

        <t>The SR Segment sub-TLV (defined in <xref target="SEGMENTTLV"/>)
        MUST 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. 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 SHOULD NOT include any SR Segment sub-TLVs.</t>
      </section>

      <section anchor="SEGMENTTLV" title="SR Segment Sub-TLV">
        <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">
            <artwork align="left"><![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)                                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t>Length: variable</t>

            <t>Segment Type: 1 octet which indicates the type of segment.
            Initial values are specified by this document (see <xref
            target="SEGMENTDESC"/> for details). Additional segment types are
            possible, but out of scope for this document.</t>

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

            <t>Flags: 2-octet field that indicates attribute and status of the
            Segment and its SID. The following bit positions are defined and
            the semantics are described in section 5 of <xref
            target="RFC9256"/>. Other bits MUST be cleared by the originator
            and MUST be ignored by a receiver.<figure>
                <artwork><![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 the presence of SID value in the SID
                field when set and that no value is indicated when clear.</t>

                <t>E-Flag: Indicates the SID value is 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 the SID has passed verification or did
                not require verification when set. When V-Flage is clear, it
                indicates the SID has failed verification.</t>

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

                <t>A-Flag: 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 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 be set to 0 by the originator and MUST
            be ignored by a receiver.<figure>
                <artwork><![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 size Segment descriptor based on
            the type of segment (refer to <xref target="SEGMENTDESC"/> for
            details)</t>

            <t>Sub-Sub-TLVs: variable and contains any other optional
            attributes associated with the specific segment.</t>
          </list></t>

        <t>The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure
        TLV (1252) defined in <xref target="RFC9514"/> 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 segment types.</t>

        <section anchor="SEGMENTDESC" title="Segment Descriptors">
          <t>Section 4 of <xref target="RFC9256"/> defines multiple types of
          segments and their description. This section defines the encoding of
          the Segment Descriptors for each of those Segment types to be used
          in the Segment sub-TLV describes previously in <xref
          target="SEGMENTTLV"/>.</t>

          <t>The following types are currently defined and their mapping to
          the respective segment types defined in <xref target="RFC9256"/>:
          <figure align="center">
              <artwork align="left"><![CDATA[+------+-------------------------------------------------------------+
| Type |   Segment Description                                       |
+------+-------------------------------------------------------------+
|   1  | (Type A) SR-MPLS Label                                      |
|   2  | (Type B) SRv6 SID as IPv6 address                           |
|   3  | (Type C) SR-MPLS Prefix SID as IPv4 Node Address            |
|   4  | (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address     |
|   5  | (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local |
|      | Interface ID                                                |
|   6  | (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote       |
|      | Interface Addresses                                         |
|   7  | (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global       |
|      | Address & Interface ID for Local & Remote nodes             |
|   8  | (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global       |
|      | Addresses for the Local & Remote Interface                  |
|   9  | (Type I) SRv6 END SID as IPv6 Node Global Address           |
|  10  | (Type J) SRv6 END.X SID as pair of IPv6 Global Address &    |
|      | Interface ID for Local & Remote nodes                       |
|  11  | (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses    |
|      | for the Local & Remote Interface                            |
+------+-------------------------------------------------------------+

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

          <section anchor="TYPE1" title="Type 1: SR-MPLS Label">
            <t>The Segment is SR-MPLS type and is specified simply as the
            label. The format of its Segment Descriptor is as follows:<figure
                align="center">
                <artwork align="left"><![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   |
+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>Algorithm: 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
                Algorithm Types registry under the IANA Interior Gateway
                Protocol (IGP) Parameters.</t>
              </list></t>
          </section>

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

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

            <t><list style="symbols">
                <t>Algorithm: 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
                Algorithm Types registry under the IANA Interior Gateway
                Protocol (IGP) Parameters.</t>
              </list></t>
          </section>

          <section anchor="TYPE3" title="Type 3: SR-MPLS Prefix SID for IPv4">
            <t>The Segment is 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">
                <artwork align="left"><![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)                  |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>Algorithm: 1-octet value that indicates the algorithm used
                for picking the SID. The algorithm values are from IGP
                Algorithm Types registry under the IANA Interior Gateway
                Protocol (IGP) Parameters.</t>

                <t>IPv4 Node Address: 4-octet value which carries the IPv4
                address associated with the node</t>
              </list></t>
          </section>

          <section anchor="TYPE4" title="Type 4: SR-MPLS Prefix SID for IPv6">
            <t>The Segment is SR-MPLS Prefix SID type and is specified as an
            IPv6 global address. The format of its Segment Descriptor is as
            follows:<figure align="center">
                <artwork align="left"><![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)                 |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>Algorithm: 1-octet value that indicates the algorithm used
                for picking the SID. The algorithm values are from IGP
                Algorithm Types registry under the IANA Interior Gateway
                Protocol (IGP) Parameters.</t>

                <t>IPv6 Node Global Address: 16-octet value which carries the
                IPv6 global address associated with the node</t>
              </list></t>
          </section>

          <section anchor="TYPE5"
                   title="Type 5: SR-MPLS Adjacency SID for IPv4 with an Interface ID">
            <t>The Segment is 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">
                <artwork align="left"><![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)                  |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>IPv4 Node Address: 4-octet value which carries the IPv4
                address associated with the node</t>

                <t>Local Interface ID: 4-octet value which carries the local
                interface ID of the node identified by the Node Address</t>
              </list></t>
          </section>

          <section anchor="TYPE6"
                   title="Type 6: SR-MPLS Adjacency SID for IPv4 with an Interface Address">
            <t>The Segment is SR-MPLS Adjacency SID type and is specified as a
            pair of IPv4 local and remote addresses. The format of its Segment
            Descriptor is as follows:<figure align="center">
                <artwork align="left"><![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)                  |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>IPv4 Local Address: 4-octet value which carries the local
                IPv4 address associated with the node</t>

                <t>IPv4 Remote Address: 4-octet value which carries the remote
                IPv4 address associated with the node's neighbor. This is
                optional and MAY be set to 0 when not used (e.g. when
                identifying point-to-point links).</t>
              </list></t>
          </section>

          <section anchor="TYPE7"
                   title="Type 7: SR-MPLS Adjacency SID for IPv6 with an interface ID">
            <t>The Segment is 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">
                <artwork align="left"><![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)                  |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>IPv6 Local Node Global Address: 16-octet value which
                carries the IPv6 global address associated with the local
                node</t>

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

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

                <t>Remote Node Interface ID: 4-octet value which carries the
                interface ID of the remote node identified by the Remote Node
                Address. This is optional and MAY be set to 0 when not used
                (e.g. when identifying point-to-point links).</t>
              </list></t>
          </section>

          <section anchor="TYPE8"
                   title="Type 8: SR-MPLS Adjacency SID for IPv6 with an Interface Address">
            <t>The Segment is SR-MPLS Adjacency SID type and is specified as a
            pair of IPv6 Global addresses for local and remote interface
            addresses. The format of its Segment Descriptor is as
            follows:<figure align="center">
                <artwork align="left"><![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)       |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>IPv6 Local Address: 16-octet value which carries the local
                IPv6 address associated with the node</t>

                <t>IPv6 Remote Address: 16-octet value which carries the
                remote IPv6 address associated with the node's neighbor</t>
              </list></t>
          </section>

          <section anchor="TYPE9"
                   title="Type 9: SRv6 END SID as IPv6 Node Address">
            <t>The Segment is SRv6 END SID type and is specified as an IPv6
            global address. The format of its Segment Descriptor is as
            follows:<figure align="center">
                <artwork align="left"><![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)                 |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>Algorithm: 1-octet value that indicates the algorithm used
                for picking the SID. The algorithm values are from IGP
                Algorithm Types registry under the IANA Interior Gateway
                Protocol (IGP) Parameters.</t>

                <t>IPv6 Node Global Address: 16-octet value which carries the
                IPv6 global address associated with the node</t>
              </list></t>
          </section>

          <section anchor="TYPE10"
                   title="Type 10: SRv6 END.X SID as an Anterface ID">
            <t>The Segment is 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">
                <artwork align="left"><![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)                  |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>IPv6 Local Node Global Address: 16-octet value which
                carries the IPv6 global address associated with the local
                node</t>

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

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

                <t>Remote Node Interface ID: 4-octet value which carries the
                interface ID of the remote node identified by the Remote Node
                Address. This is optional and MAY be set to 0 when not used
                (e.g. when identifying point-to-point links).</t>
              </list></t>
          </section>

          <section anchor="TYPE11"
                   title="Type 11: SRv6 END.X SID as an Interface Address">
            <t>The Segment is SRv6 END.X SID type and is specified as a pair
            of IPv6 Global addresses for local and remote interface addresses.
            The format of its Segment Descriptor is as follows:<figure
                align="center">
                <artwork align="left"><![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)       |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t><list style="symbols">
                <t>IPv6 Local Address: 16-octet value which carries the local
                IPv6 address associated with the node</t>

                <t>IPv6 Remote Address: 16-octet value which carries the
                remote IPv6 address associated with the node's neighbor</t>
              </list></t>
          </section>
        </section>
      </section>

      <section anchor="SLMETRIC" title="SR Segment List Metric Sub-TLV">
        <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 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"/>) at the SR CP level.</t>

        <t>It is a sub-TLV of the SR Segment List TLV and has the following
        format: <figure align="center">
            <artwork align="left"><![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                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t>Length: 16 octets</t>

            <t>Metric Type: 1-octet field which identifies the type of metric.
            The metric type code points are listed in <xref
            target="METRICTYPE"/> of this document. 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.</t>

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

where:]]></artwork>
              </figure><list style="symbols">
                <t>M-Flag: Indicates that the metric margin allowed for this
                path computation is specified when set and indicates that
                metric margin allowed is not specified when clear.</t>

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

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

                <t>V-Flag: Indicates that the 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 octets. MUST be set to 0 by the originator and MUST
            be ignored by a receiver.</t>

            <t>Metric Margin: 4-octet value which indicates the metric margin
            value when the M-flag is set. The metric margin is specified as
            either an absolute value or as a percentage of the minimum
            computed path metric based on the A-flag. The metric margin
            loosens the criteria for minimum metric path calculation up to the
            specified metric to accomodate for other factors such as bandwidth
            availability, minimal SID stack depth, and maximizing of ECMP for
            the SR path computed.</t>

            <t>Metric Bound: 4-octet value which indicates the maximum metric
            value that is allowed when the B-flag is set. If the computed path
            metric crosses the specified bound value then the path is
            considered invalid.</t>

            <t>Metric Value: 4-octet value which 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>
      </section>

      <section anchor="SLBW" title="SR Segment List Bandwidth Sub-TLV">
        <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 one is considered valid 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">
            <artwork align="left"><![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                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

            <t>Length: 4 octets</t>

            <t>Bandwidth: 4 octets which specify the allocated bandwidth in
            unit of bytes per second in IEEE floating point format.</t>
          </list></t>
      </section>

      <section anchor="SLID" title="SR Segment List Identifier Sub-TLV">
        <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 one is
        considered valid 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">
            <artwork align="left"><![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                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

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

            <t>Length: 4 octets</t>

            <t>Segment List Identifier: 4 octets which carry a 32-bit unsigned
            non-zero number 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>
      </section>
    </section>

    <section anchor="Procedures" title="Procedures">
      <t>The BGP-LS advertisements for the SR Policy CP 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"/> is used. An SR Policy
      candidate path (CP) may be instantiated on the headend node via a local
      configuration, PCEP, or BGP SR Policy signaling and this is indicated
      via the SR Protocol Origin. When a PCE node is the BGP-LS Producer, it
      uses the "reported via PCE" variants of the SR Protocol Origin 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"/>. The SR Candidate Path State TLV as
      defined in <xref target="CPSTATE"/> is included to report the state of
      the CP. The SR BSID TLV as defined in <xref target="CPBSID"/> or <xref
      target="CPBSIDSRV6"/> is included to report the BSID of the CP 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"/>. The SR Segment List TLV is included for
      each of the SID-List(s) associated with the CP. Each SR Segment List TLV
      in turn includes SR Segment sub-TLV(s) to report the segment(s) and
      their 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">
      <t>The 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"/> apply to this
      document.</t>

      <t>In general, the SR Policy head-end nodes are responsible for the
      advertisement of SR Policy state information.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This section describes the code point allocation by IANA for this
      document.</t>

      <section anchor="NLRITYPES" title="BGP-LS NLRI-Types">
        <t>IANA maintains a registry called "BGP-LS NLRI-Types" in the "Border
        Gateway Protocol - Link State (BGP-LS) Parameters" registry group.</t>

        <t>The following table lists the status of code points that have been
        allocated by IANA:</t>

        <t><figure>
            <artwork><![CDATA[ +------+-------------------------------+---------------+
 | Type | NLRI Type                     |   Reference   |
 +------+-------------------------------+---------------+
 |  5   | SR Policy Candidate Path NLRI | this document |
 +------+-------------------------------+---------------+
]]></artwork>
          </figure></t>
      </section>

      <section anchor="PROTOCOLIDS" title="BGP-LS Protocol-IDs">
        <t>IANA maintains a registry called "BGP-LS Protocol-IDs" in the
        "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry
        group.</t>

        <t>The following Protocol-ID codepoints have been allocated by
        IANA:</t>

        <t><figure>
            <artwork><![CDATA[ +-------------+----------------------------------+---------------+
 | Protocol-ID | NLRI information source protocol |   Reference   |
 +-------------+----------------------------------+---------------+
 |     9       |       Segment Routing            | this document |
 +-------------+----------------------------------+---------------+
]]></artwork>
          </figure></t>
      </section>

      <section anchor="BGPLSTLVS" title="BGP-LS TLVs">
        <t>IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs"
        in the "Border Gateway Protocol - Link State (BGP-LS) Parameters"
        registry group.</t>

        <t>The following table lists the status of TLV code points that have
        been allocated by IANA and others that are pending allocation:</t>

        <t><figure>
            <artwork><![CDATA[+-------+----------------------------------------+---------------+
| Code  |             Description                | Value defined |
| Point |                                        |       in      |
+-------+----------------------------------------+---------------+
|   554 |   SR Policy CP Descriptor              | this document |
|  1201 |   SR Binding SID                       | this document |
|  1202 |   SR CP State                          | this document |
|  1203 |   SR CP Name                           | this document |
|  1204 |   SR CP Constraints                    | this document |
|  1205 |   SR Segment List                      | this document |
|  1206 |   SR Segment                           | this document |
|  1207 |   SR Segment List Metric               | this document |
|  1208 |   SR Affinity Constraint               | this document |
|  1209 |   SR SRLG Constraint                   | this document |
|  1210 |   SR Bandwidth Constraint              | this document |
|  1211 |   SR Disjoint Group Constraint         | this document |
|  1212 |   SRv6 Binding SID                     | this document |
|  1213 |   SR Policy Name                       | this document |
|  1214 |   SR Bidirectional Group Constraint    | this document |
|  1215 |   SR Metric Constraint                 | this document |
|  1216 |   SR Segment List Bandwidth            | this document |
|  1217 |   SR Segment List Identifier           | this document |
+-------+----------------------------------------+---------------+]]></artwork>
          </figure></t>
      </section>

      <section anchor="PROTOCOLORIGINS" title="SR Policy Protocol Origin">
        <t>Note to IANA (RFC editor to remove this before publication): The
        new registry creation request below is also present in the
        draft-ietf-pce-segment-routing-policy-cp. IANA is requested to process
        the registry creation via the first of these two documents to reach
        publication stage and the authors of the other document would update
        the IANA considerations suitably. The initial allocations in this
        document are a super-set of the initial allocations in
        draft-ietf-pce-segment-routing-policy-cp.</t>

        <t>This document requests IANA to maintain a new registry under
        "Segment Routing" registry group with the allocation policy of "Expert
        Review" <xref target="RFC8126"/> using the guidelines for Designated
        Experts as specified in <xref target="RFC9256"/>. The new registry is
        called "SR Policy Protocol Origin" and should have the reference to
        this document and <xref
        target="I-D.ietf-pce-segment-routing-policy-cp"/>. This registry
        contains the codepoints allocated to the "Protocol Origin" field
        defined in <xref target="SRPOLICYCP"/>.</t>

        <t>The registry contains the following codepoints, with initial
        values, to be assigned by IANA with the reference set to this
        document:<figure>
            <artwork><![CDATA[+---------+--------------------------------------+---------------+
|  Code   |                                      |               |
|  Point  |  Protocol Origin                     |   Reference   |
+---------+--------------------------------------+---------------+
|   0     | Reserved (not to be used)            | this document |
|   1     | PCEP                                 | this document |
|   2     | BGP SR Policy                        | this document |
|   3     | Configuration (CLI, YANG model via   | this document |
|         | NETCONF, etc.)                       | this document |
|   4-9   | Unassigned                           | this document |
|   10    | PCEP reported via PCE/PCEP           | this document |
|  11-19  | Unassigned                           | this document |
|   20    | BGP SR Policy reported via PCE/PCEP  | this document |
|  21-29  | Unassigned                           | this document |
|   30    | Configuration (CLI, YANG model via   | this document |
|         | NETCONF, etc.) reported via PCE/PCEP | this document |
|  31-250 | Unassigned                           | this document |
| 251-255 | Private Use (not to be assigned by   | this document |
|         | IANA                                 | this document |
+---------+--------------------------------------+---------------+]]></artwork>
          </figure></t>
      </section>

      <section anchor="SEGDESC" title="BGP-LS SR Segment Descriptors">
        <t>This document requests IANA to maintain a new registry under
        "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry
        group with the allocation policy of "Expert Review" <xref
        target="RFC8126"/> using the guidelines for Designated Experts as
        specified in <xref target="RFC9552"/>. The new registry is called "SR
        Segment Descriptor Types" and contains the codepoints allocated to the
        "Segment Type" field defined in <xref target="SEGMENTTLV"/> and
        described in <xref target="SEGMENTDESC"/>. The registry contains the
        following codepoints, with initial values, to be assigned by IANA with
        the reference set to this document:<figure>
            <artwork><![CDATA[+--------+-----------------------------------------------------------+
|  Code  |   Segment Description                                     |
|  Point |                                                           |
+--------+-----------------------------------------------------------+
|    0   | Reserved (not to be used)                                 |
|    1   | (Type A) SR-MPLS Label                                    |
|    2   | (Type B) SRv6 SID as IPv6 address                         |
|    3   | (Type C) SR-MPLS Prefix SID as IPv4 Node Address          |
|    4   | (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address   |
|    5   | (Type E) SR-MPLS Adjacency SID as IPv4 Node Address &     |
|        | Local Interface ID                                        |
|    6   | (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote     |
|        | Interface Addresses                                       |
|    7   | (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global     |
|        | Address & Interface ID for Local & Remote nodes           |
|    8   | (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global     |
|        | Addresses for the Local & Remote Interface                |
|    9   | (Type I) SRv6 END SID as IPv6 Node Global Address         |
|   10   | (Type J) SRv6 END.X SID as pair of IPv6 Global Address &  |
|        | Interface ID for Local & Remote nodes                     |
|   11   | (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses  |
|        | for the Local & Remote Interface                          |
| 12-255 | Unassigned                                                |
+--------+-----------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section anchor="METRICTYPE" title="BGP-LS SR Policy Metric Type">
        <t>This document requests IANA to maintain a new registry under
        "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry
        group with the allocation policy of "Expert Review" <xref
        target="RFC8126"/> using the guidelines for Designated Experts as
        specified in <xref target="RFC9552"/>. The new registry is called
        "BGP-LS SR Policy Metric Type" and contains the codepoints allocated
        to the "metric type" field defined in <xref target="SLMETRIC"/>. The
        registry contains the following codepoints, with initial values, to be
        assigned by IANA with the reference set to this document:<figure>
            <artwork><![CDATA[+------------+-----------------------------------------------------+
| Code Point |                   Metric Type                       |
+------------+-----------------------------------------------------+
|     0      | IGP Metric                                          |
|     1      | Min Unidirectional Link Delay [RFC7471]             |
|     2      | TE Metric [RFC3630]                                 |
|     3      | Hop Count [RFC5440]                                 |
|     4      | SID List Length                                     |
|     5      | Bandwidth Metric [I-D.ietf-lsr-flex-algo-bw-con]    |
|    6-120   | Unassigned                                          |
|  121-127   | Private Use (not to be assigned by IANA)            |
|  128-255   | User Defined Metric [I-D.ietf-lsr-flex-algo-bw-con] |
+------------+-----------------------------------------------------+

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

    <section anchor="Security" title="Security Considerations">
      <t>Procedures and protocol extensions defined in this document do not
      affect the base BGP security model. See <xref target="RFC6952"/> for
      details. The security considerations of the base BGP-LS specification as
      described in <xref target="RFC9552"/> also apply.</t>

      <t>The BGP-LS SR Policy extensions specified in this document enable
      traffic engineering and service programming use-cases within an SR
      domain as described in <xref target="RFC9256"/>. SR operates within a
      trusted SR domain <xref target="RFC8402"/> 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 security considerations of <xref
      target="RFC9552"/>) may be used to ensure that the SR Policy information
      is not advertised by accident or error to an EBGP peering session
      outside the SR domain.</t>

      <t>Additionally, it may be considered that the export of SR Policy
      information, as described in this document, constitutes a risk to
      confidentiality of mission-critical or commercially sensitive
      information about the network (more 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 to the editing 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>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz
      Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah,
      Dhanendra Jain, Francois Clad, Zafar Ali, Stephane Litkowski, Aravind
      Babu Mahendra Babu, Geetanjalli Bhalla, Ahmed Bashandy, Mike Koldychev,
      Samuel Sidor, Alex Tokar, and Rajesh Melarcode Venkatesswaran for their
      review and valuable comments. The authors would also like to thank Susan
      Hares for her shepherd review of the document and helpful comments to
      improve this document.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

      <?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-ls-te-path'?>

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

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

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

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

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

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

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

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

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

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