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"		<!DOCTYPE rfc [
	symRefs="true" tocInclude="true" updates="7470" version="3" xml:lang="en">		<!ENTITY nbsp "&#160;">
	<!--6 xml2rfc v2v3 conversion 3.10.0 -->		<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
			tf-pce-stateful-pce-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>		<front>
	<title abbrev="VENDOR-STATEFUL">Conveying Vendor-Specific Information in		<title abbrev="VENDOR-STATEFUL">Conveying Vendor-Specific Information in
	the Path Computation Element (PCE) Communication Protocol (PCEP)		the Path Computation Element Communication Protocol (PCEP)
	extensions for Stateful PCE.</title>		Extensions for Stateful PCE</title>
			<seriesInfo name="RFC" value="9752"/>
	<seriesInfo name="Internet-Draft"
	value="draft-ietf-pce-stateful-pce-vendor-13"/>
	<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="March" year="2025"/>
	<workgroup>PCE Working Group</workgroup>		<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>		<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>
			<!-- [rfced] "to revise the refrence to the IANA registry" is unclear without fu
			rther 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		<t>This document updates RFC 7470 to revise the reference to the
	IANA registry for managing Enterprise Numbers.</t>		IANA registry for managing Enterprise Numbers.</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
	skipping to change at line 176 ¶		skipping to change at line 142 ¶
	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>
			<!-- [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"		<t>The format of the PCUpd message (with <xref format="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 (with <xref 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 417 ¶
	</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		<!-- [rfced] The use of "as per" twice in this sentence is confusing. As it see
			ms the second instance refers to best practices for implementing TLS, please con
			sider 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"/>, it is <bcp14>RECOMMEN
			DED</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"/>, as per the
	recommendations and best current practices in RFC 9325 <xref		recommendations and best current practices 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>
	<section anchor="Acknowledgments" numbered="true" toc="default">		</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			440.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.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"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			578.xml"/>
			<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"/>
			<!-- [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/draf
			t-ietf-pce-pcep-yang-30">
			<front>
			<title>A YANG Data Model for Path Computation Element Communications Proto
			col (PCEP)</title>
			<author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor"
			>
			<organization>Huawei</organization>
			</author>
			<author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
			<organization>Juniper Networks</organization>
			</author>
			<author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
			</author>
			<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
			<organization>Nvidia</organization>
			</author>
			<date month="January" day="26" year="2025" />
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-30" />
			</reference>
			</references>
			</references>
			<section anchor="Acknowledgments" numbered="false" toc="default">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>Thanks to Dhruv Dhody for shepherding and for significant contributions and suggestions.</t>		<t>Thanks to <contact fullname="Dhruv Dhody"/> for shepherding the documen t and for their significant contributions and suggestions.</t>
	<t>Thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="Avant ika"/>,		<t>Thanks to <contact fullname="Adrian Farrel"/>, <contact fullname="Avant ika"/>,
	<contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>,		<contact fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>,
	<contact fullname="Gunter Van de Velde"/>, <contact fullname="John Scud der"/>,		<contact fullname="Gunter Van de Velde"/>, <contact fullname="John Scud der"/>,
	<contact fullname="Mahendra Singh Negi"/>, <contact fullname="Mahesh Je thanandani"/>,		<contact fullname="Mahendra Singh Negi"/>, <contact fullname="Mahesh Je thanandani"/>,
	<contact fullname="Mike McBride"/>, <contact fullname="Murray Kucherawy "/>,		<contact fullname="Mike McBride"/>, <contact fullname="Murray Kucherawy "/>,
	<contact fullname="Orie Steele"/>, <contact fullname="Paul Wouters"/>,		<contact fullname="Orie Steele"/>, <contact fullname="Paul Wouters"/>,
	<contact fullname="Roman Danyliw"/>, <contact fullname="Susan Hares"/>,		<contact fullname="Roman Danyliw"/>, <contact fullname="Susan Hares"/>,
	<contact fullname="Swapna K"/>, <contact fullname="Udayasree Palle"/>,		<contact fullname="Swapna K"/>, <contact fullname="Udayasree Palle"/>,
	<contact fullname="Warren Kumari"/>, <contact fullname="Wassim Haddad"/ >,		<contact fullname="Warren Kumari"/>, <contact fullname="Wassim Haddad"/ >, and
	<contact fullname="Xiao Min"/> for their reviews, comments and suggesti ons.</t>		<contact fullname="Xiao Min"/> for their reviews, comments and suggesti ons.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="false" toc="default">
	<name>Contributors</name>		<name>Contributors</name>
	<artwork align="left" alt="" name="" type=""><![CDATA[		<contact fullname="Dhruv Dhody">
	Dhruv Dhody		<organization>Huawei</organization>
	Huawei		<address>
	India		<postal>
			<country>India</country>
	EMail: dhruv.ietf@gmail.com		</postal>
			<email>dhruv.ietf@gmail.com</email>
	Mike Koldychev		</address>
	Ciena		</contact>
			<contact fullname="Mike Koldychev">
			<organization>Ciena</organization>
			<address>
			<email>mkoldych@proton.me</email>
			</address>
			</contact>
	EMail: mkoldych@proton.me
	]]></artwork>
	</section>		</section>
	</middle>
	<back>
	<references>
	<name>References</name>
	<references>
	<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		</back>
	FC.2119.xml"
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8174.xml"
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.5440.xml"
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.5511.xml"
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.7470.xml"
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<!-- [rfced] We updated artwork to sourcecode in Section 2, with type set to "rb
	FC.8231.xml"		nf". Please review and let us know if any updates are needed.
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		The current list of preferred values for "type" is available at
	FC.8281.xml"		<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
	xmlns:xi="http://www.w3.org/2001/XInclude"/>		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.
			-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.		<!-- [rfced] Throughout the text, the following terminology appears to be used
	0195.xml"		inconsistently.
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	</references>
	<references>		- Vendor Information Object vs Vendor Information object (per RFC 7470)
	<name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		We have updated this as "Vendor Information object". Please let us know any obj
	FC.2578.xml"		ections.
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		- Please review the capitalization of stateful in the following and let us know
	FC.9371.xml"		if/how they should be made consistent.
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		stateful PCE operations
	FC.7942.xml"		Stateful PCE
	xmlns:xi="http://www.w3.org/2001/XInclude"/>		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.
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		Note that our script did not flag any words in particular, but this should
	FC.8051.xml"		still be reviewed as a best practice.
	xmlns:xi="http://www.w3.org/2001/XInclude"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		-->
	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>
	</rfc>		</rfc>
End of changes. 94 change blocks.
	254 lines changed or deleted		293 lines changed or added
This html diff was produced by rfcdiff 1.48.