<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "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" ?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-pce-stateful-pce-optional-13" number="9753" consensus="true" ipr="trust200902" obsoletes="" submissionType="IETF" updates="8231"xml:lang="en">xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="STATEFUL-OPT">Extension for Stateful PCE toallowAllow Optional Processing ofPCEPath Computation Element Communication Protocol (PCEP) Objects</title> <seriesInfo name="RFC" value="9753"/> <author fullname="Cheng Li" initials="C." surname="Li"> <organization>Huawei Technologies</organization> <address> <postal> <street>Huawei Campus, No. 156 Beiqing Rd.</street> <city>Beijing</city><region/><code>100095</code> <country>China</country> </postal><phone/> <facsimile/><email>c.l@huawei.com</email><uri/></address> </author> <author fullname="Haomian Zheng" initials="H." surname="Zheng"> <organization>Huawei Technologies</organization> <address> <postal> <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street> <city>Dongguan</city> <region>Guangdong</region> <code>523808</code> <country>China</country> </postal><phone/> <facsimile/><email>zhenghaomian@huawei.com</email><uri/></address> </author> <author fullname="Stephane Litkowski" initials="S" surname="Litkowski"> <organization>Cisco</organization> <address><postal> <street/> <city/> <region/> <code/> <country/> </postal><email>slitkows.ietf@gmail.com</email> </address> </author><date/> <area>Routing</area> <workgroup>PCE Working Group</workgroup><date month="March" year="2025"/> <area>RTG</area> <workgroup>pce</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>This document introduces a mechanism to mark some of the Path Computation Element(PCE)Communication Protocol (PCEP) objects as optional during PCEPmessages exchange formessage exchange, so theStateful PCEstateful Path Computation Element (PCE) modelto allow relaxingcan relax some constraints during path computation and setup. This document introduces this relaxation to statefulPCEPCE, and it updates RFC 8231.</t> </abstract> </front> <middle> <sectiontitle="Introduction" toc="default">toc="default" numbered="true"> <name>Introduction</name> <t><xreftarget="RFC5440"/>target="RFC5440" format="default"/> describes the Path Computation Element Communication Protocol(PCEP)(PCEP), which enables communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between two PCEs based on the PCE architecture <xreftarget="RFC4655"/>.</t>target="RFC4655" format="default"/>.</t> <t>PCEPExtensionsextensions forStatefulthe stateful PCEModelmodel <xreftarget="RFC8231"/>target="RFC8231" format="default"/> describes a set of extensions to PCEP to enable active control of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) tunnels. <xreftarget="RFC8281"/>target="RFC8281" format="default"/> describes the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for dynamic control.</t> <t><xreftarget="RFC5440"/>target="RFC5440" format="default"/> defined the P flag (Processing-Rule) in the 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 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) message to indicate to a PCC whether or not an optional object was considered by the PCE during path computation. Stateful PCE <xreftarget="RFC8231"/> specifiedtarget="RFC8231" format="default"/> specifies that the P and I flags of the PCEP objectsdefined in <xref target="RFC8231"/> isare to be set to zero on transmission and ignored on receipt, since they are exclusively related to the path computation requests. This document defines a new flag, the R (RELAX) flag in STATEFUL-PCE-CAPABILITYTLVTLV, in the PCEP common object header to 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 to identify optional objects in the Path Computation State Report (PCRpt) <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, the Path Computation Update Request (PCUpd) <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, and the LSP Initiate Request (PCInitiate) <xreftarget="RFC8281"/> message.</t>target="RFC8281" format="default"/> messages.</t> <t>This document updates <xreftarget="RFC8231"/>target="RFC8231" format="default"/> concerning usage of the P and I flags as well as the handling of unknown objects inthestateful PCEP message exchange.</t> <sectiontitle="Requirements Language" toc="default"> <t>Thetoc="default" numbered="true"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section toc="default" numbered="true"> <name>Overview</name> <!--<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document[rfced] We are having trouble parsing this sentence. Please consider whether the suggested text conveys the intended meaning. Original: [RFC5440] describes the handling of unknown objects as per the setting of the P flag for the PCReq message. Perhaps: Setting the P flag in the PCReq message tobe interpretedhandle unknown objects is as described in<xref target="RFC2119"/>.</t>--> </section> </section> <section title="Overview" toc="default">Section 7.2 of [RFC5440]. --> <t><xreftarget="RFC5440"/>target="RFC5440" format="default"/> describes the handling of unknown objects as per the setting of the P flag for the PCReq message. Further, <xreftarget="RFC8231"/>target="RFC8231" format="default"/> defined the usage of the LSP Error Code TLV in the PCRpt message in response to a failed LSP Update Request via the PCUpd message (for example, due to an unsupportedobject/TLV).</t>object or TLV).</t> <t>This document specifies the procedure of marking some objects as 'optional to be processed' by the PCEP peer in the stateful PCEP messages. Furthermore, this document updates the procedure for handling unknown objects inthestateful PCEP messages based on the P flag.</t> <sectiontitle="Usage Example" toc="default">toc="default" numbered="true"> <name>Usage Example</name> <t>The PCRpt message is used to report the current state of an LSP. As part of themessagemessage, both the <intended-attribute-list> and <actual-attribute-list> are encoded (see <xreftarget="RFC8231"/>).target="RFC8231" format="default"/>). For example, the <intended-attribute-list> could include the METRIC object to indicate a limiting constraint (Bound 'B' flag set) for the Path Delay Variation metric <xreftarget="RFC8233"/>.target="RFC8233" format="default"/>. <!-- [rfced] Does marking something as optional allow the PCEP peer to ignore the object? If yes, may we update the text as follows? Original: In these cases, it would be useful to mark the objects as 'optional' and they could be ignored by the PCEP peer. Perhaps: In these cases, it would be useful to mark the objects as 'optional' so they could be ignored by the PCEP peer. --> In some scenarios, it would be useful tostateindicate that thislimitingconstraint can be relaxed by the PCE in case it cannot find a path. <!--Similarly in the case of an association group <xref target="RFC8697"/> such as Disjoint Association <xref target="RFC8800"/>, the PCE may need to completely relax the disjointness constraint in order to provide a path to all the LSPs that are part of the association.--> In these cases, it would be useful to mark the 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 peer has relaxed the constraint and ignored the processing of the PCEP object.</t> <t>Thus, this document specifies how the already existing P and I flags in the PCEP common object header could be used during the stateful PCEP message exchange. <!-- [rfced] We are having trouble parsing this text. It refers to the P and I flags, but then switches to "the flag". Does "the flag" refer to the R flag, which has not yet been introduced? Please review and let us know how the text may be clarified. Original (prior sentence included for context): Thus, this document specifies how the already existing P and I flags in the PCEP common object header could be used during the stateful PCEP message exchange. Further, it should be noted that similar to handling of P and I flags in<xref target="RFC5440"/>,[RFC5440], the flag applies to full PCEP Object and could not be applied to the granularity of an optional TLVs encoded in the PCEPObject.</t>Object. Perhaps: Further, it should be noted that, similar to handling of P and I flags in [RFC5440], the flag indicating that the constraint has been relaxed applies to the full PCEP object and cannot be applied at the granularity of an optional TLV encoded in the PCEP object. --> It should be noted that similar to handling of P and I flags in <xref target="RFC5440" format="default"/>, the flag applies to full PCEP object and could not be applied to the granularity of an optional TLVs encoded in the PCEP object.</t> </section> </section> <sectiontitle="PCEP Extension" toc="default"> <section title="STATEFUL-PCE-CAPABILITY TLV" toc="default">toc="default" numbered="true"> <name>PCEP Extension</name> <section toc="default" numbered="true"> <name>STATEFUL-PCE-CAPABILITY TLV</name> <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 initialization phase, as follows. During the PCEP initialization phase, a PCC sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in <xreftarget="RFC8231"/>.target="RFC8231" format="default"/>. A new flag, the R (RELAX) flag, is added to this TLV to indicatethesupport for relaxing the processing of some objects via the use of the P and I flags in the PCEP common object header.</t> <t>R (RELAX bit -TBD1):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 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 PCEP Speakerwouldwill not handle the P and I flags in the PCEP common object header for stateful PCE messages.</t> <t>The R flagMUST<bcp14>MUST</bcp14> be set by both the PCC and PCE to indicate support forthehandlingofthe P and I flags in the PCEP common object header to allow relaxing some constraints by marking objects as 'optional to process'. If the PCEP speakerdiddoes not set the R flag but receives PCEP objects with the P or Ibitbits set, itMUST<bcp14>MUST</bcp14> ignore the flags. <xreftarget="RFC8231"/> statedtarget="RFC8231" format="default"/> states that P and I flags of the PCEP objectsdefined in <xref target="RFC8231"/>are set to 0 on transmission and ignored on receipt. Itfailedfails to mention the behaviour of objects defined outside of <xreftarget="RFC8231"/>target="RFC8231" format="default"/>, leading to ambiguity.</t> </section> <sectiontitle="Handlingtoc="default" numbered="true"> <name>Handling of the Pflag" toc="default">Flag</name> <sectiontitle="Thetoc="default" numbered="true"> <name>The PCRptMessage" toc="default">Message</name> <t>The P flag in the PCRpt message <xreftarget="RFC8231"/>target="RFC8231" format="default"/> allows a PCC to specify to a PCE whether the object must be taken into account by the PCE (during state maintenance, path computation, or 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 is set by both peers, the objectMUST<bcp14>MUST</bcp14> be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCEis free tocan ignore it. The P flag for the mandatory objects, such as the LSP and the ERO (Explicit Route Object) object (intended path),MUST<bcp14>MUST</bcp14> be set in the PCRpt message. If a mandatory object is received with the P flag set incorrectly according to the rules stated above, the receiving peerMUST<bcp14>MUST</bcp14> send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1(reception(Reception of an object with P flag not set). On a PCEP session on which the R bit was set by both peers, the PCCSHOULD<bcp14>SHOULD</bcp14> set the P flag by default, unless a local configuration or local policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and could be ignored by the PCE or the object itself conveys informational parameters that can be safely ignored.</t> <sectiontitle="Delegation" toc="default">toc="default" numbered="true"> <name>Delegation</name> <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 described in <xreftarget="RFC8051"/>.target="RFC8051" format="default"/>. Note that for the delegated LSPs, the PCE can update and mark some objects as ignored even when the PCChadhas set the P flag during the delegation. Similarly, the PCE can update and mark some objects as a 'must to process' even when the PCChadhas not set the P flag during delegation.</t> <t>The PCCMUST<bcp14>MUST</bcp14> acknowledge this by sending the PCRpt message with the P flag set as per the PCE expectation for the corresponding object. If the PCC cannot accept the update message, itMUST<bcp14>MUST</bcp14> react as per the processing rules of unacceptable update insection 5.8.3 of<xreftarget="RFC8231"/>.</t>section="5.8.3" target="RFC8231" format="default"/>.</t> </section> </section> <sectiontitle="Thetoc="default" numbered="true"> <name>The PCUpd Message and the PCInitiateMessage" toc="default">Message</name> <t>The P flag in the PCUpd message <xreftarget="RFC8231"/>target="RFC8231" format="default"/> and the PCInitiate message <xreftarget="RFC8281"/>target="RFC8281" format="default"/> 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 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, the objectMUST<bcp14>MUST</bcp14> be taken into account by the PCC. Conversely, when the P flag is cleared, the object is optional and the PCCis free tocan ignore it. The P flag for the mandatoryobjects,objects -- such as the SRP (Stateful PCE Request Parameters), theLSPLSP, and theERO, MUSTERO -- <bcp14>MUST</bcp14> be set in the PCUpd/PCInitiate message. If a mandatory object is received with the P flag set incorrectly according to the rules stated above, the receiving peerMUST<bcp14>MUST</bcp14> send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1(reception(Reception of an object with P flag not set). <!--By default, the PCE SHOULD set the P flag, unless a local configuration or local policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and could be ignored by the PCC.--> On a PCEP session in which both peers set the R bit, the PCESHOULD<bcp14>SHOULD</bcp14> set the P flag by default unless a local configuration/policy indicates that some constraints (corresponding PCEP objects) can be marked as optional andcouldcan be ignored by the PCC or the object itself conveys informational parameters that can be safely ignored.</t> </section> </section> <sectiontitle="Handlingtoc="default" numbered="true"> <name>Handling of the Iflag" toc="default">Flag</name> <sectiontitle="Thetoc="default" numbered="true"> <name>The PCUpdMessage" toc="default">Message</name> <t>The I flag in the PCUpd message <xreftarget="RFC8231"/>target="RFC8231" format="default"/> allows a PCE to indicate to a PCC whether or not an optional object was processed. The PCEMAY<bcp14>MAY</bcp14> 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 flag is cleared, the PCE indicates that the optional object was processed.</t> <t>Note that when a PCE is unable to find the path that meets all the constraints as per the PCEPObjectobject that cannot be ignored (i.e. the P flag is set), the PCUpd messageMAY<bcp14>MAY</bcp14> optionally include the PCEPObjectsobjects that caused the path computation to fail along with the empty ERO.</t> </section> <sectiontitle="Thetoc="default" numbered="true"> <name>The PCRptMessage" toc="default">Message</name> <!-- [rfced] PCUpd seems to be exapnded slightly differently in two places. Based on what we see in RFC 8231 (see below), we don't believe the terms are interchangeable. Please review and let us know how/if these should be made consistent? Perhaps Section 3.3.2 can just refer to PCUpd and PCInitiate since those terms are introduced earlier in the document? Section 1: Path Computation Update Request (PCUpd) This document defines a new flag, the R (RELAX) 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 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 (PCRpt) [RFC8231], the Path Computation Update Request (PCUpd) [RFC8231], and the LSP Initiate Request (PCInitiate) [RFC8281] message. Section 3.3.2: LSP Update Request (PCUpd) 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 an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate). From RFC 8231: Path Computation Update Request (PCUpd) Section 6.2 of RFC 8231: A PCUpd message can carry more than one LSP Update Request. --> <t>The I flag in the PCRpt message <xreftarget="RFC8231"/>target="RFC8231" format="default"/> allows a PCC to indicate to a PCE whether or not an optional object was processed in response to an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate). The PCCMAY<bcp14>MAY</bcp14> include the ignored 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 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 PCInitiate message(i.e.(i.e., without the SRP object in the PCRpt message).</t> <t>Note that when a PCC is unable to set upthea path that meets all the parameters as per the PCEPObjectobject that cannot be ignored(i.e.(i.e., the P flag is set), the PCRpt messageMAY<bcp14>MAY</bcp14> optionally include the PCEPObjectsobjects that caused the path setup to fail along with the LSP-ERROR-CODE TLV <xreftarget="RFC8231"/>target="RFC8231" format="default"/> indicating the reason for the failure.</t> </section> <sectiontitle="Thetoc="default" numbered="true"> <name>The PCInitiateMessage" toc="default">Message</name> <t>The I flag has no meaning in the PCinitiate message <xreftarget="RFC8281"/>,target="RFC8281" format="default"/>, so the I flagMUST<bcp14>MUST</bcp14> set to 0 on transmission and ignored on receipt.</t> </section> </section> <sectiontitle="Unknowntoc="default" numbered="true"> <name>Unknown ObjectHandling" toc="default"> <t>ThisHandling</name> <!-- [rfced] We are having trouble parsing this sentence. Please consider whether the suggested text is more clear. Otherwise, please clarify. Original: 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 header in a similar way as<xref target="RFC5440"/>,[RFC5440], i.e. if a PCEP speaker does not understand an object with the P flag set or understands the object but decides to ignore the object, the entire stateful PCEP message MUST be rejected and the PCE MUST send a PCErr message withError-Type="UnknownError- Type="Unknown Object" or "Not supported Object" [RFC5440]. Perahps: This document updates the handling of unknown objects in the stateful PCEP messages by setting the P flag in the common object header in a similar way as described in [RFC5440]. That is, if a PCEP speaker does not understand an object with the P flag set, or if the PCEP speaker understands the object but decides to ignore the object, the entire stateful PCEP message MUST be rejected, and the PCE MUST send a PCErr message with Error- Type="Unknown Object" or "Not supported object" [RFC5440]. --> <t>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 header in a similar way as <xreftarget="RFC5440"/>. In casetarget="RFC5440" format="default"/>, i.e. if a PCEP speaker does not understand an object with the P flag set or understands the object but decides to ignore the object, the entire stateful PCEP message <bcp14>MUST</bcp14> be rejected and the PCE <bcp14>MUST</bcp14> send a PCErr message with Error-Type="Unknown Object" or "Not supported object" <xref target="RFC5440" format="default"/>. If the P flag is not set, the PCEP speakeris free tocan ignore the object and continue with the message processing as defined.</t> <t><xreftarget="RFC8231"/>target="RFC8231" format="default"/> defined the LSP Error Code TLV to be carried in the PCRpt message in the LSP object to convey error information. This document does not change that procedure.</t> </section> </section> <sectiontitle="Security Considerations" toc="default">toc="default" numbered="true"> <name>Security Considerations</name> <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. It updates the unknown object error handling in stateful PCEP message exchange.These changes onOn theirownown, these changes do not add any new security concerns. The security considerations identified in <xreftarget="RFC5440"/>,target="RFC5440" format="default"/>, <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, and <xreftarget="RFC8281"/>target="RFC8281" format="default"/> continue to apply.</t> <t>As per <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that these PCEP extensions can only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) <xreftarget="RFC8253"/>target="RFC8253" format="default"/> as per the recommendations and best current practices described in <xreftarget="RFC9325"/>.</t>target="RFC9325" format="default"/>.</t> </section> <sectiontitle="IANA Considerations" toc="default"> <section title="STATEFUL-PCE-CAPABILITY TLV" toc="default"> <t/>toc="default" numbered="true"> <name>IANA Considerations</name> <section toc="default" numbered="true"> <name>STATEFUL-PCE-CAPABILITY TLV</name> <t><xreftarget="RFC8231"/>target="RFC8231" format="default"/> defined the STATEFUL-PCE-CAPABILITY TLV and IANA created the "STATEFUL-PCE-CAPABILITY TLV Flag Field"subregistryregistry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANAis requested to allocatehas allocated a new bit in thesubregistry,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><table> <thead> <tr> <th>Bit</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>17</td> <td>RELAX</td> <td>RFC 9753</td> </tr> </tbody> </table> </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 working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".</t> <t>At the time of posting the -09 version of this document, there are no 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> <sectiontitle="Manageability Considerations" toc="default"> <section title="Controltoc="default" numbered="true"> <name>Manageability Considerations</name> <section toc="default" numbered="true"> <name>Control of Function andPolicy" toc="default">Policy</name> <t>An implementation supporting this documentSHOULD<bcp14>SHOULD</bcp14> allow configuration of the capability to support relaxation of constraints in the stateful PCEP message exchange. TheySHOULD<bcp14>SHOULD</bcp14> also allow configuration of related LSP constraints (or parameters) that are optional to process.</t> </section> <sectiontitle="Informationtoc="default" numbered="true"> <name>Information and DataModels" toc="default">Models</name> <t>An implementation supporting this documentSHOULD<bcp14>SHOULD</bcp14> allow the operator to view the capability defined in this document. To serve this purpose, the PCEP YANG module <xreftarget="I-D.ietf-pce-pcep-yang"/>target="PCEP-YANG" format="default"/> could be extended in the future.</t> </section> <sectiontitle="Livenesstoc="default" numbered="true"> <name>Liveness Detection andMonitoring" toc="default">Monitoring</name> <t>Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in <xreftarget="RFC5440"/>.</t>target="RFC5440" format="default"/>.</t> </section> <sectiontitle="Verifytoc="default" numbered="true"> <name>Verify CorrectOperations" toc="default">Operations</name> <t>Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in <xreftarget="RFC5440"/>.</t>target="RFC5440" format="default"/>.</t> </section> <sectiontitle="Requirements Ontoc="default" numbered="true"> <name>Requirements on OtherProtocols" toc="default">Protocols</name> <t>Mechanisms defined in this document do not imply any new requirements on other protocols.</t> </section> <sectiontitle="Impact Ontoc="default" numbered="true"> <name>Impact on NetworkOperations" toc="default">Operations</name> <t>Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in <xreftarget="RFC5440"/>.</t>target="RFC5440" format="default"/>.</t> </section> </section> <sectiontitle="Acknowledgments" toc="default">toc="default" numbered="true"> <name>Acknowledgments</name> <t>Thanks toJonathan Hardwick<contact fullname="Jonathan Hardwick"/> for the discussion and suggestions around thisdraft.</t>document.</t> <t>Thanks toOscar<contact fullname="Oscar Gonzalez deDios, Mike Koldychev, Samuel Sidor, and Peng ShaofuDios"/>, <contact fullname="Mike Koldychev"/>, <contact fullname="Samuel Sidor"/>, and <contact fullname="Peng Shaofu"/> forthetheir review comments.</t> </section> </middle> <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> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/> </references><references title="Informative References"> <?rfc include="reference.RFC.4655.xml" ?> <?rfc include="reference.RFC.7942.xml" ?> <?rfc include="reference.RFC.8051.xml"?> <?rfc include="reference.RFC.8233.xml"?><references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8233.xml"/> <!--><?rfc include="reference.RFC.8697.xml"?>--> <!--><?rfc include="reference.RFC.8800.xml"?>--><?rfc include="reference.RFC.9325.xml" ?> <?rfc include="reference.I-D.ietf-pce-pcep-yang"?><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/> <!-- [I-D.ietf-pce-pcep-yang] draft-ietf-pce-pcep-yang-30 IESG State: RFC Ed Queue as of 02/10/25. Used long way for WiP since it was missing editor role for Dhruv Dhody. --> <reference anchor="PCEP-YANG" target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-30"> <front> <title>A YANG Data Model for Path Computation Element Communications Protocol (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> </references> </references> <sectiontitle="Contributors" toc="default"> <t><figure> <artwork><![CDATA[ Dhruv Dhody Huawei India Email: dhruv.ietf@gmail.com ]]></artwork> </figure></t>toc="default" numbered="false"> <name>Contributors</name> <contact fullname="Dhruv Dhody"> <organization>Huawei</organization> <address> <postal><country>India</country></postal> <email>dhruv.ietf@gmail.com</email> </address> </contact> </section> <!-- [rfced] Note that we have lowercased "object" when it appears as "PCEP object" to align with use in the referenced RFCs (e.g., 9753, 5440). Please let us know if any updates are needed. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>