Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 9756 Huawei
Updates: 5440, 8231, 8233, 8281, 8623, 8664, A. Farrel
8685, 8697, 8733, 8745, 8779, 8780, Old Dog Consulting
8800, 8934, 9050, 9059, 9168, 9357, March 2025
9504, 9603, 9604
Category: Standards Track
ISSN: 2070-1721
This document updates the registration procedure within the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group. This specification changes some of the registries with Standards Action to IETF Review as defined in RFC 8126 and thus updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604.
このドキュメントは、IANA「Path Computation Element Protocol（PCEP）番号」レジストリグループ内の登録手順を更新します。この仕様は、RFC 8126で定義されているようにIETFレビューの標準アクションを備えたレジストリの一部を変更し、RFCS 8231、8233、8281、8623、8664、8685、8697、8733、8745、8779、8780、8800、8934、9059、9059、9059、9059、90599357、9504、9603、および9604。
Designating "experimental use" sub-ranges within codepoint registries is often beneficial for protocol experimentation in controlled environments. Although the registries for PCEP messages, objects, and TLV types have sub-ranges assigned for Experimental Use, the registry for PCEP Error-Types and Error-values currently does not. This document updates RFC 5440 by designating a specific range of PCEP Error-Types for Experimental Use.
CodePointレジストリ内で「実験的使用」サブレンジを指定することは、制御された環境でのプロトコル実験に有益なことがよくあります。PCEPメッセージ、オブジェクト、およびTLVタイプのレジストリには、実験的使用のためにサブレンジが割り当てられていますが、PCEPエラータイプとエラー価値のレジストリは現在そうではありません。このドキュメントは、実験的に使用するために特定の範囲のPCEPエラータイプを指定することにより、RFC 5440を更新します。
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/rfc9756.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9756で取得できます。
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
2. Standards Action PCEP Registries Affected
3. Experimental Error-Types
3.1. Advice on Experimentation
3.2. Handling of Unknown Experimentation
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Rationale for Updating All Registries with Standards
Action
Appendix B. Consideration of RFC 8356
Acknowledgements
Contributors
Authors' Addresses
The IANA "Path Computation Element Protocol (PCEP) Numbers" registry group was populated by several RFCs produced by the Path Computation Element (PCE) Working Group. Most of the registries include IETF Review [RFC8126] as the registration procedure. There are a few registries that use Standards Action. Thus, the values in those registries can be assigned only through the Standards Track or Best Current Practice RFCs in the IETF Stream. This memo changes the policy from Standards Action to IETF Review to allow any type of RFC under the IETF Stream to make the allocation request.
IANA「Path Computation Element Protocol（PCEP）番号」レジストリグループには、Path Computation Element（PCE）ワーキンググループによって生成されたいくつかのRFCが入力されました。ほとんどのレジストリには、登録手順としてIETFレビュー[RFC8126]が含まれています。標準アクションを使用するレジストリがいくつかあります。したがって、これらのレジストリの値は、IETFストリームの標準トラックまたは最良の現在のプラクティスRFCを介してのみ割り当てることができます。このメモは、ポリシーを標準アクションからIETFレビューに変更して、IETFストリームの下であらゆるタイプのRFCを許可し、割り当てリクエストを作成します。
Further, in Section 9 of [RFC5440], IANA assigns values to the PCEP parameters. The allocation policy for each of these parameters specified in [RFC5440] is IETF Review [RFC8126]. In consideration of the benefits of conducting experiments with PCEP and the utility of experimental codepoints [RFC3692], codepoint ranges for PCEP messages, objects, and TLV types for Experimental Use [RFC8126] are designated in [RFC8356]. However, protocol experiments may also need to return protocol error messages indicating experiment-specific error cases. It will often be that previously assigned error codes (in the "PCEP-ERROR Object Error Types and Values" registry) can be used to indicate the error cases within an experiment, but there may also be instances where new, experimental error codes are needed. In order to run experiments, it is important that the codepoint values used in the experiments do not collide with existing codepoints or any future allocations. This document updates [RFC5440] by changing the allocation policy for the registry of PCEP Error-Types to mark some of the codepoints as assigned for Experimental Use. As stated in [RFC3692], experiments using these codepoints are not intended to be used in general deployments, and due care must be taken to ensure that two experiments using the same codepoints are not run in the same environment.
さらに、[RFC5440]のセクション9では、IANAはPCEPパラメーターに値を割り当てます。[RFC5440]で指定されたこれらの各パラメーターの割り当てポリシーは、IETFレビュー[RFC8126]です。PCEPで実験を行うことの利点と実験的コードポイント[RFC3692]の有用性を考慮して、実験的使用のためのPCEPメッセージ、オブジェクト、およびTLVタイプのコードポイント範囲[RFC8126]は[RFC8356]で指定されています。ただし、プロトコル実験は、実験固有のエラーケースを示すプロトコルエラーメッセージを返す必要もあります。多くの場合、以前に割り当てられたエラーコード（「pcep-errorオブジェクトエラータイプと値」レジストリで）を使用して、実験内のエラーケースを示すことができますが、新しい実験エラーコードが必要な場合もあります。実験を実行するには、実験で使用されるコードポイント値が既存のコードポイントや将来の割り当てと衝突しないことが重要です。このドキュメントは、PCEPエラータイプのレジストリの割り当てポリシーを変更して、実験用に割り当てられたコードポイントの一部をマークすることにより、[RFC5440]を更新します。[RFC3692]に記載されているように、これらのコードポイントを使用した実験は一般的な展開で使用することを意図していないため、同じ環境で同じコードポイントを使用した2つの実験が実行されないことを確認するために十分な注意を払う必要があります。
The following table lists the registries under the "Path Computation Element Protocol (PCEP) Numbers" registry group whose registration policies have been changed from Standards Action to IETF Review. The affected registries list this document as an additional reference. Where this change has been applied to a specific range of values within the particular registry, that range is given in the Remarks column.
次の表には、登録ポリシーが標準アクションからIETFレビューに変更された「Path Computation Element Protocol（PCEP）番号」レジストリグループの下にあるレジストリを示します。影響を受けるレジストリは、このドキュメントを追加の参照としてリストします。この変更が特定のレジストリ内の特定の値の範囲に適用されている場合、その範囲は備考列に記載されています。
+========================================+===========+=========+
| Registry | RFC | Remarks |
+========================================+===========+=========+
| BU Object Type Field | [RFC8233] | |
+----------------------------------------+-----------+---------+
| LSP Object Flag Field | [RFC8231] | |
+----------------------------------------+-----------+---------+
| STATEFUL-PCE-CAPABILITY TLV Flag Field | [RFC8231] | |
+----------------------------------------+-----------+---------+
| LSP-ERROR-CODE TLV Error Code Field | [RFC8231] | |
+----------------------------------------+-----------+---------+
| SRP Object Flag Field | [RFC8281] | |
+----------------------------------------+-----------+---------+
| SR-ERO Flag Field | [RFC8664] | |
+----------------------------------------+-----------+---------+
| PATH-SETUP-TYPE-CAPABILITY Sub-TLV | [RFC8664] | |
| Type Indicators | | |
+----------------------------------------+-----------+---------+
| SR Capability Flag Field | [RFC8664] | |
+----------------------------------------+-----------+---------+
| WA Object Flag Field | [RFC8780] | |
+----------------------------------------+-----------+---------+
| Wavelength Restriction TLV Action | [RFC8780] | |
| Values | | |
+----------------------------------------+-----------+---------+
| Wavelength Allocation TLV Flag Field | [RFC8780] | |
+----------------------------------------+-----------+---------+
| S2LS Object Flag Field | [RFC8623] | |
+----------------------------------------+-----------+---------+
| H-PCE-CAPABILITY TLV Flag Field | [RFC8685] | |
+----------------------------------------+-----------+---------+
| H-PCE-FLAG TLV Flag Field | [RFC8685] | |
+----------------------------------------+-----------+---------+
| ASSOCIATION Flag Field | [RFC8697] | |
+----------------------------------------+-----------+---------+
| ASSOCIATION Type Field | [RFC8697] | |
+----------------------------------------+-----------+---------+
| AUTO-BANDWIDTH-CAPABILITY TLV Flag | [RFC8733] | |
| Field | | |
+----------------------------------------+-----------+---------+
| Path Protection Association Group TLV | [RFC8745] | |
| Flag Field | | |
+----------------------------------------+-----------+---------+
| Generalized Endpoint Types | [RFC8779] | 0-244 |
+----------------------------------------+-----------+---------+
| GMPLS-CAPABILITY TLV Flag Field | [RFC8779] | |
+----------------------------------------+-----------+---------+
| DISJOINTNESS-CONFIGURATION TLV Flag | [RFC8800] | |
| Field | | |
+----------------------------------------+-----------+---------+
| SCHED-PD-LSP-ATTRIBUTE TLV Opt Field | [RFC8934] | |
+----------------------------------------+-----------+---------+
| Schedule TLVs Flag Field | [RFC8934] | |
+----------------------------------------+-----------+---------+
| FLOWSPEC Object Flag Field | [RFC9168] | |
+----------------------------------------+-----------+---------+
| Bidirectional LSP Association Group | [RFC9059] | |
| TLV Flag Field | | |
+----------------------------------------+-----------+---------+
| PCECC-CAPABILITY sub-TLV | [RFC9050] | |
+----------------------------------------+-----------+---------+
| CCI Object Flag Field for MPLS Label | [RFC9050] | |
+----------------------------------------+-----------+---------+
| TE-PATH-BINDING TLV BT Field | [RFC9604] | |
+----------------------------------------+-----------+---------+
| TE-PATH-BINDING TLV Flag Field | [RFC9604] | |
+----------------------------------------+-----------+---------+
| LSP-EXTENDED-FLAG TLV Flag Field | [RFC9357] | |
+----------------------------------------+-----------+---------+
| LSP Exclusion Subobject Flag Field | [RFC9504] | |
+----------------------------------------+-----------+---------+
| SRv6-ERO Flag Field | [RFC9603] | |
+----------------------------------------+-----------+---------+
| SRv6 Capability Flag Field | [RFC9603] | |
+----------------------------------------+-----------+---------+
Table 1: PCEP Registries Affected
表1：影響を受けるPCEPレジストリ
Future registries in the "Path Computation Element Protocol (PCEP) Numbers" registry group should prefer to use IETF Review over Standards Action.
「Path Computation Element Protocol（PCEP）番号」の将来のレジストリレジストリグループは、標準アクションよりもIETFレビューを使用することを好む必要があります。
Per this document, IANA has designated four PCEP Error-Type codepoints (252-255) for Experimental Use.
このドキュメントによると、IANAは、実験的に使用するために4つのPCEPエラータイプのコードポイント（252-255）を指定しています。
IANA maintains the "PCEP-ERROR Object Error Types and Values" registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has changed the assignment policy for the "PCEP-ERROR Object Error Types and Values" registry as follows:
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリグループの下にある「PCEP-Errorオブジェクトエラータイプと値」レジストリを維持します。IANAは、「PCEP-Errorオブジェクトエラータイプと値」レジストリの割り当てポリシーを次のように変更しました。
+=========+==============+=====================================+
| Range | Registration | Note |
| | Procedures | |
+=========+==============+=====================================+
| 0-251 | IETF Review | The IETF Review procedure applies |
| | | to all Error-values (0-255) for |
| | | Error-Types in this range. |
+---------+--------------+-------------------------------------+
| 252-255 | Experimental | The Experimental Use policy applies |
| | Use | to all Error-values (0-255) for |
| | | Error-Types in this range. |
+---------+--------------+-------------------------------------+
Table 2: PCEP-ERROR Object Error Types and Values Registry Assignment Policy
表2：PCEP-ERRORオブジェクトエラータイプと値レジストリ割り当てポリシー
Furthermore, IANA has added the following entry to the registry:
さらに、IANAは次のエントリをレジストリに追加しました。
+============+==================+=====================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+==================+=====================+===========+
| 252-255 | Reserved for | 0-255: Reserved for | RFC 9756 |
| | Experimental Use | Experimental Use | |
+------------+------------------+---------------------+-----------+
Table 3: PCEP-ERROR Object Error Types and Values Registry
表3：PCEP-ERRORオブジェクトエラータイプと値レジストリ
An experiment that wishes to return experimental error codes should use one of the experimental Error-Type values as defined in this document. The experiment should agree on, between all participating parties, which Error-Type to use and which Error-values to use within that Error-Type. The experiment will describe what the meanings of those Error-Type/Error-value pairs are. Those Error-Types and Error-values should not be recorded in any public (especially any IETF) documentation. Textual or symbolic names for the Error-Types and Error-values may be used to help keep the documentation clear.
実験的なエラーコードを返したい実験では、このドキュメントで定義されているように、実験的なエラー型値の1つを使用する必要があります。実験は、すべての参加者間で、使用するエラータイプとそのエラータイプ内で使用するエラー値に同意する必要があります。実験では、これらのエラータイプ/エラー値ペアの意味が何であるかを説明します。これらのエラータイプとエラー値は、一般（特にIETF）ドキュメントに記録されるべきではありません。エラータイプとエラー値のテキストまたはシンボリック名を使用して、ドキュメントを明確にするのに役立ちます。
If multiple experiments are taking place at the same time using the same implementations, care must be taken to keep the sets of Error-Types/Error-values distinct.
同じ実装を使用して複数の実験が同時に行われている場合、エラータイプ/エラー値のセットを明確に保つように注意する必要があります。
Note that there is no scope for experimental Error-values within existing non-experimental Error-Types. This reduces the complexity of the registry and implementations. Experiments should place all experimental Error-values under the chosen experimental Error-Types.
既存の非実験的エラータイプ内の実験的エラー値の範囲はないことに注意してください。これにより、レジストリと実装の複雑さが削減されます。実験では、選択した実験誤差型の下にすべての実験誤差値を配置する必要があります。
If, at some future time, the experiment is declared a success and moved to IETF work targeting publication on the Standards Track, each pair of Error-Types/Error-values will need to be assigned by IANA from the registry. In some cases, this will involve assigning a new Error-Type with its subtended Error-values. In other cases, use may be made of an existing Error-Type with new subtended Error-values being assigned. The resulting change to code in an implementation is as simple as changing the numeric values of the Error-Types and Error-values.
ある時期に、実験が成功と宣言され、標準トラックでの出版物をターゲットとするIETF作業に移動した場合、エラータイプ/エラー値の各ペアは、レジストリからIANAによって割り当てる必要があります。場合によっては、これには、抑制されたエラー値を備えた新しいエラータイプを割り当てることが含まれます。それ以外の場合、既存のエラータイプで使用される場合があります。実装でのコードの結果の変更は、エラータイプとエラー価値の数値を変更するのと同じくらい簡単です。
A PCEP implementation that receives an experimental Error-Type in a PCEP message and does not recognize the Error-Type (i.e., is not part of the experiment) will treat the error as it would treat any other unknown Error-Type (such as from a new protocol extension). An implementation that is notified of a PCEP error will normally close the PCEP session (see [RFC5440]). In general, PCEP implementations are not required to take specific action based on Error-Types but may log the errors for diagnostic purposes.
PCEPメッセージで実験エラー型を受信し、エラータイプを認識しないPCEP実装（つまり、実験の一部ではありません）は、他の不明なエラータイプ（新しいプロトコル拡張など）を処理するため、エラーを処理します。PCEPエラーが通知される実装は、通常、PCEPセッションを閉じます（[RFC5440]を参照）。一般に、PCEPの実装は、エラータイプに基づいて特定のアクションを実行する必要はありませんが、診断目的でエラーを記録する場合があります。
An implementation that is part of an experiment may receive an experimental Error-Type but not recognize the Error-value. This could happen because of any of the following reasons:
実験の一部である実装は、実験的なエラータイプを受け取ることができますが、エラー値を認識しない場合があります。これは、次のいずれかの理由で発生する可能性があります。
* a faulty implementation
* 誤った実装
* two implementations not being synchronized with respect to which Error-values to use in the experiment
* 実験で使用するエラー値に関して同期されていない2つの実装
* more than one experiment being run at the same time
* 同時に複数の実験が実行されています
As with unknown Error-Types, an implementation receiving an unknown Error-value is not expected to do more than log the received error and may close the PCEP session.
不明なエラータイプと同様に、未知のエラー値を受信する実装は、受信したエラーを記録し、PCEPセッションを閉じること以上のものを実行するとは予想されません。
This memo is entirely about updating the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group.
このメモは、IANA「Path Computation Element Protocol（PCEP）番号」レジストリグループの更新に関するものです。
This memo does not change the security considerations for any of the updated RFCs. Refer to [RFC5440] and [PCEPS-UPDATES] for further details of the specific security measures applicable to PCEP.
このメモは、更新されたRFCのセキュリティに関する考慮事項を変更しません。PCEPに適用される特定のセキュリティ対策の詳細については、[RFC5440]および[PCEPS-Updates]を参照してください。
[RFC3692] asserts that the existence of experimental codepoints introduces no new security considerations. However, implementations accepting experimental error codepoints need to consider how they parse and process them in case they come, accidentally, from another experiment. Further, an implementation accepting experimental codepoints needs to consider the security aspects of the experimental extensions. [RFC6709] provides various design considerations for protocol extensions (including those designated as experimental).
[RFC3692]は、実験的なコードポイントの存在が新しいセキュリティ上の考慮事項を導入しないと主張しています。ただし、実験的なエラーコードポイントを受け入れる実装では、別の実験から誤って来た場合に備えて、それらがどのように解析および処理されるかを検討する必要があります。さらに、実験的なコードポイントを受け入れる実装では、実験的拡張のセキュリティの側面を考慮する必要があります。[RFC6709]は、プロトコル拡張（実験として指定されたものを含む）にさまざまな設計上の考慮事項を提供します。
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/info/rfc8233>.
[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>.
[RFC8356] Dhody, D., King, D., and A. Farrel, "Experimental
Codepoint Allocation for the Path Computation Element
Communication Protocol (PCEP)", RFC 8356,
DOI 10.17487/RFC8356, March 2018,
<https://www.rfc-editor.org/info/rfc8356>.
[RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
Path Computation Element (PCE) Protocol Extensions for
Usage with Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
<https://www.rfc-editor.org/info/rfc8623>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>.
[RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and
L. Fang, "Path Computation Element Communication Protocol
(PCEP) Extensions for MPLS-TE Label Switched Path (LSP)
Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733,
DOI 10.17487/RFC8733, February 2020,
<https://www.rfc-editor.org/info/rfc8733>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F.
Zhang, Ed., "Path Computation Element Communication
Protocol (PCEP) Extensions for GMPLS", RFC 8779,
DOI 10.17487/RFC8779, July 2020,
<https://www.rfc-editor.org/info/rfc8779>.
[RFC8780] Lee, Y., Ed. and R. Casellas, Ed., "The Path Computation
Element Communication Protocol (PCEP) Extension for
Wavelength Switched Optical Network (WSON) Routing and
Wavelength Assignment (RWA)", RFC 8780,
DOI 10.17487/RFC8780, July 2020,
<https://www.rfc-editor.org/info/rfc8780>.
[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element Communication Protocol (PCEP)
Extension for Label Switched Path (LSP) Diversity
Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
July 2020, <https://www.rfc-editor.org/info/rfc8800>.
[RFC8934] Chen, H., Ed., Zhuang, Y., Ed., Wu, Q., and D. Ceccarelli,
"PCE Communication Protocol (PCEP) Extensions for Label
Switched Path (LSP) Scheduling with Stateful PCE",
RFC 8934, DOI 10.17487/RFC8934, October 2020,
<https://www.rfc-editor.org/info/rfc8934>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs)",
RFC 9059, DOI 10.17487/RFC9059, June 2021,
<https://www.rfc-editor.org/info/rfc9059>.
[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation
Element Communication Protocol (PCEP) Extension for Flow
Specification", RFC 9168, DOI 10.17487/RFC9168, January
2022, <https://www.rfc-editor.org/info/rfc9168>.
[RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag
Extension for Stateful PCE", RFC 9357,
DOI 10.17487/RFC9357, February 2023,
<https://www.rfc-editor.org/info/rfc9357>.
[RFC9504] Lee, Y., Zheng, H., Gonzalez de Dios, O., Lopez, V., and
Z. Ali, "Path Computation Element Communication Protocol
(PCEP) Extensions for Stateful PCE Usage in GMPLS-
Controlled Networks", RFC 9504, DOI 10.17487/RFC9504,
December 2023, <https://www.rfc-editor.org/info/rfc9504>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
and Y. Zhu, "Path Computation Element Communication
Protocol (PCEP) Extensions for IPv6 Segment Routing",
RFC 9603, DOI 10.17487/RFC9603, July 2024,
<https://www.rfc-editor.org/info/rfc9603>.
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
<https://www.rfc-editor.org/info/rfc9604>.
[PCEPS-UPDATES]
Dhody, D., Turner, S., and R. Housley, "Updates for PCEPS:
TLS Connection Establishment Restrictions", Work in
Progress, Internet-Draft, draft-ietf-pce-pceps-tls13-04, 9
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pceps-tls13-04>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>.
This specification updates all the mentioned registries with the Standards Action policy. The PCE WG considered keeping Standards Action for some registries, such as flag fields with limited bits where the space is tight, but decided against it. The Working Group Last Call and IETF Last Call processes should be enough to handle the case of frivolous experiments taking over the few codepoints. The working group could also create a new protocol field and registry for future use as done in the past (see [RFC9357]).
この仕様は、言及されたすべてのレジストリを標準アクションポリシーに更新します。PCE WGは、スペースがタイトなものが限られたビットが制限されているが、それに反対することを決定する旗フィールドなど、一部のレジストリの標準訴訟を維持することを検討しました。ワーキンググループの最後のコールとIETFの最後のコールプロセスは、いくつかのコードポイントを引き継ぐ軽薄な実験のケースを処理するのに十分なはずです。ワーキンググループは、過去に行われたように、将来使用するための新しいプロトコルフィールドとレジストリを作成することもできます（[RFC9357]を参照）。
It is worth noting that [RFC8356] deliberately chose to make experimental codepoints available only in the PCEP messages, objects, and TLV type registries. Appendix A of [RFC8356] gives a brief explanation of why that decision was taken, stating that:
[RFC8356]は、PCEPメッセージ、オブジェクト、およびTLVタイプレジストリでのみ実験的なコードポイントを利用可能にすることを意図的に選択したことに注意する価値があります。[RFC8356]の付録Aは、その決定が下された理由の簡単な説明を示しています。
The justification for this decision is that, if an experiment finds that it wants to use a new codepoint in another PCEP sub-registry, it can implement the same function using a new experimental object or TLV instead.
この決定の正当性は、実験で別のPCEPサブレジストリで新しいコードポイントを使用したいことがわかった場合、代わりに新しい実験オブジェクトまたはTLVを使用して同じ関数を実装できることです。
While it is true that an experimental implementation could assign an experimental PCEP object and designate it the "experimental errors object", using it to carry arbitrary contents including experimental error codes, such an approach would cause unnecessary divergence in the code. The allowance of experimental Error-Types is a better approach that will more easily enable the migration of successful experiments onto the Standards Track.
実験的実装により、実験的なPCEPオブジェクトを割り当てて「実験エラーオブジェクト」を指定し、実験エラーコードを含む任意のコンテンツを運ぶためにそれを使用できることは事実ですが、そのようなアプローチはコードに不必要な発散を引き起こします。実験的なエラータイプの許容値は、成功した実験の標準トラックへの移行をより簡単に可能にするより良いアプローチです。
Thanks to John Scudder for the initial discussion behind this document. Thanks to Ketan Talaulikar, Andrew Stone, Samuel Sidor, Quan Xiong, Cheng Li, and Aijun Wang for the review comments. Thanks to Carlos Pignataro for the OPSDIR review. Thanks to Meral Shirazipour for the GENART review. Thanks to Paul Kyzivat for the ArtArt review. Thanks to Alexey Melnikov for the SECDIR review.
この文書の背後にある最初の議論をしてくれたJohn Scudderに感謝します。Ketan Talaulikar、Andrew Stone、Samuel Sidor、Quan Xiong、Cheng Li、Aijun Wangにレビューのコメントをしてくれたことに感謝します。OpsdirレビューをしてくれたCarlos Pignataroに感謝します。Genart ReviewのMeral Shirazipourに感謝します。ArtartレビューをしてくれたPaul Kyzivatに感謝します。SecdirレビューをしてくれたAlexey Melnikovに感謝します。
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk