rfc9862v1.txt		rfc9862.txt
	skipping to change at line 13 ¶		skipping to change at line 13 ¶
	Request for Comments: 9862 S. Sivabalan		Request for Comments: 9862 S. Sivabalan
	Updates: 8231 Ciena Corporation		Updates: 8231 Ciena Corporation
	Category: Standards Track S. Sidor		Category: Standards Track S. Sidor
	ISSN: 2070-1721 Cisco Systems, Inc.		ISSN: 2070-1721 Cisco Systems, Inc.
	C. Barth		C. Barth
	Juniper Networks, Inc.		Juniper Networks, Inc.
	S. Peng		S. Peng
	Huawei Technologies		Huawei Technologies
	H. Bidgoli		H. Bidgoli
	Nokia		Nokia
	September 2025		October 2025
	Path Computation Element Communication Protocol (PCEP) Extensions for		Path Computation Element Communication Protocol (PCEP) Extensions for
	Segment Routing (SR) Policy Candidate Paths		Segment Routing (SR) Policy Candidate Paths
	Abstract		Abstract
	A Segment Routing (SR) Policy is an ordered list of instructions		A Segment Routing (SR) Policy is an ordered list of instructions
	called "segments" that represent a source-routed policy. Packet		called "segments" that represent a source-routed policy. Packet
	flows are steered into an SR Policy on a node where it is		flows are steered into an SR Policy on a node where it is
	instantiated. An SR Policy is made of one or more candidate paths.		instantiated. An SR Policy is made of one or more Candidate Paths.
	This document specifies the Path Computation Element Communication		This document specifies the Path Computation Element Communication
	Protocol (PCEP) extension to signal candidate paths of an SR Policy.		Protocol (PCEP) extension to signal Candidate Paths of an SR Policy.
	Additionally, this document updates RFC 8231 to allow delegation and		Additionally, this document updates RFC 8231 to allow delegation and
	setup of an SR Label Switched Path (LSP) without using the path		setup of an SR Label Switched Path (LSP) without using the path
	computation request and reply messages. This document is applicable		computation request and reply messages. This document is applicable
	to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over		to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over
	IPv6 (SRv6).		IPv6 (SRv6).
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	skipping to change at line 82 ¶		skipping to change at line 82 ¶
	4.4. Association Parameters		4.4. Association Parameters
	4.5. Association Information		4.5. Association Information
	4.5.1. SRPOLICY-POL-NAME TLV		4.5.1. SRPOLICY-POL-NAME TLV
	4.5.2. SRPOLICY-CPATH-ID TLV		4.5.2. SRPOLICY-CPATH-ID TLV
	4.5.3. SRPOLICY-CPATH-NAME TLV		4.5.3. SRPOLICY-CPATH-NAME TLV
	4.5.4. SRPOLICY-CPATH-PREFERENCE TLV		4.5.4. SRPOLICY-CPATH-PREFERENCE TLV
	5. SR Policy Signaling Extensions		5. SR Policy Signaling Extensions
	5.1. SRPOLICY-CAPABILITY TLV		5.1. SRPOLICY-CAPABILITY TLV
	5.2. LSP Object TLVs		5.2. LSP Object TLVs
	5.2.1. COMPUTATION-PRIORITY TLV		5.2.1. COMPUTATION-PRIORITY TLV
	5.2.2. Explicit Null Label Policy (ENLP) TLV		5.2.2. EXPLICIT-NULL-LABEL-POLICY TLV
	5.2.3. INVALIDATION TLV		5.2.3. INVALIDATION TLV
	5.2.3.1. Drop-Upon-Invalid Applies to SR Policy		5.2.3.1. Drop-Upon-Invalid Applies to SR Policy
	5.3. Updates to RFC 8231		5.3. Updates to RFC 8231
	6. IANA Considerations		6. IANA Considerations
	6.1. Association Type		6.1. Association Type
	6.2. PCEP TLV Type Indicators		6.2. PCEP TLV Type Indicators
	6.3. PCEP Errors		6.3. PCEP Errors
	6.4. TE-PATH-BINDING TLV Flag Field		6.4. TE-PATH-BINDING TLV Flag Field
	6.5. SR Policy Invalidation Operational State		6.5. SR Policy Invalidation Operational State
	6.6. SR Policy Invalidation Configuration State		6.6. SR Policy Invalidation Configuration State
	skipping to change at line 138 ¶		skipping to change at line 138 ¶
	* Association of an SR Policy with an intent via color, enabling		* Association of an SR Policy with an intent via color, enabling
	headend-based steering of BGP service routes over SR Policies		headend-based steering of BGP service routes over SR Policies
	provisioned via PCEP.		provisioned via PCEP.
	"Path Computation Element Communication Protocol (PCEP) Extensions		"Path Computation Element Communication Protocol (PCEP) Extensions
	for Establishing Relationships between Sets of Label Switched Paths		for Establishing Relationships between Sets of Label Switched Paths
	(LSPs)" [RFC8697] introduces a generic mechanism to create a grouping		(LSPs)" [RFC8697] introduces a generic mechanism to create a grouping
	of LSPs that is called an "Association".		of LSPs that is called an "Association".
	An SR Policy is associated with one or more candidate paths. A		An SR Policy is associated with one or more Candidate Paths. A
	candidate path is the unit for signaling an SR Policy to a headend as		Candidate Path is the unit for signaling an SR Policy to a headend as
	described in Section 2.2 of [RFC9256]. This document extends		described in Section 2.2 of [RFC9256]. This document extends
	[RFC8664] to support signaling SR Policy Candidate Paths as LSPs and		[RFC8664] to support signaling SR Policy Candidate Paths as LSPs and
	to signal Candidate Path membership in an SR Policy by means of the		to signal Candidate Path membership in an SR Policy by means of the
	Association mechanism. A PCEP Association corresponds to an SR		Association mechanism. A PCEP Association corresponds to an SR
	Policy and an LSP corresponds to a Candidate Path. The unit of		Policy and an LSP corresponds to a Candidate Path. The unit of
	signaling in PCEP is the LSP, thus, all the information related to an		signaling in PCEP is the LSP, thus, all the information related to an
	SR Policy is carried at the Candidate Path level.		SR Policy is carried at the Candidate Path level.
	Also, this document updates Section 5.8.2 of [RFC8231], making the		Also, this document updates Section 5.8.2 of [RFC8231], making the
	use of Path Computation Request (PCReq) and Path Computation Reply		use of Path Computation Request (PCReq) and Path Computation Reply
	skipping to change at line 212 ¶		skipping to change at line 212 ¶
	Association parameters: Refers to the key data that uniquely		Association parameters: Refers to the key data that uniquely
	identifies an Association, as described in [RFC8697].		identifies an Association, as described in [RFC8697].
	Association information: Refers to information related to		Association information: Refers to information related to
	Association Type, as described in Section 6.1.4 of [RFC8697].		Association Type, as described in Section 6.1.4 of [RFC8697].
	SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 (for		SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 (for
	Segment Routing) or 3 (for SRv6).		Segment Routing) or 3 (for SRv6).
	SR Policy Association (SRPA): A new Association Type used to group		SR Policy Association (SRPA): A new Association Type used to group
	candidate paths belonging to the same SR Policy. Depending on the		Candidate Paths belonging to the same SR Policy. Depending on the
	discussion context, it can refer to the PCEP ASSOCIATION object of		discussion context, it can refer to the PCEP ASSOCIATION object of
	an SR Policy type or to a group of LSPs that belong to the		an SR Policy type or to a group of LSPs that belong to the
	association.		association.
	The base PCEP specification [RFC4655] originally defined the use of		The base PCEP specification [RFC4655] originally defined the use of
	the PCE architecture for MPLS and GMPLS networks with LSPs		the PCE architecture for MPLS and GMPLS networks with LSPs
	instantiated using the RSVP-TE signaling protocol. Over time,		instantiated using the RSVP-TE signaling protocol. Over time,
	support for additional path setup types such as SRv6 has been		support for additional path setup types such as SRv6 has been
	introduced [RFC9603]. The term "LSP" is used extensively in PCEP		introduced [RFC9603]. The term "LSP" is used extensively in PCEP
	specifications, and in the context of this document, refers to a		specifications, and in the context of this document, refers to a
	skipping to change at line 242 ¶		skipping to change at line 242 ¶
	of a single segment list within an SR Policy Candidate Path.		of a single segment list within an SR Policy Candidate Path.
	Encoding of multiple segment lists is outside the scope of this		Encoding of multiple segment lists is outside the scope of this
	document and is specified in [PCEP-MULTIPATH].		document and is specified in [PCEP-MULTIPATH].
	An SRPA carries three pieces of information: SR Policy Identifier, SR		An SRPA carries three pieces of information: SR Policy Identifier, SR
	Policy Candidate Path Identifier, and SR Policy Candidate Path		Policy Candidate Path Identifier, and SR Policy Candidate Path
	Attribute(s).		Attribute(s).
	This document also specifies some additional information that is not		This document also specifies some additional information that is not
	encoded as part of an SRPA: computation priority of the LSP, Explicit		encoded as part of an SRPA: computation priority of the LSP, Explicit
	Null Label Policy for the unlabeled IP packets and Drop-Upon-Invalid		NULL Label Policy for the unlabeled IP packets and Drop-Upon-Invalid
	behavior for traffic steering when the LSP is operationally down (see		behavior for traffic steering when the LSP is operationally down (see
	Section 5).		Section 5).
	4. SR Policy Association (SRPA)		4. SR Policy Association (SRPA)
	Per [RFC8697], LSPs are associated with other LSPs with which they		Per [RFC8697], LSPs are associated with other LSPs with which they
	interact by adding them to a common association group. An		interact by adding them to a common association group. An
	association group is uniquely identified by the combination of the		association group is uniquely identified by the combination of the
	following fields in the ASSOCIATION object (Section 6.1 of		following fields in the ASSOCIATION object (Section 6.1 of
	[RFC8697]): Association Type, Association ID, Association Source, and		[RFC8697]): Association Type, Association ID, Association Source, and
	skipping to change at line 351 ¶		skipping to change at line 351 ¶
	* Originator ([RFC9256], Section 2.4)		* Originator ([RFC9256], Section 2.4)
	* Discriminator ([RFC9256], Section 2.5)		* Discriminator ([RFC9256], Section 2.5)
	4.3. SR Policy Candidate Path Attributes		4.3. SR Policy Candidate Path Attributes
	SR Policy Candidate Path Attributes carry optional, non-key		SR Policy Candidate Path Attributes carry optional, non-key
	information about a Candidate Path and MAY change during the lifetime		information about a Candidate Path and MAY change during the lifetime
	of an LSP. SR Policy Candidate Path Attributes consist of:		of an LSP. SR Policy Candidate Path Attributes consist of:
	* Candidate Path preference ([RFC9256], Section 2.7)		* Candidate Path Preference ([RFC9256], Section 2.7)
	* Candidate Path name ([RFC9256], Section 2.6)		* Candidate Path name ([RFC9256], Section 2.6)
	* SR Policy name ([RFC9256], Section 2.1)		* SR Policy name ([RFC9256], Section 2.1)
	4.4. Association Parameters		4.4. Association Parameters
	Per Section 2.1 of [RFC9256], an SR Policy is identified through the		Per Section 2.1 of [RFC9256], an SR Policy is identified through the
	<Headend, Color, Endpoint> tuple.		<Headend, Color, Endpoint> tuple.
	skipping to change at line 377 ¶		skipping to change at line 377 ¶
	Policy, as defined in [RFC9256], Section 2.1.		Policy, as defined in [RFC9256], Section 2.1.
	Association ID (16 bit): Always set to the numeric value 1.		Association ID (16 bit): Always set to the numeric value 1.
	Extended Association ID TLV: Mandatory TLV for an SRPA. Encodes the		Extended Association ID TLV: Mandatory TLV for an SRPA. Encodes the
	Color and Endpoint of the SR Policy (Figure 1).		Color and Endpoint of the SR Policy (Figure 1).
	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 = 31 | Length = 8 or 20 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Color |		| Color |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Endpoint ~		~ Endpoint ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Extended Association ID TLV Format		Figure 1: Extended Association ID TLV Format
	Type: 31 for the Extended Association ID TLV [RFC8697].		Type: 31 for the Extended Association ID TLV [RFC8697].
	Length: 8 octets if IPv4 address or 20 octets if IPv6 address is		Length: 8 octets if IPv4 address or 20 octets if IPv6 address is
	encoded in the Endpoint field.		encoded in the Endpoint field.
	Color: Unsigned non-zero 32-bit integer value, SR Policy color		Color: Unsigned non-zero 32-bit integer value, SR Policy color
	per Section 2.1 of [RFC9256].		per Section 2.1 of [RFC9256].
	Endpoint: Can be either IPv4 (4 octets) or IPv6 address (16		Endpoint: Can be either IPv4 (4 octets) or IPv6 address (16
	octets). This value MAY be different from the one contained in		octets). This value MAY be different from the one contained in
	the Destination address field in the END-POINTS object, or in		the destination address field in the END-POINTS object, or in
	the Tunnel Endpoint Address field in the LSP-IDENTIFIERS TLV		the Tunnel Endpoint Address field in the LSP-IDENTIFIERS TLV
	(Section 2.1 of [RFC9256]).		(Section 2.1 of [RFC9256]).
	If a PCEP speaker receives an SRPA object whose association		If a PCEP speaker receives an SRPA object whose association
	parameters do not follow the above specification, then the PCEP		parameters do not follow the above specification, then the PCEP
	speaker MUST send a PCErr message with:		speaker MUST send a PCErr message with:
	* Error-Type = 26 "Association Error"		* Error-Type = 26 "Association Error"
	* Error-value = 20 "SR Policy Identifier Mismatch"		* Error-value = 20 "SR Policy Identifier Mismatch"
	skipping to change at line 419 ¶		skipping to change at line 419 ¶
	meant to guarantee that there is no possibility of a race condition		meant to guarantee that there is no possibility of a race condition
	when multiple PCEP speakers want to associate the same SR Policy at		when multiple PCEP speakers want to associate the same SR Policy at
	the same time. By adhering to this format, all PCEP speakers come up		the same time. By adhering to this format, all PCEP speakers come up
	with the same association parameters independently of each other		with the same association parameters independently of each other
	based on the SR Policy parameters [RFC9256].		based on the SR Policy parameters [RFC9256].
	The last hop of a computed SR Policy Candidate Path MAY differ from		The last hop of a computed SR Policy Candidate Path MAY differ from
	the Endpoint contained in the <Headend, Color, Endpoint> tuple. An		the Endpoint contained in the <Headend, Color, Endpoint> tuple. An
	example use case is to terminate the SR Policy before reaching the		example use case is to terminate the SR Policy before reaching the
	Endpoint and have decapsulated traffic be forwarded the rest of the		Endpoint and have decapsulated traffic be forwarded the rest of the
	path to the Endpoint node using the native Interior Gateway Protocol		path to the Endpoint node using the Interior Gateway Protocol (IGP)
	(IGP) path(s). In this example, the destination of the SR Policy		shortest path(s). In this example, the destination of the SR Policy
	Candidate Paths will be some node before the Endpoint, but the		Candidate Paths will be some node before the Endpoint, but the
	Endpoint value is still used at the headend to steer traffic with		Endpoint value is still used at the headend to steer traffic with
	that Endpoint IP address into the SR Policy. The Destination of the		that Endpoint IP address into the SR Policy. The destination of the
	SR Policy Candidate Path is signaled using the END-POINTS object and/		SR Policy Candidate Path is signaled using the END-POINTS object and/
	or the LSP-IDENTIFIERS TLV, per the usual PCEP procedure. When		or the LSP-IDENTIFIERS TLV, per the usual PCEP procedure. When
	neither the END-POINTS object nor the LSP-IDENTIFIERS TLV is present,		neither the END-POINTS object nor the LSP-IDENTIFIERS TLV is present,
	the PCEP speaker MUST extract the destination from the Endpoint field		the PCEP speaker MUST extract the destination from the Endpoint field
	in the SRPA Extended Association ID TLV.		in the SRPA Extended Association ID TLV.
	SR Policy with Color-Only steering is signaled with the Endpoint		SR Policy with Color-Only steering is signaled with the Endpoint
	value set to unspecified, i.e., 0.0.0.0 for IPv4 or :: for IPv6, per		value set to unspecified, i.e., 0.0.0.0 for IPv4 or :: for IPv6, per
	Section 8.8 of [RFC9256].		Section 8.8 of [RFC9256].
	skipping to change at line 448 ¶		skipping to change at line 448 ¶
	SRPOLICY-POL-NAME TLV (Section 4.5.1): (optional) encodes the SR		SRPOLICY-POL-NAME TLV (Section 4.5.1): (optional) encodes the SR
	Policy Name string.		Policy Name string.
	SRPOLICY-CPATH-ID TLV (Section 4.5.2): (mandatory) encodes the SR		SRPOLICY-CPATH-ID TLV (Section 4.5.2): (mandatory) encodes the SR
	Policy Candidate Path Identifier.		Policy Candidate Path Identifier.
	SRPOLICY-CPATH-NAME TLV (Section 4.5.3): (optional) encodes the SR		SRPOLICY-CPATH-NAME TLV (Section 4.5.3): (optional) encodes the SR
	Policy Candidate Path string name.		Policy Candidate Path string name.
	SRPOLICY-CPATH-PREFERENCE TLV (Section 4.5.4): (optional) encodes		SRPOLICY-CPATH-PREFERENCE TLV (Section 4.5.4): (optional) encodes
	the SR Policy Candidate Path preference value.		the SR Policy Candidate Path Preference value.
	When a mandatory TLV is missing from an SRPA object, the PCEP speaker		When a mandatory TLV is missing from an SRPA object, the PCEP speaker
	MUST send a PCErr message with:		MUST send a PCErr message with:
	* Error-Type = 6 "Mandatory Object Missing"		* Error-Type = 6 "Mandatory Object Missing"
	* Error-value = 21 "Missing SR Policy Mandatory TLV"		* Error-value = 21 "Missing SR Policy Mandatory TLV"
	Only one TLV instance of each TLV type can be carried in an SRPA		Only one TLV instance of each TLV type can be carried in an SRPA
	object, and only the first occurrence is processed. Any others MUST		object, and only the first occurrence is processed. Any others MUST
	skipping to change at line 607 ¶		skipping to change at line 607 ¶
	| Preference |		| Preference |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: SRPOLICY-CPATH-PREFERENCE TLV Format		Figure 5: SRPOLICY-CPATH-PREFERENCE TLV Format
	Type: 59 for the SRPOLICY-CPATH-PREFERENCE TLV.		Type: 59 for the SRPOLICY-CPATH-PREFERENCE TLV.
	Length: 4.		Length: 4.
	Preference: 32-bit unsigned integer value that encodes the		Preference: 32-bit unsigned integer value that encodes the
	preference of the Candidate Path as defined in Section 2.7 of		Preference of the Candidate Path as defined in Section 2.7 of
	[RFC9256].		[RFC9256].
	5. SR Policy Signaling Extensions		5. SR Policy Signaling Extensions
	This section introduces mechanisms described for SR Policies in		This section introduces mechanisms described for SR Policies in
	[RFC9256] to PCEP. These extensions do not make use of the SRPA for		[RFC9256] to PCEP. These extensions do not make use of the SRPA for
	signaling in PCEP, and therefore cannot rely on the Association		signaling in PCEP; therefore, they cannot rely on the Association
	capability negotiation in the ASSOC-Type-List TLV and separate		capability negotiation in the ASSOC-Type-List TLV. Instead, separate
	capability negotiation is required.		capability negotiation is required.
	This document specifies four new TLVs to be carried in the OPEN or		This document specifies four new TLVs to be carried in the OPEN or
	LSP object. Only one TLV instance of each type can be carried, and		LSP object. Only one TLV instance of each type can be carried, and
	only the first occurrence is processed. Any others MUST be ignored.		only the first occurrence is processed. Any others MUST be ignored.
	5.1. SRPOLICY-CAPABILITY TLV		5.1. SRPOLICY-CAPABILITY TLV
	The SRPOLICY-CAPABILITY TLV (Figure 6) is a TLV for the OPEN object.		The SRPOLICY-CAPABILITY TLV (Figure 6) is a TLV for the OPEN object.
	It is used at session establishment to learn the peer's capabilities		It is used at session establishment to learn the peer's capabilities
	skipping to change at line 663 ¶		skipping to change at line 663 ¶
	P-flag (Computation Priority): If set to 1 by a PCEP speaker, the		P-flag (Computation Priority): If set to 1 by a PCEP speaker, the
	P-flag indicates that the PCEP speaker supports the handling of		P-flag indicates that the PCEP speaker supports the handling of
	the COMPUTATION-PRIORITY TLV for the SR Policy (Section 5.2.1).		the COMPUTATION-PRIORITY TLV for the SR Policy (Section 5.2.1).
	If this flag is set to 0, then the receiving PCEP speaker MUST		If this flag is set to 0, then the receiving PCEP speaker MUST
	NOT send the COMPUTATION-PRIORITY TLV and MUST ignore it on		NOT send the COMPUTATION-PRIORITY TLV and MUST ignore it on
	receipt.		receipt.
	E-flag (Explicit NULL Label Policy): If set to 1 by a PCEP		E-flag (Explicit NULL Label Policy): If set to 1 by a PCEP
	speaker, the E-flag indicates that the PCEP speaker supports		speaker, the E-flag indicates that the PCEP speaker supports
	the handling of the Explicit Null Label Policy (ENLP) TLV for		the handling of the EXPLICIT-NULL-LABEL-POLICY TLV for the SR
	the SR Policy (Section 5.2.2). If this flag is set to 0, then		Policy (Section 5.2.2). If this flag is set to 0, then the
	the receiving PCEP speaker MUST NOT send the ENLP TLV and MUST		receiving PCEP speaker MUST NOT send the EXPLICIT-NULL-LABEL-
	ignore it on receipt.		POLICY TLV and MUST ignore it on receipt.
	I-flag (Invalidation): If set to 1 by a PCEP speaker, the I-flag		I-flag (Invalidation): If set to 1 by a PCEP speaker, the I-flag
	indicates that the PCEP speaker supports the handling of the		indicates that the PCEP speaker supports the handling of the
	INVALIDATION TLV for the SR Policy (Section 5.2.3). If this		INVALIDATION TLV for the SR Policy (Section 5.2.3). If this
	flag is set to 0, then the receiving PCEP speaker MUST NOT send		flag is set to 0, then the receiving PCEP speaker MUST NOT send
	the INVALIDATION TLV and MUST ignore it on receipt.		the INVALIDATION TLV and MUST ignore it on receipt.
	L-flag (Stateless Operation): If set to 1 by a PCEP speaker, the		L-flag (Stateless Operation): If set to 1 by a PCEP speaker, the
	L-flag indicates that the PCEP speaker supports the stateless		L-flag indicates that the PCEP speaker supports the stateless
	(PCReq/PCRep) operations for the SR Policy (Section 5.3). If		(PCReq/PCRep) operations for the SR Policy (Section 5.3). If
	skipping to change at line 718 ¶		skipping to change at line 718 ¶
	Length: 4.		Length: 4.
	Priority: 8-bit unsigned integer value that encodes numerical		Priority: 8-bit unsigned integer value that encodes numerical
	priority with which this LSP is to be recomputed by the PCE upon		priority with which this LSP is to be recomputed by the PCE upon
	topology change. The lowest value is the highest priority.		topology change. The lowest value is the highest priority.
	Reserved: This field MUST be set to zero on transmission and MUST be		Reserved: This field MUST be set to zero on transmission and MUST be
	ignored on receipt.		ignored on receipt.
	5.2.2. Explicit Null Label Policy (ENLP) TLV		5.2.2. EXPLICIT-NULL-LABEL-POLICY TLV
	To steer an unlabeled IP packet into an SR Policy for the MPLS data		To steer an unlabeled IP packet into an SR Policy for the MPLS data
	plane, it is necessary to push a label stack of one or more labels on		plane, it is necessary to push a label stack of one or more labels on
	that packet. The Explicit NULL Label Policy (ENLP) TLV is an		that packet. The EXPLICIT-NULL-LABEL-POLICY TLV is an optional TLV
	optional TLV for the LSP object used to indicate whether an Explicit		for the LSP object used to indicate whether an Explicit NULL label
	NULL Label [RFC3032] must be pushed on an unlabeled IP packet before		[RFC3032] must be pushed on an unlabeled IP packet before any other
	any other labels. The contents of this TLV are used by the SR Policy		labels. The contents of this TLV are used by the SR Policy manager
	manager as described in Section 4.1 of [RFC9256]. If an ENLP TLV is		as described in Section 4.1 of [RFC9256]. If an EXPLICIT-NULL-LABEL-
	not present, the decision of whether to push an Explicit NULL label		POLICY TLV is not present, the decision of whether to push an
	on a given packet is a matter of local configuration. Note that		Explicit NULL label on a given packet is a matter of local
	Explicit Null is currently only defined for SR-MPLS and not for SRv6.		configuration. Note that Explicit NULL is currently only defined for
	Therefore, the receiving PCEP speaker MUST ignore the presence of		SR-MPLS and not for SRv6. Therefore, the receiving PCEP speaker MUST
	this TLV for SRv6 Policies.		ignore the presence of this TLV for SRv6 Policies.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ENLP | Reserved |		| ENLP | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: Explicit Null Label Policy (ENLP) TLV Format		Figure 8: EXPLICIT-NULL-LABEL-POLICY TLV Format
	Type: 69 for the ENLP TLV.		Type: 69 for the EXPLICIT-NULL-LABEL-POLICY TLV.
	Length: 4.		Length: 4.
	ENLP: Explicit NULL Label Policy. 8-bit unsigned integer value that		ENLP: Explicit NULL Label Policy. 8-bit unsigned integer value that
	indicates whether Explicit NULL labels are to be pushed on		indicates whether Explicit NULL labels are to be pushed on
	unlabeled IP packets that are being steered into a given SR		unlabeled IP packets that are being steered into a given SR
	Policy. The values of this field are specified in the IANA		Policy. The values of this field are specified in the IANA
	registry "SR Policy ENLP Values" under the "Segment Routing"		registry "SR Policy ENLP Values" under the "Segment Routing"
	registry group, which was introduced in Section 6.10 of [RFC9830].		registry group, which was introduced in Section 6.10 of [RFC9830].
	Reserved: This field MUST be set to zero on transmission and MUST be		Reserved: This field MUST be set to zero on transmission and MUST be
	ignored on receipt.		ignored on receipt.
	The ENLP unassigned values may be used for future extensions, and		The ENLP unassigned values may be used for future extensions, and
	implementations MUST ignore the ENLP TLV with unrecognized values.		implementations MUST ignore the EXPLICIT-NULL-LABEL-POLICY TLV with
	The behavior signaled in this TLV MAY be overridden by local		unrecognized values. The behavior signaled in this TLV MAY be
	configuration by the network operator based on their deployment		overridden by local configuration by the network operator based on
	requirements. Section 4.1 of [RFC9256] describes the behavior on the		their deployment requirements. Section 4.1 of [RFC9256] describes
	headend for the handling of the explicit null label.		the behavior on the headend for the handling of the Explicit NULL
			label.
	5.2.3. INVALIDATION TLV		5.2.3. INVALIDATION TLV
	The INVALIDATION TLV (Figure 9) is an optional TLV. This TLV is used		The INVALIDATION TLV (Figure 9) is an optional TLV. This TLV is used
	to control traffic steering into an LSP when the LSP is operationally		to control traffic steering into an LSP when the LSP is operationally
	down/invalid. In the context of SR Policy, this TLV facilitates the		down/invalid. In the context of SR Policy, this TLV facilitates the
	Drop-Upon-Invalid behavior, specified in Section 8.2 of [RFC9256].		Drop-Upon-Invalid behavior, specified in Section 8.2 of [RFC9256].
	Normally, if the LSP is down/invalid then it stops attracting		Normally, if the LSP is down/invalid then it stops attracting
	traffic; traffic that would have been destined for that LSP is		traffic; traffic that would have been destined for that LSP is
	redirected somewhere else, such as via IGP or another LSP. The Drop-		redirected somewhere else, such as via IGP or another LSP. The Drop-
	skipping to change at line 855 ¶		skipping to change at line 856 ¶
	Path of that SR Policy, i.e., when any Candidate Path has Drop-Upon-		Path of that SR Policy, i.e., when any Candidate Path has Drop-Upon-
	Invalid enabled, it means that the whole SR Policy has the feature		Invalid enabled, it means that the whole SR Policy has the feature
	enabled. As stated in Section 8.1 of [RFC9256], an SR Policy is		enabled. As stated in Section 8.1 of [RFC9256], an SR Policy is
	invalid when all its Candidate Paths are invalid.		invalid when all its Candidate Paths are invalid.
	Once all the Candidate Paths of an SR Policy have become invalid,		Once all the Candidate Paths of an SR Policy have become invalid,
	then the SR Policy checks whether any of the Candidate Paths have		then the SR Policy checks whether any of the Candidate Paths have
	Drop-Upon-Invalid enabled. If so, the SR Policy enters the drop		Drop-Upon-Invalid enabled. If so, the SR Policy enters the drop
	state and "activates" the highest preference Candidate Path that has		state and "activates" the highest preference Candidate Path that has
	the Drop-Upon-Invalid enabled. Note that only one Candidate Path		the Drop-Upon-Invalid enabled. Note that only one Candidate Path
	needs to be reported to the PCE with the D (dropping) flag set.		needs to be reported to the PCE with the Dropping (D) flag set.
	5.3. Updates to RFC 8231		5.3. Updates to RFC 8231
	Section 5.8.2 of [RFC8231] allows delegation of an LSP in		Section 5.8.2 of [RFC8231] allows delegation of an LSP in
	operationally down state, but at the same time mandates the use of		operationally down state, but at the same time mandates the use of
	PCReq before sending PCRpt. This document updates Section 5.8.2 of		PCReq before sending PCRpt. This document updates Section 5.8.2 of
	[RFC8231], by making that section of [RFC8231] not applicable to SR		[RFC8231], by making that section of [RFC8231] not applicable to SR
	Policy LSPs. Thus, when a PCC wants to delegate an SR Policy LSP, it		Policy LSPs. Thus, when a PCC wants to delegate an SR Policy LSP, it
	MAY proceed directly to sending PCRpt, without first sending PCReq		MAY proceed directly to sending PCRpt, without first sending PCReq
	and waiting for PCRep. This has the advantage of reducing the number		and waiting for PCRep. This has the advantage of reducing the number
	skipping to change at line 936 ¶		skipping to change at line 937 ¶
	Table 2		Table 2
	6.3. PCEP Errors		6.3. PCEP Errors
	This document defines the following:		This document defines the following:
	* one new Error-value within the "Mandatory Object Missing" Error-		* one new Error-value within the "Mandatory Object Missing" Error-
	Type,		Type,
	* two new Error-values within the "Association Error" Error-Type,		* one new Error-value within the "Reception of an invalid object",
	and		and
	* one new Error-value within the "Reception of an invalid object".		* two new Error-values within the "Association Error" Error-Type.
	IANA has made the following assignments in the "PCEP-ERROR Object		IANA has made the following assignments in the "PCEP-ERROR Object
	Error Types and Values" registry of the "Path Computation Element		Error Types and Values" registry of the "Path Computation Element
	Protocol (PCEP) Numbers" registry group.		Protocol (PCEP) Numbers" registry group.
	+============+================+======================+===========+
	| Error-Type | Meaning | Error-value | Reference |
	+============+================+======================+===========+
	| 6 | Mandatory | | [RFC5440] |
	| | Object Missing | | |
	| +----------------+----------------------+-----------+
	| | | 21: Missing SR | RFC 9862 |
	| | | Policy Mandatory TLV | |
	+------------+----------------+----------------------+-----------+
	| 26 | Association | | [RFC8697] |
	| | Error | | |
	| +----------------+----------------------+-----------+
	| | | 20: SR Policy | RFC 9862 |
	| | | Identifers Mismatch | |
	| +----------------+----------------------+-----------+
	| | | 21: SR Policy | RFC 9862 |
	| | | Candidate Path | |
	| | | Identifier Mismatch | |
	+------------+----------------+----------------------+-----------+
	Table 3
	IANA has made the following assigments in the "PCEP-ERROR Object
	Error Types and Values" registry of the "Path Computation Element
	Protocol (PCEP) Numbers" registry group.
	+============+=================+=======================+===========+		+============+=================+=======================+===========+
	| Error-Type | Meaning | Error-value | Reference |		| Error-Type | Meaning | Error-value | Reference |
	+============+=================+=======================+===========+		+============+=================+=======================+===========+
	| 6 | Mandatory | | [RFC5440] |		| 6 | Mandatory | | [RFC5440] |
	| | Object Missing | | |		| | Object Missing | | |
	| +-----------------+-----------------------+-----------+		| +-----------------+-----------------------+-----------+
			| | | 21: Missing SR Policy | RFC 9862 |
			| | | Mandatory TLV | |
			| +-----------------+-----------------------+-----------+
	| | | 22: Missing SR Policy | RFC 9862 |		| | | 22: Missing SR Policy | RFC 9862 |
	| | | Association | |		| | | Association | |
	+------------+-----------------+-----------------------+-----------+		+------------+-----------------+-----------------------+-----------+
	| 10 | Reception of an | | [RFC5440] |		| 10 | Reception of an | | [RFC5440] |
	| | invalid object | | |		| | invalid object | | |
	| +-----------------+-----------------------+-----------+		| +-----------------+-----------------------+-----------+
	| | | 44: Missing SRPOLICY- | RFC 9862 |		| | | 44: Missing SRPOLICY- | RFC 9862 |
	| | | CAPABILITY TLV | |		| | | CAPABILITY TLV | |
	+------------+-----------------+-----------------------+-----------+		+------------+-----------------+-----------------------+-----------+
			| 26 | Association | | [RFC8697] |
			| | Error | | |
			| +-----------------+-----------------------+-----------+
			| | | 20: SR Policy | RFC 9862 |
			| | | Identifiers Mismatch | |
			| +-----------------+-----------------------+-----------+
			| | | 21: SR Policy | RFC 9862 |
			| | | Candidate Path | |
			| | | Identifier Mismatch | |
			+------------+-----------------+-----------------------+-----------+
	Table 4		Table 3
	6.4. TE-PATH-BINDING TLV Flag Field		6.4. TE-PATH-BINDING TLV Flag Field
	A draft version of this document added a new bit in the "TE-PATH-		A draft version of this document added a new bit in the "TE-PATH-
	BINDING TLV Flag Field" registry of the "Path Computation Element		BINDING TLV Flag Field" registry of the "Path Computation Element
	Protocol (PCEP) Numbers" registry group, which was early allocated by		Protocol (PCEP) Numbers" registry group, which was early allocated by
	IANA.		IANA.
	IANA has marked the bit position as deprecated.		IANA has marked the bit position as deprecated.
	+=====+==================================+===========+		+=====+==================================+===========+
	| Bit | Description | Reference |		| Bit | Description | Reference |
	+=====+==================================+===========+		+=====+==================================+===========+
	| 1 | Deprecated (Specified-BSID-only) | RFC 9862 |		| 1 | Deprecated (Specified-BSID-only) | RFC 9862 |
	+-----+----------------------------------+-----------+		+-----+----------------------------------+-----------+
	Table 5		Table 4
	6.5. SR Policy Invalidation Operational State		6.5. SR Policy Invalidation Operational State
	IANA has created and will maintain a new registry under the "Path		IANA has created and will maintain a new registry under the "Path
	Computation Element Protocol (PCEP) Numbers" registry group. The new		Computation Element Protocol (PCEP) Numbers" registry group. The new
	registry is called "SR Policy Invalidation Operational Flags". New		registry is called "SR Policy Invalidation Operational Flags". New
	values are to be assigned by "IETF Review" [RFC8126]. Each bit will		values are to be assigned by "IETF Review" [RFC8126]. Each bit will
	be tracked with the following qualities:		be tracked with the following qualities:
	* Bit (counting from bit 0 as the most significant bit)		* Bit (counting from bit 0 as the most significant bit)
	* Description		* Description
	* Reference		* Reference
	+=======+==============================================+===========+		+=====+========================================+===========+
	| Bit | Description | Reference |		| Bit | Description | Reference |
	+=======+==============================================+===========+		+=====+========================================+===========+
	| 0 - 6 | Unassigned | |		| 0 - | Unassigned | |
	+-------+----------------------------------------------+-----------+		| 6 | | |
	| 7 | D: Dropping - the LSP is currently | RFC 9862 |		+-----+----------------------------------------+-----------+
	| | attracting traffic and actively dropping it. | |		| 7 | D: Dropping - the LSP is actively | RFC 9862 |
	+-------+----------------------------------------------+-----------+		| | dropping traffic as a result of Drop- | |
			| | Upon-Invalid behavior being activated. | |
			+-----+----------------------------------------+-----------+
	Table 6		Table 5
	6.6. SR Policy Invalidation Configuration State		6.6. SR Policy Invalidation Configuration State
	IANA has created and will maintain a new registry under the "Path		IANA has created and will maintain a new registry under the "Path
	Computation Element Protocol (PCEP) Numbers" registry group. The new		Computation Element Protocol (PCEP) Numbers" registry group. The new
	registry is called "SR Policy Invalidation Configuration Flags". New		registry is called "SR Policy Invalidation Configuration Flags". New
	values are to be assigned by "IETF Review" [RFC8126]. Each bit will		values are to be assigned by "IETF Review" [RFC8126]. Each bit will
	be tracked with the following qualities:		be tracked with the following qualities:
	* Bit (counting from bit 0 as the most significant bit)		* Bit (counting from bit 0 as the most significant bit)
	* Description		* Description
	* Reference		* Reference
	+=======+==================================+===========+		+=======+========================================+===========+
	| Bit | Description | Reference |		| Bit | Description | Reference |
	+=======+==================================+===========+		+=======+========================================+===========+
	| 0 - 6 | Unassigned. | |		| 0 - 6 | Unassigned. | |
	+-------+----------------------------------+-----------+		+-------+----------------------------------------+-----------+
	| 7 | D: Drop enabled - the Drop-Upon- | RFC 9862 |		| 7 | D: Drop enabled - the Candidate Path | RFC 9862 |
	| | Invalid is enabled on the LSP. | |		| | has Drop-Upon-Invalid feature enabled. | |
	+-------+----------------------------------+-----------+		+-------+----------------------------------------+-----------+
	Table 7		Table 6
	6.7. SR Policy Capability TLV Flag Field		6.7. SR Policy Capability TLV Flag Field
	IANA has created and will maintain a new registry under the "Path		IANA has created and will maintain a new registry under the "Path
	Computation Element Protocol (PCEP) Numbers" registry group. The new		Computation Element Protocol (PCEP) Numbers" registry group. The new
	registry is called "SR Policy Capability TLV Flag Field". New values		registry is called "SR Policy Capability TLV Flag Field". New values
	are to be assigned by "IETF Review" [RFC8126]. Each bit will be		are to be assigned by "IETF Review" [RFC8126]. Each bit will be
	tracked with the following qualities:		tracked with the following qualities:
	* Bit (counting from bit 0 as the most significant bit)		* Bit (counting from bit 0 as the most significant bit)
	skipping to change at line 1086 ¶		skipping to change at line 1076 ¶
	+--------+-------------------------------------+-----------+		+--------+-------------------------------------+-----------+
	| 28 | Unassigned | RFC 9862 |		| 28 | Unassigned | RFC 9862 |
	+--------+-------------------------------------+-----------+		+--------+-------------------------------------+-----------+
	| 29 | Invalidation (I-flag) | RFC 9862 |		| 29 | Invalidation (I-flag) | RFC 9862 |
	+--------+-------------------------------------+-----------+		+--------+-------------------------------------+-----------+
	| 30 | Explicit NULL Label Policy (E-flag) | RFC 9862 |		| 30 | Explicit NULL Label Policy (E-flag) | RFC 9862 |
	+--------+-------------------------------------+-----------+		+--------+-------------------------------------+-----------+
	| 31 | Computation Priority (P-flag) | RFC 9862 |		| 31 | Computation Priority (P-flag) | RFC 9862 |
	+--------+-------------------------------------+-----------+		+--------+-------------------------------------+-----------+
	Table 8		Table 7
	7. Security Considerations		7. Security Considerations
	The information carried in the newly defined SRPA object and TLVs		The information carried in the newly defined SRPA object and TLVs
	could provide an eavesdropper with additional information about the		could provide an eavesdropper with additional information about the
	SR Policy.		SR Policy.
	The security considerations described in [RFC5440], [RFC8231],		The security considerations described in [RFC5440], [RFC8231],
	[RFC8281], [RFC8664], [RFC8697], [RFC9256], and [RFC9603] are		[RFC8281], [RFC8664], [RFC8697], [RFC9256], and [RFC9603] are
	applicable to this specification.		applicable to this specification.
	skipping to change at line 1120 ¶		skipping to change at line 1110 ¶
	8.1. Control of Function and Policy		8.1. Control of Function and Policy
	A PCE or PCC implementation MAY allow the capabilities specified in		A PCE or PCC implementation MAY allow the capabilities specified in
	Section 5.1 and the capability for support of an SRPA advertised in		Section 5.1 and the capability for support of an SRPA advertised in
	the ASSOC-Type-List TLV to be enabled and disabled.		the ASSOC-Type-List TLV to be enabled and disabled.
	8.2. Information and Data Models		8.2. Information and Data Models
	[PCEP-SRv6-YANG] defines a YANG module with common building blocks		[PCEP-SRv6-YANG] defines a YANG module with common building blocks
	for PCEP extensions described in Section 4.		for PCEP extensions described in Section 4 of this document.
	8.3. Liveness Detection and Monitoring		8.3. Liveness Detection and Monitoring
	Mechanisms defined in this document do not imply any new liveness		Mechanisms defined in this document do not imply any new liveness
	detection and monitoring requirements in addition to those already		detection and monitoring requirements in addition to those already
	listed in [RFC5440], [RFC8664], and [RFC9256].		listed in [RFC5440], [RFC8664], and [RFC9256].
	8.4. Verify Correct Operations		8.4. Verify Correct Operations
	Operation verification requirements already listed in [RFC5440],		Operation verification requirements already listed in [RFC5440],
	skipping to change at line 1260 ¶		skipping to change at line 1250 ¶
	Internet-Draft, draft-ietf-idr-bgp-ls-sr-policy-17, 6		Internet-Draft, draft-ietf-idr-bgp-ls-sr-policy-17, 6
	March 2025, <https://datatracker.ietf.org/doc/html/draft-		March 2025, <https://datatracker.ietf.org/doc/html/draft-
	ietf-idr-bgp-ls-sr-policy-17>.		ietf-idr-bgp-ls-sr-policy-17>.
	[PCEP-MULTIPATH]		[PCEP-MULTIPATH]
	Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,		Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,
	Bidgoli, H., Yadav, B., Peng, S., Mishra, G. S., and S.		Bidgoli, H., Yadav, B., Peng, S., Mishra, G. S., and S.
	Sidor, "Path Computation Element Communication Protocol		Sidor, "Path Computation Element Communication Protocol
	(PCEP) Extensions for Signaling Multipath Information",		(PCEP) Extensions for Signaling Multipath Information",
	Work in Progress, Internet-Draft, draft-ietf-pce-		Work in Progress, Internet-Draft, draft-ietf-pce-
	multipath-14, 5 September 2025,		multipath-16, 17 October 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-pce-		<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
	multipath-14>.		multipath-16>.
	[PCEP-SRv6-YANG]		[PCEP-SRv6-YANG]
	Li, C., Sivabalan, S., Peng, S., Koldychev, M., and L.		Li, C., Sivabalan, S., Peng, S., Koldychev, M., and L.
	Ndifor, "A YANG Data Model for Segment Routing (SR) Policy		Ndifor, "A YANG Data Model for Segment Routing (SR) Policy
	and SR in IPv6 (SRv6) support in Path Computation Element		and SR in IPv6 (SRv6) support in Path Computation Element
	Communications Protocol (PCEP)", Work in Progress,		Communications Protocol (PCEP)", Work in Progress,
	Internet-Draft, draft-ietf-pce-pcep-srv6-yang-07, 21 April		Internet-Draft, draft-ietf-pce-pcep-srv6-yang-08, 14
	2025, <https://datatracker.ietf.org/doc/html/draft-ietf-		October 2025, <https://datatracker.ietf.org/doc/html/
	pce-pcep-srv6-yang-07>.		draft-ietf-pce-pcep-srv6-yang-08>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
	[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path		[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
	Computation Element (PCE)-Based Architecture", RFC 4655,		Computation Element (PCE)-Based Architecture", RFC 4655,
	DOI 10.17487/RFC4655, August 2006,		DOI 10.17487/RFC4655, August 2006,
	<https://www.rfc-editor.org/info/rfc4655>.		<https://www.rfc-editor.org/info/rfc4655>.
	skipping to change at line 1304 ¶		skipping to change at line 1294 ¶
	P., and D. Jain, "Advertising Segment Routing Policies in		P., and D. Jain, "Advertising Segment Routing Policies in
	BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,		BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
	<https://www.rfc-editor.org/info/rfc9830>.		<https://www.rfc-editor.org/info/rfc9830>.
	Acknowledgements		Acknowledgements
	We would like to thank Abdul Rehman, Andrew Stone, Boris Khasanov,		We would like to thank Abdul Rehman, Andrew Stone, Boris Khasanov,
	Cheng Li, Dhruv Dhody, Gorry Fairhurst, Gyan Mishra, Huaimo Chen,		Cheng Li, Dhruv Dhody, Gorry Fairhurst, Gyan Mishra, Huaimo Chen,
	Ines Robles, Joseph Salowey, Ketan Talaulikar, Marina Fizgeer, Mike		Ines Robles, Joseph Salowey, Ketan Talaulikar, Marina Fizgeer, Mike
	Bishopm, Praveen Kumar, Robert Sparks, Roman Danyliw, Stephane		Bishopm, Praveen Kumar, Robert Sparks, Roman Danyliw, Stephane
	Litkowski, Tom Petch, Zoey Rose, Xiao Min, Xiong Quan for review and		Litkowski, Tom Petch, Zoey Rose, Xiao Min, and Xiong Quan for their
	suggestions.		reviews and suggestions.
	Contributors		Contributors
	Dhruv Dhody		Dhruv Dhody
	Huawei		Huawei
	India		India
	Email: dhruv.ietf@gmail.com		Email: dhruv.ietf@gmail.com
	Cheng Li		Cheng Li
	Huawei Technologies		Huawei Technologies
End of changes. 39 change blocks.
	98 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.48.