Diff: rfc9753v1.txt - rfc9753.txt

	rfc9753v1.txt	rfc9753.txt

	Internet Engineering Task Force (IETF) C. Li	Internet Engineering Task Force (IETF) C. Li
	Request for Comments: 9753 H. Zheng	Request for Comments: 9753 H. Zheng
	Updates: 8231 Huawei Technologies	Updates: 8231 Huawei Technologies
	Category: Standards Track S. Litkowski	Category: Standards Track S. Litkowski
	ISSN: 2070-1721 Cisco	ISSN: 2070-1721 Cisco

	March 2025	April 2025

	Extension for Stateful PCE to Allow Optional Processing of Path	Extension for Stateful PCE to Allow Optional Processing of Path
	Computation Element Communication Protocol (PCEP) Objects	Computation Element Communication Protocol (PCEP) Objects

	Abstract	Abstract

	This document introduces a mechanism to mark some of the Path	This document introduces a mechanism to mark some of the Path
	Computation Element Communication Protocol (PCEP) objects as optional	Computation Element Communication Protocol (PCEP) objects as optional
	during PCEP message exchange, so the stateful Path Computation	during PCEP message exchange, so the stateful Path Computation
	Element (PCE) model can relax some constraints during path	Element (PCE) model can relax some constraints during path

	skipping to change at line 77 ¶	skipping to change at line 77 ¶
	4. Security Considerations	4. Security Considerations
	5. IANA Considerations	5. IANA Considerations
	5.1. STATEFUL-PCE-CAPABILITY TLV	5.1. STATEFUL-PCE-CAPABILITY TLV
	6. Manageability Considerations	6. Manageability Considerations
	6.1. Control of Function and Policy	6.1. Control of Function and Policy
	6.2. Information and Data Models	6.2. Information and Data Models
	6.3. Liveness Detection and Monitoring	6.3. Liveness Detection and Monitoring
	6.4. Verify Correct Operations	6.4. Verify Correct Operations
	6.5. Requirements on Other Protocols	6.5. Requirements on Other Protocols
	6.6. Impact on Network Operations	6.6. Impact on Network Operations

	7. Acknowledgments	7. References
	8. References	7.1. Normative References
	8.1. Normative References	7.2. Informative References
	8.2. Informative References	Acknowledgments
	Contributors	Contributors
	Authors' Addresses	Authors' Addresses

	1. Introduction	1. Introduction

	[RFC5440] describes the Path Computation Element Communication	[RFC5440] describes the Path Computation Element Communication
	Protocol (PCEP), which enables communication between a Path	Protocol (PCEP), which enables communication between a Path
	Computation Client (PCC) and a Path Control Element (PCE), or between	Computation Client (PCC) and a Path Control Element (PCE), or between
	two PCEs based on the PCE architecture [RFC4655].	two PCEs based on the PCE architecture [RFC4655].


	skipping to change at line 130 ¶	skipping to change at line 130 ¶
	1.1. Requirements Language	1.1. Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	2. Overview	2. Overview


	[RFC5440] describes the handling of unknown objects as per the	Setting the P flag in the PCReq message to handle unknown objects is
	setting of the P flag for the PCReq message. Further, [RFC8231]	as described in Section 7.2 of [RFC5440]. Further, [RFC8231] defined
	defined the usage of the LSP Error Code TLV in the PCRpt message in	the usage of the LSP Error Code TLV in the PCRpt message in response
	response to a failed LSP Update Request via the PCUpd message (for	to a failed LSP Update Request via the PCUpd message (for example,
	example, due to an unsupported object or TLV).	due to an unsupported object or TLV).

	This document specifies the procedure of marking some objects as	This document specifies the procedure of marking some objects as
	'optional to be processed' by the PCEP peer in the stateful PCEP	'optional to be processed' by the PCEP peer in the stateful PCEP
	messages. Furthermore, this document updates the procedure for	messages. Furthermore, this document updates the procedure for
	handling unknown objects in stateful PCEP messages based on the P	handling unknown objects in stateful PCEP messages based on the P
	flag.	flag.

	2.1. Usage Example	2.1. Usage Example

	The PCRpt message is used to report the current state of an LSP. As	The PCRpt message is used to report the current state of an LSP. As
	part of the message, both the <intended-attribute-list> and <actual-	part of the message, both the <intended-attribute-list> and <actual-
	attribute-list> are encoded (see [RFC8231]). For example, the	attribute-list> are encoded (see [RFC8231]). For example, the
	<intended-attribute-list> could include the METRIC object to indicate	<intended-attribute-list> could include the METRIC object to indicate
	a limiting constraint (Bound 'B' flag set) for the Path Delay	a limiting constraint (Bound 'B' flag set) for the Path Delay
	Variation metric [RFC8233]. In some scenarios, it would be useful to	Variation metric [RFC8233]. In some scenarios, it would be useful to
	indicate that this constraint can be relaxed by the PCE in case it	indicate that this constraint can be relaxed by the PCE in case it
	cannot find a path. In these cases, it would be useful to mark the	cannot find a path. In these cases, it would be useful to mark the

	objects as 'optional' and they could be ignored by the PCEP peer.	objects as 'optional' so they could be ignored by the PCEP peer.
	Also, it would be useful for the PCEP speaker to learn if the PCEP	Also, it would be useful for the PCEP speaker to learn if the PCEP
	peer has relaxed the constraint and ignored the processing of the	peer has relaxed the constraint and ignored the processing of the
	PCEP object.	PCEP object.

	Thus, this document specifies how the already existing P and I flags	Thus, this document specifies how the already existing P and I flags
	in the PCEP common object header could be used during the stateful	in the PCEP common object header could be used during the stateful

	PCEP message exchange. It should be noted that similar to handling	PCEP message exchange. The scope of how P and I flags are applied is
	of P and I flags in [RFC5440], the flag applies to full PCEP object	defined in [RFC5440] and is unchanged by this document. Therefore,
	and could not be applied to the granularity of an optional TLVs	these flags can only be applied to an entire PCEP object; they cannot
	encoded in the PCEP object.	be applied at the granularity of optional TLVs encoded in the PCEP
		object.

	3. PCEP Extension	3. PCEP Extension

	3.1. STATEFUL-PCE-CAPABILITY TLV	3.1. STATEFUL-PCE-CAPABILITY TLV

	A PCEP speaker indicates its ability to support the handling of the P	A PCEP speaker indicates its ability to support the handling of the P
	and I flags in the stateful PCEP message exchange during the PCEP	and I flags in the stateful PCEP message exchange during the PCEP
	initialization phase, as follows. During the PCEP initialization	initialization phase, as follows. During the PCEP initialization
	phase, a PCC sends an Open message with an OPEN object that contains	phase, a PCC sends an Open message with an OPEN object that contains
	the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new	the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new

	skipping to change at line 277 ¶	skipping to change at line 278 ¶
	Note that when a PCE is unable to find the path that meets all the	Note that when a PCE is unable to find the path that meets all the
	constraints as per the PCEP object that cannot be ignored (i.e. the	constraints as per the PCEP object that cannot be ignored (i.e. the
	P flag is set), the PCUpd message MAY optionally include the PCEP	P flag is set), the PCUpd message MAY optionally include the PCEP
	objects that caused the path computation to fail along with the empty	objects that caused the path computation to fail along with the empty
	ERO.	ERO.

	3.3.2. The PCRpt Message	3.3.2. The PCRpt Message

	The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to	The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to
	a PCE whether or not an optional object was processed in response to	a PCE whether or not an optional object was processed in response to

	an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate).	a PCUpd or PCInitiate message. The PCC MAY include the ignored
	The PCC MAY include the ignored optional object in its report and set	optional object in its report and set the I flag to indicate that the
	the I flag to indicate that the optional object was ignored at PCC.	optional object was ignored at PCC. When the I flag is cleared, the
	When the I flag is cleared, the PCC indicates that the optional	PCC indicates that the optional object was processed. The I flag has
	object was processed. The I flag has no meaning if the PCRpt message	no meaning if the PCRpt message is not in response to a PCUpd or
	is not in response to a PCUpd or PCInitiate message (i.e., without	PCInitiate message (i.e., without the SRP object in the PCRpt
	the SRP object in the PCRpt message).	message).

	Note that when a PCC is unable to set up a path that meets all the	Note that when a PCC is unable to set up a path that meets all the
	parameters as per the PCEP object that cannot be ignored (i.e., the P	parameters as per the PCEP object that cannot be ignored (i.e., the P
	flag is set), the PCRpt message MAY optionally include the PCEP	flag is set), the PCRpt message MAY optionally include the PCEP
	objects that caused the path setup to fail along with the LSP-ERROR-	objects that caused the path setup to fail along with the LSP-ERROR-
	CODE TLV [RFC8231] indicating the reason for the failure.	CODE TLV [RFC8231] indicating the reason for the failure.

	3.3.3. The PCInitiate Message	3.3.3. The PCInitiate Message


	The I flag has no meaning in the PCinitiate message [RFC8281], so the	The I flag has no meaning in the PCInitiate message [RFC8281], so the
	I flag MUST set to 0 on transmission and ignored on receipt.	I flag MUST set to 0 on transmission and ignored on receipt.

	3.4. Unknown Object Handling	3.4. Unknown Object Handling

	This document updates the handling of unknown objects in the stateful	This document updates the handling of unknown objects in the stateful

	PCEP messages as per the setting of the P flag in the common object	PCEP messages by setting the P flag in the common object header in a
	header in a similar way as [RFC5440], i.e. if a PCEP speaker does not	similar way as described in [RFC5440]. That is, if a PCEP speaker
	understand an object with the P flag set or understands the object	does not understand an object with the P flag set, or if the PCEP
	but decides to ignore the object, the entire stateful PCEP message	speaker understands the object but decides to ignore the object, the
	MUST be rejected and the PCE MUST send a PCErr message with Error-	entire stateful PCEP message MUST be rejected, and the PCE MUST send
	Type="Unknown Object" or "Not supported object" [RFC5440]. If the P	a PCErr message with Error- Type="Unknown Object" or "Not supported
	flag is not set, the PCEP speaker can ignore the object and continue	object" [RFC5440]. If the P flag is not set, the PCEP speaker can
	with the message processing as defined.	ignore the object and continue with the message processing as
		defined.

	[RFC8231] defined the LSP Error Code TLV to be carried in the PCRpt	[RFC8231] defined the LSP Error Code TLV to be carried in the PCRpt
	message in the LSP object to convey error information. This document	message in the LSP object to convey error information. This document
	does not change that procedure.	does not change that procedure.

	4. Security Considerations	4. Security Considerations

	This document specifies how the already existing P and I flags in the	This document specifies how the already existing P and I flags in the
	PCEP common object header could be used during stateful PCEP	PCEP common object header could be used during stateful PCEP
	exchanges. It updates the unknown object error handling in stateful	exchanges. It updates the unknown object error handling in stateful

	skipping to change at line 383 ¶	skipping to change at line 385 ¶
	6.5. Requirements on Other Protocols	6.5. Requirements on Other Protocols

	Mechanisms defined in this document do not imply any new requirements	Mechanisms defined in this document do not imply any new requirements
	on other protocols.	on other protocols.

	6.6. Impact on Network Operations	6.6. Impact on Network Operations

	Mechanisms defined in this document do not have any impact on network	Mechanisms defined in this document do not have any impact on network
	operations in addition to those already listed in [RFC5440].	operations in addition to those already listed in [RFC5440].


	7. Acknowledgments	7. References

	Thanks to Jonathan Hardwick for the discussion and suggestions around
	this document.

	Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and
	Peng Shaofu for their review comments.

	8. References


	8.1. Normative References	7.1. Normative References

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,	Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,	DOI 10.17487/RFC5440, March 2009,
	<https://www.rfc-editor.org/info/rfc5440>.	<https://www.rfc-editor.org/info/rfc5440>.

	skipping to change at line 427 ¶	skipping to change at line 421 ¶
	Path Computation Element Communication Protocol (PCEP)",	Path Computation Element Communication Protocol (PCEP)",
	RFC 8253, DOI 10.17487/RFC8253, October 2017,	RFC 8253, DOI 10.17487/RFC8253, October 2017,
	<https://www.rfc-editor.org/info/rfc8253>.	<https://www.rfc-editor.org/info/rfc8253>.

	[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path	[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
	Computation Element Communication Protocol (PCEP)	Computation Element Communication Protocol (PCEP)
	Extensions for PCE-Initiated LSP Setup in a Stateful PCE	Extensions for PCE-Initiated LSP Setup in a Stateful PCE
	Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,	Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
	<https://www.rfc-editor.org/info/rfc8281>.	<https://www.rfc-editor.org/info/rfc8281>.


	8.2. Informative References	7.2. Informative References

	[PCEP-YANG]	[PCEP-YANG]
	Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.	Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.
	Tantsura, "A YANG Data Model for Path Computation Element	Tantsura, "A YANG Data Model for Path Computation Element
	Communications Protocol (PCEP)", Work in Progress,	Communications Protocol (PCEP)", Work in Progress,
	Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January	Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January
	2025, <https://datatracker.ietf.org/doc/html/draft-ietf-	2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
	pce-pcep-yang-30>.	pce-pcep-yang-30>.

	[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path	[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path

	skipping to change at line 459 ¶	skipping to change at line 453 ¶
	Protocol (PCEP) to Compute Service-Aware Label Switched	Protocol (PCEP) to Compute Service-Aware Label Switched
	Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September	Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
	2017, <https://www.rfc-editor.org/info/rfc8233>.	2017, <https://www.rfc-editor.org/info/rfc8233>.

	[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,	[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
	"Recommendations for Secure Use of Transport Layer	"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security	Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November	(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
	2022, <https://www.rfc-editor.org/info/rfc9325>.	2022, <https://www.rfc-editor.org/info/rfc9325>.


		Acknowledgments

		Thanks to Jonathan Hardwick for the discussion and suggestions around
		this document.

		Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and
		Peng Shaofu for their review comments.

	Contributors	Contributors

	Dhruv Dhody	Dhruv Dhody
	Huawei	Huawei
	India	India
	Email: dhruv.ietf@gmail.com	Email: dhruv.ietf@gmail.com

	Authors' Addresses	Authors' Addresses

	Cheng Li	Cheng Li

End of changes. 12 change blocks.
	42 lines changed or deleted	44 lines changed or added
This html diff was produced by rfcdiff 1.48.