rfc9752.original.xml   rfc9752.xml 
<?xml version="1.0" encoding='utf-8'?> <?xml version="1.0" encoding='UTF-8'?>
<rfc category="std" docName="draft-ietf-pce-stateful-pce-vendor-13"
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> <!DOCTYPE rfc [
<title abbrev="VENDOR-STATEFUL">Conveying Vendor-Specific Information in <!ENTITY nbsp "&#160;">
the Path Computation Element (PCE) Communication Protocol (PCEP) <!ENTITY zwsp "&#8203;">
extensions for Stateful PCE.</title> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<seriesInfo name="Internet-Draft" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
value="draft-ietf-pce-stateful-pce-vendor-13"/> tf-pce-stateful-pce-vendor-13" number="9752" consensus="true" ipr="trust200902"
obsoletes="" sortRefs="true" submissionType="IETF" symRefs="true" tocInclude="tr
ue" updates="7470" version="3" xml:lang="en">
<front>
<title abbrev="Vendor-Specific Info for Stateful PCE">Conveying Vendor-Speci
fic Information in
the Path Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE</title>
<seriesInfo name="RFC" value="9752"/>
<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/>
<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/>
<email>zhenghaomian@huawei.com</email> <email>zhenghaomian@huawei.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Ciena</organization> <organization>Ciena</organization>
<address> <address>
<postal> <postal>
<street>385 Terry Fox Drive</street> <street>385 Terry Fox Drive</street>
<city>Kanata</city> <city>Kanata</city>
<region>Ontario</region> <region>Ontario</region>
<code>K2K 0L1</code> <code>K2K 0L1</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>msiva282@gmail.com</email> <email>msiva282@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Samuel Sidor" initials="S." surname="Sidor"> <author fullname="Samuel Sidor" initials="S." surname="Sidor">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>ssidor@cisco.com</email> <email>ssidor@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Zafar Ali" initials="Z." surname="Ali"> <author fullname="Zafar Ali" initials="Z." surname="Ali">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>zali@cisco.com</email> <email>zali@cisco.com</email>
</address> </address>
</author> </author>
<date/> <date month="April" year="2025"/>
<workgroup>PCE Working Group</workgroup> <area>RTG</area>
<workgroup>pce</workgroup>
<keyword>PCE</keyword>
<keyword>Vendor specific</keyword>
<keyword>vendor-specific</keyword>
<abstract> <abstract>
<t>This document specifies extensions to the Path Computation Element <t>This document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) that enable the inclusion of Communication Protocol (PCEP) that enable the inclusion of
vendor-specific information in stateful PCE operations. These extensions vendor-specific information in stateful Path Computation Element (PCE) ope rations. These extensions
allow vendors to incorporate proprietary data within PCEP messages, allow vendors to incorporate proprietary data within PCEP messages,
facilitating enhanced network optimization and functionality in facilitating enhanced network optimization and functionality in
environments requiring vendor-specific features. The extensions maintain environments requiring vendor-specific features. The extensions maintain
compatibility with existing PCEP implementations and promote compatibility with existing PCEP implementations and promote
interoperability across diverse network deployments. RFC 7470 defines a interoperability across diverse network deployments. RFC 7470 defines a
facility to carry vendor-specific information in stateless PCE facility to carry vendor-specific information in stateless PCEP messages.
Communication Protocol (PCEP) messages. This document extends this This document extends this
capability for the Stateful PCEP messages.</t> capability for the stateful PCEP messages.</t>
<t>
<t>This document updates RFC 7470 to revise the reference to the This document updates RFC 7470 to specify that Enterprise Numbers
IANA registry for managing Enterprise Numbers.</t> are managed through the "Private Enterprise Numbers (PENs)" registry.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The Path Computation Element Communication Protocol (PCEP) <xref <t>The Path Computation Element Communication Protocol (PCEP) <xref
format="default" target="RFC5440"/> provides mechanisms for a Path format="default" target="RFC5440"/> provides mechanisms for a Path
Computation Element (PCE) to perform path computation in response to a Computation Element (PCE) to perform path computation in response to a
Path Computation Client (PCC) request.</t> Path Computation Client (PCC) request.</t>
<t>A Stateful PCE is capable of considering, for the purposes of the <t>A stateful PCE is capable of considering, for the purposes of
path computation, not only the network state in terms of links and nodes path computation, not only the network state in terms of links and nodes
(referred to as the Traffic Engineering Database or TED) but also the (referred to as the Traffic Engineering Database or TED) but also the
status of active services (previously computed paths, and currently status of active services (previously computed paths, and currently
reserved resources, stored in the Label Switched Paths Database reserved resources, stored in the Label Switched Paths Database
(LSP-DB)). <xref format="default" target="RFC8051"/> describes general (LSP-DB)). <xref format="default" target="RFC8051"/> describes general
considerations for a Stateful PCE deployment and examines its considerations for a stateful PCE deployment and examines its
applicability and benefits, as well as its challenges and limitations applicability and benefits, as well as its challenges and limitations
through a number of use cases.</t> through a number of use cases.</t>
<t><xref format="default" target="RFC8231"/> describes a set of <t><xref format="default" target="RFC8231"/> describes a set of
extensions to PCEP to provide stateful control. A Stateful PCE has extensions to PCEP to provide stateful control. A stateful PCE has
access to not only the information carried by the network's Interior access to not only the information carried by the network's Interior
Gateway Protocol (IGP), but also the set of active paths and their Gateway Protocol (IGP), but also the set of active paths and their
reserved resources for its computations. The additional state allows the reserved resources for its computations. The additional state allows the
PCE to compute constrained paths while considering individual LSPs and PCE to compute constrained paths while considering individual LSPs and
their interactions. <xref format="default" target="RFC8281"/> describes their interactions. <xref format="default" target="RFC8281"/> describes
the setup, maintenance, and teardown of PCE-initiated LSPs under the the setup, maintenance, and teardown of PCE-initiated LSPs under the
Stateful PCE model. These extensions add new messages in PCEP for stateful PCE model. These extensions add new messages in PCEP for
Stateful PCE.</t> stateful PCE.</t>
<t><xref format="default" target="RFC7470"/> defines the Vendor Informatio n <t><xref format="default" target="RFC7470"/> defines the Vendor Informatio n
Object, which can carry arbitrary, proprietary information, such as object, which can carry arbitrary, proprietary information, such as
vendor-specific constraints, in stateless PCEP. It also defines the vendor-specific constraints, in stateless PCEP. It also defines the
VENDOR-INFORMATION-TLV, which allows arbitrary information to be embedded VENDOR-INFORMATION-TLV, which allows arbitrary information to be embedded
within any existing or future PCEP object that supports TLVs.</t> within any existing or future PCEP object that supports TLVs.</t>
<t>While originally designed for stateless PCEP, the Vendor Information <t>While originally designed for stateless PCEP, the Vendor Information
Object and VENDOR-INFORMATION-TLV are also useful in the Stateful PCE mode object and VENDOR-INFORMATION-TLV are also useful in the stateful PCE mode
l. l.
The VENDOR-INFORMATION-TLV can be included in any of the stateful PCEP The VENDOR-INFORMATION-TLV can already be included in any of the stateful
objects as per <xref format="default" target="RFC7470"/> already. This PCEP
objects per <xref format="default" target="RFC7470"/>. This
document further extends stateful PCEP messages to support the use of the document further extends stateful PCEP messages to support the use of the
Vendor Information Object.</t> Vendor Information object.</t>
<section anchor="Requirements" numbered="true" toc="default"> <section anchor="Requirements" numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
14 <xref format="default" target="RFC2119"/> <xref format="default" ",
target="RFC8174"/> when, and only when, they appear in all capitals, "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
as shown here.</t> "<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> </section>
<section anchor="RBNF" numbered="true" toc="default"> <section anchor="RBNF" numbered="true" toc="default">
<name>Use of RBNF</name> <name>Use of RBNF</name>
<t>The message formats in this document are illustrated using Routing <t>The message formats in this document are illustrated using Routing
Backus-Naur Form (RBNF) encoding, as specified in <xref Backus-Naur Form (RBNF) encoding, as specified in <xref
format="default" target="RFC5511"/>. The use of RBNF is illustrative format="default" target="RFC5511"/>. The use of RBNF is illustrative
only and may omit certain important details; the normative only and may omit certain important details; the normative
specification of messages is found in the descriptive text. If there specification of messages is found in the descriptive text. If there
is any divergence between the RBNF and the descriptive text, the is any divergence between the RBNF and the descriptive text, the
descriptive text is considered authoritative.</t> descriptive text is considered authoritative.</t>
</section> </section>
</section> </section>
<section anchor="Procedures" numbered="true" toc="default"> <section anchor="Procedures" numbered="true" toc="default">
<name>Procedures for the Vendor Information Object</name> <name>Procedures for the Vendor Information Object</name>
<t>A Path Computation LSP State Report message (also referred to as <t>A Path Computation LSP State Report message (also referred to as
PCRpt message) <xref format="default" section="6.1" PCRpt message; see <xref format="default" section="6.1"
sectionFormat="parens" target="RFC8231"/> is a PCEP message sent by a 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 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 convey proprietary or vendor-specific information or metrics to a PCE
does so by including a Vendor Information object in the PCRpt message. does so by including a Vendor Information object in the PCRpt message.
The contents and format of the object, including the VENDOR-INFORMATION The contents and format of the object, including the VENDOR-INFORMATION
object and the VENDOR-INFORMATION-TLV, are described in Section 4 of object and the VENDOR-INFORMATION-TLV, are described in
<xref format="default" target="RFC7470"/>. The PCE determines how to <xref section="4" sectionFormat="of" target="RFC7470"/>. The PCE determine
s how to
interpret the information in the Vendor Information object by examining interpret the information in the Vendor Information object by examining
the Enterprise Number it contains.</t> the Enterprise Number it contains.</t>
<!-- DNE: Text from [RFC7470] is correct. -->
<t><xref format="default" target="RFC7470"/> stated that:</t> <t><xref format="default" target="RFC7470"/> stated that:</t>
<ul empty="true" spacing="normal" bare="false"> <blockquote>
<li>"Enterprise Numbers are assigned by IANA and managed through an IANA <t>Enterprise Numbers are assigned by IANA and managed through an IANA
registry <xref format="default" target="RFC2578"/>".</li> registry <xref format="default" target="RFC2578"/>.</t>
</ul> </blockquote>
<t>This document updates <xref format="default" target="RFC7470"/> and rep laces this text with:</t> <t>This document updates <xref format="default" target="RFC7470"/> and rep laces this text with:</t>
<ul empty="true" spacing="normal" bare="false"> <blockquote>
<li>"Enterprise Numbers are assigned by IANA and managed <t>Enterprise Numbers are assigned by IANA and managed
through the "Private Enterprise Numbers (PENs)" registry as through the "Private Enterprise Numbers (PENs)" registry as
described in <xref format="default" target="RFC9371"/>." described in <xref format="default" target="RFC9371"/>.</t>
</li> </blockquote>
</ul>
<t>The Vendor Information object is OPTIONAL in a PCRpt message. <t>The Vendor Information object is <bcp14>OPTIONAL</bcp14> in a PCRpt mes
Multiple instances of the object MAY be contained in a single PCRpt sage.
message. Different instances of the object MAY have different Enterprise Multiple instances of the object <bcp14>MAY</bcp14> be contained in a sing
le PCRpt
message. Different instances of the object <bcp14>MAY</bcp14> have differe
nt Enterprise
Numbers.</t> Numbers.</t>
<t>The format of the PCRpt message (with <xref format="default" <t>The format of the PCRpt message (with <xref format="default"
section="6.1" sectionFormat="of" target="RFC8231"/> as the base) is section="6.1" sectionFormat="of" target="RFC8231"/> as the base) is
updated as follows:</t> updated as follows:</t>
<artwork align="left" alt="" name="" type=""><![CDATA[ <sourcecode type="rbnf"><![CDATA[
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
<path> <path>
[<vendor-info-list>] [<vendor-info-list>]
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<vendor-info-list> ::= <VENDOR-INFORMATION> <vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>] [<vendor-info-list>]
<path> is defined in [RFC8231]. <path> is defined in [RFC8231].
]]></artwork> ]]></sourcecode>
<t>A Path Computation LSP Update Request message (also referred to as <t>A Path Computation LSP Update Request message (also referred to as
PCUpd message) <xref format="default" section="6.2" PCUpd message; see <xref format="default" section="6.2"
sectionFormat="parens" target="RFC8231"/> is a PCEP message sent by a 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 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 object can be included in a PCUpd message to convey proprietary or
vendor-specific information.</t> vendor-specific information.</t>
<t>The format of the PCUpd message (with <xref format="default" <t>The format of the PCUpd message (using the format described in <xref fo rmat="default"
section="6.2" sectionFormat="of" target="RFC8231"/> as the base) is section="6.2" sectionFormat="of" target="RFC8231"/> as the base) is
updated as follows:</t> updated as follows:</t>
<artwork align="left" alt="" name="" type=""><![CDATA[ <sourcecode type="rbnf"><![CDATA[
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<update-request-list> <update-request-list>
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<update-request-list> ::= <update-request> <update-request-list> ::= <update-request>
[<update-request-list>] [<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
<LSP> <LSP>
<path> <path>
[<vendor-info-list>] [<vendor-info-list>]
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<vendor-info-list> ::= <VENDOR-INFORMATION> <vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>] [<vendor-info-list>]
<path> is defined in [RFC8231]. <path> is defined in [RFC8231].
]]></artwork> ]]></sourcecode>
<t>A Path Computation LSP Initiate Message (also referred to as <t>A Path Computation LSP Initiate Message (also referred to as
PCInitiate message) <xref format="default" section="5.1" PCInitiate message; see <xref format="default" section="5.1"
sectionFormat="parens" target="RFC8281"/> is a PCEP message sent by a sectionFormat="of" target="RFC8281"/>) is a PCEP message sent by a
PCE to a PCC to trigger an LSP instantiation or deletion. The Vendor PCE to a PCC to trigger an LSP instantiation or deletion. The Vendor
Information object can be included in a PCInitiate message to convey Information object can be included in a PCInitiate message to convey
proprietary or vendor-specific information.</t> proprietary or vendor-specific information.</t>
<t>The format of the PCInitiate message (with <xref format="default" <t>The format of the PCInitiate message (using the format described in <xr ef format="default"
section="5.1" sectionFormat="of" target="RFC8281"/> as the base) is section="5.1" sectionFormat="of" target="RFC8281"/> as the base) is
updated as follows:</t> updated as follows:</t>
<artwork align="left" alt="" name="" type=""><![CDATA[ <sourcecode type="rbnf"><![CDATA[
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <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-list>] [<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= <PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>| (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP> <PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP> <LSP>
[<END-POINTS>] [<END-POINTS>]
<ERO> <ERO>
[<attribute-list>] [<attribute-list>]
[<vendor-info-list>] [<vendor-info-list>]
]]></sourcecode>
Where: <t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<vendor-info-list> ::= <VENDOR-INFORMATION> <vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>] [<vendor-info-list>]
]]></sourcecode>
<PCE-initiated-lsp-deletion> and <attribute-list> is as per <t> &lt;PCE-initiated-lsp-deletion&gt; and &lt;attribute-list&gt; are as def
[RFC8281]. ined in
]]></artwork> <xref target="RFC8281"/>.</t>
<t>A legacy implementation that does not recognize the Vendor <t>A legacy implementation that does not recognize the Vendor
Information object will act according to the procedures set out in <xref Information object will act according to the procedures set out in <xref
format="default" target="RFC8231"/> and <xref format="default" format="default" target="RFC8231"/> and <xref format="default"
target="RFC8281"/>. An implementation that supports the Vendor target="RFC8281"/>. An implementation that supports the Vendor
Information object, but receives one carrying an Enterprise Number that Information object, but receives one carrying an Enterprise Number that
it does not support, MUST ignore the object in the same way as described it does not support, <bcp14>MUST</bcp14> ignore the object in the same way as described
in <xref format="default" section="2" sectionFormat="of" in <xref format="default" section="2" sectionFormat="of"
target="RFC7470"/>.</t> target="RFC7470"/>.</t>
</section> </section>
<section anchor="TLV" numbered="true" toc="default"> <section anchor="TLV" numbered="true" toc="default">
<name>Procedures for the Vendor Information TLV</name> <name>Procedures for the Vendor Information TLV</name>
<t>The Vendor Information TLV can be used to carry vendor-specific <t>The Vendor Information TLV can be used to carry vendor-specific
information that applies to a specific PCEP object by including the TLV information that applies to a specific PCEP object by including the TLV
in the object. This includes objects used in Stateful PCE extensions in the object. This includes objects used in Stateful PCE extensions
such as Stateful PCE Request Parameter (SRP) and LSP objects. All the such as Stateful PCE Request Parameter (SRP) and LSP objects. All of the
procedures are as per section 3 of <xref format="default" procedures are as described in <xref section="3" sectionFormat="of"
target="RFC7470"/>.</t> target="RFC7470"/>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Manageability Considerations</name> <name>Manageability Considerations</name>
<t>All manageability requirements and considerations listed in <xref <t>All manageability requirements and considerations listed in <xref
format="default" target="RFC5440"/>, <xref format="default" format="default" target="RFC5440"/>, <xref format="default"
target="RFC7470"/>, <xref format="default" target="RFC8231"/>, and <xref target="RFC7470"/>, <xref format="default" target="RFC8231"/>, and <xref
format="default" target="RFC8281"/> apply to PCEP protocol extensions format="default" target="RFC8281"/> apply to the PCEP protocol extensions
defined in this document. In addition, the requirements and defined in this document. In addition, the requirements and
considerations listed in this section apply.</t> considerations listed in this section apply.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Control of Function and Policy</name> <name>Control of Function and Policy</name>
<t>The requirements for control of function and policy for <t>The requirements for control of function and policy for
vendor-specific information as set out in [RFC7470] continue to apply vendor-specific information as set out in [RFC7470] continue to apply
to Stateful PCEP extensions specified in this document.</t> to Stateful PCEP extensions specified in this document.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Information and Data Models</name> <name>Information and Data Models</name>
<t>The PCEP YANG module is specified in <xref format="default" <t>The PCEP YANG module is specified in <xref format="default"
target="I-D.ietf-pce-pcep-yang"/>. Any standard YANG module will not target="PCEP-YANG"/>. Any standard YANG module will not
include details of vendor-specific information. However, include details of vendor-specific information. However,
the standard YANG module could be extended to report the use of the a standard YANG module could be extended to report the use of the
Vendor Information object or TLV and the Enterprise Numbers that the Vendor Information object or TLV and the Enterprise Numbers that the
objects and TLVs contain.</t> objects and TLVs contain.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name> <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 format="default" target="RFC5440"/>.</t> listed in <xref format="default" target="RFC5440"/>.</t>
skipping to change at line 411 skipping to change at line 383
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements On Other Protocols</name> <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 numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Impact On Network Operations</name> <name>Impact on Network Operations</name>
<t>Mechanisms defined in <xref format="default" target="RFC5440"/> and <t>Mechanisms defined in <xref format="default" target="RFC5440"/> and
<xref format="default" target="RFC8231"/> also apply to PCEP <xref format="default" target="RFC8231"/> also apply to PCEP
extensions defined in this document.</t> extensions defined in this document.</t>
<t>Section 6.6 of <xref format="default" target="RFC7470"/> highlights <t><xref section="6.6" sectionFormat="of" target="RFC7470"/> highlights
how the presence of additional vendor-specific information in PCEP how the presence of additional vendor-specific information in PCEP
messages may congest the operations and how to detect and handle it. messages may congest the operations and how to detect and handle it.
This also applies to stateful PCEP messages as outlined in Section 2. This also applies to stateful PCEP messages as outlined in <xref target=
Specifically, a PCEP speaker SHOULD NOT include vendor information in "Procedures"/>.
Specifically, a PCEP speaker <bcp14>SHOULD NOT</bcp14> include vendor in
formation in
stateful PCEP message if it believes the recipient does not support stateful PCEP message if it believes the recipient does not support
that information.</t> that information.</t>
<t>Encoding optimization for the Vendor Information Object, for <t>Encoding optimization for the Vendor Information object, for
example, in case of the object with the same content encoded for example, in case the object has the same content encoded for
multiple LSPs, is considered out of the scope of this document and may 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 be proposed in the future as a separate document applicable to other
PCEP objects.</t> PCEP objects.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>There are no IANA actions in this document.</t> <t>This document has no IANA actions.</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>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
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 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 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>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The protocol extensions defined in this document do not change the <t>The protocol extensions defined in this document do not change the
nature of PCEP. Therefore, the security considerations set out in <xref nature of PCEP. Therefore, the security considerations set out in <xref
format="default" target="RFC5440"/>, <xref format="default" format="default" target="RFC5440"/>, <xref format="default"
target="RFC7470"/>, <xref format="default" target="RFC8231"/> and <xref target="RFC7470"/>, <xref format="default" target="RFC8231"/>, and <xref
format="default" target="RFC8281"/> apply unchanged.</t> format="default" target="RFC8281"/> apply unchanged.</t>
<t>As per <xref format="default" target="RFC8231"/> it is RECOMMENDED <t>Per <xref format="default" target="RFC8231"/>, it is <bcp14>RECOMMENDED </bcp14>
that these PCEP extensions only be activated on authenticated and that these PCEP extensions only be activated on authenticated and
encrypted sessions across PCEs and PCCs using Transport Layer Security encrypted sessions across PCEs and PCCs using Transport Layer Security
(TLS) <xref format="default" target="RFC8253"/>, as per the (TLS) <xref format="default" target="RFC8253"/>. See the
recommendations and best current practices in RFC 9325 <xref recommendations and best current practices for using TLS in RFC 9325 <xref
derivedContent="BCP195" format="default" target="BCP195"/>.</t> derivedContent="BCP195" format="default" target="BCP195"/>.</t>
<t>The use of vendor-specific information as defined in <xref <t>The use of vendor-specific information as defined in <xref
format="default" target="RFC7470"/> and in this document may provide a format="default" target="RFC7470"/> and in this document may provide a
covert channel that could be misused by PCEP speaker implementations or covert channel that could be misused by PCEP speaker implementations or
by malicious software at PCEP speakers. While there is limited protection by malicious software at PCEP speakers. While there is limited protection
against this, an operator monitoring the PCEP sessions can detect the against this, an operator monitoring the PCEP sessions can detect the
use of vendor-specific information, be aware of the decoding mechanism use of vendor-specific information, be aware of the decoding mechanism
for this data, and inspect it accordingly. It is crucial for the for this data, and inspect it accordingly. It is crucial for the
operator to remain vigilant and monitor for any potential misuse of this operator to remain vigilant and monitor for any potential misuse of this
object. Appropriate steps need to be taken to prevent the installation of object. Appropriate steps need to be taken to prevent the installation of
malicious software at the PCEP speaker by implementing robust integrity, malicious software at the PCEP speaker by implementing robust integrity,
authentication, and authorization techniques for installation and authentication, and authorization techniques for installation and
updating, which are out of scope of this draft.</t> updating, which are out of scope of this document.</t>
</section>
<section anchor="Acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name>
<t>Thanks to Dhruv Dhody for shepherding and for significant contributions
and suggestions.</t>
<t>Thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="Avant
ika"/>,
<contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Gunter Van de Velde"/>, <contact fullname="John Scud
der"/>,
<contact fullname="Mahendra Singh Negi"/>, <contact fullname="Mahesh Je
thanandani"/>,
<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"/
>,
<contact fullname="Xiao Min"/> for their reviews, comments and suggesti
ons.</t>
</section> </section>
<section numbered="true" 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>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.2119.xml" 119.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.8174.xml" 440.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
511.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
470.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
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
195.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R </references>
FC.5440.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <references>
FC.5511.xml" <name>Informative References</name>
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.7470.xml" 578.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
371.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
253.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <!-- [I-D.ietf-pce-pcep-yang] draft-ietf-pce-pcep-yang-30
FC.8231.xml" IESG State: RFC Ed Queue as of 02/10/25. Used long way for WiP since
xmlns:xi="http://www.w3.org/2001/XInclude"/> it was missing editor role for Dhruv Dhody. -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <reference anchor="PCEP-YANG" target="https://datatracker.ietf.org/doc/html/draf
FC.8281.xml" t-ietf-pce-pcep-yang-30">
xmlns:xi="http://www.w3.org/2001/XInclude"/> <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>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
0195.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
</references> </references>
</references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<references> <t>Thanks to <contact fullname="Dhruv Dhody"/> for shepherding the documen
<name>Informative References</name> t and for their significant contributions and suggestions.</t>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2578.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <t>Thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="Avant
FC.9371.xml" ika"/>,
xmlns:xi="http://www.w3.org/2001/XInclude"/> <contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Gunter Van de Velde"/>, <contact fullname="John Scud
der"/>,
<contact fullname="Mahendra Singh Negi"/>, <contact fullname="Mahesh Je
thanandani"/>,
<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 suggest
ions.</t>
</section>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <section numbered="false" toc="default">
FC.7942.xml" <name>Contributors</name>
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <contact fullname="Dhruv Dhody">
FC.8051.xml" <organization>Huawei</organization>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <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>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R </section>
FC.8253.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-pcep-yang.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
</references>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 96 change blocks. 
280 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.48.