rfc9857.original		rfc9857.txt
	Inter-Domain Routing S. Previdi		Internet Engineering Task Force (IETF) S. Previdi
	Internet-Draft Individual		Request for Comments: 9857 Individual
	Intended status: Standards Track K. Talaulikar, Ed.		Category: Standards Track K. Talaulikar, Ed.
	Expires: 7 September 2025 Cisco Systems		ISSN: 2070-1721 Cisco Systems
	J. Dong		J. Dong
	Huawei Technologies		Huawei Technologies
	H. Gredler		H. Gredler
	RtBrick Inc.		RtBrick Inc.
	J. Tantsura		J. Tantsura
	Nvidia		Nvidia
	6 March 2025		September 2025
	Advertisement of Segment Routing Policies using BGP Link-State		Advertisement of Segment Routing Policies Using BGP - Link State
	draft-ietf-idr-bgp-ls-sr-policy-17
	Abstract		Abstract
	This document describes a mechanism to collect the Segment Routing		This document describes a mechanism used to collect Segment Routing
	Policy information that is locally available in a node and advertise		(SR) Policy information that is locally available in a node and
	it into BGP Link-State (BGP-LS) updates. Such information can be		advertise it into BGP - Link State (BGP-LS) updates. Such
	used by external components for path computation, re-optimization,		information can be used by external components for path computation,
	service placement, network visualization, etc.		reoptimization, service placement, network visualization, etc.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 7 September 2025.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9857.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Language
	2. Carrying SR Policy Information in BGP . . . . . . . . . . . . 5		2. Carrying SR Policy Information in BGP
	3. SR Policy Candidate Path NLRI Type . . . . . . . . . . . . . 6		3. SR Policy Candidate Path NLRI Type
	3.1. SR Policy Headend as BGP-LS Producer . . . . . . . . . . 7		3.1. SR Policy Headend as the BGP-LS Producer
	3.2. PCE as BGP-LS Producer . . . . . . . . . . . . . . . . . 8		3.2. PCE as the BGP-LS Producer
	4. SR Policy Candidate Path Descriptor . . . . . . . . . . . . . 8		4. SR Policy Candidate Path Descriptor
	5. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 10		5. SR Policy State TLVs
	5.1. SR Binding SID TLV . . . . . . . . . . . . . . . . . . . 10		5.1. SR Binding SID TLV
	5.2. SRv6 Binding SID TLV . . . . . . . . . . . . . . . . . . 13		5.2. SRv6 Binding SID TLV
	5.3. SR Candidate Path State TLV . . . . . . . . . . . . . . . 14		5.3. SR Candidate Path State TLV
	5.4. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 17		5.4. SR Policy Name TLV
	5.5. SR Candidate Path Name TLV . . . . . . . . . . . . . . . 17		5.5. SR Candidate Path Name TLV
	5.6. SR Candidate Path Constraints TLV . . . . . . . . . . . . 18		5.6. SR Candidate Path Constraints TLV
	5.6.1. SR Affinity Constraint Sub-TLV . . . . . . . . . . . 21		5.6.1. SR Affinity Constraint Sub-TLV
	5.6.2. SR SRLG Constraint Sub-TLV . . . . . . . . . . . . . 22		5.6.2. SR SRLG Constraint Sub-TLV
	5.6.3. SR Bandwidth Constraint Sub-TLV . . . . . . . . . . . 23		5.6.3. SR Bandwidth Constraint Sub-TLV
	5.6.4. SR Disjoint Group Constraint Sub-TLV . . . . . . . . 23		5.6.4. SR Disjoint Group Constraint Sub-TLV
	5.6.5. SR Bidirectional Group Constraint Sub-TLV . . . . . . 26		5.6.5. SR Bidirectional Group Constraint Sub-TLV
	5.6.6. SR Metric Constraint Sub-TLV . . . . . . . . . . . . 28		5.6.6. SR Metric Constraint Sub-TLV
	5.7. SR Segment List TLV . . . . . . . . . . . . . . . . . . . 31		5.7. SR Segment List TLV
	5.7.1. SR Segment Sub-TLV . . . . . . . . . . . . . . . . . 33		5.7.1. SR Segment Sub-TLV
	5.7.2. SR Segment List Metric Sub-TLV . . . . . . . . . . . 43		5.7.2. SR Segment List Metric Sub-TLV
	5.7.3. SR Segment List Bandwidth Sub-TLV . . . . . . . . . . 45		5.7.3. SR Segment List Bandwidth Sub-TLV
	5.7.4. SR Segment List Identifier Sub-TLV . . . . . . . . . 46		5.7.4. SR Segment List Identifier Sub-TLV
	6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 47		6. Procedures
	7. Manageability Considerations . . . . . . . . . . . . . . . . 47		7. Manageability Considerations
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		8. IANA Considerations
	8.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 48		8.1. BGP-LS NLRI Types
	8.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 48		8.2. BGP-LS Protocol-IDs
	8.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 48		8.3. BGP-LS TLVs
	8.4. SR Policy Protocol Origin . . . . . . . . . . . . . . . . 49		8.4. SR Policy Protocol-Origin
	8.5. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 50		8.5. BGP-LS SR Segment Descriptors
	8.6. BGP-LS SR Policy Metric Type . . . . . . . . . . . . . . 51		8.6. BGP-LS SR Policy Metric Type
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 52		9. Security Considerations
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53		10. References
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53		10.1. Normative References
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53		10.2. Informative References
	12.1. Normative References . . . . . . . . . . . . . . . . . . 53		Acknowledgements
	12.2. Informative References . . . . . . . . . . . . . . . . . 55		Contributors
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57		Authors' Addresses
	1. Introduction		1. Introduction
	SR Policy architecture details are specified in [RFC9256]. An SR		SR Policy architecture details are specified in [RFC9256]. An SR
	Policy comprises one or more candidate paths of which at a given time		Policy comprises one or more candidate paths of which at a given time
	one and only one may be active (i.e., installed in forwarding and		one and only one may be active (i.e., installed in forwarding and
	usable for steering of traffic). Each candidate path in turn may		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 be		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		active. When multiple SID lists are active, traffic is load balanced
	balanced over them. This document covers the advertisement of state		over them. This document covers the advertisement of state
	information at the individual SR Policy candidate path level.		information at the individual SR Policy candidate path level.
	SR Policies are generally instantiated at the head-end and are based		SR Policies are generally instantiated at the headend 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).		node using various APIs and protocols (e.g., the Path Computation
			Element Communication Protocol (PCEP) or BGP).
	In many network environments, the configuration, and state of each SR		In many network environments, the configuration and state of each SR
	Policy that is available in the network is required by controllers.		Policy that is available in the network is required by controllers.
	Such controllers, that are aware of both topology and SR Policy state		Such controllers, which are aware of both topology and SR Policy
	information, allow the network operator to optimize several functions		state information, allow the network operator to optimize several
	and operations in their networks.		functions and operations in their networks.
	One example of a controller is the stateful Path Computation Element		One example of a controller is the stateful Path Computation Element
	(PCE) [RFC8231], which could provide benefits in path optimization.		(PCE) [RFC8231], which can provide benefits in path optimization.
	While some extensions are proposed in the Path Computation Element		While some extensions are proposed in the PCEP for Path Computation
	Communication Protocol (PCEP) for the Path Computation Clients (PCCs)		Clients (PCCs) to report Label Switched Path (LSP) states to the PCE,
	to report the LSP states to the PCE, this mechanism may not be		this mechanism may not be applicable in a management-based PCE
	applicable in a management-based PCE architecture as specified in		architecture as specified in Section 5.5 of [RFC4655]. As
	section 5.5 of [RFC4655]. As illustrated in the figure below, the		illustrated in the figure below, the PCC is not a Label Switching
	PCC is not an LSR in the routing domain, thus the head-end nodes of		Router (LSR) in the routing domain, thus the headend nodes of the SR
	the SR Policies may not implement the PCEP protocol. In this case, a		Policies may not implement the PCEP. In this case, a general
	general mechanism to collect the SR Policy states from the ingress		mechanism to collect the SR Policy states from the ingress Label Edge
	LERs is needed. This document proposes an SR Policy state collection		Routers (LERs) is needed. This document proposes an SR Policy state
	mechanism complementary to the mechanism defined in [RFC8231].		collection mechanism complementary to the mechanism defined in
			[RFC8231].
	-----------		-----------
	| ----- |		| ----- |
	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 |
	---------- ----------		---------- ----------
	Figure 1 Management-Based PCE Usage		Figure 1: Management-Based PCE Usage
	In networks with composite PCE nodes as specified in section 5.1 of		In networks with composite PCE nodes as specified in Section 5.1 of
	[RFC4655], PCE is implemented on several routers in the network, and		[RFC4655], PCE is implemented on several routers in the network, and
	the PCCs in the network can use the mechanism described in [RFC8231]		the PCCs in the network can use the mechanism described in [RFC8231]
	to report the SR Policy information to the PCE nodes. An external		to report the SR Policy information to the PCE nodes. An external
	component may also need to collect the SR Policy information from all		component may also need to collect the SR Policy information from all
	the PCEs in the network to obtain a global view of the state of all		the PCEs in the network to obtain a global view of the state of all
	SR Policy paths in the network.		SR Policy paths in the network.
	In multi-area or multi-AS scenarios, each area or AS can have a child		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 to collect the SR Policies in its domain. In addition, a parent
	PCE needs to collect SR Policy information from multiple child PCEs		PCE needs to collect SR Policy information from multiple child PCEs
	to obtain a global view of SR Policy paths inside and across the		to obtain a global view of SR Policy paths inside and across the
	domains involved.		domains involved.
	In another network scenario, a centralized controller is used for		In another network scenario, a centralized controller is used for
	service placement. Obtaining the SR Policy state information is		service placement. Obtaining the SR Policy state information is
	quite important for making appropriate service placement decisions		quite important for making appropriate service placement decisions
	with the purpose of both meeting the application's requirements and		with the purpose of both meeting the application's requirements and
	utilizing network resources efficiently.		utilizing network resources efficiently.
	The Network Management System (NMS) may need to provide global		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.		visualization function.
	BGP has been extended to distribute link-state and traffic		BGP has been extended to distribute link-state and Traffic
	engineering information to external components [RFC9552]. Using the		Engineering (TE) information to external components [RFC9552]. Using
	same protocol to collect SR Policy and state information is desirable		the same protocol to collect SR Policy and state information is
	for these external components since this avoids introducing multiple		desirable for these external components since this avoids introducing
	protocols for network topology information collection. This document		multiple protocols for network topology information collection. This
	describes a mechanism to distribute SR Policy information (both SR-		document describes a mechanism to distribute SR Policy information
	MPLS, and SRv6 [RFC8402]) to external components using BGP-LS and		(both SR-MPLS and SRv6 [RFC8402]) to external components using BGP-LS
	covers both explicit and dynamic candidate paths. The advertisements		and covers both explicit and dynamic candidate paths. The
	of composite candidate path is outside the scope of this document.		advertisements of a composite candidate path are outside the scope of
			this document.
	The BGP-LS Producer [RFC9552] that is originating the advertisement		The BGP-LS Producer [RFC9552] that is originating the advertisement
	of SR Policy information can be either:		of SR Policy information can be either:
	* a SR Policy headend node, or		* an SR Policy headend node or
	* a PCE which is receiving the SR Policy information from its PCCs		* a PCE that is receiving the SR Policy information from its PCCs
	(i.e., SR Policy headend nodes) via PCEP		(i.e., SR Policy headend nodes) via PCEP
	The extensions specified in this document complement the BGP SR		The extensions specified in this document complement the BGP SR
	Policy SAFI [I-D.ietf-idr-sr-policy-safi] and		Policy SAFI [RFC9830] [RFC9831] and are used to advertise SR Policies
	[I-D.ietf-idr-bgp-sr-segtypes-ext] that are used to advertise SR		from controllers to the headend routers using BGP by enabling the
	Policies from controllers to the headend routers using BGP by		reporting of the operational state of those SR Policies back from the
	enabling the reporting of the operational state of those SR Policies		headend to the controllers.
	back from the headend to the controllers.
	While this document focuses on SR Policies,		While this document focuses on SR Policies, [BGP-LS-TE-PATH]
	[I-D.ietf-idr-bgp-ls-te-path] introduces further extension to support		introduces further extensions to support other TE paths such as MPLS-
	other TE Paths such as MPLS-TE LSPs.		TE LSPs.
	The encodings specified in this document (specifically in Section 4		The encodings specified in this document (specifically in Sections 4
	and Section 5) make use of flags that convey various types of		and 5) make use of flags that convey various types of information of
	information of the SR Policy. The document uses the term "set" to		the SR Policy. The document uses the term "set" to indicate that the
	indicate that the value of a flag bit is 1 and the term "clear" when		value of a flag bit is 1 and the term "clear" when the value is 0.
	the value is 0.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Carrying SR Policy Information in BGP		2. Carrying SR Policy Information in BGP
	The "Link-State NLRI" defined in [RFC9552] is extended to carry the		The "Link-State Network Layer Reachability Information (NLRI)"
	SR Policy information. New TLVs carried in the BGP Link-State		defined in [RFC9552] is extended to carry the SR Policy information.
	Attribute defined in [RFC9552] are also defined to carry the		New TLVs carried in the BGP-LS Attribute defined in [RFC9552] are
	attributes of an SR Policy in the subsequent sections.		also defined to carry the attributes of an SR Policy in the
			subsequent sections.
	The format of "Link-State NLRI" is defined in [RFC9552] as follows:		The format of the Link-State NLRI is defined in [RFC9552] as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NLRI Type | Total NLRI Length |		| NLRI Type | Total NLRI Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Link-State NLRI (variable) //		// Link-State NLRI (variable) //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2 BGP-LS NLRI Format		Figure 2: BGP-LS NLRI Format
	An additional "NLRI Type" known as SR Policy Candidate Path NLRI		An additional NLRI Type known as "SR Policy Candidate Path NLRI"
	(value 5) is defined for the advertisement of SR Policy Information.		(value 5) is defined for the advertisement of SR Policy Information.
	This SR Policy Candidate Path NLRI is used to report the state		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.		underlying segment lists.
	3. SR Policy Candidate Path NLRI Type		3. SR Policy Candidate Path NLRI Type
	This document defines SR Policy Candidate Path NLRI Type with its		This document defines the SR Policy Candidate Path NLRI type with its
	format as shown in the following figure:		format as shown in the following figure:
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| 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 //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3 SR Policy Candidate Path NLRI Format		Figure 3: SR Policy Candidate Path NLRI Format
	Where:		Where:
	* Protocol-ID field specifies the component that owns the SR Policy		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		Routing" (value 9) is introduced by this document that MUST be
	used for advertisement of SR Policies.		used for the advertisement of SR Policies.
	* "Identifier" is an 8 octet value as defined in section 5.2 of		Identifier: An 8-octet value as defined in Section 5.2 of [RFC9552].
	[RFC9552].
	* "Local Node Descriptor" (TLV 256) [RFC9552] is used as specified		Local Node Descriptors (TLV 256): Defined in [RFC9552] and used as
	further in this section.		specified further in this section.
	* The SR Policy Candidate Path Descriptor TLV is specified in		SR Policy Candidate Path Descriptor TLV: Specified in Section 4.
	Section 4.
	The Local Node Descriptor TLV carries information that only		The Local Node Descriptors TLV carries information that only
	identifies the headend node of the SR Policy irrespective of whether		identifies the headend node of the SR Policy irrespective of whether
	the BGP-LS Producer is a headend or a PCE node.		the BGP-LS Producer is a headend or a PCE node.
	The Local Node Descriptor TLV MUST include at least one of the		The Local Node Descriptors TLV MUST include at least one of the
	following Node Descriptor TLVs:		following Node Descriptor TLVs:
	* IPv4 Router-ID of Local Node (TLV 1028) [RFC9552], which		* IPv4 Router-ID of Local Node (TLV 1028) [RFC9552], which
	identifies the headend node of the SR Policy as specified in		identifies the headend node of the SR Policy as specified in
	section 2.1 of [RFC9256].		Section 2.1 of [RFC9256].
	* IPv6 Router-ID of Local Node (TLV 1029) [RFC9552], which		* IPv6 Router-ID of Local Node (TLV 1029) [RFC9552], which
	identifies the headend node of the SR Policy as specified in		identifies the headend node of the SR Policy as specified in
	section 2.1 of [RFC9256].		Section 2.1 of [RFC9256].
	The following sub-sections describe the encoding of sub-TLVs within		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.		Producer.
	3.1. SR Policy Headend as BGP-LS Producer		3.1. SR Policy Headend as the BGP-LS Producer
	The Local Node Descriptor TLV MUST include the following Node		The Local Node Descriptors TLV MUST include the following Node
	Descriptor TLVs when the headend node is the BGP-LS Producer:		Descriptor TLVs when the headend node is the BGP-LS Producer:
	* BGP Router-ID (TLV 516) [RFC9086], which contains a valid BGP		* BGP Router-ID (TLV 516) [RFC9086], which contains a valid BGP
	Identifier of the headend node of the SR Policy.		Identifier of the headend node of the SR Policy.
	* Autonomous System Number (TLV 512) [RFC9552], which contains the		* Autonomous System (TLV 512) [RFC9552], which contains the
	ASN (or AS Confederation Identifier (ASN) [RFC5065], if		Autonomous System Number (ASN) (or AS Confederation Identifier
	confederations are used) of the headend node of the SR Policy.		[RFC5065], if confederations are used) of the headend node of the
			SR Policy.
	The Local Node Descriptor TLV MAY include the following Node		The Local Node Descriptors TLV MAY include the following Node
	Descriptor TLVs when the headend node is the BGP-LS Producer:		Descriptor TLVs when the headend node is the BGP-LS Producer:
	* BGP Confederation Member (TLV 517) [RFC9086], which contains the		* BGP Confederation Member (TLV 517) [RFC9086], which contains the
	ASN of the confederation member (i.e. Member-AS Number), if BGP		ASN of the confederation member (i.e., Member-AS Number); if BGP
	confederations are used, the headend node of the SR Policy.		confederations are used, it contains the headend node of the SR
			Policy.
	* Other Node Descriptors as defined in [RFC9552] to identify the		* Other Node Descriptors as defined in [RFC9552] to identify the
	headend node of the SR Policy. The determination of whether the		headend node of the SR Policy. The determination of whether the
	IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID		IGP Router-ID (TLV 515) contains a 4-octet OSPF Router-ID or a
	or a 6-octet ISO System-ID is to be done based on the length of		6-octet ISO System-ID is to be done based on the length of that
	that sub-TLV since the Protocol-ID in the NLRI is always going to		sub-TLV as the Protocol-ID in the NLRI is always going to be
	be "Segment Routing".		"Segment Routing".
	3.2. PCE as BGP-LS Producer		3.2. PCE as the BGP-LS Producer
	The PCE node MUST NOT include its identifiers in the Node Descriptor		The PCE node MUST NOT include its identifiers in the Node Descriptor
	TLV in the NLRI as the Node Descriptor TLV MUST only carry the		TLV in the NLRI as the Node Descriptor TLV MUST only carry the
	identifiers of the SR Policy headend.		identifiers of the SR Policy headend.
	The Local Node Descriptor TLV MAY include the following Node		The Local Node Descriptors TLV MAY include the following 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):		database):
	* BGP Router-ID (TLV 516) [RFC9086], which contains a valid BGP		* BGP Router-ID (TLV 516) [RFC9086], which contains a valid BGP
	Identifier of the headend node of the SR Policy.		Identifier of the headend node of the SR Policy.
	* Autonomous System Number (TLV 512) [RFC9552], which contains the		* Autonomous System (TLV 512) [RFC9552], which contains the ASN (or
	ASN (or AS Confederation Identifier (ASN) [RFC5065], if		AS Confederation Identifier [RFC5065], if confederations are used)
	confederations are used) of the headend node of the SR Policy.		of the headend node of the SR Policy.
	* BGP Confederation Member (TLV 517) [RFC9086], which contains the		* BGP Confederation Member (TLV 517) [RFC9086], which contains the
	ASN of the confederation member (i.e. Member-AS Number), if BGP		ASN of the confederation member (i.e., Member-AS Number); if BGP
	confederations are used, the headend node of the SR Policy.		confederations are used, it contains the headend node of the SR
			Policy.
	* Other Node Descriptors as defined in [RFC9552] to identify the		* Other Node Descriptors as defined in [RFC9552] to identify the
	headend node of the SR Policy. The determination of whether the		headend node of the SR Policy. The determination of whether the
	IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID		IGP Router-ID (TLV 515) contains a 4-octet OSPF Router-ID or a
	or a 6-octet ISO System-ID is to be done based on the length of		6-octet ISO System-ID is to be done based on the length of that
	that sub-TLV since the Protocol-ID in the NLRI is always going to		sub-TLV since the Protocol-ID in the NLRI is always going to be
	be "Segment Routing".		"Segment Routing".
	When a Path Computation Element (PCE) node is functioning as the BGP-		When a PCE node is functioning as the BGP-LS Producer on behalf of
	LS Producer on behalf of one or more headends, it MAY include its own		one or more headends, it MAY include its own BGP Router-ID (TLV 516),
	BGP Router-ID (TLV 516), Autonomous System Number (TLV 512), or BGP		Autonomous System (TLV 512), or BGP Confederation Member (TLV 517) in
	Confederation Member (TLV 517) in the BGP-LS Attribute.		the BGP-LS Attribute.
	4. SR Policy Candidate Path Descriptor		4. SR Policy Candidate Path Descriptor
	The SR Policy Candidate Path Descriptor TLV identifies a Segment		The SR Policy Candidate Path Descriptor TLV identifies an SR Policy
	Routing Policy candidate path as defined in [RFC9256]. It is a		candidate path as defined in [RFC9256]. It is a mandatory TLV for
	mandatory TLV for SR Policy Candidate Path NLRI type. The TLV has		the SR Policy Candidate Path NLRI type. The TLV has the following
	the following format:		format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4 SR Policy Candidate Path Descriptor Format		Figure 4: SR Policy Candidate Path Descriptor Format
	Where:		Where:
	* Type: 554		Type: 554
	* Length: variable (valid values are 24, 36 or 48 octets)		Length: Variable (valid values are 24, 36, or 48 octets)
	* Protocol-Origin: 1-octet field which identifies the protocol or		Protocol-Origin: 1-octet field that identifies the protocol or
	component which is responsible for the instantiation of this path		component that is responsible for the instantiation of this path
	as specified in section 2.3 of [RFC9256]. The protocol-origin		as specified in Section 2.3 of [RFC9256]. The protocol-origin
	codepoints to be used are listed in Section 8.4.		code points to be used are listed in Section 8.4.
	* Flags: 1-octet field with following bit positions defined. Other		Flags: 1-octet field with the following bit positions defined.
	bits MUST be cleared by the originator and MUST be ignored by a		Other bits MUST be cleared by the originator and MUST be ignored
	receiver.		by a receiver.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|E|O| |		|E|O| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Where:		Where:
	- E-Flag: Indicates the encoding of endpoint as IPv6 address when		E-Flag: Indicates the encoding of an endpoint as an IPv6 address
	set and IPv4 address when clear		when set and an IPv4 address when clear.
	- O-Flag: Indicates the encoding of originator address as IPv6		O-Flag: Indicates the encoding of the originator address as an
	address when set and IPv4 address when clear		IPv6 address when set and an IPv4 address when clear.
	* Reserved: 2 octets which MUST be set to 0 by the originator and		Reserved: 2 octets that MUST be set to 0 by the originator and MUST
	MUST be ignored by a receiver.		be ignored by a receiver.
	* Endpoint: 4 or 16 octets (as indicated by the flags) containing		Endpoint: 4 or 16 octets (as indicated by the flags) containing the
	the address of the endpoint of the SR Policy as specified in		address of the endpoint of the SR Policy as specified in
	section 2.1 of [RFC9256].		Section 2.1 of [RFC9256].
	* Color: 4 octets that indicate the color of the SR Policy as		Policy Color: 4 octets that indicate the color of the SR Policy as
	specified in section 2.1 of [RFC9256].		specified in Section 2.1 of [RFC9256].
	* Originator ASN: 4 octets to carry the 4-byte encoding of the ASN		Originator ASN: 4 octets to carry the 4-byte encoding of the ASN of
	of the originator. Refer to section 2.4 of [RFC9256] for details.		the originator. Refer to Section 2.4 of [RFC9256] for details.
	* Originator Address: 4 or 16 octets (as indicated by the flags) to		Originator Address: 4 or 16 octets (as indicated by the flags) to
	carry the address of the originator. Refer to section 2.4 of		carry the address of the originator. Refer to Section 2.4 of
	[RFC9256] for details.		[RFC9256] for details.
	* Discriminator: 4 octets to carry the discriminator of the path.		Discriminator: 4 octets to carry the discriminator of the path.
	Refer to section 2.5 of [RFC9256] for details.		Refer to Section 2.5 of [RFC9256] for details.
	5. SR Policy State TLVs		5. SR Policy State TLVs
	This section defines the various TLVs which enable the headend to		This section defines the various TLVs that enable the headend to
	report the state at the SR Policy candidate path level. These TLVs		report the state at the SR Policy candidate path level. These TLVs
	(and their sub-TLVs) are carried in the optional non-transitive BGP-		(and their sub-TLVs) are carried in the optional non-transitive BGP-
	LS Attribute defined in [RFC9552] associated with the SR Policy		LS Attribute defined in [RFC9552] and are associated with the SR
	Candidate Path NLRI type.		Policy Candidate Path NLRI type.
	The detailed procedures for the advertisement are described in		The detailed procedures for the advertisement are described in
	Section 6.		Section 6.
	5.1. SR Binding SID TLV		5.1. SR Binding SID TLV
	The SR Binding SID (BSID) is an optional TLV that is used to report		The SR Binding Segment Identifier (BSID) is an optional TLV that is
	the BSID and its attributes for the SR Policy candidate path. The		used to report the BSID and its attributes for the SR Policy
	TLV MAY also optionally contain the Specified BSID value for		candidate path. The TLV MAY also optionally contain the Specified
	reporting as described in section 6.2.3 of [RFC9256]. Only a single		BSID value for reporting as described in Section 6.2.3 of [RFC9256].
	instance of this TLV is advertised for a given candidate path. If		Only a single instance of this TLV is advertised for a given
	multiple instances are present, then the first valid (i.e., not		candidate path. If multiple instances are present, then the first
	determined to be malformed as per section 8.2.2 of [RFC9552]) one is		valid one (i.e., not determined to be malformed as per Section 8.2.2
	used and the rest are ignored.		of [RFC9552]) is used and the rest are ignored.
	The TLV has the following format:		The TLV has the following format:
	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) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5 SR Binding SID TLV Format		Figure 5: SR Binding SID TLV Format
	Where:		Where:
	* Type: 1201		Type: 1201
	* Length: variable (valid values are 12 or 36 octets)		Length: Variable (valid values are 12 or 36 octets)
	* BSID Flags: 2-octet field that indicates attribute and status of		BSID Flags: 2-octet field that indicates the attribute and status of
	the Binding SID (BSID) associated with this candidate path. The		the Binding SID (BSID) associated with this candidate path. The
	following bit positions are defined and the semantics are		following bit positions are defined, and the semantics are
	described in detail in section 6.2 of [RFC9256]. Other bits MUST		described in detail in Section 6.2 of [RFC9256]. Other bits MUST
	be cleared by the originator and MUST be ignored by a receiver.		be cleared by the originator and MUST be ignored by a receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|D|B|U|L|F| |		|D|B|U|L|F| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- D-Flag: Indicates the dataplane for the BSIDs and if they are		D-Flag: Indicates the data plane for the BSIDs and if a BSID is a
	16 octet SRv6 SID (when set) or are 4 octet SR/MPLS label value		16-octet SRv6 SID (when set) or 4-octet SR/MPLS label value
	(when clear).		(when clear).
	- B-Flag: Indicates the allocation of the value in the BSID field		B-Flag: Indicates the allocation of the value in the BSID field
	when set and indicates that BSID is not allocated when clear.		when set and that BSID is not allocated when clear.
	- U-Flag: Indicates the specified BSID value is unavailable when		U-Flag: Indicates that the specified BSID value is unavailable
	set. When clear it indicates that this candidate path is using		when set. When clear, it indicates that this candidate path is
	the specified BSID. This flag is ignored when there is no		using the specified BSID. This flag is ignored when there is
	specified BSID.		no specified BSID.
	- L-Flag: Indicates the BSID value is from the Segment Routing		L-Flag: Indicates that the BSID value is from the Segment Routing
	Local Block (SRLB) of the headend node when set and is from the		Local Block (SRLB) of the headend node when set and from the
	local dynamic label pool when clear.		local dynamic label pool when clear.
	- F-Flag: Indicates the BSID value is one allocated from dynamic		F-Flag: Indicates that the BSID value is one allocated from a
	label pool due to fallback (e.g. when specified BSID is		dynamic label pool due to fallback (e.g., when a specified BSID
	unavailable) when set and indicates that there has been no		is unavailable) when set and that there has been no fallback
	fallback for BSID allocation when clear.		for BSID allocation when clear.
	* RESERVED: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* Binding SID: It indicates the operational or allocated BSID value		Binding SID: Indicates the operational or allocated BSID value based
	based on the status flags.		on the status flags.
	* Specified BSID: It is used to report the explicitly specified BSID		Specified BSID: Used to report the explicitly specified BSID value
	value regardless of whether it is successfully allocated or not.		regardless of whether it is successfully allocated or not. The
	The field is set to value 0 when BSID has not been specified.		field is set to value 0 when the BSID has not been specified.
	The BSID fields above depend on the dataplane (SRv6 or MPLS)		The BSID fields above depend on the data plane (SRv6 or MPLS)
	indicated by the D-Flag. If D-Flag set (SRv6 dataplane), then the		indicated by the D-flag. If the D-flag is set (SRv6 data plane),
	length of the BSID fields is 16 octets. If the D-Flag is clear (MPLS		then the length of the BSID fields is 16 octets. If the D-flag is
	dataplane), then the length of the BSID fields is 4 octets. When		clear (MPLS data plane), then the length of the BSID fields is 4
	carrying the MPLS Label, as shown in the figure below, the TC, S, and		octets. When carrying the MPLS Label, as shown in the figure below,
	TTL (total of 12 bits) are RESERVED and MUST be set to 0 by the		the TC, S, and TTL (total of 12 bits) are RESERVED and MUST be set to
	originator and MUST be ignored by a receiver.		0 by the originator and MUST be ignored by a receiver.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6 SR Binding SID Label Format		Figure 6: SR Binding SID Label Format
	In the case of an SRv6, the SR Binding SID sub-TLV does not have the		In the case of an SRv6, the SR Binding SID sub-TLV does not have the
	ability to signal the SRv6 Endpoint Behavior [RFC8986] or the		ability to signal the SRv6 Endpoint behavior [RFC8986] or the
	structure of the SID. Therefore, the SR Binding SID sub-TLV SHOULD		structure of the SID. Therefore, the SR Binding SID sub-TLV SHOULD
	NOT be used for the advertisement of an SRv6 Binding SID. Instead,		NOT be used for the advertisement of an SRv6 Binding SID. Instead,
	the SRv6 Binding SID TLV defined in Section 5.2 SHOULD be used for		the SRv6 Binding SID TLV defined in Section 5.2 SHOULD be used for
	signaling of an SRv6 Binding SID. The use of the SR Binding SID sub-		the signaling of an SRv6 Binding SID. The use of the SR Binding SID
	TLV for advertisement of the SRv6 Binding SID has been deprecated,		sub-TLV for advertisement of the SRv6 Binding SID has been
	and is documented here only for backward compatibility with		deprecated, and it is documented here only for backward compatibility
	implementations that followed early versions of this specification.		with implementations that followed early draft versions of this
			specification.
	5.2. SRv6 Binding SID TLV		5.2. SRv6 Binding SID TLV
	The SRv6 Binding SID (BSID) is an optional TLV that is used to report		The SRv6 Binding SID (BSID) is an optional TLV that is used to report
	the SRv6 BSID and its attributes for the SR Policy candidate path.		the SRv6 BSID and its attributes for the SR Policy candidate path.
	The TLV MAY also optionally contain the Specified SRv6 BSID value for		The TLV MAY also optionally contain the Specified SRv6 BSID value for
	reporting as described in section 6.2.3 of [RFC9256]. Multiple		reporting as described in Section 6.2.3 of [RFC9256]. Multiple
	instances of this TLV may be used to report each of the SRv6 BSIDs		instances of this TLV may be used to report each of the SRv6 BSIDs
	associated with the candidate path.		associated with the candidate path.
	The TLV has the following format:		The TLV has the following format:
	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) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7 SRv6 Binding SID TLV Format		Figure 7: SRv6 Binding SID TLV Format
	Where:		Where:
	* Type: 1212		Type: 1212
	* Length: variable		Length: Variable
	* BSID Flags: 2-octet field that indicates attribute and status of		BSID Flags: 2-octet field that indicates the attribute and status of
	the Binding SID (BSID) associated with this candidate path. The		the BSID associated with this candidate path. The following bit
	following bit positions are defined and the semantics are		positions are defined, and the semantics are described in detail
	described in detail in section 6.2 of [RFC9256]. Other bits MUST		in Section 6.2 of [RFC9256]. Other bits MUST be cleared by the
	be cleared by the originator and MUST be ignored by a receiver.		originator and MUST be ignored by a receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|B|U|F| |		|B|U|F| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- B-Flag: Indicates the allocation of the value in the BSID field		B-Flag: Indicates the allocation of the value in the BSID field
	when set and indicates that BSID is not allocated when clear.		when set and that BSID is not allocated when clear.
	- U-Flag: Indicates the specified BSID value is unavailable when		U-Flag: Indicates the specified BSID value is unavailable when
	set. When clear it indicates that this candidate path is using		set. When clear, it indicates that this candidate path is
	the specified BSID. This flag is ignored when there is no		using the specified BSID. This flag is ignored when there is
	specified BSID.		no specified BSID.
	- F-Flag: Indicates the BSID value is one allocated dynamically		F-Flag: Indicates that the BSID value is one allocated
	due to fallback (e.g. when specified BSID is unavailable) when		dynamically due to fallback (e.g., when the specified BSID is
	set and indicates that there has been no fallback for BSID		unavailable) when set and that there has been no fallback for
	allocation when clear.		BSID allocation when clear.
	* RESERVED: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* Binding SID: It indicates the operational or allocated BSID value		Binding SID: Indicates the operational or allocated BSID value based
	based on the status flags.		on the status flags.
	* Specified BSID: It is used to report the explicitly specified BSID		Specified BSID: Used to report the explicitly specified BSID value
	value regardless of whether it is successfully allocated or not.		regardless of whether it is successfully allocated or not. The
	The field is set to value 0 when BSID has not been specified.		field is set to value 0 when the BSID has not been specified.
	* Sub-TLVs: variable and contains any other optional attributes		Sub-TLVs: Variable and contain any other optional attributes
	associated with the SRv6 BSID.		associated with the SRv6 BSID.
	The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure TLV		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) MAY optionally be used as sub-TLVs of the SRv6 Binding SID TLV
	to indicate the SRv6 Endpoint behavior and SID structure for the		to indicate the SRv6 Endpoint behavior and SID structure for the
	Binding SID value in the TLV. [RFC9514] defines SRv6 Endpoint		Binding SID value in the TLV. [RFC9514] defines the SRv6 Endpoint
	Behavior TLV And SRv6 SID Structure TLV.		Behavior TLV and the SRv6 SID Structure TLV.
	5.3. SR Candidate Path State TLV		5.3. SR Candidate Path State TLV
	The SR Candidate Path State TLV provides the operational status and		The SR Candidate Path State TLV provides the operational status and
	attributes of the SR Policy at the candidate path level. Only a		attributes of the SR Policy at the candidate path level. 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.,
	determined to be malformed as per section 8.2.2 of [RFC9552]) one is		not determined to be malformed as per Section 8.2.2 of [RFC9552]) is
	used and the rest are ignored.		used and the rest are ignored.
	The TLV has the following format:		The TLV has the following format:
	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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8 SR Candidate Path State TLV Format		Figure 8: SR Candidate Path State TLV Format
	Where:		Where:
	* Type: 1202		Type: 1202
	* Length: 8 octets		Length: 8 octets
	* Priority: 1-octet value which indicates the priority of the		Priority: 1-octet value that indicates the priority of the candidate
	candidate path. Refer Section 2.12 of [RFC9256].		path. Refer to Section 2.12 of [RFC9256].
	* RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be		RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be
	ignored by a receiver.		ignored by a receiver.
	* Flags: 2-octet field that indicates attribute and status of the		Flags: 2-octet field that indicates the attribute and status of the
	candidate path. The following bit positions are defined and the		candidate path. The following bit positions are defined, and the
	semantics are described in section 5 of [RFC9256] unless stated		semantics are described in Section 5 of [RFC9256] unless stated
	otherwise for individual flags. Other bits MUST be cleared by the		otherwise for individual flags. Other bits MUST be cleared by the
	originator and MUST be ignored by a receiver.		originator and MUST be ignored by a receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		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| |		|S|A|B|E|V|O|D|C|I|T|U| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- S-Flag: Indicates the candidate path is in an administrative		S-Flag: Indicates that the candidate path is in an administrative
	shut state when set and not in administrative shut state when		shut state when set and not in an administrative shut state
	clear.		when clear.
	- A-Flag: Indicates the candidate path is the active path (i.e.		A-Flag: Indicates that the candidate path is the active path
	one provisioned in the forwarding plane as specified in section		(i.e., one provisioned in the forwarding plane as specified in
	2.9 of [RFC9256]) for the SR Policy when set and not the active		Section 2.9 of [RFC9256]) for the SR Policy when set and not
	path when clear.		the active path when clear.
	- B-Flag: Indicates the candidate path is the backup path (i.e.		B-Flag: Indicates that the candidate path is the backup path
	one identified for path protection of the active path as		(i.e., one identified for path protection of the active path as
	specified in section 9.3 of [RFC9256]) for the SR Policy when		specified in Section 9.3 of [RFC9256]) for the SR Policy when
	set and not the backup path when clear.		set and not the backup path when clear.
	- E-Flag: Indicates that the candidate path has been evaluated		E-Flag: Indicates that the candidate path has been evaluated for
	for validity (e.g. headend may evaluate candidate paths based		validity (e.g., headend may evaluate candidate paths based on
	on their preferences) when set and has not been evaluated for		their preferences) when set and has not been evaluated for
	validity when clear.		validity when clear.
	- V-Flag: Indicates the candidate path has at least one valid		V-Flag: Indicates that the candidate path has at least one valid
	SID-List when set and indicates no valid SID-List is available		SID list when set and that no valid SID list is available or
	or evaluated when clear. When the E-Flag is clear (i.e. the		evaluated when clear. When the E-flag is clear (i.e., the
	candidate path has not been evaluated), then this flag MUST be		candidate path has not been evaluated), then this flag MUST be
	set to 0 by the originator and ignored by the receiver.		set to 0 by the originator and MUST be ignored by a receiver.
	- O-Flag: Indicates the candidate path was instantiated by the		O-Flag: Indicates that the candidate path was instantiated by the
	headend due to an on-demand nexthop trigger based on a local		headend due to an on-demand next hop trigger based on a local
	template when set and that the candidate path has not been		template when set and that the candidate path has not been
	instantiated due to on-demand nexthop trigger when clear.		instantiated due to an on-demand next hop trigger when clear.
	Refer to section 8.5 of [RFC9256] for details.		Refer to Section 8.5 of [RFC9256] for details.
	- D-Flag: Indicates the candidate path was delegated for		D-Flag: Indicates that the candidate path was delegated for
	computation to a PCE/controller when set and indicates that the		computation to a PCE/controller when set and that the candidate
	candidate path has not been delegated for computation when		path has not been delegated for computation when clear.
	clear.
	- C-Flag: Indicates the candidate path was provisioned by a PCE/		C-Flag: Indicates that the candidate path was provisioned by a
	controller when set and indicates that the candidate path was		PCE/controller when set and that the candidate path was not
	not provisioned by a PCE/controller when clear.		provisioned by a PCE/controller when clear.
	- I-Flag: Indicates the candidate path is to perform the "drop		I-Flag: Indicates that the candidate path is to perform the
	upon invalid" behavior when no other valid candidate path is		"Drop-Upon-Invalid" behavior when no other valid candidate path
	available for this SR Policy when the flag is set. Refer to		is available for this SR Policy when the flag is set. Refer to
	section 8.2 of [RFC9256] for details. When clear, it indicates		Section 8.2 of [RFC9256] for details. When clear, it indicates
	that the candidate path is not enabled for the "drop upon		that the candidate path is not enabled for the "Drop-Upon-
	invalid" behavior.		Invalid" behavior.
	- T-Flag: Indicates the candidate path has been marked as		T-Flag: Indicates that the candidate path has been marked 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 Section 8.3 of
	[RFC9256] for steering into a transit policy using its BSID.		[RFC9256] for steering into a transit policy using its BSID.
	- U-Flag: Indicates that this candidate path is reported as		U-Flag: Indicates that the candidate path is reported as active
	active and is dropping traffic as a result of the "drop upon		and is dropping traffic as a result of the "Drop-Upon-Invalid"
	invalid" behavior being activated for the SR Policy when set.		behavior being activated for the SR Policy when set. When
			clear, it indicates that the candidate path is not dropping
	When clear, it indicates that the candidate path is not		traffic as a result of the "Drop-Upon-Invalid" behavior. Refer
	dropping traffic as a result of the "drop upon invalid"		to Section 8.2 of [RFC9256] for details.
	behavior. Refer to section 8.2 of [RFC9256] for details.
	* Preference: 4-octet value which indicates the preference of the		Preference: 4-octet value that indicates the preference of the
	candidate path. Refer to section 2.7 of [RFC9256] for details.		candidate path. Refer to Section 2.7 of [RFC9256] for details.
	5.4. SR Policy Name TLV		5.4. SR Policy Name TLV
	The SR Policy Name TLV is an optional TLV that is used to carry the		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		symbolic name associated with the SR Policy. Only a single instance
	of this TLV is advertised for a given candidate path. If multiple		of 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
	be malformed as per section 8.2.2 of [RFC9552]) one is used and the		to be malformed as per Section 8.2.2 of [RFC9552]) is used and the
	rest are ignored.		rest are ignored.
	The TLV has the following format:		The TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SR Policy Name (variable) //		| SR Policy Name (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 9 SR Policy Name TLV Format		Figure 9: SR Policy Name TLV Format
	Where:		Where:
	* Type: 1213		Type: 1213
	* Length: variable		Length: Variable
	* SR Policy Name: Symbolic name for the SR Policy without a NULL		SR Policy Name: Symbolic name for the SR Policy without a NUL
	terminator as specified in section 2.1 of [RFC9256]. It is		terminator as specified in Section 2.1 of [RFC9256]. It is
	RECOMMENDED that the size of the symbolic name be limited to 255		RECOMMENDED that the size of the symbolic name be limited to 255
	bytes. Implementations MAY choose to truncate long names to 255		bytes. Implementations MAY choose to truncate long names to 255
	bytes when signaling via BGP-LS.		bytes when signaling via BGP-LS.
	5.5. SR Candidate Path Name TLV		5.5. SR Candidate Path Name TLV
	The SR Candidate Path Name TLV is an optional TLV that is used to		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.,
	determined to be malformed as per section 8.2.2 of [RFC9552]) one is		not determined to be malformed as per Section 8.2.2 of [RFC9552]) is
	used and the rest are ignored.		used and the rest are ignored.
	The TLV has the following format:		The TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Candidate Path Name (variable) //		| Candidate Path Name (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10 SR Candidate Path Name TLV Format		Figure 10: SR Candidate Path Name TLV Format
	Where:		Where:
	* Type: 1203		Type: 1203
	* Length: variable		Length: Variable
	* Candidate Path Name: Symbolic name for the SR Policy candidate		Candidate Path Name: Symbolic name for the SR Policy candidate path
	path without a NULL terminator as specified in section 2.6 of		without a NUL terminator as specified in Section 2.6 of [RFC9256].
	[RFC9256]. It is RECOMMENDED that the size of the symbolic name		It is RECOMMENDED that the size of the symbolic name be limited to
	be limited to 255 bytes. Implementations MAY choose to truncate		255 bytes. Implementations MAY choose to truncate long names to
	long names to 255 bytes when signaling via BGP-LS.		255 bytes when signaling via BGP-LS.
	5.6. SR Candidate Path Constraints TLV		5.6. SR Candidate Path Constraints TLV
	The SR Candidate Path Constraints TLV is an optional TLV that is used		The SR Candidate Path Constraints TLV is an optional TLV that is used
	to report the constraints associated with the candidate path. The		to report the constraints associated with the candidate path. The
	constraints are generally applied to a dynamic candidate path which		constraints are generally applied to a dynamic candidate path that is
	is computed either by the headend or may be delegated to a		either computed by the headend or delegated to a controller. The
	controller. The constraints may also be applied to an explicit path		constraints may also be applied to an explicit path where the
	where the computation entity is expected to validate that the path		computation entity is expected to validate that the path satisfies
	satisfies the specified constraints and if not the path is to be		the specified constraints; if not, the path is to be invalidated
	invalidated (e.g., due to topology changes). Only a single instance		(e.g., due to topology changes). Only a single instance of this TLV
	of this TLV is advertised for a given candidate path. If multiple		is advertised for a given candidate path. If multiple instances are
	instances are present, then the first valid (i.e., not determined to		present, then the first valid one (i.e., not determined to be
	be malformed as per section 8.2.2 of [RFC9552]) one is used and the		malformed as per Section 8.2.2 of [RFC9552]) is used and the rest are
	rest are ignored.		ignored.
	The TLV has the following format:		The TLV has the following format:
	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 | RESERVED1 |		| Flags | RESERVED1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MTID | Algorithm | RESERVED2 |		| MTID | Algorithm | RESERVED2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| sub-TLVs (variable) //		| sub-TLVs (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11 SR Candidate Path Constraints TLV Format		Figure 11: SR Candidate Path Constraints TLV Format
	Where:		Where:
	* Type: 1204		Type: 1204
	* Length: variable		Length: Variable
	* Flags: 2-octet field that indicates the constraints that are being		Flags: 2-octet field that indicates the constraints that are being
	applied to the candidate path. The following bit positions are		applied to the candidate path. The following bit positions are
	defined and the other bits MUST be cleared by the originator and		defined, and the other bits MUST be cleared by the originator and
	MUST be ignored by a receiver.		MUST be ignored by a receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|D|P|U|A|T|S|F|H| |		|D|P|U|A|T|S|F|H| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- D-Flag: Indicates that the candidate path uses SRv6 dataplane		D-Flag: Indicates that the candidate path uses an SRv6 data plane
	when set and SR/MPLS dataplane when clear		when set and an SR/MPLS data plane when clear.
	- P-Flag: Indicates that the candidate path prefers the use of		P-Flag: Indicates that the candidate path prefers the use of only
	only protected SIDs when set and indicates that the candidate		protected SIDs when set and that the candidate path does not
	path does not prefer the use of only protected SIDs when clear.		prefer the use of only protected SIDs when clear. This flag is
	This flag is mutually exclusive with the U-Flag (i.e., both		mutually exclusive with the U-flag (i.e., both of these flags
	these flags cannot be set at the same time).		cannot be set at the same time).
	- U-Flag: Indicates that the candidate path prefers the use of		U-Flag: Indicates that the candidate path prefers the use of only
	only unprotected SIDs when set and indicates that the candidate		unprotected SIDs when set and that the candidate path does not
	path does not prefer the use of only unprotected SIDs when		prefer the use of only unprotected SIDs when clear. This flag
	clear. This flag is mutually exclusive with the P-Flag (i.e.,		is mutually exclusive with the P-Flag (i.e., both of these
	both these flags cannot be set at the same time).		flags cannot be set at the same time).
	- A-Flag: Indicates that the candidate path uses only the SIDs		A-Flag: Indicates that the candidate path uses only the SIDs
	belonging to the specified SR Algorithm when set and indicates		belonging to the specified SR Algorithm when set and that the
	that the candidate path does not use only the SIDs belonging to		candidate path does not use only the SIDs belonging to the
	the specified SR Algorithm when clear.		specified SR Algorithm when clear.
	- T-Flag: Indicates that the candidate path uses only the SIDs		T-Flag: Indicates that the candidate path uses only the SIDs
	belonging to the specified topology when set and indicates that		belonging to the specified topology when set and that the
	the candidate path does not use only the SIDs belonging to the		candidate path does not use only the SIDs belonging to the
	specified topology when clear.		specified topology when clear.
	- S-Flag: Indicates that the use of protected (P-Flag) or		S-Flag: Indicates that the use of protected (P-flag) 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
	constraint (and only a preference) when clear.		(and only a preference) when clear.
	- F-Flag: Indicates that the candidate path is fixed once		F-Flag: Indicates that the candidate path is fixed once computed
	computed and not modified except on operator intervention and		and not modified except on operator intervention and that the
	indicates that the candidate path may be modified as part of		candidate path may be modified as part of recomputation when
	recomputation when clear.		clear.
	- H-Flag: Indicates that the candidate path uses only adjacency		H-Flag: Indicates that the candidate path uses only adjacency
	SIDs and traverses hop-by-hop over the links corresponding to		SIDs and traverses hop-by-hop over the links corresponding to
	those adjacency SIDs when set and indicates that the candidate		those adjacency SIDs when set and that the candidate path is
	path is not restricted to using only hop-by-hop adjacency SIDs		not restricted to using only hop-by-hop adjacency SIDs when
	when clear.		clear.
	* RESERVED1: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED1: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* MTID: Indicates the multi-topology identifier of the IGP topology		MTID: Indicates the multi-topology identifier of the IGP topology
	that is preferred to be used when the path is set up. When the		that is preferred to be used when the path is set up. When the
	T-flag is set then the path is strictly using the specified		T-flag is set, then the path is strictly using the specified
	topology SIDs only.		topology SIDs only.
	* Algorithm: Indicates the algorithm that is preferred to be used		Algorithm: Indicates the algorithm that is preferred to be used when
	when the path is set up. When the A-flag is set then the path is		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.		"Interior Gateway Protocol (IGP) Parameters" registry group.
	* RESERVED2: 1 octet. MUST be set to 0 by the originator and MUST		RESERVED2: 1 octet. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* sub-TLVs: one or more optional sub-TLVs MAY be included in this		sub-TLVs: One or more optional sub-TLVs MAY be included in this TLV
	TLV to describe other constraints. These sub-TLVs are: SR		to describe other constraints. These sub-TLVs are: SR Affinity
	Affinity Constraint, SR SRLG Constraint, SR Bandwidth Constraint,		Constraint, SR Shared Risk Link Group (SRLG) Constraint, SR
	SR Disjoint Group Constraint, SR Bidirectional Group Constraint,		Bandwidth Constraint, SR Disjoint Group Constraint, SR
	and SR Metric Constraint.		Bidirectional Group Constraint, and SR Metric Constraint.
	These constraint sub-TLVs are defined below.		These constraint sub-TLVs are defined below.
	5.6.1. SR Affinity Constraint Sub-TLV		5.6.1. SR Affinity Constraint Sub-TLV
	The SR Affinity Constraint sub-TLV is an optional sub-TLV of the SR		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		Candidate Path Constraints TLV that is used to carry the affinity
	constraints [RFC2702] associated with the candidate path. The		constraints [RFC2702] associated with the candidate path. The
	affinity is expressed in terms of Extended Admin Group (EAG) as		affinity is expressed in terms of an Extended Administrative Group
	defined in [RFC7308]. Only a single instance of this sub-TLV is		(EAG) as defined in [RFC7308]. Only a single instance of this sub-
	advertised for a given candidate path. If multiple instances are		TLV is advertised for a given candidate path. If multiple instances
	present, then the first valid (i.e., not determined to be malformed		are present, then the first valid one (i.e., not determined to be
	as per section 8.2.2 of [RFC9552]) one is used and the rest are		malformed as per Section 8.2.2 of [RFC9552]) is used and the rest are
	ignored.		ignored.
	The sub-TLV has the following format:		The sub-TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12 SR Affinity Constraints Sub-TLV Format		Figure 12: SR Affinity Constraint Sub-TLV Format
	Where:		Where:
	* Type: 1208		Type: 1208
	* Length: variable, dependent on the size of the Extended Admin		Length: Variable, dependent on the size of the EAG. MUST be a non-
	Group. MUST be a non-zero multiple of 4 octets.		zero multiple of 4 octets.
	* Exclude-Any-Size: one octet to indicate the size of Exclude-Any		Exclude-Any-Size: 1 octet to indicate the size of Exclude-Any EAG
	EAG bitmask size in multiples of 4 octets. (e.g. value 0		bitmask size in multiples of 4 octets (e.g., value 0 indicates the
	indicates the Exclude-Any EAG field is skipped, value 1 indicates		Exclude-Any EAG field is skipped, and value 1 indicates that 4
	that 4 octets of Exclude-Any EAG is included)		octets of Exclude-Any EAG are included).
	* Include-Any-Size: one octet to indicate the size of Include-Any		Include-Any-Size: 1 octet to indicate the size of Include-Any EAG
	EAG bitmask size in multiples of 4 octets. (e.g. value 0		bitmask size in multiples of 4 octets (e.g., value 0 indicates the
	indicates the Include-Any EAG field is skipped, value 1 indicates		Include-Any EAG field is skipped, and value 1 indicates that 4
	that 4 octets of Include-Any EAG is included)		octets of Include-Any EAG are included).
	* Include-All-Size: one octet to indicate the size of Include-All		Include-All-Size: 1 octet to indicate the size of Include-All EAG
	EAG bitmask size in multiples of 4 octets. (e.g. value 0		bitmask size in multiples of 4 octets (e.g., value 0 indicates the
	indicates the Include-All EAG field is skipped, value 1 indicates		Include-All EAG field is skipped, and value 1 indicates that 4
	that 4 octets of Include-All EAG is included)		octets of Include-All EAG are included).
	* RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be		RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be
	ignored by a receiver.		ignored by a receiver.
	* Exclude-Any EAG: the bitmask used to represent the affinities that		Exclude-Any EAG: The bitmask used to represent the affinities that
	have been excluded from the path.		have been excluded from the path.
	* Include-Any EAG: the bitmask used to represent the affinities that		Include-Any EAG: The bitmask used to represent the affinities that
	have been included in the path.		have been included in the path.
	* Include-All EAG: the bitmask used to represent all the affinities		Include-All EAG: The bitmask used to represent all the affinities
	that have been included in the path.		that have been included in the path.
	5.6.2. SR SRLG Constraint Sub-TLV		5.6.2. SR SRLG Constraint Sub-TLV
	The SR SRLG Constraint sub-TLV is an optional sub-TLV of the SR		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 [RFC4202] that have been excluded from the		[RFC4202] that have been excluded from the candidate path. Only a
	candidate path. Only a single instance of this sub-TLV is advertised		single instance of this sub-TLV is advertised for a given candidate
	for a given candidate path. If multiple instances are present, then		path. If multiple instances are present, then the first valid one
	the first valid (i.e., not determined to be malformed as per section		(i.e., not determined to be malformed as per Section 8.2.2 of
	8.2.2 of [RFC9552]) one is used and the rest are ignored.		[RFC9552]) is used and the rest are ignored.
	The sub-TLV has the following format:		The sub-TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SRLG Values (variable, multiples of 4 octets) //		| SRLG Values (variable, multiples of 4 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 13 SR SRLG Constraints Sub-TLV Format		Figure 13: SR SRLG Constraint Sub-TLV Format
	Where:		Where:
	* Type: 1209		Type: 1209
	* Length: variable, dependent on the number of SRLGs encoded. MUST		Length: Variable, dependent on the number of SRLGs encoded. MUST be
	be a non-zero multiple of 4 octets.		a non-zero multiple of 4 octets.
	* SRLG Values: One or more SRLG values. Each SRLG value is of 4		SRLG Values: One or more SRLG values. Each SRLG value is of 4
	octets.		octets.
	5.6.3. SR Bandwidth Constraint Sub-TLV		5.6.3. SR Bandwidth Constraint Sub-TLV
	The SR Bandwidth Constraint sub-TLV is an optional sub-TLV of the SR		The SR Bandwidth Constraint sub-TLV is an optional sub-TLV of the SR
	Candidate Path Constraints TLV that is used to indicate the bandwidth		Candidate Path Constraints TLV that is used to indicate the bandwidth
	that has been requested for the candidate path. Only a single		that has been requested for the candidate path. Only a single
	instance of this sub-TLV is advertised for a given candidate path.		instance of this sub-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.,
	determined to be malformed as per section 8.2.2 of [RFC9552]) one is		not determined to be malformed as per Section 8.2.2 of [RFC9552]) is
	used and the rest are ignored.		used and the rest are ignored.
	The sub-TLV has the following format:		The sub-TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 14 SR Bandwidth Constraints Sub-TLV Format		Figure 14: SR Bandwidth Constraint Sub-TLV Format
	Where:		Where:
	* Type: 1210		Type: 1210
	* Length: 4 octets		Length: 4 octets
	* Bandwidth: 4 octets which specify the desired bandwidth in unit of		Bandwidth: 4 octets that specify the desired bandwidth in unit of
	bytes per second in IEEE floating point format [IEEE754].		bytes per second in IEEE floating point format [IEEE754].
	5.6.4. SR Disjoint Group Constraint Sub-TLV		5.6.4. SR Disjoint Group Constraint Sub-TLV
	The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV of		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		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 [RFC8800]		The types of disjointness are described in Section 3 of [RFC8800]
	where the level of disjointness increases in the order: link, node,		where the level of disjointness increases in the order: link, node,
	SRLG, Node + SRLG. The computation is expected to achieve the		SRLG, Node + SRLG. The computation is expected to achieve the
	highest level of disjointness requested and when that is not possible		highest level of disjointness requested; when that is not possible,
	then fall back to a lesser level progressively based on the levels		then fall back to a lesser level progressively based on the levels
	indicated. Only a single instance of this sub-TLV is advertised for		indicated. Only a single instance of this sub-TLV is advertised for
	a given candidate path. If multiple instances are present, then the		a given candidate path. If multiple instances are present, then the
	first valid (i.e., not determined to be malformed as per section		first valid one (i.e., not determined to be malformed as per
	8.2.2 of [RFC9552]) one is used and the rest are ignored.		Section 8.2.2 of [RFC9552]) is used and the rest are ignored.
	The sub-TLV has the following format:		The sub-TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request-Flags | Status-Flags | RESERVED |		| Request Flags | Status Flags | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Disjoint Group Identifier (variable) //		| Disjoint Group Identifier (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 15 SR Disjoint Group Constraints Sub-TLV Format		Figure 15: SR Disjoint Group Constraint Sub-TLV Format
	Where:		Where:
	* Type: 1211		Type: 1211
	* Length: Variable. Minimum of 8 octets.		Length: Variable. Minimum of 8 octets.
	* Request Flags: one octet to indicate the level of disjointness		Request Flags: 1 octet to indicate the level of disjointness
	requested as specified in the form of flags. The following flags		requested as specified in the form of flags. The following flags
	are defined and the other bits MUST be cleared by the originator		are defined, and the other bits MUST be cleared by the originator
	and MUST be ignored by a receiver.		and MUST be ignored by a receiver.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|S|N|L|F|I| |		|S|N|L|F|I| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Where:		Where:
	- S-Flag: Indicates that SRLG disjointness is requested when set		S-Flag: Indicates that SRLG disjointness is requested when set
	and indicates that SRLG disjointness is not requested when		and that SRLG disjointness is not requested when clear.
	clear.
	- N-Flag: Indicates that node disjointness is requested when set		N-Flag: Indicates that node disjointness is requested when set
	and indicates that node disjointness is not requested when		and that node disjointness is not requested when clear.
	clear.
	- L-Flag: Indicates that link disjointness is requested when set		L-Flag: Indicates that link disjointness is requested when set
	and indicates that the link disjointness is not requested when		and that the link disjointness is not requested when clear.
	clear.
	- F-Flag: Indicates that the computation may fall back to a lower		F-Flag: Indicates that the computation may fall back to a lower
	level of disjointness amongst the ones requested when all		level of disjointness amongst the ones requested when all
	cannot be achieved when set and indicates that fallback to a		cannot be achieved when set and that fallback to a lower level
	lower level of disjointness is not allowed when clear.		of disjointness is not allowed when clear.
	- I-Flag: Indicates that the computation may fall back to the		I-Flag: Indicates that the computation may fall back to the
	default best path (e.g. IGP path) in case of none of 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
	that fallback to the default best path is not allowed when		to the default best path is not allowed when clear.
	clear.
	* Status Flags: one octet to indicate the level of disjointness that		Status Flags: 1 octet to indicate the level of disjointness that has
	has been achieved by the computation as specified in the form of		been achieved by the computation as specified in the form of
	flags. The following flags are defined and the other bits MUST be		flags. The following flags are defined, and the other bits MUST
	cleared by the originator and MUST be ignored by a receiver.		be cleared by the originator and MUST be ignored by a receiver.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|S|N|L|F|I|X| |		|S|N|L|F|I|X| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Where:		Where:
	- S-Flag: Indicates that SRLG disjointness is achieved when set		S-Flag: Indicates that SRLG disjointness is achieved when set and
	and indicates that SRLG disjointness is not achieved when		that SRLG disjointness is not achieved when clear.
	clear.
	- N-Flag: Indicates that node disjointness is achieved when set		N-Flag: Indicates that node disjointness is achieved when set and
	and indicates that node disjointness was not achieved when		that node disjointness was not achieved when clear.
	clear.
	- L-Flag: Indicates that link disjointness is achieved when set		L-Flag: Indicates that link disjointness is achieved when set and
	and indicates that link disjointness was not achieved when		that link disjointness was not achieved when clear.
	clear.
	- F-Flag: Indicates that the computation has fallen back to a		F-Flag: Indicates that the computation has fallen back to a lower
	lower level of disjointness than requested when set and		level of disjointness than requested when set and that there
	indicates that there has been no fallback to a lower level of		has been no fallback to a lower level of disjointness when
	disjointness when clear.		clear.
	- I-Flag: Indicates that the computation has fallen back to the		I-Flag: Indicates that the computation has fallen back to the
	best path (e.g. IGP path) and disjointness has not been		best path (e.g., an IGP path) and disjointness has not been
	achieved when set and indicates that there has been no fallback		achieved when set and that there has been no fallback to the
	to best path when clear.		best path when clear.
	- X-Flag : Indicates that the disjointness constraint could not		X-Flag: Indicates that the disjointness constraint could not be
	be achieved and hence path has been invalidated when set and		achieved and hence the path has been invalidated when set and
	indicates that the path has not been invalidated due to unmet		that the path has not been invalidated due to unmet
	disjointness constraints when clear.		disjointness constraints when clear.
	* RESERVED: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* Disjoint Group Identifier: 4-octet value that is the group		Disjoint Group Identifier: 4-octet value that is the group
	identifier for a set of disjoint paths. Alternatively, this field		identifier for a set of disjoint paths. Alternatively, this field
	MAY contain the entire PCEP Association Object as specified in		MAY contain the entire PCEP ASSOCIATION Object as specified in
	section 6.1 of [RFC8697] (including its optional TLVs) when PCEP		Section 6.1 of [RFC8697] (including its optional TLVs) when PCEP
	is used for the signaling the SR Policy candidate path and where		is used for the signaling of the SR Policy candidate path and
	the BGP-LS Producer is unable to determine the group identifier		where the BGP-LS Producer is unable to determine the group
	that can be accommodated in a 4-octet value (since PCEP supports		identifier that can be accommodated in a 4-octet value (since PCEP
	multiple methods of encoding an association identifier). Note		supports multiple methods of encoding an association identifier).
	that the parsing of the PCEP object is expected to be performed		Note that the parsing of the PCEP object is expected to be
	only by the BGP-LS Consumer (hence, outside the scope of this		performed only by the BGP-LS Consumer (hence, outside the scope of
	document) and not by any BGP Speaker as specified in [RFC9552].		this document) and not by any BGP Speaker as specified in
	If the PCEP object size is such that the update for a single SR		[RFC9552]. If the PCEP object size is such that the update for a
	Policy Candidate Path NLRI would exceed the supported BGP message		single SR Policy Candidate Path NLRI would exceed the supported
	size by the implementation, then the PCEP Association Object MUST		BGP message size by the implementation, then the PCEP ASSOCIATION
	NOT be encoded and this sub-TLV skipped along with an error log.		Object MUST NOT be encoded and this sub-TLV skipped along with an
	Refer section 5.3 of [RFC9552] for discussion on implications of		error log. Refer to Section 5.3 of [RFC9552] for discussion on
	encoding large sets of information into BGP-LS.		implications of encoding large sets of information into BGP-LS.
	5.6.5. SR Bidirectional Group Constraint Sub-TLV		5.6.5. SR Bidirectional Group Constraint Sub-TLV
	The SR Bidirectional Group Constraint sub-TLV is an optional sub-TLV		The SR Bidirectional Group Constraint sub-TLV is an optional sub-TLV
	of the SR Candidate Path Constraints TLV that is used to carry the		of the SR Candidate Path Constraints TLV that is used to carry the
	bidirectional constraint associated with the candidate path. The		bidirectional constraint associated with the candidate path. The
	bidirectional relationship between two SR Policy Candidate Paths is		bidirectional relationship between two SR Policy candidate paths is
	expressed by associating them with the same bidirectional group		expressed by associating them with the same bidirectional group
	identifier and then specifying the type of bidirectional routing		identifier and then specifying the type of bidirectional routing
	required between their paths. Only a single instance of this sub-TLV		required between their paths. Only a single instance of this sub-TLV
	is advertised for a given candidate path. If multiple instances are		is 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
	as per section 8.2.2 of [RFC9552]) one is used and the rest are		malformed as per Section 8.2.2 of [RFC9552]) is used and the rest are
	ignored.		ignored.
	The sub-TLV has the following format:		The sub-TLV has the following format:
	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 | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Bidirectional Group Identifier (variable) //		| Bidirectional Group Identifier (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 16 SR Bidirectional Group Constraints Sub-TLV Format		Figure 16: SR Bidirectional Group Constraint Sub-TLV Format
	Where:		Where:
	* Type: 1214		Type: 1214
	* Length: Variable. Minimum of 8 octets.		Length: Variable. Minimum of 8 octets.
	* Flags: two octets to indicate the bidirectional path setup		Flags: 2 octets to indicate the bidirectional path setup information
	information as specified in the form of flags. The following		as specified in the form of flags. The following flags are
	flags are defined and the other bits MUST be cleared by the		defined, and the other bits MUST be cleared by the originator and
	originator and MUST be ignored by a receiver.		MUST be ignored by a receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R|C| |		|R|C| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- R-Flag: Indicates that this candidate path of the SR Policy		R-Flag: Indicates that the candidate path of the SR Policy forms
	forms the reverse path when the R-Flag is set. If the R-Flag		the reverse path when the R-flag is set. If the R-flag is
	is clear, this candidate path forms the forward path.		clear, the candidate path forms the forward path.
	- C-Flag: Indicates that the bidirectional path is co-routed when		C-Flag: Indicates that the bidirectional path is co-routed when
	set and indicates that the bidirectional path is not co-routed		set and that the bidirectional path is not co-routed when
	when clear.		clear.
	* RESERVED: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* Bidirectional Group Identifier: 4-octet value that is the group		Bidirectional Group Identifier: 4-octet value that is the group
	identifier for a set of bidirectional paths. Alternatively, this		identifier for a set of bidirectional paths. Alternatively, this
	field MAY contain the entire PCEP Association Object as specified		field MAY contain the entire PCEP ASSOCIATION Object as specified
	in section 6.1 of [RFC8697] (including its optional TLVs) when		in Section 6.1 of [RFC8697] (including its optional TLVs) when
	PCEP is used for the signaling the SR Policy candidate path and		PCEP is used for the signaling of the SR Policy candidate path and
	where the BGP-LS Producer is unable to determine the group		where the BGP-LS Producer is unable to determine the group
	identifier that can be accommodated in a 4-octet value (since PCEP		identifier that can be accommodated in a 4-octet value (since PCEP
	supports multiple methods of encoding an association identifier).		supports multiple methods of encoding an association identifier).
	Note that the parsing of the PCEP object is expected to be		Note that the parsing of the PCEP object is expected to be
	performed only by the BGP-LS Consumer (hence, outside the scope of		performed only by the BGP-LS Consumer (hence, outside the scope of
	this document) and not by any BGP Speaker as specified in		this document) and not by any BGP Speaker as specified in
	[RFC9552]. If the PCEP object size is such that the update for a		[RFC9552]. If the PCEP object size is such that the update for a
	single SR Policy Candidate Path NLRI would exceed the supported		single SR Policy Candidate Path NLRI would exceed the supported
	BGP message size by the implementation, then the PCEP Association		BGP message size by the implementation, then the PCEP ASSOCIATION
	Object MUST NOT be encoded and this sub-TLV skipped along with an		Object MUST NOT be encoded and this sub-TLV skipped along with an
	error log. Refer section 5.3 of [RFC9552] for discussion on		error log. Refer to Section 5.3 of [RFC9552] for discussion on
	implications of encoding large sets of information into BGP-LS.		implications of encoding large sets of information into BGP-LS.
	5.6.6. SR Metric Constraint Sub-TLV		5.6.6. SR Metric Constraint Sub-TLV
	The SR Metric Constraint sub-TLV is an optional sub-TLV of the SR		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 MAY be used
	to report the metric margin or bound to be used for validation (i.e.,		to report the metric margin or is bound to be used for validation
	the path is invalidated if the metric is beyond specified values).		(i.e., the path is invalidated if the metric is beyond specified
	Multiple instances of this sub-TLV may be used to report different		values). Multiple instances of this sub-TLV may be used to report
	metric type uses.		different metric type uses.
	The sub-TLV has the following format:		The sub-TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 17 SR Metric Constraints Sub-TLV Format		Figure 17: SR Metric Constraint Sub-TLV Format
	Where:		Where:
	* Type: 1215		Type: 1215
	* Length: 12 octets		Length: 12 octets
	* Metric Type: 1-octet field which identifies the type of the metric		Metric Type: 1-octet field that identifies the type of metric being
	being used. The Table 1 below lists the metric types introduced		used. Below is a list of metric types introduced by this document
	by this document along with reference for each. Where the		along with references for each. Where the references are for IS-
	references are for IS-IS and OSPF specifications, those metric		IS and OSPF specifications, those metric types are defined for a
	types are defined for a link while in the SR Policy context those		link while in the SR Policy context those relate to the candidate
	relate to the candidate path or the segment list. The metric type		path or the segment list. The metric type code points that may be
	code points that may be used in this sub-TLV are also listed in		used in this sub-TLV are also listed in Section 8.6 of this
	Section 8.6 of this document. Note that the metric type in this		document. Note that the metric types in this field are taken from
	field is not taken from the "IGP Metric Type" registry from IANA		the "BGP-LS SR Policy Metric Types" IANA registry, which includes
	"IGP Parameters" and is a separate registry that includes IGP		IGP Metric Types as well as metric types specific to SR Policy
	Metric Types as well as metric types specific to SR Policy path		path computation (i.e., the metric types are not from the "IGP
	computation. Additional metric types may be introduced by future		Metric-Type" registry). Additional metric types may be introduced
	documents. This document does not make any assumption of a		by future documents. This document does not make any assumptions
	smaller metric value being better than a higher metric value; that		about a smaller metric value being better than a higher metric
	is something dependent on the semantics of the specific metric		value; that is something that is dependent on the semantics of the
	type. The document uses the words "best" and "worst" to abstract		specific metric type. This document uses the words "best" and
	this aspect when referring to metric margins and bounds.		"worst" to abstract this aspect when referring to metric margins
			and bounds.
	- Type 0: IGP: In IS-IS, this is known as the default metric and		Type 0: IGP:
	specified in section 3 of [RFC5305]. This is known as metric		This is specified in Section 3 of [RFC5305] for IS-IS and is
	in both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].		known as the default metric. This is specified in [RFC2328]
			for OSPFv2 and in [RFC5340] for OSPFv3 and is known as the
			metric in both.
	- Type 1: Min Unidirectional Delay: This is specified in section		Type 1: Min Unidirectional Delay:
	4.2 of [RFC8570] for IS-IS and in section 4.2 of [RFC7471] for		This is specified in Section 4.2 of [RFC8570] for IS-IS and in
	OSPFv2/OSPFv3.		Section 4.2 of [RFC7471] for OSPFv2/OSPFv3.
	- Type 2: TE: This is specified in section 3.7 of [RFC5305] as		Type 2: TE:
	the TE default metric for IS-IS, in section 2.5.5 of [RFC3630]		This is specified in Section 3.7 of [RFC5305] for IS-IS as the
	for OSPFv2, and in section 4 of [RFC5329] for OSPFv3.		TE default metric, in Section 2.5.5 of [RFC3630] for OSPFv2,
			and in Section 4 of [RFC5329] for OSPFv3.
	- Type 3: Hop Count: This is specified in section 7.8 of		Type 3: Hop Count:
	[RFC5440].		This is specified in Section 7 of [RFC5440].
	- Type 4: SID List Length: This is specified in section 4.5 of		Type 4: SID List Length:
	[RFC8664].		This is specified in Section 4.5 of [RFC8664].
	- Type 5: Bandwidth: This is specified in section 4 of		Type 5: Bandwidth:
	[I-D.ietf-lsr-flex-algo-bw-con].		This is specified in Section 4 of [RFC9843].
	- Type 6: Average Unidirectional Delay: This is specified in		Type 6: Avg Unidirectional Delay:
	section 4.1 of [RFC8570] for IS-IS and in section 4.1 of		This is specified in Section 4.1 of [RFC8570] for IS-IS and in
	[RFC7471] for OSPFv2/OSPFv3.		Section 4.1 of [RFC7471] for OSPFv2/OSPFv3.
	- Type 7: Unidirectional Delay Variation: This is specified in		Type 7: Unidirectional Delay Variation:
	section 4.3 of [RFC8570] for IS-IS and in section 4.3 of		This is specified in Section 4.3 of [RFC8570] for IS-IS and in
	[RFC7471] for OSPFv2/OSPFv3.		Section 4.3 of [RFC7471] for OSPFv2/OSPFv3.
	- Type 8: Loss: This is specified in section 4.4 of [RFC8570] for		Type 8: Loss:
	IS-IS and in section 4.4 of [RFC7471] for OSPFv2/OSPFv3.		This is specified in Section 4.4 of [RFC8570] for IS-IS and in
			Section 4.4 of [RFC7471] for OSPFv2/OSPFv3.
	- Types 128 to 255 (both inclusive): User Defined: This is		Types 128 to 255 (both inclusive): User Defined:
	specified for IS-IS and OSPF in section 2 of		This is specified in Section 2 of [RFC9843] for IS-IS and OSPF.
	[I-D.ietf-lsr-flex-algo-bw-con].
	* Flags: 1-octet field that indicates the validity of the metric		Flags: 1-octet field that indicates the validity of the metric
	fields and their semantics. The following bit positions are		fields and their semantics. The following bit positions are
	defined and the other bits MUST be cleared by the originator and		defined, and the other bits MUST be cleared by the originator and
	MUST be ignored by a receiver.		MUST be ignored by a receiver.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|O|M|A|B| |		|O|M|A|B| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Where:		Where:
	- O-Flag: Indicates that this is the optimization metric being		O-Flag: Indicates that this is the optimization metric being
	reported for a dynamic candidate path when set and indicates		reported for a dynamic candidate path when set and that the
	that the metric is not the optimization metric when clear.		metric is not the optimization metric when clear. This bit
	This bit MUST NOT be set in more than one instance of this TLV		MUST NOT be set in more than one instance of this TLV for a
	for a given candidate path advertisement.		given candidate path advertisement.
	- M-Flag: Indicates that the metric margin allowed is specified		M-Flag: Indicates that the metric margin allowed is specified
	when set and indicates that metric margin allowed is not		when set and that the metric margin allowed is not specified
	specified when clear.		when clear.
	- A-Flag: Indicates that the metric margin is specified as an		A-Flag: Indicates that the metric margin is specified as an
	absolute value when set and is expressed as a percentage of the		absolute value when set and that the metric margin is expressed
	minimum metric when clear.		as a percentage of the minimum metric when clear.
	- B-Flag: Indicates that the metric bound allowed for the path is		B-Flag: Indicates that the metric bound allowed for the path is
	specified when set and indicates that metric bound is not		specified when set and that the metric bound is not specified
	specified when clear.		when clear.
	* RESERVED: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* Metric Margin: 4-octet value which indicates the metric margin		Metric Margin: 4-octet value that indicates the metric margin when
	when the M-flag is set. The metric margin is specified, depending		the M-flag is set. The metric margin is specified, depending on
	on the A-flag, as either an absolute value or as a percentage of		the A-flag, as either an absolute value or a percentage of the
	the best computed path metric based on the specified constraints		best computed path metric based on the specified constraints for
	for path calculation. The metric margin allows for the metric		path calculation. The metric margin allows for the metric value
	value of the computed path to vary (depending on the semantics of		of the computed path to vary (depending on the semantics of the
	the specific metric type) from the best metric value possible to		specific metric type) from the best metric value possible to
	optimize for other factors (that are not specified as constraints)		optimizing for other factors (that are not specified as
	such as bandwidth availability, minimal SID stack depth, and		constraints) such as bandwidth availability, minimal SID stack
	maximizing of ECMP for the SR path computed.		depth, and the maximizing of ECMP for the computed SR path.
	* Metric Bound: 4-octet value which indicates the worst metric value		Metric Bound: 4-octet value that indicates the worst metric value
	(depending on the semantics of the specific metric type) that is		(depending on the semantics of the specific metric type) allowed
	allowed when the B-flag is set. If the computed path metric		when the B-flag is set. If the computed path metric crosses the
	crosses the specified bound value then the path is considered		specified bound value, then the path is considered invalid.
	invalid.
	The absolute metric margin and the metric bound values are encoded as		The absolute metric margin and the metric bound values are encoded as
	specified for each metric type. For metric types that are smaller		specified for each metric type. For metric types that are smaller
	than 4 octets in size, the most significant bits are filled with		than 4 octets in size, the most significant bits are filled with
	zeros. The percentage metric margin is encoded as an unsigned		zeros. The percentage metric margin is encoded as an unsigned
	integer percentage value.		integer percentage value.
	5.7. SR Segment List TLV		5.7. SR Segment List TLV
	The SR Segment List TLV is used to report a single SID-List of a		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.		multiple SID lists of a candidate path.
	The TLV has the following format:		The TLV has the following format:
	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) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 18 SR Segment List TLV Format		Figure 18: SR Segment List TLV Format
	Where:		Where:
	* Type: 1205		Type: 1205
	* Length: variable		Length: Variable
	* Flags: 2-octet field that indicates attribute and status of the		Flags: 2-octet field that indicates the attribute and status of the
	SID-List.The following bit positions are defined and the semantics		SID list. The following bit positions are defined, and the
	are described in detail in [RFC9256]. Other bits MUST be cleared		semantics are described in detail in [RFC9256]. Other bits MUST
	by the originator and MUST be ignored by a receiver.		be cleared by the originator and MUST be ignored by a receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		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| |		|D|E|C|V|R|F|A|T|M| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- D-Flag: Indicates the SID-List consists of SRv6 SIDs when set		D-Flag: Indicates that the SID list consists of SRv6 SIDs when
	and indicates it consists of SR/MPLS labels when clear.		set and SR/MPLS labels when clear.
	- E-Flag: Indicates that SID-List is associated with an explicit		E-Flag: Indicates that the SID list is associated with an
	candidate path when set and with a dynamic candidate path when		explicit candidate path when set and a dynamic candidate path
	clear. All segment lists of a given candidate path MUST be		when clear. All segment lists of a given candidate path MUST
	either explicit or dynamic and in case of inconsistency, the		be either explicit or dynamic. In case of inconsistency, the
	receiver MAY consider them all to be dynamic.		receiver MAY consider them all to be dynamic.
	- C-Flag: Indicates that SID-List has been computed for a dynamic		C-Flag: Indicates that the SID list has been computed for a
	path when set. It is always reported as set for explicit		dynamic path when set. It is always reported as set for
	paths. When clear, it indicates that the SID-List has not been		explicit paths. When clear, it indicates that the SID list has
	computed for a dynamic path.		not been computed for a dynamic path.
	- V-Flag: Indicates the SID-List has passed verification or its		V-Flag: Indicates that the SID list has passed verification or
	verification was not required when set and failed verification		its verification was not required when set and that it failed
	when clear.		verification when clear.
	- R-Flag: Indicates that the first Segment has been resolved when		R-Flag: Indicates that the first Segment has been resolved when
	set and failed resolution when clear.		set and that it failed resolution when clear.
	- F-Flag: Indicates that the computation for the dynamic path		F-Flag: Indicates that the computation for the dynamic path
	failed when set and succeeded (or not required in case of		failed when set and that it succeeded (or was not required in
	explicit path) when clear.		case of an explicit path) when clear.
	- A-Flag: Indicates that all the SIDs in the SID-List belong to		A-Flag: Indicates that all the SIDs in the SID list belong to the
	the specified algorithm when set and indicates that not all the		specified algorithm when set and that not all the SIDs belong
	SIDs belong to the specified algorithm when clear.		to the specified algorithm when clear.
	- T-Flag: Indicates that all the SIDs in the SID-List belong to		T-Flag: Indicates that all the SIDs in the SID list belong to the
	the specified topology (identified by the multi-topology ID)		specified topology (identified by the multi-topology ID) when
	when set and indicates that not all the SIDs belong to the		set and that not all the SIDs belong to the specified topology
	specified topology when clear.		when clear.
	- M-Flag: Indicates that the SID-list has been removed from the		M-Flag: Indicates that the SID list has been removed from the
	forwarding plane due to fault detection by a monitoring		forwarding plane due to fault detection by a monitoring
	mechanism (e.g. BFD) when set and indicates no fault detected		mechanism (e.g., Bidirectional Forwarding Detection (BFD)) when
	or monitoring is not being done when clear.		set and that no fault is detected or no monitoring is being
			done when clear.
	* RESERVED: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED1: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* MTID: 2 octets that indicates the multi-topology identifier of the		MTID: 2 octets that indicate the multi-topology identifier of the
	IGP topology that is to be used when the T-flag is set.		IGP topology that is to be used when the T-flag is set.
	* Algorithm: 1 octet that indicates the algorithm of the SIDs used		Algorithm: 1 octet that indicates the algorithm of the SIDs used in
	in the SID-List when the A-flag is set. The algorithm values are		the SID list when the A-flag is set. The algorithm values are
	from IGP Algorithm Types registry under the IANA Interior Gateway		from the "IGP Algorithm Types" IANA registry under the "Interior
	Protocol (IGP) Parameters.		Gateway Protocol (IGP) Parameters" registry group.
	* RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be		RESERVED2: 1 octet. MUST be set to 0 by the originator and MUST be
	ignored by a receiver.		ignored by a receiver.
	* Weight: 4-octet field that indicates the weight associated with		Weight: 4-octet field that indicates the weight associated with the
	the SID-List for weighted load-balancing. Refer to section 2.2		SID list for weighted load balancing. Refer to Sections 2.2 and
	and 2.11 of [RFC9256].		2.11 of [RFC9256].
	* Sub-TLVs: variable and contains the ordered set of Segments and		Sub-TLVs: Variable and contain the ordered set of Segments and any
	any other optional attributes associated with the specific SID-		other optional attributes associated with the specific SID list.
	List.
	The SR Segment sub-TLV (defined in Section 5.7.1) MUST be included as		The SR Segment sub-TLV (defined in Section 5.7.1) MUST be included as
	an ordered set of sub-TLVs within the SR Segment List TLV when the		an ordered set of sub-TLVs within the SR Segment List TLV when the
	SID-List is not empty. A SID-List may be empty in certain situations		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		(e.g., for a dynamic path) where the headend has not yet performed
	computation and hence not derived the segments required for the path.		the computation and hence not derived the segments required for the
	In such cases where the SID-LIST is empty, the SR Segment List TLV		path. In such cases where the SID list is empty, the SR Segment List
	MUST NOT include any SR Segment sub-TLVs.		TLV MUST NOT include any SR Segment sub-TLVs.
	5.7.1. SR Segment Sub-TLV		5.7.1. SR Segment Sub-TLV
	The SR Segment sub-TLV describes a single segment in a SID-List. One		The SR Segment sub-TLV describes a single segment in a SID list. One
	or more instances of this sub-TLV in an ordered manner constitute a		or more instances of this sub-TLV in an ordered manner constitute a
	SID-List for an SR Policy candidate path. It is a sub-TLV of the SR		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:		Segment List TLV and it has the following format:
	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) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 19 SR Segment Sub-TLV Format		Figure 19: SR Segment Sub-TLV Format
	Where:		Where:
	* Type: 1206		Type: 1206
	* Length: variable		Length: Variable
	* Segment Type: 1 octet which indicates the type of segment.		Segment Type: 1 octet that indicates the type of segment. Initial
	Initial values are specified by this document (see Section 5.7.1.1		values are specified by this document (see Section 5.7.1.1 for
	for details). Additional segment types are possible, but out of		details). Additional segment types are possible but are out of
	scope for this document.		scope for this document.
	* RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be		RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be
	ignored by a receiver.		ignored by a receiver.
	* Flags: 2-octet field that indicates attribute and status of the		Flags: 2-octet field that indicates the attribute and status of the
	Segment and its SID. The following bit positions are defined and		Segment and its SID. The following bit positions are defined, and
	the semantics are described in section 5 of [RFC9256]. Other bits		the semantics are described in Section 5 of [RFC9256]. Other bits
	MUST be cleared by the originator and MUST be ignored by a		MUST be cleared by the originator and MUST be ignored by a
	receiver.		receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S|E|V|R|A| |		|S|E|V|R|A| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	- S-Flag: Indicates the presence of SID value in the SID field		S-Flag: Indicates the presence of the SID value in the SID field
	when set and that no value is indicated when clear.		when set and no value when clear.
	- E-Flag: Indicates the SID value is explicitly provisioned value		E-Flag: Indicates that the SID value is an explicitly provisioned
	(locally on headend or via controller/PCE) when set and is a		value (locally on headend or via controller/PCE) when set and
	dynamically resolved value by headend when clear		is a dynamically resolved value by headend when clear.
	- V-Flag: Indicates the SID has passed verification or did not		V-Flag: Indicates that the SID has passed verification or did not
	require verification when set. When V-Flag is clear, it		require verification when set. When the V-flag is clear, it
	indicates the SID has failed verification.		indicates the SID has failed verification.
	- R-Flag: Indicates the SID has been resolved or did not require		R-Flag: Indicates that the SID has been resolved or did not
	resolution (e.g. because it is not the first SID) when set.		require resolution (e.g., because it is not the first SID) when
	When R-Flag is clear, it indicates the SID has failed		set. When the R-flag is clear, it indicates the SID has failed
	resolution.		resolution.
	- A-Flag: Indicates that the Algorithm indicated in the Segment		A-Flag: Indicates that the Algorithm indicated in the segment
	descriptor is valid when set. When clear, it indicates that		descriptor is valid when set. When clear, it indicates that
	the headend is unable to determine the algorithm of the SID.		the headend is unable to determine the algorithm of the SID.
	* SID: 4 octets carrying the MPLS Label or 16 octets carrying the		SID: 4 octets carrying the MPLS Label or 16 octets carrying the SRv6
	SRv6 SID based on the Segment Type. When carrying the MPLS Label,		SID based on the Segment Type. When carrying the MPLS Label, as
	as shown in the figure below, the TC, S, and TTL (total of 12		shown in the figure below, the TC, S, and TTL (total of 12 bits)
	bits) are RESERVED and MUST be set to 0 by the originator and MUST		are RESERVED and MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	* Segment Descriptor: variable size Segment descriptor based on the		Segment Descriptor: Variable size segment descriptor based on the
	type of segment (refer to Section 5.7.1.1 for details)		type of segment (refer to Section 5.7.1.1 for details).
	* Sub-Sub-TLVs: variable and contains any other optional attributes		Sub-Sub-TLVs: Variable and contain any other optional attributes
	associated with the specific segment.		associated with the specific segment.
	The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure TLV		The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure TLV
	(1252) defined in [RFC9514] are used as sub-sub-TLVs of the SR		(1252) defined in [RFC9514] are used as sub-sub-TLVs of the SR
	Segment sub-TLV. These two sub-sub-TLVs are used to optionally		Segment sub-TLV. These two sub-sub-TLVs are used to optionally
	indicate the SRv6 Endpoint behavior and SID structure when		indicate the SRv6 Endpoint behavior and SID structure when
	advertising the SRv6 specific segment types.		advertising the SRv6-specific segment types.
	5.7.1.1. Segment Descriptors		5.7.1.1. Segment Descriptors
	Section 4 of [RFC9256] defines multiple types of segments and their		Section 4 of [RFC9256] defines multiple types of segments and their
	description. This section defines the encoding of the Segment		descriptions. This section defines the encoding of the segment
	Descriptors for each of those Segment types to be used in the Segment		descriptors for each of those segment types to be used in the Segment
	sub-TLV described previously in Section 5.7.1.		sub-TLV described previously in Section 5.7.1.
	The following types are currently defined and their mapping to the		The following types are currently defined, and their mappings to the
	respective segment types defined in [RFC9256]:		respective segment types are defined in [RFC9256]:
	+------+-------------------------------------------------------------+		+======+=================================================+
	| Type | Segment Description |		| Type | Segment Description |
	+------+-------------------------------------------------------------+		+======+=================================================+
	| 1 | (Type A) SR-MPLS Label |		| 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 |		| 2 | (Type B) SRv6 SID |
	| 4 | (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address |		+------+-------------------------------------------------+
	| 5 | (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local |		| 3 | (Type C) IPv4 Prefix with optional SR Algorithm |
	| | Interface ID |		+------+-------------------------------------------------+
	| 6 | (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote |		| 4 | (Type D) IPv6 Global Prefix with optional SR |
	| | Interface Addresses |		| | Algorithm for SR-MPLS |
	| 7 | (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global |		+------+-------------------------------------------------+
	| | Address & Interface ID for Local & Remote nodes |		| 5 | (Type E) IPv4 Prefix with Local Interface ID |
	| 8 | (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global |		+------+-------------------------------------------------+
	| | Addresses for the Local & Remote Interface |		| 6 | (Type F) IPv4 Addresses for link endpoints as |
	| 9 | (Type I) SRv6 END SID as IPv6 Node Global Address |		| | Local, Remote pair |
	| 10 | (Type J) SRv6 END.X SID as pair of IPv6 Global Address & |		+------+-------------------------------------------------+
	| | Interface ID for Local & Remote nodes |		| 7 | (Type G) IPv6 Prefix and Interface ID for link |
	| 11 | (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses |		| | endpoints as Local, Remote pair for SR-MPLS |
	| | for the Local & Remote Interface |		+------+-------------------------------------------------+
	+------+-------------------------------------------------------------+		| 8 | (Type H) IPv6 Addresses for link endpoints as |
			| | Local, Remote pair for SR-MPLS |
			+------+-------------------------------------------------+
			| 9 | (Type I) IPv6 Global Prefix with optional SR |
			| | Algorithm for SRv6 |
			+------+-------------------------------------------------+
			| 10 | (Type J) IPv6 Prefix and Interface ID for link |
			| | endpoints as Local, Remote pair for SRv6 |
			+------+-------------------------------------------------+
			| 11 | (Type K) IPv6 Addresses for link endpoints as |
			| | Local, Remote pair for SRv6 |
			+------+-------------------------------------------------+
	Table 1 SR Segment Types		Table 1: SR Segment Types
	5.7.1.1.1. Type 1: SR-MPLS Label (Type A)		5.7.1.1.1. Type 1: Segment Type A
	The Segment is SR-MPLS type and is specified simply as the label.		The Segment is an SR-MPLS type and is specified simply as the label.
	The format of its Segment Descriptor is as follows:		The format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Algorithm |		| Algorithm |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 20 Type 1 Segment Descriptor		Figure 20: Type 1 Segment Descriptor
	Where:		Where:
	* Algorithm: 1-octet value that indicates the algorithm used for		Algorithm: 1-octet value that indicates the algorithm used for
	picking the SID. This is valid only when the A-flag has been set		picking the SID. This is valid only when the A-flag has been set
	in the Segment TLV. The algorithm values are from IGP Algorithm		in the Segment TLV. The algorithm values are from the "IGP
	Types registry under the IANA Interior Gateway Protocol (IGP)		Algorithm Types" IANA registry under the "Interior Gateway
	Parameters.		Protocol (IGP) Parameters" registry group.
	5.7.1.1.2. Type 2: SRv6 SID (Type B)		5.7.1.1.2. Type 2: Segment Type B
	The Segment is SRv6 type and is specified simply as the SRv6 SID		The Segment is an SRv6 type and is specified simply as SRv6 SID. The
	address. The format of its Segment Descriptor is as follows:		format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Algorithm |		| Algorithm |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 21 Type 2 Segment Descriptor		Figure 21: Type 2 Segment Descriptor
	Where:		Where:
	* Algorithm: 1-octet value that indicates the algorithm used for		Algorithm: 1-octet value that indicates the algorithm used for
	picking the SID. This is valid only when the A-flag has been set		picking the SID. This is valid only when the A-flag has been set
	in the Segment TLV. The algorithm values are from IGP Algorithm		in the Segment TLV. The algorithm values are from the "IGP
	Types registry under the IANA Interior Gateway Protocol (IGP)		Algorithm Types" IANA registry under the "Interior Gateway
	Parameters.		Protocol (IGP) Parameters" registry group.
	5.7.1.1.3. Type 3: SR-MPLS Prefix SID for IPv4 (Type C)		5.7.1.1.3. Type 3: Segment Type C
	The Segment is SR-MPLS Prefix SID type and is specified as an IPv4		The Segment is an SR-MPLS Prefix SID type and is specified as an IPv4
	node address. The format of its Segment Descriptor is as follows:		node address. The format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Algorithm |		| Algorithm |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Node Address (4 octets) |		| IPv4 Node Address (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 22 Type 3 Segment Descriptor		Figure 22: Type 3 Segment Descriptor
	Where:		Where:
	* Algorithm: 1-octet value that indicates the algorithm used for		Algorithm: 1-octet value that indicates the algorithm used for
	picking the SID. The algorithm values are from IGP Algorithm		picking the SID. The algorithm values are from the "IGP Algorithm
	Types registry under the IANA Interior Gateway Protocol (IGP)		Types" IANA registry under the "Interior Gateway Protocol (IGP)
	Parameters.		Parameters" registry group.
	* IPv4 Node Address: 4-octet value which carries the IPv4 address		IPv4 Node Address: 4-octet value that carries the IPv4 address
	associated with the node		associated with the node.
	5.7.1.1.4. Type 4: SR-MPLS Prefix SID for IPv6 (Type D)		5.7.1.1.4. Type 4: Segment Type D
	The Segment is SR-MPLS Prefix SID type and is specified as an IPv6		The Segment is an SR-MPLS Prefix SID type and is specified as an IPv6
	global address. The format of its Segment Descriptor is as follows:		node global address. The format of its segment descriptor is as
			follows:
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Algorithm |		| Algorithm |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IPv6 Node Global Address (16 octets) |		| IPv6 Node Global Address (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 23 Type 4 Segment Descriptor		Figure 23: Type 4 Segment Descriptor
	Where:		Where:
	* Algorithm: 1-octet value that indicates the algorithm used for		Algorithm: 1-octet value that indicates the algorithm used for
	picking the SID. The algorithm values are from IGP Algorithm		picking the SID. The algorithm values are from the "IGP Algorithm
	Types registry under the IANA Interior Gateway Protocol (IGP)		Types" IANA registry under the "Interior Gateway Protocol (IGP)
	Parameters.		Parameters" registry group.
	* IPv6 Node Global Address: 16-octet value which carries the IPv6		IPv6 Node Global Address: 16-octet value that carries the IPv6
	global address associated with the node		global address associated with the node.
	5.7.1.1.5. Type 5: SR-MPLS Adjacency SID for IPv4 with an Interface ID		5.7.1.1.5. Type 5: Segment Type E
	(Type E)
	The Segment is SR-MPLS Adjacency SID type and is specified as an IPv4		The Segment is an SR-MPLS Adjacency SID type and is specified as an
	node address along with the local interface ID on that node. The		IPv4 node address along with the local interface ID on that node.
	format of its Segment Descriptor is as follows:		The format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Node Address (4 octets) |		| IPv4 Node Address (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Interface ID (4 octets) |		| Local Interface ID (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 24 Type 5 Segment Descriptor		Figure 24: Type 5 Segment Descriptor
	Where:		Where:
	* IPv4 Node Address: 4-octet value which carries the IPv4 address		IPv4 Node Address: 4-octet value that carries the IPv4 address
	associated with the node		associated with the node.
	* Local Interface ID: 4-octet value which carries the local		Local Interface ID: 4-octet value that carries the local interface
	interface ID of the node identified by the Node Address		ID of the node identified by the Node Address.
	5.7.1.1.6. Type 6: SR-MPLS Adjacency SID for IPv4 with an Interface		5.7.1.1.6. Type 6: Segment Type F
	Address (Type F)
	The Segment is SR-MPLS Adjacency SID type and is specified as a pair		The Segment is an SR-MPLS Adjacency SID type and is specified as a
	of IPv4 local and remote addresses. The format of its Segment		pair of IPv4 local and remote interface addresses. The format of its
	Descriptor is as follows:		segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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		Figure 25: Type 6 Segment Descriptor
	Where:		Where:
	* IPv4 Local Address: 4-octet value which carries the local IPv4		IPv4 Local Interface Address: 4-octet value that carries the local
	address associated with the node's interface		IPv4 address associated with the node's interface.
	* IPv4 Remote Address: 4-octet value which carries the remote IPv4		IPv4 Remote Interface Address: 4-octet value that carries the remote
	address associated with interface on the node's neighbor. This is		IPv4 address associated with the interface on the node's neighbor.
	optional and MAY be set to 0 when not used (e.g. when identifying		This is optional and MAY be set to 0 when not used (e.g., when
	point-to-point links).		identifying point-to-point links).
	5.7.1.1.7. Type 7: SR-MPLS Adjacency SID for IPv6 with an interface ID		5.7.1.1.7. Type 7: Segment Type G
	(Type G)
	The Segment is SR-MPLS Adjacency SID type and is specified as a pair		The Segment is an SR-MPLS Adjacency SID type and is specified as a
	of IPv6 global address and interface ID for local and remote nodes.		pair of IPv6 global address and interface ID for local and remote
	The format of its Segment Descriptor is as follows:		nodes. The format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 26 Type 7 Segment Descriptor		Figure 26: Type 7 Segment Descriptor
	Where:		Where:
	* IPv6 Local Node Global Address: 16-octet value which carries the		IPv6 Local Node Global Address: 16-octet value that carries the IPv6
	IPv6 global address associated with the local node		global address associated with the local node.
	* Local Node Interface ID : 4-octet value which carries the		Local Node Interface ID: 4-octet value that carries the interface ID
	interface ID of the local node identified by the Local Node		of the local node identified by the Local Node Address.
	Address
	* IPv6 Remote Node Global Address: 16-octet value which carries the		IPv6 Remote Node Global Address: 16-octet value that carries the
	IPv6 global address associated with the remote node. This is		IPv6 global address associated with the remote node. This is
	optional and MAY be set to 0 when not used (e.g. when identifying		optional and MAY be set to 0 when not used (e.g., when identifying
	point-to-point links).		point-to-point links).
	* Remote Node Interface ID: 4-octet value which carries the		Remote Node Interface ID: 4-octet value that carries the interface
	interface ID of the remote node identified by the Remote Node		ID of the remote node identified by the Remote Node Address. This
	Address. This is optional and MAY be set to 0 when not used (e.g.		is optional and MAY be set to 0 when not used (e.g., when
	when identifying point-to-point links).		identifying point-to-point links).
	5.7.1.1.8. Type 8: SR-MPLS Adjacency SID for IPv6 with an Interface		5.7.1.1.8. Type 8: Segment Type H
	Address (Type H)
	The Segment is SR-MPLS Adjacency SID type and is specified as a pair		The Segment is an SR-MPLS Adjacency SID type and is specified as a
	of IPv6 Global addresses for local and remote interface addresses.		pair of IPv6 global addresses for local and remote interface
	The format of its Segment Descriptor is as follows:		addresses. The format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| 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) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 27 Type 8 Segment Descriptor		Figure 27: Type 8 Segment Descriptor
	Where:		Where:
	* IPv6 Local Address: 16-octet value which carries the local IPv6		IPv6 Local Global Address: 16-octet value that carries the local
	address associated with the node's interface		IPv6 address associated with the node's interface.
	* IPv6 Remote Address: 16-octet value which carries the remote IPv6		IPv6 Remote Global Address: 16-octet value that carries the remote
	address associated with the interface on the node's neighbor		IPv6 address associated with the interface on the node's neighbor.
	5.7.1.1.9. Type 9: SRv6 END SID as IPv6 Node Address (Type I)		5.7.1.1.9. Type 9: Segment Type I
	The Segment is SRv6 END SID type and is specified as an IPv6 global		The Segment is an SRv6 END SID type and is specified as an IPv6 node
	address. The format of its Segment Descriptor is as follows:		global address. The format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Algorithm |		| Algorithm |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IPv6 Node Global Address (16 octets) |		| IPv6 Node Global Address (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 28 Type 9 Segment Descriptor		Figure 28: Type 9 Segment Descriptor
	Where:		Where:
	* Algorithm: 1-octet value that indicates the algorithm used for		Algorithm: 1-octet value that indicates the algorithm used for
	picking the SID. The algorithm values are from IGP Algorithm		picking the SID. The algorithm values are from the "IGP Algorithm
	Types registry under the IANA Interior Gateway Protocol (IGP)		Types" IANA registry under the "Interior Gateway Protocol (IGP)
	Parameters.		Parameters" registry group.
	* IPv6 Node Global Address: 16-octet value which carries the IPv6		IPv6 Node Global Address: 16-octet value that carries the IPv6
	global address associated with the node		global address associated with the node.
	5.7.1.1.10. Type 10: SRv6 END.X SID as an Interface ID (Type J)		5.7.1.1.10. Type 10: Segment Type J
	The Segment is SRv6 END.X SID type and is specified as a pair of IPv6		The Segment is an SRv6 END.X SID type and is specified as a pair of
	global address and interface ID for local and remote nodes. The		IPv6 global address and interface ID for local and remote nodes. The
	format of its Segment Descriptor is as follows:		format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 29 Type 10 Segment Descriptor		Figure 29: Type 10 Segment Descriptor
	Where:		Where:
	* IPv6 Local Node Global Address: 16-octet value which carries the		IPv6 Local Node Global Address: 16-octet value that carries the IPv6
	IPv6 global address associated with the local node		global address associated with the local node.
	* Local Node Interface ID: 4-octet value which carries the interface		Local Node Interface ID: 4-octet value that carries the interface ID
	ID of the local node identified by the Local Node Address		of the local node identified by the Local Node Address.
	* IPv6 Remote Node Global Address: 16-octet value which carries the		IPv6 Remote Node Global Address: 16-octet value that carries the
	IPv6 global address associated with the remote node. This is		IPv6 global address associated with the remote node. This is
	optional and MAY be set to 0 when not used (e.g. when identifying		optional and MAY be set to 0 when not used (e.g., when identifying
	point-to-point links).		point-to-point links).
	* Remote Node Interface ID: 4-octet value which carries the		Remote Node Interface ID: 4-octet value that carries the interface
	interface ID of the remote node identified by the Remote Node		ID of the remote node identified by the Remote Node Address. This
	Address. This is optional and MAY be set to 0 when not used (e.g.		is optional and MAY be set to 0 when not used (e.g., when
	when identifying point-to-point links).		identifying point-to-point links).
	5.7.1.1.11. Type 11: SRv6 END.X SID as an Interface Address (Type K)		5.7.1.1.11. Type 11: Segment Type K
	The Segment is SRv6 END.X SID type and is specified as a pair of IPv6		The Segment is an SRv6 END.X SID type and is specified as a pair of
	Global addresses for local and remote interface addresses. The		IPv6 global addresses for local and remote interface addresses. The
	format of its Segment Descriptor is as follows:		format of its segment descriptor is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| 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) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 30 Type 11 Segment Descriptor		Figure 30: Type 11 Segment Descriptor
	Where:		Where:
	* IPv6 Local Address: 16-octet value which carries the local IPv6		IPv6 Local Global Address: 16-octet value that carries the local
	address associated with the node's interface		IPv6 address associated with the node's interface.
	* IPv6 Remote Address: 16-octet value which carries the remote IPv6		IPv6 Remote Global Address: 16-octet value that carries the remote
	address associated with the interface on the node's neighbor		IPv6 address associated with the interface on the node's neighbor.
	5.7.2. SR Segment List Metric Sub-TLV		5.7.2. SR Segment List Metric Sub-TLV
	The SR Segment List Metric sub-TLV reports the computed metric of the		The SR Segment List Metric sub-TLV reports the computed metric of the
	specific SID-List. It is used to report the type of metric and its		specific SID list. It is used to report the type of metric and its
	computed value by the computation entity (i.e., either the headend or		computed value by the computation entity (i.e., either the headend or
	the controller when the path is delegated) when available. More than		the controller when the path is delegated) when available. More than
	one instance of this sub-TLV may be present in SR Segment List to		one instance of this sub-TLV may be present in the SR Segment List to
	report metric values of different metric types. The metric margin		report metric values of different metric types. The metric margin
	and bound may be optionally reported using this sub-TLV when this		and bound may be optionally reported using this sub-TLV when this
	information is not being reported using the SR Metric Constraint sub-		information is not being reported using the SR Metric Constraint sub-
	TLV (refer to Section 5.6.6) at the SR candidate path level.		TLV (refer to Section 5.6.6) at the SR Policy candidate path level.
	It is a sub-TLV of the SR Segment List TLV and has the following		It is a sub-TLV of the SR Segment List TLV and has the following
	format:		format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 31 SR Segment List Metric Sub-TLV Format		Figure 31: SR Segment List Metric Sub-TLV Format
	Where:		Where:
	* Type: 1207		Type: 1207
	* Length: 16 octets		Length: 16 octets
	* Metric Type: 1-octet field which identifies the type of metric.		Metric Type: 1-octet field that identifies the type of metric. The
	The semantics are the same as the Metric Type field in the SR		semantics are the same as the metric type field in the SR Metric
	Metric Constraints sub-TLV in Section 5.6.6 of this document.		Constraint sub-TLV in Section 5.6.6 of this document.
	* Flags: 1-octet field that indicates the validity of the metric		Flags: 1-octet field that indicates the validity of the metric
	fields and their semantics. The following bit positions are		fields and their semantics. The following bit positions are
	defined and the other bits MUST be cleared by the originator and		defined, and the other bits MUST be cleared by the originator and
	MUST be ignored by a receiver.		MUST be ignored by a receiver.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|M|A|B|V| |		|M|A|B|V| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Where:		Where:
	- M-Flag: Indicates that the metric margin allowed for this path		M-Flag: Indicates that the metric margin allowed for this path
	computation is specified when set and indicates that metric		computation is specified when set and that the metric margin
	margin allowed is not specified when clear.		allowed is not specified when clear.
	- A-Flag: Indicates that the metric margin is specified as an		A-Flag: Indicates that the metric margin is specified as an
	absolute value when set and is expressed as a percentage of the		absolute value when set and that the metric margin is expressed
	minimum metric when clear.		as a percentage of the minimum metric when clear.
	- B-Flag: Indicates that the metric bound allowed for the path is		B-Flag: Indicates that the metric bound allowed for the path is
	specified when set and indicates that metric bound is not		specified when set and that the metric bound is not specified
	specified when clear.		when clear.
	- V-Flag: Indicates that the metric value computed is being		V-Flag: Indicates that the computed metric value is being
	reported when set and indicates that the computed metric value		reported when set and that the computed metric value is not
	is not being reported when clear.		being reported when clear.
	* RESERVED: 2 octets. MUST be set to 0 by the originator and MUST		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be
	be ignored by a receiver.		ignored by a receiver.
	* Metric Margin: 4-octet value which indicates the metric margin		Metric Margin: 4-octet value that indicates the metric margin value
	value when the M-flag is set. The metric margin is specified,		when the M-flag is set. The metric margin is specified, depending
	depending on the A-flag, as either an absolute value or as a		on the A-flag, as either an absolute value or a percentage of the
	percentage of the best computed path metric based on the specified		best computed path metric based on the specified constraints for
	constraints for path calculation. The metric margin allows for		path calculation. The metric margin allows for the metric value
	the metric value of the computed path to vary (depending on the		of the computed path to vary (depending on the semantics of the
	semantics of the specific metric type) from the best metric value		specific metric type) from the best metric value possible to
	possible to optimize for other factors (that are not specified as		optimizing for other factors (that are not specified as
	constraints) such as bandwidth availability, minimal SID stack		constraints) such as bandwidth availability, minimal SID stack
	depth, and maximizing of ECMP for the SR path computed.		depth, and the maximizing of ECMP for the computed SR path.
	* Metric Bound: 4-octet value which indicates the worst metric value		Metric Bound: 4-octet value that indicates the worst metric value
	(depending on the semantics of the specific metric type) that is		(depending on the semantics of the specific metric type) that is
	allowed when the B-flag is set. If the computed path metric		allowed when the B-flag is set. If the computed path metric
	crosses the specified bound value then the path is considered		crosses the specified bound value, then the path is considered
	invalid.		invalid.
	* Metric Value: 4-octet value which indicates the metric of the		Metric Value: 4-octet value that indicates the metric of the
	computed path when the V-flag is set. This value is available and		computed path when the V-flag is set. This value is available and
	reported when the computation is successful and a valid path is		reported when the computation is successful and a valid path is
	available.		available.
	The absolute metric margin, metric bound, and metric values are		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.		integer percentage value.
	5.7.3. SR Segment List Bandwidth Sub-TLV		5.7.3. SR Segment List Bandwidth Sub-TLV
	The SR Segment List Bandwidth sub-TLV is an optional sub-TLV used to		The SR Segment List Bandwidth sub-TLV is an optional sub-TLV used to
	report the bandwidth allocated to the specific SID-List by the path		report the bandwidth allocated to the specific SID list by the path
	computation entity. Only a single instance of this sub-TLV is		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
	as per section 8.2.2 of [RFC9552]) one is used and the rest are		malformed as per Section 8.2.2 of [RFC9552]) is used and the rest are
	ignored.		ignored.
	It is a sub-TLV of the SR Segment List TLV and has the following		It is a sub-TLV of the SR Segment List TLV and has the following
	format:		format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 32 SR Segment List Bandwidth Sub-TLV Format		Figure 32: SR Segment List Bandwidth Sub-TLV Format
	Where:		Where:
	* Type: 1216		Type: 1216
	* Length: 4 octets		Length: 4 octets
	* Bandwidth: 4 octets which specify the allocated bandwidth in unit		Bandwidth: 4 octets that specify the allocated bandwidth in unit of
	of bytes per second in IEEE floating point format [IEEE754].		bytes per second in IEEE floating point format [IEEE754].
	5.7.4. SR Segment List Identifier Sub-TLV		5.7.4. SR Segment List Identifier Sub-TLV
	The SR Segment List Identifier sub-TLV is an optional sub-TLV used to		The SR Segment List Identifier sub-TLV is an optional sub-TLV used to
	report an identifier associated with the specific SID-List. Only a		report an identifier associated with the specific SID list. Only a
	single instance of this sub-TLV is advertised for a given Segment		single instance of this sub-TLV is advertised for a given segment
	List. If multiple instances are present, then the first valid (i.e.,		list. If multiple instances are present, then the first valid one
	not determined to be malformed as per section 8.2.2 of [RFC9552]) one		(i.e., not determined to be malformed as per Section 8.2.2 of
	is used and the rest are ignored.		[RFC9552]) is used and the rest are ignored.
	It is a sub-TLV of the SR Segment List TLV and has the following		It is a sub-TLV of the SR Segment List TLV and has the following
	format:		format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 33 SR Segment List Identifier Sub-TLV Format		Figure 33: SR Segment List Identifier Sub-TLV Format
	Where:		Where:
	* Type: 1217		Type: 1217
	* Length: 4 octets
	* Segment List Identifier: 4 octets which carry a 32-bit unsigned		Length: 4 octets
	non-zero integer that serves as the identifier associated with the
			Segment List Identifier: 4 octets that carry a 32-bit unsigned non-
			zero integer that serves as the identifier associated with the
	segment list. A value of 0 indicates that there is no identifier		segment list. A value of 0 indicates that there is no identifier
	associated with the Segment List. The scope of this identifier is		associated with the segment list. The scope of this identifier is
	the SR Policy Candidate path.		the SR Policy candidate path.
	6. Procedures		6. Procedures
	The BGP-LS advertisements for the SR Policy Candidate Path NLRI type		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		Producer). The BGP-LS Producer may also be a node (e.g., a PCE) that
	is advertising on behalf of the headend.		is advertising on behalf of the headend.
	For the reporting of SR Policy Candidate Paths, the NLRI descriptor		For the reporting of SR Policy candidate paths, the NLRI descriptor
	TLV as specified in Section 4 is used. An SR Policy candidate path		TLV as specified in Section 4 is used. An SR Policy candidate path
	may be instantiated on the headend node via a local configuration,		may be instantiated on the headend node via a local configuration,
	PCEP, or BGP SR Policy signaling and this is indicated via the SR		PCEP, or BGP SR Policy signaling, and this is indicated via the SR
	Protocol Origin. When a PCE node is the BGP-LS Producer, it uses the		Protocol-Origin. When a PCE node is the BGP-LS Producer, it uses the
	"in PCEP" variants of the SR Protocol Origin (where available) so as		"in PCEP" variants of the SR Protocol-Origin (where available) so as
	to distinguish them from advertisements by headend nodes. The SR		to distinguish them from advertisements by headend nodes. The SR
	Policy Candidate Path's state and attributes are encoded in the BGP-		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		LS Attribute field as SR Policy State TLVs and sub-TLVs as described
	in Section 5. The SR Candidate Path State TLV as defined in		in Section 5. The SR Candidate Path State TLV as defined in
	Section 5.3 is included to report the state of the candidate path.		Section 5.3 is included to report the state of the candidate path.
	The SR BSID TLV as defined in Section 5.1 or Section 5.2 is included		The SR BSID TLV as defined in Sections 5.1 and 5.2 is included to
	to report the BSID of the candidate path when one is either specified		report the BSID of the candidate path when one is either specified or
	or allocated by the headend. The constraints and the optimization		allocated by the headend. The constraints and the optimization
	metric for the SR Policy Candidate Path are reported using the SR		metric for the SR Policy candidate path are reported using the SR
	Candidate Path Constraints TLV and its sub-TLVs as described in		Candidate Path Constraints TLV and its sub-TLVs as described in
	Section 5.6. The SR Segment List TLV is included for each of the		Section 5.6. The SR Segment List TLV is included for each SID
	SID-List(s) associated with the candidate path. Each SR Segment List		list(s) associated with the candidate path. Each SR Segment List TLV
	TLV in turn includes SR Segment sub-TLV(s) to report the segment(s)		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		and its status. The SR Segment List Metric sub-TLV is used to report
	report the metric values at an individual SID List level.		the metric values at an individual SID list level.
	7. Manageability Considerations		7. Manageability Considerations
	The Existing BGP operational and management procedures apply to this		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 [RFC9552] apply to this document.		considerations as specified in [RFC9552] apply to this document.
	In general, the SR Policy head-end nodes are responsible for the		In general, the SR Policy headend nodes are responsible for the
	advertisement of SR Policy state information.		advertisement of SR Policy state information.
	8. IANA Considerations		8. IANA Considerations
	This section describes the code point allocation by IANA for this		This section describes the code point allocations by IANA for this
	document.		document.
	8.1. BGP-LS NLRI-Types		8.1. BGP-LS NLRI Types
	IANA maintains a registry called "BGP-LS NLRI-Types" in the "Border		IANA maintains a registry called "BGP-LS NLRI Types" under the
	Gateway Protocol - Link State (BGP-LS) Parameters" registry group.		"Border Gateway Protocol - Link State (BGP-LS) Parameters" registry
			group.
	The following table lists the code points that have been allocated by		The following NLRI Type code point has been allocated by IANA:
	IANA:
	+------+-------------------------------+---------------+		+======+===============================+===========+
	| Type | NLRI Type | Reference |		| Type | NLRI Type | Reference |
	+------+-------------------------------+---------------+		+======+===============================+===========+
	| 5 | SR Policy Candidate Path NLRI | this document |		| 5 | SR Policy Candidate Path NLRI | RFC 9857 |
	+------+-------------------------------+---------------+		+------+-------------------------------+-----------+
	Table 2 NLRI Type Codepoint		Table 2: NLRI Type Code Point
	8.2. BGP-LS Protocol-IDs		8.2. BGP-LS Protocol-IDs
	IANA maintains a registry called "BGP-LS Protocol-IDs" in the "Border		IANA maintains a registry called "BGP-LS Protocol-IDs" under the
	Gateway Protocol - Link State (BGP-LS) Parameters" registry group.		"Border Gateway Protocol - Link State (BGP-LS) Parameters" registry
			group.
	The following Protocol-ID codepoints have been allocated by IANA:		The following Protocol-ID code point has been allocated by IANA:
	+-------------+----------------------------------+---------------+		+=============+==================================+===========+
	| Protocol-ID | NLRI information source protocol | Reference |		| Protocol-ID | NLRI information source protocol | Reference |
	+-------------+----------------------------------+---------------+		+=============+==================================+===========+
	| 9 | Segment Routing | this document |		| 9 | Segment Routing | RFC 9857 |
	+-------------+----------------------------------+---------------+		+-------------+----------------------------------+-----------+
	Table 3 Protocol ID Codepoint		Table 3: Protocol-ID Code Point
	8.3. BGP-LS TLVs		8.3. BGP-LS TLVs
	IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs" in		IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs"
	the "Border Gateway Protocol - Link State (BGP-LS) Parameters"		under the "Border Gateway Protocol - Link State (BGP-LS) Parameters"
	registry group.		registry group.
	The following table lists the TLV code points that have been		The following table lists the TLV code points that have been
	allocated by IANA:		allocated by IANA:
	+-------+----------------------------------------+---------------+		+================+=====================================+===========+
	| Code | Description | Value defined |		| TLV Code Point | Description | Reference |
	| Point | | in |		+================+=====================================+===========+
	+-------+----------------------------------------+---------------+		| 554 | SR Policy Candidate Path Descriptor | RFC 9857 |
	| 554 | SR Policy Candidate Path Descriptor | this document |		+----------------+-------------------------------------+-----------+
	| 1201 | SR Binding SID | this document |		| 1201 | SR Binding SID | RFC 9857 |
	| 1202 | SR Candidate Path State | this document |		+----------------+-------------------------------------+-----------+
	| 1203 | SR Candidate Path Name | this document |		| 1202 | SR Candidate Path State | RFC 9857 |
	| 1204 | SR Candidate Path Constraints | this document |		+----------------+-------------------------------------+-----------+
	| 1205 | SR Segment List | this document |		| 1203 | SR Candidate Path Name | RFC 9857 |
	| 1206 | SR Segment | this document |		+----------------+-------------------------------------+-----------+
	| 1207 | SR Segment List Metric | this document |		| 1204 | SR Candidate Path Constraints | RFC 9857 |
	| 1208 | SR Affinity Constraint | this document |		+----------------+-------------------------------------+-----------+
	| 1209 | SR SRLG Constraint | this document |		| 1205 | SR Segment List | RFC 9857 |
	| 1210 | SR Bandwidth Constraint | this document |		+----------------+-------------------------------------+-----------+
	| 1211 | SR Disjoint Group Constraint | this document |		| 1206 | SR Segment | RFC 9857 |
	| 1212 | SRv6 Binding SID | this document |		+----------------+-------------------------------------+-----------+
	| 1213 | SR Policy Name | this document |		| 1207 | SR Segment List Metric | RFC 9857 |
	| 1214 | SR Bidirectional Group Constraint | this document |		+----------------+-------------------------------------+-----------+
	| 1215 | SR Metric Constraint | this document |		| 1208 | SR Affinity Constraint | RFC 9857 |
	| 1216 | SR Segment List Bandwidth | this document |		+----------------+-------------------------------------+-----------+
	| 1217 | SR Segment List Identifier | this document |		| 1209 | SR SRLG Constraint | RFC 9857 |
	+-------+----------------------------------------+---------------+		+----------------+-------------------------------------+-----------+
			| 1210 | SR Bandwidth Constraint | RFC 9857 |
	Table 4 NLRI and Attribute TLVs Codepoint		+----------------+-------------------------------------+-----------+
			| 1211 | SR Disjoint Group Constraint | RFC 9857 |
			+----------------+-------------------------------------+-----------+
			| 1212 | SRv6 Binding SID | RFC 9857 |
			+----------------+-------------------------------------+-----------+
			| 1213 | SR Policy Name | RFC 9857 |
			+----------------+-------------------------------------+-----------+
			| 1214 | SR Bidirectional Group Constraint | RFC 9857 |
			+----------------+-------------------------------------+-----------+
			| 1215 | SR Metric Constraint | RFC 9857 |
			+----------------+-------------------------------------+-----------+
			| 1216 | SR Segment List Bandwidth | RFC 9857 |
			+----------------+-------------------------------------+-----------+
			| 1217 | SR Segment List Identifier | RFC 9857 |
			+----------------+-------------------------------------+-----------+
	8.4. SR Policy Protocol Origin		Table 4: NLRI and Attribute TLV Code Points
	Note to IANA (RFC editor to remove this before publication): The new		8.4. SR Policy Protocol-Origin
	registry creation request below is also present in the draft-ietf-
	pce-segment-routing-policy-cp. IANA is requested to process the
	registry creation via the first of these two documents to reach
	publication stage and the authors of the other document would update
	the IANA considerations suitably. The initial allocations in this
	document are a super-set of the initial allocations in draft-ietf-
	pce-segment-routing-policy-cp.
	This document requests IANA to maintain a new registry under "Segment		Per this document, IANA has created and maintains a new registry
	Routing" registry group with the allocation policy of "Expert Review"		called "SR Policy Protocol-Origin" under the "Segment Routing"
	[RFC8126] using the guidelines for Designated Experts as specified in		registry group with the allocation policy of Expert Review [RFC8126]
	[RFC9256]. The new registry is called "SR Policy Protocol Origin"		using the guidelines for designated experts as specified in
	and should have the reference to this document. This registry		[RFC9256]. This registry contains the code points allocated to the
	contains the codepoints allocated to the "Protocol Origin" field		"Protocol-Origin" field defined in Section 4.
	defined in Section 4.
	The registry contains the following codepoints, with initial values,		IANA has assigned the initial values as follows:
	to be assigned by IANA with the reference set to this document:
	+---------+--------------------------------------+---------------+		+=========+================================+===========+
	| Code | | |		| Code | Protocol-Origin | Reference |
	| Point | Protocol Origin | Reference |		| Point | | |
	+---------+--------------------------------------+---------------+		+=========+================================+===========+
	| 0 | Reserved (not to be used) | this document |		| 0 | Reserved | RFC 9857 |
	| 1 | PCEP | this document |		+---------+--------------------------------+-----------+
	| 2 | BGP SR Policy | this document |		| 1 | PCEP | RFC 9857 |
	| 3 | Configuration (CLI, YANG model via | this document |		+---------+--------------------------------+-----------+
	| | NETCONF, etc.) | |		| 2 | BGP SR Policy | RFC 9857 |
	| 4-9 | Unassigned | this document |		+---------+--------------------------------+-----------+
	| 10 | PCEP (In PCEP or when | this document |		| 3 | Configuration (CLI, YANG model | RFC 9857 |
	| | BGP-LS Producer is PCE) | |		| | via NETCONF, etc.) | |
	| 11-19 | Unassigned | this document |		+---------+--------------------------------+-----------+
	| 20 | BGP SR Policy (In PCEP or when | this document |		| 4-9 | Unassigned | RFC 9857 |
	| | BGP-LS Producer is PCE) | |		+---------+--------------------------------+-----------+
	| 21-29 | Unassigned | this document |		| 10 | PCEP (in PCEP or when BGP-LS | RFC 9857 |
	| 30 | Configuration (CLI, YANG model via | this document |		| | Producer is PCE) | |
	| | NETCONF, etc.) (In PCEP or when | |		+---------+--------------------------------+-----------+
	| | BGP-LS Producer is PCE) | |		| 11-19 | Unassigned | RFC 9857 |
	| 31-250 | Unassigned | this document |		+---------+--------------------------------+-----------+
	| 251-255 | Private Use (not to be assigned by | this document |		| 20 | BGP SR Policy (in PCEP or when | RFC 9857 |
	| | IANA) | |		| | BGP-LS Producer is PCE) | |
	+---------+--------------------------------------+---------------+		+---------+--------------------------------+-----------+
			| 21-29 | Unassigned | RFC 9857 |
			+---------+--------------------------------+-----------+
			| 30 | Configuration (CLI, YANG model | RFC 9857 |
			| | via NETCONF, etc. In PCEP or | |
			| | when BGP-LS Producer is PCE) | |
			+---------+--------------------------------+-----------+
			| 31-250 | Unassigned | RFC 9857 |
			+---------+--------------------------------+-----------+
			| 251-255 | Reserved for Private Use | RFC 9857 |
			+---------+--------------------------------+-----------+
	Table 5 SR Policy Protocol Origin Codepoint		Table 5: SR Policy Protocol-Origin Code Points
	8.5. BGP-LS SR Segment Descriptors		8.5. BGP-LS SR Segment Descriptors
	This document requests IANA to create a registry called "SR Segment		Per this document, IANA has created a registry called "BGP-LS SR
	Descriptor Types" under the "Border Gateway Protocol - Link State		Segment Descriptor Types" under the "Border Gateway Protocol - Link
	(BGP-LS) Parameters" registry group with the allocation policy of		State (BGP-LS) Parameters" registry group with the allocation policy
	"Expert Review" [RFC8126] using the guidelines for Designated Experts		of Expert Review [RFC8126] using the guidelines for designated
	as specified in [RFC9552]. There is also an additional guideline to		experts as specified in [RFC9552]. There is also an additional
	the Designated Experts to maintain the alignment between the		guideline for the designated experts to maintain the alignment
	allocations in this registry with those in the "Segment Types"		between the allocations in this registry with those in the "Segment
	registry under the "Segment Routing" registry group. This requires		Types" registry under the "Segment Routing" registry group. This
	that an allocation in the Segment Routing "Segment Types" registry is		requires that an allocation in the Segment Routing "Segment Types"
	required before allocation can be done in the BGP-LS "SR Segment		registry is required before allocation can be done in the "BGP-LS SR
	Descriptor Types" registry for a new segment type. However, this		Segment Descriptor Types" registry for a new segment type. However,
	does not mandate that the specification of a new Segment Routing		this does not mandate that the specification of a new Segment Routing
	Segment Type also requires the specification of its equivalent SR		Segment Type also requires the specification of its equivalent SR
	Segment Descriptor Type in BGP-LS; that can be done as and when		Segment Descriptor Type in BGP-LS; that can be done as and when
	required while maintaining alignment.		required while maintaining alignment.
	This registry contains the codepoints allocated to the "Segment Type"		This registry contains the code points allocated to the "Segment
	field defined in Section 5.7.1 and described in Section 5.7.1.1. The		Type" field defined in Section 5.7.1 and described in
	registry contains the following codepoints, with initial values, to		Section 5.7.1.1. IANA has assigned the initial values as follows:
	be assigned by IANA with the reference set to this document:
	+---------+---------------------------------------+---------------+		+============+====================+===========+
	| Code | Segment Description | Reference |		| Code Point | Segment Descriptor | Reference |
	| Point | | |		+============+====================+===========+
	+--------+----------------------------------------+---------------+		| 0 | Reserved | RFC 9857 |
	| 0 | Reserved (not to be used) | this document |		+------------+--------------------+-----------+
	| 1 | (Type A) SR-MPLS Label | this document |		| 1 | Type A Segment | RFC 9857 |
	| 2 | (Type B) SRv6 SID as IPv6 address | this document |		+------------+--------------------+-----------+
	| 3 | (Type C) SR-MPLS Prefix SID as | this document |		| 2 | Type B Segment | RFC 9857 |
	| | IPv4 Node Address | |		+------------+--------------------+-----------+
	| 4 | (Type D) SR-MPLS Prefix SID as | this document |		| 3 | Type C Segment | RFC 9857 |
	| | IPv6 Node Global Address | |		+------------+--------------------+-----------+
	| 5 | (Type E) SR-MPLS Adjacency SID as | this document |		| 4 | Type D Segment | RFC 9857 |
	| | IPv4 Node Address & Local Interface ID | |		+------------+--------------------+-----------+
	| 6 | (Type F) SR-MPLS Adjacency SID as | this document |		| 5 | Type E Segment | RFC 9857 |
	| | IPv4 Local & Remote Interface Addresses| |		+------------+--------------------+-----------+
	| 7 | (Type G) SR-MPLS Adjacency SID as pair | this document |		| 6 | Type F Segment | RFC 9857 |
	| | of IPv6 Global Address & Interface ID | |		+------------+--------------------+-----------+
	| | for Local & Remote nodes | |		| 7 | Type G Segment | RFC 9857 |
	| 8 | (Type H) SR-MPLS Adjacency SID as pair | this document |		+------------+--------------------+-----------+
	| | of IPv6 Global Addresses for the | |		| 8 | Type H Segment | RFC 9857 |
	| | Local & Remote Interface | |		+------------+--------------------+-----------+
	| 9 | (Type I) SRv6 END SID as IPv6 Node | this document |		| 9 | Type I Segment | RFC 9857 |
	| | Global Address		+------------+--------------------+-----------+
	| 10 | (Type J) SRv6 END.X SID as pair of | this document |		| 10 | Type J Segment | RFC 9857 |
	| | IPv6 Global Address & Interface ID for | |		+------------+--------------------+-----------+
	| | Local & Remote nodes | |		| 11 | Type K Segment | RFC 9857 |
	| 11 | (Type K) SRv6 END.X SID as pair of | this document |		+------------+--------------------+-----------+
	| | IPv6 Global Addresses for the | |		| 12-255 | Unassigned | RFC 9857 |
	| | Local & Remote Interface | |		+------------+--------------------+-----------+
	| 12-255 | Unassigned | this document |
	+--------+----------------------------------------+---------------+
	Table 6 SR Segment Descriptor Types Codepoint		Table 6: BGP-LS SR Segment Descriptor Type
			Code Points
	8.6. BGP-LS SR Policy Metric Type		8.6. BGP-LS SR Policy Metric Type
	This document requests IANA to create a registry called "BGP-LS SR		Per this document, IANA has created a registry called "BGP-LS SR
	Policy Metric Type" under the "Border Gateway Protocol - Link State		Policy Metric 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" [RFC8126] using the guidelines for Designated Experts		Expert Review [RFC8126] using the guidelines for designated experts
	as specified in [RFC9552]. This registry contains the codepoints		as specified in [RFC9552]. This registry contains the code points
	allocated to the "metric type" field defined in Section 5.7.2. The		allocated to the metric type field defined in Section 5.7.2. IANA
	registry contains the following codepoints, with initial values, to		has assigned the initial values as follows:
	be assigned by IANA with the reference set to this document:
	+---------+--------------------------------+---------------------+		+============+================================+===========+
	| Code | | |		| Code Point | Metric Type | Reference |
	| Point | Metric Type | Reference |		+============+================================+===========+
	+---------+--------------------------------+---------------------+		| 0 | IGP | RFC 9857 |
	| 0 | IGP | this document |		+------------+--------------------------------+-----------+
	| 1 | Min Unidirectional Delay | this document |		| 1 | Min Unidirectional Delay | RFC 9857 |
	| 2 | TE | this document |		+------------+--------------------------------+-----------+
	| 3 | Hop Count | this document |		| 2 | TE | RFC 9857 |
	| 4 | SID List Length | this document |		+------------+--------------------------------+-----------+
	| 5 | Bandwidth | this document |		| 3 | Hop Count | RFC 9857 |
	| 6 | Avg Unidirectional Delay | this document |		+------------+--------------------------------+-----------+
	| 7 | Unidirectional Delay Variation | this document |		| 4 | SID List Length | RFC 9857 |
	| 8 | Loss | this document |		+------------+--------------------------------+-----------+
	| 9-127 | Unassigned | this document |		| 5 | Bandwidth | RFC 9857 |
	| 128-255 | User Defined | this document |		+------------+--------------------------------+-----------+
	+---------+--------------------------------+---------------------+		| 6 | Avg Unidirectional Delay | RFC 9857 |
			+------------+--------------------------------+-----------+
			| 7 | Unidirectional Delay Variation | RFC 9857 |
			+------------+--------------------------------+-----------+
			| 8 | Loss | RFC 9857 |
			+------------+--------------------------------+-----------+
			| 9-127 | Unassigned | RFC 9857 |
			+------------+--------------------------------+-----------+
			| 128-255 | User Defined | RFC 9857 |
			+------------+--------------------------------+-----------+
	Table 7 SR Policy Metric Type Codepoint		Table 7: SR Policy Metric Type Code Point
	9. Security Considerations		9. Security Considerations
	Procedures and protocol extensions defined in this document do not		Procedures and protocol extensions defined in this document do not
	affect the base BGP security model. See [RFC6952] for details. The		affect the base BGP security model. See [RFC6952] for details. The
	security considerations of the base BGP-LS specification as described		security considerations of the base BGP-LS specification as described
	in [RFC9552] also apply.		in [RFC9552] also apply.
	The BGP-LS SR Policy extensions specified in this document enable		The BGP-LS SR Policy extensions specified in this document enable TE
	traffic engineering and service programming use-cases within an SR		and service programming use cases within an SR domain as described in
	domain as described in [RFC9256]. SR operates within a trusted SR		[RFC9256]. SR operates within a trusted SR domain [RFC8402], and its
	domain [RFC8402] and its security considerations also apply to BGP		security considerations also apply to BGP sessions when carrying SR
	sessions when carrying SR Policy information. The SR Policies		Policy information. The SR Policies advertised to controllers and
	advertised to controllers and other applications via BGP-LS are		other applications via BGP-LS are expected to be used entirely within
	expected to be used entirely within this trusted SR domain, i.e.,		this trusted SR domain, i.e., within a single AS or between multiple
	within a single AS or between multiple ASes/domains within a single		ASes/domains within a single provider network. Therefore, precaution
	provider network. Therefore, precaution is necessary to ensure that		is necessary to ensure that the SR Policy information advertised via
	the SR Policy information advertised via BGP sessions is limited to		BGP sessions is limited to nodes and/or controllers/applications in a
	nodes and/or controllers/applications in a secure manner within this		secure manner within this trusted SR domain. The general guidance
	trusted SR domain. The general guidance for BGP-LS with respect to		for BGP-LS with respect to isolation of BGP-LS sessions from BGP
	isolation of BGP-LS sessions from BGP sessions for other address-		sessions for other address-families (refer to the security
	families (refer security considerations of [RFC9552]) may be used to		considerations of [RFC9552]) may be used to ensure that the SR Policy
	ensure that the SR Policy information is not advertised by accident		information is not advertised to an External BGP (EBGP) peering
	or error to an EBGP peering session outside the SR domain.		session outside the SR domain by accident or error.
	Additionally, it may be considered that the export of SR Policy		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 the
	confidentiality of mission-critical or commercially sensitive		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		addresses, SR SIDs, and the SR Policies deployed). BGP peerings are
	not automatic and require configuration. Thus, it is the		not automatic and require configuration. Thus, it is the
	responsibility of the network operator to ensure that only trusted		responsibility of the network operator to ensure that only trusted
	nodes (that include both routers and controller applications) within		nodes (that include both routers and controller applications) within
	the SR domain are configured to receive such information.		the SR domain are configured to receive such information.
	10. Contributors		10. References
	The following people have substantially contributed to the editing of
	this document:
	Clarence Filsfils
	Cisco Systems
	Email: cfilsfil@cisco.com
	Mach (Guoyi) Chen
	Huawei Technologies
	Email: mach.chen@huawei.com
	11. Acknowledgements
	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.
	12. References
	12.1. Normative References
	[I-D.ietf-lsr-flex-algo-bw-con]		10.1. Normative References
	Hegde, S., Britto, W., Shetty, R., Decraene, B., Psenak,
	P., and T. Li, "IGP Flexible Algorithms: Bandwidth, Delay,
	Metrics and Constraints", Work in Progress, Internet-
	Draft, draft-ietf-lsr-flex-algo-bw-con-22, 13 February
	2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
	lsr-flex-algo-bw-con-22>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,		DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.		<https://www.rfc-editor.org/info/rfc2328>.
	skipping to change at page 55, line 51 ¶		skipping to change at line 2547 ¶
	Bernier, D., and B. Decraene, "Border Gateway Protocol -		Bernier, D., and B. Decraene, "Border Gateway Protocol -
	Link State (BGP-LS) Extensions for Segment Routing over		Link State (BGP-LS) Extensions for Segment Routing over
	IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December		IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December
	2023, <https://www.rfc-editor.org/info/rfc9514>.		2023, <https://www.rfc-editor.org/info/rfc9514>.
	[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and		[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
	Traffic Engineering Information Using BGP", RFC 9552,		Traffic Engineering Information Using BGP", RFC 9552,
	DOI 10.17487/RFC9552, December 2023,		DOI 10.17487/RFC9552, December 2023,
	<https://www.rfc-editor.org/info/rfc9552>.		<https://www.rfc-editor.org/info/rfc9552>.
	12.2. Informative References		[RFC9843] Hegde, S., Britto, W., Shetty, R., Decraene, B., Psenak,
			P., and T. Li, "IGP Flexible Algorithms: Bandwidth, Delay,
			Metrics, and Constraints", RFC 9843, DOI 10.17487/RFC9843,
			September 2025, <https://www.rfc-editor.org/info/rfc9843>.
	[I-D.ietf-idr-bgp-ls-te-path]		10.2. Informative References
	Previdi, S., Talaulikar, K., Dong, J., Gredler, H., and J.
	Tantsura, "Advertisement of Traffic Engineering Paths
	using BGP Link-State", Work in Progress, Internet-Draft,
	draft-ietf-idr-bgp-ls-te-path-02, 11 November 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
	ls-te-path-02>.
	[I-D.ietf-idr-bgp-sr-segtypes-ext]		[BGP-LS-TE-PATH]
	Talaulikar, K., Filsfils, C., Previdi, S., Mattes, P., and		Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H.,
	D. Jain, "Segment Routing Segment Types Extensions for BGP		and J. Tantsura, "Advertisement of Traffic Engineering
	SR Policy", Work in Progress, Internet-Draft, draft-ietf-		Paths using BGP Link-State", Work in Progress, Internet-
	idr-bgp-sr-segtypes-ext-08, 20 February 2025,		Draft, draft-ietf-idr-bgp-ls-te-path-02, 11 November 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-		<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
	sr-segtypes-ext-08>.		ls-te-path-02>.
	[I-D.ietf-idr-sr-policy-safi]
	Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
	D. Jain, "Advertising Segment Routing Policies in BGP",
	Work in Progress, Internet-Draft, draft-ietf-idr-sr-
	policy-safi-13, 6 February 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
	policy-safi-13>.
	[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE		[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
	Standard for Floating-Point Arithmetic", IEEE 754-2019,		Std 754-2019, DOI 10.1109/ieeestd.2019.8766229, 22 July
	DOI 10.1109/ieeestd.2019.8766229, 22 July 2019,		2019, <https://ieeexplore.ieee.org/document/8766229>.
	<https://ieeexplore.ieee.org/document/8766229>.
	[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.		[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
	McManus, "Requirements for Traffic Engineering Over MPLS",		McManus, "Requirements for Traffic Engineering Over MPLS",
	RFC 2702, DOI 10.17487/RFC2702, September 1999,		RFC 2702, DOI 10.17487/RFC2702, September 1999,
	<https://www.rfc-editor.org/info/rfc2702>.		<https://www.rfc-editor.org/info/rfc2702>.
	[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions		[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
	in Support of Generalized Multi-Protocol Label Switching		in Support of Generalized Multi-Protocol Label Switching
	(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,		(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
	<https://www.rfc-editor.org/info/rfc4202>.		<https://www.rfc-editor.org/info/rfc4202>.
	skipping to change at page 57, line 28 ¶		skipping to change at line 2609 ¶
	Extensions for Stateful PCE", RFC 8231,		Extensions for Stateful PCE", RFC 8231,
	DOI 10.17487/RFC8231, September 2017,		DOI 10.17487/RFC8231, September 2017,
	<https://www.rfc-editor.org/info/rfc8231>.		<https://www.rfc-editor.org/info/rfc8231>.
	[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,		[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
	"Path Computation Element Communication Protocol (PCEP)		"Path Computation Element Communication Protocol (PCEP)
	Extension for Label Switched Path (LSP) Diversity		Extension for Label Switched Path (LSP) Diversity
	Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,		Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
	July 2020, <https://www.rfc-editor.org/info/rfc8800>.		July 2020, <https://www.rfc-editor.org/info/rfc8800>.
			[RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
			P., and D. Jain, "Advertising Segment Routing Policies in
			BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
			<https://www.rfc-editor.org/info/rfc9830>.
			[RFC9831] Talaulikar, K., Ed., Filsfils, C., Previdi, S., Mattes,
			P., and D. Jain, "Segment Type Extensions for BGP Segment
			Routing (SR) Policy", RFC 9831, DOI 10.17487/RFC9831,
			September 2025, <https://www.rfc-editor.org/info/rfc9831>.
			Acknowledgements
			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 reviews
			and valuable comments. The authors would also like to thank Susan
			Hares for her shepherd review 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.
			Contributors
			The following people have contributed substantially to the content of
			this document and should be considered coauthors:
			Clarence Filsfils
			Cisco Systems
			Email: cfilsfil@cisco.com
			Mach(Guoyi) Chen
			Huawei Technologies
			Email: mach.chen@huawei.com
	Authors' Addresses		Authors' Addresses
	Stefano Previdi		Stefano Previdi
	Individual		Individual
	Email: stefano@previdi.net		Email: stefano@previdi.net
	Ketan Talaulikar (editor)		Ketan Talaulikar (editor)
	Cisco Systems		Cisco Systems
	India		India
	Email: ketant.ietf@gmail.com		Email: ketant.ietf@gmail.com
End of changes. 447 change blocks.
	1262 lines changed or deleted		1277 lines changed or added
This html diff was produced by rfcdiff 1.48.