rfc9857v1.txt		rfc9857.txt
	skipping to change at line 14 ¶		skipping to change at line 14 ¶
	Category: Standards Track K. Talaulikar, Ed.		Category: Standards Track K. Talaulikar, Ed.
	ISSN: 2070-1721 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
	September 2025		September 2025
	Advertisement of Segment Routing Policies Using BGP Link-State		Advertisement of Segment Routing Policies Using BGP - Link State
	Abstract		Abstract
	This document describes a mechanism used to collect Segment Routing		This document describes a mechanism used to collect Segment Routing
	(SR) Policy information that is locally available in a node and		(SR) Policy information that is locally available in a node and
	advertise it into BGP Link-State (BGP-LS) updates. Such information		advertise it into BGP - Link State (BGP-LS) updates. Such
	can be used by external components for path computation,		information can be used by external components for path computation,
	reoptimization, service placement, network visualization, etc.		reoptimization, service placement, network visualization, etc.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	skipping to change at line 86 ¶		skipping to change at line 86 ¶
	5.7.1. SR Segment Sub-TLV		5.7.1. SR Segment Sub-TLV
	5.7.2. SR Segment List Metric Sub-TLV		5.7.2. SR Segment List Metric Sub-TLV
	5.7.3. SR Segment List Bandwidth Sub-TLV		5.7.3. SR Segment List Bandwidth Sub-TLV
	5.7.4. SR Segment List Identifier Sub-TLV		5.7.4. SR Segment List Identifier Sub-TLV
	6. Procedures		6. Procedures
	7. Manageability Considerations		7. Manageability Considerations
	8. IANA Considerations		8. IANA Considerations
	8.1. BGP-LS NLRI Types		8.1. BGP-LS NLRI Types
	8.2. BGP-LS Protocol-IDs		8.2. BGP-LS Protocol-IDs
	8.3. BGP-LS TLVs		8.3. BGP-LS TLVs
	8.4. SR Policy Protocol Origin		8.4. SR Policy Protocol-Origin
	8.5. BGP-LS SR Segment Descriptors		8.5. BGP-LS SR Segment Descriptors
	8.6. BGP-LS SR Policy Metric Type		8.6. BGP-LS SR Policy Metric Type
	9. Security Considerations		9. Security Considerations
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	10.2. Informative References		10.2. Informative References
	Acknowledgements		Acknowledgements
	Contributors		Contributors
	Authors' Addresses		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 the 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-Lists of which one or more SID-Lists may be		have one or more SID lists of which one or more SID lists may be
	active. When multiple SID-Lists are active, traffic is load balanced		active. When multiple SID lists are active, traffic is load 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 headend 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., the Path Computation		node using various APIs and protocols (e.g., the Path Computation
	Element Communication Protocol (PCEP) or BGP).		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.
	skipping to change at line 127 ¶		skipping to change at line 127 ¶
	functions 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 can provide benefits in path optimization.		(PCE) [RFC8231], which can provide benefits in path optimization.
	While some extensions are proposed in the PCEP for Path Computation		While some extensions are proposed in the PCEP for Path Computation
	Clients (PCCs) to report Label Switched Path (LSP) states to the PCE,		Clients (PCCs) to report Label Switched Path (LSP) states to the PCE,
	this mechanism may not be applicable in a management-based PCE		this mechanism may not be applicable in a management-based PCE
	architecture as specified in Section 5.5 of [RFC4655]. As		architecture as specified in Section 5.5 of [RFC4655]. As
	illustrated in the figure below, the PCC is not a Label Switching		illustrated in the figure below, the PCC is not a Label Switching
	Router (LSR) in the routing domain, thus the headend nodes of the SR		Router (LSR) in the routing domain, thus the headend nodes of 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
	Label Edge Routers (LERs) is needed. This document proposes an SR		Routers (LERs) is needed. This document proposes an SR Policy state
	Policy state collection mechanism complementary to the mechanism		collection mechanism complementary to the mechanism defined in
	defined in [RFC8231].		[RFC8231].
	-----------		-----------
	| ----- |		| ----- |
	Service | | TED |<-+----------->		Service | | TED |<-+----------->
	Request | ----- | TED synchronization		Request | ----- | TED synchronization
	| | | | mechanism (e.g., the		| | | | mechanism (e.g., the
	v | | | routing protocol)		v | | | routing protocol)
	------------- Request/ | v |		------------- Request/ | v |
	| | Response| ----- |		| | Response| ----- |
	| NMS |<--------+> | PCE | |		| NMS |<--------+> | PCE | |
	skipping to change at line 246 ¶		skipping to change at line 246 ¶
	// 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 the 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 Descriptors 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 the 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 Descriptors" (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 Descriptors 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 Descriptors 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
	skipping to change at line 327 ¶		skipping to change at line 325 ¶
	The Local Node Descriptors 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, it contains the headend node of the SR		confederations are used, it contains the headend node of the SR
	Policy.		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 as the Protocol-ID in the NLRI is always going to be		sub-TLV as the Protocol-ID in the NLRI is always going to be
	"Segment Routing".		"Segment Routing".
	3.2. PCE as the 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 Descriptors 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
	skipping to change at line 357 ¶		skipping to change at line 355 ¶
	AS Confederation Identifier [RFC5065], if confederations are used)		AS Confederation Identifier [RFC5065], if 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, it contains the headend node of the SR		confederations are used, it contains the headend node of the SR
	Policy.		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 PCE node is functioning as the BGP-LS Producer on behalf of		When a PCE node is functioning as the BGP-LS Producer on behalf of
	one or more headends, it MAY include its own BGP Router-ID (TLV 516),		one or more headends, it MAY include its own BGP Router-ID (TLV 516),
	Autonomous System (TLV 512), or BGP Confederation Member (TLV 517) in		Autonomous System (TLV 512), or BGP 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 an SR Policy		The SR Policy Candidate Path Descriptor TLV identifies an SR Policy
	candidate path as defined in [RFC9256]. It is a mandatory TLV for		candidate path as defined in [RFC9256]. It is a mandatory TLV for
	skipping to change at line 500 ¶		skipping to change at line 498 ¶
	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 data plane 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 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 that BSID is not allocated when clear.		when set and that BSID is not allocated when clear.
	U-Flag: Indicates that the specified BSID value is unavailable		U-Flag: Indicates that the specified BSID value is unavailable
	when set. When clear, it indicates that this candidate path is		when set. When clear, it indicates that this candidate path is
	using the specified BSID. This flag is ignored when there is		using the specified BSID. This flag is ignored when there is
	no specified BSID.		no specified BSID.
	skipping to change at line 532 ¶		skipping to change at line 530 ¶
	ignored by a receiver.		ignored by a receiver.
	Binding SID: Indicates the operational or allocated BSID value based		Binding SID: Indicates the operational or allocated BSID value based
	on the status flags.		on the status flags.
	Specified BSID: Used to report the explicitly specified BSID value		Specified BSID: Used to report the explicitly specified BSID value
	regardless of whether it is successfully allocated or not. The		regardless of whether it is successfully allocated or not. The
	field is set to value 0 when the 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 data plane (SRv6 or MPLS)		The BSID fields above depend on the data plane (SRv6 or MPLS)
	indicated by the D-Flag. If the D-Flag is set (SRv6 data plane),		indicated by the D-flag. If the D-flag is set (SRv6 data plane),
	then the length of the BSID fields is 16 octets. If the D-Flag is		then the length of the BSID fields is 16 octets. If the D-flag is
	clear (MPLS data plane), then the length of the BSID fields is 4		clear (MPLS data plane), then the length of the BSID fields is 4
	octets. When carrying the MPLS Label, as shown in the figure below,		octets. When carrying the MPLS Label, as shown in the figure below,
	the TC, S, and TTL (total of 12 bits) are RESERVED and MUST be set to		the TC, S, and TTL (total of 12 bits) are RESERVED and MUST be set to
	0 by the originator and MUST be ignored by a receiver.		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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 580 ¶		skipping to change at line 578 ¶
	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
	skipping to change at line 706 ¶		skipping to change at line 704 ¶
	(i.e., 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 for		E-Flag: Indicates that the candidate path has been evaluated for
	validity (e.g., headend may evaluate candidate paths based on		validity (e.g., headend may evaluate candidate paths based 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 that 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 that no valid SID-List is available or		SID list when set and that no valid SID list is available or
	evaluated when clear. When the E-Flag is clear (i.e., the		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 a receiver.		set to 0 by the originator and MUST be ignored by a receiver.
	O-Flag: Indicates that the candidate path was instantiated by the		O-Flag: Indicates that the candidate path was instantiated by the
	headend due to an on-demand next hop 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 an on-demand next hop 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 that the candidate path was delegated for		D-Flag: Indicates that the candidate path was delegated for
	computation to a PCE/controller when set and that the candidate		computation to a PCE/controller when set and that the candidate
	path has not been delegated for computation when clear.		path has not been delegated for computation when clear.
	skipping to change at line 776 ¶		skipping to change at line 774 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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.
	skipping to change at line 810 ¶		skipping to change at line 808 ¶
	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 path		Candidate Path Name: Symbolic name for the SR Policy candidate 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 that is		constraints are generally applied to a dynamic candidate path that is
	computed either by the headend or may be delegated to a controller.		either computed by the headend or delegated to a controller. The
	The constraints may also be applied to an explicit path where the		constraints may also be applied to an explicit path where the
	computation entity is expected to validate that the path satisfies		computation entity is expected to validate that the path satisfies
	the specified constraints; if not, the path is to be invalidated		the specified constraints; if not, the path is to be invalidated
	(e.g., due to topology changes). Only a single instance of this TLV		(e.g., due to topology changes). Only a single instance of this 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 one (i.e., not determined to be		present, then the first valid one (i.e., not determined to be
	malformed as per Section 8.2.2 of [RFC9552]) is used and the rest are		malformed as per Section 8.2.2 of [RFC9552]) is used and the rest are
	ignored.		ignored.
	The TLV has the following format:		The TLV has the following format:
	skipping to change at line 871 ¶		skipping to change at line 869 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	D-Flag: Indicates that the candidate path uses an SRv6 data plane		D-Flag: Indicates that the candidate path uses an SRv6 data plane
	when set and an SR/MPLS data plane when clear.		when set and an SR/MPLS data plane when clear.
	P-Flag: Indicates that the candidate path prefers the use of only		P-Flag: Indicates that the candidate path prefers the use of only
	protected SIDs when set and that the candidate path does not		protected SIDs when set and that the candidate path does not
	prefer the use of only protected SIDs when clear. This flag is		prefer the use of only protected SIDs when clear. This flag is
	mutually exclusive with the U-Flag (i.e., both of these flags		mutually exclusive with the U-flag (i.e., both of 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 only		U-Flag: Indicates that the candidate path prefers the use of only
	unprotected SIDs when set and that the candidate path does not		unprotected SIDs when set and that the candidate path does not
	prefer the use of only unprotected SIDs when clear. This flag		prefer the use of only unprotected SIDs when clear. This flag
	is mutually exclusive with the P-Flag (i.e., both of these		is mutually exclusive with the P-Flag (i.e., both of 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 that the		belonging to the specified SR Algorithm when set and that the
	candidate path does not use only the SIDs belonging to the		candidate path does not use only the SIDs belonging to 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 that the		belonging to the specified topology when set and that 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 that there is no strict constraint		of a preference when set and that there is no strict constraint
	(and only a preference) when clear.		(and only a preference) when clear.
	F-Flag: Indicates that the candidate path is fixed once computed		F-Flag: Indicates that the candidate path is fixed once computed
	and not modified except on operator intervention and that the		and not modified except on operator intervention and that the
	candidate path may be modified as part of recomputation when		candidate path may be modified as part of 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
	skipping to change at line 1063 ¶		skipping to change at line 1061 ¶
	Length: 4 octets		Length: 4 octets
	Bandwidth: 4 octets that 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; 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 one (i.e., not determined to be malformed as per		first valid one (i.e., not determined to be malformed as per
	Section 8.2.2 of [RFC9552]) 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 Constraint Sub-TLV Format		Figure 15: SR Disjoint Group Constraint Sub-TLV Format
	Where:		Where:
	Type: 1211		Type: 1211
	skipping to change at line 1168 ¶		skipping to change at line 1166 ¶
	X-Flag: Indicates that the disjointness constraint could not be		X-Flag: Indicates that the disjointness constraint could not be
	achieved and hence the path has been invalidated when set and		achieved and hence the path has been invalidated when set and
	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 be		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST 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 of the SR Policy candidate path and		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 to 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.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 one (i.e., not determined to be		present, then the first valid one (i.e., not determined to be
	malformed as per Section 8.2.2 of [RFC9552]) 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:
	skipping to change at line 1232 ¶		skipping to change at line 1230 ¶
	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 the candidate path of the SR Policy forms		R-Flag: Indicates that the candidate path of the SR Policy forms
	the reverse path when the R-Flag is set. If the R-Flag is		the reverse path when the R-flag is set. If the R-flag is
	clear, the 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 that the bidirectional path is not co-routed when		set and that the bidirectional path is not co-routed when
	clear.		clear.
	RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST 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 of 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 to 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
	skipping to change at line 1295 ¶		skipping to change at line 1293 ¶
	Figure 17: SR Metric Constraint 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 that identifies the type of metric being		Metric Type: 1-octet field that identifies the type of metric being
	used. Table 1 lists the metric types introduced by this document		used. Below is a list of metric types introduced by this document
	along with reference for each. Where the references are for IS-IS		along with references for each. Where the references are for IS-
	and OSPF specifications, those metric types are defined for a link		IS and OSPF specifications, those metric types are defined for a
	while in the SR Policy context those relate to the candidate path		link while in the SR Policy context those relate to the candidate
	or the segment list. The metric type code points that may be used		path or the segment list. The metric type code points that may be
	in this sub-TLV are also listed in Section 8.6 of this document.		used in this sub-TLV are also listed in Section 8.6 of this
	Note that the metric type in this field is not taken from the "IGP		document. Note that the metric types in this field are taken from
	Metric-Type" registry from IANA "IGP Parameters" and is a separate		the "BGP-LS SR Policy Metric Types" IANA registry, which includes
	registry that includes IGP Metric Types as well as metric types		IGP Metric Types as well as metric types specific to SR Policy
	specific to SR Policy path computation. Additional metric types		path computation (i.e., the metric types are not from the "IGP
	may be introduced by future documents. This document does not		Metric-Type" registry). Additional metric types may be introduced
	make any assumptions about a smaller metric value being better		by future documents. This document does not make any assumptions
	than a higher metric value; that is something that is dependent on		about a smaller metric value being better than a higher metric
	the semantics of the specific metric type. This document uses the		value; that is something that is dependent on the semantics of the
	words "best" and "worst" to abstract this aspect when referring to		specific metric type. This document uses the words "best" and
	metric margins and bounds.		"worst" to abstract this aspect when referring to metric margins
			and bounds.
	Type 0: IGP:		Type 0: IGP:
	This is specified in Section 3 of [RFC5305] for IS-IS and is		This is specified in Section 3 of [RFC5305] for IS-IS and is
	known as the default metric. This is specified in [RFC2328]		known as the default metric. This is specified in [RFC2328]
	for OSPFv2 and in [RFC5340] for OSPFv3 and is known as the		for OSPFv2 and in [RFC5340] for OSPFv3 and is known as the
	metric in both.		metric in both.
	Type 1: Min Unidirectional Delay:		Type 1: Min Unidirectional Delay:
	This is specified in Section 4.2 of [RFC8570] for IS-IS and in		This is specified in Section 4.2 of [RFC8570] for IS-IS and in
	Section 4.2 of [RFC7471] for OSPFv2/OSPFv3.		Section 4.2 of [RFC7471] for OSPFv2/OSPFv3.
	skipping to change at line 1408 ¶		skipping to change at line 1407 ¶
	specified bound value, then the path is considered invalid.		specified bound value, then the path is considered 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 the 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		SID list. The following bit positions are defined, and the
	semantics are described in detail in [RFC9256]. Other bits MUST		semantics are described in detail in [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|E|C|V|R|F|A|T|M| |		|D|E|C|V|R|F|A|T|M| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Where:		Where:
	D-Flag: Indicates that the SID-List consists of SRv6 SIDs when		D-Flag: Indicates that the SID list consists of SRv6 SIDs when
	set and SR/MPLS labels when clear.		set and SR/MPLS labels when clear.
	E-Flag: Indicates that the SID-List is associated with an		E-Flag: Indicates that the SID list is associated with an
	explicit candidate path when set and a dynamic candidate path		explicit candidate path when set and a dynamic candidate path
	when clear. All segment lists of a given candidate path MUST		when clear. All segment lists of a given candidate path MUST
	be either explicit or dynamic. 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 the SID-List has been computed for a		C-Flag: Indicates that the SID list has been computed for a
	dynamic path when set. It is always reported as set for		dynamic path when set. It is always reported as set for
	explicit paths. When clear, it indicates that the SID-List has		explicit paths. When clear, it indicates that the SID list has
	not been computed for a dynamic path.		not been computed for a dynamic path.
	V-Flag: Indicates that the SID-List has passed verification or		V-Flag: Indicates that the SID list has passed verification or
	its verification was not required when set and that it failed		its verification was not required when set and that it failed
	verification 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 that it 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 that it succeeded (or was not required in		failed when set and that it succeeded (or was not required in
	case of an explicit path) when clear.		case of an explicit path) when clear.
	A-Flag: Indicates that all the SIDs in the SID-List belong to the		A-Flag: Indicates that all the SIDs in the SID list belong to the
	specified algorithm when set and that not all the SIDs belong		specified algorithm when set and that not all the 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 the		T-Flag: Indicates that all the SIDs in the SID list belong to the
	specified topology (identified by the multi-topology ID) when		specified topology (identified by the multi-topology ID) when
	set and that not all the SIDs belong to the specified topology		set and that not all the SIDs belong to the 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., Bidirectional Forwarding Detection (BFD)) when		mechanism (e.g., Bidirectional Forwarding Detection (BFD)) when
	set and that no fault is detected or no monitoring is being		set and that no fault is detected or no monitoring is being
	done when clear.		done when clear.
	RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be		RESERVED: 2 octets. MUST be set to 0 by the originator and MUST be
	ignored by a receiver.		ignored by a receiver.
	MTID: 2 octets that indicate 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 in		Algorithm: 1 octet that indicates the algorithm of the SIDs used in
	the SID-List when the A-flag is set. The algorithm values are		the SID list when the A-flag is set. The algorithm values are
	from the "IGP Algorithm Types" IANA registry under the "Interior		from the "IGP Algorithm Types" IANA registry under the "Interior
	Gateway Protocol (IGP) Parameters" registry group.		Gateway Protocol (IGP) Parameters" registry group.
	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.
	Weight: 4-octet field that indicates the weight associated with the		Weight: 4-octet field that indicates the weight associated with the
	SID-List for weighted load balancing. Refer to Sections 2.2 and		SID list for weighted load balancing. Refer to Sections 2.2 and
	2.11 of [RFC9256].		2.11 of [RFC9256].
	Sub-TLVs: Variable and contain the ordered set of Segments and any		Sub-TLVs: Variable and contain the ordered set of Segments and any
	other optional attributes associated with the specific SID-List.		other optional attributes associated with the specific SID 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		(e.g., for a dynamic path) where the headend has not yet performed
	the computation and hence not derived the segments required for the		the computation and hence not derived the segments required for the
	path. In such cases where the SID-LIST is empty, the SR Segment List		path. In such cases where the SID list is empty, the SR Segment List
	TLV 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
	skipping to change at line 1577 ¶		skipping to change at line 1576 ¶
	Where:		Where:
	S-Flag: Indicates the presence of the SID value in the SID field		S-Flag: Indicates the presence of the SID value in the SID field
	when set and no value when clear.		when set and no value when clear.
	E-Flag: Indicates that the SID value is an explicitly provisioned		E-Flag: Indicates that the SID value is an explicitly provisioned
	value (locally on headend or via controller/PCE) when set and		value (locally on headend or via controller/PCE) when set and
	is a dynamically resolved value by headend when clear.		is a dynamically resolved value by headend when clear.
	V-Flag: Indicates that 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 the 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 that the SID has been resolved or did not		R-Flag: Indicates that the SID has been resolved or did not
	require resolution (e.g., because it is not the first SID) when		require resolution (e.g., because it is not the first SID) when
	set. When the R-Flag is clear, it indicates the SID has failed		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 SRv6		SID: 4 octets carrying the MPLS Label or 16 octets carrying the SRv6
	SID based on the Segment Type. When carrying the MPLS Label, as		SID based on the Segment Type. When carrying the MPLS Label, as
	shown in the figure below, the TC, S, and TTL (total of 12 bits)		shown in the figure below, the TC, S, and TTL (total of 12 bits)
	are RESERVED and MUST be set to 0 by the originator and MUST be		are RESERVED and MUST be set to 0 by the originator and MUST 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 contain 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
	descriptions. 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 mappings to the		The following types are currently defined, and their mappings to the
	respective segment types are 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 |
	+------+---------------------------------------------------------+		+------+---------------------------------------------------------+
	skipping to change at line 1657 ¶		skipping to change at line 1656 ¶
	+------+---------------------------------------------------------+		+------+---------------------------------------------------------+
	| 10 | (Type J) SRv6 END.X SID as pair of IPv6 Global Address |		| 10 | (Type J) SRv6 END.X SID as pair of IPv6 Global Address |
	| | & Interface ID for Local & Remote nodes |		| | & Interface ID for Local & Remote nodes |
	+------+---------------------------------------------------------+		+------+---------------------------------------------------------+
	| 11 | (Type K) SRv6 END.X SID as pair of IPv6 Global |		| 11 | (Type K) SRv6 END.X SID as pair of IPv6 Global |
	| | Addresses for the Local & Remote Interface |		| | Addresses for the Local & Remote Interface |
	+------+---------------------------------------------------------+		+------+---------------------------------------------------------+
	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 an 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 the "IGP		in the Segment TLV. The algorithm values are from the "IGP
	Algorithm Types" IANA registry under the "Interior Gateway		Algorithm Types" IANA registry under the "Interior Gateway
	Protocol (IGP) Parameters" registry group.		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 an 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 the "IGP		in the Segment TLV. The algorithm values are from the "IGP
	Algorithm Types" IANA registry under the "Interior Gateway		Algorithm Types" IANA registry under the "Interior Gateway
	Protocol (IGP) Parameters" registry group.		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 an 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
	skipping to change at line 1724 ¶		skipping to change at line 1723 ¶
	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 the "IGP Algorithm		picking the SID. The algorithm values are from the "IGP Algorithm
	Types" IANA registry under the "Interior Gateway Protocol (IGP)		Types" IANA registry under the "Interior Gateway Protocol (IGP)
	Parameters" registry group.		Parameters" registry group.
	IPv4 Node Address: 4-octet value that 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 an 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
	node global address. The format of its Segment Descriptor is as		node global address. The format of its segment descriptor is as
	follows:		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) |
	| |		| |
	skipping to change at line 1753 ¶		skipping to change at line 1752 ¶
	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 the "IGP Algorithm		picking the SID. The algorithm values are from the "IGP Algorithm
	Types" IANA registry under the "Interior Gateway Protocol (IGP)		Types" IANA registry under the "Interior Gateway Protocol (IGP)
	Parameters" registry group.		Parameters" registry group.
	IPv6 Node Global Address: 16-octet value that 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 an SR-MPLS Adjacency SID type and is specified as an		The Segment is an SR-MPLS Adjacency SID type and is specified as an
	IPv4 node address along with the local interface ID on that node.		IPv4 node address along with the local interface ID on that node.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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 that 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 that carries the local interface		Local Interface ID: 4-octet value that carries the local 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 an SR-MPLS Adjacency SID type and is specified as a		The Segment is an SR-MPLS Adjacency SID type and is specified as a
	pair of IPv4 local and remote interface addresses. The format of its		pair of IPv4 local and remote interface addresses. The format of its
	Segment 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 that 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 that carries the remote IPv4		IPv4 Remote Interface Address: 4-octet value that carries the remote
	address associated with the interface on the node's neighbor.		IPv4 address associated with the interface on the node's neighbor.
	This is optional and MAY be set to 0 when not used (e.g., when		This is optional and MAY be set to 0 when not used (e.g., when
	identifying 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 an SR-MPLS Adjacency SID type and is specified as a		The Segment is an SR-MPLS Adjacency SID type and is specified as a
	pair of IPv6 global address and interface ID for local and remote		pair of IPv6 global address and interface ID for local and remote
	nodes. 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) |
	skipping to change at line 1850 ¶		skipping to change at line 1846 ¶
	IPv6 Remote Node Global Address: 16-octet value that 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 that carries the interface		Remote Node Interface ID: 4-octet value that carries the interface
	ID of the remote node identified by the Remote Node Address. This		ID of the remote node identified by the Remote Node Address. This
	is optional and MAY be set to 0 when not used (e.g., when		is optional and MAY be set to 0 when not used (e.g., 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 an SR-MPLS Adjacency SID type and is specified as a		The Segment is an SR-MPLS Adjacency SID type and is specified as a
	pair of IPv6 global addresses for local and remote interface		pair of IPv6 global addresses for local and remote interface
	addresses. 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 that 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 that 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 an SRv6 END SID type and is specified as an IPv6 node		The Segment is an SRv6 END SID type and is specified as an IPv6 node
	global address. The format of its Segment Descriptor is as follows:		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) |
	| |		| |
	| |		| |
	skipping to change at line 1909 ¶		skipping to change at line 1904 ¶
	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 the "IGP Algorithm		picking the SID. The algorithm values are from the "IGP Algorithm
	Types" IANA registry under the "Interior Gateway Protocol (IGP)		Types" IANA registry under the "Interior Gateway Protocol (IGP)
	Parameters" registry group.		Parameters" registry group.
	IPv6 Node Global Address: 16-octet value that 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 an SRv6 END.X SID type and is specified as a pair of		The Segment is an SRv6 END.X SID type and is specified as a pair of
	IPv6 global address and interface ID for local and remote nodes. The		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) |
	skipping to change at line 1953 ¶		skipping to change at line 1948 ¶
	IPv6 Remote Node Global Address: 16-octet value that 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 that carries the interface		Remote Node Interface ID: 4-octet value that carries the interface
	ID of the remote node identified by the Remote Node Address. This		ID of the remote node identified by the Remote Node Address. This
	is optional and MAY be set to 0 when not used (e.g., when		is optional and MAY be set to 0 when not used (e.g., 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 an SRv6 END.X SID type and is specified as a pair of		The Segment is an SRv6 END.X SID type and is specified as a pair of
	IPv6 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 that 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 that 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 the 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 Policy 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:
	skipping to change at line 2021 ¶		skipping to change at line 2016 ¶
	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 that identifies the type of metric. The		Metric Type: 1-octet field that identifies the type of metric. The
	semantics are the same as the Metric Type field in the SR Metric		semantics are the same as the metric type field in the SR Metric
	Constraint 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| |
	skipping to change at line 2086 ¶		skipping to change at line 2081 ¶
	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 one (i.e., not determined to be		present, then the first valid one (i.e., not determined to be
	malformed as per Section 8.2.2 of [RFC9552]) 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 2118 ¶		skipping to change at line 2113 ¶
	Type: 1216		Type: 1216
	Length: 4 octets		Length: 4 octets
	Bandwidth: 4 octets that specify the allocated bandwidth in unit of		Bandwidth: 4 octets that specify the allocated bandwidth in unit 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 one		list. If multiple instances are present, then the first valid one
	(i.e., not determined to be malformed as per Section 8.2.2 of		(i.e., not determined to be malformed as per Section 8.2.2 of
	[RFC9552]) 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 |
	skipping to change at line 2146 ¶		skipping to change at line 2141 ¶
	Where:		Where:
	Type: 1217		Type: 1217
	Length: 4 octets		Length: 4 octets
	Segment List Identifier: 4 octets that carry a 32-bit unsigned non-		Segment List Identifier: 4 octets that carry a 32-bit unsigned non-
	zero integer that serves as the identifier associated with the		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 Sections 5.1 and 5.2 is included to		The SR BSID TLV as defined in Sections 5.1 and 5.2 is included to
	report the BSID of the candidate path when one is either specified or		report the BSID of the candidate path when one is either specified 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 SID-		Section 5.6. The SR Segment List TLV is included for each SID
	List(s) associated with the candidate path. Each SR Segment List TLV		list(s) associated with the candidate path. Each SR Segment List TLV
	in turn includes an SR Segment sub-TLV(s) to report the segment(s)		in turn includes an SR Segment sub-TLV(s) to report the segment(s)
	and its status. The SR Segment List Metric sub-TLV is used to report		and its status. The SR Segment List Metric sub-TLV is used to 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 headend 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.
	skipping to change at line 2276 ¶		skipping to change at line 2271 ¶
	+----------------+-------------------------------------+-----------+		+----------------+-------------------------------------+-----------+
	| 1215 | SR Metric Constraint | RFC 9857 |		| 1215 | SR Metric Constraint | RFC 9857 |
	+----------------+-------------------------------------+-----------+		+----------------+-------------------------------------+-----------+
	| 1216 | SR Segment List Bandwidth | RFC 9857 |		| 1216 | SR Segment List Bandwidth | RFC 9857 |
	+----------------+-------------------------------------+-----------+		+----------------+-------------------------------------+-----------+
	| 1217 | SR Segment List Identifier | RFC 9857 |		| 1217 | SR Segment List Identifier | RFC 9857 |
	+----------------+-------------------------------------+-----------+		+----------------+-------------------------------------+-----------+
	Table 4: NLRI and Attribute TLV Code Points		Table 4: NLRI and Attribute TLV Code Points
	8.4. SR Policy Protocol Origin		8.4. SR Policy Protocol-Origin
	Per this document, IANA has created and maintains a new registry		Per this document, IANA has created and maintains a new registry
	called "SR Policy Protocol Origin" under the "Segment Routing"		called "SR Policy Protocol-Origin" under the "Segment Routing"
	registry group with the allocation policy of Expert Review [RFC8126]		registry group with the allocation policy of Expert Review [RFC8126]
	using the guidelines for designated experts as specified in		using the guidelines for designated experts as specified in
	[RFC9256]. This registry contains the code points allocated to the		[RFC9256]. This registry contains the code points allocated to the
	"Protocol Origin" field defined in Section 4.		"Protocol-Origin" field defined in Section 4.
	IANA has assigned the initial values as follows:		IANA has assigned the initial values as follows:
	+=========+================================+===========+		+=========+================================+===========+
	| Code | Protocol Origin | Reference |		| Code | Protocol-Origin | Reference |
	| Point | | |		| Point | | |
	+=========+================================+===========+		+=========+================================+===========+
	| 0 | Reserved | RFC 9857 |		| 0 | Reserved | RFC 9857 |
	+---------+--------------------------------+-----------+		+---------+--------------------------------+-----------+
	| 1 | PCEP | RFC 9857 |		| 1 | PCEP | RFC 9857 |
	+---------+--------------------------------+-----------+		+---------+--------------------------------+-----------+
	| 2 | BGP SR Policy | RFC 9857 |		| 2 | BGP SR Policy | RFC 9857 |
	+---------+--------------------------------+-----------+		+---------+--------------------------------+-----------+
	| 3 | Configuration (CLI, YANG model | RFC 9857 |		| 3 | Configuration (CLI, YANG model | RFC 9857 |
	| | via NETCONF, etc.) | |		| | via NETCONF, etc.) | |
	skipping to change at line 2321 ¶		skipping to change at line 2316 ¶
	+---------+--------------------------------+-----------+		+---------+--------------------------------+-----------+
	| 30 | Configuration (CLI, YANG model | RFC 9857 |		| 30 | Configuration (CLI, YANG model | RFC 9857 |
	| | via NETCONF, etc. In PCEP or | |		| | via NETCONF, etc. In PCEP or | |
	| | when BGP-LS Producer is PCE) | |		| | when BGP-LS Producer is PCE) | |
	+---------+--------------------------------+-----------+		+---------+--------------------------------+-----------+
	| 31-250 | Unassigned | RFC 9857 |		| 31-250 | Unassigned | RFC 9857 |
	+---------+--------------------------------+-----------+		+---------+--------------------------------+-----------+
	| 251-255 | Reserved for Private Use | RFC 9857 |		| 251-255 | Reserved for Private Use | RFC 9857 |
	+---------+--------------------------------+-----------+		+---------+--------------------------------+-----------+
	Table 5: SR Policy Protocol Origin Code Points		Table 5: SR Policy Protocol-Origin Code Points
	8.5. BGP-LS SR Segment Descriptors		8.5. BGP-LS SR Segment Descriptors
	Per this document, IANA has created a registry called "BGP-LS SR		Per this document, IANA has created a registry called "BGP-LS SR
	Segment Descriptor Types" under the "Border Gateway Protocol - Link		Segment Descriptor Types" under the "Border Gateway Protocol - Link
	State (BGP-LS) Parameters" registry group with the allocation policy		State (BGP-LS) Parameters" registry group with the allocation policy
	of Expert Review [RFC8126] using the guidelines for designated		of Expert Review [RFC8126] using the guidelines for designated
	experts as specified in [RFC9552]. There is also an additional		experts as specified in [RFC9552]. There is also an additional
	guideline for the designated experts to maintain the alignment		guideline for the designated experts to maintain the alignment
	between the allocations in this registry with those in the "Segment		between the allocations in this registry with those in the "Segment
	skipping to change at line 2345 ¶		skipping to change at line 2340 ¶
	Segment Descriptor Types" registry for a new segment type. However,		Segment Descriptor Types" registry for a new segment type. However,
	this 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 code points allocated to the "Segment		This registry contains the code points allocated to the "Segment
	Type" field defined in Section 5.7.1 and described in		Type" field defined in Section 5.7.1 and described in
	Section 5.7.1.1. IANA has assigned the initial values as follows:		Section 5.7.1.1. IANA has assigned the initial values as follows:
	+========+========================================+===========+		+============+====================+===========+
	| Code | Segment Descriptor | Reference |		| Code Point | Segment Descriptor | Reference |
	| Point | | |		+============+====================+===========+
	+========+========================================+===========+		| 0 | Reserved | RFC 9857 |
	| 0 | Reserved | RFC 9857 |		+------------+--------------------+-----------+
	+--------+----------------------------------------+-----------+		| 1 | Type A Segment | RFC 9857 |
	| 1 | (Type A) SR-MPLS Label | RFC 9857 |		+------------+--------------------+-----------+
	+--------+----------------------------------------+-----------+		| 2 | Type B Segment | RFC 9857 |
	| 2 | (Type B) SRv6 SID as IPv6 address | RFC 9857 |		+------------+--------------------+-----------+
	+--------+----------------------------------------+-----------+		| 3 | Type C Segment | RFC 9857 |
	| 3 | (Type C) SR-MPLS Prefix SID as IPv4 | RFC 9857 |		+------------+--------------------+-----------+
	| | Node Address | |		| 4 | Type D Segment | RFC 9857 |
	+--------+----------------------------------------+-----------+		+------------+--------------------+-----------+
	| 4 | (Type D) SR-MPLS Prefix SID as IPv6 | RFC 9857 |		| 5 | Type E Segment | RFC 9857 |
	| | Node Global Address | |		+------------+--------------------+-----------+
	+--------+----------------------------------------+-----------+		| 6 | Type F Segment | RFC 9857 |
	| 5 | (Type E) SR-MPLS Adjacency SID as IPv4 | RFC 9857 |		+------------+--------------------+-----------+
	| | Node Address & Local Interface ID | |		| 7 | Type G Segment | RFC 9857 |
	+--------+----------------------------------------+-----------+		+------------+--------------------+-----------+
	| 6 | (Type F) SR-MPLS Adjacency SID as IPv4 | RFC 9857 |		| 8 | Type H Segment | RFC 9857 |
	| | Local & Remote Interface Addresses | |		+------------+--------------------+-----------+
	+--------+----------------------------------------+-----------+		| 9 | Type I Segment | RFC 9857 |
	| 7 | (Type G) SR-MPLS Adjacency SID as pair | RFC 9857 |		+------------+--------------------+-----------+
	| | of IPv6 Global Address & Interface ID | |		| 10 | Type J Segment | RFC 9857 |
	| | for Local & Remote nodes | |		+------------+--------------------+-----------+
	+--------+----------------------------------------+-----------+		| 11 | Type K Segment | RFC 9857 |
	| 8 | (Type H) SR-MPLS Adjacency SID as pair | RFC 9857 |		+------------+--------------------+-----------+
	| | of IPv6 Global Addresses for the Local | |		| 12-255 | Unassigned | RFC 9857 |
	| | & Remote Interface | |		+------------+--------------------+-----------+
	+--------+----------------------------------------+-----------+
	| 9 | (Type I) SRv6 END SID as IPv6 Node | RFC 9857 |
	| | Global Address | |
	+--------+----------------------------------------+-----------+
	| 10 | (Type J) SRv6 END.X SID as pair of | RFC 9857 |
	| | IPv6 Global Address & Interface ID for | |
	| | Local & Remote nodes | |
	+--------+----------------------------------------+-----------+
	| 11 | (Type K) SRv6 END.X SID as pair of | RFC 9857 |
	| | IPv6 Global Addresses for the Local & | |
	| | Remote Interface | |
	+--------+----------------------------------------+-----------+
	| 12-255 | Unassigned | RFC 9857 |
	+--------+----------------------------------------+-----------+
	Table 6: BGP-LS SR Segment Descriptor Type Code Points		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
	Per this document, IANA has created a registry called "BGP-LS SR		Per this document, IANA has created a registry called "BGP-LS SR
	Policy Metric Types" 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 code points		as specified in [RFC9552]. This registry contains the code points
	allocated to the "Metric Type" field defined in Section 5.7.2. IANA		allocated to the metric type field defined in Section 5.7.2. IANA
	has assigned the initial values as follows:		has assigned the initial values as follows:
	+============+================================+===========+		+============+================================+===========+
	| Code Point | Metric Type | Reference |		| Code Point | Metric Type | Reference |
	+============+================================+===========+		+============+================================+===========+
	| 0 | IGP | RFC 9857 |		| 0 | IGP | RFC 9857 |
	+------------+--------------------------------+-----------+		+------------+--------------------------------+-----------+
	| 1 | Min Unidirectional Delay | RFC 9857 |		| 1 | Min Unidirectional Delay | RFC 9857 |
	+------------+--------------------------------+-----------+		+------------+--------------------------------+-----------+
	| 2 | TE | RFC 9857 |		| 2 | TE | RFC 9857 |
End of changes. 112 change blocks.
	207 lines changed or deleted		189 lines changed or added
This html diff was produced by rfcdiff 1.48.