rfc9753xml2.original.xml   rfc9753.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-pce-stateful-pce-optional-13"
ipr="trust200902" obsoletes="" submissionType="IETF" updates="8231"
xml:lang="en">
<front>
<title abbrev="STATEFUL-OPT">Extension for Stateful PCE to allow Optional
Processing of PCE Communication Protocol (PCEP) Objects</title>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-pce-stateful-pce-optional-13" number="9753" consensus="true" ipr="trust200902
" obsoletes="" submissionType="IETF" updates="8231" xml:lang="en" tocInclude="tr
ue" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="Optional Processing of PCEP Objects">Extension for Stateful P
CE to Allow Optional
Processing of Path Computation Element Communication Protocol (PCEP) Objects
</title>
<seriesInfo name="RFC" value="9753"/>
<author fullname="Cheng Li" initials="C." surname="Li"> <author fullname="Cheng Li" initials="C." surname="Li">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<region/>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>c.l@huawei.com</email> <email>c.l@huawei.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Haomian Zheng" initials="H." surname="Zheng"> <author fullname="Haomian Zheng" initials="H." surname="Zheng">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street> <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
<city>Dongguan</city> <city>Dongguan</city>
<region>Guangdong</region> <region>Guangdong</region>
<code>523808</code> <code>523808</code>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>zhenghaomian@huawei.com</email> <email>zhenghaomian@huawei.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski"> <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>slitkows.ietf@gmail.com</email> <email>slitkows.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="April" year="2025"/>
<area>RTG</area>
<workgroup>pce</workgroup>
<date/> <keyword>PCEP</keyword>
<keyword>Stateful</keyword>
<area>Routing</area> <keyword>optional processing</keyword>
<workgroup>PCE Working Group</workgroup>
<abstract> <abstract>
<t>This document introduces a mechanism to mark some of the Path <t>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 during PCEP messages exchange for the Stateful PCE model to optional during PCEP message exchange, so the stateful Path Computation El
allow relaxing some constraints during path computation and setup. This ement (PCE) model
document introduces this relaxation to stateful PCE and updates RFC can relax some constraints during path computation and setup. This
document introduces this relaxation to stateful PCE, and it updates RFC
8231.</t> 8231.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<t><xref target="RFC5440"/> describes the Path Computation Element <name>Introduction</name>
Communication Protocol (PCEP) which enables communication between a Path <t><xref target="RFC5440" format="default"/> describes the Path Computatio
n Element
Communication 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 <xref target="RFC4655"/>.</t> two PCEs based on the PCE architecture <xref target="RFC4655" format="defa
ult"/>.</t>
<t>PCEP Extensions for Stateful PCE Model <xref target="RFC8231"/> <t>PCEP extensions for the stateful PCE model <xref target="RFC8231" forma
t="default"/>
describes a set of extensions to PCEP to enable active control of describes a set of extensions to PCEP to enable active control of
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
Generalized MPLS (GMPLS) tunnels. <xref target="RFC8281"/> describes the Generalized MPLS (GMPLS) tunnels. <xref target="RFC8281" format="default"/ > describes the
setup and teardown of PCE-initiated LSPs under the active stateful PCE setup and teardown of PCE-initiated LSPs under the active stateful PCE
model, without the need for local configuration on the PCC, thus model, without the need for local configuration on the PCC, thus
allowing for dynamic control.</t> allowing for dynamic control.</t>
<t><xref target="RFC5440" format="default"/> defined the P flag (Processin
<t><xref target="RFC5440"/> defined the P flag (Processing-Rule) in the g-Rule) in the
Common Object Header to allow a PCC to specify in a Path Computation Common Object Header to allow a PCC to specify in a Path Computation
Request (PCReq) message (sent to a PCE) whether the object must be taken Request (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 into 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 <xref considered by the PCE during path computation. Stateful PCE <xref target="
target="RFC8231"/> specified that the P and I flags of the PCEP objects RFC8231" format="default"/> specifies that the P and I flags of the PCEP objects
defined in <xref target="RFC8231"/> is to be set to zero on transmission are to be set to zero on transmission
and ignored on receipt, since they are exclusively related to the path and ignored on receipt, since they are exclusively related to the path
computation requests. This document defines a new flag, the R (RELAX) computation requests. This document defines a new flag, the R (RELAX)
flag in STATEFUL-PCE-CAPABILITY TLV in the PCEP common object header to flag in STATEFUL-PCE-CAPABILITY TLV, in the PCEP common object header to
indicate a PCE speaker supporting P and I flags processing, and also indicate a PCE speaker supporting P and I flags processing, and it also
specifies how the P and I flags could be used in the stateful PCE model specifies how the P and I flags could be used in the stateful PCE model
to identify optional objects in the Path Computation State Report to identify optional objects in the Path Computation State Report
(PCRpt) <xref target="RFC8231"/>, the Path Computation Update Request (PCRpt) <xref target="RFC8231" format="default"/>, the Path Computation Up
(PCUpd) <xref target="RFC8231"/>, and the LSP Initiate Request date Request
(PCInitiate) <xref target="RFC8281"/> message.</t> (PCUpd) <xref target="RFC8231" format="default"/>, and the LSP Initiate Re
quest
<t>This document updates <xref target="RFC8231"/> concerning usage of (PCInitiate) <xref target="RFC8281" format="default"/> messages.</t>
the P and I flags as well as the handling of unknown objects in the <t>This document updates <xref target="RFC8231" format="default"/> concern
ing usage of
the P and I flags as well as the handling of unknown objects in
stateful PCEP message exchange.</t> stateful PCEP message exchange.</t>
<section toc="default" numbered="true">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<section title="Requirements Language" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/>.</t>-->
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<name>Overview</name>
<section title="Overview" toc="default"> <t>Setting the P flag in the PCReq message to handle unknown objects
<t><xref target="RFC5440"/> describes the handling of unknown objects as is as described in <xref target="RFC5440" section="7.2" sectionFormat="of"/>.
per the setting of the P flag for the PCReq message. Further, <xref Further, <xref target="RFC8231" format="default"/> defined the usage of the LSP
target="RFC8231"/> defined the usage of the LSP Error Code TLV in the Error Code TLV in the
PCRpt message in response to failed LSP Update Request via the PCUpd PCRpt message in response to a failed LSP Update Request via the PCUpd
message (for example, due to an unsupported object/TLV).</t> message (for example, due to an unsupported object or TLV).</t>
<t>This document specifies the procedure of marking some objects as <t>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 handling messages. Furthermore, this document updates the procedure for handling
unknown objects in the stateful PCEP messages based on the P flag.</t> unknown objects in stateful PCEP messages based on the P flag.</t>
<section toc="default" numbered="true">
<section title="Usage Example" toc="default"> <name>Usage Example</name>
<t>The PCRpt message is used to report the current state of an LSP. As <t>The PCRpt message is used to report the current state of an LSP. As
part of the message both the &lt;intended-attribute-list&gt; and part of the message, both the &lt;intended-attribute-list&gt; and
&lt;actual-attribute-list&gt; are encoded (see <xref &lt;actual-attribute-list&gt; are encoded (see <xref target="RFC8231" fo
target="RFC8231"/>). For example, the &lt;intended-attribute-list&gt; rmat="default"/>). For example, the &lt;intended-attribute-list&gt;
could include the METRIC object to indicate a limiting constraint could include the METRIC object to indicate a limiting constraint
(Bound 'B' flag set) for the Path Delay Variation metric <xref (Bound 'B' flag set) for the Path Delay Variation metric <xref target="R
target="RFC8233"/>. In some scenarios, it would be useful to state FC8233" format="default"/>.
that this limiting constraint can be relaxed by the PCE in case it In some scenarios, it would be useful to indicate
that this constraint can be relaxed by the PCE in case it
cannot find a path. <!--Similarly in the case of an association group cannot find a path. <!--Similarly in the case of an association group
<xref target="RFC8697"/> such as Disjoint Association <xref <xref target="RFC8697"/> such as Disjoint Association <xref
target="RFC8800"/>, the PCE may need to completely relax the target="RFC8800"/>, the PCE may need to completely relax the
disjointness constraint in order to provide a path to all the LSPs disjointness constraint in order to provide a path to all the LSPs
that are part of the association.--> In these cases, it would be that are part of the association.-->
useful to mark the objects as 'optional' and they could be ignored by In these cases, it would be useful to mark
the PCEP peer. Also, it would be useful for the PCEP speaker to learn the 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 peer has relaxed the constraint and ignored the processing if the PCEP peer has relaxed the constraint and ignored the processing
of the PCEP object.</t> of the PCEP object.</t>
<t>Thus, this document specifies how the already existing P and I <t>Thus, this document specifies how the already existing P and I
flags in the PCEP common object header could be used during the flags in the PCEP common object header could be used during the
stateful PCEP message exchange. Further, it should be noted that stateful PCEP message exchange.
similar to handling of P and I flags in <xref target="RFC5440"/>, the The scope of how P and I flags are applied is defined in <xref target="RFC5440"
flag applies to full PCEP Object and could not be applied to the /> and is unchanged by this document. Therefore, these flags can only be applied
granularity of an optional TLVs encoded in the PCEP Object.</t> to an entire PCEP
object; they cannot be applied at the granularity of optional TLVs encoded in t
he PCEP object.
</t>
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<section title="PCEP Extension" toc="default"> <name>PCEP Extension</name>
<section title="STATEFUL-PCE-CAPABILITY TLV" toc="default"> <section toc="default" numbered="true">
<name>STATEFUL-PCE-CAPABILITY TLV</name>
<t>A PCEP speaker indicates its ability to support the handling of the <t>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 P 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 <xref the STATEFUL-PCE-CAPABILITY TLV, as defined in <xref target="RFC8231" fo
target="RFC8231"/>. A new flag, the R (RELAX) flag, is added to this rmat="default"/>. A new flag, the R (RELAX) flag, is added to this
TLV to indicate the support for relaxing the processing of some TLV to indicate support for relaxing the processing of some
objects via the use of the P and I flags in the PCEP common object objects via the use of the P and I flags in the PCEP common object
header.</t> header.</t>
<t>R (RELAX bit - 17): If set to 1 by a PCEP Speaker, the R flag
<t>R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag
indicates that the PCEP Speaker is willing to handle the P and I flags 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 stateful in the PCEP common object header for the PCEP objects in the stateful
PCEP messages. If the bit is unset, it indicates that the PCEP Speaker 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 object header will not handle the P and I flags in the PCEP common object header
for stateful PCE messages.</t> for stateful PCE messages.</t>
<t>The R flag MUST be set by both PCC and PCE to indicate support for <t>The R flag <bcp14>MUST</bcp14> be set by both the PCC and PCE to indi
the handling of the P and I flags in the PCEP common object header to cate support 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 PCEP 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. <xref objects with the P or I bits set, it <bcp14>MUST</bcp14> ignore the flag
target="RFC8231"/> stated that P and I flags of the PCEP objects s. <xref target="RFC8231" format="default"/> states that P and I flags of the PC
defined in <xref target="RFC8231"/> are set to 0 on transmission and EP objects
ignored on receipt. It failed to mention the behaviour of objects are set to 0 on transmission and
defined outside of <xref target="RFC8231"/> leading to ambiguity.</t> ignored on receipt. It fails to mention the behaviour of objects
defined outside of <xref target="RFC8231" format="default"/>, leading to
ambiguity.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Handling of P flag" toc="default"> <name>Handling of the P Flag</name>
<section title="The PCRpt Message" toc="default"> <section toc="default" numbered="true">
<t>The P flag in the PCRpt message <xref target="RFC8231"/> allows a <name>The PCRpt Message</name>
<t>The P flag in the PCRpt message <xref target="RFC8231" format="defa
ult"/> allows a
PCC to specify to a PCE whether the object must be taken into PCC to specify to a PCE whether the object must be taken into
account by the PCE (during state maintenance, path computation, or account by the PCE (during state maintenance, path computation, or
re-optimisation) or is optional to process. When the P flag is set re-optimisation) or is optional to process. When the P flag is set
in the PCRpt message received on a PCEP session on which the R bit in the PCRpt message received on a PCEP session on which the R bit
is set by both peers, the object MUST be taken into account by the is set by both peers, the object <bcp14>MUST</bcp14> be taken into acc ount by the
PCE. Conversely, when the P flag is cleared, the object is optional PCE. Conversely, when the P flag is cleared, the object is optional
and the PCE is free to ignore it. The P flag for the mandatory and the PCE can ignore it. The P flag for the mandatory
objects, such as the LSP and the ERO (Explicit Route Object) object objects, such as the LSP and the ERO (Explicit Route Object) object
(intended path), MUST be set in the PCRpt message. If a mandatory (intended path), <bcp14>MUST</bcp14> be set in the PCRpt message. If a mandatory
object is received with the P flag set incorrectly according to the object is received with the P flag set incorrectly according to the
rules stated above, the receiving peer MUST send a PCErr message rules stated above, the receiving peer <bcp14>MUST</bcp14> send a PCEr r message
with Error-Type=10 (Reception of an invalid object) and with Error-Type=10 (Reception of an invalid object) and
Error-value=1 (reception of an object with P flag not set). On a Error-value=1 (Reception of an object with P flag not set). On a
PCEP session on which the R bit was set by both peers, the PCC PCEP session on which the R bit was set by both peers, the PCC
SHOULD set the P flag by default, unless a local configuration or <bcp14>SHOULD</bcp14> set the P flag by default, unless a local config uration or
local policy indicates that some constraints (corresponding PCEP local policy indicates that some constraints (corresponding PCEP
objects) can be marked as optional and could be ignored by the PCE objects) can be marked as optional and could be ignored by the PCE
or the object itself conveys informational parameters that can be or the object itself conveys informational parameters that can be
safely ignored.</t> safely ignored.</t>
<section toc="default" numbered="true">
<section title="Delegation" toc="default"> <name>Delegation</name>
<t>Delegation is an operation to grant a PCE temporary rights to <t>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 modify a subset of parameters on one or more LSPs by a PCC as
described in <xref target="RFC8051"/>. Note that for the delegated described in <xref target="RFC8051" format="default"/>. Note that fo r the delegated
LSPs, the PCE can update and mark some objects as ignored even LSPs, the PCE can update and mark some objects as ignored even
when the PCC had set the P flag during the delegation. Similarly, when the PCC has set the P flag during the delegation. Similarly,
the PCE can update and mark some objects as a 'must to process' the PCE can update and mark some objects as a 'must to process'
even when the PCC had not set the P flag during delegation.</t> even when the PCC has not set the P flag during delegation.</t>
<t>The PCC MUST acknowledge this by sending the PCRpt message with <t>The PCC <bcp14>MUST</bcp14> acknowledge this by sending the PCRpt message with
the P flag set as per the PCE expectation for the corresponding the P flag set as per the PCE expectation for the corresponding
object. If PCC cannot accept the update message, it MUST react as object. If the PCC cannot accept the update message, it <bcp14>MUST<
per the processing rules of unacceptable update in section 5.8.3 /bcp14> react as
of <xref target="RFC8231"/>.</t> per the processing rules of unacceptable update in <xref section="5.
8.3" target="RFC8231" format="default"/>.</t>
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<section title="The PCUpd Message and the PCInitiate Message" <name>The PCUpd Message and the PCInitiate Message</name>
toc="default"> <t>The P flag in the PCUpd message <xref target="RFC8231" format="defa
<t>The P flag in the PCUpd message <xref target="RFC8231"/> and the ult"/> and the
PCInitiate message <xref target="RFC8281"/> allows a PCE to specify PCInitiate message <xref target="RFC8281" format="default"/> allows a
PCE to specify
to a PCC whether the object must be taken into account by the PCC to a PCC whether the object must be taken into account by the PCC
(during path setup) or is optional to process. When the P flag is (during path setup) or is optional to process. When the P flag is
set in the PCUpd/PCInitiate message received on a PCEP session on set in the PCUpd/PCInitiate message received on a PCEP session on
which the R bit was set by both peers, the object MUST be taken into which the R bit was set by both peers, the object <bcp14>MUST</bcp14> be taken into
account by the PCC. Conversely, when the P flag is cleared, the account by the PCC. Conversely, when the P flag is cleared, the
object is optional and the PCC is free to ignore it. The P flag for object is optional and the PCC can ignore it. The P flag for
the mandatory objects, such as the SRP (Stateful PCE Request the mandatory objects -- such as the SRP (Stateful PCE Request
Parameters), the LSP and the ERO, MUST be set in the Parameters), the LSP, and the ERO -- <bcp14>MUST</bcp14> be set in the
PCUpd/PCInitiate message. If a mandatory object is received with the PCUpd/PCInitiate message. If a mandatory object is received with the
P flag set incorrectly according to the rules stated above, the P flag set incorrectly according to the rules stated above, the
receiving peer MUST send a PCErr message with Error-Type=10 receiving peer <bcp14>MUST</bcp14> send a PCErr message with Error-Typ
(Reception of an invalid object) and Error-value=1 (reception of an e=10
object with P flag not set). <!--By default, the PCE SHOULD set the P (Reception of an invalid object) and Error-value=1 (Reception of an
flag, unless a object with P flag not set). On a PCEP session in which both peers set
local configuration or local policy indicates that some constraints the R
(corresponding PCEP objects) can be marked as optional and could be bit, the PCE <bcp14>SHOULD</bcp14> set the P flag by default unless a
ignored by the PCC.--> On a PCEP session in which both peers set R local
bit, the PCE SHOULD set the P flag by default unless a local
configuration/policy indicates that some constraints (corresponding configuration/policy indicates that some constraints (corresponding
PCEP objects) can be marked as optional and could be ignored by the PCEP objects) can be marked as optional and can be ignored by the
PCC or the object itself conveys informational parameters that can PCC or the object itself conveys informational parameters that can
be safely ignored.</t> be safely ignored.</t>
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<section title="Handling of I flag" toc="default"> <name>Handling of the I Flag</name>
<section title="The PCUpd Message" toc="default"> <section toc="default" numbered="true">
<t>The I flag in the PCUpd message <xref target="RFC8231"/> allows a <name>The PCUpd Message</name>
<t>The I flag in the PCUpd message <xref target="RFC8231" format="defa
ult"/> allows a
PCE to indicate to a PCC whether or not an optional object was PCE to indicate to a PCC whether or not an optional object was
processed. The PCE MAY include the ignored optional object in its processed. The PCE <bcp14>MAY</bcp14> include the ignored optional obj ect in its
update request and set the I flag to indicate that the optional update request and set the I flag to indicate that the optional
object was ignored. When the I flag is cleared, the PCE indicates object was ignored. When the I flag is cleared, the PCE indicates
that the optional object was processed.</t> that the optional object was processed.</t>
<t>Note that when a PCE is unable to find the path that meets all <t>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 the P flag is set), the PCUpd message <bcp14>MAY</bcp14> optionally in
PCEP Objects that caused the path computation to fail along with the clude the
PCEP objects that caused the path computation to fail along with the
empty ERO.</t> empty ERO.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="The PCRpt Message" toc="default"> <name>The PCRpt Message</name>
<t>The I flag in the PCRpt message <xref target="RFC8231"/> allows a <t>The I flag in the PCRpt message <xref target="RFC8231" format="defa
ult"/> allows a
PCC to indicate to a PCE whether or not an optional object was PCC to indicate to a PCE whether or not an optional object was
processed in response to an LSP Update Request (PCUpd) or LSP processed in response to a PCUpd or PCInitiate message.
Initiate Request (PCInitiate). The PCC MAY include the ignored The PCC <bcp14>MAY</bcp14> include the ignored
optional object in its report and set the I flag to indicate that optional object in its report and set the I flag to indicate that
the optional object was ignored at PCC. When the I flag is cleared, the optional object was ignored at PCC. When the I flag is cleared,
the PCC indicates that the optional object was processed. The I flag the PCC indicates that the optional object was processed. The I flag
has no meaning if the PCRpt message is not in response to a PCUpd or has no meaning if the PCRpt message is not in response to a PCUpd or
PCInitiate message (i.e. without the SRP object in the PCRpt PCInitiate message (i.e., without the SRP object in the PCRpt
message).</t> message).</t>
<t>Note that when a PCC is unable to set up a path that meets all
<t>Note that when a PCC is unable to set up the path that meets all the parameters as per the PCEP object that cannot be ignored (i.e.,
the parameters as per the PCEP Object that cannot be ignored (i.e. the P flag is set), the PCRpt message <bcp14>MAY</bcp14> optionally in
the P flag is set), the PCRpt message MAY optionally include the clude the
PCEP Objects that caused the path setup to fail along with the PCEP objects that caused the path setup to fail along with the
LSP-ERROR-CODE TLV <xref target="RFC8231"/> indicating the reason LSP-ERROR-CODE TLV <xref target="RFC8231" format="default"/> indicatin
g the reason
for the failure.</t> for the failure.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="The PCInitiate Message" toc="default"> <name>The PCInitiate Message</name>
<t>The I flag has no meaning in the PCinitiate message <xref <t>The I flag has no meaning in the PCInitiate message <xref target="R
target="RFC8281"/>, so the I flag MUST set to 0 on transmission and FC8281" format="default"/>, so the I flag <bcp14>MUST</bcp14> set to 0 on transm
ission and
ignored on receipt.</t> ignored on receipt.</t>
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<name>Unknown Object Handling</name>
<section title="Unknown Object Handling" toc="default"> <t>
<t>This document updates the handling of unknown objects in the This document updates the handling of unknown objects in the stateful
stateful PCEP messages as per the setting of the P flag in the common PCEP messages by setting the P flag in the common object
object header in a similar way as <xref target="RFC5440"/>, i.e. if a header in a similar way as described in <xref target="RFC5440"/>. That is, i
PCEP speaker does not understand an object with the P flag set or f a
understands the object but decides to ignore the object, the entire PCEP speaker does not understand an object with the P flag set, or
stateful PCEP message MUST be rejected and the PCE MUST send a PCErr if the PCEP speaker understands the object
message with Error-Type="Unknown Object" or "Not supported Object" but decides to ignore the object, the entire stateful PCEP message
<xref target="RFC5440"/>. In case the P flag is not set, the PCEP <bcp14>MUST</bcp14> be rejected, and the PCE <bcp14>MUST</bcp14> send a PCErr
speaker is free to ignore the object and continue with the message message with Error-
Type="Unknown Object" or "Not supported object" <xref target="RFC5440"/>.
If the P flag is not set, the PCEP
speaker can ignore the object and continue with the message
processing as defined.</t> processing as defined.</t>
<t><xref target="RFC8231" format="default"/> defined the LSP Error Code
<t><xref target="RFC8231"/> defined LSP Error Code TLV to be carried TLV to be carried
in PCRpt message in the LSP object to convey error information. This in the PCRpt message in the LSP object to convey error information. This
document does not change that procedure.</t> document does not change that procedure.</t>
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<section title="Security Considerations" toc="default"> <name>Security Considerations</name>
<t>This document specifies how the already existing P and I flags in the <t>This document specifies how the already existing P and I flags in the
PCEP common object header could be used during stateful PCEP exchanges. PCEP common object header could be used during stateful PCEP exchanges.
It updates the unknown object error handling in stateful PCEP message It updates the unknown object error handling in stateful PCEP message
exchange. These changes on their own do not add any new security exchange. On their own, these changes do not add any new security
concerns. The security considerations identified in <xref concerns. The security considerations identified in <xref target="RFC5440"
target="RFC5440"/>, <xref target="RFC8231"/>, and <xref format="default"/>, <xref target="RFC8231" format="default"/>, and <xref target
target="RFC8281"/> continue to apply.</t> ="RFC8281" format="default"/> continue to apply.</t>
<t>As per <xref target="RFC8231" format="default"/>, it is <bcp14>RECOMMEN
<t>As per <xref target="RFC8231"/>, it is RECOMMENDED that these PCEP DED</bcp14> that these PCEP
extensions can only be activated on authenticated and encrypted sessions extensions can only be activated on authenticated and encrypted sessions
across PCEs and PCCs belonging to the same administrative authority, across PCEs and PCCs belonging to the same administrative authority,
using Transport Layer Security (TLS) <xref target="RFC8253"/> as per the using Transport Layer Security (TLS) <xref target="RFC8253" format="defaul
recommendations and best current practices in <xref t"/> as per the
target="RFC9325"/>.</t> recommendations and best current practices described in <xref target="RFC9
325" format="default"/>.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="IANA Considerations" toc="default"> <name>IANA Considerations</name>
<section title="STATEFUL-PCE-CAPABILITY TLV" toc="default"> <section toc="default" numbered="true">
<t/> <name>STATEFUL-PCE-CAPABILITY TLV</name>
<t><xref target="RFC8231" format="default"/> defined the STATEFUL-PCE-CA
<t><xref target="RFC8231"/> defined the STATEFUL-PCE-CAPABILITY TLV PABILITY TLV
and IANA created the "STATEFUL-PCE-CAPABILITY TLV Flag Field" and IANA created the "STATEFUL-PCE-CAPABILITY TLV Flag Field"
subregistry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's
Flag field. IANA is requested to allocate a new bit in the Flag field. IANA has allocated a new bit in the
subregistry, as follows:</t> registry, as follows:</t>
<t><figure align="left" alt="" height="" suppress-title="false"
title="" width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
Bit Description Reference
TBD1 RELAX bit [This-I.D.]
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="Imp" title="Implementation Status">
<t>[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]</t>
<t>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 <xref
target="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.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and <table>
working groups to assign due consideration to documents that have the <thead>
benefit of running code, which may serve as evidence of valuable <tr>
experimentation and feedback that have made the implemented protocols <th>Bit</th>
more mature. It is up to the individual working groups to use this <th>Description</th>
information as they see fit".</t> <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>17</td>
<td>RELAX</td>
<td>RFC 9753</td>
</tr>
</tbody>
</table>
<t>At the time of posting the -09 version of this document, there are no </section>
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.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Manageability Considerations" toc="default"> <name>Manageability Considerations</name>
<section title="Control of Function and Policy" toc="default"> <section toc="default" numbered="true">
<t>An implementation supporting this document SHOULD allow <name>Control of Function and Policy</name>
<t>An implementation supporting this document <bcp14>SHOULD</bcp14> allo
w
configuration of the capability to support relaxation of constraints configuration of the capability to support relaxation of constraints
in the stateful PCEP message exchange. They SHOULD also allow in the stateful PCEP message exchange. They <bcp14>SHOULD</bcp14> also a llow
configuration of related LSP constraints (or parameters) that are configuration of related LSP constraints (or parameters) that are
optional to process.</t> optional to process.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Information and Data Models" toc="default"> <name>Information and Data Models</name>
<t>An implementation supporting this document SHOULD allow the <t>An implementation supporting this document <bcp14>SHOULD</bcp14> allo
w the
operator to view the capability defined in this document. To serve operator to view the capability defined in this document. To serve
this purpose, the PCEP YANG module <xref this purpose, the PCEP YANG module <xref target="PCEP-YANG" format="defa
target="I-D.ietf-pce-pcep-yang"/> could be extended in the future.</t> ult"/> could be extended in the future.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Liveness Detection and Monitoring" toc="default"> <name>Liveness Detection and Monitoring</name>
<t>Mechanisms defined in this document do not imply any new liveness <t>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 <xref target="RFC5440"/>.</t> listed in <xref target="RFC5440" format="default"/>.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Verify Correct Operations" toc="default"> <name>Verify Correct Operations</name>
<t>Mechanisms defined in this document do not imply any new operation <t>Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in <xref verification requirements in addition to those already listed in <xref t
target="RFC5440"/>.</t> arget="RFC5440" format="default"/>.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Requirements On Other Protocols" toc="default"> <name>Requirements on Other Protocols</name>
<t>Mechanisms defined in this document do not imply any new <t>Mechanisms defined in this document do not imply any new
requirements on other protocols.</t> requirements on other protocols.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Impact On Network Operations" toc="default"> <name>Impact on Network Operations</name>
<t>Mechanisms defined in this document do not have any impact on <t>Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in <xref network operations in addition to those already listed in <xref target="
target="RFC5440"/>.</t> RFC5440" format="default"/>.</t>
</section> </section>
</section> </section>
<section title="Acknowledgments" toc="default">
<t>Thanks to Jonathan Hardwick for the discussion and suggestions around
this draft.</t>
<t>Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and
Peng Shaofu for the review comments.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.8174.xml" ?>
<?rfc include="reference.RFC.8231.xml" ?>
<?rfc include="reference.RFC.8253.xml"?>
<?rfc include="reference.RFC.8281.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.7942.xml" ?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
281.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<?rfc include="reference.RFC.8051.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
051.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
233.xml"/>
<!--><?rfc include="reference.RFC.8697.xml"?>-->
<?rfc include="reference.RFC.8233.xml"?> <!--><?rfc include="reference.RFC.8800.xml"?>-->
<!--><?rfc include="reference.RFC.8697.xml"?>--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93 25.xml"/>
<!--><?rfc include="reference.RFC.8800.xml"?>--> <!-- [I-D.ietf-pce-pcep-yang] draft-ietf-pce-pcep-yang-30
Used long way for WiP since
it was missing editor role for Dhruv Dhody. -->
<?rfc include="reference.RFC.9325.xml" ?> <reference anchor="PCEP-YANG" target="https://datatracker.ietf.org/doc/html/draf
t-ietf-pce-pcep-yang-30">
<front>
<title>A YANG Data Model for Path Computation Element Communications Proto
col (PCEP)</title>
<author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor"
>
<organization>Huawei</organization>
</author>
<author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
<organization>Juniper Networks</organization>
</author>
<author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<organization>Nvidia</organization>
</author>
<date month="January" day="26" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-30" />
</reference>
<?rfc include="reference.I-D.ietf-pce-pcep-yang"?> </references>
</references> </references>
<section toc="default" numbered="false">
<name>Acknowledgments</name>
<t>Thanks to <contact fullname="Jonathan Hardwick"/> for the discussion
and suggestions around this document.</t>
<t>Thanks to <contact fullname="Oscar Gonzalez de Dios"/>, <contact
fullname="Mike Koldychev"/>, <contact fullname="Samuel Sidor"/>, and
<contact fullname="Peng Shaofu"/> for their review comments.</t>
</section>
<section title="Contributors" toc="default"> <section toc="default" numbered="false">
<t><figure> <name>Contributors</name>
<artwork><![CDATA[
Dhruv Dhody <contact fullname="Dhruv Dhody">
Huawei <organization>Huawei</organization>
India <address>
<postal><country>India</country></postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
Email: dhruv.ietf@gmail.com
]]></artwork>
</figure></t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 108 change blocks. 
339 lines changed or deleted 342 lines changed or added

This html diff was produced by rfcdiff 1.48.