Internet Engineering Task Force (IETF) S. Previdi
Request for Comments: 9830 Huawei Technologies
Updates: 9012 C. Filsfils
Category: Standards Track K. Talaulikar, Ed.
ISSN: 2070-1721 Cisco Systems
P. Mattes
Microsoft
D. Jain
Google
September 2025
A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP.
A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy.SRポリシーは、1つ以上の候補パス（CPS）で構成され、それぞれが1つ以上のセグメントリストで構成されています。ヘッドエンドは、コマンドラインインターフェイス（CLI）、ネットワーク構成プロトコル（NetConf）、パス計算要素通信プロトコル（PCEP）、またはBGPなどのさまざまなメカニズムを使用して、これらのCPSでプロビジョニングできます。
This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs.
このドキュメントは、SRポリシーCPSを配布するためにBGPを使用する方法を指定します。SRポリシーのCPを宣伝するためのBGP SAFIを導入し、これらのCPSに関連するシグナル情報にトンネルカプセル化属性のサブTLVを定義します。
Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy.
さらに、このドキュメントは、SRポリシーよりも追加のステアリングモードをサポートするために、色の拡張コミュニティを拡張することにより、RFC 9012を更新します。
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/rfc9830.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9830で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. SR Policy Encoding
2.1. SR Policy SAFI and NLRI
2.2. SR Policy and Tunnel Encapsulation Attribute
2.3. Applicability of Tunnel Encapsulation Attribute Sub-TLVs
2.4. SR Policy Sub-TLVs
2.4.1. Preference Sub-TLV
2.4.2. Binding SID Sub-TLV
2.4.3. SRv6 Binding SID Sub-TLV
2.4.4. Segment List Sub-TLV
2.4.5. Explicit NULL Label Policy Sub-TLV
2.4.6. SR Policy Priority Sub-TLV
2.4.7. SR Policy Candidate Path Name Sub-TLV
2.4.8. SR Policy Name Sub-TLV
3. Color Extended Community
4. SR Policy Operations
4.1. Advertisement of SR Policies
4.2. Reception of an SR Policy NLRI
4.2.1. Validation of an SR Policy NLRI
4.2.2. Eligibility for Local Use of an SR Policy NLRI
4.2.3. Propagation of an SR Policy
5. Error Handling and Fault Management
6. IANA Considerations
6.1. Subsequent Address Family Identifiers (SAFI) Parameters
6.2. BGP Tunnel Encapsulation Attribute Tunnel Types
6.3. BGP Tunnel Encapsulation Attribute Sub-TLVs
6.4. Color Extended Community Flags
6.5. SR Policy Segment List Sub-TLVs
6.6. SR Policy Binding SID Flags
6.7. SR Policy SRv6 Binding SID Flags
6.8. SR Policy Segment Flags
6.9. Color Extended Community Color-Only Types
6.10. SR Policy ENLP Values
7. Security Considerations
8. Manageability Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Segment Routing (SR) [RFC8402] allows a headend node to steer a packet flow along a specific path. Intermediate per-path states are eliminated thanks to source routing.
セグメントルーティング（SR）[RFC8402]を使用すると、ヘッドエンドノードが特定のパスに沿ってパケットフローを導くことができます。ソースルーティングのおかげで、パスごとの中間状態は排除されます。
The headend node is said to steer a flow into an SR Policy [RFC9256].
ヘッドエンドノードは、SRポリシー[RFC9256]に流れを導くと言われています。
The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
SRポリシーに導かれたパケットには、そのSRポリシーに関連するセグメントの順序付けられたリストがあります。
[RFC9256] further details the concepts of SR Policy and steering into an SR Policy. These apply equally to the SR-MPLS and Segment Routing over IPv6 (SRv6) data plane instantiations of Segment Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) as described in [RFC8402]. [RFC8660] describes the representation and processing of this ordered list of segments as an MPLS label stack for SR-MPLS. [RFC8754] and [RFC8986] describe the same for SRv6 with the use of the Segment Routing Header (SRH).
[RFC9256] SRポリシーの概念とSRポリシーへの操縦の概念を詳細に説明しています。これらは、[RFC8402]に記載されているように、SR-MPLSおよびSRV6セグメント識別子（SIDS）を使用して、セグメントルーティングのIPv6（SRV6）データプレーンインスタンス化を介したSR-MPLSおよびセグメントルーティングに等しく適用されます。[RFC8660]は、SR-MPLSのMPLSラベルスタックとして、この順序付けられたセグメントのリストの表現と処理を説明しています。[RFC8754]および[RFC8986]は、セグメントルーティングヘッダー（SRH）を使用してSRV6についても同じことを説明しています。
The functionality related to SR Policy described in [RFC9256] can be conceptually viewed as being incorporated in an SR Policy Module (SRPM). The following is a reminder of the high-level functionality of SRPM:
[RFC9256]で説明されているSRポリシーに関連する機能は、SRポリシーモジュール（SRPM）に組み込まれていると概念的に見ることができます。以下は、SRPMの高レベルの機能を思い出させるものです。
* Learning multiple CPs for an SR Policy via various mechanisms (CLI, NETCONF, PCEP, or BGP).
* さまざまなメカニズム（CLI、NetConf、PCEP、またはBGP）を介してSRポリシーの複数のCPSを学習します。
* Selection of the best CP for an SR Policy.
* SRポリシーに最適なCPの選択。
* Associating a Binding SID (BSID) to the selected CP of an SR Policy.
* バインディングSID（BSID）をSRポリシーの選択したCPに関連付けます。
* Installation of the selected CP and its BSID in the forwarding plane.
* 選択したCPとそのBSIDの転送面に設置。
This document specifies the use of BGP to distribute one or more of the CPs of an SR Policy to the headend of that SR Policy. The document describes the functionality provided by BGP and, as appropriate, provides references for the functionality, which is outside the scope of BGP (i.e., resides within SRPM on the headend node).
このドキュメントは、SRポリシーのCPSの1つ以上をそのSRポリシーのヘッドエンドに配布するためのBGPの使用を指定しています。このドキュメントでは、BGPによって提供される機能について説明し、必要に応じて、BGPの範囲外（つまり、ヘッドエンドノード上のSRPM内にある）の機能の参照を提供します。
This document specifies a way of representing SR Policy CPs in BGP UPDATE messages. BGP can then be used to propagate the SR Policy CPs to the headend nodes in a network. The usual BGP rules for BGP propagation and best-path selection are used. At the headend of a specific SR Policy, this will result in one or more CPs being installed into the "BGP table". These paths are then passed to the SRPM. The SRPM may compare them to CPs learned via other mechanisms and will choose one or more paths to be installed in the data plane. BGP itself does not install SR Policy CPs into the data plane.
このドキュメントは、BGP更新メッセージでSRポリシーCPSを表す方法を指定しています。その後、BGPを使用して、SRポリシーCPSをネットワーク内のヘッドエンドノードに伝播できます。BGP伝播とベストパス選択の通常のBGPルールが使用されます。特定のSRポリシーのヘッドエンドでは、「BGPテーブル」に1つ以上のCPSがインストールされます。これらのパスは、SRPMに渡されます。SRPMは、それらを他のメカニズムを介して学習したCPSと比較し、データプレーンにインストールされる1つ以上のパスを選択します。BGP自体は、SRポリシーCPSをデータプレーンにインストールしません。
This document introduces a BGP Subsequent Address Family Identifier (SAFI) for IPv4 and IPv6 address families. In BGP UPDATE messages of those AFI/SAFIs, the Network Layer Reachability Information (NLRI) identifies an SR Policy CP while the attributes encode the segment lists and other details of that SR Policy CP.
このドキュメントでは、IPv4およびIPv6アドレスファミリのBGP後続のアドレスファミリ識別子（SAFI）を紹介します。これらのAFI/SAFISのBGP更新メッセージでは、ネットワークレイヤーリーチビリティ情報（NLRI）がSRポリシーCPを識別し、属性がセグメントリストとそのSRポリシーCPのその他の詳細をエンコードします。
While, for simplicity, the text in this document states that BGP advertises an SR Policy, it is to be understood that BGP advertises a CP of an SR Policy and that this SR Policy might have several other CPs provided via BGP (via an NLRI with a different distinguisher as defined in Section 2.1), PCEP, NETCONF, or local policy configuration.
簡単にするために、このドキュメントのテキストは、BGPがSRポリシーを宣伝すると述べていますが、BGPはSRポリシーのCPを宣伝し、このSRポリシーはBGP（セクション2.1で定義されている別の違いを備えたNLRIを介して提供される可能性があることを理解する必要があります。
Typically, an SR Policy Controller [RFC9256] defines the set of policies and advertises them to SR Policy headend routers (typically ingress routers). These SR Policy advertisements use the BGP extensions defined in this document. In most cases, the SR Policy advertisement is tailored for a specific SR Policy headend; consequently, it may be transmitted over a direct BGP session (i.e., without intermediate BGP hops) to that headend and is not propagated any further. In such cases, the SR Policy advertisements will not traverse any Route Reflector (RR) (see [RFC4456] and Section 4.2.3).
通常、SRポリシーコントローラー[RFC9256]は、一連のポリシーを定義し、SRポリシーヘッドエンドルーター（通常、ルーターを侵入）に宣伝します。これらのSRポリシー広告は、このドキュメントで定義されているBGP拡張機能を使用します。ほとんどの場合、SRポリシー広告は特定のSRポリシーヘッドエンドに合わせて調整されています。その結果、直接BGPセッション（つまり、中間BGPホップなし）でそのヘッドエンドに送信される可能性があり、それ以上伝播されません。そのような場合、SRポリシー広告は、ルートリフレクター（RR）を通過しません（[RFC4456]およびセクション4.2.3を参照）。
Alternatively, a BGP egress router may advertise SR Policies that represent paths that terminate on it. In such cases, the router can send these policies directly to each headend over a dedicated BGP session, without necessitating any further propagation of the SR Policy.
あるいは、BGP出力ルーターは、それを終了するパスを表すSRポリシーを宣伝する場合があります。そのような場合、ルーターは、SRポリシーのさらなる伝播を必要とせずに、専用のBGPセッションでこれらのポリシーを各ヘッドエンドに直接送信できます。
In some situations, it is undesirable for a controller or BGP egress router to have a BGP session to each SR Policy headend. In these situations, BGP RRs may be used to propagate the advertisements. In certain other deployments, it may be necessary for the advertisement to propagate through a sequence of one or more Autonomous Systems (ASes) within an SR Domain (refer to Section 7 for the associated security considerations). To make this possible, an attribute needs to be attached to the advertisement that enables a BGP speaker to determine whether it is intended to be a headend for the advertised SR Policy. This is done by attaching one or more Route Target extended communities to the advertisement [RFC4360].
状況によっては、コントローラーまたはBGPの出力ルーターが各SRポリシーヘッドエンドにBGPセッションを行うことは望ましくありません。これらの状況では、BGP RRを使用して広告を伝播することができます。他の特定の展開では、広告がSRドメイン内の1つまたは複数の自律システム（ASE）のシーケンスを介して伝播する必要がある場合があります（関連するセキュリティに関する考慮事項については、セクション7を参照）。これを可能にするために、BGPスピーカーが広告されたSRポリシーのヘッドエンドであるかどうかを判断できるようにする属性を広告に添付する必要があります。これは、1つ以上のルートターゲット拡張コミュニティを広告[RFC4360]に添付することによって行われます。
The BGP extensions for the advertisement of SR Policies include following components:
SRポリシーの広告のBGP拡張機能には、次のコンポーネントが含まれます。
* A SAFI whose NLRIs identify an SR Policy CP.
* NLRIがSRポリシーCPを識別するSAFI。
* A Tunnel Type identifier for SR Policy and a set of sub-TLVs to be inserted into the Tunnel Encapsulation Attribute (as defined in [RFC9012]) specifying segment lists of the SR Policy CP as well as other information about the SR Policy.
* SRポリシーのトンネルタイプ識別子と、SRポリシーCPのセグメントリストとSRポリシーに関するその他の情報を指定するトンネルカプセル化属性（[RFC9012]で定義）に挿入されるサブTLVのセット。
* One or more IPv4 address-specific format Route Target extended community ([RFC4360]) attached to the SR Policy CP advertisement that indicates the intended headend of such an SR Policy CP advertisement.
* 1つ以上のIPv4アドレス固有のフォーマットルートターゲット拡張コミュニティ（[RFC4360]）は、SRポリシーCP広告の意図されたヘッドエンドを示すSRポリシーCP広告に添付されています。
The SR Policy SAFI route updates utilize the Tunnel Encapsulation Attribute to signal an SR Policy, which itself functions as a tunnel. This usage differs notably from the approach described in [RFC9012], where the Tunnel Encapsulation Attribute is associated with a BGP route update (e.g., for Internet or VPN routes) to specify the tunnel used for forwarding traffic. This document does not modify or supersede the usage of the Tunnel Encapsulation Attribute for existing AFI/SAFIs as defined in [RFC9012]. Details regarding the processing of the Tunnel Encapsulation Attribute for the SR Policy SAFI are provided in Sections 2.2 and 2.3.
SRポリシーSAFIルートの更新は、トンネルカプセル化属性を利用して、それ自体がトンネルとして機能するSRポリシーを信号します。この使用法は、特に[RFC9012]で説明されているアプローチとは異なります。トンネルカプセル化属性は、トラフィックを転送するために使用されるトンネルを指定するBGPルートの更新（たとえば、インターネットまたはVPNルートの場合）に関連付けられています。このドキュメントは、[RFC9012]で定義されているように、既存のAFI/SAFISのトンネルカプセル化属性の使用を変更または優先しません。SRポリシーSAFIのトンネルカプセル化属性の処理に関する詳細は、セクション2.2および2.3に記載されています。
The northbound advertisement of the operational state of the SR Policy CPs as part of BGP - Link State (BGP-LS) [RFC9552] topology information is specified in [BGP-LS-SR-POLICY].
BGP-Link State（BGP-LS）[RFC9552]トポロジー情報の一部としてのSRポリシーCPSの運用状態の北行きの広告は、[BGP-LS-SR-Policy]で指定されています。
The signaling of Dynamic and Composite CPs (Sections 5.2 and 5.3, respectively, of [RFC9256]) is outside the scope of this document.
動的および複合CPSのシグナル伝達（それぞれ[RFC9256]のセクション5.2および5.3）は、このドキュメントの範囲外です。
The Color Extended Community (as defined in [RFC9012]) is used to steer traffic into an SR Policy, as described in Section 8.8 of [RFC9256]. Section 3 of this document updates [RFC9012] with modifications to the format of the Flags field of the Color Extended Community by using the two leftmost bits of that field.
[RFC9256]のセクション8.8で説明されているように、色の拡張コミュニティ（[RFC9012]で定義されている）を使用してSRポリシーにトラフィックを誘導します。このドキュメントのセクション3は、[RFC9012]を、そのフィールドの2つの左端ビットを使用して、Color Extendedコミュニティのフラグフィールドの形式を変更して更新します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The SR Policy SAFI with code point 73 is introduced in this document. The AFI used MUST be IPv4(1) or IPv6(2).
コードポイント73を備えたSRポリシーSAFIは、このドキュメントに紹介されています。使用されるAFIは、IPv4（1）またはIPv6（2）でなければなりません。
The SR Policy SAFI uses the NLRI format defined as follows:
SRポリシーSafiは、次のように定義されているNLRI形式を使用します。
+------------------+
| NLRI Length | 1 octet
+------------------+
| Distinguisher | 4 octets
+------------------+
| Color | 4 octets
+------------------+
| Endpoint | 4 or 16 octets
+------------------+
Figure 1: SR Policy SAFI Format
図1：SRポリシーSAFI形式
Where:
ただし：
NLRI Length:
NLRIの長さ：
1 octet indicating the length expressed in bits as defined in [RFC4760]. When AFI = 1, the value MUST be 96; when AFI = 2, the value MUST be 192.
[RFC4760]で定義されているように、ビットで発現される長さを示す1オクテット。AFI = 1の場合、値は96でなければなりません。AFI = 2の場合、値は192でなければなりません。
Distinguisher:
distimuniuther：
4-octet value uniquely identifying the SR Policy in the context of <Color, Endpoint> tuple. The distinguisher has no semantic value. It is used by the SR Policy originator to form unique NLRIs the following situations:
4-OCTET値<色、エンドポイント>タプルのコンテキストでSRポリシーを一意に識別します。distinguisherにはセマンティック値がありません。これは、SRポリシーオリジネーターによって、次の状況を独自のNLRISを形成するために使用しています。
* to differentiate multiple CPs of the same SR Policy
* 同じSRポリシーの複数のCPを区別します
* to differentiate CPs meant for different headends but having the same Color and Endpoint
* さまざまなヘッドエンド用であるが同じ色とエンドポイントを持つCPSを区別する
The distinguisher is the discriminator of the SR Policy CP as specified in Section 2.5 of [RFC9256].
Distinguisherは、[RFC9256]のセクション2.5で指定されているSRポリシーCPの識別器です。
Color:
色：
4 octets that carry an unsigned non-zero integer value indicating the Color of the SR Policy as specified in Section 2.1 of [RFC9256]. The Color is used to match the Color of the destination prefixes to steer traffic into the SR Policy as specified in Section 8 of [RFC9256].
[RFC9256]のセクション2.1で指定されているように、SRポリシーの色を示す、署名されていない非ゼロ整数値を持つ4オクテット。この色は、[RFC9256]のセクション8で指定されているように、宛先プレフィックスの色と一致させるために使用されます。
Endpoint:
終点：
a value that identifies the Endpoint of an SR Policy. The Endpoint may represent a single node or a set of nodes (e.g., an anycast address). The Endpoint is an IPv4 (4-octet) address or an IPv6 (16-octet) address according to the AFI of the NLRI. The address can be either unicast or an unspecified address (0.0.0.0 for IPv4, :: for IPv6), known as a null Endpoint as specified in Section 2.1 of [RFC9256].
SRポリシーのエンドポイントを識別する値。エンドポイントは、単一のノードまたはノードのセットを表す場合があります（例：Anycastアドレス）。エンドポイントは、NLRIのAFIに従って、IPv4（4-OCTET）アドレスまたはIPv6（16-OCTET）アドレスです。アドレスは、[RFC9256]のセクション2.1で指定されているように、ヌルエンドポイントとして知られる、ユニキャストまたは不特定のアドレス（IPv4の場合は0.0.0.0、IPv6の場合は0.0.0.0）です。
The Color and Endpoint are used to automate the steering of BGP service routes on an SR Policy as described in Section 8 of [RFC9256].
色とエンドポイントは、[RFC9256]のセクション8で説明されているように、SRポリシーのBGPサービスルートのステアリングを自動化するために使用されます。
The NLRI containing an SR Policy CP is carried in a BGP UPDATE message [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. The fault management and error handling in the encoding of the NLRI are specified in Section 5.
SRポリシーCPを含むNLRIは、BGPマルチプロトコル拡張[RFC4760]を使用してBGPアップデートメッセージ[RFC4271]に掲載されます。
A BGP UPDATE message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI attribute with the SR Policy SAFI MUST also carry the BGP mandatory attributes. In addition, the BGP UPDATE message MAY also contain any of the BGP optional attributes.
SRポリシーSAFIを使用してMP_REACH_NLRIまたはMP_UNREACH_NLRI属性を搭載したBGP更新メッセージも、BGPの必須属性を運ぶ必要があります。さらに、BGP更新メッセージには、BGPオプションの属性も含まれている場合があります。
The next-hop network address field in SR Policy SAFI (73) updates may be either a 4-octet IPv4 address or a 16-octet IPv6 address, independent of the SR Policy AFI. The Length field of the next-hop address specifies the next-hop address family. If the next-hop length is 4, then the next-hop is an IPv4 address. If the next-hop length is 16, then it is a global IPv6 address. If the next-hop length is 32, then it has a global IPv6 address followed by a link-local IPv6 address. The setting of the next-hop field and its attendant processing is governed by standard BGP procedures as described in Section 3 of [RFC4760] and Section 3 of [RFC2545].
SRポリシーSAFI（73）の更新のNext-HOPネットワークアドレスフィールドは、SRポリシーAFIとは無関係に、4-OCTET IPv4アドレスまたは16-OCTET IPv6アドレスのいずれかです。next-Hopアドレスの長さフィールドは、Next-Hopアドレスファミリを指定します。next-Hopの長さが4の場合、次のホップはIPv4アドレスです。次のホップの長さが16の場合、グローバルIPv6アドレスです。next-Hopの長さが32の場合、グローバルIPv6アドレスに続いてLink-Local IPv6アドレスが続きます。[RFC4760]のセクション3および[RFC2545]のセクション3で説明されているように、next-Hopフィールドとその付随する処理の設定は、標準のBGP手順によって支配されます。
It is important to note that at any BGP speaker receiving BGP updates with SR Policy NLRIs, the SRPM processes only the best path as per the BGP best-path selection algorithm. In other words, this document leverages the existing BGP propagation and best-path selection rules. Details of the procedures are described in Section 4.
SRポリシーNLRISでBGP更新を受けるBGPスピーカーでは、SRPMがBGPベストパス選択アルゴリズムに従って最適なパスのみを処理することに注意することが重要です。言い換えれば、このドキュメントは、既存のBGP伝播とベストパス選択ルールを活用しています。手順の詳細については、セクション4で説明します。
It has to be noted that if several CPs of the same SR Policy (Endpoint, Color) are signaled via BGP to a headend, then it is RECOMMENDED that each NLRI use a different distinguisher. If BGP has installed into the BGP table two advertisements whose respective NLRIs have the same Color and Endpoint, but different distinguishers, both advertisements are passed to the SRPM as different CPs along with their respective originator information (i.e., Autonomous System Number (ASN) and BGP Router-ID) as described in Section 2.4 of [RFC9256]. The ASN would be the ASN of the origin and the BGP Router-ID is determined in the following order:
同じSRポリシーのいくつかのCPS（エンドポイント、色）がBGPを介してヘッドエンドに合図されている場合、各NLRIが異なる違いを使用することをお勧めします。BGPがBGPテーブルにインストールした場合、それぞれのNLRIが同じ色とエンドポイントを持っているが異なる違いを持つ2つの広告が、両方の広告が、それぞれのオリジネーター情報（すなわち、自律システム数（ASN）およびBGP Router-ID）とともに異なるCPSに渡されます。ASNは原点のASNであり、BGPルーターIDは次の順序で決定されます。
* From the Route Origin Community [RFC4360] if present and carrying an IP Address, or
* Route Origin Community [RFC4360]からIPアドレスを搭載している場合、または
* As the BGP ORIGINATOR_ID [RFC4456] if present, or
* BGP Originator_id [rfc4456]が存在する場合、または
* As the BGP Router-ID of the peer from which the update was received as a last resort.
* 更新が最後の手段として受信されたピアのBGPルーターIDとして。
Section 2.9 of [RFC9256] specifies the selection of the active CP of the SR Policy by the SRPM based on the information provided to it by BGP.
[RFC9256]のセクション2.9は、BGPが提供する情報に基づいて、SRPMによるSRポリシーのアクティブなCPの選択を指定しています。
The content of the SR Policy CP is encoded in the Tunnel Encapsulation Attribute defined in [RFC9012] using a Tunnel Type called the "SR Policy" type with code point 15. The use of the SR Policy Tunnel Type is applicable only for the AFI/SAFI pairs of (1/73, 2/73). This document specifies the use of the Tunnel Encapsulation Attribute with the SR Policy Tunnel Type and the use of any other Tunnel Type with the SR Policy SAFI MUST be considered malformed and handled by the "treat-as-withdraw" strategy [RFC7606].
SRポリシーCPの内容は、[RFC9012]で定義されたトンネルカプセル化属性にエンコードされています。コードポイント15の「SRポリシー」タイプと呼ばれるトンネルタイプを使用します。SRポリシートンネルタイプの使用は、（1/73、2/73）のAFI/SAFIペアにのみ適用できます。このドキュメントは、SRポリシートンネルタイプを使用したトンネルカプセル化属性の使用と、SRポリシーSAFIを使用した他のトンネルタイプの使用を指定していることを指定します。
The SR Policy Encoding structure is as follows:
SRポリシーエンコード構造は次のとおりです。
SR Policy SAFI NLRI: <Distinguisher, Color, Endpoint>
Attributes:
Tunnel Encapsulation Attribute (23)
Tunnel Type: SR Policy (15)
Binding SID
Preference
Priority
SR Policy Name
SR Policy Candidate Path Name
Explicit NULL Label Policy (ENLP)
Segment List
Weight
Segment
Segment
...
...
Figure 2: SR Policy Encoding
図2：SRポリシーエンコーディング
Where:
ただし：
* The SR Policy SAFI NLRI is defined in Section 2.1.
* SRポリシーSafi NLRIは、セクション2.1で定義されています。
* The Tunnel Encapsulation Attribute is defined in [RFC9012].
* トンネルカプセル化属性は[RFC9012]で定義されています。
* The Tunnel Type is set to 15.
* トンネルタイプは15に設定されています。
* Preference, Binding SID, Priority, SR Policy Name, SR Policy Candidate Path Name, ENLP, Segment-List, Weight, and Segment sub-TLVs are defined in Section 2.4.
* 優先、バインディングSID、優先度、SRポリシー名、SRポリシー候補パス名、ENLP、セグメントリスト、重量、およびセグメントサブTLVはセクション2.4で定義されています。
* Additional sub-TLVs may be defined in the future.
* 追加のサブTLVは、将来定義される場合があります。
A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV of type "SR Policy"; such updates MUST be considered malformed and handled by the "treat-as-withdraw" strategy [RFC7606].
トンネルカプセル化属性には、タイプ「SRポリシー」のTLVを1つ以上含めてはなりません。このような更新は、「服用としての扱い」戦略[RFC7606]によって奇形と扱われると見なされる必要があります。
BGP does not need to perform the validation of the tunnel (i.e., SR Policy) itself as indicated in Section 6 of [RFC9012]. The validation of the SR Policy information that is advertised using the sub-TLVs specified in Section 2.4 is performed by the SRPM.
BGPは、[RFC9012]のセクション6に示されているように、トンネル（つまり、SRポリシー）自体の検証を実行する必要はありません。セクション2.4で指定されたサブTLVを使用して宣伝されているSRポリシー情報の検証は、SRPMによって実行されます。
The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel Encapsulation Attribute, as defined in [RFC9012], are not utilized for SR Policy encodings. Consequently, their values are not relevant within the context of the SR Policy SAFI NLRI. If these sub-TLVs are present, a BGP speaker MUST ignore them and MAY remove them from the Tunnel Encapsulation Attribute during propagation.
[RFC9012]で定義されているトンネルカプセル化属性のトンネル出力エンドポイントとカラーサブTLVは、SRポリシーエンコーディングには利用されていません。したがって、それらの価値は、SRポリシーSafi NLRIのコンテキスト内では関係ありません。これらのサブTLVが存在する場合、BGPスピーカーはそれらを無視し、伝播中にトンネルカプセル化属性からそれらを削除する必要があります。
Similarly, any other sub-TLVs, including those specified in [RFC9012], that do not have explicitly defined applicability to the SR Policy SAFI MUST be ignored by the BGP speaker and MAY be removed from the Tunnel Encapsulation Attribute during propagation.
同様に、[RFC9012]で指定されたものを含む他のサブTLVは、SRポリシーSAFIへの適用性を明示的に定義していないものをBGPスピーカーによって無視し、伝播中にトンネルカプセル化属性から削除する必要があります。
This section specifies the sub-TLVs defined for encoding the information about the SR Policy Candidate Path.
このセクションでは、SRポリシー候補パスに関する情報をエンコードするために定義されたサブTLVを指定します。
Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, SR Policy Name, SR Policy Candidate Path Name, and Explicit NULL Label Policy are all optional sub-TLVs introduced for the BGP Tunnel Encapsulation Attribute [RFC9012] being defined in this section.
優先、バインディングSID、SRV6バインディングSID、セグメントリスト、優先度、SRポリシー名、SRポリシー候補パス名、および明示的なヌルラベルポリシーはすべて、このセクションで定義されているBGPトンネルカプセル化属性[RFC9012]に導入されたオプションのサブTLVです。
Weight and Segment are sub-TLVs of the Segment-List sub-TLV mentioned above.
重みとセグメントは、上記のセグメントリストサブTLVのサブTLVです。
An early draft version of this document included only the Binding SID sub-TLV that could be used for both SR-MPLS and SRv6 BSIDs. The SRv6 Binding SID TLV was introduced in later versions to support the advertisement of additional SRv6 capabilities without affecting backward compatibility for early implementations.
このドキュメントの初期ドラフトバージョンには、SR-MPLSとSRV6 BSIDの両方に使用できるバインディングSID Sub-TLVのみが含まれていました。SRV6バインディングSID TLVは、早期の実装のための後方互換性に影響を与えることなく、追加のSRV6機能の広告をサポートするために、後のバージョンで導入されました。
The fault management and error handling in the encoding of the sub-TLVs defined in this section are specified in Section 5. For the TLVs/sub-TLVs that are specified as single instance, only the first instance of that TLV/sub-TLV is used: the other instances MUST be ignored and MUST NOT considered to be malformed.
このセクションで定義されているサブTLVのエンコードにおける障害管理とエラー処理は、セクション5で指定されています。単一のインスタンスとして指定されているTLVS/Sub-TLVについては、そのTLV/SUB-TLVの最初のインスタンスのみが使用され、他のインスタンスを無視する必要があり、誤ったと考える必要はありません。
None of the sub-TLVs defined in the following subsections have any effect on the BGP best-path selection or propagation procedures. These sub-TLVs are not used by the BGP path selection process and are instead passed on to SRPM as SR Policy Candidate Path information for further processing as described in Section 2 of [RFC9256].
以下のサブセクションで定義されたサブTLVは、BGPのベストパス選択または伝播手順に影響を与えません。これらのサブTLVは、BGPパス選択プロセスでは使用されず、代わりに[RFC9256]のセクション2で説明されているように、さらなる処理のためのSRポリシー候補パス情報としてSRPMに渡されます。
The use of SR Policy sub-TLVs is applicable only for the AFI/SAFI pairs of (1/73, 2/73). Future documents may extend their applicability to other AFI/SAFI.
SRポリシーサブTLVの使用は、（1/73、2/73）のAFI/SAFIペアにのみ適用されます。将来の文書は、他のAFI/SAFIに適用性を拡大する場合があります。
The Preference sub-TLV is used to carry the Preference of an SR Policy CP. The contents of this sub-TLV are used by the SRPM as described in Section 2.7 of [RFC9256].
優先Sub-TLVは、SRポリシーCPの優先権を運ぶために使用されます。このサブTLVの内容は、[RFC9256]のセクション2.7で説明されているようにSRPMによって使用されます。
The Preference sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding.
設定Sub-TLVはオプションです。SRポリシーエンコーディングに複数回表示してはなりません。
The Preference sub-TLV has the following format:
設定Sub-TLVには次の形式があります。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Preference Sub-TLV
図3：優先サブTLV
Where:
ただし：
Type:
タイプ：
12
12
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 6.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は6でなければなりません。
Flags:
フラグ：
1 octet of flags. No flags are defined in this document. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.
旗の1オクテット。このドキュメントでは、フラグは定義されていません。フラグフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Preference:
好み：
a 4-octet value indicating the Preference of the SR Policy CP as described in Section 2.7 of [RFC9256].
[RFC9256]のセクション2.7で説明されているSRポリシーCPの選好を示す4-OCTET値。
The Binding SID sub-TLV is used to signal the BSID-related information of the SR Policy CP. The contents of this sub-TLV are used by the SRPM as described in Section 6 of [RFC9256].
バインディングSID Sub-TLVは、SRポリシーCPのBSID関連情報を知らせるために使用されます。このサブTLVの内容は、[RFC9256]のセクション6で説明されているようにSRPMによって使用されます。
The Binding SID sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding.
バインディングSID Sub-TLVはオプションです。SRポリシーエンコーディングに複数回表示してはなりません。
When the Binding SID sub-TLV is used to signal an SRv6 SID, the selection of the corresponding SRv6 Endpoint Behavior [RFC8986] to be instantiated is determined by the headend node. It is RECOMMENDED that the SRv6 Binding SID sub-TLV, as defined in Section 2.4.3, be used when signaling an SRv6 BSID for an SR Policy CP. The support for the use of this Binding SID sub-TLV for the signaling of an SRv6 BSID is retained primarily for backward compatibility with implementations that followed early draft versions of this document that had not defined the SRv6 Binding SID sub-TLV.
バインディングSID Sub-TLVを使用してSRV6 SIDをシグナルにすると、インスタンス化される対応するSRV6エンドポイント挙動[RFC8986]の選択は、ヘッドエンドノードによって決定されます。セクション2.4.3で定義されているSRV6結合SID Sub-TLVは、SRポリシーCPのSRV6 BSIDをシグナルにするときに使用することをお勧めします。SRV6 BSIDのシグナル伝達のためのこのバインディングSID SUB-TLVの使用のサポートは、主にSRV6バインディングSID Sub-TLVを定義していないこのドキュメントの初期ドラフトバージョンに続いて従った実装との後方互換性のために保持されます。
The Binding SID sub-TLV has the following format:
バインディングSID Sub-TLVには、次の形式があります。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding SID (variable, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding SID Sub-TLV
図4：バインディングSIDサブTLV
Where:
ただし：
Type:
タイプ：
13
13
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 18 when a SRv6 BSID is present, 6 when an SR-MPLS BSID is present, or 2 when no BSID is present.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は、SRV6 BSIDが存在する場合は18、SR-MPLS BSIDが存在する場合は6、またはBSIDが存在しない場合は2でなければなりません。
Flags:
フラグ：
1 octet of flags. The following flags are defined in the registry "SR Policy Binding SID Flags" as described in Section 6.6:
旗の1オクテット。次のフラグは、セクション6.6で説明されているように、レジストリ「SRポリシーバインドSIDフラグ」で定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I| |
+-+-+-+-+-+-+-+-+
Figure 5: SR Policy Binding SID Flags
図5：SRポリシーバインディングSIDフラグ
Where:
ただし：
* The S-Flag encodes the "Specified-BSID-Only" behavior. It is used by SRPM as described in Section 6.2.3 of [RFC9256].
* S-Flagは、「指定されたBSIDのみ」の動作をエンコードします。[RFC9256]のセクション6.2.3で説明されているように、SRPMで使用されます。
* The I-Flag encodes the "Drop-Upon-Invalid" behavior. It is used by SRPM as described in Section 8.2 of [RFC9256] to define a specific SR Policy forwarding behavior. The flag indicates that the SR Policy is to perform the "Drop-Upon-Invalid" behavior when no valid CP is available for this SR Policy. In this situation, the CP with the highest preference amongst those with the "Drop-Upon-Invalid" behavior is made active to drop traffic steered over the SR Policy.
* i-flagは、「ドロップインバリッド」動作をエンコードします。[RFC9256]のセクション8.2で説明されているように、特定のSRポリシー転送動作を定義するためにSRPMで使用されます。フラグは、SRポリシーが、このSRポリシーで有効なCPが利用できない場合に「ドロップインバリッド」動作を実行することであることを示しています。この状況では、SRポリシーを操縦するトラフィックを落とすために、「ドロップアップインバリッド」動作を持つ人々の間で最も優先されるCPが最も優先されます。
* The unassigned bits in the Flags field MUST be set to zero upon transmission and MUST be ignored upon receipt.
* フラグフィールドの未割り当てビットは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
RESERVED:
予約済み：
1 octet of reserved bits. MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Binding SID:
バインディングシド：
If the length is 2, then no BSID is present. If the length is 6, then the BSID is encoded in 4 octets using the format below. Traffic Class (TC), S, and TTL (Total of 12 bits) are RESERVED and MUST be set to zero and MUST be ignored.
長さが2の場合、BSIDは存在しません。長さが6の場合、BSIDは以下の形式を使用して4オクテットでエンコードされます。トラフィッククラス（TC）、S、およびTTL（合計12ビット）は予約されており、ゼロに設定する必要があり、無視する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding SID Label Encoding
図6：バインディングSIDラベルエンコーディング
The Label field is validated by the SRPM but MUST NOT contain the reserved MPLS label values (0-15). If the length is 18, then the BSID contains a 16-octet SRv6 SID.
ラベルフィールドはSRPMによって検証されますが、予約されたMPLSラベル値（0-15）を含めてはなりません。長さが18の場合、BSIDには16オクテットのSRV6 SIDが含まれています。
The SRv6 Binding SID sub-TLV is used to signal the SRv6-BSID-related information of an SR Policy CP. It enables the specification of the SRv6 Endpoint Behavior [RFC8986] to be instantiated on the headend node. The contents of this sub-TLV are used by the SRPM as described in Section 6 of [RFC9256].
SRV6バインディングSID Sub-TLVは、SRポリシーCPのSRV6-BSID関連情報を信号するために使用されます。これにより、SRV6エンドポイントの動作[RFC8986]の指定をヘッドエンドノードにインスタンス化できます。このサブTLVの内容は、[RFC9256]のセクション6で説明されているようにSRPMによって使用されます。
The SRv6 Binding SID sub-TLV is OPTIONAL. More than one SRv6 Binding SID sub-TLV MAY be signaled in the same SR Policy encoding to indicate one or more SRv6 SIDs, each with potentially different SRv6 Endpoint Behaviors to be instantiated.
SRV6 Binding SID Sub-TLVはオプションです。複数のSRV6バインドSID SUB-TLVが同じSRポリシーをエンコードするのと同じSRV6 SIDを示すために、それぞれがインスタンス化される可能性が異なる潜在的に異なるSRV6エンドポイント動作を示すことを示す可能性があります。
The SRv6 Binding SID sub-TLV has the following format:
SRV6バインディングSID Sub-TLVには、次の形式があります。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Binding SID (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure (optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SRv6 Binding SID Sub-TLV
図7：SRV6結合SIDサブTLV
Where:
ただし：
Type:
タイプ：
20
20
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 26 when the SRv6 Endpoint Behavior and SID Structure is present; else, it MUST be 18.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。SRV6エンドポイントの動作とSID構造が存在する場合、値は26でなければなりません。そうでなければ、18でなければなりません。
Flags:
フラグ：
1 octet of flags. The following flags are defined in the registry "SR Policy SRv6 Binding SID Flags" as described in Section 6.7:
旗の1オクテット。次のフラグは、セクション6.7で説明されているように、レジストリ「SRポリシーSRV6バインディングSIDフラグ」に定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I|B| |
+-+-+-+-+-+-+-+-+
Figure 8: SR Policy SRv6 Binding SID Flags
図8：SRポリシーSRV6バインディングSIDフラグ
Where:
ただし：
* The S-Flag encodes the "Specified-BSID-Only" behavior. It is used by SRPM as described in Section 6.2.3 of [RFC9256].
* S-Flagは、「指定されたBSIDのみ」の動作をエンコードします。[RFC9256]のセクション6.2.3で説明されているように、SRPMで使用されます。
* The I-Flag encodes the "Drop-Upon-Invalid" behavior. It is used by SRPM as described in Section 8.2 of [RFC9256].
* i-flagは、「ドロップインバリッド」動作をエンコードします。[RFC9256]のセクション8.2で説明されているように、SRPMで使用されます。
* The B-Flag, when set, indicates the presence of the "SRv6 Endpoint Behavior & SID Structure" encoding specified in Section 2.4.4.2.4.
* B-FLAGは、設定されたときに、セクション2.4.4.2.4で指定された「SRV6エンドポイントの動作とSID構造」の存在を示します。
* The unassigned bits in the Flags field MUST be set to zero upon transmission and MUST be ignored upon receipt.
* フラグフィールドの未割り当てビットは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
SRv6 Binding SID:
SRV6バインディングSID：
Contains a 16-octet SRv6 SID. The value 0 MAY be used when the controller wants to indicate the desired SRv6 Endpoint Behavior, SID Structure, or flags without specifying the BSID.
16-OCTET SRV6 SIDが含まれています。値0は、コントローラーがBSIDを指定せずに目的のSRV6エンドポイントの動作、SID構造、またはフラグを示したい場合に使用できます。
SRv6 Endpoint Behavior and SID Structure:
SRV6エンドポイントの動作とSID構造：
Optional, as defined in Section 2.4.4.2.4. The SRv6 Endpoint Behavior and SID Structure MUST NOT be included when the SRv6 SID has not been included.
セクション2.4.4.2.4で定義されているように、オプション。SRV6 SIDが含まれていない場合、SRV6エンドポイントの動作とSID構造を含めてはなりません。
The Segment List sub-TLV encodes a single explicit path towards the Endpoint as described in Section 5.1 of [RFC9256]. The Segment List sub-TLV includes the elements of the paths (i.e., segments) as well as an optional Weight sub-TLV.
セグメントリストSub-TLVは、[RFC9256]のセクション5.1で説明されているように、エンドポイントに向かって単一の明示的なパスをエンコードします。セグメントリストSub-TLVには、パスの要素（つまり、セグメント）とオプションの重量Sub-TLVが含まれます。
The Segment List sub-TLV may exceed 255 bytes in length due to a large number of segments. A 2-octet length is thus required. According to Section 2 of [RFC9012], the sub-TLV type defines the size of the Length field. Therefore, for the Segment List sub-TLV, a code point of 128 or higher is used.
セグメントリストSub-TLVは、多数のセグメントのため、長さ255バイトを超える場合があります。したがって、2-OCTETの長さが必要です。[RFC9012]のセクション2によると、Sub-TLVタイプは長さフィールドのサイズを定義します。Therefore, for the Segment List sub-TLV, a code point of 128 or higher is used.
The Segment List sub-TLV is OPTIONAL and MAY appear multiple times in the SR Policy encoding. The ordering of Segment List sub-TLVs does not matter since each sub-TLV encodes a Segment List.
セグメントリストSub-TLVはオプションであり、SRポリシーエンコーディングに複数回表示される場合があります。各サブTLVがセグメントリストをエンコードするため、セグメントリストサブTLVの順序は重要ではありません。
The Segment List sub-TLV contains zero or more Segment sub-TLVs and MAY contain a Weight sub-TLV.
セグメントリストSub-TLVにはゼロ以上のセグメントサブTLVが含まれており、重量サブTLVが含まれる場合があります。
The Segment List sub-TLV has the following format:
セグメントリストSub-TLVには次の形式があります。
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 | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Segment List Sub-TLV
図9：セグメントリストサブTLV
Where:
ただし：
Type:
タイプ：
128
128
Length:
長さ：
The total length (not including the Type and Length fields) of the sub-TLVs encoded within the Segment List sub-TLV in terms of octets.
オクテットの観点からセグメントリストサブTLV内でエンコードされたサブTLVの合計長さ（タイプと長さフィールドを含まない）。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
sub-TLVs currently defined:
現在定義されているサブTLV：
* An optional single Weight sub-TLV
* オプションのシングルウェイトサブTLV
* Zero or more Segment sub-TLVs
* ゼロ以上のセグメントサブTLV
Validation of an explicit path encoded by the Segment List sub-TLV is beyond the scope of BGP and performed by the SRPM as described in Section 5 of [RFC9256].
セグメントリストSub-TLVによってエンコードされた明示的なパスの検証は、BGPの範囲を超えており、[RFC9256]のセクション5で説明されているようにSRPMによって実行されます。
The Weight sub-TLV specifies the weight associated with a given segment list. The contents of this sub-TLV are used only by the SRPM as described in Section 2.11 of [RFC9256].
重量サブTLVは、特定のセグメントリストに関連付けられた重量を指定します。このサブTLVの内容は、[RFC9256]のセクション2.11で説明されているように、SRPMによってのみ使用されます。
The Weight sub-TLV is OPTIONAL; it MUST NOT appear more than once inside the Segment List sub-TLV.
重量サブTLVはオプションです。セグメントリストSub-TLV内に複数回表示してはなりません。
The Weight sub-TLV has the following format:
Weight Sub-TLVには次の形式があります。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Weight Sub-TLV
図10：重量サブTLV
Where:
ただし：
Type:
タイプ：
9
9
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 6.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は6でなければなりません。
Flags:
フラグ：
1 octet of flags. No flags are defined in this document. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.
旗の1オクテット。このドキュメントでは、フラグは定義されていません。フラグフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Weight:
重さ：
4 octets carrying an unsigned integer value indicating the weight associated with a segment list as described in Section 2.11 of [RFC9256]. A weight value of zero is invalid.
[RFC9256]のセクション2.11で説明されているように、セグメントリストに関連する重みを示す署名されていない整数値を持つ4オクテット。ゼロの重量値は無効です。
A Segment sub-TLV describes a single segment in a segment list (i.e., a single element of the explicit path). One or more Segment sub-TLVs constitute an explicit path of the SR Policy CP. The contents of these sub-TLVs are used only by the SRPM as described in Section 4 of [RFC9256].
セグメントSub-TLVは、セグメントリストの単一のセグメント（つまり、明示的なパスの単一要素）を記述します。1つ以上のセグメントサブTLVは、SRポリシーCPの明示的なパスを構成します。これらのサブTLVの内容は、[RFC9256]のセクション4で説明されているように、SRPMによってのみ使用されます。
The Segment sub-TLVs are OPTIONAL and MAY appear multiple times in the Segment List sub-TLV.
セグメントサブTLVはオプションであり、セグメントリストサブTLVに複数回表示される場合があります。
Section 4 of [RFC9256] defines several Segment Types:
[RFC9256]のセクション4では、いくつかのセグメントタイプを定義しています。
Type A:
タイプA：
SR-MPLS Label
sr-mplsラベル
Type B:
タイプB：
SRv6 SID
SRV6 SID
Type C:
タイプC：
IPv4 Prefix with optional SR Algorithm
オプションのSRアルゴリズムを備えたIPv4プレフィックス
Type D:
タイプD：
IPv6 Global Prefix with optional SR Algorithm for SR-MPLS
SR-MPLSのオプションのSRアルゴリズムを備えたIPv6グローバルプレフィックス
Type E:
タイプE：
IPv4 Prefix with Local Interface ID
ローカルインターフェイスIDを備えたIPv4プレフィックス
Type F:
タイプF：
IPv4 Addresses for link endpoints as Local, Remote pair
IPv4は、ローカル、リモートペアとしてリンクエンドポイントのアドレス指定を行います
Type G:
タイプG：
IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS
sr-mplのローカル、リモートペアとしてのリンクエンドポイントのIPv6プレフィックスとインターフェイスID
Type H:
タイプH：
IPv6 Addresses for link endpoints as Local, Remote pair for SR-MPLS
IPv6は、sr-mplsのローカル、リモートペアとしてリンクエンドポイントのアドレス
Type I:
タイプI：
IPv6 Global Prefix with optional SR Algorithm for SRv6
SRV6のオプションのSRアルゴリズムを備えたIPv6グローバルプレフィックス
Type J:
タイプJ：
IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6
srv6用のローカル、リモートペアとしてのリンクエンドポイントのIPv6プレフィックスとインターフェイスID
Type K:
タイプK：
IPv6 Addresses for link endpoints as Local, Remote pair for SRv6
IPv6は、srv6のローカル、リモートペアとしてリンクエンドポイントのアドレス
The following subsections specify the sub-TLVs used for Segment Types A and B. The other segment types are specified in [RFC9831]. As specified in Section 5.1 of [RFC9256], a mix of SR-MPLS and SRv6 segments make the segment-list invalid.
次のサブセクションでは、セグメントタイプAおよびBに使用されるサブTLVを指定します。他のセグメントタイプは[RFC9831]で指定されています。[RFC9256]のセクション5.1で指定されているように、SR-MPLとSRV6セグメントの混合により、セグメントリストが無効になります。
The Type A Segment sub-TLV encodes a single SR-MPLS SID. The format is as follows and is used to encode MPLS Label fields as specified in [RFC3032] and [RFC5462]:
タイプAセグメントSub-TLVは、単一のSR-MPLS SIDをエンコードします。この形式は次のとおりであり、[RFC3032]および[RFC5462]で指定されているように、MPLSラベルフィールドをエンコードするために使用されます。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Type A Segment Sub-TLV
図11：タイプAセグメントサブTLV
Where:
ただし：
Type:
タイプ：
1
1
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 6.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は6でなければなりません。
Flags:
フラグ：
1 octet of flags as defined in Section 2.4.4.2.3.
セクション2.4.4.2.3で定義されているフラグのオクテット。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Label:
ラベル：
20 bits of label value.
20ビットのラベル値。
TC:
TC:
3 bits of traffic class.
3ビットのトラフィッククラス。
S:
S:
1 bit of bottom-of-stack.
1ビットのボトムオブボトム。
TTL:
TTL:
1 octet of TTL.
TTLの1オクテット。
The following applies to the Type-1 Segment sub-TLV:
以下は、Type-1セグメントSub-TLVに適用されます。
* The S bit MUST be zero upon transmission and MUST be ignored upon reception.
* Sビットは送信時にゼロでなければならず、受信時に無視する必要があります。
* If the originator wants the receiver to choose the TC value, it sets the TC field to zero.
* オリジネーターが受信機にTC値を選択することを望む場合、TCフィールドをゼロに設定します。
* If the originator wants the receiver to choose the TTL value, it sets the TTL field to 255.
* オリジネーターが受信機にTTL値を選択することを望む場合、TTLフィールドを255に設定します。
* If the originator wants to recommend a value for these fields, it puts those values in the TC and/or TTL fields.
* オリジネーターがこれらのフィールドに値を推奨したい場合、これらの値をTCおよび/またはTTLフィールドに配置します。
* The receiver MAY override the originator's values for these fields. This would be determined by local policy at the receiver. One possible policy would be to override the fields only if the fields have the default values specified above.
* 受信者は、これらのフィールドのオリジネーターの値をオーバーライドする場合があります。これは、レシーバーのローカルポリシーによって決定されます。可能なポリシーの1つは、フィールドに上記のデフォルト値がある場合にのみ、フィールドをオーバーライドすることです。
The Type B Segment sub-TLV encodes a single SRv6 SID. The format is as follows:
タイプBセグメントSub-TLVは、単一のSRV6 SIDをエンコードします。フォーマットは次のとおりです。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Type B Segment Sub-TLV
図12：タイプBセグメントサブTLV
Where:
ただし：
Type:
タイプ：
13
13
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 26 when the SRv6 Endpoint Behavior and SID Structure is present; else, it MUST be 18.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。SRV6エンドポイントの動作とSID構造が存在する場合、値は26でなければなりません。そうでなければ、18でなければなりません。
Flags:
フラグ：
1 octet of flags as defined in Section 2.4.4.2.3.
セクション2.4.4.2.3で定義されているフラグのオクテット。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
SRv6 SID:
SRV6 SID：
16 octets of IPv6 address.
IPv6アドレスの16オクテット。
SRv6 Endpoint Behavior and SID Structure:
SRV6エンドポイントの動作とSID構造：
Optional, as defined in Section 2.4.4.2.4. The SRv6 Endpoint Behavior and SID Structure MUST NOT be included when the SRv6 SID has not been included.
セクション2.4.4.2.4で定義されているように、オプション。SRV6 SIDが含まれていない場合、SRV6エンドポイントの動作とSID構造を含めてはなりません。
The sub-TLV code point 2 defined for the advertisement of Segment Type B in the earlier draft versions of this document has been deprecated to avoid backward compatibility issues.
このドキュメントの以前のドラフトバージョンのセグメントタイプBの広告に対して定義されたサブTLVコードポイント2は、後方互換性の問題を回避するために廃止されました。
The Segment Type sub-TLVs described above may contain the following SR Policy Segment Flags in their Flags field. Also refer to Section 6.8:
上記のセグメントタイプのサブTLVには、フラグフィールドに次のSRポリシーセグメントフラグが含まれる場合があります。セクション6.8も参照してください。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V| |B| |
+-+-+-+-+-+-+-+-+
Figure 13: SR Policy Segment Flags
図13：SRポリシーセグメントフラグ
Where:
ただし：
* When the V-Flag is set, it is used by SRPM for "SID verification" as described in Section 5.1 of [RFC9256].
* V-FLAGが設定されている場合、[RFC9256]のセクション5.1で説明されているように、「SID検証」にSRPMによって使用されます。
* When the B-Flag is set, it indicates the presence of the "SRv6 Endpoint Behavior & SID Structure" encoding specified in Section 2.4.4.2.4.
* B-FLAGが設定されると、セクション2.4.4.2.4で指定された「SRV6エンドポイントの動作とSID構造」の存在が示されます。
* The unassigned bits in the Flags field MUST be set to zero upon transmission and MUST be ignored upon receipt.
* フラグフィールドの未割り当てビットは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The following applies to the Segment Flags:
以下はセグメントフラグに適用されます。
* V-Flag applies to all Segment Types.
* V-Flagはすべてのセグメントタイプに適用されます。
* B-Flag applies to Segment Type B. If B-Flag appears with Segment Type A, it MUST be ignored.
* B-FLAGはセグメントタイプBに適用されます。B-FLAGがセグメントタイプAで表示される場合、無視する必要があります。
The Segment Type sub-TLVs described above MAY contain the SRv6 Endpoint Behavior and SID Structure [RFC8986] encoding as described below:
上記のセグメントタイプのサブTLVには、以下に説明するようにエンコードするSRV6エンドポイントの動作とSID構造[RFC8986]が含まれている場合があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SRv6 Endpoint Behavior and SID Structure
図14：SRV6エンドポイントの動作とSID構造
Where:
ただし：
Endpoint Behavior:
エンドポイントの動作：
2 octets. It carries the SRv6 Endpoint Behavior code point for this SRv6 SID as defined in Section 10.2 of [RFC8986]. When set with the value 0xFFFF (i.e., Opaque), the choice of SRv6 Endpoint Behavior is left to the headend.
2オクテット。[RFC8986]のセクション10.2で定義されているように、このSRV6 SIDのSRV6エンドポイントの動作コードポイントを運びます。値0xffff（つまり、不透明）で設定すると、SRV6エンドポイントの動作の選択がヘッドエンドに残されます。
Reserved:
予約済み：
2 octets of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの2オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Locator Block Length:
ロケーターブロック長：
1 octet. SRv6 SID Locator Block length in bits.
1オクテット。srv6 sidロケーターブロック長さのブロック長。
Locator Node Length:
ロケーターノード長：
1 octet. SRv6 SID Locator Node length in bits.
1オクテット。SRV6 SIDロケーターノード長さのビット。
Function Length:
関数の長さ：
1 octet. SRv6 SID Function length in bits.
1オクテット。SRV6 SID関数のビットの長さ。
Argument Length:
引数の長さ：
1 octet. SRv6 SID Arguments length in bits.
1オクテット。srv6 sid bits in bitsの長さ。
The total of the locator block, locator node, function, and argument lengths MUST be less than or equal to 128.
ロケーターブロック、ロケーターノード、機能、および引数の長さの合計は、128以下でなければなりません。
To steer an unlabeled IP packet into an SR Policy for the MPLS data plane, it is necessary to push a label stack of one or more labels on that packet.
Unbeled IPパケットをMPLSデータプレーンのSRポリシーに導くには、そのパケットに1つ以上のラベルのラベルスタックをプッシュする必要があります。
The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate whether an Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP packet before any other labels.
明示的なNULLラベルポリシー（ENLP）Sub-TLVを使用して、他のラベルの前に明示的なNULLラベル[RFC3032]を非標識IPパケットにプッシュする必要があるかどうかを示します。
If an ENLP sub-TLV is not present, the decision of whether to push an Explicit NULL label on a given packet is a matter of local configuration.
ENLP Sub-TLVが存在しない場合、特定のパケットに明示的なヌルラベルをプッシュするかどうかの決定は、ローカル構成の問題です。
The ENLP sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding.
ENLP Sub-TLVはオプションです。SRポリシーエンコーディングに複数回表示してはなりません。
The contents of this sub-TLV are used by the SRPM as described in Section 4.1 of [RFC9256].
このサブTLVの内容は、[RFC9256]のセクション4.1で説明されているように、SRPMによって使用されます。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENLP |
+-+-+-+-+-+-+-+-+
Figure 15: ENLP Sub-TLV
図15：ENLP Sub-TLV
Where:
ただし：
Type:
タイプ：
14
14
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 3.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は3でなければなりません。
Flags:
フラグ：
1 octet of flags. No flags are defined in this document. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.
旗の1オクテット。このドキュメントでは、フラグは定義されていません。フラグフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
ENLP (Explicit NULL Label Policy):
ENLP（明示的なヌルラベルポリシー）：
Indicates whether Explicit NULL labels are to be pushed on unlabeled IP packets that are being steered into a given SR Policy. The following values have been currently defined for this field:
明示的なNULLラベルが、特定のSRポリシーに操縦されている非標識IPパケットをプッシュするかどうかを示します。このフィールドでは、次の値が現在定義されています。
1:
1：
Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet but do not push an IPv6 Explicit NULL label on an unlabeled IPv6 packet.
ラベルのないIPv4パケットにIPv4 explicit nullラベルを押しますが、ラベルのないIPv6パケットにIPv6明示的なヌルラベルをプッシュしないでください。
2:
2：
Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet but do not push an IPv4 Explicit NULL label on an unlabeled IPv4 packet.
ラベルのないIPv6パケットにIPv6明示的なヌルラベルを押しますが、無効なIPv4パケットにIPv4明示ヌルラベルをプッシュしないでください。
3:
3：
Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet and push an IPv6 Explicit NULL label on an unlabeled IPv6 packet.
ラベルのないIPv4パケットにIPv4明示的なヌルラベルを押して、無効なIPv6パケットにIPv6明示的なヌルラベルを押します。
4:
4：
Do not push an Explicit NULL label.
明示的なヌルラベルを押さないでください。
This field can have one of the values as specified in Section 6.10. The ENLP unassigned values may be used for future extensions. Implementations adhering to this document MUST ignore the ENLP sub-TLV with unrecognized values (viz. other than 1 through 4). The behavior signaled in this sub-TLV MAY be overridden by local configuration by the network operator based on their deployment requirements. Section 4.1 of [RFC9256] describes the behavior on the headend for the handling of the Explicit NULL label.
このフィールドは、セクション6.10で指定されている値の1つを持つことができます。ENLP未割り当て値は、将来の拡張に使用できます。このドキュメントを順守する実装では、認識されていない値を持つENLP Sub-TLVを無視する必要があります（すなわち、1〜4以外）。このSub-TLVで合図された動作は、展開要件に基づいてネットワークオペレーターによってローカル構成によってオーバーライドされる場合があります。[RFC9256]のセクション4.1では、明示的なヌルラベルの処理のためのヘッドエンドの動作について説明します。
An operator MAY set the SR Policy Priority sub-TLV to indicate the order in which the SR policies are recomputed upon topological change. The contents of this sub-TLV are used by the SRPM as described in Section 2.12 of [RFC9256].
オペレーターは、SRポリシーの優先度サブTLVを設定して、SRポリシーがトポロジーの変化に再計算される順序を示すことができます。このサブTLVの内容は、[RFC9256]のセクション2.12で説明されているように、SRPMによって使用されます。
The Priority sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding.
優先サブTLVはオプションです。SRポリシーエンコーディングに複数回表示してはなりません。
The Priority sub-TLV has the following format:
優先度のサブTLVには、次の形式があります。
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 | Length | Priority | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Priority Sub-TLV
図16：優先サブTLV
Where:
ただし：
Type:
タイプ：
15
15
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 2.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は2でなければなりません。
Priority:
優先度：
A 1-octet value indicating the priority as specified in Section 2.12 of [RFC9256].
[RFC9256]のセクション2.12で指定されている優先度を示す1オクセット値。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
An operator MAY set the SR Policy Candidate Path Name sub-TLV to attach a symbolic name to the SR Policy CP.
オペレーターは、SRポリシー候補パス名Sub-TLVをSRポリシーCPに象徴的な名前を添付するように設定することができます。
Usage of the SR Policy Candidate Path Name sub-TLV is described in Section 2.6 of [RFC9256].
SRポリシー候補のパス名Sub-TLVの使用については、[RFC9256]のセクション2.6で説明されています。
The SR Policy Candidate Path Name sub-TLV may exceed 255 bytes in length due to a long name. A 2-octet length is thus required. According to Section 2 of [RFC9012], the sub-TLV type defines the size of the Length field. Therefore, for the SR Policy Candidate Path Name sub-TLV, a code point of 128 or higher is used.
SRポリシー候補のパス名Sub-TLVは、長い名前のために255バイトを超える長さを超える場合があります。したがって、2-OCTETの長さが必要です。[RFC9012]のセクション2によると、Sub-TLVタイプは長さフィールドのサイズを定義します。したがって、SRポリシー候補パス名Sub-TLVの場合、128以上のコードポイントが使用されます。
It is RECOMMENDED that the size of the symbolic name for the CP be limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes when signaling via BGP.
CPのシンボリック名のサイズを255バイトに制限することをお勧めします。実装は、BGPを介して信号を送信するときに、長い名前を255バイトに切り捨てることを選択できます。
The SR Policy Candidate Path Name sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding.
SRポリシー候補パス名Sub-TLVはオプションです。SRポリシーエンコーディングに複数回表示してはなりません。
The SR Policy Candidate Path Name sub-TLV has the following format:
SRポリシー候補パス名Sub-TLVには、次の形式があります。
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 | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SR Policy Candidate Path Name //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SR Policy Candidate Path Name Sub-TLV
図17：SRポリシー候補パス名Sub-TLV
Where:
ただし：
Type:
タイプ：
129
129
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value is variable.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は可変です。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
SR Policy Candidate Path Name:
SRポリシー候補パス名：
Symbolic name for the SR Policy CP without a NULL terminator with encoding as specified in Section 2.6 of [RFC9256].
[RFC9256]のセクション2.6で指定されているように、エンコードを備えたヌルターミネーターを備えたSRポリシーCPのシンボリック名。
An operator MAY set the SR Policy Name sub-TLV to associate a symbolic name with the SR Policy for which the CP is being advertised via the SR Policy NLRI.
オペレーターは、SRポリシー名Sub-TLVを設定して、SRポリシーNLRIを介してCPが宣伝されているSRポリシーに象徴的な名前を関連付けることができます。
Usage of the SR Policy Name sub-TLV is described in Section 2.1 of [RFC9256].
SRポリシー名Sub-TLVの使用法は、[RFC9256]のセクション2.1で説明されています。
The SR Policy Name sub-TLV may exceed 255 bytes in length due to a long SR Policy name. A 2-octet length is thus required. According to Section 2 of [RFC9012], the sub-TLV type defines the size of the Length field. Therefore, for the SR Policy Name sub-TLV, a code point of 128 or higher is used.
SRポリシー名Sub-TLVは、長いSRポリシー名のため、長さ255バイトを超える場合があります。したがって、2-OCTETの長さが必要です。[RFC9012]のセクション2によると、Sub-TLVタイプは長さフィールドのサイズを定義します。したがって、SRポリシー名Sub-TLVの場合、128以上のコードポイントが使用されます。
It is RECOMMENDED that the size of the symbolic name for the SR Policy be limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes when signaling via BGP.
SRポリシーのシンボリック名のサイズを255バイトに制限することをお勧めします。実装は、BGPを介して信号を送信するときに、長い名前を255バイトに切り捨てることを選択できます。
The SR Policy Name sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding.
SRポリシー名Sub-TLVはオプションです。SRポリシーエンコーディングに複数回表示してはなりません。
The SR Policy Name sub-TLV has the following format:
SRポリシー名Sub-TLVには、次の形式があります。
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 | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SR Policy Name //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SR Policy Name Sub-TLV
図18：SRポリシー名Sub-TLV
Where:
ただし：
Type:
タイプ：
130
130
Length:
長さ：
Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value is variable.
オクテットの観点から値フィールドの長さ（つまり、タイプと長さのフィールドは含まれない）を指定します。値は可変です。
RESERVED:
予約済み：
1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約ビットの1オクテット。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
SR Policy Name:
SRポリシー名：
Symbolic name for the SR Policy without a NULL terminator with encoding as specified in Section 2.1 of [RFC9256].
[RFC9256]のセクション2.1で指定されているように、エンコードを備えたヌルターミネーターを備えたSRポリシーのシンボリック名。
The Color Extended Community [RFC9012] is used to steer traffic corresponding to BGP routes into an SR Policy with matching Color value. The Color Extended Community MAY be carried in any BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (Ethernet VPN, usually known as EVPN). Use of the Color Extended Community in BGP UPDATE messages of other AFI/SAFIs is not covered by [RFC9012]; hence, it is outside the scope of this document as well.
Color Extended Community [RFC9012]を使用して、BGPルートに対応するトラフィックを、色値を一致させるSRポリシーに導きます。AFI/SAFIが1/1（IPv4ユニキャスト）、2/1（IPv6ユニキャスト）、1/4（IPV4ラベル付きユニキャスト）、2/4（IPv6ラベル付きユニキャスト）、1/128（VPN-IPV4 UNICAST）、UNCAST 2/128（VPN-IPV4）、2/128（VPN-IPV6）、VPN-IPV6）、VPN-IPV6）、VPN-IPV6）、2/128（VPN-IPV6）の任意のBGPアップデートメッセージで、色の拡張コミュニティを運ぶことができます。25/70（イーサネットVPN、通常はEVPNとして知られています）。他のAFI/SAFISのBGP更新メッセージでの色拡張コミュニティの使用は、[RFC9012]でカバーされていません。したがって、このドキュメントの範囲外にもあります。
Two bits from the Flags field of the Color Extended Community are used as follows to support the requirements of Color-Only steering as specified in Section 8.8 of [RFC9256]:
[RFC9256]のセクション8.8で指定されているように、色のみのステアリングの要件をサポートするために、色の拡張コミュニティのフラグフィールドから2ビットが次のように使用されます。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C O| Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Color Extended Community Flags
図19：色の拡張コミュニティフラグ
The C and O bits together form the Color-Only Type field, which indicates the various matching criteria between the BGP Next Hop (NH) and the SR Policy Endpoint in addition to the matching of the Color value. The following types are defined:
CとOビットは、色のみのタイプフィールドを形成します。これは、色値の一致に加えて、BGP Next Hop（NH）とSRポリシーエンドポイントの間のさまざまな一致基準を示します。次のタイプが定義されています。
Type 0 (bits 00):
タイプ0（ビット00）：
Specific Endpoint Match. Request a match for the Endpoint that is the BGP NH.
特定のエンドポイントマッチ。BGP NHであるエンドポイントの一致をリクエストします。
Type 1 (bits 01):
タイプ1（ビット01）：
Specific or Null Endpoint Match. Request a match for either the Endpoint that is the BGP NH or a null Endpoint (e.g., a default gateway).
特定またはヌルのエンドポイントマッチ。BGP NHまたはnullエンドポイント（デフォルトゲートウェイなど）であるエンドポイントの一致をリクエストします。
Type 2 (bits 10):
タイプ2（ビット10）：
Specific, Null, or Any Endpoint Match. Request a match for either the Endpoint that is the BGP NH or a null or any Endpoint.
特定、null、または任意のエンドポイントマッチ。BGP NHまたはnullまたは任意のエンドポイントであるエンドポイントの一致をリクエストします。
Type 3 (bits 11):
タイプ3（ビット11）：
Reserved for future use and SHOULD NOT be used. Upon reception, an implementation MUST treat it like Type 0.
将来の使用のために予約されており、使用しないでください。受信後、実装はタイプ0のように扱う必要があります。
The details of the SR Policy steering mechanisms based on these Color-Only types are specified in Section 8.8 of [RFC9256].
これらの色のみのタイプに基づいたSRポリシーステアリングメカニズムの詳細は、[RFC9256]のセクション8.8で指定されています。
One or more Color Extended Communities MAY be associated with a BGP route update. Sections 8.4.1, 8.5.1, and 8.8.2 of [RFC9256] specify the steering behaviors over SR Policies when multiple Color Extended Communities are associated with a BGP route.
1つ以上の色の拡張コミュニティは、BGPルートの更新に関連付けられている場合があります。[RFC9256]のセクション8.4.1、8.5.1、および8.8.2は、複数の色の拡張コミュニティがBGPルートに関連付けられている場合、SRポリシーに対するステアリング行動を指定します。
As mentioned in Section 1, BGP is not the actual consumer of an SR Policy NLRI. BGP is in charge of the origination and propagation of the SR Policy NLRI, but its installation and use are outside the scope of BGP. The details of SR Policy installation and use are specified in [RFC9256].
セクション1で述べたように、BGPはSRポリシーNLRIの実際の消費者ではありません。BGPは、SRポリシーNLRIの起源と伝播を担当していますが、その設置と使用はBGPの範囲外です。SRポリシーのインストールと使用の詳細は[RFC9256]で指定されています。
Typically, but not limited to, an SR Policy is computed by a controller or a Path Computation Engine (PCE) and originated by a BGP speaker on its behalf.
通常、SRポリシーはコントローラーまたはパス計算エンジン（PCE）によって計算され、BGPスピーカーが代表して発信されます。
Multiple SR Policy NLRIs may be present with the same <Color, Endpoint> tuple but with different distinguishers when these SR policies are intended for different headends.
複数のSRポリシーNLRIは、同じ<色、エンドポイント>タプルで存在する場合がありますが、これらのSRポリシーが異なるヘッドエンドを対象としている場合、異なる違いを備えています。
The distinguisher of each SR Policy NLRI prevents undesired BGP route selection among these SR Policy NLRIs and allows their propagation across RRs [RFC4456].
各SRポリシーNLRIの識別装置は、これらのSRポリシーNLRI間の望ましくないBGPルートの選択を防ぎ、RRS全体で伝播を可能にします[RFC4456]。
Moreover, one or more route targets SHOULD be attached to the advertisement, where each route target identifies one or more intended headends for the advertised SR Policy update.
さらに、1つ以上のルートターゲットを広告に添付する必要があります。各ルートターゲットは、広告されたSRポリシーアップデートの1つ以上の意図されたヘッドエンドを識別します。
If no route target is attached to the SR Policy NLRI, then it is assumed that the originator sends the SR Policy update directly (e.g., through a BGP session) to the intended receiver. In such a case, the NO_ADVERTISE community [RFC1997] MUST be attached to the SR Policy update (see further details in Section 4.2.3).
SRポリシーNLRIにルートターゲットが添付されていない場合、オリジネーターはSRポリシーの更新（たとえば、BGPセッションを介して）を意図したレシーバーに直接送信すると想定されます。そのような場合、NO_Advertiseコミュニティ[RFC1997]をSRポリシーの更新に添付する必要があります（詳細4.2.3の詳細を参照）。
On reception of an SR Policy NLRI, a BGP speaker first determines if it is valid as described in Section 4.2.1; then, the BGP speaker performs the decision process for selection of the best route (Section 9.1 of [RFC4271]). The key difference from the base BGP decision process is that BGP does not download the selected best routes of the SR Policy SAFI into the forwarding; instead, it considers them "usable" for passing on to the SRPM for further processing as described in Section 4.2.2. The selected best route is "propagated" (Section 9.1.3 of [RFC4271]) as described in Section 4.2.3, irrespective of its "usability" by the local router.
SRポリシーNLRIの受信時に、BGPスピーカーは、最初にセクション4.2.1で説明されているように有効かどうかを判断します。次に、BGPスピーカーは、最適なルートを選択するための決定プロセスを実行します（[RFC4271]のセクション9.1）。基本BGP決定プロセスとの重要な違いは、BGPがSRポリシーSAFIの選択した最良のルートを転送にダウンロードしないことです。代わりに、セクション4.2.2で説明されているように、さらなる処理のためにSRPMに渡すためにそれらを「使用可能」と見なします。選択された最良のルートは、地元のルーターによる「使いやすさ」に関係なく、セクション4.2.3で説明されているように、「伝播」されています（[RFC4271]のセクション9.1.3）。
When a BGP speaker receives an SR Policy NLRI from a neighbor, it MUST first perform validation based on the following rules in addition to the validation described in Section 5:
BGPスピーカーが隣人からSRポリシーNLRIを受信する場合、セクション5で説明されている検証に加えて、最初に次のルールに基づいて検証を実行する必要があります。
* The SR Policy NLRI MUST include a distinguisher, Color, and Endpoint field that implies that the length of the NLRI MUST be either 12 or 24 octets (depending on the address family of the Endpoint).
* SRポリシーNLRIには、NLRIの長さが12オクターまたは24オクテットでなければならないことを意味する識別装置、色、およびエンドポイントフィールドを含める必要があります（エンドポイントのアドレスファミリーによって異なります）。
* The SR Policy update MUST have either the NO_ADVERTISE community, at least one Route Target extended community in IPv4-address format, or both. If a router supporting this specification receives an SR Policy update with no Route Target extended communities and no NO_ADVERTISE community, the update MUST be considered to be malformed.
* SRポリシーの更新には、NO_Advertiseコミュニティ、少なくとも1つのルートターゲット拡張コミュニティがIPv4-Address形式で拡張されたコミュニティ、またはその両方が必要です。この仕様をサポートするルーターが、ルートターゲットの拡張コミュニティとNO_AdvertiseコミュニティなしのSRポリシーアップデートを受信する場合、更新は奇形と見なされる必要があります。
* The Tunnel Encapsulation Attribute MUST be attached to the BGP UPDATE message and MUST have a Tunnel Type TLV set to SR Policy (code point is 15).
* トンネルカプセル化属性は、BGP更新メッセージに添付する必要があり、SRポリシーに設定されたトンネルタイプTLVが必要です（コードポイントは15）。
A router that receives an SR Policy update that is not valid according to these criteria MUST treat the update as malformed, and the SR Policy CP MUST NOT be passed to the SRPM.
これらの基準に従って有効でないSRポリシーアップデートを受信するルーターは、更新を奇形として扱う必要があり、SRポリシーCPをSRPMに渡すことはできません。
An SR Policy NLRI update that does not have a Route Target extended community but does have the NO_ADVERTISE community is considered usable.
Route Target Extended Communityを持たないが、NO_Advertiseコミュニティがあると見なされるSRポリシーNLRIアップデートは、使用可能と見なされます。
If one or more route targets are present, then at least one route target MUST match the BGP Identifier of the receiver for the update to be considered usable. The BGP Identifier is defined in [RFC4271] as a 4-octet IPv4 address and is updated by [RFC6286] as a 4-octet, unsigned, non-zero integer. Therefore, the Route Target extended community MUST be of the same format.
1つ以上のルートターゲットが存在する場合、更新が使用可能と見なされるために、少なくとも1つのルートターゲットが受信機のBGP識別子と一致する必要があります。BGP識別子は、[RFC4271]で4-OCTET IPv4アドレスとして定義され、[RFC6286]によって4-OCTET、符号なしの非ゼロ整数として更新されます。したがって、ルートターゲット拡張コミュニティは同じ形式でなければなりません。
If one or more route targets are present, and none matches the local BGP Identifier, then, while the SR Policy NLRI is valid, the SR Policy NLRI is not usable on the receiver node.
1つ以上のルートターゲットが存在し、ローカルBGP識別子と一致するものがない場合、SRポリシーNLRIは有効ですが、SRポリシーNLRIはレシーバーノードで使用できません。
When the SR Policy tunnel type includes any sub-TLV that is unrecognized or unsupported, the update SHOULD NOT be considered usable. An implementation MAY provide an option for ignoring unsupported sub-TLVs.
SRポリシートンネルタイプに、認識されていない、またはサポートされていないサブTLVが含まれている場合、更新は使用可能と見なされるべきではありません。実装は、サポートされていないサブTLVを無視するためのオプションを提供する場合があります。
Once BGP on the receiving node has determined that the SR Policy NLRI is usable, it passes the SR Policy CP to the SRPM. Note that, along with the CP details, BGP also passes the originator information for breaking ties in the CP selection process as described in Section 2.4 of [RFC9256].
受信ノードのBGPがSRポリシーNLRIが使用可能であると判断すると、SRポリシーCPをSRPMに渡します。CPの詳細とともに、BGPは[RFC9256]のセクション2.4で説明されているように、CP選択プロセスの結びつきを破るためのオリジネーター情報も渡すことに注意してください。
When an update for an SR Policy NLRI results in its becoming unusable, BGP MUST delete its corresponding SR Policy CP from the SRPM.
SRポリシーNLRIの更新が使用できなくなると、BGPはSRPMから対応するSRポリシーCPを削除する必要があります。
The SRPM applies the rules defined in Section 2 of [RFC9256] to determine whether the SR Policy CP is valid and to select the active CP for a given SR Policy.
SRPMは、[RFC9256]のセクション2で定義されているルールを適用して、SRポリシーCPが有効かどうかを判断し、特定のSRポリシーのアクティブなCPを選択します。
SR Policy NLRIs that have the NO_ADVERTISE community attached to them MUST NOT be propagated.
no_advertiseコミュニティがそれらに添付されているSrポリシーNLRISを伝播してはなりません。
By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate it to any External BGP (EBGP) neighbor. An implementation MAY provide an explicit configuration to override this and enable the propagation of valid SR Policy NLRIs to specific EBGP neighbors where the SR domain comprises multiple ASes within a single service provider domain (see Section 7 for details).
デフォルトでは、SRポリシーNLRIを受信するBGPノードは、外部BGP（EBGP）隣人に伝播してはなりません。実装は、これをオーバーライドし、SRドメインが単一のサービスプロバイダードメイン内の複数のASEを含む特定のEBGP近隣に有効なSRポリシーNLRIの伝播を可能にする明示的な構成を提供する場合があります（詳細についてはセクション7を参照）。
A BGP node advertises a received SR Policy NLRI to its Internal BGP (IBGP) neighbors according to normal IBGP propagation rules.
BGPノードは、通常のIBGP伝播ルールに従って、内部BGP（IBGP）の隣人に対して受信したSRポリシーNLRIを宣伝します。
By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove the Route Target extended community before propagation. An implementation MAY provide support for configuration to filter and/or remove the Route Target extended community before propagation.
デフォルトでは、SRポリシーNLRIを受信するBGPノードは、伝播前にルートターゲット拡張コミュニティを削除すべきではありません。実装は、伝播前にルートターゲット拡張コミュニティをフィルタリングおよび/または削除する構成のサポートを提供する場合があります。
A BGP node MUST NOT alter the SR Policy information carried in the Tunnel Encapsulation Attribute during propagation.
BGPノードは、伝播中にトンネルカプセル化属性にあるSRポリシー情報を変更してはなりません。
This section describes the error-handling actions, as described in [RFC7606], that are to be performed for the handling of the BGP UPDATE messages for the BGP SR Policy SAFI.
このセクションでは、[RFC7606]で説明されているように、BGP SRポリシーSafiのBGP更新メッセージの処理のために実行されるエラー処理アクションについて説明します。
A BGP speaker MUST perform the following syntactic validation of the SR Policy NLRI to determine if it is malformed. This includes the validation of the length of each NLRI and the total length of the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the validation of the consistency of the NLRI length with the AFI and the endpoint address as specified in Section 2.1.
BGPスピーカーは、SRポリシーNLRIの次の構文検証を実行して、それが奇形であるかどうかを判断する必要があります。これには、各NLRIの長さの検証と、MP_REACH_NLRIおよびMP_UNREACH_NLRI属性の全長が含まれます。また、セクション2.1で指定されているように、NLRI長のAFIとエンドポイントアドレスの一貫性の検証も含まれます。
When the error determined allows for the router to skip the malformed NLRI(s) and continue the processing of the rest of the BGP UPDATE message, then it MUST handle such malformed NLRIs as 'treat-as-withdraw'. In other cases, where the error in the NLRI encoding results in the inability to process the BGP UPDATE message (e.g., length-related encoding errors), then the router SHOULD handle such malformed NLRIs as "AFI/SAFI disable" when other AFI/SAFIs besides SR Policy are being advertised over the same session. Alternately, the router MUST perform "session reset" when the session is only being used for SR Policy or when a "AFI/SAFI disable" action is not possible.
エラーが決定された場合、ルーターが奇形のNLRIをスキップし、BGPアップデートメッセージの残りの部分の処理を継続できるようになった場合、そのような奇形のNLRIを「withdraw」と扱う必要があります。他のケースでは、NLRIエンコードのエラーがBGP更新メッセージ（長さ関連エンコードエラーなど）を処理できない場合、ルーターは、SRポリシー以外の他のAFI/SAFIが同じセッションで宣伝されている場合、「AFI/SAFI無効」としてそのような奇形NLRIを処理する必要があります。あるいは、セッションがSRポリシーにのみ使用されている場合、または「AFI/SAFI無効」アクションが不可能な場合、ルーターは「セッションリセット」を実行する必要があります。
The validation of the TLVs/sub-TLVs introduced in this document and defined in their respective subsections of Section 2.4 MUST be performed to determine if they are malformed or invalid. The validation of the Tunnel Encapsulation Attribute itself and the other TLVs/sub-TLVs specified in Section 13 of [RFC9012] MUST be done as described in that document. In case of any error detected, either at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw" strategy MUST be applied. This is because an SR Policy update without a valid Tunnel Encapsulation Attribute (comprised of all valid TLVs/sub-TLVs) is not usable.
このドキュメントで導入され、セクション2.4のそれぞれのサブセクションで定義されたTLVS/SUB-TLVの検証は、それらが奇形であるか無効かを判断するために実行する必要があります。[RFC9012]のセクション13で指定されているトンネルカプセル化属性自体と他のTLV/Sub-TLVの検証は、そのドキュメントで説明されているように行う必要があります。属性またはそのTLV/Sub-TLVレベルのいずれかで検出されたエラーが検出された場合、「服用としての扱い」戦略を適用する必要があります。これは、有効なトンネルカプセル化属性（すべての有効なTLV/Sub-TLVで構成される）のないSRポリシーの更新が使用できないためです。
An SR Policy update that is determined not to be valid (and, therefore, malformed) based on the rules described in Section 4.2.1 MUST be handled by the "treat-as-withdraw" strategy.
セクション4.2.1で説明されているルールに基づいて有効ではない（したがって、奇形）と判断されたSRポリシーの更新は、「draw-as-withdraw」戦略で処理する必要があります。
The validation of the individual fields of the TLVs/sub-TLVs defined in Section 2.4 are beyond the scope of BGP as they are handled by the SRPM as described in the individual TLV/sub-TLV subsections. A BGP implementation MUST NOT perform semantic verification of such fields nor consider the SR Policy update to be invalid or not usable based on such validation.
セクション2.4で定義されたTLV/Sub-TLVの個々のフィールドの検証は、個々のTLV/Sub-TLVサブセクションで説明されているように、SRPMによって処理されるBGPの範囲を超えています。BGPの実装は、そのようなフィールドのセマンティック検証を実行したり、SRポリシーの更新がそのような検証に基づいて無効であるか、使用できないと考えてはなりません。
An implementation SHOULD log any errors found during the above validation for further analysis.
実装は、上記の検証中に見つかったエラーを記録して、さらなる分析を行う必要があります。
This document uses code point allocations from the following existing registries in the "Subsequent Address Family Identifiers (SAFI) Parameters" registry group:
このドキュメントでは、次の既存のレジストリからのコードポイント割り当てを「後続のアドレスファミリ識別子（SAFI）パラメーター」レジストリグループに使用します。
* The "SAFI Values" registry
* 「Safi Values」レジストリ
This document uses code point allocations from the following existing registries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group:
このドキュメントでは、「Border Gateway Protocol（BGP）トンネルカプセル化」の次の既存のレジストリからのコードポイント割り当てを使用しています。
* The "BGP Tunnel Encapsulation Attribute Tunnel Types" registry
* 「BGPトンネルカプセル化属性トンネルタイプ」レジストリ
* The "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry
* 「BGPトンネルカプセル化属性サブTLVS」レジストリ
* The "Color Extended Community Flags" registry
* 「Color Extended Community Flags」レジストリ
This document creates the following new registries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group:
このドキュメントでは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループに次の新しいレジストリを作成します。
* The "SR Policy Segment List Sub-TLVs" registry
* 「SRポリシーセグメントリストサブTLV」レジストリ
* The "SR Policy Binding SID Flags" registry
* 「SRポリシーバインドSIDフラグ」レジストリ
* The "SR Policy SRv6 Binding SID Flags" registry
* 「SRポリシーSRV6バインディングSIDフラグ」レジストリ
* The "SR Policy Segment Flags" registry
* 「SRポリシーセグメントフラグ」レジストリ
* The "Color Extended Community Color-Only Types" registry
* 「Color Extended Community Colorのみタイプ」レジストリ
This document creates the following new registry in the "Segment Routing" registry group:
このドキュメントは、「セグメントルーティング」レジストリグループに次の新しいレジストリを作成します。
* The "SR Policy ENLP Values" registry
* 「SRポリシーENLP値」レジストリ
This document registers a SAFI code point in the "SAFI Values" registry of the "Subsequent Address Family Identifiers (SAFI) Parameters" registry group as follows:
このドキュメントは、「後続のアドレスファミリ識別子（SAFI）パラメーター」レジストリグループの「SAFI値」レジストリのSAFIコードポイントを次のように登録します。
+=======+================+===========+
| Value | Description | Reference |
+=======+================+===========+
| 73 | SR Policy SAFI | RFC 9830 |
+-------+----------------+-----------+
Table 1: BGP SAFI Code Point
表1：BGP SAFIコードポイント
This document registers a Tunnel Type code point in the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.
このドキュメントは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループの下の「BGPトンネルカプセル化属性トンネルタイプ」レジストリのトンネルタイプコードポイントを登録します。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 15 | SR Policy | RFC 9830 |
+-------+-------------+-----------+
Table 2: Tunnel Type Code Point
表2：トンネルタイプコードポイント
This document defines sub-TLVs in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.
このドキュメントは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループの下の「BGPトンネルカプセル化属性サブTLVS」レジストリのサブTLVを定義します。
+=======+==========================+===========+===================+
| Value | Description | Reference | Change Controller |
+=======+==========================+===========+===================+
| 12 | Preference sub-TLV | RFC 9830 | IETF |
+-------+--------------------------+-----------+-------------------+
| 13 | Binding SID sub-TLV | RFC 9830 | IETF |
+-------+--------------------------+-----------+-------------------+
| 14 | ENLP sub-TLV | RFC 9830 | IETF |
+-------+--------------------------+-----------+-------------------+
| 15 | Priority sub-TLV | RFC 9830 | IETF |
+-------+--------------------------+-----------+-------------------+
| 20 | SRv6 Binding SID sub-TLV | RFC 9830 | IETF |
+-------+--------------------------+-----------+-------------------+
| 128 | Segment List sub-TLV | RFC 9830 | IETF |
+-------+--------------------------+-----------+-------------------+
| 129 | SR Policy Candidate Path | RFC 9830 | IETF |
| | Name sub-TLV | | |
+-------+--------------------------+-----------+-------------------+
| 130 | SR Policy Name sub-TLV | RFC 9830 | IETF |
+-------+--------------------------+-----------+-------------------+
Table 3: BGP Tunnel Encapsulation Attribute Sub-TLV Code Points
表3：BGPトンネルカプセル化属性サブTLVコードポイント
This document defines the use of 2 bits in the "Color Extended Community Flags" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.
このドキュメントでは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループの下で、「Color Extended Community Flags」レジストリで2ビットの使用を定義しています。
+==============+========================+===========+
| Bit Position | Description | Reference |
+==============+========================+===========+
| 0-1 | Color-only Types Field | RFC 9830 |
+--------------+------------------------+-----------+
Table 4: Color Extended Community Flag Bits
表4：色の拡張コミュニティフラグビット
This document creates a new registry called "SR Policy Segment List Sub-TLVs" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. The registration policy of this registry is "IETF Review" (see [RFC8126]).
このドキュメントは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループの下に「SRポリシーセグメントリストサブTLV」と呼ばれる新しいレジストリを作成します。このレジストリの登録ポリシーは「IETFレビュー」です（[RFC8126]を参照）。
The following initial sub-TLV code points are assigned by this document:
次の最初のサブTLVコードポイントは、このドキュメントによって割り当てられます。
+========+========================+===========+
| Value | Description | Reference |
+========+========================+===========+
| 0 | Reserved | RFC 9830 |
+--------+------------------------+-----------+
| 1 | Type A Segment sub-TLV | RFC 9830 |
+--------+------------------------+-----------+
| 2 | Deprecated | RFC 9830 |
+--------+------------------------+-----------+
| 3-8 | Unassigned |
+--------+------------------------+-----------+
| 9 | Weight sub-TLV | RFC 9830 |
+--------+------------------------+-----------+
| 10 | Deprecated | RFC 9830 |
+--------+------------------------+-----------+
| 11 | Deprecated | RFC 9830 |
+--------+------------------------+-----------+
| 12 | Deprecated | RFC 9830 |
+--------+------------------------+-----------+
| 13 | Type B Segment sub-TLV | RFC 9830 |
+--------+------------------------+-----------+
| 14-255 | Unassigned |
+--------+------------------------------------+
Table 5: SR Policy Segment List Sub-TLV Code Points
表5：SRポリシーセグメントリストサブTLVコードポイント
This document creates a new registry called "SR Policy Binding SID Flags" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. The registration policy of this registry is "Standards Action" (see [RFC8126]).
このドキュメントは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループの下に「SRポリシーバインドSIDフラグ」と呼ばれる新しいレジストリを作成します。このレジストリの登録ポリシーは「標準アクション」です（[RFC8126]を参照）。
The following flags are defined:
次のフラグが定義されています。
+=====+===================================+===========+
| Bit | Description | Reference |
+=====+===================================+===========+
| 0 | Specified-BSID-Only Flag (S-Flag) | RFC 9830 |
+-----+-----------------------------------+-----------+
| 1 | Drop-Upon-Invalid Flag (I-Flag) | RFC 9830 |
+-----+-----------------------------------+-----------+
| 2-7 | Unassigned |
+-----+-----------------------------------------------+
Table 6: SR Policy Binding SID Flags
表6：SRポリシーバインディングSIDフラグ
This document creates a new registry called "SR Policy SRv6 Binding SID Flags" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. The registration policy of this registry is "Standards Action" (see [RFC8126]).
このドキュメントでは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループの下で、「SRポリシーSRV6 Binding SID Flags」と呼ばれる新しいレジストリを作成します。このレジストリの登録ポリシーは「標準アクション」です（[RFC8126]を参照）。
The following flags are defined:
次のフラグが定義されています。
+=====+===================================+===========+
| Bit | Description | Reference |
+=====+===================================+===========+
| 0 | Specified-BSID-Only Flag (S-Flag) | RFC 9830 |
+-----+-----------------------------------+-----------+
| 1 | Drop-Upon-Invalid Flag (I-Flag) | RFC 9830 |
+-----+-----------------------------------+-----------+
| 2 | SRv6 Endpoint Behavior & SID | RFC 9830 |
| | Structure Flag (B-Flag) | |
+-----+-----------------------------------+-----------+
| 3-7 | Unassigned |
+-----+-----------------------------------------------+
Table 7: SR Policy SRv6 Binding SID Flags
表7：SRポリシーSRV6バインディングSIDフラグ
This document creates a new registry called "SR Policy Segment Flags" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. The registration policy of this registry is "IETF Review" (see [RFC8126]).
このドキュメントは、「Border Gateway Protocol（BGP）トンネルカプセル化」レジストリグループの下に「SRポリシーセグメントフラグ」と呼ばれる新しいレジストリを作成します。このレジストリの登録ポリシーは「IETFレビュー」です（[RFC8126]を参照）。
The following flags are defined:
次のフラグが定義されています。
+=====+====================================+===========+
| Bit | Description | Reference |
+=====+====================================+===========+
| 0 | Segment Verification Flag (V-Flag) | RFC 9830 |
+-----+------------------------------------+-----------+
| 1-2 | Unassigned |
+-----+------------------------------------+-----------+
| 3 | SRv6 Endpoint Behavior & SID | RFC 9830 |
| | Structure Flag (B-Flag) | |
+-----+------------------------------------+-----------+
| 4-7 | Unassigned |
+-----+------------------------------------------------+
Table 8: SR Policy Segment Flags
表8：SRポリシーセグメントフラグ
This document creates a new registry called "Color Extended Community Color-Only Types" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group for assignment of code points (values 0 through 3) in the Color-Only Type field of the Color Extended Community Flags field. The registration policy of this registry is "Standards Action" (see [RFC8126]).
このドキュメントでは、「Border Gateway Protocol（BGP）トンネルカプセル化」の下に「Color Extended Communityのみのカラーのみタイプ」と呼ばれる新しいレジストリを作成します。レジストリグループは、色の拡張コミュニティフラグフィールドの色のみのフィールドにコードポイント（値0〜3）の割り当てのためのレジストリグループです。このレジストリの登録ポリシーは「標準アクション」です（[RFC8126]を参照）。
The following types are defined:
次のタイプが定義されています。
+======+=======================================+===========+
| Type | Description | Reference |
+======+=======================================+===========+
| 0 | Specific Endpoint Match | RFC 9830 |
+------+---------------------------------------+-----------+
| 1 | Specific or Null Endpoint Match | RFC 9830 |
+------+---------------------------------------+-----------+
| 2 | Specific, Null, or Any Endpoint Match | RFC 9830 |
+------+---------------------------------------+-----------+
| 3 | Unassigned | RFC 9830 |
+------+---------------------------------------+-----------+
Table 9: Color Extended Community Color-Only Types
表9：色の拡張コミュニティの色のみタイプ
IANA will maintain a new registry under the "Segment Routing" registry group with the registration policy of "Standards Action" (see [RFC8126]). The new registry is called "SR Policy ENLP Values" and contains the code points allocated to the ENLP field defined in Section 2.4.5. The registry contains the following code points:
IANAは、「標準アクション」の登録ポリシーを備えた「セグメントルーティング」レジストリグループの下で新しいレジストリを維持します（[RFC8126]を参照）。新しいレジストリは「SRポリシーENLP値」と呼ばれ、セクション2.4.5で定義されているENLPフィールドに割り当てられたコードポイントが含まれています。レジストリには、次のコードポイントが含まれています。
+=======+===================================+===========+
| Code | Description | Reference |
| Point | | |
+=======+===================================+===========+
| 0 | Reserved | RFC 9830 |
+-------+-----------------------------------+-----------+
| 1 | Push an IPv4 Explicit NULL label | RFC 9830 |
| | on an unlabeled IPv4 packet but | |
| | do not push an IPv6 Explicit NULL | |
| | label on an unlabeled IPv6 packet | |
+-------+-----------------------------------+-----------+
| 2 | Push an IPv6 Explicit NULL label | RFC 9830 |
| | on an unlabeled IPv6 packet but | |
| | do not push an IPv4 Explicit NULL | |
| | label on an unlabeled IPv4 packet | |
+-------+-----------------------------------+-----------+
| 3 | Push an IPv6 Explicit NULL label | RFC 9830 |
| | on an unlabeled IPv6 packet and | |
| | push an IPv4 Explicit NULL label | |
| | on an unlabeled IPv4 packet | |
+-------+-----------------------------------+-----------+
| 4 | Do not push an Explicit NULL | RFC 9830 |
| | label | |
+-------+-----------------------------------+-----------+
| 5-255 | Unassigned |
+-------+-----------------------------------------------+
Table 10: SR Policy ENLP Values
表10：SRポリシーENLP値
The security mechanisms of the base BGP security model apply to the extensions described in this document as well. See the Security Considerations section of [RFC4271] for a discussion of BGP security. Also, refer to [RFC4272] and [RFC6952] for analysis of security issues for BGP.
ベースBGPセキュリティモデルのセキュリティメカニズムは、このドキュメントで説明されている拡張機能にも適用されます。BGPセキュリティの議論については、[RFC4271]のセキュリティに関する考慮事項セクションを参照してください。また、BGPのセキュリティ問題の分析については、[RFC4272]および[RFC6952]を参照してください。
The BGP SR Policy extensions specified in this document enable traffic engineering and service programming use cases within an SR domain as described in [RFC9256]. SR operates within a trusted SR domain [RFC8402]; its security considerations also apply to BGP sessions when carrying SR Policy information. The SR Policies distributed by BGP are expected to be used entirely within this trusted SR domain, which comprises a single AS or multiple ASes / domains within a single provider network. Therefore, precaution is necessary to ensure that the SR Policy information advertised via BGP sessions is limited to nodes in a secure manner within this trusted SR domain. BGP peering sessions for address families other than those that use the SR Policy SAFI may be set up to routers outside the SR domain. The isolation of BGP SR Policy SAFI peering sessions may be used to ensure that the SR Policy information is not advertised by accident or in error to an EBGP peering session outside the SR domain.
このドキュメントで指定されたBGP SRポリシー拡張は、[RFC9256]で説明されているように、SRドメイン内のトラフィックエンジニアリングおよびサービスプログラミングの使用ケースを可能にします。SRは、信頼できるSRドメイン[RFC8402]内で動作します。セキュリティ上の考慮事項は、SRポリシー情報を実施する際のBGPセッションにも適用されます。BGPによって配布されるSRポリシーは、単一のプロバイダーネットワーク内の単一または複数のASES /ドメインを含むこの信頼できるSRドメイン内で完全に使用されることが期待されています。したがって、BGPセッションを介して宣伝されているSRポリシー情報が、この信頼できるSRドメイン内で安全な方法でノードに限定されることを保証するために予防策が必要です。SRポリシーSAFIを使用するファミリー以外の住所ファミリーのBGPピアリングセッションは、SRドメインの外側のルーターに設定される場合があります。BGP SRポリシーSAFIピアリングセッションの分離を使用して、SRポリシー情報がSRドメイン外のEBGPピアリングセッションに偶然または誤って宣伝されないようにすることができます。
Additionally, it may be a consideration that the export of SR Policy information, as described in this document, constitutes a risk to confidentiality of mission-critical or commercially sensitive information about the network (more specifically endpoint/node addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted nodes (that include both routers and controller applications) within the SR domain are configured to receive such information.
さらに、このドキュメントに記載されているように、SRポリシー情報のエクスポートが、ネットワークに関するミッションクリティカルまたは商業的に機密性の高い情報の機密性に対するリスクを構成することを考慮している可能性があります（より具体的にはエンドポイント/ノードアドレス、SR SID、およびSRポリシーが展開されたSRポリシー）。BGPピーリングは自動ではなく、構成が必要です。したがって、SRドメイン内の信頼できるノード（ルーターとコントローラーアプリケーションの両方を含む）のみがそのような情報を受信するように構成されていることを保証することは、ネットワークオペレーターの責任です。
The specification of BGP models is an ongoing work based on [BGP-YANG-MODEL]; its future extensions are expected to cover the SR Policy SAFI. Existing BGP operational procedures also apply to the SAFI specified in this document. The management, operations, and monitoring of BGP speakers and the SR Policy SAFI sessions between them are not very different from other BGP sessions and can be managed using the same data models.
BGPモデルの仕様は、[BGP-Yang-Model]に基づいた継続的な作業です。その将来の拡張は、SRポリシーSafiをカバーすることが期待されています。既存のBGP運用手順は、このドキュメントで指定されたSAFIにも適用されます。BGPスピーカーの管理、運用、監視、およびそれらの間のSRポリシーサフィセッションは、他のBGPセッションとそれほど違いはなく、同じデータモデルを使用して管理できます。
The YANG data model for the operation and management of SR Policies [SR-POLICY-YANG] reports the SR Policies provisioned via BGP SR Policy SAFI along with their operational states.
SRポリシー[SR-Policy-Yang]の運用と管理のためのYangデータモデルは、BGP SRポリシーSafiとその運用状態を介して提供されたSRポリシーを報告しています。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.
[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>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999,
<https://www.rfc-editor.org/info/rfc2545>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[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>.
[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>.
[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>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[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>.
[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>.
[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>.
[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>.
[BGP-LS-SR-POLICY]
Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H.,
and J. Tantsura, "Advertisement of Segment Routing
Policies using BGP Link-State", Work in Progress,
Internet-Draft, draft-ietf-idr-bgp-ls-sr-policy-17, 6
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-idr-bgp-ls-sr-policy-17>.
[BGP-YANG-MODEL]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "YANG
Model for Border Gateway Protocol (BGP-4)", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-model-18, 21
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-idr-bgp-model-18>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[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>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[RFC9831] Talaulikar, K., Ed., Filsfils, C., Previdi, S., Mattes,
P., and D. Jain, "Segment Type Extensions for BGP Segment
Routing (SR) Policy", RFC 9831, DOI 10.17487/RFC9831,
September 2025, <https://www.rfc-editor.org/info/rfc9831>.
[SR-POLICY-YANG]
Raza, K., Ed., Saleh, T., Shunwan, Z., Voyer, D., Durrani,
M., Matsushima, S., and V. Beeram, "YANG Data Model for
Segment Routing Policy", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-policy-yang-05, 25 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-05>.
The authors of this document would like to thank Shyam Sethuram, John Scudder, Przemyslaw Krol, Alex id Bogdanov, Nandan Saha, Bruno Decraene, Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, Jakob Heitz, Viral Patel, Peng Shaofu, Cheng Li, Martin Vigoureux, John Scudder, Vincent Roca, Brian Haberman, Mohamed Boucadair, Shunwan Zhuang, Andrew Alston, Jeffrey (Zhaohui) Zhang, Nagendra Nainar, Rajesh Melarcode Venkateswaran, Nat Kao, Boris Hassanov, Vincent Roca, Russ Housley, and Dan Romascanu for their comments and review of this document. The authors would like to thank Susan Hares for her detailed shepherd review that helped in improving the document.
この文書の著者は、Shyam Sethuram、John Scudder、Przemyslaw Krol、Alex ID Bogdanov、Nandan Saha、Bruno Decraene、Gurusiddesh Nidasesi、Kausik Majumdar、Zafar Ali、Swadesh Agarwal、Jakob Heitz、Viral Patel、Peeng heitz、Jakob Heitz、Scudder、Vincent Roca、Brian Haberman、Mohamed Boucadair、Shunwan Zhuang、Andrew Alston、Jeffrey（Zhaohui）Zhang、Nagendra Nainar、Rajesh Melarcode Venkateswaran、Nat Kao、Boris hassanov、vincent roca for dan著者は、ドキュメントの改善に役立った彼女の詳細な羊飼いのレビューについて、スーザン・ホレスに感謝したいと思います。
Eric Rosen
Juniper Networks
United States of America
Email: erosen@juniper.net
Arjun Sreekantiah
Cisco Systems
United States of America
Email: asreekan@cisco.com
Acee Lindem
Cisco Systems
United States of America
Email: acee@cisco.com
Siva Sivabalan
Cisco Systems
United States of America
Email: msiva@cisco.com
Imtiyaz Mohammad
Arista Networks
India
Email: imtiyaz@arista.com
Gaurav Dawra
Cisco Systems
United States of America
Email: gdawra.ietf@gmail.com
Peng Shaofu
ZTE Corporation
China
Email: peng.shaofu@zte.com.cn
Steven Lin
Calix
United States of America
Email: steven.lin@calix.com
Stefano Previdi
Huawei Technologies
Italy
Email: stefano@previdi.net
Clarence Filsfils
Cisco Systems
Brussels
Belgium
Email: cfilsfil@cisco.com
Ketan Talaulikar (editor)
Cisco Systems
India
Email: ketant.ietf@gmail.com
Paul Mattes
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Email: pamattes@microsoft.com
Dhanendra Jain
Google
Email: dhanendra.ietf@gmail.com