<?xml version="1.0"encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!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-vendor-13" number="9752" consensus="true" ipr="trust200902" obsoletes="" sortRefs="true" submissionType="IETF" symRefs="true" tocInclude="true" updates="7470" version="3" xml:lang="en"><!--6 xml2rfc v2v3 conversion 3.10.0 --><front> <title abbrev="VENDOR-STATEFUL">Conveying Vendor-Specific Information in the Path Computation Element(PCE)Communication Protocol (PCEP)extensionsExtensions for StatefulPCE.</title>PCE</title> <seriesInfoname="Internet-Draft" value="draft-ietf-pce-stateful-pce-vendor-13"/>name="RFC" value="9752"/> <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/><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/><email>zhenghaomian@huawei.com</email><uri/></address> </author> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"> <organization>Ciena</organization> <address> <postal> <street>385 Terry Fox Drive</street> <city>Kanata</city> <region>Ontario</region> <code>K2K 0L1</code> <country>Canada</country> </postal> <email>msiva282@gmail.com</email> </address> </author> <author fullname="Samuel Sidor" initials="S." surname="Sidor"> <organization>Cisco Systems, Inc.</organization> <address><postal> <street/> <city/> <region/> <code/> <country/> </postal><email>ssidor@cisco.com</email> </address> </author> <author fullname="Zafar Ali" initials="Z." surname="Ali"> <organization>Cisco Systems, Inc.</organization> <address><postal> <street/> <city/> <region/> <code/> <country/> </postal><email>zali@cisco.com</email> </address> </author><date/> <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>PCE</keyword> <abstract> <t>This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor-specific information in statefulPCEPath Computation Element (PCE) operations. These extensions allow vendors to incorporate proprietary data within PCEP messages, facilitating enhanced network optimization and functionality in environments requiring vendor-specific features. The extensions maintain compatibility with existing PCEP implementations and promote interoperability across diverse network deployments. RFC 7470 defines a facility to carry vendor-specific information in statelessPCE Communication Protocol (PCEP)PCEP messages. This document extends this capability for the Stateful PCEP messages.</t> <!-- [rfced] "to revise the refrence to the IANA registry" is unclear without further context. Please consider whether the suggested text clarifies the intent. Original: This document updates RFC 7470 to revise the reference to the IANA registry for managing Enterprise Numbers. Perhaps: This document updates RFC 7470 to specify that Enterprise numbers are managed through the "Private Enterprise Numbers (PENs)" registry. --> <t>This document updates RFC 7470 to revise the reference to the IANA registry for managing Enterprise Numbers.</t> </abstract> </front> <middle> <section anchor="introduction" numbered="true" toc="default"> <name>Introduction</name> <t>The Path Computation Element Communication Protocol (PCEP) <xref format="default" target="RFC5440"/> provides mechanisms for a Path Computation Element (PCE) to perform path computation in response to a Path Computation Client (PCC) request.</t> <t>A Stateful PCE is capable of considering, for the purposes ofthepath computation, not only the network state in terms of links and nodes (referred to as the Traffic Engineering Database or TED) but also the status of active services (previously computed paths, and currently reserved resources, stored in the Label Switched Paths Database (LSP-DB)). <xref format="default" target="RFC8051"/> describes general considerations for a Stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases.</t> <t><xref format="default" target="RFC8231"/> describes a set of extensions to PCEP to provide stateful control. A Stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. <xref format="default" target="RFC8281"/> describes the setup, maintenance, and teardown of PCE-initiated LSPs under the Stateful PCE model. These extensions add new messages in PCEP for Stateful PCE.</t> <t><xref format="default" target="RFC7470"/> defines the Vendor InformationObject,object, which can carry arbitrary, proprietary information, such as vendor-specific constraints, in stateless PCEP. It also defines the VENDOR-INFORMATION-TLV, which allows arbitrary information to be embedded within any existing or future PCEP object that supports TLVs.</t> <t>While originally designed for stateless PCEP, the Vendor InformationObjectobject and VENDOR-INFORMATION-TLV are also useful in the Stateful PCE model. The VENDOR-INFORMATION-TLV can already be included in any of the stateful PCEP objectsasper <xref format="default"target="RFC7470"/> already.target="RFC7470"/>. This document further extends stateful PCEP messages to support the use of the Vendor InformationObject.</t>object.</t> <section anchor="Requirements" numbered="true" toc="default"> <name>Requirements Language</name><t>The<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 <xrefformat="default"target="RFC2119"/> <xrefformat="default"target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="RBNF" numbered="true" toc="default"> <name>Use of RBNF</name> <t>The message formats in this document are illustrated using Routing Backus-Naur Form (RBNF) encoding, as specified in <xref format="default" target="RFC5511"/>. The use of RBNF is illustrative only and may omit certain important details; the normative specification of messages is found in the descriptive text. If there is any divergence between the RBNF and the descriptive text, the descriptive text is considered authoritative.</t> </section> </section> <section anchor="Procedures" numbered="true" toc="default"> <name>Procedures for the Vendor Information Object</name> <t>A Path Computation LSP State Report message (also referred to as PCRptmessage)message; see <xref format="default" section="6.1"sectionFormat="parens" target="RFC8231"/>sectionFormat="of" target="RFC8231"/>) is a PCEP message sent by a PCC to a PCE to report the current state of an LSP. A PCC that wants to convey proprietary or vendor-specific information or metrics to a PCE does so by including a Vendor Information object in the PCRpt message. The contents and format of the object, including the VENDOR-INFORMATION object and the VENDOR-INFORMATION-TLV, are described inSection 4 of<xrefformat="default"section="4" sectionFormat="of" target="RFC7470"/>. The PCE determines how to interpret the information in the Vendor Information object by examining the Enterprise Number it contains.</t> <!-- DNE: Text from [RFC7470] is correct. --> <t><xref format="default" target="RFC7470"/> stated that:</t><ul empty="true" spacing="normal" bare="false"> <li>"Enterprise<blockquote> <t>Enterprise Numbers are assigned by IANA and managed through an IANA registry <xref format="default"target="RFC2578"/>".</li> </ul>target="RFC2578"/>.</t> </blockquote> <t>This document updates <xref format="default" target="RFC7470"/> and replaces this text with:</t><ul empty="true" spacing="normal" bare="false"> <li>"Enterprise<blockquote> <t>Enterprise Numbers are assigned by IANA and managed through the "Private Enterprise Numbers (PENs)" registry as described in <xref format="default"target="RFC9371"/>." </li> </ul>target="RFC9371"/>.</t> </blockquote> <t>The Vendor Information object isOPTIONAL<bcp14>OPTIONAL</bcp14> in a PCRpt message. Multiple instances of the objectMAY<bcp14>MAY</bcp14> be contained in a single PCRpt message. Different instances of the objectMAY<bcp14>MAY</bcp14> have different Enterprise Numbers.</t> <t>The format of the PCRpt message (with <xref format="default" section="6.1" sectionFormat="of" target="RFC8231"/> as the base) is updated as follows:</t><artwork align="left" alt="" name="" type=""><![CDATA[<sourcecode type="rbnf"><![CDATA[ <PCRpt Message> ::= <Common Header> <state-report-list>Where:]]></sourcecode> <t>Where:</t> <sourcecode type="rbnf"><![CDATA[ <state-report-list> ::= <state-report>[<state-report-list>] <state-report> ::= [<SRP>] <LSP> <path> [<vendor-info-list>]Where:]]></sourcecode> <t>Where:</t> <sourcecode type="rbnf"><![CDATA[ <vendor-info-list> ::= <VENDOR-INFORMATION> [<vendor-info-list>] <path> is defined in [RFC8231].]]></artwork>]]></sourcecode> <t>A Path Computation LSP Update Request message (also referred to as PCUpdmessage)message; see <xref format="default" section="6.2"sectionFormat="parens" target="RFC8231"/>sectionFormat="of" target="RFC8231"/>) is a PCEP message sent by a PCE to a PCC to update the attributes of an LSP. The Vendor Information object can be included in a PCUpd message to convey proprietary or vendor-specific information.</t> <!-- [rfced] For clarity, may we update the text as follows? Original: The format of the PCUpd message (with Section 6.2 of [RFC8231] as the base) is updated as follows: ... The format of the PCInitiate message (with Section 5.1 of [RFC8281] as the base) is updated as follows: Perhaps: The format of the PCUpd message (using the format described in Section 6.2 of [RFC8231] as the base) is updated as follows: ... The format of the PCInitiate message (using the format described in Section 5.1 of [RFC8281] as the base) is updated as follows: --> <t>The format of the PCUpd message (with <xref format="default" section="6.2" sectionFormat="of" target="RFC8231"/> as the base) is updated as follows:</t><artwork align="left" alt="" name="" type=""><![CDATA[<sourcecode type="rbnf"><![CDATA[ <PCUpd Message> ::= <Common Header> <update-request-list>Where:]]></sourcecode> <t>Where:</t> <sourcecode type="rbnf"><![CDATA[ <update-request-list> ::= <update-request> [<update-request-list>] <update-request> ::= <SRP> <LSP> <path> [<vendor-info-list>]Where:]]></sourcecode> <t>Where:</t> <sourcecode type="rbnf"><![CDATA[ <vendor-info-list> ::= <VENDOR-INFORMATION> [<vendor-info-list>] <path> is defined in [RFC8231].]]></artwork>]]></sourcecode> <t>A Path Computation LSP Initiate Message (also referred to as PCInitiatemessage)message; see <xref format="default" section="5.1"sectionFormat="parens" target="RFC8281"/>sectionFormat="of" target="RFC8281"/>) is a PCEP message sent by a PCE to a PCC to trigger an LSP instantiation or deletion. The Vendor Information object can be included in a PCInitiate message to convey proprietary or vendor-specific information.</t> <t>The format of the PCInitiate message (with <xref format="default" section="5.1" sectionFormat="of" target="RFC8281"/> as the base) is updated as follows:</t><artwork align="left" alt="" name="" type=""><![CDATA[<sourcecode type="rbnf"><![CDATA[ <PCInitiate Message> ::= <Common Header> <PCE-initiated-lsp-list>Where:]]></sourcecode> <t>Where:</t> <sourcecode type="rbnf"><![CDATA[ <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> [<PCE-initiated-lsp-list>] <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>| <PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-instantiation> ::= <SRP> <LSP> [<END-POINTS>] <ERO> [<attribute-list>] [<vendor-info-list>]Where:]]></sourcecode> <t>Where:</t> <sourcecode type="rbnf"><![CDATA[ <vendor-info-list> ::= <VENDOR-INFORMATION> [<vendor-info-list>]<PCE-initiated-lsp-deletion>]]></sourcecode> <t> <PCE-initiated-lsp-deletion> and<attribute-list> is<attribute-list> are asper [RFC8281]. ]]></artwork>defined in <xref target="RFC8281"/>.</t> <t>A legacy implementation that does not recognize the Vendor Information object will act according to the procedures set out in <xref format="default" target="RFC8231"/> and <xref format="default" target="RFC8281"/>. An implementation that supports the Vendor Information object, but receives one carrying an Enterprise Number that it does not support,MUST<bcp14>MUST</bcp14> ignore the object in the same way as described in <xref format="default" section="2" sectionFormat="of" target="RFC7470"/>.</t> </section> <section anchor="TLV" numbered="true" toc="default"> <name>Procedures for the Vendor Information TLV</name> <t>The Vendor Information TLV can be used to carry vendor-specific information that applies to a specific PCEP object by including the TLV in the object. This includes objects used in Stateful PCE extensions such as Stateful PCE Request Parameter (SRP) and LSP objects. All of the procedures are asper section 3 ofdescribed in <xrefformat="default"section="3" sectionFormat="of" target="RFC7470"/>.</t> </section> <section numbered="true" toc="default"> <name>Manageability Considerations</name> <t>All manageability requirements and considerations listed in <xref format="default" target="RFC5440"/>, <xref format="default" target="RFC7470"/>, <xref format="default" target="RFC8231"/>, and <xref format="default" target="RFC8281"/> apply to the PCEP protocol extensions defined in this document. In addition, the requirements and considerations listed in this section apply.</t> <section numbered="true" toc="default"> <name>Control of Function and Policy</name> <t>The requirements for control of function and policy for vendor-specific information as set out in [RFC7470] continue to apply to Stateful PCEP extensions specified in this document.</t> </section> <section numbered="true" toc="default"> <name>Information and Data Models</name> <t>The PCEP YANG module is specified in <xref format="default"target="I-D.ietf-pce-pcep-yang"/>.target="PCEP-YANG"/>. Any standard YANG module will not include details of vendor-specific information. However,thea standard YANG module could be extended to report the use of the Vendor Information object or TLV and the Enterprise Numbers that the objects and TLVs contain.</t> </section> <section numbered="true" toc="default"> <name>Liveness Detection and 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 <xref format="default" target="RFC5440"/>.</t> </section> <section numbered="true" toc="default"> <name>Verifying Correct Operations</name> <t>Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in <xref format="default" target="RFC5440"/> and <xref format="default" target="RFC8231"/>.</t> </section> <section numbered="true" toc="default"> <name>Requirements On Other Protocols</name> <t>Mechanisms defined in this document do not imply any new requirements on other protocols.</t> </section> <section numbered="true" toc="default"> <name>ImpactOnon Network Operations</name> <t>Mechanisms defined in <xref format="default" target="RFC5440"/> and <xref format="default" target="RFC8231"/> also apply to PCEP extensions defined in this document.</t><t>Section 6.6 of <xref format="default"<t><xref section="6.6" sectionFormat="of" target="RFC7470"/> highlights how the presence of additional vendor-specific information in PCEP messages may congest the operations and how to detect and handle it. This also applies to stateful PCEP messages as outlined inSection 2.<xref target="Procedures"/>. Specifically, a PCEP speakerSHOULD NOT<bcp14>SHOULD NOT</bcp14> include vendor information in stateful PCEP message if it believes the recipient does not support that information.</t> <t>Encoding optimization for the Vendor InformationObject,object, for example, in caseofthe objectwithhas the same content encoded for multiple LSPs, is considered out of the scope of this document and may be proposed in the future as a separate document applicable to other PCEP objects.</t> </section> </section> <section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name><t>There are no IANA actions in this document.</t> </section> <section anchor="imps" numbered="true" toc="default"> <name>Implementation Status</name> <t>[NOTE TO RFC EDITOR : This whole section and the reference to RFC 7942 is to be removed before publication as an RFC]</t><t>Thissection 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 format="default" 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 effortdocument hasbeen 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 format="default" 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> <section numbered="true" toc="default"> <name>Cisco Systems</name> <ul spacing="normal"> <li>Organization: Cisco Systems, Inc.</li> <li>Implementation: Cisco IOS-XR PCE and PCC</li> <li>Description: Vendor Information Object used in PCRpt, PCUpd and PCInitiate messages.</li> <li>Maturity Level: Production</li> <li>Coverage: Full</li> <li>Contact: ssidor@cisco.com</li> </ul> </section>no IANA actions.</t> </section> <section anchor="Security" numbered="true" toc="default"> <name>Security Considerations</name> <t>The protocol extensions defined in this document do not change the nature of PCEP. Therefore, the security considerations set out in <xref format="default" target="RFC5440"/>, <xref format="default" target="RFC7470"/>, <xref format="default"target="RFC8231"/>target="RFC8231"/>, and <xref format="default" target="RFC8281"/> apply unchanged.</t> <!-- [rfced] The use of "as per" twice in this sentence is confusing. As it seems the second instance refers to best practices for implementing TLS, please consider the update below. Original: As per [RFC8231] it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in RFC 9325 [BCP195]. Perhaps: Per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs using Transport Layer Security (TLS) [RFC8253]. See the recommendations and best current practices for using TLS in RFC 9325 [BCP195]. --> <t>As per <xref format="default"target="RFC8231"/>target="RFC8231"/>, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs using Transport Layer Security (TLS) <xref format="default" target="RFC8253"/>, as per the recommendations and best current practices in RFC 9325 <xref derivedContent="BCP195" format="default" target="BCP195"/>.</t> <t>The use of vendor-specific information as defined in <xref format="default" target="RFC7470"/> and in this document may provide a covert channel that could be misused by PCEP speaker implementations or by malicious software at PCEP speakers. While there is limited protection against this, an operator monitoring the PCEP sessions can detect the use of vendor-specific information, be aware of the decoding mechanism for this data, and inspect it accordingly. It is crucial for the operator to remain vigilant and monitor for any potential misuse of this object. Appropriate steps need to be taken to prevent the installation of malicious software at the PCEP speaker by implementing robust integrity, authentication, and authorization techniques for installation and updating, which are out of scope of thisdraft.</t>document.</t> </section> </middle> <back> <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.8174.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.5511.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7470.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.8281.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.195.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2578.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9371.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.8253.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> <section anchor="Acknowledgments"numbered="true"numbered="false" toc="default"> <name>Acknowledgments</name> <t>Thanks toDhruv Dhody<contact fullname="Dhruv Dhody"/> for shepherding the document and for their significant contributions and suggestions.</t> <t>Thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="Avantika"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Gunter Van de Velde"/>, <contact fullname="John Scudder"/>, <contact fullname="Mahendra Singh Negi"/>, <contact fullname="Mahesh Jethanandani"/>, <contact fullname="Mike McBride"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Orie Steele"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Susan Hares"/>, <contact fullname="Swapna K"/>, <contact fullname="Udayasree Palle"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Wassim Haddad"/>, and <contact fullname="Xiao Min"/> for their reviews, comments and suggestions.</t> </section> <sectionnumbered="true"numbered="false" toc="default"> <name>Contributors</name><artwork align="left" alt="" name="" type=""><![CDATA[ Dhruv Dhody Huawei India EMail: dhruv.ietf@gmail.com Mike Koldychev Ciena EMail: mkoldych@proton.me ]]></artwork><contact fullname="Dhruv Dhody"> <organization>Huawei</organization> <address> <postal> <country>India</country> </postal> <email>dhruv.ietf@gmail.com</email> </address> </contact> <contact fullname="Mike Koldychev"> <organization>Ciena</organization> <address> <email>mkoldych@proton.me</email> </address> </contact> </section></middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7470.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2578.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9371.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-pcep-yang.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> </references> </references></back> <!-- [rfced] We updated artwork to sourcecode in Section 2, with type set to "rbnf". Please review and let us know if any updates are needed. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> <!-- [rfced] Throughout the text, the following terminology appears to be used inconsistently. - Vendor Information Object vs Vendor Information object (per RFC 7470) We have updated this as "Vendor Information object". Please let us know any objections. - Please review the capitalization of stateful in the following and let us know if/how they should be made consistent. stateful PCE operations Stateful PCE Stateful PCE deployment Stateful PCE model Stateful PCE extensions Stateful PCEP extensions Stateful PCEP messages stateful PCEP message stateful PCEP objects --> <!-- [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. --> </rfc>