rfc9752v1.txt   rfc9752.txt 
Internet Engineering Task Force (IETF) C. Li Internet Engineering Task Force (IETF) C. Li
Request for Comments: 9752 H. Zheng Request for Comments: 9752 H. Zheng
Updates: 7470 Huawei Technologies Updates: 7470 Huawei Technologies
Category: Standards Track S. Sivabalan Category: Standards Track S. Sivabalan
ISSN: 2070-1721 Ciena ISSN: 2070-1721 Ciena
S. Sidor S. Sidor
Z. Ali Z. Ali
Cisco Systems, Inc. Cisco Systems, Inc.
March 2025 April 2025
Conveying Vendor-Specific Information in the Path Computation Element Conveying Vendor-Specific Information in the Path Computation Element
Communication Protocol (PCEP) Extensions for Stateful PCE Communication Protocol (PCEP) Extensions for Stateful PCE
Abstract Abstract
This document specifies extensions to the Path Computation Element This document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) that enable the inclusion of vendor- Communication Protocol (PCEP) that enable the inclusion of vendor-
specific information in stateful Path Computation Element (PCE) specific information in stateful Path Computation Element (PCE)
operations. These extensions allow vendors to incorporate operations. These extensions allow vendors to incorporate
proprietary data within PCEP messages, facilitating enhanced network proprietary data within PCEP messages, facilitating enhanced network
optimization and functionality in environments requiring vendor- optimization and functionality in environments requiring vendor-
specific features. The extensions maintain compatibility with specific features. The extensions maintain compatibility with
existing PCEP implementations and promote interoperability across existing PCEP implementations and promote interoperability across
diverse network deployments. RFC 7470 defines a facility to carry diverse network deployments. RFC 7470 defines a facility to carry
vendor-specific information in stateless PCEP messages. This vendor-specific information in stateless PCEP messages. This
document extends this capability for the Stateful PCEP messages. document extends this capability for the stateful PCEP messages.
This document updates RFC 7470 to revise the reference to the IANA This document updates RFC 7470 to specify that Enterprise Numbers are
registry for managing Enterprise Numbers. managed through the "Private Enterprise Numbers (PENs)" registry.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 91 skipping to change at line 91
Contributors Contributors
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The Path Computation Element Communication Protocol (PCEP) [RFC5440] The Path Computation Element Communication Protocol (PCEP) [RFC5440]
provides mechanisms for a Path Computation Element (PCE) to perform provides mechanisms for a Path Computation Element (PCE) to perform
path computation in response to a Path Computation Client (PCC) path computation in response to a Path Computation Client (PCC)
request. request.
A Stateful PCE is capable of considering, for the purposes of path A stateful PCE is capable of considering, for the purposes of path
computation, not only the network state in terms of links and nodes 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 (LSP- reserved resources, stored in the Label Switched Paths Database (LSP-
DB)). [RFC8051] describes general considerations for a Stateful PCE DB)). [RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as deployment and examines its applicability and benefits, as well as
its challenges and limitations through a number of use cases. its challenges and limitations through a number of use cases.
[RFC8231] describes a set of extensions to PCEP to provide stateful [RFC8231] describes a set of extensions to PCEP to provide stateful
control. A Stateful PCE has access to not only the information control. A stateful PCE has access to not only the information
carried by the network's Interior Gateway Protocol (IGP), but also carried by the network's Interior Gateway Protocol (IGP), but also
the set of active paths and their reserved resources for its the set of active paths and their reserved resources for its
computations. The additional state allows the PCE to compute computations. The additional state allows the PCE to compute
constrained paths while considering individual LSPs and their constrained paths while considering individual LSPs and their
interactions. [RFC8281] describes the setup, maintenance, and interactions. [RFC8281] describes the setup, maintenance, and
teardown of PCE-initiated LSPs under the Stateful PCE model. These teardown of PCE-initiated LSPs under the stateful PCE model. These
extensions add new messages in PCEP for Stateful PCE. extensions add new messages in PCEP for stateful PCE.
[RFC7470] defines the Vendor Information object, which can carry [RFC7470] defines the Vendor Information object, which can carry
arbitrary, proprietary information, such as vendor-specific arbitrary, proprietary information, such as vendor-specific
constraints, in stateless PCEP. It also defines the VENDOR- constraints, in stateless PCEP. It also defines the VENDOR-
INFORMATION-TLV, which allows arbitrary information to be embedded INFORMATION-TLV, which allows arbitrary information to be embedded
within any existing or future PCEP object that supports TLVs. within any existing or future PCEP object that supports TLVs.
While originally designed for stateless PCEP, the Vendor Information While originally designed for stateless PCEP, the Vendor Information
object and VENDOR-INFORMATION-TLV are also useful in the Stateful PCE object and VENDOR-INFORMATION-TLV are also useful in the stateful PCE
model. The VENDOR-INFORMATION-TLV can already be included in any of model. The VENDOR-INFORMATION-TLV can already be included in any of
the stateful PCEP objects per [RFC7470]. This document further the stateful PCEP objects per [RFC7470]. This document further
extends stateful PCEP messages to support the use of the Vendor extends stateful PCEP messages to support the use of the Vendor
Information object. Information object.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
skipping to change at line 197 skipping to change at line 197
[<vendor-info-list>] [<vendor-info-list>]
<path> is defined in [RFC8231]. <path> is defined in [RFC8231].
A Path Computation LSP Update Request message (also referred to as A Path Computation LSP Update Request message (also referred to as
PCUpd message; see Section 6.2 of [RFC8231]) is a PCEP message sent PCUpd message; see Section 6.2 of [RFC8231]) is a PCEP message sent
by a PCE to a PCC to update the attributes of an LSP. The Vendor 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 Information object can be included in a PCUpd message to convey
proprietary or vendor-specific information. proprietary or vendor-specific information.
The format of the PCUpd message (with Section 6.2 of [RFC8231] as the The format of the PCUpd message (using the format described in
base) is updated as follows: Section 6.2 of [RFC8231] as the base) is updated as follows:
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<update-request-list> <update-request-list>
Where: Where:
<update-request-list> ::= <update-request> <update-request-list> ::= <update-request>
[<update-request-list>] [<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
skipping to change at line 226 skipping to change at line 226
[<vendor-info-list>] [<vendor-info-list>]
<path> is defined in [RFC8231]. <path> is defined in [RFC8231].
A Path Computation LSP Initiate Message (also referred to as A Path Computation LSP Initiate Message (also referred to as
PCInitiate message; see Section 5.1 of [RFC8281]) is a PCEP message PCInitiate message; see Section 5.1 of [RFC8281]) is a PCEP message
sent by a PCE to a PCC to trigger an LSP instantiation or deletion. 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 The Vendor Information object can be included in a PCInitiate message
to convey proprietary or vendor-specific information. to convey proprietary or vendor-specific information.
The format of the PCInitiate message (with Section 5.1 of [RFC8281] The format of the PCInitiate message (using the format described in
as the base) is updated as follows: Section 5.1 of [RFC8281] as the base) is updated as follows:
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: Where:
<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> ::=
skipping to change at line 338 skipping to change at line 338
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
The protocol extensions defined in this document do not change the The protocol extensions defined in this document do not change the
nature of PCEP. Therefore, the security considerations set out in nature of PCEP. Therefore, the security considerations set out in
[RFC5440], [RFC7470], [RFC8231], and [RFC8281] apply unchanged. [RFC5440], [RFC7470], [RFC8231], and [RFC8281] apply unchanged.
As per [RFC8231], it is RECOMMENDED that these PCEP extensions only Per [RFC8231], it is RECOMMENDED that these PCEP extensions only be
be activated on authenticated and encrypted sessions across PCEs and activated on authenticated and encrypted sessions across PCEs and
PCCs using Transport Layer Security (TLS) [RFC8253], as per the PCCs using Transport Layer Security (TLS) [RFC8253]. See the
recommendations and best current practices in RFC 9325 [BCP195]. recommendations and best current practices for using TLS in RFC 9325
[BCP195].
The use of vendor-specific information as defined in [RFC7470] and in The use of vendor-specific information as defined in [RFC7470] and in
this document may provide a covert channel that could be misused by this document may provide a covert channel that could be misused by
PCEP speaker implementations or by malicious software at PCEP PCEP speaker implementations or by malicious software at PCEP
speakers. While there is limited protection against this, an speakers. While there is limited protection against this, an
operator monitoring the PCEP sessions can detect the use of vendor- operator monitoring the PCEP sessions can detect the use of vendor-
specific information, be aware of the decoding mechanism for this specific information, be aware of the decoding mechanism for this
data, and inspect it accordingly. It is crucial for the operator to data, and inspect it accordingly. It is crucial for the operator to
remain vigilant and monitor for any potential misuse of this object. remain vigilant and monitor for any potential misuse of this object.
Appropriate steps need to be taken to prevent the installation of Appropriate steps need to be taken to prevent the installation of
skipping to change at line 451 skipping to change at line 452
Acknowledgments Acknowledgments
Thanks to Dhruv Dhody for shepherding the document and for their Thanks to Dhruv Dhody for shepherding the document and for their
significant contributions and suggestions. significant contributions and suggestions.
Thanks to Adrian Farrel, Avantika, Deb Cooley, Éric Vyncke, Gunter Thanks to Adrian Farrel, Avantika, Deb Cooley, Éric Vyncke, Gunter
Van de Velde, John Scudder, Mahendra Singh Negi, Mahesh Jethanandani, Van de Velde, John Scudder, Mahendra Singh Negi, Mahesh Jethanandani,
Mike McBride, Murray Kucherawy, Orie Steele, Paul Wouters, Roman Mike McBride, Murray Kucherawy, Orie Steele, Paul Wouters, Roman
Danyliw, Susan Hares, Swapna K, Udayasree Palle, Warren Kumari, Danyliw, Susan Hares, Swapna K, Udayasree Palle, Warren Kumari,
Wassim Haddad, and Xiao Min for their reviews, comments and Wassim Haddad, and Xiao Min for their reviews, comments, and
suggestions. suggestions.
Contributors Contributors
Dhruv Dhody Dhruv Dhody
Huawei Huawei
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Mike Koldychev Mike Koldychev
 End of changes. 12 change blocks. 
19 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.48.