Internet Engineering Task Force (IETF) C. Li
Request for Comments: 9752 H. Zheng
Updates: 7470 Huawei Technologies
Category: Standards Track S. Sivabalan
ISSN: 2070-1721 Ciena
S. Sidor
Z. Ali
Cisco Systems, Inc.
April 2025
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor-specific information in stateful Path Computation Element (PCE) operations. These extensions allow vendors to incorporate proprietary data within PCEP messages, facilitating enhanced network optimization and functionality in environments requiring vendor-specific features. The extensions maintain compatibility with existing PCEP implementations and promote interoperability across diverse network deployments. RFC 7470 defines a facility to carry vendor-specific information in stateless PCEP messages. This document extends this capability for the stateful PCEP messages.
このドキュメントは、Stateful Path Computation Element（PCE）操作にベンダー固有の情報を含めることを可能にするパス計算要素通信プロトコル（PCEP）への拡張機能を指定します。これらの拡張機能により、ベンダーはPCEPメッセージに独自のデータを組み込むことができ、ベンダー固有の機能を必要とする環境でのネットワーク最適化と機能の強化を促進します。拡張機能は、既存のPCEP実装との互換性を維持し、多様なネットワーク展開全体で相互運用性を促進します。RFC 7470は、ステートレスPCEPメッセージにベンダー固有の情報を携帯する機能を定義しています。このドキュメントは、ステートフルなPCEPメッセージのこの機能を拡張します。
This document updates RFC 7470 to specify that Enterprise Numbers are managed through the "Private Enterprise Numbers (PENs)" registry.
このドキュメントは、RFC 7470を更新して、エンタープライズ番号が「プライベートエンタープライズ番号（PENS）」レジストリを介して管理されていることを指定します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9752.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9752で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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
The Path Computation Element Communication Protocol (PCEP) [RFC5440] provides mechanisms for a Path Computation Element (PCE) to perform path computation in response to a Path Computation Client (PCC) request.
PATH計算要素通信プロトコル（PCEP）[RFC5440]は、パス計算クライアント（PCC）要求に応じてパス計算を実行するパス計算要素（PCE）のメカニズムを提供します。
A stateful PCE is capable of considering, for the purposes of 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 status of active services (previously computed paths, and currently reserved resources, stored in the Label Switched Paths Database (LSP-DB)). [RFC8051] describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases.
ステートフルPCEは、パス計算のために、リンクとノード（トラフィックエンジニアリングデータベースまたはTEDと呼ばれる）の観点からネットワーク状態だけでなく、アクティブサービスのステータス（以前に計算されたパス、および現在予約されたリソース）の観点から、ラベルスイッチングパスデータベース（LSP-DB））の状態を検討することができます。[RFC8051]は、州のPCE展開に関する一般的な考慮事項を説明し、その適用性と利点、および多くのユースケースによる課題と制限を調べます。
[RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model. These extensions add new messages in PCEP for stateful PCE.
[RFC8231]は、PCEPへの拡張セットを説明して、ステートフルな制御を提供します。ステートフルなPCEは、ネットワークのインテリアゲートウェイプロトコル（IGP）が携帯する情報だけでなく、アクティブパスのセットとその計算用の予約リソースにもアクセスできます。追加の状態により、個々のLSPとその相互作用を検討しながら、PCEが制約付きパスを計算することができます。[RFC8281]は、Stateful PCEモデルの下でのPCE開始LSPのセットアップ、メンテナンス、および分解について説明しています。これらの拡張機能は、Stateful PCEのPCEPに新しいメッセージを追加します。
[RFC7470] defines the Vendor Information object, which can carry arbitrary, proprietary information, such as vendor-specific constraints, in stateless PCEP. It also defines the VENDOR-INFORMATION-TLV, which allows arbitrary information to be embedded within any existing or future PCEP object that supports TLVs.
[RFC7470]ベンダー情報オブジェクトを定義します。ベンダー情報オブジェクトは、ステートレスPCEPでベンダー固有の制約などの任意の独自の情報を運ぶことができます。また、TLVをサポートする既存または将来のPCEPオブジェクトに任意の情報を埋め込むことができるベンダーインフォメーションTLVも定義します。
While originally designed for stateless PCEP, the Vendor Information object and VENDOR-INFORMATION-TLV are also useful in the stateful PCE model. The VENDOR-INFORMATION-TLV can already be included in any of the stateful PCEP objects per [RFC7470]. This document further extends stateful PCEP messages to support the use of the Vendor Information object.
元々はステートレスPCEP向けに設計されていますが、ベンダー情報オブジェクトとベンダーインフォメーションTLVは、ステートフルPCEモデルにも役立ちます。ベンダーインフォメーション-TLVは、[RFC7470]あたりのステートフルPCEPオブジェクトのいずれかに既に含めることができます。このドキュメントは、ベンダー情報オブジェクトの使用をサポートするために、ステートフルPCEPメッセージをさらに拡張します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The message formats in this document are illustrated using Routing Backus-Naur Form (RBNF) encoding, as specified in [RFC5511]. The use of RBNF is illustrative only and may omit certain important details; the normative specification of messages is found in the descriptive text. If there is any divergence between the RBNF and the descriptive text, the descriptive text is considered authoritative.
このドキュメントのメッセージ形式は、[RFC5511]で指定されているように、ルーティングバックナウルフォーム（RBNF）エンコードを使用して示されています。RBNFの使用は実例のみであり、特定の重要な詳細を省略する場合があります。メッセージの規範的な仕様は、記述テキストにあります。RBNFと記述テキストの間に発散がある場合、記述テキストは権威あると見なされます。
A Path Computation LSP State Report message (also referred to as PCRpt message; see Section 6.1 of [RFC8231]) is a PCEP message sent by a PCC to a PCE to report the current state of an LSP. A PCC that wants to convey proprietary or vendor-specific information or metrics to a PCE does so by including a Vendor Information object in the PCRpt message. The contents and format of the object, including the VENDOR-INFORMATION object and the VENDOR-INFORMATION-TLV, are described in Section 4 of [RFC7470]. The PCE determines how to interpret the information in the Vendor Information object by examining the Enterprise Number it contains.
パス計算LSP状態レポートメッセージ（PCRPTメッセージとも呼ばれます。[RFC8231]のセクション6.1を参照）は、PCCによってPCCに送信されたPCEPメッセージで、LSPの現在の状態を報告します。PCRPTメッセージにベンダー情報オブジェクトを含めることにより、専有またはベンダー固有の情報またはメトリックをPCEに伝えたいPCC。ベンダーインフォメーションオブジェクトとベンダーインフォメーションTLVを含むオブジェクトの内容と形式は、[RFC7470]のセクション4で説明されています。PCEは、含まれるエンタープライズ番号を調べることにより、ベンダー情報オブジェクトの情報を解釈する方法を決定します。
[RFC7470] stated that:
[RFC7470]は次のように述べています。
Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578].
エンタープライズ番号はIANAによって割り当てられ、IANAレジストリ[RFC2578]を介して管理されます。
This document updates [RFC7470] and replaces this text with:
このドキュメントは[RFC7470]を更新し、このテキストを以下に置き換えます。
Enterprise Numbers are assigned by IANA and managed through the "Private Enterprise Numbers (PENs)" registry as described in [RFC9371].
エンタープライズ番号はIANAによって割り当てられ、[RFC9371]で説明されている「プライベートエンタープライズ番号（PENS）」レジストリを通じて管理されます。
The Vendor Information object is OPTIONAL in a PCRpt message. Multiple instances of the object MAY be contained in a single PCRpt message. Different instances of the object MAY have different Enterprise Numbers.
ベンダー情報オブジェクトは、PCRPTメッセージでオプションです。オブジェクトの複数のインスタンスは、単一のPCRPTメッセージに含まれる場合があります。オブジェクトのインスタンスが異なると、エンタープライズ数が異なる場合があります。
The format of the PCRpt message (with Section 6.1 of [RFC8231] as the base) is updated as follows:
[RFC8231]としてのPCRPTメッセージの形式（ベースとして）は次のように更新されます。
<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 referred to as 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 Information object can be included in a PCUpd message to convey proprietary or vendor-specific information.
パス計算LSP更新リクエストメッセージ（PCUPDメッセージとも呼ばれます。[RFC8231]のセクション6.2を参照）は、LSPの属性を更新するためにPCCからPCCによって送信されるPCEPメッセージです。ベンダー情報オブジェクトは、PCUPDメッセージに含めて、独自またはベンダー固有の情報を伝えることができます。
The format of the PCUpd message (using the format described in Section 6.2 of [RFC8231] as the base) is updated as follows:
PCUPDメッセージの形式（[RFC8231]のセクション6.2で説明されている形式をベースとして使用）は、次のように更新されます。
<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 referred to as 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. The Vendor Information object can be included in a PCInitiate message to convey proprietary or vendor-specific information.
PATH計算LSP開始メッセージ（PCINITIATEメッセージとも呼ばれます。[RFC8281]のセクション5.1を参照）は、PCCによってPCCに送信されたPCEPメッセージで、LSPインスタンス化または削除をトリガーします。ベンダー情報オブジェクトは、専有情報またはベンダー固有の情報を伝えるためのPCINITIATEメッセージに含めることができます。
The format of the PCInitiate message (using the format described in Section 5.1 of [RFC8281] as the base) is updated as follows:
PCInitiateメッセージの形式（[RFC8281]のセクション5.1で説明されている形式をベースとして使用）は、次のように更新されます。
<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].
<pce-initiated-lsp-deletion>および<属性リスト>は[RFC8281]で定義されています。
A legacy implementation that does not recognize the Vendor Information object will act according to the procedures set out in [RFC8231] and [RFC8281]. An implementation that supports the Vendor Information object, but receives one carrying an Enterprise Number that it does not support, MUST ignore the object in the same way as described in Section 2 of [RFC7470].
ベンダー情報オブジェクトを認識しないレガシーの実装は、[RFC8231]および[RFC8281]に記載されている手順に従って機能します。ベンダー情報オブジェクトをサポートするが、サポートされていないエンタープライズ番号を運ぶものを受信する実装は、[RFC7470]のセクション2で説明されているのと同じ方法でオブジェクトを無視する必要があります。
The Vendor Information TLV can be used to carry vendor-specific information that applies to a specific PCEP object by including the TLV in the object. This includes objects used in Stateful PCE extensions such as Stateful PCE Request Parameter (SRP) and LSP objects. All of the procedures are as described in Section 3 of [RFC7470].
ベンダー情報TLVを使用して、TLVをオブジェクトに含めることにより、特定のPCEPオブジェクトに適用されるベンダー固有の情報を運ぶことができます。これには、Stateful PCE Requestパラメーター（SRP）やLSPオブジェクトなどのStateful PCE拡張機能で使用されるオブジェクトが含まれます。すべての手順は、[RFC7470]のセクション3で説明されています。
All manageability requirements and considerations listed in [RFC5440], [RFC7470], [RFC8231], and [RFC8281] apply to the PCEP protocol extensions defined in this document. In addition, the requirements and considerations listed in this section apply.
[RFC5440]、[RFC7470]、[RFC8231]、および[RFC8281]にリストされているすべての管理可能性の要件と考慮事項は、このドキュメントで定義されているPCEPプロトコル拡張に適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
The requirements for control of function and policy for vendor-specific information as set out in [RFC7470] continue to apply to Stateful PCEP extensions specified in this document.
[RFC7470]に記載されているベンダー固有の情報の機能とポリシーの制御の要件は、このドキュメントで指定されたステートフルなPCEP拡張機能に引き続き適用されます。
The PCEP YANG module is specified in [PCEP-YANG]. Any standard YANG module will not include details of vendor-specific information. However, a standard YANG module could be extended to report the use of the Vendor Information object or TLV and the Enterprise Numbers that the objects and TLVs contain.
PCEP Yangモジュールは[PCEP-Yang]で指定されています。標準ヤンモジュールには、ベンダー固有の情報の詳細は含まれません。ただし、標準のYangモジュールを拡張して、ベンダー情報オブジェクトまたはTLVの使用と、オブジェクトとTLVに含まれるエンタープライズ番号を報告できます。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]に既にリストされているものに加えて、新しい活性検出および監視要件を意味するものではありません。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [RFC8231].
このドキュメントで定義されているメカニズムは、[RFC5440]および[RFC8231]に既にリストされているものに加えて、新しい操作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルの新しい要件を意味するものではありません。
Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document.
[RFC5440]および[RFC8231]で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張機能にも適用されます。
Section 6.6 of [RFC7470] highlights how the presence of additional vendor-specific information in PCEP messages may congest the operations and how to detect and handle it. This also applies to stateful PCEP messages as outlined in Section 2. Specifically, a PCEP speaker SHOULD NOT include vendor information in stateful PCEP message if it believes the recipient does not support that information.
[RFC7470]のセクション6.6は、PCEPメッセージに追加のベンダー固有の情報の存在が操作を混乱させる方法と、それを検出および処理する方法を強調しています。これは、セクション2で概説されているステートフルなPCEPメッセージにも適用されます。具体的には、PCEPスピーカーは、受信者がその情報をサポートしていないと考えている場合、ステートフルPCEPメッセージにベンダー情報を含めるべきではありません。
Encoding optimization for the Vendor Information object, 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 be proposed in the future as a separate document applicable to other PCEP objects.
たとえば、ベンダー情報オブジェクトの最適化をエンコードすると、オブジェクトが複数のLSPに対してエンコードされたコンテンツが同じである場合、このドキュメントの範囲外であると見なされ、他のPCEPオブジェクトに適用可能な個別のドキュメントとして将来提案される場合があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
The protocol extensions defined in this document do not change the nature of PCEP. Therefore, the security considerations set out in [RFC5440], [RFC7470], [RFC8231], and [RFC8281] apply unchanged.
このドキュメントで定義されているプロトコル拡張は、PCEPの性質を変更しません。したがって、[RFC5440]、[RFC7470]、[RFC8231]、および[RFC8281]に記載されているセキュリティ上の考慮事項は、変更されていません。
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].
[RFC8231]ごとに、これらのPCEP拡張は、トランスポート層セキュリティ（TLS）[RFC8253]を使用して、PCESおよびPCC全体で認証および暗号化されたセッションでのみアクティブ化することをお勧めします。RFC 9325 [BCP195]でTLSを使用するための推奨事項と最良の現在のプラクティスを参照してください。
The use of vendor-specific information as defined in [RFC7470] and in this document may provide a covert channel that could be misused by PCEP speaker implementations or by malicious software at PCEP speakers. While there is limited protection against this, an operator monitoring the PCEP sessions can detect the use of vendor-specific information, be aware of the decoding mechanism for this data, and inspect it accordingly. It is crucial for the operator to remain vigilant and monitor for any potential misuse of this object. Appropriate steps need to be taken to prevent the installation of malicious software at the PCEP speaker by implementing robust integrity, authentication, and authorization techniques for installation and updating, which are out of scope of this document.
[RFC7470]およびこのドキュメントで定義されているベンダー固有の情報の使用は、PCEPスピーカーの実装またはPCEPスピーカーの悪意のあるソフトウェアによって誤用される可能性のある秘密チャネルを提供する場合があります。これに対する保護は限られていますが、PCEPセッションを監視するオペレーターは、ベンダー固有の情報の使用を検出し、このデータのデコードメカニズムに注意し、それに応じて検査することができます。オペレーターが警戒し続け、このオブジェクトの潜在的な誤用を監視することが重要です。このドキュメントの範囲外であるインストールと更新のための堅牢な整合性、認証、および認証手法を実装することにより、PCEPスピーカーに悪意のあるソフトウェアのインストールを防ぐために適切な手順を実行する必要があります。
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[PCEP-YANG]
Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.
Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-30>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<https://www.rfc-editor.org/info/rfc2578>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC9371] Baber, A. and P. Hoffman, "Registration Procedures for
Private Enterprise Numbers (PENs)", RFC 9371,
DOI 10.17487/RFC9371, March 2023,
<https://www.rfc-editor.org/info/rfc9371>.
Thanks to Dhruv Dhody for shepherding the document and for their significant contributions and suggestions.
ドキュメントを羊飼いしてくれたDhruv Dhodyに感謝し、その重要な貢献と提案に感謝します。
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.
エイドリアン・ファレル、アバンティカ、デブ・クーリー、エリック・ヴィンケ、ガンター・ヴァン・デ・ヴェルデ、ジョン・スカダー、マヘンドラ・シン・ネギ、マヘシュ・ジェサナンダニ、マイク・マクブライド、マレー・クチェラウィー、オリエ・スティール、ポール・ワウター、ロマン・ハーリウ、ワッサン・ハー、ワラ・k、ワサン・ハーリー、Haddad、およびXiaoは、レビュー、コメント、提案について。
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Mike Koldychev
Ciena
Email: mkoldych@proton.me
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