rfc9857xml2.original.xml   rfc9857.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-bgp-ls-sr-policy-17"
ipr="trust200902">
<front>
<title abbrev="Advertising SR Policies using BGP-LS">Advertisement of
Segment Routing Policies using BGP Link-State</title>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-idr-bgp-ls-sr-policy-17" number="9857" consensus="true" ipr="trust200902" obs
oletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDe
pth="3" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="Advertising SR Policies Using BGP-LS">Advertisement of
Segment Routing Policies Using BGP - Link State</title>
<seriesInfo name="RFC" value="9857"/>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Individual</organization> <organization>Individual</organization>
<address> <address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Tal
<author fullname="Ketan Talaulikar" initials="K." role="editor" aulikar">
surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jie Dong" initials="J." surname="Dong"> <author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>jie.dong@huawei.com</email> <email>jie.dong@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler"> <author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>RtBrick Inc.</organization> <organization>RtBrick Inc.</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>hannes@rtbrick.com</email> <email>hannes@rtbrick.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Nvidia</organization> <organization>Nvidia</organization>
<address> <address>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2025" month="September"/>
<date year=""/> <area>RTG</area>
<workgroup>idr</workgroup>
<area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<keyword>SR</keyword> <keyword>SR</keyword>
<keyword>SR Policy</keyword> <keyword>SR Policy</keyword>
<keyword>SR-MPLS</keyword> <keyword>SR-MPLS</keyword>
<keyword>SRv6</keyword> <keyword>SRv6</keyword>
<keyword>Traffic Engineering</keyword> <keyword>Traffic Engineering</keyword>
<keyword>BGP SR Policy</keyword> <keyword>BGP SR Policy</keyword>
<abstract> <abstract>
<t>This document describes a mechanism to collect the Segment Routing <t>This document describes a mechanism used to collect Segment Routing (SR )
Policy information that is locally available in a node and advertise it 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 into BGP - Link State (BGP-LS) updates. Such information can be used by
external components for path computation, re-optimization, service external components for path computation, reoptimization, service
placement, network visualization, etc.</t> placement, network visualization, etc.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<t>SR Policy architecture details are specified in <xref <name>Introduction</name>
target="RFC9256"/>. An SR Policy comprises one or more candidate paths <t>SR Policy architecture details are specified in <xref target="RFC9256"
format="default"/>. An SR Policy comprises one or more candidate paths
of which at a given time one and only one may be active (i.e., installed 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 candidate path in forwarding and usable for the steering of traffic). Each candidate path
in turn may have one or more SID-List of which one or more SID-List may in turn may have one or more SID lists of which one or more SID lists may
be active. When multiple SID-Lists are active then traffic is load be active. When multiple SID lists are active, traffic is load
balanced over them. This document covers the advertisement of state balanced over them. This document covers the advertisement of state
information at the individual SR Policy candidate path level.</t> information at the individual SR Policy candidate path level.</t>
<t>SR Policies are generally instantiated at the headend and are based
<t>SR Policies are generally instantiated at the head-end and are based
on either local configuration or controller-based programming of the on either local configuration or controller-based programming of the
node using various APIs and protocols (e.g., PCEP or BGP).</t> node using various APIs and protocols (e.g., the Path Computation Element
Communication Protocol (PCEP) or BGP).</t>
<t>In many network environments, the configuration, and state of each SR <t>In many network environments, the configuration and state of each SR
Policy that is available in the network is required by controllers. Such Policy that is available in the network is required by controllers. Such
controllers, that are aware of both topology and SR Policy state controllers, which are aware of both topology and SR Policy state
information, allow the network operator to optimize several functions information, allow the network operator to optimize several functions
and operations in their networks.</t> and operations in their networks.</t>
<t>One example of a controller is the stateful Path Computation Element <t>One example of a controller is the stateful Path Computation Element
(PCE) <xref target="RFC8231"/>, which could provide benefits in path (PCE) <xref target="RFC8231" format="default"/>, which can provide benefit
optimization. While some extensions are proposed in the Path Computation s in path
Element Communication Protocol (PCEP) for the Path Computation Clients optimization. While some extensions are proposed in the PCEP for Path Comp
(PCCs) to report the LSP states to the PCE, this mechanism may not be utation Clients
(PCCs) to report Label Switched Path (LSP) states to the PCE, this mechani
sm may not be
applicable in a management-based PCE architecture as specified in applicable in a management-based PCE architecture as specified in
section 5.5 of <xref target="RFC4655"/>. As illustrated in the figure <xref target="RFC4655" sectionFormat="of" section="5.5"/>. As illustrated
below, the PCC is not an LSR in the routing domain, thus the head-end in the figure
nodes of the SR Policies may not implement the PCEP protocol. In this below, the PCC is not a Label Switching Router (LSR) in the routing domain
, thus the headend
nodes of the SR Policies may not implement the PCEP. In this
case, a general mechanism to collect the SR Policy states from the case, a general mechanism to collect the SR Policy states from the
ingress LERs is needed. This document proposes an SR Policy state ingress Label Edge Routers (LERs) is needed. This document proposes an SR
collection mechanism complementary to the mechanism defined in <xref Policy state
target="RFC8231"/>.<figure> collection mechanism complementary to the mechanism defined in <xref targe
<artwork><![CDATA[ ----------- t="RFC8231" format="default"/>.</t>
<figure>
<name>Management-Based PCE Usage</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
-----------
| ----- | | ----- |
Service | | TED |<-+-----------> Service | | TED |<-+----------->
Request | ----- | TED synchronization Request | ----- | TED synchronization
| | | | mechanism (e.g., | | | | mechanism (e.g., the
v | | | routing protocol) v | | | routing protocol)
------------- Request/ | v | ------------- Request/ | v |
| | Response| ----- | | | Response| ----- |
| NMS |<--------+> | PCE | | | NMS |<--------+> | PCE | |
| | | ----- | | | | ----- |
------------- ----------- ------------- -----------
Service | Service |
Request | Request |
v v
---------- Signaling ---------- ---------- Signaling ----------
| Head-End | Protocol | Adjacent | | Headend | Protocol | Adjacent |
| Node |<---------->| Node | | Node |<---------->| Node |
---------- ---------- ---------- ----------]]></artwork>
</figure>
Figure 1 Management-Based PCE Usage <t>In networks with composite PCE nodes as specified in
]]></artwork> <xref target="RFC4655" sectionFormat="of" section="5.1"/>, PCE is implemen
</figure></t> ted on several routers in the
<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 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 <xref target="RFC8231" format="default"/> to report the SR Policy informat ion to the PCE
nodes. An external component may also need to collect the SR Policy 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 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> 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 <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 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 needs to collect SR Policy information from multiple child PCEs to
obtain a global view of SR Policy paths inside and across the domains obtain a global view of SR Policy paths inside and across the domains
involved.</t> involved.</t>
<t>In another network scenario, a centralized controller is used for <t>In another network scenario, a centralized controller is used for
service placement. Obtaining the SR Policy state information is quite service placement. Obtaining the SR Policy state information is quite
important for making appropriate service placement decisions with the important for making appropriate service placement decisions with the
purpose of both meeting the application's requirements and utilizing purpose of both meeting the application's requirements and utilizing
network resources efficiently.</t> network resources efficiently.</t>
<t>The Network Management System (NMS) may need to provide global <t>The Network Management System (NMS) may need to provide global
visibility of the SR Policies in the network as part of the network visibility of the SR Policies in the network as part of the network
visualization function.</t> visualization function.</t>
<t>BGP has been extended to distribute link-state and Traffic
<t>BGP has been extended to distribute link-state and traffic Engineering (TE) information to external components <xref target="RFC9552"
engineering information to external components <xref target="RFC9552"/>. format="default"/>.
Using the same protocol to collect SR Policy and state information is Using the same protocol to collect SR Policy and state information is
desirable for these external components since this avoids introducing desirable for these external components since this avoids introducing
multiple protocols for network topology information collection. This multiple protocols for network topology information collection. This
document describes a mechanism to distribute SR Policy information (both document describes a mechanism to distribute SR Policy information (both
SR-MPLS, and SRv6 <xref target="RFC8402"/>) to external components using SR-MPLS and SRv6 <xref target="RFC8402" format="default"/>) to external co mponents using
BGP-LS and covers both explicit and dynamic candidate paths. The BGP-LS and covers both explicit and dynamic candidate paths. The
advertisements of composite candidate path is outside the scope of this advertisements of a composite candidate path are outside the scope of this
document.</t> document.</t>
<t>The BGP-LS Producer <xref target="RFC9552" format="default"/> that is o
<t>The BGP-LS Producer <xref target="RFC9552"/> that is originating the riginating the
advertisement of SR Policy information can be either:<list advertisement of SR Policy information can be either:</t>
style="symbols"> <ul spacing="normal">
<t>a SR Policy headend node, or</t> <li>
<t>an SR Policy headend node or</t>
<t>a PCE which is receiving the SR Policy information from its PCCs </li>
<li>
<t>a PCE that is receiving the SR Policy information from its PCCs
(i.e., SR Policy headend nodes) via PCEP</t> (i.e., SR Policy headend nodes) via PCEP</t>
</list></t> </li>
</ul>
<t>The extensions specified in this document complement the BGP SR <t>The extensions specified in this document complement the BGP SR
Policy SAFI <xref target="I-D.ietf-idr-sr-policy-safi"/> and <xref Policy SAFI <xref target="RFC9830" format="default"/> <xref target="RFC983
target="I-D.ietf-idr-bgp-sr-segtypes-ext"/> that are used to advertise 1" format="default"/> and are used to advertise
SR Policies from controllers to the headend routers using BGP by SR Policies from controllers to the headend routers using BGP by
enabling the reporting of the operational state of those SR Policies enabling the reporting of the operational state of those SR Policies
back from the headend to the controllers.</t> back from the headend to the controllers.</t>
<t>While this document focuses on SR Policies, <xref target="I-D.ietf-idr-
<t>While this document focuses on SR Policies, <xref bgp-ls-te-path" format="default"/> introduces further extensions to
target="I-D.ietf-idr-bgp-ls-te-path"/> introduces further extension to support other TE paths such as MPLS-TE LSPs.</t>
support other TE Paths such as MPLS-TE LSPs.</t> <t>The encodings specified in this document (specifically in Sections <xre
f target="SRPOLICYCP" format="counter"/> and <xref target="SRPOLICYTLVS" format=
<t>The encodings specified in this document (specifically in <xref "counter"/>) make use of
target="SRPOLICYCP"/> and <xref target="SRPOLICYTLVS"/>) make use of
flags that convey various types of information of the SR Policy. The flags that convey various types of information of the SR Policy. The
document uses the term "set" to indicate that the value of a flag bit is document uses the term "set" to indicate that the value of a flag bit is
1 and the term "clear" when the value is 0.</t> 1 and the term "clear" when the value is 0.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</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> </section>
<section anchor="TEINFOINBGP" numbered="true" toc="default">
<section anchor="TEINFOINBGP" <name>Carrying SR Policy Information in BGP</name>
title="Carrying SR Policy Information in BGP"> <t>The "Link-State Network Layer Reachability Information (NLRI)" defined
<t>The "Link-State NLRI" defined in <xref target="RFC9552"/> is extended in <xref target="RFC9552" format="default"/> is extended
to carry the SR Policy information. New TLVs carried in the BGP to carry the SR Policy information. New TLVs carried in the BGP-LS
Link-State Attribute defined in <xref target="RFC9552"/> are also Attribute defined in <xref target="RFC9552" format="default"/> are also
defined to carry the attributes of an SR Policy in the subsequent defined to carry the attributes of an SR Policy in the subsequent
sections.</t> sections.</t>
<t>The format of the Link-State NLRI is defined in <xref target="RFC9552"
<t>The format of "Link-State NLRI" is defined in <xref format="default"/> as follows:</t>
target="RFC9552"/> as follows:<figure> <figure>
<artwork align="center"><![CDATA[ 0 1 <name>BGP-LS NLRI Format</name>
2 3 <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Link-State NLRI (variable) // // Link-State NLRI (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 2 BGP-LS NLRI Format <t>An additional NLRI Type known as "SR Policy Candidate Path NLRI"
]]></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> (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 <t>This SR Policy Candidate Path NLRI is used to report the state
details of individual SR Policy Candidate paths along with their details of individual SR Policy candidate paths along with their
underlying segment lists.</t> underlying segment lists.</t>
</section> </section>
<section anchor="TEPOLICYNLRI" numbered="true" toc="default">
<section anchor="TEPOLICYNLRI" title="SR Policy Candidate Path NLRI Type"> <name>SR Policy Candidate Path NLRI Type</name>
<t>This document defines SR Policy Candidate Path NLRI Type with its <t>This document defines the SR Policy Candidate Path NLRI type with its
format as shown in the following figure:</t> format as shown in the following figure:</t>
<figure>
<t><figure> <name>SR Policy Candidate Path NLRI Format</name>
<artwork align="center"><![CDATA[ 0 1 <artwork align="center" name="" type="" alt=""><![CDATA[
2 3 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 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 | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
| (64 bits) | | (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptor TLV (for the Headend) // // Local Node Descriptors TLV (for the Headend) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SR Policy Candidate Path Descriptor TLV // // SR Policy Candidate Path Descriptor TLV //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 3 SR Policy Candidate Path NLRI Format <t>Where:</t>
Where: <dl spacing="normal">
]]></artwork> <dt>Protocol-ID field:</dt><dd> Specifies the component that owns the
</figure><list style="symbols"> SR Policy
<t>Protocol-ID field specifies the component that owns the SR Policy
state in the advertising node. An additional Protocol-ID "Segment state in the advertising node. An additional Protocol-ID "Segment
Routing" (value 9) is introduced by this document that MUST be used Routing" (value 9) is introduced by this document that <bcp14>MUST</bc
for advertisement of SR Policies.</t> p14> be used
for the advertisement of SR Policies.</dd>
<t>"Identifier" is an 8 octet value as defined in section 5.2 of <dt>Identifier:</dt><dd>An 8-octet value as defined in
<xref target="RFC9552"/>.</t> <xref target="RFC9552" sectionFormat="of" section="5.2"/>.</dd>
<dt>Local Node Descriptors (TLV 256):</dt><dd>Defined in <xref target=
<t>"Local Node Descriptor" (TLV 256) <xref target="RFC9552"/> is "RFC9552" format="default"/> and
used as specified further in this section.</t> used as specified further in this section.</dd>
<dt>SR Policy Candidate Path Descriptor TLV:</dt><dd>Specified in <xre
<t>The SR Policy Candidate Path Descriptor TLV is specified in <xref f target="SRPOLICYCP" format="default"/>.</dd>
target="SRPOLICYCP"/>.</t> </dl>
</list></t> <t>The Local Node Descriptors TLV carries information that only
<t>The Local Node Descriptor TLV carries information that only
identifies the headend node of the SR Policy irrespective of whether the identifies the headend node of the SR Policy irrespective of whether the
BGP-LS Producer is a headend or a PCE node.</t> BGP-LS Producer is a headend or a PCE node.</t>
<t>The Local Node Descriptors TLV <bcp14>MUST</bcp14> include at least one
<t>The Local Node Descriptor TLV MUST include at least one of the of the
following Node Descriptor TLVs:<list style="symbols"> following Node Descriptor TLVs:</t>
<t>IPv4 Router-ID of Local Node (TLV 1028) <xref target="RFC9552"/>, <ul spacing="normal">
<li>
<t>IPv4 Router-ID of Local Node (TLV 1028) <xref target="RFC9552" form
at="default"/>,
which identifies the headend node of the SR Policy as specified in which identifies the headend node of the SR Policy as specified in
section 2.1 of <xref target="RFC9256"/>.</t> <xref target="RFC9256" sectionFormat="of" section="2.1"/>.</t>
</li>
<t>IPv6 Router-ID of Local Node (TLV 1029) <xref target="RFC9552"/>, <li>
<t>IPv6 Router-ID of Local Node (TLV 1029) <xref target="RFC9552" form
at="default"/>,
which identifies the headend node of the SR Policy as specified in which identifies the headend node of the SR Policy as specified in
section 2.1 of <xref target="RFC9256"/>.</t> <xref target="RFC9256" sectionFormat="of" section="2.1"/>.</t>
</list></t> </li>
</ul>
<t>The following sub-sections describe the encoding of sub-TLVs within <t>The following subsections describe the encoding of sub-TLVs within
the Local Node Descriptor TLV depending on which node is the BGP-LS the Local Node Descriptors TLV depending on which node is the BGP-LS
Producer.</t> Producer.</t>
<section numbered="true" toc="default">
<section title="SR Policy Headend as BGP-LS Producer"> <name>SR Policy Headend as the BGP-LS Producer</name>
<t>The Local Node Descriptor TLV MUST include the following Node <t>The Local Node Descriptors TLV <bcp14>MUST</bcp14> include the follow
Descriptor TLVs when the headend node is the BGP-LS Producer:<list ing Node
style="symbols"> Descriptor TLVs when the headend node is the BGP-LS Producer:</t>
<t>BGP Router-ID (TLV 516) <xref target="RFC9086"/>, which <ul spacing="normal">
<li>
<t>BGP Router-ID (TLV 516) <xref target="RFC9086" format="default"/>
, which
contains a valid BGP Identifier of the headend node of the SR contains a valid BGP Identifier of the headend node of the SR
Policy.</t> Policy.</t>
</li>
<t>Autonomous System Number (TLV 512) <xref target="RFC9552"/>, <li>
which contains the ASN (or AS Confederation Identifier (ASN) <xref <t>Autonomous System (TLV 512) <xref target="RFC9552" format="defaul
target="RFC5065"/>, if confederations are used) of the headend t"/>,
which contains the Autonomous System Number (ASN) (or AS Confederati
on Identifier <xref target="RFC5065" format="default"/>, if confederations are u
sed) of the headend
node of the SR Policy.</t> node of the SR Policy.</t>
</list></t> </li>
</ul>
<t>The Local Node Descriptor TLV MAY include the following Node <t>The Local Node Descriptors TLV <bcp14>MAY</bcp14> include the followi
Descriptor TLVs when the headend node is the BGP-LS Producer:<list ng Node
style="symbols"> Descriptor TLVs when the headend node is the BGP-LS Producer:</t>
<t>BGP Confederation Member (TLV 517) <xref target="RFC9086"/>, <ul spacing="normal">
which contains the ASN of the confederation member (i.e. Member-AS <li>
Number), if BGP confederations are used, the headend node of the <t>BGP Confederation Member (TLV 517) <xref target="RFC9086" format=
"default"/>,
which contains the ASN of the confederation member (i.e., Member-AS
Number); if BGP confederations are used, it contains the headend nod
e of the
SR Policy.</t> SR Policy.</t>
</li>
<t>Other Node Descriptors as defined in <xref target="RFC9552"/> <li>
<t>Other Node Descriptors as defined in <xref target="RFC9552" forma
t="default"/>
to identify the headend node of the SR Policy. The determination 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 of whether the IGP Router-ID (TLV 515) contains a 4-octet
OSPF Router-ID or a 6-octet ISO System-ID is to be done based on OSPF Router-ID or a 6-octet ISO System-ID is to be done based on
the length of that sub-TLV since the Protocol-ID in the NLRI is the length of that sub-TLV as the Protocol-ID in the NLRI is
always going to be "Segment Routing".</t> always going to be "Segment Routing".</t>
</list></t> </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="PCE as BGP-LS Producer"> <name>PCE as the BGP-LS Producer</name>
<t>The PCE node MUST NOT include its identifiers in the Node <t>The PCE node <bcp14>MUST NOT</bcp14> include its identifiers in the N
Descriptor TLV in the NLRI as the Node Descriptor TLV MUST only carry ode
Descriptor TLV in the NLRI as the Node Descriptor TLV <bcp14>MUST</bcp14
> only carry
the identifiers of the SR Policy headend.</t> the identifiers of the SR Policy headend.</t>
<t>The Local Node Descriptors TLV <bcp14>MAY</bcp14> include the followi
<t>The Local Node Descriptor TLV MAY include the following Node ng Node
Descriptor TLVs when the PCE node is the BGP-LS Producer and it has Descriptor TLVs when the PCE node is the BGP-LS Producer and it has
this information about the headend (e.g., as part of its topology this information about the headend (e.g., as part of its topology
database):<list style="symbols"> database):</t>
<t>BGP Router-ID (TLV 516) <xref target="RFC9086"/>, which <ul spacing="normal">
<li>
<t>BGP Router-ID (TLV 516) <xref target="RFC9086" format="default"/>
, which
contains a valid BGP Identifier of the headend node of the SR contains a valid BGP Identifier of the headend node of the SR
Policy.</t> Policy.</t>
</li>
<t>Autonomous System Number (TLV 512) <xref target="RFC9552"/>, <li>
which contains the ASN (or AS Confederation Identifier (ASN) <xref <t>Autonomous System (TLV 512) <xref target="RFC9552" format="defaul
target="RFC5065"/>, if confederations are used) of the headend t"/>,
which contains the ASN (or AS Confederation Identifier <xref target=
"RFC5065" format="default"/>, if confederations are used) of the headend
node of the SR Policy.</t> node of the SR Policy.</t>
</li>
<t>BGP Confederation Member (TLV 517) <xref target="RFC9086"/>, <li>
which contains the ASN of the confederation member (i.e. Member-AS <t>BGP Confederation Member (TLV 517) <xref target="RFC9086" format=
Number), if BGP confederations are used, the headend node of the "default"/>,
which contains the ASN of the confederation member (i.e., Member-AS
Number); if BGP confederations are used, it contains the headend nod
e of the
SR Policy.</t> SR Policy.</t>
</li>
<t>Other Node Descriptors as defined in <xref target="RFC9552"/> <li>
to identify the headend node of the SR Policy. The determination <t>Other Node Descriptors as defined in <xref target="RFC9552" forma
of whether the IGP Router-ID sub-TLV (TLV 515) contains a 4-octet t="default"/>
to identify the headend node of the SR Policy.
The determination
of whether the IGP Router-ID (TLV 515) contains a 4-octet
OSPF Router-ID or a 6-octet ISO System-ID is to be done based on OSPF Router-ID or a 6-octet ISO System-ID is to be done based on
the length of that sub-TLV since the Protocol-ID in the NLRI is the length of that sub-TLV since the Protocol-ID in the NLRI is
always going to be "Segment Routing".</t> always going to be "Segment Routing".</t>
</list></t> </li>
</ul>
<t>When a Path Computation Element (PCE) node is functioning as the <t>When a PCE node is functioning as the
BGP-LS Producer on behalf of one or more headends, it MAY include its BGP-LS Producer on behalf of one or more headends, it <bcp14>MAY</bcp14>
own BGP Router-ID (TLV 516), Autonomous System Number (TLV 512), or include its
own BGP Router-ID (TLV 516), Autonomous System (TLV 512), or
BGP Confederation Member (TLV 517) in the BGP-LS Attribute.</t> BGP Confederation Member (TLV 517) in the BGP-LS Attribute.</t>
</section> </section>
</section> </section>
<section anchor="SRPOLICYCP" numbered="true" toc="default">
<section anchor="SRPOLICYCP" title="SR Policy Candidate Path Descriptor"> <name>SR Policy Candidate Path Descriptor</name>
<t>The SR Policy Candidate Path Descriptor TLV identifies a Segment <t>The SR Policy Candidate Path Descriptor TLV identifies an SR Policy can
Routing Policy candidate path as defined in <xref target="RFC9256"/>. It didate path as defined in <xref target="RFC9256" format="default"/>. It
is a mandatory TLV for SR Policy Candidate Path NLRI type. The TLV has is a mandatory TLV for the SR Policy Candidate Path NLRI type. The TLV has
the following format: <figure> the following format: </t>
<artwork align="center"><![CDATA[ 0 1 <figure>
2 3 <name>SR Policy Candidate Path Descriptor Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol-origin| Flags | RESERVED | |Protocol-Origin| Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint (4 or 16 octets) // | Endpoint (4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Color (4 octets) | | Policy Color (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator AS Number (4 octets) | | Originator AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (4 or 16 octets) // | Originator Address (4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator (4 octets) | | Discriminator (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 4 SR Policy Candidate Path Descriptor Format
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 <t>Where:</t>
carry the address of the originator. Refer to section 2.4 of <xref <dl spacing="normal" newline="false">
target="RFC9256"/> for details.</t> <dt>Type:</dt><dd>554</dd>
<dt>Length:</dt><dd>Variable (valid values are 24, 36, or 48 octets)</dd
>
<dt>Protocol-Origin:</dt><dd>1-octet field that identifies the protocol
or
component that is responsible for the instantiation of this path as
specified in <xref target="RFC9256" sectionFormat="of"
section="2.3"/>. The protocol-origin code points to be used are listed
in <xref target="PROTOCOLORIGINS" format="default"/>.</dd>
<dt>Flags:</dt><dd><t>1-octet field with the following bit positions
defined. Other bits <bcp14>MUST</bcp14> be cleared by the originator
and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|E|O| |
+-+-+-+-+-+-+-+-+]]></artwork>
<t>Discriminator: 4 octets to carry the discriminator of the path. <t>Where:</t>
Refer to section 2.5 of <xref target="RFC9256"/> for details.</t> <dl spacing="normal" newline="false">
</list></t> <dt>E-Flag:</dt><dd>Indicates the encoding of an endpoint as an IPv6
address when set and an IPv4 address when clear.</dd>
<dt>O-Flag:</dt><dd>Indicates the encoding of the originator address
as an IPv6 address when set and an IPv4 address when clear.</dd>
</dl>
</dd>
<dt>Reserved:</dt><dd>2 octets that <bcp14>MUST</bcp14> be set to 0
by the originator and <bcp14>MUST</bcp14> be ignored by a
receiver.</dd>
<dt>Endpoint:</dt><dd>4 or 16 octets (as indicated by the flags)
containing the address of the endpoint of the SR Policy as specified
in <xref target="RFC9256" sectionFormat="of" section="2.1"/>.</dd>
<dt>Policy Color:</dt><dd>4 octets that indicate the color of the SR Po
licy
as specified in <xref target="RFC9256" sectionFormat="of"
section="2.1"/>.</dd>
<dt>Originator ASN:</dt><dd>4 octets to carry the 4-byte encoding of
the ASN of the originator. Refer to <xref target="RFC9256"
sectionFormat="of" section="2.4"/> for details.</dd>
<dt>Originator Address:</dt><dd>4 or 16 octets (as indicated by the
flags) to carry the address of the originator. Refer to <xref
target="RFC9256" sectionFormat="of" section="2.4"/> for details.</dd>
<dt>Discriminator:</dt><dd>4 octets to carry the discriminator of the
path. Refer to <xref target="RFC9256" sectionFormat="of"
section="2.5"/> for details.</dd>
</dl>
</section> </section>
<section anchor="SRPOLICYTLVS" numbered="true" toc="default">
<section anchor="SRPOLICYTLVS" title="SR Policy State TLVs"> <name>SR Policy State TLVs</name>
<t>This section defines the various TLVs which enable the headend to <t>This section defines the various TLVs that enable the headend to
report the state at the SR Policy candidate path level. These TLVs (and report the state at the SR Policy candidate path level. These TLVs (and
their sub-TLVs) are carried in the optional non-transitive BGP-LS their sub-TLVs) are carried in the optional non-transitive BGP-LS
Attribute defined in <xref target="RFC9552"/> associated with the SR Attribute defined in <xref target="RFC9552" format="default"/> and are ass ociated with the SR
Policy Candidate Path NLRI type.</t> Policy Candidate Path NLRI type.</t>
<t>The detailed procedures for the advertisement are described in <xref ta
<t>The detailed procedures for the advertisement are described in <xref rget="Procedures" format="default"/>.</t>
target="Procedures"/>.</t> <section anchor="CPBSID" numbered="true" toc="default">
<name>SR Binding SID TLV</name>
<section anchor="CPBSID" title="SR Binding SID TLV"> <t>The SR Binding Segment Identifier (BSID) is an optional TLV that is u
<t>The SR Binding SID (BSID) is an optional TLV that is used to report sed to report
the BSID and its attributes for the SR Policy candidate path. The TLV the BSID and its attributes for the SR Policy candidate path. The TLV
MAY also optionally contain the Specified BSID value for reporting as <bcp14>MAY</bcp14> also optionally contain the Specified BSID value for
described in section 6.2.3 of <xref target="RFC9256"/>. Only a single reporting as
described in <xref target="RFC9256" sectionFormat="of" section="6.2.3"/
>. Only a single
instance of this TLV is advertised for a given candidate path. If instance of this TLV is advertised for a given candidate path. If
multiple instances are present, then the first valid (i.e., not multiple instances are present, then the first valid one (i.e., not
determined to be malformed as per section 8.2.2 of <xref determined to be malformed as per <xref target="RFC9552" sectionFormat="
target="RFC9552"/>) one is used and the rest are ignored.</t> of" section="8.2.2"/>) is used and the rest are ignored.</t>
<t>The TLV has the following format:</t>
<t>The TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ <name>SR Binding SID TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSID Flags | RESERVED | | BSID Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding SID (4 or 16 octets) // | Binding SID (4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Specified Binding SID (4 or 16 octets) // | Specified Binding SID (4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 5 SR Binding SID TLV Format <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>Type:</dt><dd>1201</dd>
]]></artwork> <dt>Length:</dt><dd>Variable (valid values are 12 or 36 octets)</dd>
</figure></t> <dt>BSID Flags:</dt><dd><t>2-octet field that indicates the attribute
and
<t><list style="symbols"> status of the Binding SID (BSID) associated with this candidate
<t>Type: 1201</t> path. The following bit positions are defined, and the semantics are
described in detail in <xref target="RFC9256" sectionFormat="of"
<t>Length: variable (valid values are 12 or 36 octets)</t> section="6.2"/>. Other bits <bcp14>MUST</bcp14> be cleared by the
originator and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
<t>BSID Flags: 2-octet field that indicates attribute and status <artwork name="" type="" align="left" alt=""><![CDATA[
of the Binding SID (BSID) associated with this candidate path. The 0 1
following bit positions are defined and the semantics are 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
described in detail in section 6.2 of <xref target="RFC9256"/>. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Other bits MUST be cleared by the originator and MUST be ignored |D|B|U|L|F| |
by a receiver.<figure> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<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) or 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 candidate path 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 <t>Where:</t>
BSID value regardless of whether it is successfully allocated or <dl spacing="normal" newline="false">
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) <dt>D-Flag:</dt><dd>Indicates the data plane for the BSIDs and if
indicated by the D-Flag. If D-Flag set (SRv6 dataplane), then the a BSID is a 16-octet SRv6 SID (when set) or 4-octet SR/MPLS
length of the BSID fields is 16 octets. If the D-Flag is clear (MPLS label value (when clear).</dd>
dataplane), then the length of the BSID fields is 4 octets. When <dt>B-Flag:</dt><dd>Indicates the allocation of the value in the
BSID field when set and that BSID is not allocated
when clear.</dd>
<dt>U-Flag:</dt><dd>Indicates that the specified BSID value is
unavailable when set. When clear, it indicates that this
candidate path is using the specified BSID. This flag is ignored
when there is no specified BSID.</dd>
<dt>L-Flag:</dt><dd>Indicates that the BSID value is from the Segm
ent
Routing Local Block (SRLB) of the headend node when set and
from the local dynamic label pool when clear.</dd>
<dt>F-Flag:</dt><dd>Indicates that the BSID value is one allocated
from a dynamic label pool due to fallback (e.g., when a specified
BSID is unavailable) when set and that there has been
no fallback for BSID allocation when clear.</dd>
</dl>
</dd>
<dt>RESERVED:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
the originator and <bcp14>MUST</bcp14> be ignored by a receiver.</dd>
<dt>Binding SID:</dt><dd>Indicates the operational or allocated
BSID value based on the status flags.</dd>
<dt>Specified BSID:</dt><dd>Used to report the explicitly
specified BSID value regardless of whether it is successfully
allocated or not. The field is set to value 0 when the BSID has not be
en
specified.</dd>
</dl>
<t>The BSID fields above depend on the data plane (SRv6 or MPLS)
indicated by the D-flag. If the D-flag is set (SRv6 data plane), then th
e
length of the BSID fields is 16 octets. If the D-flag is clear (MPLS
data plane), then the length of the BSID fields is 4 octets. When
carrying the MPLS Label, as shown in the figure below, the TC, S, and 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 TTL (total of 12 bits) are RESERVED and <bcp14>MUST</bcp14> be set to 0
originator and MUST be ignored by a receiver.</t> by the
originator and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
<t><figure> <figure>
<artwork><![CDATA[ <name>SR Binding SID Label Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 6 SR Binding SID Label Format
]]></artwork>
</figure></t>
<t>In the case of an SRv6, the SR Binding SID sub-TLV does not have <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 the ability to signal the SRv6 Endpoint behavior <xref
target="RFC8986"/> or the structure of the SID. Therefore, the SR target="RFC8986" format="default"/> or the structure of the
Binding SID sub-TLV SHOULD NOT be used for the advertisement of an SID. Therefore, the SR Binding SID sub-TLV <bcp14>SHOULD NOT</bcp14>
SRv6 Binding SID. Instead, the SRv6 Binding SID TLV defined in <xref be used for the advertisement of an SRv6 Binding SID. Instead, the
target="CPBSIDSRV6"/> SHOULD be used for signaling of an SRv6 Binding SRv6 Binding SID TLV defined in <xref target="CPBSIDSRV6"
SID. The use of the SR Binding SID sub-TLV for advertisement of the format="default"/> <bcp14>SHOULD</bcp14> be used for the signaling of an
SRv6 Binding SID has been deprecated, and is documented here only for SRv6 Binding SID. The use of the SR Binding SID sub-TLV for
backward compatibility with implementations that followed early advertisement of the SRv6 Binding SID has been deprecated, and it is
versions of this specification.</t> documented here only for backward compatibility with implementations
that followed early draft versions of this specification.</t>
</section> </section>
<section anchor="CPBSIDSRV6" numbered="true" toc="default">
<section anchor="CPBSIDSRV6" title="SRv6 Binding SID TLV"> <name>SRv6 Binding SID TLV</name>
<t>The SRv6 Binding SID (BSID) is an optional TLV that is used to <t>The SRv6 Binding SID (BSID) is an optional TLV that is used to
report the SRv6 BSID and its attributes for the SR Policy candidate report the SRv6 BSID and its attributes for the SR Policy candidate
path. The TLV MAY also optionally contain the Specified SRv6 BSID path. The TLV <bcp14>MAY</bcp14> also optionally contain the Specified S
value for reporting as described in section 6.2.3 of <xref Rv6 BSID
target="RFC9256"/>. Multiple instances of this TLV may be used to value for reporting as described in <xref target="RFC9256" sectionFormat
="of" section="6.2.3"/>. Multiple instances of this TLV may be used to
report each of the SRv6 BSIDs associated with the candidate path.</t> report each of the SRv6 BSIDs associated with the candidate path.</t>
<t>The TLV has the following format:</t>
<figure>
<name>SRv6 Binding SID TLV Format</name>
<t>The TLV has the following format:<figure align="center"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSID Flags | RESERVED | | BSID Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding SID (16 octets) // | Binding SID (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Specified Binding SID (16 octets) // | Specified Binding SID (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Sub-TLVs (variable) // // sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 7 SRv6 Binding SID TLV Format <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>Type:</dt><dd>1212</dd>
]]></artwork> <dt>Length:</dt><dd>Variable</dd>
</figure></t> <dt>BSID Flags:</dt><dd><t>2-octet field that indicates the attribute
and status of the BSID associated with this candidate
<t><list style="symbols"> path. The following bit positions are defined, and the semantics are
<t>Type: 1212</t> described in detail in <xref target="RFC9256" sectionFormat="of"
section="6.2"/>. Other bits <bcp14>MUST</bcp14> be cleared by the
<t>Length: variable</t> originator and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>BSID Flags: 2-octet field that indicates attribute and status 0 1
of the Binding SID (BSID) associated with this candidate path. The 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
following bit positions are defined and the semantics are +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
described in detail in section 6.2 of <xref target="RFC9256"/>. |B|U|F| |
Other bits MUST be cleared by the originator and MUST be ignored +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
by a receiver.<figure> <t>Where:</t>
<artwork><![CDATA[ 0 1 <dl spacing="normal" newline="false">
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 <dt>B-Flag:</dt><dd>Indicates the allocation of the value in the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BSID field when set and that BSID is not allocated
|B|U|F| | when clear.</dd>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dt>U-Flag:</dt><dd>Indicates the specified BSID value is
unavailable when set. When clear, it indicates that this
Where: candidate path is using the specified BSID. This flag is ignored
]]></artwork> when there is no specified BSID.</dd>
</figure><list style="symbols"> <dt>F-Flag:</dt><dd>Indicates that the BSID value is one allocated
<t>B-Flag: Indicates the allocation of the value in the BSID dynamically due to fallback (e.g., when the specified BSID is
field when set and indicates that BSID is not allocated when unavailable) when set and that there has been no
clear.</t> fallback for BSID allocation when clear.</dd>
</dl>
<t>U-Flag: Indicates the specified BSID value is unavailable </dd>
when set. When clear it indicates that this candidate path is <dt>RESERVED:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
using the specified BSID. This flag is ignored when there is the originator and <bcp14>MUST</bcp14> be ignored by a receiver.</dd>
no specified BSID.</t> <dt>Binding SID:</dt><dd>Indicates the operational or allocated
BSID value based on the status flags.</dd>
<t>F-Flag: Indicates the BSID value is one allocated <dt>Specified BSID:</dt><dd>Used to report the explicitly
dynamically due to fallback (e.g. when specified BSID is specified BSID value regardless of whether it is successfully
unavailable) when set and indicates that there has been no allocated or not. The field is set to value 0 when the BSID has not be
fallback for BSID allocation when clear.</t> en
</list></t> specified.</dd>
<dt>Sub-TLVs:</dt><dd>Variable and contain any other optional
<t>RESERVED: 2 octets. MUST be set to 0 by the originator and MUST attributes associated with the SRv6 BSID.</dd>
be ignored by a receiver.</t> </dl>
<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 <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 (1252) <bcp14>MAY</bcp14> optionally be used as sub-TLVs of the SRv6 Binding SID
TLV to indicate the SRv6 Endpoint behavior and SID structure for the TLV to indicate the SRv6 Endpoint behavior and SID structure for the
Binding SID value in the TLV. <xref target="RFC9514"/> defines SRv6 Binding SID value in the TLV. <xref target="RFC9514" format="default"/>
Endpoint Behavior TLV And SRv6 SID Structure TLV.</t> defines the SRv6
Endpoint Behavior TLV and the SRv6 SID Structure TLV.</t>
</section> </section>
<section anchor="CPSTATE" numbered="true" toc="default">
<section anchor="CPSTATE" title="SR Candidate Path State TLV"> <name>SR Candidate Path State TLV</name>
<t>The SR Candidate Path State TLV provides the operational status and <t>The SR Candidate Path State TLV provides the operational status and
attributes of the SR Policy at the candidate path level. Only a single attributes of the SR Policy at the candidate path level. Only a single
instance of this TLV is advertised for a given candidate path. If instance of this TLV is advertised for a given candidate path. If
multiple instances are present, then the first valid (i.e., not multiple instances are present, then the first valid one (i.e., not
determined to be malformed as per section 8.2.2 of <xref determined to be malformed as per <xref target="RFC9552" sectionFormat=
target="RFC9552"/>) one is used and the rest are ignored.</t> "of" section="8.2.2"/>) is used and the rest are ignored.</t>
<t>The TLV has the following format:</t>
<t>The TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ <name>SR Candidate Path State TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | RESERVED | Flags | | Priority | RESERVED | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (4 octets) | | Preference (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 8 SR Candidate Path State TLV Format
Where:
]]></artwork>
</figure></t>
<t><list style="symbols">
<t>Type: 1202</t>
<t>Length: 8 octets</t>
<t>Priority: 1-octet value which indicates the priority of the
candidate path. 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 <t>Where:</t>
candidate path. The following bit positions are defined and the <dl spacing="normal" newline="false">
semantics are described in section 5 of <xref target="RFC9256"/> <dt>Type:</dt><dd>1202</dd>
unless stated otherwise for individual flags. Other bits MUST be <dt>Length:</dt><dd>8 octets</dd>
cleared by the originator and MUST be ignored by a <dt>Priority:</dt><dd>1-octet value that indicates the priority of t
receiver.<figure> he
<artwork><![CDATA[ 0 1 candidate path. Refer to <xref target="RFC9256" sectionFormat="of" s
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ection="2.12"/>.</dd>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dt>RESERVED:</dt><dd>1 octet. <bcp14>MUST</bcp14> be set to 0 by th
|S|A|B|E|V|O|D|C|I|T|U| | e originator and <bcp14>MUST</bcp14>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ be ignored by a receiver.</dd>
<dt>Flags:</dt><dd><t>2-octet field that indicates the attribute and
status of the
candidate path. The following bit positions are defined, and the
semantics are described in <xref target="RFC9256" sectionFormat="of"
section="5"/>
unless stated otherwise for individual flags. Other bits <bcp14>MUST
</bcp14> be
cleared by the originator and <bcp14>MUST</bcp14> be ignored by a
receiver.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A|B|E|V|O|D|C|I|T|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
Where: <t>Where:</t>
]]></artwork> <dl spacing="normal" newline="false">
</figure><list style="symbols"> <dt>S-Flag:</dt><dd>Indicates that the candidate path is in an
<t>S-Flag: Indicates the candidate path is in an administrative shut state when set and not in an administrative
administrative shut state when set and not in administrative shut state when clear.</dd>
shut state when clear.</t> <dt>A-Flag:</dt><dd>Indicates that the candidate path is the act
ive path
(i.e., one provisioned in the forwarding plane as specified in
<xref target="RFC9256" sectionFormat="of" section="2.9"/>) for t
he SR Policy
when set and not the active path when clear.</dd>
<dt>B-Flag:</dt><dd>Indicates that the candidate path is the bac
kup path
(i.e., one identified for path protection of the active path as
specified in <xref target="RFC9256" sectionFormat="of" section="
9.3"/>) for the
SR Policy when set and not the backup path when clear.</dd>
<dt>E-Flag:</dt><dd>Indicates that the candidate path has been
evaluated for validity (e.g., headend may evaluate candidate
paths based on their preferences) when set and has not been
evaluated for validity when clear.</dd>
<dt>V-Flag:</dt><dd>Indicates that the candidate path has at lea
st one valid
SID list when set and that no valid SID list is available
or evaluated when clear.
<t>A-Flag: Indicates the candidate path is the active path <!--[rfced] We note multiple instances of "MUST be set to 0 by the
(i.e. one provisioned in the forwarding plane as specified in originator and MUST be ignored by a receiver". Should the one
section 2.9 of <xref target="RFC9256"/>) for the SR Policy instance below that contains only one "MUST" be updated
when set and not the active path when clear.</t> accordingly (see Section 5.3)?
<t>B-Flag: Indicates the candidate path is the backup path Original:
(i.e. one identified for path protection of the active path as V-Flag: Indicates the candidate path has at least one valid SID-List
specified in section 9.3 of <xref target="RFC9256"/>) for the when set and indicates no valid SID-List is available or evaluated
SR Policy when set and not the backup path when clear.</t> when clear. When the E-Flag is clear (i.e. the candidate path has not
been evaluated), then this flag MUST be set to 0 by the originator and
ignored by the receiver.
<t>E-Flag: Indicates that the candidate path has been Perhaps:
evaluated for validity (e.g. headend may evaluate candidate V-Flag: Indicates that the candidate path has at least one valid SID-List
paths based on their preferences) when set and has not been when set and that no valid SID-List is available or evaluated when clear.
evaluated for validity when clear.</t> When the E-Flag is clear (i.e., the candidate path has not been evaluated),
then this flag MUST be set to 0 by the originator and MUST be ignored by a
receiver.
<t>V-Flag: Indicates the candidate path has at least one valid AD approval needed.
SID-List when set and indicates no valid SID-List is available -->
or evaluated when clear. When the E-Flag is clear (i.e. the
candidate path has not been evaluated), then this flag MUST be
set to 0 by the originator and ignored by the receiver.</t>
<t>O-Flag: Indicates the candidate path was instantiated by When the E-flag is clear (i.e., the
the headend due to an on-demand nexthop trigger based on a candidate path has not been evaluated), then this flag <bcp14>MU
ST</bcp14> be
set to 0 by the originator and MUST be ignored by a receiver.</d
d>
<dt>O-Flag:</dt><dd>Indicates that the candidate path was instan
tiated by
the headend due to an on-demand next hop trigger based on a
local template when set and that the candidate path has not local template when set and that the candidate path has not
been instantiated due to on-demand nexthop trigger when clear. been instantiated due to an on-demand next hop trigger when clea
Refer to section 8.5 of <xref target="RFC9256"/> for r.
details.</t> Refer to <xref target="RFC9256" sectionFormat="of" section="8.5"
/> for
<t>D-Flag: Indicates the candidate path was delegated for details.</dd>
computation to a PCE/controller when set and indicates that <dt>D-Flag:</dt><dd>Indicates that the candidate path was delega
ted for
computation to a PCE/controller when set and that
the candidate path has not been delegated for computation when the candidate path has not been delegated for computation when
clear.</t> clear.</dd>
<dt>C-Flag:</dt><dd>Indicates that the candidate path was provis
<t>C-Flag: Indicates the candidate path was provisioned by a ioned by a
PCE/controller when set and indicates that the candidate path PCE/controller when set and that the candidate path
was not provisioned by a PCE/controller when clear.</t> was not provisioned by a PCE/controller when clear.</dd>
<dt>I-Flag:</dt><dd>Indicates that the candidate path is to perf
<t>I-Flag: Indicates the candidate path is to perform the orm the
"drop upon invalid" behavior when no other valid candidate "Drop-Upon-Invalid" behavior when no other valid candidate
path is available for this SR Policy when the flag is set. path is available for this SR Policy when the flag is set.
Refer to section 8.2 of <xref target="RFC9256"/> for details. Refer to <xref target="RFC9256" sectionFormat="of" section="8.2" /> for details.
When clear, it indicates that the candidate path is not When clear, it indicates that the candidate path is not
enabled for the "drop upon invalid" behavior.</t> enabled for the "Drop-Upon-Invalid" behavior.</dd>
<dt>T-Flag:</dt><dd>Indicates that the candidate path has been m
<t>T-Flag: Indicates the candidate path has been marked as arked as
eligible for use as a transit policy on the headend when set eligible for use as a transit policy on the headend when set
and not eligible for use as a transit policy when clear. and not eligible for use as a transit policy when clear.
Transit policy is a policy whose BSID can be used in the Transit policy is a policy whose BSID can be used in the
segment list of another SR Policy. Refer to section 8.3 of segment list of another SR Policy. Refer to
<xref target="RFC9256"/> for steering into a transit policy <xref target="RFC9256" sectionFormat="of" section="8.3"/> for st
using its BSID.</t> eering into a transit policy
using its BSID.</dd>
<t>U-Flag: Indicates that this candidate path is reported as <dt>U-Flag:</dt><dd>Indicates that the candidate path is reporte
active and is dropping traffic as a result of the "drop upon d as
invalid" behavior being activated for the SR Policy when set. active and is dropping traffic as a result of the "Drop-Upon-Inv
alid"
behavior being activated for the SR Policy when set.
When clear, it indicates that the candidate path is not When clear, it indicates that the candidate path is not
dropping traffic as a result of the "drop upon invalid" dropping traffic as a result of the "Drop-Upon-Invalid"
behavior. Refer to section 8.2 of <xref target="RFC9256"/> for behavior. Refer to <xref target="RFC9256" sectionFormat="of" sec
details.</t> tion="8.2"/> for
</list></t> details.</dd>
</dl>
<t>Preference: 4-octet value which indicates the preference of the </dd>
candidate path. Refer to section 2.7 of <xref target="RFC9256"/> <dt>Preference:</dt><dd>4-octet value that indicates the preference
for details.</t> of the
</list></t> candidate path. Refer to <xref target="RFC9256" sectionFormat="of" s
ection="2.7"/>
for details.</dd>
</dl>
</section> </section>
<section anchor="POLNAME" numbered="true" toc="default">
<section anchor="POLNAME" title="SR Policy Name TLV"> <name>SR Policy Name TLV</name>
<t>The SR Policy Name TLV is an optional TLV that is used to carry the <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 symbolic name associated with the SR Policy. Only a single instance of
this TLV is advertised for a given candidate path. If multiple this TLV is advertised for a given candidate path. If multiple
instances are present, then the first valid (i.e., not determined to instances are present, then the first valid one (i.e., not determined to
be malformed as per section 8.2.2 of <xref target="RFC9552"/>) one is be malformed as per <xref target="RFC9552" sectionFormat="of" section="8
.2.2"/>) is
used and the rest are ignored.</t> used and the rest are ignored.</t>
<t>The TLV has the following format:</t>
<t>The TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>SR Policy Name TLV Format</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR Policy Name (variable) // | SR Policy Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 9 SR Policy Name TLV Format
Where:
]]></artwork>
</figure></t>
<t><list style="symbols">
<t>Type: 1213</t>
<t>Length: variable</t>
<t>SR Policy Name: Symbolic name for the SR Policy without a NULL <t>Where:</t>
terminator as specified in section 2.1 of <xref <dl spacing="normal" newline="false">
target="RFC9256"/>. It is RECOMMENDED that the size of the <dt>Type:</dt><dd>1213</dd>
symbolic name be limited to 255 bytes. Implementations MAY choose <dt>Length:</dt><dd>Variable</dd>
to truncate long names to 255 bytes when signaling via BGP-LS.</t> <dt>SR Policy Name:</dt><dd>Symbolic name for the SR Policy without
</list></t> a NUL
terminator as specified in <xref target="RFC9256" sectionFormat="of"
section="2.1"/>. It is <bcp14>RECOMMENDED</bcp14> that the size of the
symbolic name be limited to 255 bytes. Implementations <bcp14>MAY</b
cp14> choose
to truncate long names to 255 bytes when signaling via BGP-LS.</dd>
</dl>
</section> </section>
<section anchor="CPNAME" numbered="true" toc="default">
<section anchor="CPNAME" title="SR Candidate Path Name TLV"> <name>SR Candidate Path Name TLV</name>
<t>The SR Candidate Path Name TLV is an optional TLV that is used to <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 carry the symbolic name associated with the candidate path. Only a
single instance of this TLV is advertised for a given candidate path. single instance of this TLV is advertised for a given candidate path.
If multiple instances are present, then the first valid (i.e., not If multiple instances are present, then the first valid one (i.e., not
determined to be malformed as per section 8.2.2 of <xref determined to be malformed as per <xref target="RFC9552" sectionFormat="
target="RFC9552"/>) one is used and the rest are ignored.</t> of" section="8.2.2"/>) is used and the rest are ignored.</t>
<t>The TLV has the following format:</t>
<t>The TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>SR Candidate Path Name TLV Format</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Candidate Path Name (variable) // | Candidate Path Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 10 SR Candidate Path Name TLV Format
Where:
]]></artwork>
</figure></t>
<t><list style="symbols">
<t>Type: 1203</t>
<t>Length: variable</t>
<t>Candidate Path Name: Symbolic name for the SR Policy candidate <t>Where:</t>
path without a NULL terminator as specified in section 2.6 of <dl spacing="normal" newline="false">
<xref target="RFC9256"/>. It is RECOMMENDED that the size of the <dt>Type:</dt><dd>1203</dd>
symbolic name be limited to 255 bytes. Implementations MAY choose <dt>Length:</dt><dd>Variable</dd>
to truncate long names to 255 bytes when signaling via BGP-LS.</t> <dt>Candidate Path Name:</dt><dd>Symbolic name for the SR Policy
</list></t> candidate path without a NUL terminator as specified in <xref
target="RFC9256" sectionFormat="of" section="2.6"/>. It is
<bcp14>RECOMMENDED</bcp14> that the size of the symbolic name be
limited to 255 bytes. Implementations <bcp14>MAY</bcp14> choose to
truncate long names to 255 bytes when signaling via BGP-LS.</dd>
</dl>
</section> </section>
<section anchor="CPCONSTRAINTS" numbered="true" toc="default">
<section anchor="CPCONSTRAINTS" <name>SR Candidate Path Constraints TLV</name>
title="SR Candidate Path Constraints TLV">
<t>The SR Candidate Path Constraints TLV is an optional TLV that is <t>The SR Candidate Path Constraints TLV is an optional TLV that is
used to report the constraints associated with the candidate path. The used to report the constraints associated with the candidate path. The
constraints are generally applied to a dynamic candidate path which is constraints are generally applied to a dynamic candidate path that is
computed either by the headend or may be delegated to a controller. either computed by the headend or delegated to a controller.
The constraints may also be applied to an explicit path where the The constraints may also be applied to an explicit path where the
computation entity is expected to validate that the path satisfies 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., specified constraints; if not, the path is to be invalidated (e.g.,
due to topology changes). Only a single instance of this TLV is due to topology changes). Only a single instance of this TLV is
advertised for a given candidate path. If multiple instances are advertised for a given candidate path. If multiple instances are
present, then the first valid (i.e., not determined to be malformed as present, then the first valid one (i.e., not determined to be malformed
per section 8.2.2 of <xref target="RFC9552"/>) one is used and the as
per <xref target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used
and the
rest are ignored.</t> rest are ignored.</t>
<t>The TLV has the following format:</t>
<t>The TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>SR Candidate Path Constraints TLV Format</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED1 | | Flags | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTID | Algorithm | RESERVED2 | | MTID | Algorithm | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (variable) // | sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 11 SR Candidate Path Constraints TLV Format
Where:
]]></artwork>
</figure></t>
<t><list style="symbols">
<t>Type: 1204</t>
<t>Length: variable</t>
<t>Flags: 2-octet field that indicates the constraints that are <t>Where:</t>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd>1204</dd>
<dt>Length:</dt><dd>Variable</dd>
<dt>Flags:</dt><dd><t>2-octet field that indicates the constraints t
hat are
being applied to the candidate path. The following bit positions being applied to the candidate path. The following bit positions
are defined and the other bits MUST be cleared by the originator are defined, and the other bits <bcp14>MUST</bcp14> be cleared by th
and MUST be ignored by a receiver.<figure> e originator
<artwork><![CDATA[ 0 1 and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1
|D|P|U|A|T|S|F|H| | 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>
]]></artwork>
</figure><list style="symbols">
<t>D-Flag: Indicates that the candidate path uses SRv6
dataplane when set and SR/MPLS dataplane when clear</t>
<t>P-Flag: Indicates that the candidate path prefers the use <t>Where:</t>
of only protected SIDs when set and indicates that the <dl spacing="normal">
<dt>D-Flag:</dt><dd>Indicates that the candidate path uses an SR
v6
data plane when set and an SR/MPLS data plane when clear.</dd>
<dt>P-Flag:</dt><dd>Indicates that the candidate path prefers th
e use
of only protected SIDs when set and that the
candidate path does not prefer the use of only protected SIDs candidate path does not prefer the use of only protected SIDs
when clear. This flag is mutually exclusive with the U-Flag when clear. This flag is mutually exclusive with the U-flag
(i.e., both these flags cannot be set at the same time).</t> (i.e., both of these flags cannot be set at the same time).</dd>
<dt>U-Flag:</dt><dd>Indicates that the candidate path prefers th
<t>U-Flag: Indicates that the candidate path prefers the use e use
of only unprotected SIDs when set and indicates that the of only unprotected SIDs when set and that the
candidate path does not prefer the use of only unprotected candidate path does not prefer the use of only unprotected
SIDs when clear. This flag is mutually exclusive with the SIDs when clear. This flag is mutually exclusive with the
P-Flag (i.e., both these flags cannot be set at the same P-Flag (i.e., both of these flags cannot be set at the same
time).</t> time).</dd>
<dt>A-Flag:</dt><dd>Indicates that the candidate path uses only
<t>A-Flag: Indicates that the candidate path uses only the the
SIDs belonging to the specified SR Algorithm when set and SIDs belonging to the specified SR Algorithm when set and
indicates that the candidate path does not use only the SIDs that the candidate path does not use only the SIDs
belonging to the specified SR Algorithm when clear.</t> belonging to the specified SR Algorithm when clear.</dd>
<dt>T-Flag:</dt><dd>Indicates that the candidate path uses only
<t>T-Flag: Indicates that the candidate path uses only the the
SIDs belonging to the specified topology when set and SIDs belonging to the specified topology when set and
indicates that the candidate path does not use only the SIDs that the candidate path does not use only the SIDs
belonging to the specified topology when clear.</t> belonging to the specified topology when clear.</dd>
<dt>S-Flag:</dt><dd>Indicates that the use of protected (P-flag)
<t>S-Flag: Indicates that the use of protected (P-Flag) or or
unprotected (U-Flag) SIDs becomes a strict constraint instead unprotected (U-flag) SIDs becomes a strict constraint instead
of a preference when set and indicates that there is no strict of a preference when set and that there is no strict
constraint (and only a preference) when clear.</t> constraint (and only a preference) when clear.</dd>
<dt>F-Flag:</dt><dd>Indicates that the candidate path is fixed o
<t>F-Flag: Indicates that the candidate path is fixed once nce
computed and not modified except on operator intervention and computed and not modified except on operator intervention and
indicates that the candidate path may be modified as part of that the candidate path may be modified as part of
recomputation when clear.</t> recomputation when clear.</dd>
<dt>H-Flag:</dt><dd>Indicates that the candidate path uses only
<t>H-Flag: Indicates that the candidate path uses only
adjacency SIDs and traverses hop-by-hop over the links adjacency SIDs and traverses hop-by-hop over the links
corresponding to those adjacency SIDs when set and indicates corresponding to those adjacency SIDs when set and
that the candidate path is not restricted to using only that the candidate path is not restricted to using only
hop-by-hop adjacency SIDs when clear.</t> hop-by-hop adjacency SIDs when clear.</dd>
</list></t> </dl>
</dd>
<t>RESERVED1: 2 octets. MUST be set to 0 by the originator and <dt>RESERVED1:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
MUST be ignored by a receiver.</t> the originator and
<bcp14>MUST</bcp14> be ignored by a receiver.</dd>
<t>MTID: Indicates the multi-topology identifier of the IGP <dt>MTID:</dt><dd>Indicates the multi-topology identifier of the IGP
topology that is preferred to be used when the path is set up. 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 When the T-flag is set, then the path is strictly using the
specified topology SIDs only.</t> specified topology SIDs only.</dd>
<dt>Algorithm:</dt><dd>Indicates the algorithm that is preferred to
<t>Algorithm: Indicates the algorithm that is preferred to be used be used
when the path is set up. When the A-flag is set then the path is 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 strictly using the specified algorithm SIDs only. The algorithm
values are from IGP Algorithm Types registry under the IANA values are from the "IGP Algorithm Types" IANA registry under the
Interior Gateway Protocol (IGP) Parameters.</t> "Interior Gateway Protocol (IGP) Parameters" registry group.</dd>
<dt>RESERVED2:</dt><dd>1 octet. <bcp14>MUST</bcp14> be set to 0 by t
<t>RESERVED2: 1 octet. MUST be set to 0 by the originator and MUST he originator and <bcp14>MUST</bcp14>
be ignored by a receiver.</t> be ignored by a receiver.</dd>
<dt>sub-TLVs:</dt><dd>One or more optional sub-TLVs <bcp14>MAY</bcp1
<t>sub-TLVs: one or more optional sub-TLVs MAY be included in this 4> be included in this
TLV to describe other constraints. These sub-TLVs are: SR Affinity TLV to describe other constraints. These sub-TLVs are: SR Affinity
Constraint, SR SRLG Constraint, SR Bandwidth Constraint, SR Constraint, SR Shared Risk Link Group (SRLG) Constraint, SR Bandwidt h Constraint, SR
Disjoint Group Constraint, SR Bidirectional Group Constraint, and Disjoint Group Constraint, SR Bidirectional Group Constraint, and
SR Metric Constraint.</t> SR Metric Constraint.</dd>
</list></t> </dl>
<t>These constraint sub-TLVs are defined below.</t> <t>These constraint sub-TLVs are defined below.</t>
<section anchor="CPAFFINITY" numbered="true" toc="default">
<section anchor="CPAFFINITY" title="SR Affinity Constraint Sub-TLV"> <name>SR Affinity Constraint Sub-TLV</name>
<t>The SR Affinity Constraint sub-TLV is an optional sub-TLV of the <t>The SR Affinity Constraint sub-TLV is an optional sub-TLV of the
SR Candidate Path Constraints TLV that is used to carry the affinity SR Candidate Path Constraints TLV that is used to carry the affinity
constraints <xref target="RFC2702"/> associated with the candidate constraints <xref target="RFC2702" format="default"/> associated with
path. The affinity is expressed in terms of Extended Admin Group the candidate
(EAG) as defined in <xref target="RFC7308"/>. Only a single instance path. The affinity is expressed in terms of an Extended Administrative
Group
(EAG) as defined in <xref target="RFC7308" format="default"/>. Only a
single instance
of this sub-TLV is advertised for a given candidate path. If of this sub-TLV is advertised for a given candidate path. If
multiple instances are present, then the first valid (i.e., not multiple instances are present, then the first valid one (i.e., not
determined to be malformed as per section 8.2.2 of <xref determined to be malformed as per <xref target="RFC9552" sectionFormat
target="RFC9552"/>) one is used and the rest are ignored.</t> ="of" section="8.2.2"/>) is used and the rest are ignored.</t>
<t>The sub-TLV has the following format:</t>
<t>The sub-TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>SR Affinity Constraint Sub-TLV Format</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excl-Any-Size | Incl-Any-Size | Incl-All-Size | RESERVED | | Excl-Any-Size | Incl-Any-Size | Incl-All-Size | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-Any EAG (optional, variable) // | Exclude-Any EAG (optional, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-Any EAG (optional, variable) // | Include-Any EAG (optional, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-All EAG (optional, variable) // | Include-All EAG (optional, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 12 SR Affinity Constraints Sub-TLV Format <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>Type:</dt><dd>1208</dd>
]]></artwork> <dt>Length:</dt><dd>Variable, dependent on the size of the EAG.
</figure></t> <bcp14>MUST</bcp14> be a non-zero multiple of 4 octets.</dd>
<dt>Exclude-Any-Size:</dt><dd>1 octet to indicate the size of
<t><list style="symbols"> Exclude-Any EAG bitmask size in multiples of 4 octets (e.g.,
<t>Type: 1208</t> value 0 indicates the Exclude-Any EAG field is skipped, and value
1
<t>Length: variable, dependent on the size of the Extended Admin indicates that 4 octets of Exclude-Any EAG are included).</dd>
Group. MUST be a non-zero multiple of 4 octets.</t> <dt>Include-Any-Size:</dt><dd>1 octet to indicate the size of
Include-Any EAG bitmask size in multiples of 4 octets (e.g.,
<t>Exclude-Any-Size: one octet to indicate the size of value 0 indicates the Include-Any EAG field is skipped, and value
Exclude-Any EAG bitmask size in multiples of 4 octets. (e.g. 1
value 0 indicates the Exclude-Any EAG field is skipped, value 1 indicates that 4 octets of Include-Any EAG are included).</dd>
indicates that 4 octets of Exclude-Any EAG is included)</t> <dt>Include-All-Size:</dt><dd>1 octet to indicate the size of
Include-All EAG bitmask size in multiples of 4 octets (e.g.,
<t>Include-Any-Size: one octet to indicate the size of value 0 indicates the Include-All EAG field is skipped, and value
Include-Any EAG bitmask size in multiples of 4 octets. (e.g. 1
value 0 indicates the Include-Any EAG field is skipped, value 1 indicates that 4 octets of Include-All EAG are included).</dd>
indicates that 4 octets of Include-Any EAG is included)</t> <dt>RESERVED:</dt><dd>1 octet. <bcp14>MUST</bcp14> be set to 0 by
the originator and
<t>Include-All-Size: one octet to indicate the size of <bcp14>MUST</bcp14> be ignored by a receiver.</dd>
Include-All EAG bitmask size in multiples of 4 octets. (e.g. <dt>Exclude-Any EAG:</dt><dd>The bitmask used to represent the aff
value 0 indicates the Include-All EAG field is skipped, value 1 inities
indicates that 4 octets of Include-All EAG is included)</t> that have been excluded from the path.</dd>
<dt>Include-Any EAG:</dt><dd>The bitmask used to represent the aff
<t>RESERVED: 1 octet. MUST be set to 0 by the originator and inities
MUST be ignored by a receiver.</t> that have been included in the path.</dd>
<dt>Include-All EAG:</dt><dd>The bitmask used to represent all the
<t>Exclude-Any EAG: the bitmask used to represent the affinities affinities that have been included in the path.</dd>
that have been excluded from the path.</t> </dl>
<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>
<section anchor="CPSRLG" numbered="true" toc="default">
<section anchor="CPSRLG" title="SR SRLG Constraint Sub-TLV"> <name>SR SRLG Constraint Sub-TLV</name>
<t>The SR SRLG Constraint sub-TLV is an optional sub-TLV of the SR <t>The SR SRLG Constraint sub-TLV is an optional sub-TLV of the SR
Candidate Path Constraints TLV that is used to carry the Shared Risk Candidate Path Constraints TLV that is used to carry the SRLG values <
Link Group (SRLG) values <xref target="RFC4202"/> that have been xref target="RFC4202" format="default"/> that have been
excluded from the candidate path. Only a single instance of this excluded from the candidate path. Only a single instance of this
sub-TLV is advertised for a given candidate path. If multiple sub-TLV is advertised for a given candidate path. If multiple
instances are present, then the first valid (i.e., not determined to instances are present, then the first valid one (i.e., not determined
be malformed as per section 8.2.2 of <xref target="RFC9552"/>) one to
be malformed as per <xref target="RFC9552" sectionFormat="of" section=
"8.2.2"/>)
is used and the rest are ignored.</t> is used and the rest are ignored.</t>
<t>The sub-TLV has the following format:</t>
<t>The sub-TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>SR SRLG Constraint Sub-TLV Format</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Values (variable, multiples of 4 octets) // | SRLG Values (variable, multiples of 4 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 13 SR SRLG Constraints Sub-TLV Format
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 non-zero multiple of 4 octets.</t>
<t>SRLG Values: One or more SRLG values. Each SRLG value is of 4 <t>Where:</t>
octets.</t> <dl spacing="normal" newline="false">
</list></t> <dt>Type:</dt><dd>1209</dd>
<dt>Length:</dt><dd>Variable, dependent on the number of SRLGs enc
oded.
<bcp14>MUST</bcp14> be a non-zero multiple of 4 octets.</dd>
<dt>SRLG Values:</dt><dd>One or more SRLG values. Each SRLG value
is of 4
octets.</dd>
</dl>
</section> </section>
<section anchor="CPBW" numbered="true" toc="default">
<section anchor="CPBW" title="SR Bandwidth Constraint Sub-TLV"> <name>SR Bandwidth Constraint Sub-TLV</name>
<t>The SR Bandwidth Constraint sub-TLV is an optional sub-TLV of the <t>The SR Bandwidth Constraint sub-TLV is an optional sub-TLV of the
SR Candidate Path Constraints TLV that is used to indicate the SR Candidate Path Constraints TLV that is used to indicate the
bandwidth that has been requested for the candidate path. Only a bandwidth that has been requested for the candidate path. Only a
single instance of this sub-TLV is advertised for a given candidate single instance of this sub-TLV is advertised for a given candidate
path. If multiple instances are present, then the first valid (i.e., path. If multiple instances are present, then the first valid one (i.e
not determined to be malformed as per section 8.2.2 of <xref .,
target="RFC9552"/>) one is used and the rest are ignored.</t> not determined to be malformed as per <xref target="RFC9552" sectionFo
rmat="of" section="8.2.2"/>) is used and the rest are ignored.</t>
<t>The sub-TLV has the following format:<figure align="center"> <t>The sub-TLV has the following format:</t>
<artwork align="left"><![CDATA[ 0 1 <figure>
2 3 <name>SR Bandwidth Constraint Sub-TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth | | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 14 SR Bandwidth Constraints Sub-TLV Format
Where:
]]></artwork>
</figure></t>
<t><list style="symbols">
<t>Type: 1210</t>
<t>Length: 4 octets</t>
<t>Bandwidth: 4 octets which specify the desired bandwidth in <t>Where:</t>
unit of bytes per second in IEEE floating point format <xref <dl spacing="normal" newline="false">
target="IEEE754"/>.</t> <dt>Type:</dt><dd>1210</dd>
</list></t> <dt>Length:</dt><dd>4 octets</dd>
<dt>Bandwidth:</dt><dd>4 octets that specify the desired bandwidth
in
unit of bytes per second in IEEE floating point format <xref targe
t="IEEE754" format="default"/>.</dd>
</dl>
</section> </section>
<section anchor="CPDISJOINT" numbered="true" toc="default">
<section anchor="CPDISJOINT" <name>SR Disjoint Group Constraint Sub-TLV</name>
title="SR Disjoint Group Constraint Sub-TLV">
<t>The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV <t>The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV
of the SR Candidate Path Constraints TLV that is used to carry the of the SR Candidate Path Constraints TLV that is used to carry the
disjointness constraint associated with the candidate path. The disjointness constraint associated with the candidate path. The
disjointness between two SR Policy Candidate Paths is expressed by disjointness between two SR Policy candidate paths is expressed by
associating them with the same disjoint group identifier and then associating them with the same disjoint group identifier and then
specifying the type of disjointness required between their paths. specifying the type of disjointness required between their paths.
The types of disjointness are described in section 3 of <xref The types of disjointness are described in <xref target="RFC8800" sect
target="RFC8800"/> where the level of disjointness increases in the ionFormat="of" section="3"/> where the level of disjointness increases in the
order: link, node, SRLG, Node + SRLG. The computation is expected to order: link, node, SRLG, Node + SRLG. The computation is expected to
achieve the highest level of disjointness requested and when that is achieve the highest level of disjointness requested; when that is
not possible then fall back to a lesser level progressively based on not possible, then fall back to a lesser level progressively based on
the levels indicated. Only a single instance of this sub-TLV is the levels indicated. Only a single instance of this sub-TLV is
advertised for a given candidate path. If multiple instances are advertised for a given candidate path. If multiple instances are
present, then the first valid (i.e., not determined to be malformed present, then the first valid one (i.e., not determined to be malforme
as per section 8.2.2 of <xref target="RFC9552"/>) one is used and d
as per <xref target="RFC9552" sectionFormat="of" section="8.2.2"/>) is
used and
the rest are ignored.</t> the rest are ignored.</t>
<t>The sub-TLV has the following format:</t>
<figure>
<name>SR Disjoint Group Constraint Sub-TLV Format</name>
<t>The sub-TLV has the following format:<figure align="center"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[ 0 1 0 1 2 3
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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-Flags | Status-Flags | RESERVED | | Request Flags | Status Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disjoint Group Identifier (variable) // | Disjoint Group Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 15 SR Disjoint Group Constraints Sub-TLV Format
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 <t>Where:</t>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd>1211</dd>
<dt>Length:</dt><dd>Variable. Minimum of 8 octets.</dd>
<dt>Request Flags:</dt><dd><t>1 octet to indicate the level of
disjointness requested as specified in the form of flags. The disjointness requested as specified in the form of flags. The
following flags are defined and the other bits MUST be cleared following flags are defined, and the other bits <bcp14>MUST</bcp14
by the originator and MUST be ignored by a receiver.<figure> > be cleared
<artwork><![CDATA[ by the originator and <bcp14>MUST</bcp14> be ignored by a receiver
0 1 2 3 4 5 6 7 .</t>
+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="left" alt=""><![CDATA[
|S|N|L|F|I| | 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S|N|L|F|I| |
Where: +-+-+-+-+-+-+-+-+]]></artwork>
]]></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 fall back to a <t>Where:</t>
<dl spacing="normal" newline="false">
<dt>S-Flag:</dt><dd>Indicates that SRLG disjointness is reques
ted
when set and that SRLG disjointness is not
requested when clear.</dd>
<dt>N-Flag:</dt><dd>Indicates that node disjointness is reques
ted
when set and that node disjointness is not
requested when clear.</dd>
<dt>L-Flag:</dt><dd>Indicates that link disjointness is reques
ted
when set and that the link disjointness is not
requested when clear.</dd>
<dt>F-Flag:</dt><dd>Indicates that the computation may fall ba
ck to a
lower level of disjointness amongst the ones requested when lower level of disjointness amongst the ones requested when
all cannot be achieved when set and indicates that fallback all cannot be achieved when set and that fallback
to a lower level of disjointness is not allowed when to a lower level of disjointness is not allowed when
clear.</t> clear.</dd>
<dt>I-Flag:</dt><dd>Indicates that the computation may fall ba
<t>I-Flag: Indicates that the computation may fall back to ck to
the default best path (e.g. IGP path) in case of none of the the default best path (e.g., an IGP path) in case none of the
desired disjointness can be achieved when set and indicates desired disjointness can be achieved when set and
that fallback to the default best path is not allowed when that fallback to the default best path is not allowed when
clear.</t> clear.</dd>
</list></t> </dl>
</dd>
<t>Status Flags: one octet to indicate the level of disjointness <dt>Status Flags:</dt><dd><t>1 octet to indicate the level of disjoi
ntness
that has been achieved by the computation as specified in the that has been achieved by the computation as specified in the
form of flags. The following flags are defined and the other form of flags. The following flags are defined, and the other
bits MUST be cleared by the originator and MUST be ignored by a bits <bcp14>MUST</bcp14> be cleared by the originator and <bcp14>M
receiver.<figure> UST</bcp14> be ignored by a
<artwork><![CDATA[ receiver.</t>
0 1 2 3 4 5 6 7 <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7
|S|N|L|F|I|X| | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |S|N|L|F|I|X| |
+-+-+-+-+-+-+-+-+]]></artwork>
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 <t>Where:</t>
<dl spacing="normal" newline="false">
<dt>S-Flag:</dt><dd>Indicates that SRLG disjointness is achiev
ed when
set and that SRLG disjointness is not achieved
when clear.</dd>
<dt>N-Flag:</dt><dd>Indicates that node disjointness is achiev
ed when
set and that node disjointness was not achieved
when clear.</dd>
<dt>L-Flag:</dt><dd>Indicates that link disjointness is achiev
ed when
set and that link disjointness was not achieved
when clear.</dd>
<dt>F-Flag:</dt><dd>Indicates that the computation has fallen
back to
a lower level of disjointness than requested when set and a lower level of disjointness than requested when set and
indicates that there has been no fallback to a lower level that there has been no fallback to a lower level
of disjointness when clear.</t> of disjointness when clear.</dd>
<dt>I-Flag:</dt><dd>Indicates that the computation has fallen
<t>I-Flag: Indicates that the computation has fallen back to back to
the best path (e.g. IGP path) and disjointness has not been the best path (e.g., an IGP path) and disjointness has not bee
achieved when set and indicates that there has been no n
fallback to best path when clear.</t> achieved when set and that there has been no
fallback to the best path when clear.</dd>
<t>X-Flag : Indicates that the disjointness constraint could <dt>X-Flag:</dt><dd>Indicates that the disjointness constraint
not be achieved and hence path has been invalidated when set could
and indicates that the path has not been invalidated due to not be achieved and hence the path has been invalidated when s
unmet disjointness constraints when clear.</t> et
</list></t> and that the path has not been invalidated due to
unmet disjointness constraints when clear.</dd>
<t>RESERVED: 2 octets. MUST be set to 0 by the originator and </dl>
MUST be ignored by a receiver.</t> </dd>
<dt>RESERVED:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
<t>Disjoint Group Identifier: 4-octet value that is the group the originator and
<bcp14>MUST</bcp14> be ignored by a receiver.</dd>
<dt>Disjoint Group Identifier:</dt><dd>4-octet value that is the g
roup
identifier for a set of disjoint paths. Alternatively, this identifier for a set of disjoint paths. Alternatively, this
field MAY contain the entire PCEP Association Object as field <bcp14>MAY</bcp14> contain the entire PCEP ASSOCIATION Objec
specified in section 6.1 of <xref target="RFC8697"/> (including t as
its optional TLVs) when PCEP is used for the signaling the SR specified in <xref target="RFC8697" sectionFormat="of" section="6.
1"/> (including
its optional TLVs) when PCEP is used for the signaling of the SR
Policy candidate path and where the BGP-LS Producer is unable to Policy candidate path and where the BGP-LS Producer is unable to
determine the group identifier that can be accommodated in a determine the group identifier that can be accommodated in a
4-octet value (since PCEP supports multiple methods of encoding 4-octet value (since PCEP supports multiple methods of encoding
an association identifier). Note that the parsing of the PCEP an association identifier). Note that the parsing of the PCEP
object is expected to be performed only by the BGP-LS Consumer object is expected to be performed only by the BGP-LS Consumer
(hence, outside the scope of this document) and not by any BGP (hence, outside the scope of this document) and not by any BGP
Speaker as specified in <xref target="RFC9552"/>. If the PCEP Speaker as specified in <xref target="RFC9552" format="default"/>. If the PCEP
object size is such that the update for a single SR Policy object size is such that the update for a single SR Policy
Candidate Path NLRI would exceed the supported BGP message size Candidate Path NLRI would exceed the supported BGP message size
by the implementation, then the PCEP Association Object MUST NOT by the implementation, then the PCEP ASSOCIATION Object <bcp14>MUS T NOT</bcp14>
be encoded and this sub-TLV skipped along with an error log. be encoded and this sub-TLV skipped along with an error log.
Refer section 5.3 of <xref target="RFC9552"/> for discussion on Refer to <xref target="RFC9552" sectionFormat="of" section="5.3"/> for discussion on
implications of encoding large sets of information into implications of encoding large sets of information into
BGP-LS.</t> BGP-LS.</dd>
</list></t> </dl>
</section> </section>
<section anchor="CPBIDIR" numbered="true" toc="default">
<section anchor="CPBIDIR" <name>SR Bidirectional Group Constraint Sub-TLV</name>
title="SR Bidirectional Group Constraint Sub-TLV">
<t>The SR Bidirectional Group Constraint sub-TLV is an optional <t>The SR Bidirectional Group Constraint sub-TLV is an optional
sub-TLV of the SR Candidate Path Constraints TLV that is used to sub-TLV of the SR Candidate Path Constraints TLV that is used to
carry the bidirectional constraint associated with the candidate carry the bidirectional constraint associated with the candidate
path. The bidirectional relationship between two SR Policy Candidate path. The bidirectional relationship between two SR Policy candidate
Paths is expressed by associating them with the same bidirectional paths is expressed by associating them with the same bidirectional
group identifier and then specifying the type of bidirectional group identifier and then specifying the type of bidirectional
routing required between their paths. Only a single instance of this routing required between their paths. Only a single instance of this
sub-TLV is advertised for a given candidate path. If multiple sub-TLV is advertised for a given candidate path. If multiple
instances are present, then the first valid (i.e., not determined to instances are present, then the first valid one (i.e., not determined
be malformed as per section 8.2.2 of <xref target="RFC9552"/>) one to
be malformed as per <xref target="RFC9552" sectionFormat="of" section=
"8.2.2"/>)
is used and the rest are ignored.</t> is used and the rest are ignored.</t>
<t>The sub-TLV has the following format:</t>
<t>The sub-TLV has the following format:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>SR Bidirectional Group Constraint Sub-TLV Format</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bidirectional Group Identifier (variable) // | Bidirectional Group Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 16 SR Bidirectional Group Constraints Sub-TLV Format
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 <t>Where:</t>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd>1214</dd>
<dt>Length:</dt><dd>Variable. Minimum of 8 octets.</dd>
<dt>Flags:</dt><dd><t>2 octets to indicate the bidirectional path
setup
information as specified in the form of flags. The following information as specified in the form of flags. The following
flags are defined and the other bits MUST be cleared by the flags are defined, and the other bits <bcp14>MUST</bcp14> be clear
originator and MUST be ignored by a receiver.<figure> ed by the
<artwork><![CDATA[ 0 1 originator and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1
|R|C| | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|C| |
Where: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure><list style="symbols">
<t>R-Flag: Indicates that this candidate path of the SR
Policy forms the reverse path when the R-Flag is set. If the
R-Flag is clear, this candidate path 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 <t>Where:</t>
group identifier for a set of bidirectional paths. <dl spacing="normal">
Alternatively, this field MAY contain the entire PCEP <dt>R-Flag:</dt><dd>Indicates that the candidate path of the S
Association Object as specified in section 6.1 of <xref R
target="RFC8697"/> (including its optional TLVs) when PCEP is Policy forms the reverse path when the R-flag is set. If the
used for the signaling the SR Policy candidate path and where R-flag is clear, the candidate path forms the forward
the BGP-LS Producer is unable to determine the group identifier path.</dd>
that can be accommodated in a 4-octet value (since PCEP supports <dt>C-Flag:</dt><dd>Indicates that the bidirectional path is
multiple methods of encoding an association identifier). Note co-routed when set and that the bidirectional path
that the parsing of the PCEP object is expected to be performed is not co-routed when clear.</dd>
only by the BGP-LS Consumer (hence, outside the scope of this </dl>
document) and not by any BGP Speaker as specified in <xref </dd>
target="RFC9552"/>. If the PCEP object size is such that the <dt>RESERVED:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
update for a single SR Policy Candidate Path NLRI would exceed the originator and <bcp14>MUST</bcp14> be ignored by a
the supported BGP message size by the implementation, then the receiver.</dd>
PCEP Association Object MUST NOT be encoded and this sub-TLV <dt>Bidirectional Group Identifier:</dt><dd>4-octet value that is
skipped along with an error log. Refer section 5.3 of <xref the group identifier for a set of bidirectional paths.
target="RFC9552"/> for discussion on implications of encoding Alternatively, this field <bcp14>MAY</bcp14> contain the entire
large sets of information into BGP-LS.</t> PCEP ASSOCIATION Object as specified in <xref target="RFC8697"
</list></t> sectionFormat="of" section="6.1"/> (including its optional TLVs)
when PCEP is used for the signaling of the SR Policy candidate path
and where the BGP-LS Producer is unable to determine the group
identifier that can be accommodated in a 4-octet value (since PCEP
supports multiple methods of encoding an association
identifier). Note that the parsing of the PCEP object is expected
to be performed only by the BGP-LS Consumer (hence, outside the
scope of this document) and not by any BGP Speaker as specified in
<xref target="RFC9552" format="default"/>. If the PCEP object size
is such that the update for a single SR Policy Candidate Path NLRI
would exceed the supported BGP message size by the implementation,
then the PCEP ASSOCIATION Object <bcp14>MUST NOT</bcp14> be
encoded and this sub-TLV skipped along with an error log. Refer to
<xref target="RFC9552" sectionFormat="of" section="5.3"/> for
discussion on implications of encoding large sets of information
into BGP-LS.</dd>
</dl>
</section> </section>
<section anchor="CPMETRIC" numbered="true" toc="default">
<section anchor="CPMETRIC" title="SR Metric Constraint Sub-TLV"> <name>SR Metric Constraint Sub-TLV</name>
<t>The SR Metric Constraint sub-TLV is an optional sub-TLV of the SR <t>The SR Metric Constraint sub-TLV is an optional sub-TLV of the SR
Candidate Path Constraints TLV that is used to report the Candidate Path Constraints TLV that is used to report the
optimization metric of the candidate path. For a dynamic path optimization metric of the candidate path. For a dynamic path
computation, it is used to report the optimization metric used along computation, it is used to report the optimization metric used along
with its parameters. For an explicit path, this sub-TLV MAY be used with its parameters. For an explicit path, this sub-TLV <bcp14>MAY</bc
to report the metric margin or bound to be used for validation p14> be used
to report the metric margin or is bound to be used for validation
(i.e., the path is invalidated if the metric is beyond specified (i.e., the path is invalidated if the metric is beyond specified
values). Multiple instances of this sub-TLV may be used to report values). Multiple instances of this sub-TLV may be used to report
different metric type uses.</t> different metric type uses.</t>
<t>The sub-TLV has the following format: </t>
<t>The sub-TLV has the following format: <figure align="center"> <figure>
<artwork align="left"><![CDATA[ <name>SR Metric Constraint Sub-TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Type | Flags | RESERVED | | Metric Type | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Margin | | Metric Margin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Bound | | Metric Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 17 SR Metric Constraints Sub-TLV Format <t>Where:</t>
<dl spacing="normal">
<dt>Type:</dt><dd>1215</dd>
<dt>Length:</dt><dd>12 octets</dd>
<dt>Metric Type:</dt><dd><t>1-octet field that identifies the type
of
metric being used.
Where: <!--[rfced] How may we rephrase the text in Section 5.6.6 for clarity?
]]></artwork> In the first sentence, we note that Table 1 (Section 5.7.1.1)
</figure><list style="symbols"> does not list references for the types. Should the term
<t>Type: 1215</t> "reference" be replaced with "Segment Descriptor" or other for
conciseness? And may we rephrase the second sentence as shown
below for clarity and to make it parallel?
<t>Length: 12 octets</t> We also note that Tables 1 and 6 contain the same information. Should
Table 1 be removed and references to Table 1 (in Sections 5.6.6 and
5.7.1.1) be updated to point to Table 6?
<t>Metric Type: 1-octet field which identifies the type of the Original (Section 5.6.6):
metric being used. The Table 1 below lists the metric types The Table 1 below lists the metric types introduced by this document
introduced by this document along with reference for each. Where along with reference for each. Where the references are for IS-IS
and OSPF specifications, those metric types are defined for a link
while in the SR Policy context those relate to the candidate path
or the segment list.
Perhaps:
Table 6 lists the metric types introduced by this document along
with a Segment Descriptor for each. Where the Segment Descriptors
relate to IS-IS and OSPF specifications, the metric types are defined
for a link. Where the Segment Descriptors relate to the SR Policy,
the metric types are defined for a candidate path or a segment list.
...
Original (Section 5.7.1.1)
The following types are currently defined and their mapping to the
respective segment types defined in [RFC9256]:
Perhaps:
See Table 6 for the type definitions and their mappings to the
respective segment types defined in [RFC9256].
-->
Below is a list of metric types
introduced by this document along with references for each. Where
the references are for IS-IS and OSPF specifications, those the references are for IS-IS and OSPF specifications, those
metric types are defined for a link while in the SR Policy metric types are defined for a link while in the SR Policy
context those relate to the candidate path or the segment list. context those relate to the candidate path or the segment list.
The metric type code points that may be used in this sub-TLV are The metric type code points that may be used in this sub-TLV are
also listed in <xref target="METRICTYPE"/> of this document. also listed in <xref target="METRICTYPE" format="default"/> of thi
Note that the metric type in this field is not taken from the s document.
"IGP Metric Type" registry from IANA "IGP Parameters" and is a Note that the metric types in this field are taken from the
separate registry that includes IGP Metric Types as well as "BGP-LS SR Policy Metric Types" IANA registry, which includes
metric types specific to SR Policy path computation. Additional IGP Metric Types as well as metric types specific to SR Policy
path computation (i.e., the metric types are not from the
"IGP Metric-Type" registry). Additional
metric types may be introduced by future documents. This metric types may be introduced by future documents. This
document does not make any assumption of a smaller metric value document does not make any assumptions about a smaller metric valu e
being better than a higher metric value; that is something being better than a higher metric value; that is something
dependent on the semantics of the specific metric type. The that is dependent on the semantics of the specific metric type. Th is
document uses the words "best" and "worst" to abstract this document uses the words "best" and "worst" to abstract this
aspect when referring to metric margins and bounds.<list aspect when referring to metric margins and bounds.</t>
style="symbols"> <dl spacing="normal" newline="true">
<t>Type 0: IGP: In IS-IS, this is known as the default <dt>Type 0: IGP:</dt><dd>This is specified in <xref target="RFC5
metric and specified in section 3 of <xref 305" sectionFormat="of" section="3"/> for IS-IS and is known as the default metr
target="RFC5305"/>. This is known as metric in both OSPFv2 ic. This is specified in <xref target="RFC2328" format="default"/> for OSPFv2 an
<xref target="RFC2328"/> and OSPFv3 <xref d in <xref target="RFC5340" format="default"/> for OSPFv3 and is known as the me
target="RFC5340"/>.</t> tric in both.</dd>
<dt>Type 1: Min Unidirectional Delay:</dt><dd>This is
<t>Type 1: Min Unidirectional Delay: This is specified in specified in <xref target="RFC8570" sectionFormat="of"
section 4.2 of <xref target="RFC8570"/> for IS-IS and in section="4.2"/> for IS-IS and in <xref target="RFC7471"
section 4.2 of <xref target="RFC7471"/> for sectionFormat="of" section="4.2"/> for OSPFv2/OSPFv3.</dd>
OSPFv2/OSPFv3.</t> <dt>Type 2: TE:</dt><dd>This is specified in <xref
target="RFC5305" sectionFormat="of" section="3.7"/> for IS-IS as
<t>Type 2: TE: This is specified in section 3.7 of <xref the TE
target="RFC5305"/> as the TE default metric for IS-IS, in default metric, in <xref target="RFC3630"
section 2.5.5 of <xref target="RFC3630"/> for OSPFv2, and in sectionFormat="of" section="2.5.5"/> for OSPFv2, and in <xref
section 4 of <xref target="RFC5329"/> for OSPFv3.</t> target="RFC5329" sectionFormat="of" section="4"/> for
OSPFv3.</dd>
<t>Type 3: Hop Count: This is specified in section 7.8 of <dt>Type 3: Hop Count:</dt><dd>This is specified in <xref
<xref target="RFC5440"/>.</t> target="RFC5440" sectionFormat="of" section="7"/>.</dd>
<dt>Type 4: SID List Length:</dt><dd>This is specified in
<t>Type 4: SID List Length: This is specified in section 4.5 <xref target="RFC8664" sectionFormat="of" section="4.5"/>.</dd>
of <xref target="RFC8664"/>.</t> <dt>Type 5: Bandwidth:</dt><dd>This is specified in <xref
target="RFC9843" sectionFormat="of"
<t>Type 5: Bandwidth: This is specified in section 4 of section="4"/>.</dd>
<xref target="I-D.ietf-lsr-flex-algo-bw-con"/>.</t> <dt>Type 6: Avg Unidirectional Delay:</dt><dd>This is
specified in <xref target="RFC8570" sectionFormat="of"
<t>Type 6: Average Unidirectional Delay: This is specified section="4.1"/> for IS-IS and in <xref target="RFC7471"
in section 4.1 of <xref target="RFC8570"/> for IS-IS and in sectionFormat="of" section="4.1"/> for OSPFv2/OSPFv3.</dd>
section 4.1 of <xref target="RFC7471"/> for <dt>Type 7: Unidirectional Delay Variation:</dt><dd>This is
OSPFv2/OSPFv3.</t> specified in <xref target="RFC8570" sectionFormat="of"
section="4.3"/> for IS-IS and in <xref target="RFC7471"
<t>Type 7: Unidirectional Delay Variation: This is specified sectionFormat="of" section="4.3"/> for OSPFv2/OSPFv3.</dd>
in section 4.3 of <xref target="RFC8570"/> for IS-IS and in <dt>Type 8: Loss:</dt><dd>This is specified in <xref
section 4.3 of <xref target="RFC7471"/> for target="RFC8570" sectionFormat="of" section="4.4"/> for IS-IS
OSPFv2/OSPFv3.</t> and in <xref target="RFC7471" sectionFormat="of"
section="4.4"/> for OSPFv2/OSPFv3.</dd>
<t>Type 8: Loss: This is specified in section 4.4 of <xref <dt>Types 128 to 255 (both inclusive): User
target="RFC8570"/> for IS-IS and in section 4.4 of <xref Defined:</dt><dd>This is specified in <xref
target="RFC7471"/> for OSPFv2/OSPFv3.</t> target="RFC9843" sectionFormat="of"
section="2"/> for IS-IS and OSPF.</dd>
<t>Types 128 to 255 (both inclusive): User Defined: This is </dl>
specified for IS-IS and OSPF in section 2 of <xref </dd>
target="I-D.ietf-lsr-flex-algo-bw-con"/>.</t> <dt>Flags:</dt><dd><t>1-octet field that indicates the validity of
</list></t> the metric fields and their semantics. The following bit positions
are defined, and the other bits <bcp14>MUST</bcp14> be cleared by
<t>Flags: 1-octet field that indicates the validity of the the originator and <bcp14>MUST</bcp14> be ignored by a
metric fields and their semantics. The following bit positions receiver.</t>
are defined and the other bits MUST be cleared by the originator <artwork name="" type="" align="left" alt=""><![CDATA[
and MUST be ignored by a receiver.<figure> 0 1 2 3 4 5 6 7
<artwork><![CDATA[ +-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 |O|M|A|B| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
|O|M|A|B| |
+-+-+-+-+-+-+-+-+
Where: <t>Where:</t>
]]></artwork> <dl spacing="normal" newline="false">
</figure><list style="symbols"> <dt>O-Flag:</dt><dd>Indicates that this is the optimization me
<t>O-Flag: Indicates that this is the optimization metric tric
being reported for a dynamic candidate path when set and being reported for a dynamic candidate path when set and
indicates that the metric is not the optimization metric that the metric is not the optimization metric
when clear. This bit MUST NOT be set in more than one when clear. This bit <bcp14>MUST NOT</bcp14> be set in more th
an one
instance of this TLV for a given candidate path instance of this TLV for a given candidate path
advertisement.</t> advertisement.</dd>
<dt>M-Flag:</dt><dd>Indicates that the metric margin allowed i
<t>M-Flag: Indicates that the metric margin allowed is s
specified when set and indicates that metric margin allowed specified when set and that the metric margin allowed
is not specified when clear.</t> is not specified when clear.</dd>
<dt>A-Flag:</dt><dd>Indicates that the metric margin is specif
<t>A-Flag: Indicates that the metric margin is specified as ied as
an absolute value when set and is expressed as a percentage an absolute value when set and that the metric margin is expre
of the minimum metric when clear.</t> ssed as a percentage
of the minimum metric when clear.</dd>
<t>B-Flag: Indicates that the metric bound allowed for the <dt>B-Flag:</dt><dd>Indicates that the metric bound allowed fo
path is specified when set and indicates that metric bound r the
is not specified when clear.</t> path is specified when set and that the metric bound
</list></t> is not specified when clear.</dd>
</dl>
<t>RESERVED: 2 octets. MUST be set to 0 by the originator and </dd>
MUST be ignored by a receiver.</t> <dt>RESERVED:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
the originator and <bcp14>MUST</bcp14> be ignored by a
<t>Metric Margin: 4-octet value which indicates the metric receiver.</dd>
margin when the M-flag is set. The metric margin is specified, <dt>Metric Margin:</dt><dd>4-octet value that indicates the
depending on the A-flag, as either an absolute value or as a metric margin when the M-flag is set. The metric margin is
percentage of the best computed path metric based on the specified, depending on the A-flag, as either an absolute value or
specified constraints for path calculation. The metric margin a percentage of the best computed path metric based on the
allows for the metric value of the computed path to vary specified constraints for path calculation. The metric margin
(depending on the semantics of the specific metric type) from allows for the metric value of the computed path to vary
the best metric value possible to optimize for other factors (depending on the semantics of the specific metric type) from the
(that are not specified as constraints) such as bandwidth best metric value possible to optimizing for other factors (that are
availability, minimal SID stack depth, and maximizing of ECMP not specified as constraints) such as bandwidth availability,
for the SR path computed.</t> minimal SID stack depth, and the maximizing of ECMP for the computed
SR path.</dd>
<t>Metric Bound: 4-octet value which indicates the worst metric <dt>Metric Bound:</dt><dd>4-octet value that indicates the worst
value (depending on the semantics of the specific metric type) metric value (depending on the semantics of the specific metric
that is allowed when the B-flag is set. If the computed path type) allowed when the B-flag is set. If the computed path
metric crosses the specified bound value then the path is metric crosses the specified bound value, then the path is
considered invalid.</t> considered invalid.</dd>
</list></t> </dl>
<t>The absolute metric margin and the metric bound values are <t>The absolute metric margin and the metric bound values are
encoded as specified for each metric type. For metric types that are encoded as specified for each metric type. For metric types that are
smaller than 4 octets in size, the most significant bits are filled smaller than 4 octets in size, the most significant bits are filled
with zeros. The percentage metric margin is encoded as an unsigned with zeros. The percentage metric margin is encoded as an unsigned
integer percentage value.</t> integer percentage value.</t>
</section> </section>
</section> </section>
<section anchor="SEGMENTLIST" numbered="true" toc="default">
<section anchor="SEGMENTLIST" title="SR Segment List TLV"> <name>SR Segment List TLV</name>
<t>The SR Segment List TLV is used to report a single SID-List of a <t>The SR Segment List TLV is used to report a single SID list of a
candidate path. Multiple instances of this TLV may be used to report candidate path. Multiple instances of this TLV may be used to report
multiple SID-Lists of a candidate path.</t> multiple SID lists of a candidate path.</t>
<t>The TLV has the following format: </t>
<figure>
<name>SR Segment List TLV Format</name>
<t>The TLV has the following format: <figure align="center"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | | Flags | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTID | Algorithm | RESERVED | | MTID | Algorithm | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight (4 octets) | | Weight (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (variable) // | sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 18 SR Segment List TLV Format
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 consists of SRv6 SIDs when
set and indicates it consists 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 <t>Where:</t>
the SID-List for weighted load-balancing. Refer to section 2.2 and <dl spacing="normal" newline="false">
2.11 of <xref target="RFC9256"/>.</t> <dt>Type:</dt><dd>1205</dd>
<dt>Length:</dt><dd>Variable</dd>
<dt>Flags:</dt><dd><t> 2-octet field that indicates the attribute and
status of the
SID list. The following bit positions are defined, and the semantics
are described in detail in <xref target="RFC9256" format="default"/>
. Other bits
<bcp14>MUST</bcp14> be cleared by the originator and <bcp14>MUST</bc
p14> be ignored by a
receiver.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|E|C|V|R|F|A|T|M| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>Sub-TLVs: variable and contains the ordered set of Segments and <t>Where:</t>
<dl spacing="normal" newline="false">
<dt>D-Flag:</dt><dd>Indicates that the SID list consists of SRv6 S
IDs
when set and SR/MPLS labels when clear.</dd>
<dt>E-Flag:</dt><dd>Indicates that the SID list is associated with
an explicit candidate path when set and a dynamic candidate
path when clear. All segment lists of a given candidate path
<bcp14>MUST</bcp14> be either explicit or dynamic. In case of
inconsistency, the receiver <bcp14>MAY</bcp14> consider them all
to be dynamic.</dd>
<dt>C-Flag:</dt><dd>Indicates that the SID list has been computed
for a dynamic path when set. It is always reported as set for
explicit paths. When clear, it indicates that the SID list has
not been computed for a dynamic path.</dd>
<dt>V-Flag:</dt><dd>Indicates that the SID list has passed
verification or its verification was not required when set and
that it failed verification when clear.</dd>
<dt>R-Flag:</dt><dd>Indicates that the first Segment has been
resolved when set and that it failed resolution when clear.</dd>
<dt>F-Flag:</dt><dd>Indicates that the computation for the
dynamic path failed when set and that it succeeded (or was not req
uired in
case of an explicit path) when clear.</dd>
<dt>A-Flag:</dt><dd>Indicates that all the SIDs in the SID list
belong to the specified algorithm when set and that
not all the SIDs belong to the specified algorithm when
clear.</dd>
<dt>T-Flag:</dt><dd>Indicates that all the SIDs in the SID list
belong to the specified topology (identified by the
multi-topology ID) when set and that not all the SIDs
belong to the specified topology when clear.</dd>
<dt>M-Flag:</dt><dd>Indicates that the SID list has been removed
from the forwarding plane due to fault detection by a monitoring
mechanism (e.g., Bidirectional Forwarding Detection (BFD)) when se
t and that no fault is detected or
no monitoring is being done when clear.</dd>
</dl>
</dd>
<dt>RESERVED1:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
the originator and <bcp14>MUST</bcp14> be ignored by a
receiver.</dd>
<dt>MTID:</dt><dd>2 octets that indicate the multi-topology identifi
er of
the IGP topology that is to be used when the T-flag is set.</dd>
<dt>Algorithm:</dt><dd>1 octet that indicates the algorithm of the S
IDs
used in the SID list when the A-flag is set. The algorithm values
are from the "IGP Algorithm Types" IANA registry under the "Interior
Gateway Protocol (IGP) Parameters" registry group.</dd>
<dt>RESERVED2:</dt><dd>1 octet. <bcp14>MUST</bcp14> be set to 0 by
the originator and <bcp14>MUST</bcp14> be ignored by a
receiver.</dd>
<dt>Weight:</dt><dd>4-octet field that indicates the weight
associated with the SID list for weighted load balancing. Refer to
Sections <xref target="RFC9256" sectionFormat="bare"
section="2.2"/> and <xref target="RFC9256" sectionFormat="bare"
section="2.11"/> of <xref target="RFC9256" format="default"/>.</dd>
<dt>Sub-TLVs:</dt><dd>Variable and contain the ordered set of Segmen
ts and
any other optional attributes associated with the specific any other optional attributes associated with the specific
SID-List.</t> SID list.</dd>
</list></t> </dl>
<t>The SR Segment sub-TLV (defined in <xref target="SEGMENTTLV" format="
<t>The SR Segment sub-TLV (defined in <xref target="SEGMENTTLV"/>) default"/>)
MUST be included as an ordered set of sub-TLVs within the SR Segment <bcp14>MUST</bcp14> be included as an ordered set of sub-TLVs within the
List TLV when the SID-List is not empty. A SID-List may be empty in SR Segment
certain situations (e.g. for a dynamic path) where the headend has not 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 yet performed the computation and hence not derived the segments
required for the path. In such cases where the SID-LIST is empty, the required for the path. In such cases where the SID list is empty, the
SR Segment List TLV MUST NOT include any SR Segment sub-TLVs.</t> SR Segment List TLV <bcp14>MUST NOT</bcp14> include any SR Segment sub-T
LVs.</t>
<section anchor="SEGMENTTLV" title="SR Segment Sub-TLV"> <section anchor="SEGMENTTLV" numbered="true" toc="default">
<t>The SR Segment sub-TLV describes a single segment in a SID-List. <name>SR Segment Sub-TLV</name>
<t>The SR Segment sub-TLV describes a single segment in a SID list.
One or more instances of this sub-TLV in an ordered manner 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 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: sub-TLV of the SR Segment List TLV and it has the following format:
<figure align="center"> </t>
<artwork align="left"><![CDATA[ <figure>
<name>SR Segment Sub-TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Type | RESERVED | Flags | | Segment Type | RESERVED | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (4 or 16 octets) // | SID (4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Segment Descriptor (variable) // // Segment Descriptor (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Sub-TLVs (variable) // // sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 19 SR Segment Sub-TLV Format
Where:
]]></artwork>
</figure><list style="symbols">
<t>Type: 1206</t>
<t>Length: variable</t>
<t>Segment Type: 1 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-Flag 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-Flag is clear, it indicates the SID has
failed resolution.</t>
<t>A-Flag: Indicates that the Algorithm indicated in the <t>Where:</t>
Segment descriptor is valid when set. When clear, it <dl spacing="normal" newline="false">
indicates that the headend is unable to determine the <dt>Type:</dt><dd>1206</dd>
algorithm of the SID.</t> <dt>Length:</dt><dd>Variable</dd>
</list></t> <dt>Segment Type:</dt><dd>1 octet that indicates the type of
segment. Initial values are specified by this document (see <xref
target="SEGMENTDESC" format="default"/> for details). Additional
segment types are possible but are out of scope for this
document.</dd>
<dt>RESERVED:</dt><dd>1 octet. <bcp14>MUST</bcp14> be set to 0 by
the originator and <bcp14>MUST</bcp14> be ignored by a
receiver.</dd>
<dt>Flags:</dt><dd><t>2-octet field that indicates the attribute and
status of the Segment and its SID. The following bit positions are
defined, and the semantics are described in <xref target="RFC9256"
sectionFormat="of" section="5"/>. Other bits <bcp14>MUST</bcp14>
be cleared by the originator and <bcp14>MUST</bcp14> be ignored by
a receiver.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|V|R|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>SID: 4 octets carrying the MPLS Label or 16 octets carrying <t>Where:</t>
<dl spacing="normal" newline="false">
<dt>S-Flag:</dt><dd>Indicates the presence of the SID value in t
he
SID field when set and no value when
clear.</dd>
<dt>E-Flag:</dt><dd>Indicates that the SID value is an explicitl
y
provisioned value (locally on headend or via controller/PCE)
when set and is a dynamically resolved value by headend when
clear.</dd>
<dt>V-Flag:</dt><dd>Indicates that the SID has passed verificati
on
or did not require verification when set. When the V-flag is
clear, it indicates the SID has failed verification.</dd>
<dt>R-Flag:</dt><dd>Indicates that the SID has been resolved or
did
not require resolution (e.g., because it is not the first SID)
when set. When the R-flag is clear, it indicates the SID has
failed resolution.</dd>
<dt>A-Flag:</dt><dd>Indicates that the Algorithm indicated in
the segment descriptor is valid when set. When clear, it
indicates that the headend is unable to determine the
algorithm of the SID.</dd>
</dl>
</dd>
<dt>SID:</dt><dd><t>4 octets carrying the MPLS Label or 16 octets
carrying
the SRv6 SID based on the Segment Type. When carrying the MPLS 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 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 of 12 bits) are RESERVED and <bcp14>MUST</bcp14> be set to 0 by th
and MUST be ignored by a receiver.<figure> e originator
<artwork><![CDATA[ and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </dd>
</figure></t> <dt>Segment Descriptor:</dt><dd>Variable size segment descriptor
based on the type of segment (refer to <xref target="SEGMENTDESC"
<t>Segment Descriptor: variable size Segment descriptor based on format="default"/> for details).</dd>
the type of segment (refer to <xref target="SEGMENTDESC"/> for <dt>Sub-Sub-TLVs:</dt><dd>Variable and contain any other optional
details)</t> attributes associated with the specific segment.</dd>
</dl>
<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 <t>The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure
TLV (1252) defined in <xref target="RFC9514"/> are used as TLV (1252) defined in <xref target="RFC9514" format="default"/> are us ed as
sub-sub-TLVs of the SR Segment sub-TLV. These two sub-sub-TLVs are 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 used to optionally indicate the SRv6 Endpoint behavior and SID
structure when advertising the SRv6 specific segment types.</t> structure when advertising the SRv6-specific segment types.</t>
<section anchor="SEGMENTDESC" numbered="true" toc="default">
<section anchor="SEGMENTDESC" title="Segment Descriptors"> <name>Segment Descriptors</name>
<t>Section 4 of <xref target="RFC9256"/> defines multiple types of <t><xref target="RFC9256" sectionFormat="of" section="4"/> defines m
segments and their description. This section defines the encoding ultiple types of
of the Segment Descriptors for each of those Segment types to be segments and their descriptions. This section defines the encoding
used in the Segment sub-TLV described previously in <xref of the segment descriptors for each of those segment types to be
target="SEGMENTTLV"/>.</t> used in the Segment sub-TLV described previously in <xref target="SE
GMENTTLV" format="default"/>.</t>
<t>The following types are currently defined and their mapping to <t>The following types are currently defined, and their mappings to
the respective segment types defined in <xref target="RFC9256"/>: the respective segment types are defined in <xref target="RFC9256" f
<figure align="center"> ormat="default"/>:
<artwork align="left"><![CDATA[+------+------------------------- </t>
------------------------------------+
| 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 |
+------+-------------------------------------------------------------+
Table 1 SR Segment Types
]]></artwork> <table anchor="SR_segment_types">
</figure></t> <name>SR Segment Types</name>
<thead>
<tr>
<th>Type</th><th>Segment Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td><td>(Type A) SR-MPLS Label</td>
</tr>
<tr>
<td>2</td><td>(Type B) SRv6 SID</td>
</tr>
<tr>
<td>3</td><td>(Type C) IPv4 Prefix with optional SR Algorithm</td>
</tr>
<tr>
<td>4</td><td>(Type D) IPv6 Global Prefix with optional SR Algorithm for S
R-MPLS</td>
</tr>
<tr>
<td>5</td><td>(Type E) IPv4 Prefix with Local Interface ID</td>
</tr>
<tr>
<td>6</td><td>(Type F) IPv4 Addresses for link endpoints as Local, Remote
pair</td>
</tr>
<tr>
<td>7</td><td>(Type G) IPv6 Prefix and Interface ID for link endpoints as
Local, Remote pair for SR-MPLS</td>
</tr>
<tr>
<td>8</td><td>(Type H) IPv6 Addresses for link endpoints as Local, Remote
pair for SR-MPLS</td>
</tr>
<tr>
<td>9</td><td>(Type I) IPv6 Global Prefix with optional SR Algorithm for S
Rv6</td>
</tr>
<tr>
<td>10</td><td>(Type J) IPv6 Prefix and Interface ID for link endpoints as
Local, Remote pair for SRv6</td>
</tr>
<tr>
<td>11</td><td>(Type K) IPv6 Addresses for link endpoints as Local, Remote
pair for SRv6</td>
</tr>
</tbody>
</table>
<section anchor="TYPE1" title="Type 1: SR-MPLS Label (Type A)"> <section anchor="TYPE1" numbered="true" toc="default">
<t>The Segment is SR-MPLS type and is specified simply as the <name>Type 1: Segment Type A</name>
label. The format of its Segment Descriptor is as <t>The Segment is an SR-MPLS type and is specified simply as the
follows:<figure align="center"> label. The format of its segment descriptor is as
<artwork align="left"><![CDATA[ 0 1 follows:</t>
2 3 <figure>
<name>Type 1 Segment Descriptor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Algorithm |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 20 Type 1 Segment Descriptor <t>Where:</t>
Where:
]]></artwork>
</figure></t>
<t><list style="symbols"> <dl spacing="normal" newline="false">
<t>Algorithm: 1-octet value that indicates the algorithm <dt>Algorithm:</dt><dd>1-octet value that indicates the
used for picking the SID. This is valid only when the A-flag algorithm used for picking the SID. This is valid only when
has been set in the Segment TLV. The algorithm values are the A-flag has been set in the Segment TLV. The algorithm
from IGP Algorithm Types registry under the IANA Interior values are from the "IGP Algorithm Types" IANA registry under th
Gateway Protocol (IGP) Parameters.</t> e
</list></t> "Interior Gateway Protocol (IGP) Parameters" registry group.</dd
>
</dl>
</section> </section>
<section anchor="TYPE2" numbered="true" toc="default">
<section anchor="TYPE2" title="Type 2: SRv6 SID (Type B)"> <name>Type 2: Segment Type B</name>
<t>The Segment is SRv6 type and is specified simply as the SRv6 <t>The Segment is an SRv6 type and is specified simply as SRv6
SID address. The format of its Segment Descriptor is as SID. The format of its segment descriptor is as
follows:<figure align="center"> follows:</t>
<artwork align="left"><![CDATA[ 0 1 <figure>
2 3 <name>Type 2 Segment Descriptor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Algorithm |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 21 Type 2 Segment Descriptor
Where:
]]></artwork>
</figure></t>
<t><list style="symbols"> <t>Where:</t>
<t>Algorithm: 1-octet value that indicates the algorithm <dl spacing="normal" newline="false">
used for picking the SID. This is valid only when the A-flag <dt>Algorithm:</dt><dd>1-octet value that indicates the
has been set in the Segment TLV. The algorithm values are algorithm used for picking the SID. This is valid only when
from IGP Algorithm Types registry under the IANA Interior the A-flag has been set in the Segment TLV. The algorithm
Gateway Protocol (IGP) Parameters.</t> values are from the "IGP Algorithm Types" IANA registry under th
</list></t> e
"Interior Gateway Protocol (IGP) Parameters" registry group.</dd
>
</dl>
</section> </section>
<section anchor="TYPE3" numbered="true" toc="default">
<section anchor="TYPE3" <name>Type 3: Segment Type C</name>
title="Type 3: SR-MPLS Prefix SID for IPv4 (Type C)"> <t>The Segment is an SR-MPLS Prefix SID type and is specified as a
<t>The Segment is SR-MPLS Prefix SID type and is specified as an n
IPv4 node address. The format of its Segment Descriptor is as IPv4 node address. The format of its segment descriptor is as
follows:<figure align="center"> follows:</t>
<artwork align="left"><![CDATA[ 0 1 <figure>
2 3 <name>Type 3 Segment Descriptor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) | | IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 22 Type 3 Segment Descriptor
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 <t>Where:</t>
address associated with the node</t> <dl spacing="normal" newline="false">
</list></t> <dt>Algorithm:</dt><dd>1-octet value that indicates the
algorithm used for picking the SID. The algorithm values are
from the "IGP Algorithm Types" IANA registry under the "Interior
Gateway Protocol (IGP) Parameters" registry group.</dd>
<dt>IPv4 Node Address:</dt><dd>4-octet value that carries the
IPv4 address associated with the node.</dd>
</dl>
</section> </section>
<section anchor="TYPE4" numbered="true" toc="default">
<section anchor="TYPE4" <name>Type 4: Segment Type D</name>
title="Type 4: SR-MPLS Prefix SID for IPv6 (Type D)"> <t>The Segment is an SR-MPLS Prefix SID type and is specified as a
<t>The Segment is SR-MPLS Prefix SID type and is specified as an n
IPv6 global address. The format of its Segment Descriptor is as IPv6 node global address. The format of its segment descriptor is
follows:<figure align="center"> as
<artwork align="left"><![CDATA[ 0 1 follows:</t>
2 3 <figure>
<name>Type 4 Segment Descriptor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Node Global Address (16 octets) | | IPv6 Node Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 23 Type 4 Segment Descriptor
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 <t>Where:</t>
the IPv6 global address associated with the node</t> <dl spacing="normal" newline="false">
</list></t> <dt>Algorithm:</dt><dd>1-octet value that indicates the
algorithm used for picking the SID. The algorithm values are
from the "IGP Algorithm Types" IANA registry under the "Interior
Gateway Protocol (IGP) Parameters" registry group.</dd>
<dt>IPv6 Node Global Address:</dt><dd>16-octet value that
carries the IPv6 global address associated with the node.</dd>
</dl>
</section> </section>
<section anchor="TYPE5" numbered="true" toc="default">
<section anchor="TYPE5" <name>Type 5: Segment Type E</name>
title="Type 5: SR-MPLS Adjacency SID for IPv4 with an Inter <t>The Segment is an SR-MPLS Adjacency SID type and is specified a
face ID (Type E)"> s
<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 an IPv4 node address along with the local interface ID on that
node. The format of its Segment Descriptor is as follows:<figure node. The format of its segment descriptor is as follows:</t>
align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>Type 5 Segment Descriptor</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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) | | IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 24 Type 5 Segment Descriptor <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>IPv4 Node Address:</dt><dd>4-octet value that carries the
]]></artwork> IPv4 address associated with the node.</dd>
</figure></t> <dt>Local Interface ID:</dt><dd>4-octet value that carries
the local interface ID of the node identified by the Node
<t><list style="symbols"> Address.</dd>
<t>IPv4 Node Address: 4-octet value which carries the IPv4 </dl>
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>
<section anchor="TYPE6" numbered="true" toc="default">
<name>Type 6: Segment Type F</name>
<t>The Segment is an SR-MPLS Adjacency SID type and is specified a
s
a pair of IPv4 local and remote interface addresses. The format of
its
segment descriptor is as follows:</t>
<figure>
<section anchor="TYPE6" <name>Type 6 Segment Descriptor</name>
title="Type 6: SR-MPLS Adjacency SID for IPv4 with an Inter <artwork align="left" name="" type="" alt=""><![CDATA[
face Address (Type F)"> 0 1 2 3
<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 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 Local Interface Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Remote Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Remote Interface Address (4 octets) |
Figure 25 Type 6 Segment Descriptor +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Where: <t>Where:</t>
]]></artwork> <dl spacing="normal" newline="false">
</figure></t> <dt>IPv4 Local Interface Address:</dt><dd>4-octet value that car
ries
<t><list style="symbols"> the local IPv4 address associated with the node's
<t>IPv4 Local Address: 4-octet value which carries the local interface.</dd>
IPv4 address associated with the node's interface</t> <dt>IPv4 Remote Interface Address:</dt><dd>4-octet value that ca
rries
<t>IPv4 Remote Address: 4-octet value which carries the the remote IPv4 address associated with the interface on the
remote IPv4 address associated with interface on the node's node's neighbor. This is optional and <bcp14>MAY</bcp14> be
neighbor. This is optional and MAY be set to 0 when not used set to 0 when not used (e.g., when identifying point-to-point
(e.g. when identifying point-to-point links).</t> links).</dd>
</list></t> </dl>
</section> </section>
<section anchor="TYPE7" numbered="true" toc="default">
<section anchor="TYPE7" <name>Type 7: Segment Type G</name>
title="Type 7: SR-MPLS Adjacency SID for IPv6 with an inter <t>The Segment is an SR-MPLS Adjacency SID type and is specified a
face ID (Type G)"> s
<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 a pair of IPv6 global address and interface ID for local and
remote nodes. The format of its Segment Descriptor is as remote nodes. The format of its segment descriptor is as
follows:<figure align="center"> follows:</t>
<artwork align="left"><![CDATA[ 0 1 <figure>
2 3 <name>Type 7 Segment Descriptor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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) | | IPv6 Local Node Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node Interface ID (4 octets) | | Local Node Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Remote Node Global Address (16 octets) | | IPv6 Remote Node Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node Interface ID (4 octets) | | Remote Node Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 26 Type 7 Segment Descriptor <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>IPv6 Local Node Global Address:</dt><dd> 16-octet value
]]></artwork> that carries the IPv6 global address associated with the
</figure></t> local node.</dd>
<dt>Local Node Interface ID:</dt><dd>4-octet value that
<t><list style="symbols"> carries the interface ID of the local node identified by the
<t>IPv6 Local Node Global Address: 16-octet value which Local Node Address.</dd>
carries the IPv6 global address associated with the local <dt>IPv6 Remote Node Global Address:</dt><dd>16-octet value
node</t> that carries the IPv6 global address associated with the
remote node. This is optional and <bcp14>MAY</bcp14> be set to
<t>Local Node Interface ID : 4-octet value which carries the 0 when not used (e.g., when identifying point-to-point
interface ID of the local node identified by the Local Node links).</dd>
Address</t> <dt>Remote Node Interface ID:</dt><dd>4-octet value that
carries the interface ID of the remote node identified by the
<t>IPv6 Remote Node Global Address: 16-octet value which Remote Node Address. This is optional and <bcp14>MAY</bcp14>
carries the IPv6 global address associated with the remote be set to 0 when not used (e.g., when identifying
node. This is optional and MAY be set to 0 when not used point-to-point links).</dd>
(e.g. when identifying point-to-point links).</t> </dl>
<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>
<section anchor="TYPE8" numbered="true" toc="default">
<name>Type 8: Segment Type H</name>
<t>The Segment is an SR-MPLS Adjacency SID type and is specified a
s
a pair of IPv6 global addresses for local and remote interface
addresses. The format of its segment descriptor is as
follows:</t>
<figure>
<name>Type 8 Segment Descriptor</name>
<section anchor="TYPE8" <artwork align="left" name="" type="" alt=""><![CDATA[
title="Type 8: SR-MPLS Adjacency SID for IPv6 with an Inter 0 1 2 3
face Address (Type H)">
<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 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) | | IPv6 Local Interface Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Global IPv6 Remote Interface Address (16 octets) | | IPv6 Remote Interface Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 27 Type 8 Segment Descriptor <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>IPv6 Local Global Address:</dt><dd>16-octet value that carri
]]></artwork> es
</figure></t> the local IPv6 address associated with the node's
interface.</dd>
<t><list style="symbols"> <dt>IPv6 Remote Global Address:</dt><dd>16-octet value that carr
<t>IPv6 Local Address: 16-octet value which carries the ies
local IPv6 address associated with the node's interface</t> the remote IPv6 address associated with the interface on the
node's neighbor.</dd>
<t>IPv6 Remote Address: 16-octet value which carries the </dl>
remote IPv6 address associated with the interface on the
node's neighbor</t>
</list></t>
</section> </section>
<section anchor="TYPE9" numbered="true" toc="default">
<section anchor="TYPE9" <name>Type 9: Segment Type I</name>
title="Type 9: SRv6 END SID as IPv6 Node Address (Type I)"> <t>The Segment is an SRv6 END SID type and is specified as an IPv6
<t>The Segment is SRv6 END SID type and is specified as an IPv6 node global address. The format of its segment descriptor is as
global address. The format of its Segment Descriptor is as follows:</t>
follows:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>Type 9 Segment Descriptor</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Node Global Address (16 octets) | | IPv6 Node Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 28 Type 9 Segment Descriptor <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>Algorithm:</dt><dd>1-octet value that indicates the
]]></artwork> algorithm used for picking the SID. The algorithm values are
</figure></t> from the "IGP Algorithm Types" IANA registry under the "Interior
Gateway Protocol (IGP) Parameters" registry group.</dd>
<t><list style="symbols"> <dt>IPv6 Node Global Address:</dt><dd>16-octet value that
<t>Algorithm: 1-octet value that indicates the algorithm carries the IPv6 global address associated with the node.</dd>
used for picking the SID. The algorithm values are from IGP </dl>
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>
<section anchor="TYPE10" numbered="true" toc="default">
<section anchor="TYPE10" <name>Type 10: Segment Type J</name>
title="Type 10: SRv6 END.X SID as an Interface ID (Type J)" <t>The Segment is an SRv6 END.X SID type and is specified as a pai
> r
<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 of IPv6 global address and interface ID for local and remote
nodes. The format of its Segment Descriptor is as nodes. The format of its segment descriptor is as
follows:<figure align="center"> follows:</t>
<artwork align="left"><![CDATA[ 0 1 <figure>
2 3 <name>Type 10 Segment Descriptor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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) | | IPv6 Local Node Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node Interface ID (4 octets) | | Local Node Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Remote Node Global Address (16 octets) | | IPv6 Remote Node Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node Interface ID (4 octets) | | Remote Node Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 29 Type 10 Segment Descriptor <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>IPv6 Local Node Global Address:</dt><dd>16-octet value
]]></artwork> that carries the IPv6 global address associated with the
</figure></t> local node.</dd>
<dt>Local Node Interface ID:</dt><dd>4-octet value that
<t><list style="symbols"> carries the interface ID of the local node identified by the
<t>IPv6 Local Node Global Address: 16-octet value which Local Node Address.</dd>
carries the IPv6 global address associated with the local <dt>IPv6 Remote Node Global Address:</dt><dd>16-octet value
node</t> that carries the IPv6 global address associated with the
remote node. This is optional and <bcp14>MAY</bcp14> be set to
<t>Local Node Interface ID: 4-octet value which carries the 0 when not used (e.g., when identifying point-to-point
interface ID of the local node identified by the Local Node links).</dd>
Address</t> <dt>Remote Node Interface ID:</dt><dd>4-octet value that
carries the interface ID of the remote node identified by the
<t>IPv6 Remote Node Global Address: 16-octet value which Remote Node Address. This is optional and <bcp14>MAY</bcp14>
carries the IPv6 global address associated with the remote be set to 0 when not used (e.g., when identifying
node. This is optional and MAY be set to 0 when not used point-to-point links).</dd>
(e.g. when identifying point-to-point links).</t> </dl>
<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>
<section anchor="TYPE11" numbered="true" toc="default">
<section anchor="TYPE11" <name>Type 11: Segment Type K</name>
title="Type 11: SRv6 END.X SID as an Interface Address (Typ <t>The Segment is an SRv6 END.X SID type and is specified as a pai
e K)"> r
<t>The Segment is SRv6 END.X SID type and is specified as a pair of IPv6 global addresses for local and remote interface
of IPv6 Global addresses for local and remote interface addresses. The format of its segment descriptor is as
addresses. The format of its Segment Descriptor is as follows:</t>
follows:<figure align="center"> <figure>
<artwork align="left"><![CDATA[ 0 1 <name>Type 11 Segment Descriptor</name>
2 3 <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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) | | IPv6 Local Interface Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Global IPv6 Remote Interface Address (16 octets) | | IPv6 Remote Interface Global Address (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 30 Type 11 Segment Descriptor <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>IPv6 Local Global Address:</dt><dd>16-octet value that carri
]]></artwork> es
</figure></t> the local IPv6 address associated with the node's
interface.</dd>
<t><list style="symbols"> <dt>IPv6 Remote Global Address:</dt><dd>16-octet value that carr
<t>IPv6 Local Address: 16-octet value which carries the ies
local IPv6 address associated with the node's interface</t> the remote IPv6 address associated with the interface on the
node's neighbor.</dd>
<t>IPv6 Remote Address: 16-octet value which carries the </dl>
remote IPv6 address associated with the interface on the
node's neighbor</t>
</list></t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="SLMETRIC" numbered="true" toc="default">
<section anchor="SLMETRIC" title="SR Segment List Metric Sub-TLV"> <name>SR Segment List Metric Sub-TLV</name>
<t>The SR Segment List Metric sub-TLV reports the computed metric of <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 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 its computed value by the computation entity (i.e., either the
headend or the controller when the path is delegated) when headend or the controller when the path is delegated) when
available. More than one instance of this sub-TLV may be present in 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 SR Segment List to report metric values of different metric types.
The metric margin and bound may be optionally reported using this The metric margin and bound may be optionally reported using this
sub-TLV when this information is not being reported using the SR sub-TLV when this information is not being reported using the SR
Metric Constraint sub-TLV (refer to <xref target="CPMETRIC"/>) at Metric Constraint sub-TLV (refer to <xref target="CPMETRIC" format="de
the SR candidate path level.</t> fault"/>) at
the SR Policy candidate path level.</t>
<t>It is a sub-TLV of the SR Segment List TLV and has the following <t>It is a sub-TLV of the SR Segment List TLV and has the following
format: <figure align="center"> format: </t>
<artwork align="left"><![CDATA[ <figure>
<name>SR Segment List Metric Sub-TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Type | Flags | RESERVED | | Metric Type | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Margin | | Metric Margin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Bound | | Metric Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Value | | Metric Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 31 SR Segment List Metric Sub-TLV Format <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>Type:</dt><dd>1207</dd>
]]></artwork> <dt>Length:</dt><dd>16 octets</dd>
</figure><list style="symbols"> <dt>Metric Type:</dt><dd>1-octet field that identifies the type
<t>Type: 1207</t> of metric. The semantics are the same as the metric type field in
the SR Metric Constraint sub-TLV in <xref target="CPMETRIC"
<t>Length: 16 octets</t> format="default"/> of this document.</dd>
<dt>Flags:</dt><dd><t>1-octet field that indicates the validity of t
<t>Metric Type: 1-octet field which identifies the type of he
metric. The semantics are the same as the Metric Type field in
the SR Metric Constraints sub-TLV in <xref target="CPMETRIC"/>
of this document.</t>
<t>Flags: 1-octet field that indicates the validity of the
metric fields and their semantics. The following bit positions metric fields and their semantics. The following bit positions
are defined and the other bits MUST be cleared by the originator are defined, and the other bits <bcp14>MUST</bcp14> be cleared by
and MUST be ignored by a receiver.<figure> the originator
<artwork><![CDATA[ and <bcp14>MUST</bcp14> be ignored by a receiver.</t>
0 1 2 3 4 5 6 7 <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7
|M|A|B|V| | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |M|A|B|V| |
+-+-+-+-+-+-+-+-+]]></artwork>
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, depending on the A-flag, as either an absolute value
or as a percentage of the best computed path metric based on the
specified constraints for path calculation. The metric margin
allows for the metric value of the computed path to vary
(depending on the semantics of the specific metric type) from
the best metric value possible to optimize for other factors
(that are not specified as constraints) 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 worst metric
value (depending on the semantics of the specific metric type)
that is allowed when the B-flag is set. If the computed path
metric crosses the specified bound value 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>
<t>Where:</t>
<dl spacing="normal" newline="false">
<dt>M-Flag:</dt><dd>Indicates that the metric margin allowed
for this path computation is specified when set and
that the metric margin allowed is not specified when clear.</dd>
<dt>A-Flag:</dt><dd>Indicates that the metric margin is
specified as an absolute value when set and that the metric marg
in is expressed as a
percentage of the minimum metric when clear.</dd>
<dt>B-Flag:</dt><dd>Indicates that the metric bound allowed
for the path is specified when set and that the metric
bound is not specified when clear.</dd>
<dt>V-Flag:</dt><dd>Indicates that the computed metric value
is being reported when set and that the computed
metric value is not being reported when clear.</dd>
</dl>
</dd>
<dt>RESERVED:</dt><dd>2 octets. <bcp14>MUST</bcp14> be set to 0 by
the originator and <bcp14>MUST</bcp14> be ignored by a
receiver.</dd>
<dt>Metric Margin:</dt><dd>4-octet value that indicates the
metric margin value when the M-flag is set. The metric margin is
specified, depending on the A-flag, as either an absolute value or
a percentage of the best computed path metric based on the
specified constraints for path calculation. The metric margin
allows for the metric value of the computed path to vary
(depending on the semantics of the specific metric type) from the
best metric value possible to optimizing for other factors (that are
not specified as constraints) such as bandwidth availability,
minimal SID stack depth, and the maximizing of ECMP for the computed
SR path.</dd>
<dt>Metric Bound:</dt><dd>4-octet value that indicates the worst
metric value (depending on the semantics of the specific metric
type) that is allowed when the B-flag is set. If the computed path
metric crosses the specified bound value, then the path is
considered invalid.</dd>
<dt>Metric Value:</dt><dd>4-octet value that indicates the metric
of the computed path when the V-flag is set. This value is
available and reported when the computation is successful and a
valid path is available.</dd>
</dl>
<t>The absolute metric margin, metric bound, and metric values are <t>The absolute metric margin, metric bound, and metric values are
encoded as specified for each metric type. For metric types that are encoded as specified for each metric type. For metric types that are
smaller than 4 octets in size, the most significant bits are filled smaller than 4 octets in size, the most significant bits are filled
with zeros. The percentage metric margin is encoded as an unsigned with zeros. The percentage metric margin is encoded as an unsigned
integer percentage value.</t> integer percentage value.</t>
</section> </section>
<section anchor="SLBW" numbered="true" toc="default">
<section anchor="SLBW" title="SR Segment List Bandwidth Sub-TLV"> <name>SR Segment List Bandwidth Sub-TLV</name>
<t>The SR Segment List Bandwidth sub-TLV is an optional sub-TLV used <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 to report the bandwidth allocated to the specific SID list by the
path computation entity. Only a single instance of this sub-TLV is path computation entity. Only a single instance of this sub-TLV is
advertised for a given Segment List. If multiple instances are advertised for a given segment list. If multiple instances are
present, then the first valid (i.e., not determined to be malformed present, then the first valid one (i.e., not determined to be malforme
as per section 8.2.2 of <xref target="RFC9552"/>) one is used and d
as per <xref target="RFC9552" sectionFormat="of" section="8.2.2"/>) is
used and
the rest are ignored.</t> the rest are ignored.</t>
<t>It is a sub-TLV of the SR Segment List TLV and has the following <t>It is a sub-TLV of the SR Segment List TLV and has the following
format: <figure align="center"> format: </t>
<artwork align="left"><![CDATA[
<figure>
<name>SR Segment List Bandwidth Sub-TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth | | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 32 SR Segment List Bandwidth Sub-TLV Format <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>Type:</dt><dd>1216</dd>
]]></artwork> <dt>Length:</dt><dd>4 octets</dd>
</figure><list style="symbols"> <dt>Bandwidth:</dt><dd>4 octets that specify the allocated
<t>Type: 1216</t> bandwidth in unit of bytes per second in IEEE floating point
format <xref target="IEEE754" format="default"/>.</dd>
<t>Length: 4 octets</t> </dl>
<t>Bandwidth: 4 octets which specify the allocated bandwidth in
unit of bytes per second in IEEE floating point format <xref
target="IEEE754"/>.</t>
</list></t>
</section> </section>
<section anchor="SLID" numbered="true" toc="default">
<section anchor="SLID" title="SR Segment List Identifier Sub-TLV"> <name>SR Segment List Identifier Sub-TLV</name>
<t>The SR Segment List Identifier sub-TLV is an optional 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. used to report an identifier associated with the specific SID list.
Only a single instance of this sub-TLV is advertised for a given Only a single instance of this sub-TLV is advertised for a given
Segment List. If multiple instances are present, then the first segment list. If multiple instances are present, then the first
valid (i.e., not determined to be malformed as per section 8.2.2 of valid one (i.e., not determined to be malformed as per
<xref target="RFC9552"/>) one is used and the rest are ignored.</t> <xref target="RFC9552" sectionFormat="of" section="8.2.2"/>) is used a
nd the rest are ignored.</t>
<t>It is a sub-TLV of the SR Segment List TLV and has the following <t>It is a sub-TLV of the SR Segment List TLV and has the following
format: <figure align="center"> format: </t>
<artwork align="left"><![CDATA[ <figure>
<name>SR Segment List Identifier Sub-TLV Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List Identifier | | Segment List Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Figure 33 SR Segment List Identifier Sub-TLV Format <t>Where:</t>
<dl spacing="normal" newline="false">
Where: <dt>Type:</dt><dd>1217</dd>
]]></artwork> <dt>Length:</dt><dd>4 octets</dd>
</figure><list style="symbols"> <dt>Segment List Identifier:</dt><dd>4 octets that carry a 32-bit
<t>Type: 1217</t> unsigned non-zero integer that serves as the identifier associated
with the segment list. A value of 0 indicates that there is no
<t>Length: 4 octets</t> identifier associated with the segment list. The scope of this
identifier is the SR Policy candidate path.</dd>
<t>Segment List Identifier: 4 octets which carry a 32-bit </dl>
unsigned non-zero integer that serves as the identifier
associated with the segment list. A value of 0 indicates that
there is no identifier associated with the Segment List. The
scope of this identifier is the SR Policy Candidate path.</t>
</list></t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Procedures" numbered="true" toc="default">
<section anchor="Procedures" title="Procedures"> <name>Procedures</name>
<t>The BGP-LS advertisements for the SR Policy Candidate Path NLRI type <t>The BGP-LS advertisements for the SR Policy Candidate Path NLRI type
are generally originated by the headend node for the SR Policies that are 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 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 Producer). The BGP-LS Producer may also be a node (e.g., a PCE) that is
advertising on behalf of the headend.</t> advertising on behalf of the headend.</t>
<t>For the reporting of SR Policy candidate paths, the NLRI descriptor
<t>For the reporting of SR Policy Candidate Paths, the NLRI descriptor TLV as specified in <xref target="SRPOLICYCP" format="default"/> is used.
TLV as specified in <xref target="SRPOLICYCP"/> is used. An SR Policy An SR Policy
candidate path may be instantiated on the headend node via a local candidate path may be instantiated on the headend node via a local
configuration, PCEP, or BGP SR Policy signaling and this is indicated 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 via the SR Protocol-Origin. When a PCE node is the BGP-LS Producer, it
uses the "in PCEP" variants of the SR Protocol Origin (where available) uses the "in PCEP" variants of the SR Protocol-Origin (where available)
so as to distinguish them from advertisements by headend nodes. The SR 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 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 Attribute field as SR Policy State TLVs and sub-TLVs as described in
<xref target="SRPOLICYTLVS"/>. The SR Candidate Path State TLV as <xref target="SRPOLICYTLVS" format="default"/>. The SR Candidate Path Stat
defined in <xref target="CPSTATE"/> is included to report the state of e TLV as
the candidate path. The SR BSID TLV as defined in <xref defined in <xref target="CPSTATE" format="default"/> is included to report
target="CPBSID"/> or <xref target="CPBSIDSRV6"/> is included to report the state of
the candidate path. The SR BSID TLV as defined in Sections <xref target="C
PBSID" format="counter"/> and <xref target="CPBSIDSRV6" format="counter"/> is in
cluded to report
the BSID of the candidate path when one is either specified or allocated the BSID of the candidate path when one is either specified or allocated
by the headend. The constraints and the optimization metric for the SR by the headend. The constraints and the optimization metric for the SR
Policy Candidate Path are reported using the SR Candidate Path Policy candidate path are reported using the SR Candidate Path
Constraints TLV and its sub-TLVs as described in <xref Constraints TLV and its sub-TLVs as described in <xref target="CPCONSTRAIN
target="CPCONSTRAINTS"/>. The SR Segment List TLV is included for each TS" format="default"/>. The SR Segment List TLV is included for each SID list(s)
of the SID-List(s) associated with the candidate path. Each SR Segment associated with the candidate path. Each SR Segment
List TLV in turn includes SR Segment sub-TLV(s) to report the segment(s) List TLV in turn includes an 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> and its status. The SR Segment List Metric sub-TLV is used to report
the metric values at an individual SID list level.</t>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>Manageability Considerations</name>
<t>The Existing BGP operational and management procedures apply to this <t>The existing BGP operational and management procedures apply to this
document. No new procedures are defined in this document. The document. No new procedures are defined in this document. The
considerations as specified in <xref target="RFC9552"/> apply to this considerations as specified in <xref target="RFC9552" format="default"/> a pply to this
document.</t> document.</t>
<t>In general, the SR Policy headend nodes are responsible for the
<t>In general, the SR Policy head-end nodes are responsible for the
advertisement of SR Policy state information.</t> advertisement of SR Policy state information.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This section describes the code point allocation by IANA for this <t>This section describes the code point allocations by IANA for this
document.</t> document.</t>
<section anchor="NLRITYPES" numbered="true" toc="default">
<section anchor="NLRITYPES" title="BGP-LS NLRI-Types"> <name>BGP-LS NLRI Types</name>
<t>IANA maintains a registry called "BGP-LS NLRI-Types" in the "Border <t>IANA maintains a registry called "BGP-LS NLRI Types" under the "Borde
r
Gateway Protocol - Link State (BGP-LS) Parameters" registry group.</t> Gateway Protocol - Link State (BGP-LS) Parameters" registry group.</t>
<t>The following NLRI Type code point has been allocated
<t>The following table lists the code points that have been allocated
by IANA:</t> by IANA:</t>
<table>
<name>NLRI Type Code Point</name>
<thead><tr><th>Type</th><th>NLRI Type</th><th>Reference</th></tr></thea
d>
<tbody><tr><td>5</td><td>SR Policy Candidate Path NLRI</td><td>RFC 9857
</td></tr></tbody>
</table>
<t><figure>
<artwork><![CDATA[ +------+-------------------------------+---------
------+
| Type | NLRI Type | Reference |
+------+-------------------------------+---------------+
| 5 | SR Policy Candidate Path NLRI | this document |
+------+-------------------------------+---------------+
Table 2 NLRI Type Codepoint
]]></artwork>
</figure></t>
</section> </section>
<section anchor="PROTOCOLIDS" numbered="true" toc="default">
<section anchor="PROTOCOLIDS" title="BGP-LS Protocol-IDs"> <name>BGP-LS Protocol-IDs</name>
<t>IANA maintains a registry called "BGP-LS Protocol-IDs" in the <t>IANA maintains a registry called "BGP-LS Protocol-IDs" under the
"Border Gateway Protocol - Link State (BGP-LS) Parameters" registry "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry
group.</t> group.</t>
<t>The following Protocol-ID code point has been allocated by
<t>The following Protocol-ID codepoints have been allocated by
IANA:</t> IANA:</t>
<t><figure> <table>
<artwork><![CDATA[ +-------------+---------------------------------- <name>Protocol-ID Code Point</name>
+---------------+ <thead><tr><th>Protocol-ID</th><th>NLRI information source protocol</th
| Protocol-ID | NLRI information source protocol | Reference | ><th>Reference</th></tr></thead>
+-------------+----------------------------------+---------------+ <tbody><tr><td>9</td><td>Segment Routing</td><td>RFC 9857</td></tr></tb
| 9 | Segment Routing | this document | ody>
+-------------+----------------------------------+---------------+ </table>
Table 3 Protocol ID Codepoint
]]></artwork>
</figure></t>
</section> </section>
<section anchor="BGPLSTLVS" numbered="true" toc="default">
<section anchor="BGPLSTLVS" title="BGP-LS TLVs"> <name>BGP-LS TLVs</name>
<t>IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs" <t>IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs"
in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" under the "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group.</t> registry group.</t>
<t>The following table lists the TLV code points that have been <t>The following table lists the TLV code points that have been
allocated by IANA:</t> allocated by IANA:</t>
<table>
<t><figure> <name>NLRI and Attribute TLV Code Points</name>
<artwork><![CDATA[+-------+----------------------------------------+ <thead>
---------------+ <tr>
| Code | Description | Value defined | <th>TLV Code Point</th>
| Point | | in | <th>Description</th>
+-------+----------------------------------------+---------------+ <th>Reference</th>
| 554 | SR Policy Candidate Path Descriptor | this document | </tr>
| 1201 | SR Binding SID | this document | </thead>
| 1202 | SR Candidate Path State | this document | <tbody>
| 1203 | SR Candidate Path Name | this document | <tr>
| 1204 | SR Candidate Path Constraints | this document | <td>554</td><td>SR Policy Candidate Path Descriptor</td><td>RFC 9857</td>
| 1205 | SR Segment List | this document | </tr>
| 1206 | SR Segment | this document | <tr>
| 1207 | SR Segment List Metric | this document | <td>1201</td><td>SR Binding SID</td><td>RFC 9857</td>
| 1208 | SR Affinity Constraint | this document | </tr>
| 1209 | SR SRLG Constraint | this document | <tr>
| 1210 | SR Bandwidth Constraint | this document | <td>1202</td><td>SR Candidate Path State</td><td>RFC 9857</td>
| 1211 | SR Disjoint Group Constraint | this document | </tr>
| 1212 | SRv6 Binding SID | this document | <tr>
| 1213 | SR Policy Name | this document | <td>1203</td><td>SR Candidate Path Name</td><td>RFC 9857</td>
| 1214 | SR Bidirectional Group Constraint | this document | </tr>
| 1215 | SR Metric Constraint | this document | <tr>
| 1216 | SR Segment List Bandwidth | this document | <td>1204</td><td>SR Candidate Path Constraints</td><td>RFC 9857</td>
| 1217 | SR Segment List Identifier | this document | </tr>
+-------+----------------------------------------+---------------+ <tr>
<td>1205</td><td>SR Segment List</td><td>RFC 9857</td>
Table 4 NLRI and Attribute TLVs Codepoint </tr>
]]></artwork> <tr>
</figure></t> <td>1206</td><td>SR Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>1207</td><td>SR Segment List Metric</td><td>RFC 9857</td>
</tr>
<tr>
<td>1208</td><td>SR Affinity Constraint</td><td>RFC 9857</td>
</tr>
<tr>
<td>1209</td><td>SR SRLG Constraint</td><td>RFC 9857</td>
</tr>
<tr>
<td>1210</td><td>SR Bandwidth Constraint</td><td>RFC 9857</td>
</tr>
<tr>
<td>1211</td><td>SR Disjoint Group Constraint</td><td>RFC 9857</td>
</tr>
<tr>
<td>1212</td><td>SRv6 Binding SID</td><td>RFC 9857</td>
</tr>
<tr>
<td>1213</td><td>SR Policy Name</td><td>RFC 9857</td>
</tr>
<tr>
<td>1214</td><td>SR Bidirectional Group Constraint</td><td>RFC 9857</td>
</tr>
<tr>
<td>1215</td><td>SR Metric Constraint</td><td>RFC 9857</td>
</tr>
<tr>
<td>1216</td><td>SR Segment List Bandwidth</td><td>RFC 9857</td>
</tr>
<tr>
<td>1217</td><td>SR Segment List Identifier</td><td>RFC 9857</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="PROTOCOLORIGINS" numbered="true" toc="default">
<name>SR Policy Protocol-Origin</name>
<section anchor="PROTOCOLORIGINS" title="SR Policy Protocol Origin"> <!-- [rfced] Section 4 of this document as well as RFC 9256 uses
<t>Note to IANA (RFC editor to remove this before publication): The "Protocol-Origin" rather than "Protocol Origin". Are any updates
new registry creation request below is also present in the needed to the "SR Policy Protocol Origin" registry name, two
draft-ietf-pce-segment-routing-policy-cp. IANA is requested to process instances of "SR Protocol Origin", or "Protocol Origin field"?
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 Original:
"Segment Routing" registry group with the allocation policy of "Expert Per this document, IANA has created and maintains a new registry
Review" <xref target="RFC8126"/> using the guidelines for Designated called "SR Policy Protocol Origin" under the "Segment Routing"
Experts as specified in <xref target="RFC9256"/>. The new registry is registry group with the allocation policy of Expert Review [RFC8126]
called "SR Policy Protocol Origin" and should have the reference to using the guidelines for designated experts as specified in
this document. This registry contains the codepoints allocated to the [RFC9256]. This registry contains the code points allocated to the
"Protocol Origin" field defined in <xref target="SRPOLICYCP"/>.</t> "Protocol Origin" field defined in Section 4.
<t>The registry contains the following codepoints, with initial [RFC-EDITOR] Updates to IANA needed
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.) | |
| 4-9 | Unassigned | this document |
| 10 | PCEP (In PCEP or when | this document |
| | BGP-LS Producer is PCE) | |
| 11-19 | Unassigned | this document |
| 20 | BGP SR Policy (In PCEP or when | this document |
| | BGP-LS Producer is PCE) | |
| 21-29 | Unassigned | this document |
| 30 | Configuration (CLI, YANG model via | this document |
| | NETCONF, etc.) (In PCEP or when | |
| | BGP-LS Producer is PCE) | |
| 31-250 | Unassigned | this document |
| 251-255 | Private Use (not to be assigned by | this document |
| | IANA) | |
+---------+--------------------------------------+---------------+
Table 5 SR Policy Protocol Origin Codepoint <t>Per this document, IANA has created and maintains a new registry call
]]></artwork> ed "SR Policy Protocol-Origin" under
</figure></t> the "Segment Routing" registry group with the allocation policy of Exper
</section> t
Review <xref target="RFC8126" format="default"/> using the guidelines fo
r designated
experts as specified in <xref target="RFC9256" format="default"/>. This
registry contains the code points allocated to the
"Protocol-Origin" field defined in <xref target="SRPOLICYCP" format="def
ault"/>.</t>
<t>IANA has assigned the initial values as follows:</t>
<table>
<name>SR Policy Protocol-Origin Code Points</name>
<thead>
<tr>
<th>Code Point</th>
<th>Protocol-Origin</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td><td>Reserved</td><td>RFC 9857</td>
</tr>
<tr>
<td>1</td><td>PCEP</td><td>RFC 9857</td>
</tr>
<tr>
<td>2</td><td>BGP SR Policy</td><td>RFC 9857</td>
</tr>
<tr>
<td>3</td><td>Configuration (CLI, YANG model via NETCONF, etc.)</td><td>RF
C 9857</td>
</tr>
<tr>
<td>4-9</td><td>Unassigned</td><td>RFC 9857</td>
</tr>
<tr>
<td>10</td><td>PCEP (in PCEP or when BGP-LS Producer is PCE)</td><td>RFC 9
857</td>
</tr>
<tr>
<td>11-19</td><td>Unassigned</td><td>RFC 9857</td>
</tr>
<tr>
<td>20</td><td>BGP SR Policy (in PCEP or when BGP-LS Producer is PCE)</td>
<td>RFC 9857</td>
</tr>
<tr>
<td>21-29</td><td>Unassigned</td><td>RFC 9857</td>
</tr>
<tr>
<td>30</td><td>Configuration (CLI, YANG model via NETCONF, etc. In PCEP or
when BGP-LS Producer is PCE)</td><td>RFC 9857</td>
</tr>
<tr>
<td>31-250</td><td>Unassigned</td><td>RFC 9857</td>
</tr>
<tr>
<td>251-255</td><td>Reserved for Private Use</td><td>RFC 9857</td>
</tr>
</tbody>
</table>
<section anchor="SEGDESC" title="BGP-LS SR Segment Descriptors"> </section>
<t>This document requests IANA to create a registry called "SR Segment <section anchor="SEGDESC" numbered="true" toc="default">
<name>BGP-LS SR Segment Descriptors</name>
<t>Per this document, IANA has created a registry called "BGP-LS SR Segm
ent
Descriptor Types" under the "Border Gateway Protocol - Link State Descriptor Types" under the "Border Gateway Protocol - Link State
(BGP-LS) Parameters" registry group with the allocation policy of (BGP-LS) Parameters" registry group with the allocation policy of
"Expert Review" <xref target="RFC8126"/> using the guidelines for Expert Review <xref target="RFC8126" format="default"/> using the guidel
Designated Experts as specified in <xref target="RFC9552"/>. There is ines for
also an additional guideline to the Designated Experts to maintain the designated experts as specified in <xref target="RFC9552" format="defaul
t"/>. There is
also an additional guideline for the designated experts to maintain the
alignment between the allocations in this registry with those in the alignment between the allocations in this registry with those in the
"Segment Types" registry under the "Segment Routing" registry group. "Segment Types" registry under the "Segment Routing" registry group.
This requires that an allocation in the Segment Routing "Segment This requires that an allocation in the Segment Routing "Segment
Types" registry is required before allocation can be done in the Types" registry is required before allocation can be done in the
BGP-LS "SR Segment Descriptor Types" registry for a new segment type. "BGP-LS SR Segment Descriptor Types" registry for a new segment type.
However, this does not mandate that the specification of a new Segment However, this does not mandate that the specification of a new Segment
Routing Segment Type also requires the specification of its equivalent Routing Segment Type also requires the specification of its equivalent
SR Segment Descriptor Type in BGP-LS; that can be done as and when SR Segment Descriptor Type in BGP-LS; that can be done as and when
required while maintaining alignment.</t> required while maintaining alignment.</t>
<t>This registry contains the code points allocated to the "Segment
Type" field defined in <xref target="SEGMENTTLV" format="default"/> and
described in
<xref target="SEGMENTDESC" format="default"/>. IANA has assigned the ini
tial values as follows:</t>
<t>This registry contains the codepoints allocated to the "Segment <!--[rfced] Under the "Segment Descriptor" column in the "BGP-LS SR
Type" field defined in <xref target="SEGMENTTLV"/> and described in Segment Descriptor Types" registry, should the following changes
<xref target="SEGMENTDESC"/>. The registry contains the following be made to the code point descriptions? That is, add articles,
codepoints, with initial values, to be assigned by IANA with the make names following "pair" plural, and capitalize instances of
reference set to this document:<figure> "address" and "node", accordingly.
<artwork><![CDATA[+---------+---------------------------------------
+---------------+
| Code | Segment Description | Reference |
| Point | | |
+--------+----------------------------------------+---------------+
| 0 | Reserved (not to be used) | this document |
| 1 | (Type A) SR-MPLS Label | this document |
| 2 | (Type B) SRv6 SID as IPv6 address | this document |
| 3 | (Type C) SR-MPLS Prefix SID as | this document |
| | IPv4 Node Address | |
| 4 | (Type D) SR-MPLS Prefix SID as | this document |
| | IPv6 Node Global Address | |
| 5 | (Type E) SR-MPLS Adjacency SID as | this document |
| | IPv4 Node Address & Local Interface ID | |
| 6 | (Type F) SR-MPLS Adjacency SID as | this document |
| | IPv4 Local & Remote Interface Addresses| |
| 7 | (Type G) SR-MPLS Adjacency SID as pair | this document |
| | of IPv6 Global Address & Interface ID | |
| | for Local & Remote nodes | |
| 8 | (Type H) SR-MPLS Adjacency SID as pair | this document |
| | of IPv6 Global Addresses for the | |
| | Local & Remote Interface | |
| 9 | (Type I) SRv6 END SID as IPv6 Node | this document |
| | Global Address
| 10 | (Type J) SRv6 END.X SID as pair of | this document |
| | IPv6 Global Address & Interface ID for | |
| | Local & Remote nodes | |
| 11 | (Type K) SRv6 END.X SID as pair of | this document |
| | IPv6 Global Addresses for the | |
| | Local & Remote Interface | |
| 12-255 | Unassigned | this document |
+--------+----------------------------------------+---------------+
Table 6 SR Segment Descriptor Types Codepoint The form to the right of the arrow is suggested. If changes are made,
]]></artwork> we will update the running text accordingly (namely the subsections
</figure></t> under Section 5.7.1.1) as well as the IANA registry.
</section>
<section anchor="METRICTYPE" title="BGP-LS SR Policy Metric Type"> Link to registry:
<t>This document requests IANA to create a registry called "BGP-LS SR <https://www.iana.org/assignments/bgp-ls-parameters/
Policy Metric Type" under the "Border Gateway Protocol - Link State bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>
(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"/>. This
registry 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 | Reference |
+---------+--------------------------------+---------------------+
| 0 | IGP | this document |
| 1 | Min Unidirectional Delay | this document |
| 2 | TE | this document |
| 3 | Hop Count | this document |
| 4 | SID List Length | this document |
| 5 | Bandwidth | this document |
| 6 | Avg Unidirectional Delay | this document |
| 7 | Unidirectional Delay Variation | this document |
| 8 | Loss | this document |
| 9-127 | Unassigned | this document |
| 128-255 | User Defined | this document |
+---------+--------------------------------+---------------------+
Table 7 SR Policy Metric Type Codepoint (Type B) SRv6 SID as IPv6 address -> (Type B) SRv6 SID as an IPv6 Address
]]></artwork>
</figure></t> (Type C) SR-MPLS Prefix SID as IPv4 Node Address ->
(Type C) SR-MPLS Prefix SID as an IPv4 Node Address
(Type D) SR-MPLS Prefix SID as IPv6 Node Global Address ->
(Type D) SR-MPLS Prefix SID as an IPv6 Node Global Address
(Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local Interface ID ->
(Type E) SR-MPLS Adjacency SID as an IPv4 Node Address & a Local Interface
ID
(Note: Section 5.7.1.1.6 describes Type F as a "pair"; is that correct to add?)
(Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses ->
(Type F) SR-MPLS Adjacency SID as a pair of IPv4 Local & Remote
Interface Addresses
(Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface ID f
or
Local & Remote nodes ->
(Type G) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses &
Interface IDs for Local & Remote Nodes
(Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for the
Local & Remote Interface ->
(Type H) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses for
Local & Remote Interface Addresses
(Type I) SRv6 END SID as IPv6 Node Global Address ->
(Type I) SRv6 END SID as an IPv6 Node Global Address
(Type J) SRv6 END.X SID as pair of IPv6 Global Address & Interface ID
for Local & Remote nodes ->
(Type J) SRv6 END.X SID as a pair of IPv6 Global Addresses & Interface IDs
for Local & Remote Nodes
(Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for the Local &
Remote Interface ->
(Type K) SRv6 END.X SID as a pair of IPv6 Global Addresses for Local &
Remote Interface Addresses
-->
<table>
<name>BGP-LS SR Segment Descriptor Type Code Points</name>
<thead>
<tr>
<th>Code Point</th><th>Segment Descriptor</th><th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td><td>Reserved</td><td>RFC 9857</td>
</tr>
<tr>
<td>1</td><td>Type A Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>2</td><td>Type B Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>3</td><td>Type C Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>4</td><td>Type D Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>5</td><td>Type E Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>6</td><td>Type F Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>7</td><td>Type G Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>8</td><td>Type H Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>9</td><td>Type I Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>10</td><td>Type J Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>11</td><td>Type K Segment</td><td>RFC 9857</td>
</tr>
<tr>
<td>12-255</td><td>Unassigned</td><td>RFC 9857</td>
</tr>
</tbody>
</table>
<!-- Table 6 (original)
<table>
<name>BGP-LS SR Segment Descriptor Type Code Points</name>
<thead>
<tr>
<th>Code Point</th><th>Segment Descriptor</th><th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td><td>Reserved</td><td>RFC 9857</td>
</tr>
<tr>
<td>1</td><td>(Type A) SR-MPLS Label</td><td>RFC 9857</td>
</tr>
<tr>
<td>2</td><td>(Type B) SRv6 SID as IPv6 address</td><td>RFC 9857</td>
</tr>
<tr>
<td>3</td><td>(Type C) SR-MPLS Prefix SID as IPv4 Node Address</td><td>RFC 9
857</td>
</tr>
<tr>
<td>4</td><td>(Type D) SR-MPLS Prefix SID as IPv6 Node Global Address</td><t
d>RFC 9857</td>
</tr>
<tr>
<td>5</td><td>(Type E) SR-MPLS Adjacency SID as IPv4 Node Address &amp; Loca
l Interface ID</td><td>RFC 9857</td>
</tr>
<tr>
<td>6</td><td>(Type F) SR-MPLS Adjacency SID as IPv4 Local &amp; Remote Inte
rface Addresses</td><td>RFC 9857</td>
</tr>
<tr>
<td>7</td><td>(Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address
&amp; Interface ID for Local &amp; Remote nodes</td><td>RFC 9857</td>
</tr>
<tr>
<td>8</td><td>(Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresse
s for the Local &amp; Remote Interface</td><td>RFC 9857</td>
</tr>
<tr>
<td>9</td><td>(Type I) SRv6 END SID as IPv6 Node Global Address</td><td>RFC
9857</td>
</tr>
<tr>
<td>10</td><td>(Type J) SRv6 END.X SID as pair of IPv6 Global Address &amp;
Interface ID for Local &amp; Remote nodes</td><td>RFC 9857</td>
</tr>
<tr>
<td>11</td><td>(Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for
the Local &amp; Remote Interface</td><td>RFC 9857</td>
</tr>
<tr>
<td>12-255</td><td>Unassigned</td><td>RFC 9857</td>
</tr>
</tbody>
</table>
-->
</section>
<section anchor="METRICTYPE" numbered="true" toc="default">
<name>BGP-LS SR Policy Metric Type</name>
<t>Per this document, IANA has created a registry called "BGP-LS SR
Policy Metric Types" under the "Border Gateway Protocol - Link State
(BGP-LS) Parameters" registry group with the allocation policy of
Expert Review <xref target="RFC8126" format="default"/> using the guidel
ines for
designated experts as specified in <xref target="RFC9552" format="defaul
t"/>. This
registry contains the code points allocated to the metric type field
defined in <xref target="SLMETRIC" format="default"/>. IANA has assigned
the initial values as follows:</t>
<table>
<name>SR Policy Metric Type Code Point</name>
<thead>
<tr><th>Code Point</th><th>Metric Type</th><th>Reference</th></tr>
</thead>
<tbody>
<tr>
<td>0</td><td>IGP</td><td>RFC 9857</td>
</tr>
<tr>
<td>1</td><td>Min Unidirectional Delay</td><td>RFC 9857</td>
</tr>
<tr>
<td>2</td><td>TE</td><td>RFC 9857</td>
</tr>
<tr>
<td>3</td><td>Hop Count</td><td>RFC 9857</td>
</tr>
<tr>
<td>4</td><td>SID List Length</td><td>RFC 9857</td>
</tr>
<tr>
<td>5</td><td>Bandwidth</td><td>RFC 9857</td>
</tr>
<tr>
<td>6</td><td>Avg Unidirectional Delay</td><td>RFC 9857</td>
</tr>
<tr>
<td>7</td><td>Unidirectional Delay Variation</td><td>RFC 9857</td>
</tr>
<tr>
<td>8</td><td>Loss</td><td>RFC 9857</td>
</tr>
<tr>
<td>9-127</td><td>Unassigned</td><td>RFC 9857</td>
</tr>
<tr>
<td>128-255</td><td>User Defined</td><td>RFC 9857</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Procedures and protocol extensions defined in this document do not <t>Procedures and protocol extensions defined in this document do not
affect the base BGP security model. See <xref target="RFC6952"/> for affect the base BGP security model. See <xref target="RFC6952" format="def ault"/> for
details. The security considerations of the base BGP-LS specification as details. The security considerations of the base BGP-LS specification as
described in <xref target="RFC9552"/> also apply.</t> described in <xref target="RFC9552" format="default"/> also apply.</t>
<t>The BGP-LS SR Policy extensions specified in this document enable <t>The BGP-LS SR Policy extensions specified in this document enable
traffic engineering and service programming use-cases within an SR TE and service programming use cases within an SR
domain as described in <xref target="RFC9256"/>. SR operates within a domain as described in <xref target="RFC9256" format="default"/>. SR opera
trusted SR domain <xref target="RFC8402"/> and its security tes within a
trusted SR domain <xref target="RFC8402" format="default"/>, and its secur
ity
considerations also apply to BGP sessions when carrying SR Policy considerations also apply to BGP sessions when carrying SR Policy
information. The SR Policies advertised to controllers and other information. The SR Policies advertised to controllers and other
applications via BGP-LS are expected to be used entirely within this applications via BGP-LS are expected to be used entirely within this
trusted SR domain, i.e., within a single AS or between multiple trusted SR domain, i.e., within a single AS or between multiple
ASes/domains within a single provider network. Therefore, precaution is ASes/domains within a single provider network. Therefore, precaution is
necessary to ensure that the SR Policy information advertised via BGP necessary to ensure that the SR Policy information advertised via BGP
sessions is limited to nodes and/or controllers/applications in a secure sessions is limited to nodes and/or controllers/applications in a secure
manner within this trusted SR domain. The general guidance for BGP-LS 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 with respect to isolation of BGP-LS sessions from BGP sessions for other
address-families (refer security considerations of <xref address-families (refer to the security considerations of <xref target="RF
target="RFC9552"/>) may be used to ensure that the SR Policy information C9552" format="default"/>) may be used to ensure that the SR Policy information
is not advertised by accident or error to an EBGP peering session is not advertised to an External BGP (EBGP) peering session
outside the SR domain.</t> outside the SR domain by accident or error.</t>
<t>Additionally, it may be considered that the export of SR Policy <t>Additionally, it may be considered that the export of SR Policy
information, as described in this document, constitutes a risk to information, as described in this document, constitutes a risk to
confidentiality of mission-critical or commercially sensitive the confidentiality of mission-critical or commercially sensitive
information about the network (more specifically endpoint/node information about the network (more specifically, endpoint/node
addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not
automatic and require configuration. Thus, it is the responsibility of automatic and require configuration. Thus, it is the responsibility of
the network operator to ensure that only trusted nodes (that include the network operator to ensure that only trusted nodes (that include
both routers and controller applications) within the SR domain are both routers and controller applications) within the SR domain are
configured to receive such information.</t> configured to receive such information.</t>
</section> </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, Rajesh Melarcode Venkatesswaran, Lin
Changwang, Liu Yao, Joel Halpern, and Ned Smith 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. The authors would like to thank John Scudder for his AD review
and helpful suggestions to improve this document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.3630'?>
<?rfc include='reference.RFC.5329'?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.7471'?>
<?rfc include='reference.RFC.5440'?>
<?rfc include='reference.RFC.9552'?>
<?rfc include='reference.RFC.8402'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.I-D.ietf-lsr-flex-algo-bw-con'?>
<?rfc include='reference.RFC.8126'?>
<?rfc include='reference.RFC.5305'?>
<?rfc include='reference.RFC.8570'?>
<?rfc include='reference.RFC.8697'?>
<?rfc include='reference.RFC.8664'?>
<?rfc include='reference.RFC.9256'?>
<?rfc include='reference.RFC.9086'?>
<?rfc include='reference.RFC.9514'?> <displayreference target="I-D.ietf-idr-bgp-ls-te-path" to="BGP-LS-TE-PATH"/>
<?rfc include='reference.RFC.8986'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4655'?>
<?rfc include='reference.I-D.ietf-idr-sr-policy-safi'?>
<?rfc include='reference.I-D.ietf-idr-bgp-sr-segtypes-ext'?>
<?rfc include='reference.I-D.ietf-idr-bgp-ls-te-path'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
630.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
329.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
471.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<?rfc include='reference.RFC.2702'?> <!-- [RFC9843]
draft-ietf-lsr-flex-algo-bw-con-22 companion doc RFC-to-be 9843 in AUTH48 as
of 08/18/25.
-->
<?rfc include='reference.RFC.4202'?> <reference anchor="RFC9843" target="https://www.rfc-editor.org/info/rfc9843">
<front>
<title>IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints<
/title>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks Inc.</organization>
</author>
<author initials="W." surname="Britto" fullname="William Britto">
<organization>Juniper Networks Inc.</organization>
</author>
<author initials="R." surname="Shetty" fullname="Rajesh Shetty">
<organization>Juniper Networks Inc.</organization>
</author>
<author initials="B." surname="Decraene" fullname="Bruno Decraene">
<organization>Orange</organization>
</author>
<author initials="P." surname="Psenak" fullname="Peter Psenak">
<organization>Cisco Systems</organization>
</author>
<author initials="T." surname="Li" fullname="Tony Li">
<organization>Juniper Networks Inc.</organization>
</author>
<date month='September' year='2025'/>
</front>
<seriesInfo name="RFC" value="9843"/>
<seriesInfo name="DOI" value="10.17487/RFC9843"/>
</reference>
<?rfc include='reference.RFC.7308'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
570.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
697.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
514.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<?rfc include='reference.RFC.6952'?> <!-- [RFC9830] [I-D.ietf-idr-sr-Spolicy-safi]
draft-ietf-idr-sr-policy-safi-13
IESG State: in AUTH48-DONE (RFC 9830) as of 08/05/25 but is waiting for companio
n docs to finish EDIT->AUTH48 prior to PUB <https://www.rfc-editor.org/cluster_i
nfo.php?cid=C534>)
-->
<reference anchor="RFC9830" target="https://www.rfc-editor.org/info/rfc9830">
<front>
<title>Advertising Segment Routing Policies in BGP</title>
<author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization>Huawei Technologies</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Mattes" fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Jain" fullname="Dhanendra Jain">
<organization>Google</organization>
</author>
<date month="September" year="2025" />
</front>
<seriesInfo name="RFC" value="9830"/>
<seriesInfo name="DOI" value="10.17487/RFC9830"/>
</reference>
<?rfc include='reference.RFC.8231'?> <!-- [RFC 9831] [I-D.ietf-idr-bgp-sr-segtypes-ext]
draft-ietf-idr-bgp-sr-segtypes-ext-08
IESG State: in AUTH48-DONE (RFC 9831) as of 09/04/25
-->
<?rfc include='reference.RFC.5065'?> <reference anchor="RFC9831" target="https://www.rfc-editor.org/info/rfc9831">
<front>
<title>Segment Type Extensions for BGP Segment Routing (SR) Policy</title>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization>Huawei Technologies</organization>
</author>
<author initials="P." surname="Mattes" fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Jain" fullname="Dhanendra Jain">
<organization>Google</organization>
</author>
<date month="September" year="2025"/>
</front>
<seriesInfo name="RFC" value="9831"/>
<seriesInfo name="DOI" value="10.17487/RFC9831"/>
</reference>
<?rfc include='reference.RFC.8800'?> <!-- [I-D.ietf-idr-bgp-ls-te-path]
draft-ietf-idr-bgp-ls-te-path-02
IESG State: Expired as of 08/06/25.
-->
<reference anchor="I-D.ietf-idr-bgp-ls-te-path" target="https://datatracker.ietf
.org/doc/html/draft-ietf-idr-bgp-ls-te-path-02">
<front>
<title>Advertisement of Traffic Engineering Paths using BGP Link-State</ti
tle>
<author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization>Individual</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="J." surname="Dong" fullname="Jie Dong">
<organization>Huawei Technologies</organization>
</author>
<author initials="H." surname="Gredler" fullname="Hannes Gredler">
<organization>RtBrick Inc.</organization>
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<organization>Nvidia</organization>
</author>
<date month="November" day="11" year="2024" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-te-path-02" />
<reference anchor="IEEE754"> </reference>
<front>
<title>IEEE Standard for Floating-Point Arithmetic</title>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<organization>Institute of Electrical and Electronics 702.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
202.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
308.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
952.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
065.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
800.xml"/>
<!-- [IEEE754] -->
<reference anchor="IEEE754" target="https://ieeexplore.ieee.org/document
/8766229">
<front>
<title>IEEE Standard for Floating-Point Arithmetic</title>
<author>
<organization abbrev="IEEE">Institute of Electrical and Electronic
s
Engineers</organization> Engineers</organization>
</author> </author>
<date day="22" month="July" year="2019"/>
<date day="22" month="July" year="2019"/> </front>
</front> <seriesInfo name="IEEE Std" value="754-2019"/>
<seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/>
</reference>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Dhruv Dhody"/>,
<contact fullname="Mohammed Abdul Aziz Khalid"/>, <contact fullname="Lou
Berger"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Siva
Sivabalan"/>, <contact fullname="Arjun Sreekantiah"/>, <contact
fullname="Dhanendra Jain"/>, <contact fullname="Francois Clad"/>,
<contact fullname="Zafar Ali"/>, <contact fullname="Stephane
Litkowski"/>, <contact fullname="Aravind Babu Mahendra Babu"/>, <contact
fullname="Geetanjalli Bhalla"/>, <contact fullname="Ahmed Bashandy"/>,
<contact fullname="Mike Koldychev"/>, <contact fullname="Samuel
Sidor"/>, <contact fullname="Alex Tokar"/>, <contact fullname="Rajesh
Melarcode Venkatesswaran"/>, <contact fullname="Lin Changwang"/>,
<contact fullname="Liu Yao"/>, <contact fullname="Joel Halpern"/>, and
<contact fullname="Ned Smith"/> for their reviews and valuable
comments. The authors would also like to thank <contact fullname="Susan
Hares"/> for her shepherd review and helpful comments to
improve this document. The authors would like to thank <contact
fullname="John Scudder"/> for his AD review and helpful suggestions to
improve this document.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<seriesInfo name="IEEE" value="754-2019"/> <name>Contributors</name>
<t>The following people have contributed substantially to the content of
this document and should be considered coauthors:</t>
<seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/> <contact fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
<address>
<email>cfilsfil@cisco.com</email>
</address>
</contact>
<format target="https://ieeexplore.ieee.org/document/8766229" <contact fullname="Mach(Guoyi) Chen">
type="HTML"/> <organization>Huawei Technologies</organization>
</reference> <address>
</references> <email>mach.chen@huawei.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 346 change blocks. 
2113 lines changed or deleted 2464 lines changed or added

This html diff was produced by rfcdiff 1.48.