RFC 9752

Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

📅 published April 2025, from ietf

RFC 9752: Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE 🎀

okay so before we dive in, here's the title block tea ☕✨

  • It's an IETF document (Internet Engineering Task Force 🦋) and its number is RFC 9752 💖
  • It's published in April 2025 🌸 and it's on the Standards Track 👑, with ISSN 2070-1721
  • The authors are C. Li and H. Zheng from Huawei Technologies, S. Sivabalan from Ciena, and S. Sidor and Z. Ali from Cisco Systems, Inc. 🫶
  • It updates RFC 7470 🔥, which is the one that handles vendor-specific info in stateless PCEP. This doc has no "Obsoletes" line, so it doesn't replace anything.

Abstract ✨

okay so this doc adds extensions to PCEP (the Path Computation Element Communication Protocol) that let you put vendor-specific info inside stateful PCE messages 🧚 That means vendors can tuck proprietary data into PCEP messages, which can help with fancy network optimization in setups that need vendor-specific features 💅 The extensions are built to stay compatible with existing PCEP implementations and to help different network deployments play nicely together 🌈

RFC 7470 already gave us a way to carry vendor-specific info in stateless PCEP messages, and this document extends that same idea to the stateful PCEP messages 💜

Also, this document updates RFC 7470 so that Enterprise Numbers are managed through the "Private Enterprise Numbers (PENs)" registry 🍓

Status of This Memo ⭐

This is an Internet Standards Track document 👑

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💖 If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9752 🦋

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 💅

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 🔥

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
  1.2.  Use of RBNF
2.  Procedures for the Vendor Information Object
3.  Procedures for the Vendor Information TLV
4.  Manageability Considerations
  4.1.  Control of Function and Policy
  4.2.  Information and Data Models
  4.3.  Liveness Detection and Monitoring
  4.4.  Verifying Correct Operations
  4.5.  Requirements On Other Protocols
  4.6.  Impact on Network Operations
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

okay so PCEP ([RFC5440]) gives a Path Computation Element (PCE) a way to do path computation when a Path Computation Client (PCC) asks for one 🦋

A stateful PCE is the next level 😭 It doesn't just look at the network state in terms of links and nodes (the Traffic Engineering Database, or TED 🌈). It also looks at active services, meaning previously computed paths and resources that are currently reserved, which are stored in the Label Switched Paths Database (LSP-DB) 💜 [RFC8051] covers the general considerations for a stateful PCE deployment, including its applicability, benefits, challenges, and limitations, through a bunch of use cases 📚

[RFC8231] describes the extensions to PCEP that give you stateful control 👑 A stateful PCE can see not only what the Interior Gateway Protocol (IGP) carries, but also the active paths and their reserved resources, so it can compute constrained paths while considering individual LSPs and how they interact 🔥 [RFC8281] covers setting up, maintaining, and tearing down PCE-initiated LSPs under the stateful PCE model, and it adds new messages to PCEP for that 🍓

[RFC7470] defines the Vendor Information object, which can carry arbitrary proprietary info (like vendor-specific constraints) in stateless PCEP 🫶 It also defines the VENDOR-INFORMATION-TLV, which lets you embed arbitrary info inside any existing or future PCEP object that supports TLVs 🌸

The Vendor Information object and the VENDOR-INFORMATION-TLV were originally designed for stateless PCEP, but they're super useful in the stateful PCE model too 💖 The VENDOR-INFORMATION-TLV can already go in any of the stateful PCEP objects per [RFC7470]. This document takes it further and extends stateful PCEP messages so they can use the Vendor Information object 🧚

1.1. Requirements Language

Here's the deal with the key words 🎀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document mean what BCP 14 [RFC2119] [RFC8174] says they mean, but only when they show up in ALL CAPS, exactly as shown here 💅

1.2. Use of RBNF

The message formats in this doc are illustrated with Routing Backus-Naur Form (RBNF), as specified in [RFC5511] 🦋 RBNF is just for illustration, so it may leave out some important details 🙈 The normative spec for messages lives in the descriptive text 💜 If the RBNF and the descriptive text ever disagree, the descriptive text wins 👑

2. Procedures for the Vendor Information Object 🌈

A Path Computation LSP State Report message (also called a PCRpt message; see Section 6.1 of [RFC8231]) is a PCEP message that a PCC sends to a PCE to report the current state of an LSP 🫶 If a PCC wants to share proprietary or vendor-specific info or metrics with a PCE, it does that by putting a Vendor Information object in the PCRpt message 💖 The contents and format of the object, including the VENDOR-INFORMATION object and the VENDOR-INFORMATION-TLV, are described in Section 4 of [RFC7470] 🧚 The PCE figures out how to interpret the info in the Vendor Information object by looking at the Enterprise Number it contains 🍓

[RFC7470] originally said:

Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578].

This document updates [RFC7470] and replaces that text with:

Enterprise Numbers are assigned by IANA and managed through the "Private Enterprise Numbers (PENs)" registry as described in [RFC9371].

The Vendor Information object is OPTIONAL in a PCRpt message 🌸 You can have multiple instances of the object in a single PCRpt message (they MAY be included), and different instances MAY carry different Enterprise Numbers 💅

Here's how the PCRpt message format changes, using Section 6.1 of [RFC8231] as the base 🔥

      <PCRpt Message> ::= <Common Header>
                          <state-report-list>

Where:

      <state-report-list> ::= <state-report>[<state-report-list>]

      <state-report> ::= [<SRP>]
                         <LSP>
                         <path>
                         [<vendor-info-list>]

Where:

      <vendor-info-list> ::= <VENDOR-INFORMATION>
                             [<vendor-info-list>]

<path> is defined in [RFC8231] 🦋

A Path Computation LSP Update Request message (also called a PCUpd message; see Section 6.2 of [RFC8231]) is a PCEP message that a PCE sends to a PCC to update the attributes of an LSP 💜 The Vendor Information object can be included in a PCUpd message to carry proprietary or vendor-specific info 👑

Here's the updated PCUpd format, using the format from Section 6.2 of [RFC8231] as the base 🌈

      <PCUpd Message> ::= <Common Header>
                          <update-request-list>

Where:

      <update-request-list> ::= <update-request>
                          [<update-request-list>]

      <update-request> ::= <SRP>
                           <LSP>
                           <path>
                           [<vendor-info-list>]

Where:

      <vendor-info-list> ::= <VENDOR-INFORMATION>
                             [<vendor-info-list>]

<path> is defined in [RFC8231] 🫶

A Path Computation LSP Initiate Message (also called a PCInitiate message; see Section 5.1 of [RFC8281]) is a PCEP message that a PCE sends to a PCC to trigger an LSP instantiation or deletion 🧚 The Vendor Information object can go in a PCInitiate message to carry proprietary or vendor-specific info 🌸

Here's the updated PCInitiate format, using the format from Section 5.1 of [RFC8281] as the base 💖

     <PCInitiate Message> ::= <Common Header>
                              <PCE-initiated-lsp-list>

Where:

     <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
                                  [<PCE-initiated-lsp-list>]

     <PCE-initiated-lsp-request> ::=
                          (<PCE-initiated-lsp-instantiation>|
                           <PCE-initiated-lsp-deletion>)

     <PCE-initiated-lsp-instantiation> ::= <SRP>
                                           <LSP>
                                           [<END-POINTS>]
                                           <ERO>
                                           [<attribute-list>]
                                           [<vendor-info-list>]

Where:

     <vendor-info-list> ::= <VENDOR-INFORMATION>
                            [<vendor-info-list>]

<PCE-initiated-lsp-deletion> and <attribute-list> are as defined in [RFC8281] 🍓

A legacy implementation that doesn't recognize the Vendor Information object will act according to the procedures in [RFC8231] and [RFC8281] 🙈 An implementation that does support the Vendor Information object, but gets one with an Enterprise Number it doesn't support, MUST ignore the object in the same way described in Section 2 of [RFC7470] 🚫💅

3. Procedures for the Vendor Information TLV 💜

The Vendor Information TLV can carry vendor-specific info that applies to a specific PCEP object, by including the TLV in that object 🦋 This covers objects used in the Stateful PCE extensions, such as the Stateful PCE Request Parameter (SRP) and LSP objects 🌈 All of the procedures are the same as described in Section 3 of [RFC7470] 👑

4. Manageability Considerations 🫶

All of the manageability requirements and considerations listed in [RFC5440], [RFC7470], [RFC8231], and [RFC8281] apply to the PCEP protocol extensions defined in this document 🔥 On top of that, the requirements and considerations listed in this section apply ✨

4.1. Control of Function and Policy

okay so the rules for controlling function and policy for vendor-specific info in [RFC7470] still apply to the Stateful PCEP extensions in this doc 💅✨

4.2. Information and Data Models

the PCEP YANG module is specified in [PCEP-YANG] 🦋. Any standard YANG module won't include details of vendor-specific info 🙈. BUT a standard YANG module could be extended to report the use of the Vendor Information object or TLV, plus the Enterprise Numbers that the objects and TLVs contain 💜.

4.3. Liveness Detection and Monitoring

the mechanisms in this doc don't add any new liveness detection and monitoring requirements on top of the ones already listed in [RFC5440] 🌸

4.4. Verifying Correct Operations

same vibe here: no new operation verification requirements beyond the ones already listed in [RFC5440] and [RFC8231] 🧚

4.5. Requirements On Other Protocols

these mechanisms don't create any new requirements on other protocols 🫶

4.6. Impact on Network Operations

the mechanisms in [RFC5440] and [RFC8231] also apply to the PCEP extensions in this doc 🔥

Section 6.6 of [RFC7470] spills the tea on how extra vendor-specific info in PCEP messages can clog up operations, and how to detect and handle it 🙈. This also applies to stateful PCEP messages, as outlined in Section 2. Specifically, a PCEP speaker SHOULD NOT include vendor information in a stateful PCEP message if it believes the recipient doesn't support that information 🚫.

Encoding optimization for the Vendor Information object (like, if the object has the same content encoded for multiple LSPs) is out of scope for this doc 🍓. It may be proposed later as a separate document that applies to other PCEP objects ✨.

5. IANA Considerations

zero IANA actions for this doc, nothing to see here 🙅‍♀️💖

6. Security Considerations

okay this section is serious but I'm still gonna be dramatic about it 😭🔥

The protocol extensions in this doc don't change the nature of PCEP 💅. So the security considerations in [RFC5440], [RFC7470], [RFC8231], and [RFC8281] apply unchanged 🫶.

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] 🔐✨. Check out the recommendations and best current practices for using TLS in RFC 9325 [BCP195] 📚💜.

⚠️ the covert channel situation is the real main character moment here, bestie 💀

The use of vendor-specific info, as defined in [RFC7470] and in this doc, may provide a covert channel that could be misused by PCEP speaker implementations or by malicious software at PCEP speakers 👀. There's limited protection against this, BUT an operator monitoring the PCEP sessions can detect the use of vendor-specific info, be aware of the decoding mechanism for this data, and inspect it accordingly 🕵️‍♀️🎀. It is crucial for the operator to stay vigilant and monitor for any potential misuse of this object 🚨. Appropriate steps need to be taken to prevent malicious software from being installed at the PCEP speaker, by implementing robust integrity, authentication, and authorization techniques for installation and updating 🛡️. Those techniques are out of scope of this document, so go get them elsewhere 💅.

7. References

7.1. Normative References

7.2. Informative References

Acknowledgments

huge thanks to Dhruv Dhody for shepherding the doc and for their significant contributions and suggestions 🫶💖.

thanks to Adrian Farrel, Avantika, Deb Cooley, Éric Vyncke, Gunter Van de Velde, John Scudder, Mahendra Singh Negi, Mahesh Jethanandani, Mike McBride, Murray Kucherawy, Orie Steele, Paul Wouters, Roman Danyliw, Susan Hares, Swapna K, Udayasree Palle, Warren Kumari, Wassim Haddad, and Xiao Min for their reviews, comments, and suggestions 👑🌈.

Contributors

Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com


Mike Koldychev
Ciena
Email: mkoldych@proton.me

Authors' Addresses

Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com


Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: zhenghaomian@huawei.com


Siva Sivabalan
Ciena
385 Terry Fox Drive
Kanata Ontario K2K 0L1
Canada
Email: msiva282@gmail.com


Samuel Sidor
Cisco Systems, Inc.
Email: ssidor@cisco.com


Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
📦 where this page comes from