Internet Engineering Task Force (IETF) 李呈 (C. Li), Ed.
Request for Comments: 9603 华为技术有限公司 (Huawei Technologies)
Category: Standards Track P. Kaladharan
ISSN: 2070-1721 RtBrick Inc
S. Sivabalan
M. Koldychev
Ciena Corporation
Y. Zhu
China Telecom
July 2024
Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm.
セグメントルーティング（SR）を使用して、ソースルーティングパラダイムを使用して、IPv6またはMPLSデータプレーンを使用してネットワークを介してパケットを操縦できます。
An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE).
SRパスは、IGP最短パスツリー（SPT）、明示的な構成、またはパス計算要素（PCE）など、さまざまなメカニズムから導出できます。
Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP.
SRはMPLSとIPv6データプレーンの両方に適用できるため、PCEはMPLSとIPv6データプレーンの両方のSRパスを計算できる必要があります。SR-MPLをサポートするパス計算要素通信プロトコル（PCEP）拡張とメカニズムが定義されています。このドキュメントでは、PCEP内のIPv6データプレーンのSRをサポートするために必要な拡張機能の概要を説明します。
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/rfc9603.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9603で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
2. Terminology
3. Overview of PCEP Operation in SRv6 Networks
3.1. Operation Overview
3.2. SRv6-Specific PCEP Message Extensions
4. Object Formats
4.1. The OPEN Object
4.1.1. The SRv6 PCE Capability sub-TLV
4.2. The RP/SRP Object
4.3. ERO
4.3.1. SRv6-ERO Subobject
4.3.1.1. SID Structure
4.3.1.2. Order of the Optional Fields
4.4. RRO
4.4.1. SRv6-RRO Subobject
5. Procedures
5.1. Exchanging the SRv6 Capability
5.2. ERO Processing
5.2.1. SRv6 ERO Validation
5.2.2. Interpreting the SRv6-ERO
5.3. RRO Processing
6. Security Considerations
7. Manageability Considerations
7.1. Control of Function and Policy
7.2. Information and Data Models
7.3. Liveness Detection and Monitoring
7.4. Verify Correct Operations
7.5. Requirements on Other Protocols
7.6. Impact on Network Operations
8. IANA Considerations
8.1. PCEP ERO and RRO Subobjects
8.2. New SRv6-ERO NAI Type Registry
8.3. New SRv6-ERO Flag Registry
8.4. LSP-ERROR-CODE TLV
8.5. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
8.6. SRv6 PCE Capability Flags
8.7. New Path Setup Type
8.8. ERROR Objects
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
As defined in [RFC8402], Segment Routing (SR) architecture allows the source node to steer a packet through a path indicated by an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based, and it can have a semantic local to an SR node or global within an SR domain.
[RFC8402]で定義されているように、セグメントルーティング（SR）アーキテクチャにより、ソースノードは、「セグメント」と呼ばれる順序付けられた命令リストで示されたパスにパケットを導くことができます。セグメントは、トポロジーまたはサービスベースの任意の命令を表すことができ、SRドメイン内のSRノードまたはグローバルのセマンティックローカルを持つことができます。
[RFC5440] describes Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a PCE or between a pair of PCEs. A PCE or a PCC operating as a PCE (in a hierarchical PCE environment) computes paths for MPLS Traffic Engineering Label Switched Paths (MPLS-TE LSPs) based on various constraints and optimization criteria.
[RFC5440]は、パス計算クライアント（PCC）とPCEまたはPCEの間の通信のためのパス計算要素通信プロトコル（PCEP）を説明しています。PCEまたはPCCは、PCE（階層PCE環境で）として動作します。MPLSトラフィックエンジニアリングラベルスイッチ付きパス（MPLS-TE LSP）のパスを、さまざまな制約と最適化基準に基づいて計算します。
[RFC8231] specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide synchronization of LSP state between a PCC and a PCE or between a pair of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PCE, and controlling the setup and path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended for an operational model in which LSPs are configured on the PCC, and control over them is delegated to the PCE.
[RFC8231]は、ステートフルPCEが[RFC4657]に準拠してネットワークパスを計算および推奨し、MPLS-TE LSPのオブジェクトとTLVを定義できるPCEPへの拡張機能を指定します。ステートフルPCEP拡張は、PCCとPCC間、またはPCEのペア間のLSP状態の同期、LSPコントロールの委任、PCCからPCCへのLSP状態の報告、PCEからのLSPのセットアップとパスルーティングの制御を提供しますPCCへ。ステートフルなPCEP拡張機能は、LSPがPCCで構成され、それらの制御がPCEに委任される運用モデルを対象としています。
A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in [RFC8281]. As per [RFC8664], it is possible to use a stateful PCE for computing one or more SR-TE paths taking into account various constraints and objective functions. Once a path is computed, the stateful PCE can initiate an SR-TE path on a PCC using PCEP extensions specified in [RFC8281] and the SR-specific PCEP extensions specified in [RFC8664].
ステートフルPCEまたはステートフルPCEを使用したコントローラーからの要求に基づいて、PCCでLSPを動的に開始するメカニズムは、[RFC8281]で指定されています。[RFC8664]によると、さまざまな制約と目的関数を考慮して、1つ以上のSR-TEパスを計算するためにStateful PCEを使用することができます。パスが計算されると、ステートフルPCEは[RFC8281]で指定されたPCEP拡張機能と[RFC8664]で指定されたSR固有のPCEP拡張機能を使用して、PCCでSR-TEパスを開始できます。
[RFC8664] specifies PCEP extensions for supporting an SR-TE LSP for the MPLS data plane. This document extends [RFC8664] to support SR for the IPv6 data plane. Additionally, using procedures described in this document, a PCC can request an SRv6 path from either a stateful or stateless PCE. This specification relies on the PATH-SETUP-TYPE TLV and procedures specified in [RFC8408].
[RFC8664]は、MPLSデータプレーンのSR-TE LSPをサポートするためのPCEP拡張機能を指定します。このドキュメントは[RFC8664]を拡張して、IPv6データプレーンのSRをサポートします。さらに、このドキュメントで説明されている手順を使用して、PCCはステートフルまたはステートレスPCEからSRV6パスを要求できます。この仕様は、[RFC8408]で指定されたパスセットアップ型TLVと手順に依存しています。
This specification provides a mechanism for a network controller (acting as a PCE) to instantiate candidate paths for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more information on the SR Policy architecture, see [RFC9256], which applies to both SR-MPLS and SRv6.
この仕様は、PCEPを使用してヘッドエンドノード（PCCとして機能する）にSRポリシーの候補パスをインスタンス化するためのネットワークコントローラー（PCEとして機能する）のメカニズムを提供します。SRポリシーアーキテクチャの詳細については、SR-MPLSとSRV6の両方に適用される[RFC9256]を参照してください。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP, PCEP Peer.
このドキュメントでは、[RFC5440]で定義されている次の用語を使用します：PCC、PCE、PCEP、PCEPピア。
This document uses the following terms defined in [RFC8051]: Stateful PCE, Delegation.
このドキュメントでは、[RFC8051]で定義されている次の用語を使用しています：ステートフルPCE、委任。
Further, the following terms are used in the document:
さらに、次の用語がドキュメントで使用されています。
MSD:
MSD:
Maximum SID Depth
最大SID深度
PST:
PST:
Path Setup Type
パスセットアップタイプ
SR:
SR:
Segment Routing
セグメントルーティング
SID:
SID:
Segment Identifier
セグメント識別子
SRv6:
SRV6：
Segment Routing over IPv6 data plane
IPv6データプレーンのセグメントルーティング
SRH:
SRH:
IPv6 Segment Routing Header [RFC8754]
IPv6セグメントルーティングヘッダー[RFC8754]
SRv6 path:
SRV6パス：
IPv6 Segment List (A list of IPv6 SIDs representing a path in IPv6 SR domain in the context of this document.)
IPv6セグメントリスト（このドキュメントのコンテキストでIPv6 SRドメインのパスを表すIPv6 SIDのリスト。）
Further, note that the term "LSP" used in the PCEP specifications would be equivalent to an SRv6 path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP.
さらに、PCEP仕様で使用される「LSP」という用語は、PCEPでSRV6をサポートするというコンテキストでSRV6パス（SRV6セグメントのリストとして表される）に相当することに注意してください。
Basic operations for PCEP speakers are built on [RFC8664].
PCEPスピーカーの基本操作は[RFC8664]に基づいて構築されています。
In PCEP messages, route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. [RFC8664] defined a new ERO subobject denoted by "SR-ERO subobject" that is capable of carrying a SID as well as the identity of the node/ adjacency represented by the SID for SR-MPLS. SR-capable PCEP speakers can generate and/or process such an ERO subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP Initiate Request message (PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in [RFC8231]. [RFC8664] also defines a new Reported Route Object (RRO), called "SR-RRO", to represent the SID list that was applied by the PCC, which is the actual path taken by the LSP in SR-MPLS network.
PCEPメッセージでは、ルート情報は、一連のサブオブジェクトで構成される明示的なルートオブジェクト（ERO）に掲載されています。[RFC8664]は、SR-MPLSのSIDが表すノード/隣接のアイデンティティと同様に、SIDを運ぶことができる「Sr-Ero Subobject」で示される新しいEROサブオブジェクトを定義しました。SR対応PCEPスピーカーは、そのようなEROサブオブジェクトを生成および/または処理できます。SR-EROサブオブジェクトを含むEROは、[RFC5440]で定義されたPCEPパス計算応答（PCREP）メッセージに含めることができます。（PCUPD）およびPCEP LSP状態レポート（PCRPT）メッセージ[RFC8231]で定義されています。[RFC8664]は、「SR-RRO」と呼ばれる新しい報告されたルートオブジェクト（RRO）を定義して、SR-MPLSネットワークのLSPが実際に取るパスであるPCCによって適用されたSIDリストを表します。
The SRv6 paths computed by a PCE can be represented as an ordered list of SRv6 segments. This document defines new subobjects "SRv6-ERO" and "SRv6-RRO" in the ERO and the RRO, respectively, to carry the SRv6 SID. SRv6-capable PCEP speakers MUST be able to generate and/or process these subobjects.
PCEによって計算されたSRV6パスは、SRV6セグメントの順序付けられたリストとして表すことができます。このドキュメントでは、EROとRROの新しいサブオブジェクト「SRV6-ERO」と「SRV6-RRO」をそれぞれ定義して、SRV6 SIDを運びます。SRV6対応のPCEPスピーカーは、これらのサブオブジェクトを生成および/または処理できる必要があります。
When a PCEP session between a PCC and a PCE is established, both PCEP speakers exchange their capabilities to indicate their ability to support SRv6-specific functionality as described in Section 4.1.1.
PCCとPCEの間のPCEPセッションが確立されると、両方のPCEPスピーカーが能力を交換して、セクション4.1.1で説明されているようにSRV6固有の機能をサポートする能力を示します。
In summary, this document defines:
要約すると、このドキュメントは次のように定義しています。
* a new PCEP capability for SRv6,
* SRV6の新しいPCEP機能、
* a new subobject SRv6-ERO in ERO,
* EROの新しいサブオブジェクトSRV6-ERO、
* a new subobject SRv6-RRO in RRO, and
* RROの新しいサブオブジェクトSRV6-RRO、および
* a new Path Setup type (PST) [RFC8408], carried in the PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs.
* パスセットアップタイプおよびパスセットアップタイプの習慣TLVで運ばれる新しいパスセットアップタイプ（PST）[RFC8408]。
In SR networks, an SR source node [RFC8754] steers a packet into an SR Policy resulting in a segment list.
SRネットワークでは、SRソースノード[RFC8754]がパケットをSRポリシーに導き、セグメントリストになります。
When SR leverages the IPv6 data plane (i.e., SRv6), the PCEP procedures and mechanisms are extended in this document.
SRがIPv6データプレーン（つまり、SRV6）をレバレッジすると、このドキュメントではPCEP手順とメカニズムが拡張されます。
This document describes the extension to support SRv6 in PCEP. A PCC or PCE indicates its ability to support SRv6 during the PCEP session initialization phase via a new SRv6-PCE-CAPABILITY sub-TLV (see details in Section 4.1.1).
このドキュメントでは、PCEPのSRV6をサポートする拡張機能について説明します。PCCまたはPCEは、新しいSRV6-PCEキャピールサブTLVを介してPCEPセッション初期化フェーズ中にSRV6をサポートする能力を示しています（セクション4.1.1の詳細を参照）。
As defined in [RFC5440], a PCEP message consists of a common header followed by a variable-length body made up of mandatory and/or optional objects. This document does not require any changes in the format of PCReq and PCRep messages specified in [RFC5440], the PCInitiate message specified in [RFC8281], or PCRpt and PCUpd messages specified in [RFC8231]. However, PCEP messages pertaining to SRv6 MUST include PATH-SETUP-TYPE TLV in the Request Parameters (RP) or Stateful PCE Request Parameters (SRP) object to clearly identify that SRv6 is intended.
[RFC5440]で定義されているように、PCEPメッセージは、必須オブジェクトおよび/またはオプションのオブジェクトで構成される可変長ボディが続く共通ヘッダーで構成されます。このドキュメントでは、[RFC5440]で指定されたPCREQおよびPCREPメッセージの形式、[RFC8281]で指定されたPCINITIATEメッセージ、または[RFC8231]で指定されたPCRPTおよびPCUPDメッセージの変更を必要としません。ただし、SRV6に関連するPCEPメッセージは、Request Parameters（RP）またはStateful PCE Requestパラメーター（SRP）オブジェクトにPath-SetupタイプTLVを含めて、SRV6が意図されていることを明確に識別する必要があります。
This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, as follows:
このドキュメントでは、次のように、SRV6の新しいパスセットアップタイプ（PST）[RFC8408]を定義します。
PST=3:
PST = 3：
Path is set up using SRv6.
SRV6を使用してパスがセットアップされます。
A PCEP speaker indicates its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST (value 3) included in the PST list.
PCEPスピーカーは、PSTリストに含まれるこの新しいPST（値3）を使用して、オープンオブジェクトにパスセットアップ型能力TLVを送信することにより、このドキュメントで説明されている関数のサポートを示します。
This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. If a PCEP speaker includes PST=3 in the PST list of the PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST also include the SRv6- PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. For further error handling, please see Section 5.
このドキュメントでは、SRV6-PCEキャピールサブTLVも定義されています。PCEPスピーカーは、このサブTLVを使用して、SRV6機能に関する情報を交換します。PCEPスピーカーに、PathSetup-Type-Capability TLVのPSTリストにPST = 3が含まれている場合、パスセットアップタイプ容量TLV内にSRV6-PCEキャピールサブTLVを含める必要があります。さらにエラー処理については、セクション5を参照してください。
The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in Figure 1.
SRV6-PCEキャピールサブTLVの形式を図1に示します。
0 1 2 3
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=27 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6-PCE-CAPABILITY Sub-TLV Format
図1：SRV6-PCEキャピールサブTLV形式
The code point for the TLV type is 27, and the format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the sub-TLV is composed of 2 octets for the type, 2 octets specifying the length, and a Value field. When set to 27, the Type field identifies the SRv6-PCE-CAPABILITY sub-TLV, and the presence of the sub-TLV indicates the support for the SRv6 paths in PCEP. The Length field defines the length of the value portion in octets. The sub-TLV is padded to 4-octet alignment, and padding is not included in the Length field. The (MSD-Type,MSD-Value) pairs are OPTIONAL. The number of (MSD-Type,MSD-Value) pairs can be determined by the Length field of the TLV.
TLVタイプのコードポイントは27であり、形式は[RFC5440]で定義されているPCEP TLV形式に準拠しています。つまり、Sub-TLVは、タイプの2オクテット、長さを指定する2オクテット、値フィールドで構成されています。27に設定すると、タイプフィールドはSRV6-PCEキャピールサブTLVを識別し、Sub-TLVの存在はPCEPのSRV6パスのサポートを示します。長さフィールドは、オクテットの値部分の長さを定義します。Sub-TLVは4-OCTETアライメントにパッドで埋められており、パディングは長さフィールドに含まれていません。（MSDタイプ、MSD-Value）ペアはオプションです。（MSDタイプ、MSD-Value）ペアの数は、TLVの長さフィールドによって決定できます。
The value is comprised of:
値は次のとおりです。
* Reserved: 2 octets; this field MUST be set to 0 on transmission and ignored on receipt.
* 予約済み：2オクテット。このフィールドは、送信時に0に設定し、受領時に無視する必要があります。
* Flags: 2 octets; one bit is currently assigned in Section 8.6
* フラグ：2オクテット。現在、セクション8.6に1つのビットが割り当てられています
- N bit (bit position 14): A PCC sets this flag bit to 1 to indicate that it is capable of resolving a Node or Adjacency Identifier (NAI) to an SRv6-SID.
- Nビット（ビット位置14）：PCCは、このフラグビットを1に設定して、ノードまたは隣接識別子（NAI）をSRV6-SIDに解決できることを示します。
- Unassigned bits MUST be set to 0 on transmission and ignored on receipt
- 割り当てられていないビットは、送信時に0に設定し、受領時に無視する必要があります
* A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per the IGP MSD Type registry created by [RFC8491] and populated with SRv6 MSD types as per [RFC9352], and where MSD-Value (1 octet) is as per [RFC8491].
* （MSDタイプ、MSD-Value）のペア：MSDタイプ（1 OCTET）は、[RFC8491]によって作成され、[RFC9352]に従ってSRV6 MSDタイプを入力し、MSD-のようにSRV6MSDタイプを入力した場合、MSD-MSD-値（1オクテット）は[RFC8491]に従っています。
The SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV conveys the SRv6 capabilities of the PCEP speaker alone. However, when it comes to the computation of an SR Policy for the SRv6 data plane, the SRv6 MSD capabilities of the intermediate SRv6 Endpoint node and the tail-end node also need to be considered to ensure those midpoints are able to correctly process their segments and for the tail-end to dispose of the SRv6 encapsulation. The SRv6 MSD capabilities of other nodes might be learned as part of the topology information via the Border Gateway Protocol - Link State (BGP-LS) [RFC9514] or via PCEP if the PCE also happens to have PCEP sessions with those nodes.
SRV6-PCEキャピールSub-TLVを介して宣伝されているSRV6 MSD情報は、PCEPスピーカーのみのSRV6機能を伝えます。ただし、SRV6データプレーンのSRポリシーの計算に関しては、中間SRV6エンドポイントノードとテールエンドノードのSRV6MSD機能も考慮する必要があります。そして、テールエンドがSRV6カプセル化を処分するために。他のノードのSRV6 MSD機能は、Border Gateway Protocol -Link State（BGP -LS）[RFC9514]を介してトポロジ情報の一部として学習される可能性があります。
It is recommended that the SRv6 MSD information not be included in the SRv6-PCE-Capability sub-TLV in deployments where the PCE is able to obtain this via IGP/BGP-LS as part of the topology information.
トポロジー情報の一部としてIGP/BGP-LSを介してPCEがこれを取得できる展開で、SRV6 MSD情報を展開中のSRV6-PCEキャピールサブTLVに含めないことをお勧めします。
This document defines a new Path Setup Type (PST=3) for SRv6. In order to indicate that the path is for SRv6, any RP or SRP object MUST include the PATH-SETUP-TYPE TLV as specified in [RFC8408], where PST is set to 3.
このドキュメントでは、SRV6の新しいパスセットアップタイプ（PST = 3）を定義します。パスがSRV6用であることを示すために、RPまたはSRPオブジェクトには[RFC8408]で指定されているパスセットアップ型TLVを含める必要があります。ここで、PSTは3に設定されています。
In order to support SRv6, a new "SRv6-ERO" subobject is defined for inclusion in the ERO.
SRV6をサポートするために、EROに含めるために新しい「SRV6-ERO」サブオブジェクトが定義されています。
An SRv6-ERO subobject is formatted as shown in Figure 2.
図2に示すように、SRV6-EROサブオブジェクトがフォーマットされています。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=40 | Length | NT | Flags |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SID (conditional) |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, conditional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID Structure (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SRv6-ERO Subobject Format
図2：SRV6-ERO SubObject形式
The fields in the SRv6-ERO subobject are as follows:
SRV6-EROサブオブジェクトのフィールドは次のとおりです。
* The "L" flag: Indicates whether the subobject represents a loose hop (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT overwrite the SID value present in the SRv6-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID values in the received SRv6-ERO based on its local policy.
* 「L」フラグ：サブオブジェクトがルーズホップを表すかどうかを示します（[RFC3209]を参照）。このフラグがゼロに設定されている場合、PCCはSRV6-EROサブオブジェクトに存在するSID値を上書きしてはなりません。それ以外の場合、PCCは、そのローカルポリシーに基づいて、受信したSRV6-EROの1つ以上のSID値を拡張または交換する場合があります。
* Type: Indicates the content of the subobject, i.e., when the field is set to 40, the subobject is an SRv6-ERO subobject representing an SRv6 SID.
* タイプ：サブオブジェクトの内容を示します。つまり、フィールドが40に設定されている場合、サブオブジェクトはSRV6 SIDを表すSRV6-EROサブオブジェクトです。
* Length: Contains the total length of the subobject in octets. The Length MUST be at least 24 and MUST be a multiple of 4. An SRv6-ERO subobject MUST contain at least one of an SRv6-SID or an NAI. The S and F bits in the Flags field indicates whether the SRv6-SID or NAI fields are absent.
* 長さ：オクテットのサブオブジェクトの全長が含まれています。長さは少なくとも24でなければならず、4の倍数でなければなりません。SRV6-EROサブオブジェクトには、少なくとも1つのSRV6-SIDまたはNAIが含まれている必要があります。フラグフィールドのSおよびFビットは、SRV6-SIDまたはNAIフィールドが存在しないかどうかを示します。
* NAI Type (NT): Indicates the type and format of the NAI contained in the object body, if any are present. If the F bit is set to one (see below), then the NT field has no meaning and MUST be ignored by the receiver. This document creates a new PCEP SRv6-ERO NAI Types registry in Section 8.2 and allocates the following values:
* NAIタイプ（NT）：オブジェクト本体に含まれるNAIのタイプと形式を示します。Fビットが1に設定されている場合（以下を参照）、NTフィールドには意味がなく、受信機が無視する必要があります。このドキュメントでは、セクション8.2に新しいPCEP SRV6-ERO NAIタイプレジストリを作成し、次の値を割り当てます。
- If NT value is 0, the NAI MUST NOT be included.
- NT値が0の場合、NAIを含めてはなりません。
- When NT value is 2, the NAI is as per the "IPv6 node ID" format defined in [RFC8664], which specifies an IPv6 address. This is used to identify the owner of the SRv6 Identifier. This is optional, as the LOC (the locator portion) of the SRv6 SID serves a similar purpose (when present).
- NT値が2の場合、NAIは[RFC8664]で定義されている「IPv6ノードID」形式に従って、IPv6アドレスを指定します。これは、SRV6識別子の所有者を識別するために使用されます。SRV6 SIDのloc（ロケーター部分）が同様の目的を果たすため、これはオプションです（存在する場合）。
- When NT value is 4, the NAI is as per the "IPv6 adjacency" format defined in [RFC8664], which specify a pair of IPv6 addresses. This is used to identify the IPv6 adjacency and used with the SRv6 Adj-SID.
- NT値が4の場合、NAIは[RFC8664]で定義されている「IPv6隣接」形式に従って、IPv6アドレスのペアを指定します。これは、IPv6の隣接性を識別するために使用され、SRV6 Adj-SIDで使用されます。
- When NT value is 6, the NAI is as per the "link-local IPv6 addresses" format defined in [RFC8664], which specify a pair of (global IPv6 address, interface ID) tuples. It is used to identify the IPv6 adjacency and used with the SRv6 Adj-SID.
- NT値が6の場合、NAIは[Rink-Local IPv6アドレス] [RFC8664]で定義されている「Link-Local IPv6アドレス」形式のように、（グローバルIPv6アドレス、インターフェイスID）タプルを指定します。IPv6の隣接性を識別するために使用され、SRV6 Adj-SIDで使用されます。
* Flags: Used to carry additional information pertaining to the SRv6-SID. This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver. This document creates a new registry SRv6-ERO Flag Field registry in Section 8.3 and allocates the following values.
* フラグ：SRV6-SIDに関する追加情報を携帯するために使用されます。このドキュメントでは、次のフラグビットを定義します。他のビットは、送信者によってゼロに設定する必要があり、受信機は無視する必要があります。このドキュメントでは、セクション8.3に新しいレジストリSRV6-EROフラグフィールドレジストリを作成し、次の値を割り当てます。
- S: When this bit is set to 1, the SRv6-SID value in the subobject body is absent. In this case, the PCC is responsible for choosing the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI that, in this case, MUST be present in the subobject. If the S bit is set to 1, then the F bit MUST be set to zero.
- S：このビットが1に設定されると、サブオブジェクト本体のSRV6-SID値がありません。この場合、PCCはSRV6-SID値を選択する責任があります。たとえば、この場合、SRV6-DBを使用してSR-DBを調べることにより、この場合はSubObjectに存在する必要があります。Sビットが1に設定されている場合、Fビットはゼロに設定する必要があります。
- F: When this bit is set to 1, the NAI value in the subobject body is absent. The F bit MUST be set to 1 if NT=0; otherwise, it MUST be set to zero. The S and F bits MUST NOT both be set to 1.
- F：このビットが1に設定されると、サブオブジェクト本体のNAI値がありません。nt = 0の場合、fビットを1に設定する必要があります。それ以外の場合は、ゼロに設定する必要があります。SとFビットの両方を1に設定してはなりません。
- T: When this bit is set to 1, the SID Structure value in the subobject body is present. The T bit MUST be set to 0 when the S bit is set to 1. If the T bit is set when the S bit is set, the T bit MUST be ignored. Thus, the T bit indicates the presence of an optional 8-byte SID Structure when SRv6 SID is included. The SID Structure is defined in Section 4.3.1.1.
- T：このビットが1に設定されると、サブオブジェクトボディのSID構造値が存在します。Sビットが1に設定されている場合、tビットを0に設定する必要があります。Sビットが設定されたときにtビットが設定されている場合、tビットは無視する必要があります。したがって、Tビットは、SRV6 SIDが含まれている場合のオプションの8バイトSID構造の存在を示します。SID構造は、セクション4.3.1.1で定義されています。
- V: The "SID verification" bit usage is as per Section 5.1 of [RFC9256]. If a PCC "Verification fails" for a SID, it MUST report this error by including the LSP-ERROR-CODE TLV with LSP Error-value "SID Verification fails" in the LSP object in the PCRpt message to the PCE.
- V：「SID検証」ビットの使用法は、[RFC9256]のセクション5.1に従っています。SIDのPCCが「検証に失敗する」場合、PCRPTメッセージのLSPオブジェクトにLSPエラー値「SID検証」を含むLSP-Error-Code TLVをPCEにPCCEに含めることにより、このエラーを報告する必要があります。
* Reserved: MUST be set to zero while sending and ignored on receipt.
* 予約済み：送信中にゼロに設定し、受領時に無視する必要があります。
* Endpoint Behavior: A 16-bit field representing the behavior associated with the SRv6 SIDs. This information is optional, but providing it is recommended whenever possible. It could be used for maintainability and diagnostic purposes. If behavior is not known, value "0xFFFF" as defined in the "SRv6 Endpoint Behaviors" registry is used [RFC8986].
* エンドポイントの動作：SRV6 SIDSに関連する動作を表す16ビットフィールド。この情報はオプションですが、可能な限りお勧めします。保守性と診断の目的で使用できます。動作が知られていない場合、「SRV6エンドポイント動作」レジストリで定義されている値「0xffff」が使用されます[RFC8986]。
* SRv6 SID: SRv6 Identifier is a 128-bit value representing the SRv6 segment.
* SRV6 SID：SRV6識別子は、SRV6セグメントを表す128ビット値です。
* NAI: The NAI associated with the SRv6-SID. The NAI's format depends on the value in the NT field and is described in [RFC8664].
* NAI：SRV6-SIDに関連するNAI。NAIの形式は、NTフィールドの値に依存し、[RFC8664]で説明されています。
At least one SRv6-SID or the NAI MUST be included in the SRv6-ERO subobject, and both MAY be included.
少なくとも1つのSRV6-SIDまたはNAIをSRV6-EROサブオブジェクトに含める必要があり、両方を含める必要があります。
The SID Structure is an optional part of the SR-ERO subobject, as described in Section 4.3.1.
SID構造は、セクション4.3.1で説明されているように、SR-EROサブオブジェクトのオプションの部分です。
[RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). A locator may be represented as B:N where B is the SRv6 SID locator block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID called "locator node".
[RFC8986]は、SRV6 SIDをloc：funct：argで構成されるものとして定義します。ここで、ロケーター（loc）がlの最も重要なビットでエンコードされ、その後、fits of function（funce）とbits of arguments（arg）が続きます。）。aロケーターはb：nとして表される場合があります。ここで、bはsrv6 sidロケーターブロック（オペレーターによってsrv6 sidsに割り当てられたIPv6プレフィックス）、nは「ロケーターノード」と呼ばれるSIDをインスタンス化する親ノードの識別子です。
The SID Structure is formatted as shown in Figure 3.
SID構造は、図3に示すようにフォーマットされています。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SID Structure Format
図3：SID構造形式
Where:
ただし：
* LB Length: 1 octet; SRv6 SID Locator Block length in bits
* LBの長さ：1オクテット。srv6 sidロケーターブロック長さのブロック長
* LN Length: 1 octet; SRv6 SID Locator Node length in bits
* LN長：1オクテット。SRV6 SIDロケーターノード長さのビット
* Fun. Length: 1 octet; SRv6 SID Function length in bits
* 楽しい。長さ：1オクテット。SRV6 SID関数のビットの長さ
* Arg. Length: 1 octet; SRv6 SID Arguments length in bits
* arg。長さ：1オクテット。srv6 sid bits in bitsの長さ
The sum of all four sizes in the SID Structure must be less than or equal to 128 bits. If the sum of all four sizes advertised in the SID Structure is larger than 128 bits, the corresponding SRv6 SID MUST be considered invalid and a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 37 ("Invalid SRv6 SID Structure") is returned.
SID構造の4つのサイズすべての合計は、128ビット以下でなければなりません。SID構造で宣伝されている4つのサイズすべての合計が128ビットを超えている場合、対応するSRV6 SIDは無効と見なされ、エラータイプ= 10（「無効なオブジェクトの受信」）およびエラー-Value =37（「無効なSRV6 SID構造」）が返されます。
* Reserved: MUST be set to zero while sending and ignored on receipt.
* 予約済み：送信中にゼロに設定し、受領時に無視する必要があります。
* Flags: Currently no flags are defined.
* フラグ：現在、フラグは定義されていません。
* Unassigned bits must be set to zero while sending and ignored on receipt.
* 送信中に、未割り当てビットをゼロに設定し、受領時に無視する必要があります。
The SRv6 SID Structure provides the detailed encoding information of an SRv6 SID, which is helpful in the use cases that require the SRv6 SID structure to be known. When a PCEP speaker receives the SRv6 SID and its structure information, the SRv6 SID can be parsed based on the SRv6 SID Structure and/or possible local policies. The SRv6 SID Structure could be used by the PCE for ease of operations and monitoring. For example, this information could be used for validation of SRv6 SIDs being instantiated in the network and checked for conformance with the SRv6 SID allocation scheme chosen by the operator as described in Section 3.2 of [RFC8986]. In the future, PCE might also be utilized to verify and automate the security of the SRv6 domain by provisioning filtering rules at the domain boundaries as described in Section 5 of [RFC8754]. The details of these potential applications are outside the scope of this document.
SRV6 SID構造は、SRV6 SIDの詳細なエンコード情報を提供します。これは、SRV6 SID構造を既知で必要とするユースケースで役立ちます。PCEPスピーカーがSRV6 SIDとその構造情報を受信すると、SRV6 SID構造および/または可能なローカルポリシーに基づいてSRV6 SIDを解析できます。SRV6 SID構造は、操作と監視を容易にするためにPCEによって使用できます。たとえば、この情報は、ネットワークにインスタンス化されているSRV6 SIDの検証に使用でき、[RFC8986]のセクション3.2で説明されているように、オペレーターが選択したSRV6 SID割り当てスキームとの適合を確認できます。将来的には、[RFC8754]のセクション5で説明されているように、ドメイン境界でフィルタリングルールをプロビジョニングすることにより、SRV6ドメインのセキュリティを検証および自動化するためにPCEを利用することもできます。これらの潜在的なアプリケーションの詳細は、このドキュメントの範囲外です。
The optional elements in the SRv6-ERO subobject, i.e., SRv6 SID, NAI, and the SID Structure, MUST be encoded in the order as depicted in Figure 2. The presence or absence of each of them is indicated by the respective flags, i.e., S flag, F flag, and T flag.
SRV6-EROサブオブジェクトのオプション要素、つまりSRV6 SID、NAI、およびSID構造は、図2に示すように順序でエンコードする必要があります。それぞれの存在または不在は、それぞれのフラグ、つまり、それぞれのフラグによって示されます。、Sフラグ、Fフラグ、およびTフラグ。
In order to ensure future compatibility, any optional elements added to the SRv6-ERO subobject in the future must specify their order and request that the Internet Assigned Numbers Authority (IANA) allocate a flag to indicate their presence from the subregistry created in Section 8.3.
将来の互換性を確保するために、将来SRV6-EROサブオブジェクトに追加されたオプションの要素は、順序を指定し、インターネットが割り当てられた番号局（IANA）がセクション8.3で作成されたサブレジストリからの存在を示すためにフラグを割り当てることを要求する必要があります。
In order to support SRv6, a new "SRv6-RRO" subobject is defined for inclusion in the RRO.
SRV6をサポートするために、RROに含めるために新しい「SRV6-RRO」サブオブジェクトが定義されています。
A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per [RFC8231]. The RRO on this message represents the SID list that was applied by the PCC, that is, the actual path taken. The procedures of [RFC8664] with respect to the RRO apply equally to this specification without change.
PCCは、[RFC8231]ごとにPCRPTメッセージを送信することにより、PCEへのSRV6パスを報告します。このメッセージのRROは、PCCによって適用されたSIDリスト、つまり実際のパスを表します。RROに関する[RFC8664]の手順は、変更なしでこの仕様に等しく適用されます。
An RRO contains one or more subobjects called "SRv6-RRO subobjects", whose format is shown in Figure 4.
RROには、「SRV6-RROサブオブジェクト」と呼ばれる1つ以上のサブオブジェクトが含まれており、その形式が図4に示されています。
0 1 2 3
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=40 | Length | NT | Flags |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SID(optional) |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID Structure (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6-RRO Subobject Format
図4：SRV6-RROサブオブジェクト形式
The format of the SRv6-RRO subobject is the same as that of the SRv6-ERO subobject but without the L flag.
SRV6-RROサブオブジェクトの形式は、Lフラグがありませんが、SRV6-EROサブオブジェクトの形式と同じです。
The V flag has no meaning in the SRv6-RRO and is ignored on receipt at the PCE.
VフラグはSRV6-RROでは意味がなく、PCEでの受領時に無視されます。
The ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as per [RFC8664].
PCRPTメッセージにおけるPCCによるSRV6-RROサブオブジェクトの順序付けは、[RFC8664]に従って残ります。
The ordering of optional elements in the SRv6-RRO subobject is the same as described in Section 4.3.1.2.
SRV6-RROサブオブジェクトのオプション要素の順序付けは、セクション4.3.1.2で説明されているものと同じです。
A PCC indicates that it is capable of supporting the head-end functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCE. A PCE indicates that it is capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCC.
PCCは、SRV6-PCEキャピールサブTLVをPCEに送信するオープンメッセージに含めることにより、SRV6のヘッドエンド関数をサポートできることを示しています。PCEは、PCCに送信するOpenメッセージにSRV6-PCEキャピールサブTLVを含めることにより、SRV6パスを計算できることを示しています。
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is absent, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 34 ("Missing PCE-SRv6-CAPABILITY sub-TLV") and MUST then close the PCEP session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with an SRv6-PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=3, then the PCEP speaker MUST ignore the SRv6-PCE-CAPABILITY sub-TLV.
PCEPスピーカーがPST = 3を含むPSTリストを備えたパスセットアップタイプの能力TLVを受信したが、SRV6-PCEキャピールサブTLVが存在しない場合、PCEPスピーカーはエラータイプ=でPCERRメッセージを送信する必要があります。10（「無効なオブジェクトの受信」）およびエラー値= 34（ "PCE-SRV6-capability sub-tlvの欠落"）。その後、PCEPセッションを閉じる必要があります。PCEPスピーカーがSRV6-PCEキャピールサブTLVを備えたパスセットアップタイプの能力TLVを受信しますが、PSTリストにはPST = 3が含まれていない場合、PCEPスピーカーはSRV6-PCE担当性サブサブサブを無視する必要があります。TLV。
In case the MSD-Type in the SRv6-PCE-CAPABILITY sub-TLV received by the PCE does not correspond to one of the SRv6 MSD types, the PCE MUST respond with a PCErr message (Error-Type = 1 ("PCEP session establishment failure") and Error-Value = 1 ("reception of an invalid Open message or a non Open message.")).
PCEで受信したSRV6-PCEキャピールサブTLVのMSDタイプがSRV6 MSDタイプの1つに対応していない場合、PCEはPCERRメッセージで応答する必要があります（ERROR-Type = 1（ "PCEPセッションの確立障害 "）およびerror-value = 1（"無効なオープンメッセージまたは非開いたメッセージの受信。 "））。
Note that the (MSD-Type,MSD-Value) pair exchanged via the SRv6-PCE-CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the sender PCC node only. However, if a PCE learns these via alternate mechanisms, e.g., routing protocols [RFC9352], then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE learns any other SRv6 MSD types that may be defined in the future via alternate mechanisms, it MUST use those values regardless of the values exchanged in the SRv6-PCE-CAPABILITY sub-TLV.
SRV6-PCE-capability sub-TLVを介して交換された（MSDタイプ、MSD-Value）ペアは、送信者PCCノードのSRV6 SIDの賦課制限を示すことに注意してください。ただし、PCEが代替メカニズム、たとえばルーティングプロトコル[RFC9352]を介してこれらを学習すると、SRV6-PCEキャピールサブTLVの値を無視します。さらに、PCEが代替メカニズムを介して将来定義される可能性のある他のSRV6 MSDタイプを学習するときはいつでも、SRV6-PCEの能力サブTLVで交換される値に関係なく、それらの値を使用する必要があります。
During path computation, a PCE must consider the MSD information of all the nodes along the path instead of only the MSD information of the ingress PCC since a packet may be dropped on any node in a forwarding path because of the SID depth exceeding the MSD of the node. The MSD capabilities of all SR nodes along the path can be learned as part of the topology information via IGP/BGP-LS or via PCEP if the PCE also happens to have PCEP sessions with those nodes.
パス計算中、PCEは、SIDの深さがMSDを超えるため、転送パスの任意のノードにパケットがドロップされる可能性があるため、イングレスPCCのMSD情報のみではなく、パスに沿ったすべてのノードのMSD情報を考慮する必要があります。ノード。パスに沿ったすべてのSRノードのMSD機能は、IGP/BGP-LSを介したトポロジ情報の一部として、またはPCEがたまたまこれらのノードとPCEPセッションを持っている場合にPCEPを介して学習できます。
A PCE MUST NOT send SRv6 paths that exceed the SRv6 MSD capabilities of the PCC. If a PCC needs to modify the SRv6 MSD value signaled via the Open message, it MUST close the PCEP session and re-establish it with the new value. If the PCC receives an SRv6 path that exceeds its SRv6 MSD capabilities, the PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 40 ("Unsupported number of SRv6-ERO subobjects").
PCEは、PCCのSRV6 MSD機能を超えるSRV6パスを送信してはなりません。PCCがオープンメッセージを介して信号を送信されたSRV6 MSD値を変更する必要がある場合、PCEPセッションを閉じて新しい値で再確立する必要があります。PCCがSRV6 MSD機能を超えるSRV6パスを受信した場合、PCCはエラータイプ= 10（「無効なオブジェクトの受信」）およびエラー値= 40（「サポートされていないSRV6-EROの数）でPCERRメッセージを送信する必要があります。サブオブジェクト "）。
The N flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-CAPABILITY sub-TLV are meaningful only in the Open message sent to a PCE. As such, the flags MUST be set to zero and a (MSD-Type,MSD-Value) pair MUST NOT be present in the SRv6-PCE-CAPABILITY sub-TLV in an Open message sent to a PCC. Similarly, a PCC MUST ignore flags and any (MSD-Type,MSD-Value) pair in a received Open message. If a PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received.
SRV6-PCEキャピールサブTLV内のNフラグと（MSDタイプ、MSD-Value）ペアは、PCEに送信された開いたメッセージでのみ意味があります。そのため、フラグはゼロに設定する必要があり、PCCに送信されたオープンメッセージでSRV6-PCEキャピールサブTLVに（MSDタイプ、MSD-Value）ペアが存在しないでください。同様に、PCCは、受信したオープンメッセージでフラグと任意の（MSDタイプ、MSD-Value）ペアを無視する必要があります。PCEがオープンメッセージで複数のSRV6-PCEキャピールサブTLVを受信した場合、最初のサブTLVのみを受信します。
The processing of ERO remains unchanged in accordance with both [RFC5440] and [RFC8664].
EROの処理は、[RFC5440]と[RFC8664]の両方に従って変化しません。
If a PCC does not support the SRv6 PCE Capability and thus cannot recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond according to the rules for a malformed object as described in [RFC5440].
PCCがSRV6 PCE機能をサポートせず、したがってSRV6-EROまたはSRV6-RROサブオブジェクトを認識できない場合、[RFC5440]で説明されている不正なオブジェクトのルールに従って応答する必要があります。
On receiving an SRv6-ERO, a PCC MUST validate that the Length field, the S bit, the F bit, the T bit, and the NT field are consistent, as follows:
SRV6-EREを受信すると、PCCは、長さフィールド、Sビット、Fビット、Tビット、およびNTフィールドが次のように一貫していることを検証する必要があります。
* If NT=0, the F bit MUST be 1, the S bit MUST be zero, and the Length MUST be 24.
* nt = 0の場合、fビットは1でなければならず、sビットはゼロでなければならず、長さは24でなければなりません。
* If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 24; otherwise, the Length MUST be 40.
* nt = 2の場合、fビットはゼロでなければなりません。Sビットが1の場合、長さは24でなければなりません。それ以外の場合、長さは40でなければなりません。
* If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 40; otherwise, the Length MUST be 56.
* nt = 4の場合、fビットはゼロでなければなりません。Sビットが1の場合、長さは40でなければなりません。それ以外の場合、長さは56でなければなりません。
* If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 48; otherwise, the Length MUST be 64.
* nt = 6の場合、fビットはゼロでなければなりません。Sビットが1の場合、長さは48でなければなりません。それ以外の場合、長さは64でなければなりません。
* If the T bit is 1, then the S bit MUST be zero.
* tビットが1の場合、Sビットはゼロでなければなりません。
If a PCC finds that the NT field, Length field, S bit, F bit, and T bit are not consistent, it MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object").
PCCがNTフィールド、長さフィールド、sビット、fビット、およびtビットが一貫していないことを発見した場合、ERO全体が無効であると考える必要があり、error-type = 10（ "無効の受信オブジェクト "）およびerror-value = 11（"奇形オブジェクト "）。
If a PCC does not recognize or support the value in the NT field, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 41 ("Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject").
PCCがNTフィールドの値を認識またはサポートしていない場合、EROの無効な全体を考慮し、Error-Type = 10（「無効なオブジェクトの受信」）およびError-Value = 41（ "でPCERRメッセージを送信する必要があります。SRV6-ERO/SRV6-RROサブオブジェクトのサポートされていないNAIタイプ "）。
If a PCC receives an SRv6-ERO subobject in which the S and F bits are both set to 1 (that is, both the SID and NAI are absent), it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 42 ("Both SID and NAI are absent in the SRv6-ERO subobject").
PCCがSRV6-EROサブオブジェクトを受信している場合、SとFビットが両方とも1に設定されている場合（つまり、SIDとNAIの両方が存在しない）、ERO無効を考慮し、エラータイプでPCERRメッセージを送信する必要があります。= 10（「無効なオブジェクトの受信」）およびエラー値= 42（ "SIDとNAIの両方がSRV6-ERO Subobjectに存在しない"）。
If a PCC receives an SRv6-ERO subobject in which the S bit is set to 1 and the F bit is set to zero (that is, the SID is absent and the NAI is present), but the PCC does not support NAI resolution, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported parameter").
PCCがsビットが1に設定され、fビットがゼロに設定されているSRV6-EROサブオブジェクトを受信した場合（つまり、SIDは存在しない、NAIは存在します）、PCCはNAI解像度をサポートしていません、ERO全体を無効にし、ERROR-Type = 4（ "サポートされていないオブジェクト"）およびエラー-Value = 4（ "サポートされていないパラメーター"）を使用してPCERRメッセージを送信する必要があります。
If a PCC detects that the subobjects of an ERO are a mixture of SRv6-ERO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 43 ("ERO mixes SRv6-ERO subobjects with other subobject types").
PCCがEROのサブオブジェクトがSRV6-EROサブオブジェクトと他のタイプのサブオブジェクトの混合物であることを検出する場合、エラータイプ= 10（「無効なオブジェクトの受信」）とエラー値でPCERRメッセージを送信する必要があります= 43（ "EROはSRV6-EROサブオブジェクトを他のサブオブジェクトタイプと混合します」）。
In case a PCEP speaker receives an SRv6-ERO subobject, when the PST is not set to 3 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-value = 19 ("Attempted SRv6 when the capability was not advertised").
PCEPスピーカーがSRV6-EROサブオブジェクトを受信した場合、PSTが3に設定されていない場合、またはSRV6-PCEキャピールサブTLVが交換されなかった場合、ERROR-Type = 19でPCERRメッセージを送信する必要があります（「無効な動作」）およびエラー値= 19（ "機能が宣伝されなかったときにsrv6を試みた"））。
If a PCC receives an SRv6 path that exceeds the SRv6 MSD capabilities, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 40 ("Unsupported number of SRv6-ERO subobjects") as per [RFC8664].
PCCがSRV6 MSD機能を超えるSRV6パスを受信した場合、エラータイプ= 10（「無効なオブジェクトの受信」）およびエラー値= 40（ "SRV6-EROサブオブジェクトのサポートされていない数のPCERRメッセージを送信する必要があります。"）[RFC8664]に従って。
The SRv6-ERO contains a sequence of subobjects. According to [RFC9256], each SRv6-ERO subobject in the sequence identifies a segment that the traffic will be directed to, in the order given. That is, the first subobject identifies the first segment the traffic will be directed to, the second SRv6-ERO subobject represents the second segment, and so on.
SRV6-EROには、サブオブジェクトのシーケンスが含まれています。[RFC9256]によると、シーケンス内の各SRV6-EROサブオブジェクトは、指定された順序でトラフィックが向けられるセグメントを識別します。つまり、最初のサブオブジェクトは、トラフィックが向けられる最初のセグメントを識別します。2番目のSRV6-EROサブオブジェクトは2番目のセグメントを表します。
The syntax-checking rules that apply to the SRv6-RRO subobject are identical to those of the SRv6-ERO subobject, except as noted below.
SRV6-RROサブオブジェクトに適用される構文チェックルールは、以下の場合を除き、SRV6-EROサブオブジェクトのルールと同一です。
If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 SID and NAI are absent, it MUST consider the entire RRO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 35 ("Both SID and NAI are absent in SRv6-RRO subobject").
PCEPスピーカーがSRV6-RROサブオブジェクトを受信した場合、SRV6 SIDとNAIの両方が存在しない場合、RROの無効なことを考慮し、エラータイプ= 10（「無効なオブジェクトの受信」）とエラーValue = 35（ "SIDとNAIの両方がSRV6-RRO Subobjectに欠けています"）。
If a PCE detects that the subobjects of an RRO are a mixture of SRv6-RRO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 36 ("RRO mixes SRv6-RRO subobjects with other subobject types").
PCEがRROのサブオブジェクトがSRV6-RROサブオブジェクトと他のタイプのサブオブジェクトの混合であることを検出した場合、エラータイプ= 10（「無効なオブジェクトの受信」）とエラー値でPCERRメッセージを送信する必要があります= 36（ "RROは、SRV6-RROサブオブジェクトを他のサブオブジェクトタイプと混合します」）。
The mechanism by which the PCC learns the path is outside the scope of this document.
PCCがパスを学習するメカニズムは、このドキュメントの範囲外にあります。
The Security Considerations described in [RFC5440], Section 2.5 of [RFC6952], [RFC8231], [RFC8281], [RFC8253], and [RFC8664] are applicable to this specification.
[RFC5440]、[RFC6952]、[RFC8231]、[RFC8281]、[RFC8253]、および[RFC8253]のセクション2.5で説明されているセキュリティ上の考慮事項は、この仕様に適用されます。
Note that this specification enables a network controller to instantiate an SRv6 path in the network. This creates an additional vulnerability if the security mechanisms of [RFC5440], [RFC8231], and [RFC8281] are not used. If there is no integrity protection on the session, then an attacker could create an SRv6 path that may not be subjected to the further verification checks. Further, the MSD field in the Open message could disclose node forwarding capabilities if suitable security mechanisms are not in place. Hence, securing the PCEP session using Transport Layer Security (TLS) [RFC8253] is RECOMMENDED.
この仕様により、ネットワークコントローラーがネットワーク内のSRV6パスをインスタンス化できることに注意してください。[RFC5440]、[RFC8231]、および[RFC8281]のセキュリティメカニズムが使用されない場合、これにより、追加の脆弱性が生じます。セッションに整合性保護がない場合、攻撃者は、さらなる検証チェックを受けない可能性のあるSRV6パスを作成できます。さらに、オープンメッセージのMSDフィールドは、適切なセキュリティメカニズムが整っていない場合、ノード転送機能を開示する可能性があります。したがって、輸送層セキュリティ（TLS）[RFC8253]を使用してPCEPセッションを保護することをお勧めします。
All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8281], and [RFC8664] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]、[RFC8231]、[RFC8281]、および[RFC8664]にリストされているすべての管理可能性の要件と考慮事項は、このドキュメントで定義されたPCEPプロトコル拡張に適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
A PCEP implementation SHOULD allow the operator to configure the SRv6 capability. Further, a policy to accept NAI only for the SRv6 SHOULD be allowed to be set.
PCEP実装により、オペレーターがSRV6機能を構成できるようにする必要があります。さらに、SRV6に対してのみNAIを受け入れるポリシーを設定することを許可される必要があります。
The PCEP YANG module is out of the scope of this document; it is defined in other documents, for example, [PCEP-YANG]. An augmented YANG module for SRv6 is also specified in [PCEP-SRv6-YANG] that allows for SRv6 capability and MSD configurations as well as to monitor the SRv6 paths set in the network.
PCEP Yangモジュールは、このドキュメントの範囲外です。たとえば、他のドキュメントで定義されています[pcep-yang]。SRV6用の拡張Yangモジュールは、[PCEP-SRV6-Yang]でも指定されており、SRV6機能とMSD構成を可能にし、ネットワークに設定されたSRV6パスを監視します。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]に既にリストされているものに加えて、新しい活性検出および監視要件を意味するものではありません。
Verification of the mechanisms defined in this document can be built on those already listed in [RFC5440], [RFC8231], and [RFC8664].
このドキュメントで定義されているメカニズムの検証は、[RFC5440]、[RFC8231]、および[RFC8664]に既にリストされているメカニズムに基づいて構築できます。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルの新しい要件を意味するものではありません。
Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply to PCEP extensions defined in this document.
[RFC5440]、[RFC8231]、および[RFC8664]で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張機能にも適用されます。
This document defines a new subobject type for the PCEP Explicit Route Object (ERO) and a new subobject type for the PCEP Reported Route Object (RRO). These have been registered in the "Resource Reservation Protocol (RSVP) Parameters" registry group as shown below.
このドキュメントでは、PCEP明示的ルートオブジェクト（ERO）の新しいサブオブジェクトタイプと、PCEP報告ルートオブジェクト（RRO）の新しいサブオブジェクトタイプを定義します。これらは、以下に示すように、「Resource Reservation Protocol（RSVP）パラメーター」レジストリグループに登録されています。
IANA has allocated the following new subobject in the "Subobject type - 20 EXPLICIT_ROUTE - Type 1 Explicit Route" registry:
IANAは、次の新しいサブオブジェクトを「subobjectタイプ-20 liblicit_route-タイプ1明示的ルート」レジストリに割り当てました：
+=======+==========================+
| Value | Description |
+=======+==========================+
| 40 | SRv6-ERO (PCEP-specific) |
+-------+--------------------------+
Table 1
IANA has allocated the following new subobject in the "Subobject type - 21 ROUTE_RECORD - Type 1 Route Record" registry:
IANAは、次の新しいサブオブジェクトを「サブオブジェクトタイプ-21 route_record-タイプ1ルートレコード」レジストリに割り当てました：
+=======+==========================+
| Value | Description |
+=======+==========================+
| 40 | SRv6-RRO (PCEP-specific) |
+-------+--------------------------+
Table 2
IANA has created the "PCEP SRv6-ERO NAI Types" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 4-bit NT field in the SRv6-ERO subobject. The registration policy is IETF Review [RFC8126]. IANA has registered the values in Table 3.
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリグループ内に「PCEP SRV6-ERO NAIタイプ」レジストリを作成して、SRV6-ERO Subobjectの4ビットNTフィールドを管理しています。登録ポリシーはIETFレビュー[RFC8126]です。IANAは、表3に値を登録しています。
+=======+===============================+===========+
| Value | Description | Reference |
+=======+===============================+===========+
| 0 | NAI is absent. | RFC 9603 |
+-------+-------------------------------+-----------+
| 2 | NAI is an IPv6 node ID. | RFC 9603 |
+-------+-------------------------------+-----------+
| 4 | NAI is an IPv6 adjacency with | RFC 9603 |
| | global IPv6 addresses. | |
+-------+-------------------------------+-----------+
| 6 | NAI is an IPv6 adjacency with | RFC 9603 |
| | link-local IPv6 addresses. | |
+-------+-------------------------------+-----------+
Table 3
IANA has created the "SRv6-ERO Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 12-bit Flag field of the SRv6-ERO subobject. New values are to be assigned by Standards Action [RFC8126]. Each registration should include the following information:
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリグループ内に「SRV6-EROフラグフィールド」レジストリを作成し、SRV6-ERO Subobjectの12ビットフラグフィールドを管理しています。新しい値は、標準アクション[RFC8126]によって割り当てられます。各登録には、次の情報を含める必要があります。
* Bit (counting from bit 0 as the most significant bit)
* ビット（最も重要なビットとしてビット0からカウント）
* Description
* 説明
* Reference
* 参照
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
+=====+==============================+===========+
| Bit | Description | Reference |
+=====+==============================+===========+
| 8 | SID Verification (V) | RFC 9603 |
+-----+------------------------------+-----------+
| 9 | SID Structure is present (T) | RFC 9603 |
+-----+------------------------------+-----------+
| 10 | NAI is absent (F) | RFC 9603 |
+-----+------------------------------+-----------+
| 11 | SID is absent (S) | RFC 9603 |
+-----+------------------------------+-----------+
Table 4
This document defines a new value in "LSP-ERROR-CODE TLV Error Code Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group.
このドキュメントは、「PATH計算要素プロトコル（PCEP）番号」レジストリグループ内の「LSP-Error-Code TLVエラーコードフィールド」レジストリの新しい値を定義します。
+=======+========================+===========+
| Value | Meaning | Reference |
+=======+========================+===========+
| 10 | SID Verification fails | RFC 9603 |
+-------+------------------------+-----------+
Table 5
IANA maintains the "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA has registered the following value:
IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリグループ内の「パスセットアップタイプの能力サブTLVタイプインジケーター」レジストリを維持し、パスセットアップタイプのサブTLVのタイプインジケータースペースを管理します。機能TLV。IANAは次の値を登録しています。
+=======+=====================+===========+
| Value | Meaning | Reference |
+=======+=====================+===========+
| 27 | SRv6-PCE-CAPABILITY | RFC 9603 |
+-------+---------------------+-----------+
Table 6
IANA has created the "SRv6 Capability Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 16-bit Flag field of the SRv6-PCE-CAPABILITY sub-TLV. New values are to be assigned by Standards Action [RFC8126]. Each registration should include the following information:
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリグループ内に「SRV6機能フラグフィールド」レジストリを作成し、SRV6-PCEキャピールサブTLVの16ビットフラグフィールドを管理しています。新しい値は、標準アクション[RFC8126]によって割り当てられます。各登録には、次の情報を含める必要があります。
* Bit (counting from bit 0 as the most significant bit)
* ビット（最も重要なビットとしてビット0からカウント）
* Description
* 説明
* Reference
* 参照
The following value is defined in this document.
このドキュメントでは、次の値が定義されています。
+=====+==============================+===========+
| Bit | Description | Reference |
+=====+==============================+===========+
| 14 | Node or Adjacency Identifier | RFC 9603 |
| | (NAI) is supported (N) | |
+-----+------------------------------+-----------+
Table 7
[RFC8408] created the "PCEP Path Setup Types" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has allocated the following value:
[RFC8408]は、「パス計算要素プロトコル（PCEP）番号」レジストリグループ内に「PCEPパスセットアップタイプ」レジストリを作成しました。IANAは次の値を割り当てました。
+=======+==========================+===========+
| Value | Description | Reference |
+=======+==========================+===========+
| 3 | Traffic engineering path | RFC 9603 |
| | is set up using SRv6. | |
+-------+--------------------------+-----------+
Table 8
IANA has allocated the following Error-values in the "PCEP-ERROR Object Error Types and Values" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group:
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリグループ内の「PCEP-Errorオブジェクトエラータイプと値」レジストリに次のエラー値を割り当てました。
+============+=================+===================================+
| Error-Type | Meaning | Error-value |
+============+=================+===================================+
| 10 | Reception of an | 34: Missing PCE-SRv6-CAPABILITY |
| | invalid object | sub-TLV |
| | +-----------------------------------+
| | | 35: Both SID and NAI are absent |
| | | in SRv6-RRO subobject |
| | +-----------------------------------+
| | | 36: RRO mixes SRv6-RRO subobjects |
| | | with other subobject types |
| | +-----------------------------------+
| | | 37: Invalid SRv6 SID Structure |
| | +-----------------------------------+
| | | 40: Unsupported number of |
| | | SRv6-ERO subobjects |
| | +-----------------------------------+
| | | 41: Unsupported NAI Type in the |
| | | SRv6-ERO/SRv6-RRO subobject |
| | +-----------------------------------+
| | | 42: Both SID and NAI are absent |
| | | in the SRv6-ERO subobject |
| | +-----------------------------------+
| | | 43: ERO mixes SRv6-ERO subobjects |
| | | with other subobject types |
+------------+-----------------+-----------------------------------+
| 19 | Invalid | 19: Attempted SRv6 when the |
| | Operation | capability was not advertised |
+------------+-----------------+-----------------------------------+
Table 9
[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>.
[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>.
[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>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[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>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M.,
Bernier, D., and B. Decraene, "Border Gateway Protocol -
Link State (BGP-LS) Extensions for Segment Routing over
IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December
2023, <https://www.rfc-editor.org/info/rfc9514>.
[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>.
[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>.
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[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>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[PCEP-YANG]
Dhody, D., Ed., Beeram, V., 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-25, 21 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-yang-25>.
[PCEP-SRv6-YANG]
Li, C., Sivabalan, S., Peng, S., Koldychev, M., and L.
Ndifor, "A YANG Data Model for Segment Routing (SR) Policy
and SR in IPv6 (SRv6) support in Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-srv6-yang-05, 18 March
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-srv6-yang-05>.
The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun Wang, Khasanov Boris, Ketan Talaulikar, Martin Vigoureux, Hariharan Ananthakrishnan, Xinyue Zhang, John Scudder, Julien Meuric, and Robert Varga for valuable suggestions.
著者は、ジェフ・タンツーラ、エイドリアン・ファレル、アイジュン・ワン、カサノフ・ボリス、ケタン・タライカル、マーティン・ヴィゴーリュ、Xinyue Zhang、John Scudder、Julien Meuric、およびRobert vargaに感謝します。
Thanks to Gunter Van de Velde, Éric Vyncke, Jim Guichard, and Mahesh Jethanandani for their comments during the IESG review.
IESGのレビュー中にコメントをしてくれたGunter Van De Velde、éricVyncke、Jim Guichard、Mahesh Jethanandaniに感謝します。
Mahendra Singh Negi
RtBrick Inc
Bangalore
Karnataka
India
Email: mahend.ietf@gmail.com
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Huang Wumin
Huawei Technologies
Huawei Building, No. 156 Beiqing Rd.
Beijing
100095
China
Email: huangwumin@huawei.com
Shuping Peng
Huawei Technologies
Huawei Building, No. 156 Beiqing Rd.
Beijing
100095
China
Email: pengshuping@huawei.com
Ran Chen
ZTE Corporation
China
Email: chen.ran@zte.com.cn
Cheng Li (editor)
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com
Additional contact information:
李呈 (editor)
中国
100095
北京
华为北研所
华为技术有限公司
Prejeeth Kaladharan
RtBrick Inc
Bangalore
Karnataka
India
Email: prejeeth@rtbrick.com
Siva Sivabalan
Ciena Corporation
Email: msiva282@gmail.com
Mike Koldychev
Ciena Corporation
Canada
Email: mkoldych@ciena.com
Yongqing Zhu
China Telecom
109 West Zhongshan Ave, Tianhe District
Bangalore
Guangzhou,
China
Email: zhuyq8@chinatelecom.cn