rfc9753.original   rfc9753.txt 
PCE Working Group C. Li Internet Engineering Task Force (IETF) C. Li
Internet-Draft H. Zheng Request for Comments: 9753 H. Zheng
Updates: 8231 (if approved) Huawei Technologies Updates: 8231 Huawei Technologies
Intended status: Standards Track S. Litkowski Category: Standards Track S. Litkowski
Expires: 31 May 2025 Cisco ISSN: 2070-1721 Cisco
27 November 2024 March 2025
Extension for Stateful PCE to allow Optional Processing of PCE Extension for Stateful PCE to Allow Optional Processing of Path
Communication Protocol (PCEP) Objects Computation Element Communication Protocol (PCEP) Objects
draft-ietf-pce-stateful-pce-optional-13
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 (PCE) Communication Protocol (PCEP) objects as Computation Element Communication Protocol (PCEP) objects as optional
optional during PCEP messages exchange for the Stateful PCE model to during PCEP message exchange, so the stateful Path Computation
allow relaxing some constraints during path computation and setup. Element (PCE) model can relax some constraints during path
This document introduces this relaxation to stateful PCE and updates computation and setup. This document introduces this relaxation to
RFC 8231. stateful PCE, and it updates RFC 8231.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 31 May 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9753.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview
2.1. Usage Example . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Usage Example
3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 4 3. PCEP Extension
3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 4 3.1. STATEFUL-PCE-CAPABILITY TLV
3.2. Handling of P flag . . . . . . . . . . . . . . . . . . . 5 3.2. Handling of the P Flag
3.2.1. The PCRpt Message . . . . . . . . . . . . . . . . . . 5 3.2.1. The PCRpt Message
3.2.1.1. Delegation . . . . . . . . . . . . . . . . . . . 5 3.2.1.1. Delegation
3.2.2. The PCUpd Message and the PCInitiate Message . . . . 6 3.2.2. The PCUpd Message and the PCInitiate Message
3.3. Handling of I flag . . . . . . . . . . . . . . . . . . . 6 3.3. Handling of the I Flag
3.3.1. The PCUpd Message . . . . . . . . . . . . . . . . . . 6 3.3.1. The PCUpd Message
3.3.2. The PCRpt Message . . . . . . . . . . . . . . . . . . 7 3.3.2. The PCRpt Message
3.3.3. The PCInitiate Message . . . . . . . . . . . . . . . 7 3.3.3. The PCInitiate Message
3.4. Unknown Object Handling . . . . . . . . . . . . . . . . . 7 3.4. Unknown Object Handling
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations
5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8 5.1. STATEFUL-PCE-CAPABILITY TLV
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 6. Manageability Considerations
7. Manageability Considerations . . . . . . . . . . . . . . . . 9 6.1. Control of Function and Policy
7.1. Control of Function and Policy . . . . . . . . . . . . . 9 6.2. Information and Data Models
7.2. Information and Data Models . . . . . . . . . . . . . . . 9 6.3. Liveness Detection and Monitoring
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 6.4. Verify Correct Operations
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9 6.5. Requirements on Other Protocols
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 6.6. Impact on Network Operations
7.6. Impact On Network Operations . . . . . . . . . . . . . . 9 7. Acknowledgments
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 10 Contributors
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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].
PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of PCEP extensions for the stateful PCE model [RFC8231] describes a set
extensions to PCEP to enable active control of Multiprotocol Label of extensions to PCEP to enable active control of Multiprotocol Label
Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS)
tunnels. [RFC8281] describes the setup and teardown of PCE-initiated tunnels. [RFC8281] describes the setup and teardown of PCE-initiated
LSPs under the active stateful PCE model, without the need for local LSPs under the active stateful PCE model, without the need for local
configuration on the PCC, thus allowing for dynamic control. configuration on the PCC, thus allowing for dynamic control.
[RFC5440] defined the P flag (Processing-Rule) in the Common Object [RFC5440] defined the P flag (Processing-Rule) in the Common Object
Header to allow a PCC to specify in a Path Computation Request Header to allow a PCC to specify in a Path Computation Request
(PCReq) message (sent to a PCE) whether the object must be taken into (PCReq) message (sent to a PCE) whether the object must be taken into
account by the PCE during path computation or is optional. The I account by the PCE during path computation or is optional. The I
flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep) flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep)
message to indicate to a PCC whether or not an optional object was message to indicate to a PCC whether or not an optional object was
considered by the PCE during path computation. Stateful PCE considered by the PCE during path computation. Stateful PCE
[RFC8231] specified that the P and I flags of the PCEP objects [RFC8231] specifies that the P and I flags of the PCEP objects are to
defined in [RFC8231] is to be set to zero on transmission and ignored be set to zero on transmission and ignored on receipt, since they are
on receipt, since they are exclusively related to the path exclusively related to the path computation requests. This document
computation requests. This document defines a new flag, the R defines a new flag, the R (RELAX) flag in STATEFUL-PCE-CAPABILITY
(RELAX) flag in STATEFUL-PCE-CAPABILITY TLV in the PCEP common object TLV, in the PCEP common object header to indicate a PCE speaker
header to indicate a PCE speaker supporting P and I flags processing, supporting P and I flags processing, and it also specifies how the P
and also specifies how the P and I flags could be used in the and I flags could be used in the stateful PCE model to identify
stateful PCE model to identify optional objects in the Path optional objects in the Path Computation State Report (PCRpt)
Computation State Report (PCRpt) [RFC8231], the Path Computation [RFC8231], the Path Computation Update Request (PCUpd) [RFC8231], and
Update Request (PCUpd) [RFC8231], and the LSP Initiate Request the LSP Initiate Request (PCInitiate) [RFC8281] messages.
(PCInitiate) [RFC8281] message.
This document updates [RFC8231] concerning usage of the P and I flags This document updates [RFC8231] concerning usage of the P and I flags
as well as the handling of unknown objects in the stateful PCEP as well as the handling of unknown objects in stateful PCEP message
message exchange. exchange.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview 2. Overview
[RFC5440] describes the handling of unknown objects as per the [RFC5440] describes the handling of unknown objects as per the
setting of the P flag for the PCReq message. Further, [RFC8231] setting of the P flag for the PCReq message. Further, [RFC8231]
defined the usage of the LSP Error Code TLV in the PCRpt message in defined the usage of the LSP Error Code TLV in the PCRpt message in
response to failed LSP Update Request via the PCUpd message (for response to a failed LSP Update Request via the PCUpd message (for
example, due to an unsupported object/TLV). example, 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 the 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
state that this limiting constraint can be relaxed by the PCE in case indicate that this constraint can be relaxed by the PCE in case it
it cannot find a path. In these cases, it would be useful to mark cannot find a path. In these cases, it would be useful to mark the
the objects as 'optional' and they could be ignored by the PCEP peer. objects as 'optional' and 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. Further, it should be noted that similar to PCEP message exchange. It should be noted that similar to handling
handling of P and I flags in [RFC5440], the flag applies to full PCEP of P and I flags in [RFC5440], the flag applies to full PCEP object
Object and could not be applied to the granularity of an optional and could not be applied to the granularity of an optional TLVs
TLVs encoded in the PCEP Object. 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
flag, the R (RELAX) flag, is added to this TLV to indicate the flag, the R (RELAX) flag, is added to this TLV to indicate support
support for relaxing the processing of some objects via the use of for relaxing the processing of some objects via the use of the P and
the P and I flags in the PCEP common object header. I flags in the PCEP common object header.
R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag R (RELAX bit - 17): If set to 1 by a PCEP Speaker, the R flag
indicates that the PCEP Speaker is willing to handle the P and I indicates that the PCEP Speaker is willing to handle the P and I
flags in the PCEP common object header for the PCEP objects in the flags in the PCEP common object header for the PCEP objects in the
stateful PCEP messages. If the bit is unset, it indicates that the stateful PCEP messages. If the bit is unset, it indicates that the
PCEP Speaker would not handle the P and I flags in the PCEP common PCEP Speaker will not handle the P and I flags in the PCEP common
object header for stateful PCE messages. object header for stateful PCE messages.
The R flag MUST be set by both PCC and PCE to indicate support for The R flag MUST be set by both the PCC and PCE to indicate support
the handling of the P and I flags in the PCEP common object header to for handling the P and I flags in the PCEP common object header to
allow relaxing some constraints by marking objects as 'optional to allow relaxing some constraints by marking objects as 'optional to
process'. If the PCEP speaker did not set the R flag but receives process'. If the PCEP speaker does not set the R flag but receives
PCEP objects with P or I bit set, it MUST ignore the flags. PCEP objects with the P or I bits set, it MUST ignore the flags.
[RFC8231] stated that P and I flags of the PCEP objects defined in [RFC8231] states that P and I flags of the PCEP objects are set to 0
[RFC8231] are set to 0 on transmission and ignored on receipt. It on transmission and ignored on receipt. It fails to mention the
failed to mention the behaviour of objects defined outside of behaviour of objects defined outside of [RFC8231], leading to
[RFC8231] leading to ambiguity. ambiguity.
3.2. Handling of P flag 3.2. Handling of the P Flag
3.2.1. The PCRpt Message 3.2.1. The PCRpt Message
The P flag in the PCRpt message [RFC8231] allows a PCC to specify to The P flag in the PCRpt message [RFC8231] allows a PCC to specify to
a PCE whether the object must be taken into account by the PCE a PCE whether the object must be taken into account by the PCE
(during state maintenance, path computation, or re-optimisation) or (during state maintenance, path computation, or re-optimisation) or
is optional to process. When the P flag is set in the PCRpt message is optional to process. When the P flag is set in the PCRpt message
received on a PCEP session on which the R bit is set by both peers, received on a PCEP session on which the R bit is set by both peers,
the object MUST be taken into account by the PCE. Conversely, when the object MUST be taken into account by the PCE. Conversely, when
the P flag is cleared, the object is optional and the PCE is free to the P flag is cleared, the object is optional and the PCE can ignore
ignore it. The P flag for the mandatory objects, such as the LSP and it. The P flag for the mandatory objects, such as the LSP and the
the ERO (Explicit Route Object) object (intended path), MUST be set ERO (Explicit Route Object) object (intended path), MUST be set in
in the PCRpt message. If a mandatory object is received with the P the PCRpt message. If a mandatory object is received with the P flag
flag set incorrectly according to the rules stated above, the set incorrectly according to the rules stated above, the receiving
receiving peer MUST send a PCErr message with Error-Type=10 peer MUST send a PCErr message with Error-Type=10 (Reception of an
(Reception of an invalid object) and Error-value=1 (reception of an invalid object) and Error-value=1 (Reception of an object with P flag
object with P flag not set). On a PCEP session on which the R bit not set). On a PCEP session on which the R bit was set by both
was set by both peers, the PCC SHOULD set the P flag by default, peers, the PCC SHOULD set the P flag by default, unless a local
unless a local configuration or local policy indicates that some configuration or local policy indicates that some constraints
constraints (corresponding PCEP objects) can be marked as optional (corresponding PCEP objects) can be marked as optional and could be
and could be ignored by the PCE or the object itself conveys ignored by the PCE or the object itself conveys informational
informational parameters that can be safely ignored. parameters that can be safely ignored.
3.2.1.1. Delegation 3.2.1.1. Delegation
Delegation is an operation to grant a PCE temporary rights to modify Delegation is an operation to grant a PCE temporary rights to modify
a subset of parameters on one or more LSPs by a PCC as described in a subset of parameters on one or more LSPs by a PCC as described in
[RFC8051]. Note that for the delegated LSPs, the PCE can update and [RFC8051]. Note that for the delegated LSPs, the PCE can update and
mark some objects as ignored even when the PCC had set the P flag mark some objects as ignored even when the PCC has set the P flag
during the delegation. Similarly, the PCE can update and mark some during the delegation. Similarly, the PCE can update and mark some
objects as a 'must to process' even when the PCC had not set the P objects as a 'must to process' even when the PCC has not set the P
flag during delegation. flag during delegation.
The PCC MUST acknowledge this by sending the PCRpt message with the P The PCC MUST acknowledge this by sending the PCRpt message with the P
flag set as per the PCE expectation for the corresponding object. If flag set as per the PCE expectation for the corresponding object. If
PCC cannot accept the update message, it MUST react as per the the PCC cannot accept the update message, it MUST react as per the
processing rules of unacceptable update in section 5.8.3 of processing rules of unacceptable update in Section 5.8.3 of
[RFC8231]. [RFC8231].
3.2.2. The PCUpd Message and the PCInitiate Message 3.2.2. The PCUpd Message and the PCInitiate Message
The P flag in the PCUpd message [RFC8231] and the PCInitiate message The P flag in the PCUpd message [RFC8231] and the PCInitiate message
[RFC8281] allows a PCE to specify to a PCC whether the object must be [RFC8281] allows a PCE to specify to a PCC whether the object must be
taken into account by the PCC (during path setup) or is optional to taken into account by the PCC (during path setup) or is optional to
process. When the P flag is set in the PCUpd/PCInitiate message process. When the P flag is set in the PCUpd/PCInitiate message
received on a PCEP session on which the R bit was set by both peers, received on a PCEP session on which the R bit was set by both peers,
the object MUST be taken into account by the PCC. Conversely, when the object MUST be taken into account by the PCC. Conversely, when
the P flag is cleared, the object is optional and the PCC is free to the P flag is cleared, the object is optional and the PCC can ignore
ignore it. The P flag for the mandatory objects, such as the SRP it. The P flag for the mandatory objects -- such as the SRP
(Stateful PCE Request Parameters), the LSP and the ERO, MUST be set (Stateful PCE Request Parameters), the LSP, and the ERO -- MUST be
in the PCUpd/PCInitiate message. If a mandatory object is received set in the PCUpd/PCInitiate message. If a mandatory object is
with the P flag set incorrectly according to the rules stated above, received with the P flag set incorrectly according to the rules
the receiving peer MUST send a PCErr message with Error-Type=10 stated above, the receiving peer MUST send a PCErr message with
(Reception of an invalid object) and Error-value=1 (reception of an Error-Type=10 (Reception of an invalid object) and Error-value=1
object with P flag not set). On a PCEP session in which both peers (Reception of an object with P flag not set). On a PCEP session in
set R bit, the PCE SHOULD set the P flag by default unless a local which both peers set the R bit, the PCE SHOULD set the P flag by
configuration/policy indicates that some constraints (corresponding default unless a local configuration/policy indicates that some
PCEP objects) can be marked as optional and could be ignored by the constraints (corresponding PCEP objects) can be marked as optional
PCC or the object itself conveys informational parameters that can be and can be ignored by the PCC or the object itself conveys
safely ignored. informational parameters that can be safely ignored.
3.3. Handling of I flag 3.3. Handling of the I Flag
3.3.1. The PCUpd Message 3.3.1. The PCUpd Message
The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to
a PCC whether or not an optional object was processed. The PCE MAY a PCC whether or not an optional object was processed. The PCE MAY
include the ignored optional object in its update request and set the include the ignored optional object in its update request and set the
I flag to indicate that the optional object was ignored. When the I I flag to indicate that the optional object was ignored. When the I
flag is cleared, the PCE indicates that the optional object was flag is cleared, the PCE indicates that the optional object was
processed. processed.
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). an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate).
The PCC MAY include the ignored optional object in its report and set The PCC MAY include the ignored optional object in its report and set
the I flag to indicate that the optional object was ignored at PCC. the I flag to indicate that the optional object was ignored at PCC.
When the I flag is cleared, the PCC indicates that the optional When the I flag is cleared, the PCC indicates that the optional
object was processed. The I flag has no meaning if the PCRpt message object was processed. The I flag has no meaning if the PCRpt message
is not in response to a PCUpd or PCInitiate message (i.e. without the is not in response to a PCUpd or PCInitiate message (i.e., without
SRP object in the PCRpt message). the SRP object in the PCRpt message).
Note that when a PCC is unable to set up the 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 as per the setting of the P flag in the common object
header in a similar way as [RFC5440], i.e. if a PCEP speaker does not header in a similar way as [RFC5440], i.e. if a PCEP speaker does not
understand an object with the P flag set or understands the object understand an object with the P flag set or understands the object
but decides to ignore the object, the entire stateful PCEP message but decides to ignore the object, the entire stateful PCEP message
MUST be rejected and the PCE MUST send a PCErr message with Error- MUST be rejected and the PCE MUST send a PCErr message with Error-
Type="Unknown Object" or "Not supported Object" [RFC5440]. In case Type="Unknown Object" or "Not supported object" [RFC5440]. If the P
the P flag is not set, the PCEP speaker is free to ignore the object flag is not set, the PCEP speaker can ignore the object and continue
and continue with the message processing as defined. with the message processing as defined.
[RFC8231] defined LSP Error Code TLV to be carried in PCRpt message [RFC8231] defined the LSP Error Code TLV to be carried in the PCRpt
in the LSP object to convey error information. This document does message in the LSP object to convey error information. This document
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
PCEP message exchange. These changes on their own do not add any new PCEP message exchange. On their own, these changes do not add any
security concerns. The security considerations identified in new security concerns. The security considerations identified in
[RFC5440], [RFC8231], and [RFC8281] continue to apply. [RFC5440], [RFC8231], and [RFC8281] continue to apply.
As per [RFC8231], it is RECOMMENDED that these PCEP extensions can As per [RFC8231], it is RECOMMENDED that these PCEP extensions can
only be activated on authenticated and encrypted sessions across PCEs only be activated on authenticated and encrypted sessions across PCEs
and PCCs belonging to the same administrative authority, using and PCCs belonging to the same administrative authority, using
Transport Layer Security (TLS) [RFC8253] as per the recommendations Transport Layer Security (TLS) [RFC8253] as per the recommendations
and best current practices in [RFC9325]. and best current practices described in [RFC9325].
5. IANA Considerations 5. IANA Considerations
5.1. STATEFUL-PCE-CAPABILITY TLV 5.1. STATEFUL-PCE-CAPABILITY TLV
[RFC8231] defined the STATEFUL-PCE-CAPABILITY TLV and IANA created [RFC8231] defined the STATEFUL-PCE-CAPABILITY TLV and IANA created
the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry to manage the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry to manage the
the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA is value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA has
requested to allocate a new bit in the subregistry, as follows: allocated a new bit in the registry, as follows:
Bit Description Reference
-------------------------------------------------
TBD1 RELAX bit [This-I.D.]
6. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups +=====+=============+===========+
to assign due consideration to documents that have the benefit of | Bit | Description | Reference |
running code, which may serve as evidence of valuable experimentation +=====+=============+===========+
and feedback that have made the implemented protocols more mature. | 17 | RELAX | RFC 9753 |
It is up to the individual working groups to use this information as +-----+-------------+-----------+
they see fit".
At the time of posting the -09 version of this document, there are no Table 1
known implementations of this mechanism. It is believed that some
vendors are considering implementations, but these plans are too
vague to make any further assertions.
7. Manageability Considerations 6. Manageability Considerations
7.1. Control of Function and Policy 6.1. Control of Function and Policy
An implementation supporting this document SHOULD allow configuration An implementation supporting this document SHOULD allow configuration
of the capability to support relaxation of constraints in the of the capability to support relaxation of constraints in the
stateful PCEP message exchange. They SHOULD also allow configuration stateful PCEP message exchange. They SHOULD also allow configuration
of related LSP constraints (or parameters) that are optional to of related LSP constraints (or parameters) that are optional to
process. process.
7.2. Information and Data Models 6.2. Information and Data Models
An implementation supporting this document SHOULD allow the operator An implementation supporting this document SHOULD allow the operator
to view the capability defined in this document. To serve this to view the capability defined in this document. To serve this
purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] could be purpose, the PCEP YANG module [PCEP-YANG] could be extended in the
extended in the future. future.
7.3. Liveness Detection and Monitoring 6.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]. listed in [RFC5440].
7.4. Verify Correct Operations 6.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[RFC5440]. [RFC5440].
7.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.
7.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].
8. Acknowledgments 7. Acknowledgments
Thanks to Jonathan Hardwick for the discussion and suggestions around Thanks to Jonathan Hardwick for the discussion and suggestions around
this draft. this document.
Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and
Peng Shaofu for the review comments. Peng Shaofu for their review comments.
9. References 8. References
9.1. Normative References 8.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 page 10, line 44 skipping to change at line 427
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>.
9.2. Informative References 8.2. Informative References
[I-D.ietf-pce-pcep-yang] [PCEP-YANG]
Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura, Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.
"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-26, 19 October Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-26>. 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
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>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication "Extensions to the Path Computation Element Communication
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>.
Appendix A. 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
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing Beijing
100095 100095
China China
 End of changes. 62 change blocks. 
219 lines changed or deleted 182 lines changed or added

This html diff was produced by rfcdiff 1.48.