Internet Engineering Task Force (IETF) B. Rajagopalan
Request for Comments: 9863 V. Beeram
Category: Standards Track Juniper Networks
ISSN: 2070-1721 S. Peng
ZTE Corporation
M. Koldychev
Ciena Corporation
G. Mishra
Verizon Communications Inc.
October 2025
Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute.
カラーは、トラフィック エンジニアリング (TE) トンネルまたはポリシーを意図または目的に関連付けるために使用される 32 ビットの数値 (符号なし整数) 属性です。たとえば、低遅延サービスを提供するように構築され、そのパスが遅延に対して最適化されている TE トンネルには、「低遅延」を表す色でタグを付けることができます。この文書は、色属性を伝達するためのパス計算要素プロトコル (PCEP) の拡張を指定します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9863.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9863 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Language
2. Protocol Operation
3. Protocol Extensions
3.1. Color Capability
3.2. COLOR TLV
4. Security Considerations
5. Manageability Considerations
5.1. Control of Function through Configuration and Policy
5.2. Information and Data Models
5.3. Liveness Detection and Monitoring
5.4. Verifying Correct Operation
5.5. Requirements on Other Protocols
5.6. Impact on Network Operation
6. IANA Considerations
6.1. PCEP TLV Type Indicator
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field
6.3. PCEP-Error Object
6.4. LSP-ERROR-CODE TLV Error Code Field
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
A Traffic Engineering (TE) Tunnel [RFC3209] or Segment Routing (SR) policy [RFC9256] can be associated with an intent or objective (e.g., low latency) by tagging it with a color. This color attribute is used as a guiding criterion for mapping services onto the TE Tunnel [RFC9012] or SR Policy [RFC9256]. The term "color" used in this document must not be interpreted as the "thread color" specified in [RFC3063] or the "resource color" (also referred to as "link color") specified in [RFC3630], [RFC5329], [RFC5305], and [RFC7308].
トラフィック エンジニアリング (TE) トンネル [RFC3209] またはセグメント ルーティング (SR) ポリシー [RFC9256] は、色でタグ付けすることで、意図または目的 (低遅延など) に関連付けることができます。この色属性は、サービスを TE トンネル [RFC9012] または SR ポリシー [RFC9256] にマッピングするための指針として使用されます。この文書で使用される「カラー」という用語は、[RFC3063] で規定されている「スレッドカラー」、または [RFC3630]、[RFC5329]、[RFC5305]、および [RFC7308] で規定されている「リソースカラー」(「リンクカラー」とも呼ばれる) として解釈してはならない。
[RFC8231] specifies extensions to the Path Computation Element Protocol (PCEP) that enable the deployment of a stateful Path Computation Element (PCE) model. These extensions allow a Path Computation Client (PCC) to delegate control of the Label Switched Paths (LSPs) associated with its TE Tunnels to a stateful PCE. [RFC8281] specifies extensions that allow a PCE to instantiate and manage PCE-initiated LSPs on a PCC under the stateful PCE model. [RFC8664] specifies extensions that enable stateful control of SR paths via PCEP.
[RFC8231] は、ステートフルなパス計算要素 (PCE) モデルの展開を可能にするパス計算要素プロトコル (PCEP) の拡張機能を指定しています。これらの拡張により、パス計算クライアント (PCC) は、その TE トンネルに関連付けられたラベル スイッチド パス (LSP) の制御をステートフル PCE に委任できるようになります。[RFC8281] は、PCE がステートフル PCE モデルの下で PCC 上で PCE によって開始される LSP をインスタンス化および管理できるようにする拡張機能を指定しています。[RFC8664] は、PCEP を介した SR パスのステートフル制御を可能にする拡張機能を指定しています。
This document introduces extensions to PCEP to allow a color tag to be assigned to any TE path operated under a stateful PCE model (including those set up using RSVP-TE [RFC8408] or Segment Routing [RFC8664]). The only exception where the extensions defined in this document MUST NOT be used to carry the color attribute is for SR paths established using the extensions defined in [RFC9862]. For these SR paths, the associated color is already included as part of the SR Policy identifier encoding.
この文書では、ステートフル PCE モデル (RSVP-TE [RFC8408] またはセグメント ルーティング [RFC8664] を使用して設定されたものを含む) で動作する任意の TE パスにカラー タグを割り当てることを可能にする PCEP の拡張機能を紹介します。この文書で定義された拡張をカラー属性を運ぶために使用してはならない唯一の例外は、[RFC9862] で定義された拡張を使用して確立された SR パスの場合です。これらの SR パスの場合、関連付けられた色は SR ポリシー識別子のエンコーディングの一部としてすでに含まれています。
The mechanism employed by the PCC for mapping services onto a TE path associated with a color attribute is outside the scope of this document, as is any other use of the color tag.
カラー属性に関連付けられた TE パスにサービスをマッピングするために PCC によって使用されるメカニズムは、カラー タグの他の使用法と同様、この文書の範囲外です。
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] で説明されているように解釈されます。
When the PCEP session is created, a PCEP (PCE/PCC) speaker sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A STATEFUL-PCE-CAPABILITY TLV Flag (see Section 3.1) is introduced in this document to enable the PCEP speaker to advertise color capability.
PCEP セッションが作成されると、PCEP (PCE/PCC) スピーカーは、[RFC8231] で定義されているように、STATEFUL-PCE-CAPABILITY TLV を含む OPEN オブジェクトを含む Open メッセージを送信します。STATEFUL-PCE-CAPABILITY TLV フラグ (セクション 3.1 を参照) がこの文書で導入され、PCEP スピーカーがカラー機能をアドバタイズできるようになります。
In PCRpt, PCUpd, and PCInitiate messages, the LSP object [RFC8231] [RFC8281] is a mandatory inclusion and is used to carry information specific to the target LSP. A TLV called the COLOR TLV (see Section 3.2), which MAY be carried in the LSP object, is introduced in this document to carry the color attribute associated with the LSP. Only one COLOR TLV SHOULD be included in the LSP object. If the COLOR TLV appears in the LSP object more than once, only the first occurrence is processed, and any others MUST be ignored.
PCRpt、PCUpd、および PCInitiate メッセージでは、LSP オブジェクト [RFC8231] [RFC8281] が必須であり、ターゲット LSP に固有の情報を運ぶために使用されます。COLOR TLV (セクション 3.2 を参照) と呼ばれる TLV は、LSP オブジェクト内で搬送されてもよく (MAY)、LSP に関連付けられたカラー属性を搬送するためにこの文書で導入されています。LSP オブジェクトには COLOR TLV を 1 つだけ含める必要があります (SHOULD)。COLOR TLV が LSP オブジェクトに複数回出現する場合、最初に出現したものだけが処理され、その他は無視されなければなりません (MUST)。
A PCEP speaker that has advertised color capability MUST NOT send COLOR TLV encoded in the LSP object to a PCEP Peer [RFC5440] that has not advertised color capability. A PCEP speaker that advertises both color capability and SR Policy Association [RFC9862] capability MUST NOT send COLOR TLV encoded in the LSP object for SR Paths. The COLOR TLV is ignored if it shows up in the LSP object of a message that carries an ASSOCIATION object of type SR Policy Association [RFC9862]. The color encoded in the SR Policy Association takes precedence in such a scenario.
カラー機能をアドバタイズした PCEP スピーカーは、LSP オブジェクト内でエンコードされた COLOR TLV を、カラー機能をアドバタイズしていない PCEP ピア [RFC5440] に送信してはなりません (MUST NOT)。カラー機能と SR ポリシー アソシエーション [RFC9862] 機能の両方をアドバタイズする PCEP スピーカーは、SR パスの LSP オブジェクトでエンコードされた COLOR TLV を送信してはなりません (MUST NOT)。COLOR TLV は、タイプ SR Policy Association [RFC9862] の ASSOCIATION オブジェクトを運ぶメッセージの LSP オブジェクトに表示される場合、無視されます。このようなシナリオでは、SR ポリシー アソシエーションでエンコードされた色が優先されます。
If a PCC is unable to honor a color value passed in a PCUpd or a PCInitiate message, the PCC MUST reject the message and send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=31 (Invalid color). This is expected behavior in scenarios where a PCC implementation does not support a color value of zero for specific path setup types, and it receives that value in the COLOR TLV of a PCUpd or a PCInitiate message.
PCC が PCUpd または PCInitiate メッセージで渡された色の値を受け入れることができない場合、PCC はメッセージを拒否し、Error-Type=19 (無効な操作) および Error-value=31 (無効な色) を含む PCErr メッセージを送信しなければなりません。これは、PCC 実装が特定のパス セットアップ タイプのカラー値 0 をサポートしておらず、その値を PCUpd または PCInitiate メッセージの COLOR TLV で受け取るシナリオで予期される動作です。
When LSPs that belong to the same TE Tunnel are within the same Path Protection Association Group [RFC8745], they are all expected to have the same color attached to them. If a PCEP speaker determines inconsistency in the color associated with the LSPs belonging to the same Path Protection Association Group, it MUST reject the message carrying the inconsistent color and send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=32 (Inconsistent color).
同じ TE トンネルに属する LSP が同じ Path Protection Association Group [RFC8745] 内にある場合、それらはすべて同じ色が割り当てられていることが期待されます。PCEP スピーカーが、同じパス保護アソシエーション グループに属する LSP に関連付けられた色に矛盾があると判断した場合、矛盾した色を運ぶメッセージを拒否し、Error-Type=19 (無効な操作) および Error-value=32 (矛盾した色) を含む PCErr メッセージを送信しなければなりません (MUST)。
Section 7.1.1 of [RFC8231] defines STATEFUL-PCE-CAPABILITY TLV flags. The following flag is used to indicate if the speaker supports color capability:
[RFC8231] のセクション 7.1.1 では、STATEFUL-PCE-CAPABILITY TLV フラグが定義されています。次のフラグは、スピーカーがカラー機能をサポートしているかどうかを示すために使用されます。
C-bit (Bit 20):
C ビット (ビット 20):
A PCE/PCC indicates that it supports the color capability defined in this document by setting this bit.
PCE/PCC は、このビットを設定することによって、この文書で定義されているカラー機能をサポートしていることを示します。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: COLOR TLV
図 1: カラー TLV
Type:
タイプ：
67
67
Length:
長さ：
4
4
Color:
色：
4-byte field that carries the actual color value (specified as an unsigned integer). A value of zero is allowed.
実際の色の値を格納する 4 バイトのフィールド (符号なし整数として指定)。値ゼロが許可されます。
This document defines a TLV for color and a flag for color capability negotiation, which do not add any security concerns beyond those discussed in [RFC5440], [RFC8231], and [RFC8281].
この文書は、カラーの TLV とカラー機能ネゴシエーションのフラグを定義します。これらは、[RFC5440]、[RFC8231]、および [RFC8281] で議論されているものを超えるセキュリティ上の懸念を追加しません。
An unauthorized PCE may maliciously associate the LSP with an incorrect color. The procedures described in [RFC8253] and [RFC9325] can be used to protect against this attack.
不正な PCE は、悪意を持って LSP を間違った色に関連付けることがあります。[RFC8253] および [RFC9325] で説明されている手順を使用して、この攻撃から保護できます。
This section follows the advice and guidance of [RFC6123].
このセクションは、[RFC6123] のアドバイスとガイダンスに従います。
An implementation supporting this document SHOULD allow the operator to turn on and off the PCEP color capability advertisement (Section 3.1). An implementation supporting this document SHOULD allow the configuration of color assignment to a TE Tunnel or an SR Policy. A PCC MAY have a local policy configuration that specifies how the color tag is used. This policy configuration is outside the scope of this document.
この文書をサポートする実装では、オペレータが PCEP カラー機能アドバタイズメントをオンまたはオフにできるようにする必要があります (セクション 3.1)。この文書をサポートする実装では、TE トンネルまたは SR ポリシーへの色の割り当ての設定を許可すべきです (SHOULD)。PCC は、カラー タグの使用方法を指定するローカル ポリシー設定を持つことができます (MAY)。このポリシー構成は、このドキュメントの範囲外です。
An implementation supporting this document SHOULD allow the inclusion of color in the data model used to retrieve the operational state of a TE Tunnel or an SR Policy. The YANG model in [YANG-TE] could be used to retrieve the operational state of a TE Tunnel, and the YANG model in [SR-POLICY-YANG] could be used to retrieve the operational state of an SR Policy.
この文書をサポートする実装では、TE トンネルまたは SR ポリシーの動作状態を取得するために使用されるデータ モデルに色を含めることを許可する必要があります (SHOULD)。[YANG-TE] の YANG モデルは TE トンネルの動作状態を取得するために使用でき、[SR-POLICY-YANG] の YANG モデルは SR ポリシーの動作状態を取得するために使用できます。
The extensions defined in this document do not require any additional liveness detection and monitoring support. See [RFC5440] and [RFC5886] for more information.
このドキュメントで定義されている拡張機能には、追加の活性検出および監視サポートは必要ありません。詳細については、[RFC5440] および [RFC5886] を参照してください。
The operator MAY retrieve the operational state of TE Paths to verify if they are tagged with the correct intended color.
オペレータは、TE パスの動作状態を取得して、意図した正しい色がタグ付けされているかどうかを確認してもよい(MAY)。
This document places no explicit requirements on other protocols.
この文書は他のプロトコルに明示的な要件を課しません。
The impact on network operations depends on how the color tag is used in the deployment. This is outside the scope of this document.
ネットワーク運用への影響は、展開内でカラー タグがどのように使用されるかによって異なります。これはこのドキュメントの範囲外です。
IANA has assigned a value in the "PCEP TLV Type Indicators" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの「PCEP TLV Type Indicators」レジストリに次のように値を割り当てました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 67 | Color | RFC 9863 |
+-------+-------------+-----------+
Table 1
IANA has assigned a bit value in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの「STATEFUL-PCE-CAPABILITY TLV Flag Field」レジストリのビット値を次のように割り当てました。
+=======+==================+===========+
| Value | Description | Reference |
+=======+==================+===========+
| 20 | COLOR-CAPABILITY | RFC 9863 |
+-------+------------------+-----------+
Table 2
IANA has assigned two Error-values for Error-Type=19 (Invalid Operation) within the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの「PCEP-ERROR Object Error Types and Values」レジストリ内の Error-Type=19 (無効な操作) に 2 つの Error-value を次のように割り当てました。
+============+===================+===================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+===================+===================+===========+
| 19 | Invalid Operation | 31: Invalid Color | RFC 9863 |
| | +-------------------+-----------+
| | | 32: Inconsistent | RFC 9863 |
| | | Color | |
+------------+-------------------+-------------------+-----------+
Table 3
A draft version of this document added an error code in the "LSP-ERROR-CODE TLV Error Code Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group, which was also early allocated by the IANA.
この文書のドラフト版では、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの「LSP-ERROR-CODE TLV Error Code Field」レジストリにエラー コードが追加されました。これも IANA によって早期に割り当てられました。
IANA has marked it as deprecated.
IANA はこれを非推奨としてマークしました。
+=======+================================+===========+
| Value | Meaning | Reference |
+=======+================================+===========+
| 9 | Deprecated (Unsupported Color) | RFC 9863 |
+-------+--------------------------------+-----------+
Table 4
[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>.
[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>.
[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>.
[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>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[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>.
[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>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9325] 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>.
[RFC9862] Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng,
S., and H. Bidgoli, "Path Computation Element
Communication Protocol (PCEP) Extensions for Segment
Routing (SR) Policy Candidate Paths", RFC 9862,
DOI 10.17487/RFC9862, October 2025,
<https://www.rfc-editor.org/info/rfc9862>.
[RFC3063] Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS
Loop Prevention Mechanism", RFC 3063,
DOI 10.17487/RFC3063, February 2001,
<https://www.rfc-editor.org/info/rfc3063>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<https://www.rfc-editor.org/info/rfc5886>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[SR-POLICY-YANG]
Saleh, T., Raza, S. K., Zhuang, S., Matsushima, S., and V.
P. Beeram, "YANG Data Model for Segment Routing Policy",
Work in Progress, Internet-Draft, draft-ietf-spring-sr-
policy-yang-06, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-06>.
[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths, and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-39, 17
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-39>.
The authors would like to thank Kaliraj Vairavakkalai, Colby Barth, Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew Stone, Diego Achaval, and Narasimha Kommuri for their review and suggestions.
著者らは、レビューと提案をいただいた Kaliraj Viravakkalai、Colby Barth、Natrajan Venkataraman、Tarek Saad、Dhruv Dhody、Adrian Farrel、Andrew Stone、Diego Achaval、Narasimha Kommuri に感謝します。
The following people have contributed to this document:
この文書には次の人々が貢献しました。
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
Balaji Rajagopalan
Juniper Networks
Email: balajir@juniper.net
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Shaofu Peng
ZTE Corporation
Email: peng.shaofu@zte.com.cn
Mike Koldychev
Ciena Corporation
Email: mkoldych@proton.me
Gyan Mishra
Verizon Communications Inc.
Email: gyan.s.mishra@verizon.com