Diff: rfc9753v1.txt - rfc9753.txt

	rfc9753v1.txt	rfc9753.txt

	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

End of changes. 6 change blocks.
	26 lines changed or deleted	28 lines changed or added
This html diff was produced by rfcdiff 1.48.