[要約] RFC 9252 は、SRv6 を利用した BGP サービスの手順とメッセージを定義し、L3VPN、EVPN、インターネットサービスを含む。RFC 4364 と RFC 7432 に基づいています。
Internet Engineering Task Force (IETF) G. Dawra, Ed.
Request for Comments: 9252 LinkedIn
Category: Standards Track K. Talaulikar, Ed.
ISSN: 2070-1721 Cisco Systems
R. Raszuk
NTT Network Innovations
B. Decraene
Orange
S. Zhuang
Huawei Technologies
J. Rabadan
Nokia
July 2022
BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
IPv6（SRV6）を介したセグメントルーティングに基づくBGPオーバーレイサービス
Abstract
概要
This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).
このドキュメントでは、レイヤー3仮想プライベートネットワーク（L3VPN）、イーサネットVPN（EVPN）、インターネットサービスなど、SRV6ベースのBGPサービスの手順とメッセージを定義します。「BGP/MPLS IP仮想ネットワーク（VPNS）」（RFC 4364）および「BGP MPLSベースのイーサネットVPN」（RFC 7432）に基づいています。
Status of This Memo
本文書の位置付け
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/rfc9252.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9252で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. SRv6 Services TLVs
3. SRv6 Service Sub-TLVs
3.1. SRv6 SID Information Sub-TLV
3.2. SRv6 Service Data Sub-Sub-TLVs
3.2.1. SRv6 SID Structure Sub-Sub-TLV
4. Encoding SRv6 SID Information
5. BGP-Based L3 Service over SRv6
5.1. IPv4 VPN over SRv6 Core
5.2. IPv6 VPN over SRv6 Core
5.3. Global IPv4 over SRv6 Core
5.4. Global IPv6 over SRv6 Core
6. BGP-Based Ethernet VPN (EVPN) over SRv6
6.1. Ethernet Auto-Discovery Route over SRv6 Core
6.1.1. Ethernet A-D per ES Route
6.1.2. Ethernet A-D per EVI Route
6.2. MAC/IP Advertisement Route over SRv6 Core
6.2.1. MAC/IP Advertisement Route with MAC Only
6.2.2. MAC/IP Advertisement Route with MAC+IP
6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core
6.4. Ethernet Segment Route over SRv6 Core
6.5. IP Prefix Route over SRv6 Core
6.6. EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6
Core
7. Error Handling
8. IANA Considerations
8.1. BGP Prefix-SID TLV Types Registry
8.2. SRv6 Service Sub-TLV Types Registry
8.3. SRv6 Service Data Sub-Sub-TLV Types Registry
8.4. BGP SRv6 Service SID Flags Registry
8.5. SAFI Values Registry
9. Security Considerations
9.1. Considerations Related to BGP Sessions
9.2. Considerations Related to BGP Services
9.3. Considerations Related to SR over IPv6 Data Plane
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
SRv6 refers to Segment Routing instantiated on the IPv6 data plane [RFC8402].
SRV6は、IPv6データプレーン[RFC8402]にインスタンス化されたセグメントルーティングを指します。
BGP is used to advertise the reachability of prefixes of a particular service from an egress Provider Edge (PE) to ingress PE nodes.
BGPは、Egress Provider Edge（PE）からPEノードを侵入するために、特定のサービスのプレフィックスの到達可能性を宣伝するために使用されます。
SRv6-based BGP services refer to the Layer 3 (L3) and Layer 2 (L2) overlay services with BGP as the control plane and SRv6 as the data plane. This document defines procedures and messages for SRv6-based BGP services, including L3VPN, EVPN, and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" [RFC4364] and "BGP MPLS-Based Ethernet VPN" [RFC7432].
SRV6ベースのBGPサービスは、レイヤー3（L3）およびレイヤー2（L2）オーバーレイサービスをコントロールプレーンとして、SRV6をデータプレーンとして参照します。このドキュメントでは、L3VPN、EVPN、インターネットサービスを含むSRV6ベースのBGPサービスの手順とメッセージを定義しています。「BGP/MPLS IP仮想ネットワーク（VPNS）」[RFC4364]および「BGP MPLSベースのイーサネットVPN」[RFC7432]に基づいています。
SRv6 SID refers to an SRv6 Segment Identifier, as defined in [RFC8402].
SRV6 SIDは、[RFC8402]で定義されているように、SRV6セグメント識別子を指します。
SRv6 Service SID refers to an SRv6 SID associated with one of the service-specific SRv6 Endpoint Behaviors on the advertising PE router, such as (but not limited to) End.DT (look up in the Virtual Routing and Forwarding (VRF) table) or End.DX (cross-connect to a next hop) behaviors in the case of L3VPN service, as defined in [RFC8986]. This document describes how existing BGP messages between PEs may carry SRv6 Service SIDs to interconnect PEs and form VPNs.
SRV6 Service SIDは、end.dtなどの（ただしこれらに限定されない）広告PEルーターのサービス固有のSRV6エンドポイントの動作の1つに関連付けられたSRV6 SIDを指します（仮想ルーティングと転送（VRF）テーブルで検索）または[RFC8986]で定義されているように、L3VPNサービスの場合のEnd.DX（次のホップへのクロスコネクト）動作。このドキュメントでは、PE間の既存のBGPメッセージがSRV6サービスSIDSを相互接続してVPNを形成する方法について説明します。
To provide SRv6 service with best-effort connectivity, the egress PE signals an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. The underlay between the PEs only needs to support plain IPv6 forwarding [RFC8200].
SRV6サービスをベストエフォルト接続を備えたサービスを提供するために、Egress PEはBGPオーバーレイサービスルートを備えたSRV6サービスSIDを信号します。Ingress PEは、宛先アドレスがEgress PEが提供するSRV6サービスSIDである外側IPv6ヘッダーのペイロードをカプセル化します。PES間のアンダーレイは、プレーンIPv6転送[RFC8200]をサポートする必要があります。
To provide SRv6 service in conjunction with an underlay Service Level Agreement (SLA) from the ingress PE to the egress PE, the egress PE colors the overlay service route with a Color Extended Community [RFC9012] for steering flows for those routes, as specified in Section 8 of [SEGMENT-ROUTING-POLICY]. The ingress PE encapsulates the payload packet in an outer IPv6 header with the SR Policy segment list associated with the related SLA along with the SRv6 Service SID associated with the route using the Segment Routing Header (SRH) [RFC8754]. The underlay nodes whose SRv6 SIDs are part of the SRH segment list MUST support the SRv6 data plane.
SRV6サービスをイングレスPEから出口PEまでのアンダーレイサービスレベル契約（SLA）と組み合わせて提供するために、脱出するPEは、指定されたルートのステアリングフロー用の色拡張コミュニティ[RFC9012]を備えたオーバーレイサービスルートを色付けします。[セグメントルーティングポリティ]のセクション8。Ingress PEは、セグメントルーティングヘッダー（SRH）[RFC8754]を使用してルートに関連付けられたSRV6サービスSIDとともに、関連するSLAに関連付けられたSRポリシーセグメントリストを使用して、外側のIPv6ヘッダーのペイロードパケットをカプセル化します。SRV6 SIDSがSRHセグメントリストの一部であるアンダーレイノードは、SRV6データプレーンをサポートする必要があります。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document extends the use of the BGP Prefix-SID attribute [RFC8669] to carry SRv6 SIDs and their associated information with the BGP address families that are listed further in this section.
このドキュメントでは、BGPプレフィックス-SID属性[RFC8669]の使用を拡張して、SRV6 SIDSとその関連情報をこのセクションにさらにリストしているBGPアドレスファミリに拡張します。
The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-SID attribute to achieve signaling of SRv6 SIDs for L3 and L2 services.
SRV6サービスTLVは、L3およびL2サービスのSRV6 SIDSのシグナル伝達を達成するために、BGPプレフィックスSID属性の2つの新しいTLVとして定義されます。
SRv6 L3 Service TLV: This TLV encodes Service SID information for SRv6-based L3 services. It corresponds to the equivalent functionality provided by an MPLS label when received with a Layer 3 service route, as defined in [RFC4364], [RFC4659], [RFC8950], and [RFC9136]. Some SRv6 Endpoint Behaviors that may be encoded are, but not limited to, End.DX4, End.DT4, End.DX6, End.DT6, and End.DT46.
SRV6 L3サービスTLV：このTLVは、SRV6ベースのL3サービスのサービスSID情報をエンコードします。[RFC4364]、[RFC4659]、[RFC8950]、および[RFC9136]で定義されているレイヤー3サービスルートで受信した場合、MPLSラベルによって提供される同等の機能に対応します。エンコードされる可能性のあるSRV6エンドポイントの動作は、end.dx4、end.dt4、end.dx6、end.dt6、およびend.dt46に限定されませんが、これらに限定されません。
SRv6 L2 Service TLV: This TLV encodes Service SID information for SRv6-based L2 services. It corresponds to the equivalent functionality provided by an MPLS label for Ethernet VPN (EVPN) Route Types for Layer 2 services, as defined in [RFC7432]. Some SRv6 Endpoint Behaviors that may be encoded are, but not limited to, End.DX2, End.DX2V, End.DT2U, and End.DT2M.
SRV6 L2サービスTLV：このTLVは、SRV6ベースのL2サービスのサービスSID情報をエンコードします。[RFC7432]で定義されているように、レイヤー2サービスのイーサネットVPN（EVPN）ルートタイプのMPLSラベルによって提供される同等の機能に対応します。エンコードされる可能性のあるSRV6エンドポイントの動作は、end.dx2、end.dx2v、end.dt2u、およびend.dt2mに限定されませんが、これらに限定されません。
When an egress PE is enabled for BGP Services over the SRv6 data plane, it signals one or more SRv6 Service SIDs enclosed in an SRv6 Service TLV(s) within the BGP Prefix-SID attribute attached to Multiprotocol BGP (MP-BGP) Network Layer Reachability Information (NLRI) defined in [RFC4760], [RFC4659], [RFC8950], [RFC7432], [RFC4364], and [RFC9136], where applicable, as described in Sections 5 and 6.
SRV6データプレーンでBGPサービスに対して出力PEが有効になっている場合、マルチプロトコルBGP（MP-BGP）ネットワーク層に接続されたBGPプレフィックス-SID属性内のSRV6サービスTLVに囲まれた1つまたは複数のSRV6サービスSIDSを信号します[RFC4760]、[RFC4659]、[RFC8950]、[RFC7432]、[RFC4364]、[RFC4364]、および[RFC9136]で定義されている到達可能性情報（NLRI）。
The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6 is outside the scope of this document.
SRV6を使用したBGPマルチキャストVPN（MVPN）サービス[RFC6513]のサポートは、このドキュメントの範囲外です。
The following depicts the SRv6 Service TLVs encoded in the BGP Prefix-SID attribute:
以下は、BGPプレフィックス-SID属性にエンコードされたSRV6サービス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6 Service TLVs
図1：SRV6サービスTLV
TLV Type (1 octet): This field is assigned a value from IANA's "BGP Prefix-SID TLV Types" subregistry. It is set to 5 for the SRv6 L3 Service TLV. It is set to 6 for the SRv6 L2 Service TLV.
TLVタイプ（1オクテット）：このフィールドには、IANAの「BGPプレフィックス-SID TLVタイプ」サブレジストリから値が割り当てられています。SRV6 L3サービスTLVで5に設定されています。SRV6 L2サービスTLVで6に設定されています。
TLV Length (2 octets): This field specifies the total length, in octets, of the TLV Value.
TLV長（2オクテット）：このフィールドは、TLV値のオクテットの総長さを指定します。
RESERVED (1 octet): This field is reserved; it MUST be set to 0 by the sender and ignored by the receiver.
予約済み（1オクテット）：このフィールドは予約されています。送信者によって0に設定され、受信機によって無視される必要があります。
SRv6 Service Sub-TLVs (variable): This field contains SRv6 service-related information and is encoded as an unordered list of Sub-TLVs whose format is described below.
SRV6 Service Sub-TLVS（変数）：このフィールドにはSRV6サービス関連の情報が含まれており、以下で説明されているサブTLVの順序付けられていないリストとしてエンコードされています。
A BGP speaker receiving a route containing the BGP Prefix-SID attribute with one or more SRv6 Service TLVs observes the following rules when advertising the received route to other peers:
1つ以上のSRV6サービスTLVを含むBGPプレフィックス-SID属性を含むルートを受信するBGPスピーカーは、受け取ったルートを他のピアへのルートを宣伝するときに次のルールを遵守します。
* If the BGP next hop is unchanged during the advertisement, the SRv6 Service TLVs, including any unrecognized Types of Sub-TLV and Sub-Sub-TLV, SHOULD be propagated further. In addition, all Reserved fields in the TLV, Sub-TLV, or Sub-Sub-TLV MUST be propagated unchanged.
* 広告中にBGPの次のホップが変更されていない場合、認識されていないタイプのSub-TLVおよびSub-Sub-TLVを含むSRV6サービスTLVをさらに伝播する必要があります。さらに、TLV、Sub-TLV、またはSub-Sub-TLVのすべての予約済みフィールドは、変更されていないと伝播する必要があります。
* If the BGP next hop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs SHOULD be updated with the locally allocated SRv6 SID information. Any received Sub-TLVs and Sub-Sub-TLVs that are unrecognized MUST be removed.
* BGPの次のホップが変更された場合、TLV、Sub-TLV、およびSub-Sub-TLVは、ローカルに割り当てられたSRV6 SID情報を使用して更新する必要があります。認識されていない受信サブTLVおよびサブサブTLVを削除する必要があります。
The format of a single SRv6 Service Sub-TLV is depicted below:
単一のSRV6サービスサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | SRv6 Service //
| Sub-TLV | Sub-TLV | Sub-TLV //
| Type | Length | Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SRv6 Service Sub-TLVs
図2：SRV6サービスサブTLV
SRv6 Service Sub-TLV Type (1 octet): This field identifies the type of SRv6 service information. It is assigned a value from IANA's "SRv6 Service Sub-TLV Types" subregistry.
SRV6サービスサブTLVタイプ（1オクター）：このフィールドは、SRV6サービス情報のタイプを識別します。IANAの「SRV6サービスサブTLVタイプ」サブレジストリから値が割り当てられます。
SRv6 Service Sub-TLV Length (2 octets): This field specifies the total length, in octets, of the Sub-TLV Value field.
SRV6サービスサブTLV長さ（2オクテット）：このフィールドは、サブTLV値フィールドのオクテットの総長さを指定します。
SRv6 Service Sub-TLV Value (variable): This field contains data specific to the Sub-TLV Type. In addition to fixed-length data, it contains other properties of the SRv6 service encoded as a set of SRv6 Service Data Sub-Sub-TLVs whose format is described in Section 3.2 below.
SRV6 Service Sub-TLV値（変数）：このフィールドには、Sub-TLVタイプに固有のデータが含まれています。固定長データに加えて、以下のセクション3.2で説明されているSRV6サービスデータサブサブTLVのセットとしてエンコードされたSRV6サービスの他のプロパティが含まれています。
SRv6 Service Sub-TLV Type 1 is assigned for the SRv6 SID Information Sub-TLV. This Sub-TLV contains a single SRv6 SID along with its properties. Its encoding is depicted below:
SRV6サービスSUB-TLVタイプ1は、SRV6 SID Information Sub-TLVに割り当てられています。このサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | |
| Sub-TLV | Sub-TLV | |
| Type=1 | Length | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID Value (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Data Sub-Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRv6 SID Information Sub-TLV
図3：SRV6 SID Information Sub-TLV
SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to represent the SRv6 SID Information Sub-TLV.
SRV6 Service Sub-TLV Type（1 Octet）：このフィールドは、SRV6 SID情報Sub-TLVを表すために1に設定されています。
SRv6 Service Sub-TLV Length (2 octets): This field contains the total length, in octets, of the Value field of the Sub-TLV.
SRV6サービスサブTLV長さ（2オクテット）：このフィールドには、サブTLVの値フィールドのオクテットの全長が含まれています。
RESERVED1 (1 octet): This field MUST be set to 0 by the sender and ignored by the receiver.
Reserved1（1 Octet）：このフィールドは、送信者によって0に設定され、受信機によって無視される必要があります。
SRv6 SID Value (16 octets): This field encodes an SRv6 SID, as defined in [RFC8986].
SRV6 SID値（16オクテット）：このフィールドは、[RFC8986]で定義されているように、SRV6 SIDをエンコードします。
SRv6 Service SID Flags (1 octet): This field encodes SRv6 Service SID Flags -- none are currently defined. It MUST be set to 0 by the sender and any unknown flags MUST be ignored by the receiver.
SRV6 Service SID Flags（1 Octet）：このフィールドはSRV6サービスSIDフラグをエンコードします - 現在定義されていません。送信者によって0に設定する必要があり、未知のフラグは受信機によって無視される必要があります。
SRv6 Endpoint Behavior (2 octets): This field encodes the SRv6 Endpoint Behavior codepoint value that is associated with the SRv6 SID. The codepoints used are from IANA's "SRv6 Endpoint Behaviors" subregistry under the "Segment Routing" registry that was introduced by [RFC8986]. The opaque SRv6 Endpoint Behavior (i.e., value 0xFFFF) MAY be used when the advertising router wishes to abstract the actual behavior of its locally instantiated SRv6 SID.
SRV6エンドポイントの動作（2オクテット）：このフィールドは、SRV6 SIDに関連付けられているSRV6エンドポイント動作コードポイント値をエンコードします。使用されるコードポイントは、[RFC8986]によって導入された「セグメントルーティング」レジストリの下にあるIANAの「SRV6エンドポイント動作」サブレジストリからのものです。広告ルーターがローカルにインスタンス化されたSRV6 SIDの実際の動作を抽象化したい場合、不透明なSRV6エンドポイントの動作（つまり、値0xFFFF）を使用できます。
RESERVED2 (1 octet): This field MUST be set to 0 by the sender and ignored by the receiver.
RESERVERT2（1 OCTET）：このフィールドは、送信者によって0に設定され、受信機によって無視される必要があります。
SRv6 Service Data Sub-Sub-TLV Value (variable): This field is used to advertise properties of the SRv6 SID. It is encoded as a set of SRv6 Service Data Sub-Sub-TLVs.
SRV6サービスデータサブサブ-TLV値（変数）：このフィールドは、SRV6 SIDのプロパティを宣伝するために使用されます。SRV6サービスデータサブサブ-TLVのセットとしてエンコードされています。
The choice of SRv6 Endpoint Behavior of the SRv6 SID is entirely up to the originator of the advertisement. While Sections 5 and 6 list the SRv6 Endpoint Behaviors that are normally expected to be used by the specific route advertisements, the reception of other SRv6 Endpoint Behaviors (e.g., new behaviors that may be introduced in the future) is not considered an error. An unrecognized SRv6 Endpoint Behavior MUST NOT be considered invalid by the receiver, except for behaviors that involve the use of arguments (refer to Section 3.2.1 for details on argument validation). An implementation MAY log a rate-limited warning when it receives an unexpected behavior.
SRV6 SIDのSRV6エンドポイントの動作の選択は、完全に広告の創始者次第です。セクション5と6は、特定のルート広告で通常使用されると予想されるSRV6エンドポイントの動作をリストしますが、他のSRV6エンドポイントの動作（将来導入される可能性のある新しい動作など）の受信はエラーとは見なされません。認識されていないSRV6エンドポイントの動作は、引数の使用を伴う動作を除き、受信機によって無効と見なされるべきではありません（引数検証の詳細については、セクション3.2.1を参照）。実装は、予期しない動作を受信したときにレート制限された警告を記録する場合があります。
When multiple SRv6 SID Information Sub-TLVs are present, the ingress PE SHOULD use the SRv6 SID from the first instance of the Sub-TLV. An implementation MAY provide a local policy to override this selection.
複数のSRV6 SID情報Sub-TLVが存在する場合、Ingress PEはSub-TLVの最初のインスタンスからSRV6 SIDを使用する必要があります。実装は、この選択をオーバーライドするためのローカルポリシーを提供する場合があります。
The format of the SRv6 Service Data Sub-Sub-TLV is depicted below:
SRV6サービスデータサブサブ-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Data | Sub-Sub-TLV Length |Sub-Sub TLV //
| Sub-Sub-TLV | | Value //
| Type | | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6 Service Data Sub-Sub-TLVs
図4：SRV6サービスデータサブサブ-TLV
SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field identifies the type of Sub-Sub-TLV. It is assigned a value from IANA's "SRv6 Service Data Sub-Sub-TLV Types" subregistry.
SRV6サービスデータサブサブ-TLVタイプ（1 OCTET）：このフィールドは、サブサブTLVのタイプを識別します。IANAの「SRV6サービスデータサブサブTLVタイプ」サブレジストリから値が割り当てられます。
SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field specifies the total length, in octets, of the Sub-Sub-TLV Value field.
SRV6サービスデータサブサブ-TLV長さ（2オクテット）：このフィールドは、サブサブTLV値フィールドのオクテットの合計長さを指定します。
SRv6 Service Data Sub-Sub-TLV Value (variable): This field contains data specific to the Sub-Sub-TLV Type.
SRV6サービスデータサブサブ-TLV値（変数）：このフィールドには、サブサブTLVタイプに固有のデータが含まれています。
SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV is used to advertise the lengths of the individual parts of the SRv6 SID, as defined in [RFC8986]. The terms Locator Block and Locator Node correspond to the B and N parts, respectively, of the SRv6 Locator that is defined in Section 3.1 of [RFC8986]. It is carried as Sub-Sub-TLV in the SRv6 SID Information Sub-TLV.
SRV6サービスデータサブサブ-TLVタイプ1は、SRV6 SID Structure Sub-Sub-TLVに割り当てられています。[RFC8986]で定義されているように、SRV6 SID構造のサブサブTLVは、SRV6 SIDの個々の部分の長さを宣伝するために使用されます。[RFC8986]のセクション3.1で定義されているSRV6ロケーターのロケーターブロックとロケーターノードという用語は、それぞれBとN部品に対応しています。SRV6 SID Information Sub-TLVでサブサブ-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | Locator Block |
| Data Sub-Sub | Data Sub-Sub-TLV | Length |
| -TLV Type=1 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Node | Function | Argument | Transposition |
| Length | Length | Length | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transposition |
| Offset |
+-+-+-+-+-+-+-+-+
Figure 5: SRv6 SID Structure Sub-Sub-TLV
図5：SRV6 SID Structure sub-sub-tlv
SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is set to 1 to represent the SRv6 SID Structure Sub-Sub-TLV.
SRV6サービスデータサブサブ-TLVタイプ（1 OCTET）：このフィールドは、SRV6 SID構造サブサブTLVを表すために1に設定されています。
SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field contains a total length of 6 octets.
SRV6サービスデータサブサブ-TLV長さ（2オクテット）：このフィールドには、合計6オクテットの長さが含まれています。
Locator Block Length (1 octet): This field contains the length of the SRv6 SID Locator Block in bits.
ロケーターブロック長（1オクテット）：このフィールドには、ビットのSRV6 SIDロケーターブロックの長さが含まれています。
Locator Node Length (1 octet): This field contains the length of the SRv6 SID Locator Node in bits.
ロケーターノード長（1オクテット）：このフィールドには、ビットのSRV6 SIDロケーターノードの長さが含まれています。
Function Length (1 octet): This field contains the length of the SRv6 SID Function in bits.
関数長（1オクテット）：このフィールドには、ビットのSRV6 SID関数の長さが含まれています。
Argument Length (1 octet): This field contains the length of the SRv6 SID Argument in bits.
引数の長さ（1オクテット）：このフィールドには、ビットのSRV6 SID引数の長さが含まれています。
Transposition Length (1 octet): This field is the size in bits for the part of the SID that has been transposed (or shifted) into an MPLS Label field.
転置長（1オクテット）：このフィールドは、MPLSラベルフィールドに転置（またはシフト）されたSIDの部分のビットのサイズです。
Transposition Offset (1 octet): This field is the offset position in bits for the part of the SID that has been transposed (or shifted) into an MPLS Label field.
転置オフセット（1オクテット）：このフィールドは、MPLSラベルフィールドに転置（またはシフト）されたSIDの部分のビットのオフセット位置です。
Section 4 describes mechanisms for the signaling of the SRv6 Service SID by transposing a variable part of the SRv6 SID value and carrying this variable part in existing MPLS Label fields to achieve more efficient packing of those service prefix NLRIs in BGP update messages. The SRv6 SID Structure Sub-Sub-TLV contains appropriate length fields when the SRv6 Service SID is signaled in split parts to enable the receiver to put together the SID accurately.
セクション4では、SRV6 SID値の変数部分を転置し、既存のMPLSラベルフィールドにこの変数部分を運ぶことにより、SRV6サービスSIDのシグナル伝達のメカニズムについて説明し、BGP更新メッセージでそれらのサービスプレフィックスNLRIのより効率的な梱包を実現します。SRV6 SID構造のサブサブTLVには、SRV6サービスSIDがスプリットパーツで信号を送信して、受信機がSIDを正確にまとめることができる場合に適切な長さフィールドが含まれています。
Transposition Offset indicates the bit position, and Transposition Length indicates the number of bits that are being taken out of the SRv6 SID value and encoded in the MPLS Label field. The bits that have been shifted out MUST be set to 0 in the SID value.
転置オフセットはビット位置を示し、転置長はSRV6 SID値から取り出され、MPLSラベルフィールドでエンコードされているビットの数を示します。シフトアウトされたビットは、SID値で0に設定する必要があります。
A Transposition Length of 0 indicates nothing is transposed and that the entire SRv6 SID value is encoded in the SID Information Sub-TLV. In this case, the Transposition Offset MUST be set to 0.
0の転置長は、何も転置されておらず、SRV6 SID値全体がSID情報Sub-TLVでエンコードされていることを示します。この場合、転置オフセットは0に設定する必要があります。
The size of the MPLS Label field limits the bits transposed from the SRv6 SID value into it. For example, the size of the MPLS Label field is 20 bits in [RFC4364] and [RFC8277], and the size is 24 bits in [RFC7432].
MPLSラベルフィールドのサイズは、SRV6 SID値から移行されたビットをITに制限します。たとえば、MPLSラベルフィールドのサイズは[RFC4364]および[RFC8277]で20ビットで、[RFC7432]でサイズは24ビットです。
As defined in [RFC8986], the sum of the Locator Block Length (LBL), Locator Node Length (LNL), Function Length (FL), and Argument Length (AL) fields MUST be less than or equal to 128 and greater than the sum of Transposition Offset and Transposition Length.
[RFC8986]で定義されているように、ロケーターブロック長（LBL）、ロケーターノード長（LNL）、関数長（FL）、および引数長（AL）フィールドの合計は、128以下で、転置オフセットと転置長の合計。
As an example, consider that the sum of the Locator Block and the Locator Node parts is 64. For an SRv6 SID where the entire Function part of size 16 bits is transposed, the transposition offset is set to 64 and the transposition length is set to 16. While for an SRv6 SID for which the FL is 24 bits and only the lower order 20 bits are transposed (e.g., due to the limit of the MPLS Label field size), the transposition offset is set to 68 and the transposition length is set to 20.
例として、ロケーターブロックとロケーターノードパーツの合計は64であることを考慮してください。サイズ16ビットの関数部分全体が転置されるSRV6 SIDの場合、転置オフセットは64に設定され、転置長はに設定されます。16. FLが24ビットで、下位20ビットのみが転置されるSRV6 SIDの場合（例：MPLSラベルフィールドサイズの限界）、転置オフセットは68に設定され、転置長は20に設定します。
BGP speakers that do not support this specification may misinterpret, on the reception of an SRv6-based BGP service route update, the part of the SRv6 SID encoded in an MPLS Label field(s) as MPLS label values for MPLS-based services. Implementations supporting this specification MUST provide a mechanism to control the advertisement of SRv6-based BGP service routes on a per-neighbor and per-service basis. The details of deployment designs and implementation options are outside the scope of this document.
この仕様をサポートしていないBGPスピーカーは、MPLSベースのサービスのMPLSラベル値としてMPLSラベルフィールドにエンコードされたSRV6 SIDの一部であるSRV6ベースのBGPサービスルートアップデートの受信について、誤解する可能性があります。この仕様をサポートする実装では、SRV6ベースのBGPサービスルートの広告をneighborごとおよびサービスごとに制御するメカニズムを提供する必要があります。展開設計と実装オプションの詳細は、このドキュメントの範囲外です。
Arguments may be generally applicable for SIDs of only specific SRv6 Endpoint Behaviors (e.g., End.DT2M); therefore, the AL MUST be set to 0 for SIDs where the Argument is not applicable. A receiver is unable to validate the applicability of arguments for SRv6 Endpoint Behaviors that are unknown to it and hence MUST ignore SRv6 SIDs with arguments (indicated by a non-zero AL) with unknown SRv6 Endpoint Behaviors. For SIDs corresponding to an SRv6 Endpoint Behavior that is known, a receiver MUST validate that the consistency of the AL with the specific SRv6 Endpoint Behavior definition.
引数は、一般に、特定のSRV6エンドポイントの動作のみのSIDに適用される場合があります（例：End.DT2M）。したがって、ALは、引数が適用されないSIDSの場合は0に設定する必要があります。受信者は、srv6エンドポイント動作に対する引数の適用性を検証できないため、未知のSRV6エンドポイントの動作を持つ引数（非ゼロALで示される）でSRV6 SIDを無視する必要があります。既知のSRV6エンドポイントの動作に対応するSIDSの場合、受信者は、特定のSRV6エンドポイントの動作定義とALの一貫性を検証する必要があります。
The SRv6 Service SID(s) for a BGP service prefix is carried in the SRv6 Services TLVs of the BGP Prefix-SID attribute.
BGPサービスプレフィックスのSRV6サービスSID（S）は、BGPプレフィックス-SID属性のSRV6サービスTLVで運ばれます。
For certain types of BGP Services, like L3VPN where a per-VRF SID allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID is shared across multiple NLRIs, thus providing efficient packing. However, for certain other types of BGP Services, like EVPN Virtual Private Wire Service (VPWS) where a per-PW SID allocation is required (i.e., End.DX2 behavior), each NLRI would have its own unique SID, thereby resulting in inefficient packing.
VRFごとのSID割り当てが使用されるL3VPN（つまり、End.DT4またはEnd.DT6動作）などの特定のタイプのBGPサービスの場合、同じSIDが複数のNLRIで共有されるため、効率的な梱包を提供します。ただし、PWごとのSID割り当てが必要なEVPN仮想プライベートワイヤサービス（VPWS）などの特定の他のタイプのBGPサービスの場合（つまり、End.DX2の動作）、各NLRIには独自のSIDがあり、それにより非効率的になります。梱包。
To achieve efficient packing, this document allows either 1) the encoding of the SRv6 Service SID as a whole in the SRv6 Services TLVs or 2) the encoding of only the common part of the SRv6 SID (e.g., Locator) in the SRv6 Services TLVs and the encoding of the variable (e.g., Function or Argument parts) in the existing label fields specific to that service encoding. This later form of encoding is referred to as the Transposition Scheme, where the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and also indicates the offset of the variable part along with its length in the SRv6 SID value. The use of the Transposition Scheme is RECOMMENDED for the specific service encodings that allow it, as described further in Sections 5 and 6.
効率的なパッキングを実現するために、このドキュメントでは、1）SRV6サービスTLVSでのSRV6サービスSID全体のエンコード、またはSRV6サービスTLVSのSRV6 SID（例えば、ロケーター）の共通部分のみのエンコードを許可します。およびそのサービスエンコードに固有の既存のラベルフィールドにおける変数（機能または引数部分など）のエンコード。この後のエンコーディング形式は転置スキームと呼ばれ、SRV6 SID構造サブサブ-TLVはSRV6 SIDの部分のサイズを記述し、SRV6 SIDの長さとともに変数部のオフセットを示します。価値。セクション5および6でさらに説明したように、それを許可する特定のサービスエンコーディングには、転置スキームの使用が推奨されます。
As an example, for the EVPN VPWS service prefix described further in Section 6.1.2, the Function part of the SRv6 SID is encoded in the MPLS Label field of the NLRI, and the SID value in the SRv6 Services TLV carries only the Locator part with the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of Locator Block, Locator Node, and Function parts (Arguments are not applicable for the End.DX2 behavior). Transposition Offset indicates the bit position, and Transposition Length indicates the number of bits that are being taken out of the SID and put into the label field.
例として、セクション6.1.2でさらに説明したEVPN VPWSサービスプレフィックスの場合、SRV6 SIDの関数部分はNLRIのMPLSラベルフィールドにエンコードされ、SRV6サービスTLVのSID値はロケーターパーツのみを運びます。SRV6 SID Structure Sub-Sub-TLVを使用。SRV6 SID構造のサブサブTLVは、ロケーターブロック、ロケーターノード、および関数パーツの長さを定義します（引数はEND.DX2の動作には適用されません）。転置オフセットはビットの位置を示し、転置長はSIDから取り出されてラベルフィールドに配置されているビットの数を示します。
In yet another example, for the EVPN Ethernet Auto-Discovery (A-D) per Ethernet Segment (ES) route described further in Section 6.1.1, only the Argument of the SID needs to be signaled. This Argument part of the SRv6 SID MAY be transposed in the Ethernet Segment Identifier (ESI) Label field of the ESI Label extended community, and the SID value in the SRv6 Services TLV is set to 0 along with the inclusion of the SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of Locator Block, Locator Node, Function, and Argument parts. The offset and length of the Argument part SID value moved to the label field is set in transposition offset and length of the SID Structure TLV. The receiving router is then able to put together the entire SRv6 Service SID (e.g., for the End.DT2M behavior), placing the label value received in the ESI Label field of the Ethernet A-D per ES route into the correct transposition offset and length in the SRv6 SID with the End.DT2M behavior received for an EVPN Route Type 3 value.
さらに別の例では、セクション6.1.1でさらに説明するイーサネットセグメント（ES）あたりのEVPNイーサネット自動ディスコービリ（A-D）の場合、SIDの引数のみを信号する必要があります。 SRV6 SIDのこの引数部分は、ESIラベル拡張コミュニティのイーサネットセグメント識別子識別子（ESI）ラベルフィールドに転置される可能性があり、SRV6サービスTLVのSID値はSRV6 SID構造サブサブを含めるとともに0に設定されます。 -SUB-TLV。 SRV6 SID構造のサブサブTLVは、ロケーターブロック、ロケーターノード、機能、および引数パーツの長さを定義します。引数パーツSID値のオフセットと長さは、ラベルフィールドに移動されます。転置オフセットとSID構造TLVの長さに設定されています。受信ルーターは、SRV6サービスSID全体（END.DT2Mの動作など）全体をまとめて、ESIルートのESIラベルフィールドに受信したラベル値を正しい転位オフセットと長さに配置することができます。 end.dt2mの動作を備えたSRV6 SIDは、EVPNルートタイプ3値に対して受信されました。
BGP egress nodes (egress PEs) advertise a set of reachable prefixes. Standard BGP update propagation schemes [RFC4271], which may make use of route reflectors [RFC4456], are used to propagate these prefixes. BGP ingress nodes (ingress PEs) receive these advertisements and may add the prefix to the RIB in an appropriate VRF.
BGP出力ノード（Egress PES）は、到達可能なプレフィックスのセットを宣伝します。標準のBGP更新伝播スキーム[RFC4271]は、ルートリフレクター[RFC4456]を使用する可能性があり、これらの接頭辞を伝播するために使用されます。BGP Ingressノード（Ingress PES）はこれらの広告を受け取り、適切なVRFでリブにプレフィックスを追加する場合があります。
Egress PEs that support SRv6-based L3 services advertise overlay service prefixes along with a Service SID enclosed in an SRv6 L3 Service TLV within the BGP Prefix-SID attribute. This TLV serves two purposes -- first, it indicates that the egress PE supports SRv6 overlay, and the BGP ingress PE receiving this route MUST perform IPv6 encapsulation and insert an SRH [RFC8754] when required; second, it indicates the value of the Service SID to be used in the encapsulation.
SRV6ベースのL3サービスをサポートする出力PESは、BGPプレフィックスSID属性内のSRV6 L3サービスTLVに囲まれたサービスSIDとともにオーバーレイサービスプレフィックスを宣伝しています。このTLVは2つの目的を果たします。まず、出力PEがSRV6オーバーレイをサポートし、このルートを受け取るBGPイングレスPEがIPv6カプセル化を実行し、必要に応じてSRH [RFC8754]を挿入する必要があることを示します。第二に、カプセル化で使用されるサービスSIDの価値を示します。
Thus, the Service SID signaled only has local significance at the egress PE, where it may be allocated or configured on a per-Customer-Edge (CE) or per-VRF basis. In practice, the SID may encode a cross-connect to a specific address family table (End.DT) or next hop / interface (End.DX), as defined in [RFC8986].
したがって、SIDのSIDは、出力PEでのみ局所的な重要性を持っていることを示しています。ここでは、顧客1人あたり（CE）またはVRFごとに割り当てられたり構成されたりする可能性があります。実際には、SIDは、[RFC8986]で定義されているように、特定のアドレスファミリテーブル（End.DT）または次のホップ /インターフェイス（End.DX）にクロスコネクトをエンコードする場合があります。
The SRv6 Service SID SHOULD be routable (refer to Section 3.3 of [RFC8986]) within the Autonomous System (AS) of the egress PE and serves the dual purpose of providing reachability between ingress PE and egress PE while also encoding the SRv6 Endpoint Behavior.
SRV6サービスSIDは、出口PEの自律システム（AS）内でルーティング可能である必要があり、SRV6エンドポイントの動作をエンコードしながら、侵入PEと出口PEの間の到達可能性を提供する二重の目的を果たします。
When steering for SRv6 services is based on shortest path forwarding (e.g., best effort or IGP Flexible Algorithm [IGP-FLEX-ALGO]) to the egress PE, the ingress PE encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header (using H.Encaps or H.Encaps.Red flavors specified in [RFC8986]), where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE MUST perform a resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. The resolvability is evaluated as per [RFC4271]. If the SRv6 SID is reachable via more than one forwarding table, local policy is used to determine which table to use. The result of an SRv6 Service SID resolvability (e.g., when provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE. The details of such steering mechanisms are outside the scope of this document.
SRV6サービスのステアリングが最短のパス転送（例：ベストエフェクトまたはIGPフレキシブルアルゴリズム[IGP-FLEX-ALGO]）に基づいている場合、侵入PEは外部IPv6ヘッダーのIPv4またはIPv6カスタマーパケットをカプセル化します（ H.ENCAPSまたはH.ENCAPS.REDフレーバー[RFC8986]で指定されたレッドフレーバー。宛先アドレスは、関連するBGPルートの更新に関連付けられたSRV6サービスSIDです。したがって、Ingress PEは、BGPベストパス計算の受信プレフィックスを検討する前に、SRV6サービスSIDの解決可能性チェックを実行する必要があります。解決可能性は[RFC4271]に従って評価されます。 SRV6 SIDが複数の転送テーブルを介して到達できる場合、ローカルポリシーを使用して使用するテーブルを決定します。 SRV6サービスSIDの解決可能性の結果（たとえば、IGPフレキシブルアルゴリズムを介して提供される場合）は、Ingress PEに代替ステアリングメカニズムが出口PEに到達できるようにするローカルポリシーを持っている場合、無視できます。このようなステアリングメカニズムの詳細は、このドキュメントの範囲外です。
For service over SRv6 core, the egress PE sets the BGP next hop to one of its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator from which the SRv6 Service SID is allocated. The BGP next hop is used for tracking the reachability of the egress PE based on existing BGP procedures.
SRV6 Coreを介したサービスのために、Egress PEはBGPを次のHopをIPv6アドレスの1つに設定します。このようなアドレスは、SRV6サービスSIDが割り当てられるSRV6ロケーターによってカバーされる場合があります。BGP Next Hopは、既存のBGP手順に基づいて出口PEの到達可能性を追跡するために使用されます。
When the BGP route received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, the steering for service flows is performed as described in Section 8 of [SEGMENT-ROUTING-POLICY]. When the ingress PE determines (with the help of the SRv6 SID Structure) that the Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID when steering the service flow. For example, the effective segment list of the SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID>.
イングレスPEで受信したBGPルートが色の拡張コミュニティで色付けされ、有効なSRV6ポリシーが利用可能になると、[セグメントルーティングポリティ]のセクション8で説明されているように、サービスフローのステアリングが実行されます。イングレスPEが（SRV6 SID構造の助けを借りて）サービスSIDがSRポリシーセグメントリストの最後のSRV6 SID（出口PEの）と同じSRV6 SIDに属していると判断した場合、最後のSRV6 SIDは除外される可能性があります。サービスフローを操縦するとき。たとえば、SIDリスト<S1、S2、S3>に関連付けられたSRV6ポリシーの有効セグメントリストは、<S1、S2、S3-Service-SID>になります。
The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN unicast over IPv6 core defined in [RFC8950].
SRV6コアのMP_REACH_NLRIは、[RFC8950]で定義されたIPv6コア上のIPv4 VPNユニキャストに従ってエンコードされます。
The label field of IPv4-VPN NLRI is encoded as specified in [RFC8277] with the 20-bit Label Value set to the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 20 and less than or equal to the FL.
IPv4-VPN NLRIのラベルフィールドは、[RFC8277]で指定されているようにエンコードされ、20ビットラベル値は、エンコードの転置スキーム（セクション4）が使用されるときにSRV6 SIDの関数部分の全体または一部に設定されています。;それ以外の場合は、暗黙のnullに設定されています。転置スキームを使用する場合、転置長は20以下であり、FLよりも等しくなければなりません。
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4, or End.DT46.
SRV6サービスSIDは、SRV6 L3サービスTLVの一部としてエンコードされています。SRV6エンドポイントの動作は、これらのいずれかでなければなりません：end.dx4、end.dt4、またはend.dt46。
The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN over IPv6 core, as defined in [RFC4659].
[RFC4659]で定義されているように、SRV6コアを介したMP_REACH_NLRIは、IPv6コアを介してIPv6 VPNに従ってエンコードされます。
The label field of the IPv6-VPN NLRI is encoded as specified in [RFC8277] with the 20-bit Label Value set to the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 20 and less than or equal to the FL.
IPv6-VPN NLRIのラベルフィールドは、[RFC8277]で指定されているようにエンコードされ、エンコードの転置スキーム（セクション4）がSRV6 SIDの関数部分または関数部分の一部または一部に設定されています。使用済み;それ以外の場合は、暗黙のnullに設定されています。転置スキームを使用する場合、転置長は20以下であり、FLよりも等しくなければなりません。
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6, or End.DT46.
SRV6サービスSIDは、SRV6 L3サービスTLVの一部としてエンコードされています。SRV6エンドポイントの動作は、これらのいずれかでなければなりません：end.dx6、end.dt6、またはend.dt46。
The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over IPv6 core, as defined in [RFC8950].
[RFC8950]で定義されているように、SRV6コアを介したMP_REACH_NLRIは、IPv6コアのIPv4に従ってエンコードされます。
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4, or End.DT46.
SRV6サービスSIDは、SRV6 L3サービスTLVの一部としてエンコードされています。SRV6エンドポイントの動作は、これらのいずれかでなければなりません：end.dx4、end.dt4、またはend.dt46。
The MP_REACH_NLRI over SRv6 core is encoded according to [RFC2545].
SRV6コア上のMP_REACH_NLRIは[RFC2545]に従ってエンコードされています。
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6, or End.DT46.
SRV6サービスSIDは、SRV6 L3サービスTLVの一部としてエンコードされています。SRV6エンドポイントの動作は、これらのいずれかでなければなりません：end.dx6、end.dt6、またはend.dt46。
[RFC7432] provides an extendable method of building an EVPN overlay. It primarily focuses on MPLS-based EVPNs, and [RFC8365] extends to IP-based EVPN overlays. [RFC7432] defines Route Types 1, 2, and 3, which carry prefixes and MPLS Label fields; the Label fields have a specific use for MPLS encapsulation of EVPN traffic. Route Type 5 carrying MPLS label information (and thus encapsulation information) for an EVPN is defined in [RFC9136]. Route Types 6, 7, and 8 are defined in [RFC9251].
[RFC7432]は、EVPNオーバーレイを構築する拡張可能な方法を提供します。主にMPLSベースのEVPNSに焦点を当てており、[RFC8365]はIPベースのEVPNオーバーレイに拡張されます。[RFC7432]は、プレフィックスとMPLSラベルフィールドを運ぶルートタイプ1、2、および3を定義します。ラベルフィールドは、EVPNトラフィックのMPLSカプセル化に特別な用途があります。EVPNのMPLSラベル情報（したがってカプセル化情報）を運ぶルートタイプ5は、[RFC9136]で定義されています。ルートタイプ6、7、および8は[RFC9251]で定義されています。
* Ethernet Auto-Discovery (A-D) route (Route Type 1)
* イーサネットオートディスコーブリ（A-D）ルート（ルートタイプ1）
* MAC/IP Advertisement route (Route Type 2)
* Mac/IP広告ルート（ルートタイプ2）
* Inclusive Multicast Ethernet Tag route (Route Type 3)
* 包括的マルチキャストイーサネットタグルート（ルートタイプ3）
* Ethernet Segment route (Route Type 4)
* イーサネットセグメントルート（ルートタイプ4）
* IP Prefix route (Route Type 5)
* IPプレフィックスルート（ルートタイプ5）
* Selective Multicast Ethernet Tag route (Route Type 6)
* 選択的マルチキャストイーサネットタグルート（ルートタイプ6）
* Multicast Membership Report Synch route (Route Type 7)
* マルチキャストメンバーシップレポート同期ルート（ルートタイプ7）
* Multicast Leave Synch route (Route Type 8)
* マルチキャスト休暇同期ルート（ルートタイプ8）
The specifications for other EVPN Route Types are outside the scope of this document.
他のEVPNルートタイプの仕様は、このドキュメントの範囲外です。
To support SRv6-based EVPN overlays, one or more SRv6 Service SIDs are advertised with Route Types 1, 2, 3, and 5. The SRv6 Service SID(s) per Route Type is advertised in SRv6 L3/L2 Service TLVs within the BGP Prefix-SID attribute. Signaling of the SRv6 Service SID(s) serves two purposes -- first, it indicates that the BGP egress device supports SRv6 overlay, and the BGP ingress device receiving this route MUST perform IPv6 encapsulation and insert an SRH [RFC8754] when required; second, it indicates the value of the Service SID(s) to be used in the encapsulation.
SRV6ベースのEVPNオーバーレイをサポートするために、1つ以上のSRV6サービスSIDがルートタイプ1、2、3、および5で宣伝されています。ルートタイプごとのSRV6サービスSIDは、BGP内のSRV6 L3/L2サービスTLVで宣伝されています。プレフィックスシド属性。SRV6サービスSIDのシグナル伝達は2つの目的に役立ちます。まず、BGP EgressデバイスがSRV6オーバーレイをサポートし、このルートを受け取るBGPイングレスデバイスがIPv6カプセル化を実行し、必要に応じてSRH [RFC8754]を挿入する必要があることを示します。第二に、カプセル化で使用されるサービスSIDの価値を示します。
The SRv6 Service SID SHOULD be routable (refer to Section 3.3 of [RFC8986]) within the AS of the egress PE and serves the dual purpose of providing reachability between the ingress PE and egress PE while also encoding the SRv6 Endpoint Behavior.
SRV6サービスSIDは、出口PE内のAS内でルーティング可能（[RFC8986]のセクション3.3を参照）であり、SRV6エンドポイントの動作をエンコードしながら、イングレスPEと出口PE間の到達可能性を提供する二重の目的を果たします。
When steering for SRv6 services is based on shortest path forwarding (e.g., best effort or IGP Flexible Algorithm [IGP-FLEX-ALGO]) to the egress PE, the ingress PE encapsulates the customer Layer 2 Ethernet packet in an outer IPv6 header (using H.Encaps.L2 or H.Encaps.L2.Red flavors specified in [RFC8986]) where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE MUST perform a resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. The resolvability is evaluated as per [RFC4271]. If the SRv6 SID is reachable via more than one forwarding table, local policy is used to determine which table to use. The result of an SRv6 Service SID resolvability (e.g., when provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE. The details of such steering mechanisms are outside the scope of this document.
SRV6サービスのステアリングが最短のパス転送（例：ベストエフェクトまたはIGPフレキシブルアルゴリズム[IGP-FLEX-ALGO]）に基づいている場合、イングレスPEは、外部IPv6ヘッダーのカスタマーレイヤー2イーサネットパケットをカプセル化します（ H.ENCAPS.L2またはH.ENCAPS.L2.REDフレーバー[RFC8986]で指定されたレッドフレーバー）ここで、宛先アドレスは関連するBGPルートの更新に関連付けられたSRV6サービスSIDです。したがって、Ingress PEは、BGPベストパス計算の受信プレフィックスを検討する前に、SRV6サービスSIDの解決可能性チェックを実行する必要があります。解決可能性は[RFC4271]に従って評価されます。 SRV6 SIDが複数の転送テーブルを介して到達できる場合、ローカルポリシーを使用して使用するテーブルを決定します。 SRV6サービスSIDの解決可能性の結果（たとえば、IGPフレキシブルアルゴリズムを介して提供される場合）は、Ingress PEに代替ステアリングメカニズムが出口PEに到達できるようにするローカルポリシーを持っている場合、無視できます。このようなステアリングメカニズムの詳細は、このドキュメントの範囲外です。
For service over SRv6 core, the egress PE sets the BGP next hop to one of its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator from which the SRv6 Service SID is allocated. The BGP next hop is used for tracking the reachability of the egress PE based on existing BGP procedures.
SRV6 Coreを介したサービスのために、Egress PEはBGPを次のHopをIPv6アドレスの1つに設定します。このようなアドレスは、SRV6サービスSIDが割り当てられるSRV6ロケーターによってカバーされる場合があります。BGP Next Hopは、既存のBGP手順に基づいて出口PEの到達可能性を追跡するために使用されます。
When the BGP route received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, the steering for service flows is performed as described in Section 8 of [SEGMENT-ROUTING-POLICY]. When the ingress PE determines (with the help of the SRv6 SID Structure) that the Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR Policy segment list, it MAY exclude that last SRv6 SID when steering the service flow. For example, the effective segment list of the SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID>.
イングレスPEで受信したBGPルートが色の拡張コミュニティで色付けされ、有効なSRV6ポリシーが利用可能になると、[セグメントルーティングポリティ]のセクション8で説明されているように、サービスフローのステアリングが実行されます。イングレスPEが（SRV6 SID構造の助けを借りて）サービスSIDがSRポリシーセグメントリストの最後のSRV6 SID（出口PEの）と同じSRV6 SIDに属していると判断した場合、最後のSRV6 SIDは除外される可能性があります。サービスフローを操縦するとき。たとえば、SIDリスト<S1、S2、S3>に関連付けられたSRV6ポリシーの有効セグメントリストは、<S1、S2、S3-Service-SID>になります。
Ethernet A-D routes are Route Type 1, as defined in [RFC7432], and may be used to achieve split-horizon filtering, fast convergence, and aliasing. EVPN Route Type 1 is also used in EVPN-VPWS as well as in EVPN-flexible cross-connect, mainly to advertise point-to-point service IDs.
イーサネットA-Dルートは、[RFC7432]で定義されているルートタイプ1であり、スプリットホリゾンフィルタリング、高速収束、エイリアシングを実現するために使用できます。EVPNルートタイプ1は、主にポイントツーポイントサービスIDを宣伝するために、EVPN-VPWSおよびEVPNの柔軟性のないクロスコネクトでも使用されます。
As a reminder, EVPN Route Type 1 is encoded as follows:
リマインダーとして、EVPNルートタイプ1は次のようにエンコードされます。
+-----------------------------------------+
| RD (8 octets) |
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------------+
| MPLS label (3 octets) |
+-----------------------------------------+
Figure 6: EVPN Route Type 1
図6：EVPNルートタイプ1
Ethernet A-D per ES route NLRI encoding over SRv6 core is as per [RFC7432].
SRV6コアを介してエンコードするESルートごとのイーサネットA-Dは[RFC7432]に従っています。
The 24-bit ESI Label field of the ESI Label extended community carries the whole or a portion of the Argument part of the SRv6 SID when the ESI filtering approach is used along with the Transposition Scheme of encoding (Section 4); otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the AL.
ESIラベル拡張コミュニティの24ビットESIラベルフィールドには、ESIフィルタリングアプローチがエンコードの転置スキームとともに使用される場合、SRV6 SIDの引数部分の全体または一部を運びます（セクション4）。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、ALよりも等しくなければなりません。
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the A-D route. The SRv6 Endpoint Behavior SHOULD be End.DT2M. When the ESI filtering approach is used, the Service SID is used to signal the Arg.FE2 SID Argument for applicable End.DT2M behavior [RFC8986]. When the local-bias approach [RFC8365] is used, the Service SID MAY be of value 0.
BGPプレフィックスSID属性内のSRV6 L2サービスTLVに囲まれたサービスSIDは、A-Dルートとともに宣伝されています。SRV6エンドポイントの動作はend.dt2mでなければなりません。ESIフィルタリングアプローチを使用すると、サービスSIDを使用して、該当するEND.DT2Mの動作[RFC8986]のArg.fe2 SID引数を信号します。ローカルバイアスアプローチ[RFC8365]を使用すると、サービスSIDは価値がある場合があります。
Ethernet A-D per EVPN Instance (EVI) route NLRI encoding over SRv6 core is similar to what is described in [RFC7432] and [RFC8214] with the following change:
SRV6コアを介したEVPNインスタンス（EVI）ルートNLRIのイーサネットA-Dは、[RFC7432]および[RFC8214]で説明されているものと類似しています。
MPLS Label: The 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLSラベル：24ビットフィールドには、エンコード（セクション4）の転置スキーム（セクション4）が使用された場合、SRV6 SIDの関数部分の全体または一部が搭載されています。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the A-D route. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX2, End.DX2V, or End.DT2U.
BGPプレフィックスSID属性内のSRV6 L2サービスTLVに囲まれたサービスSIDは、A-Dルートとともに宣伝されています。SRV6エンドポイントの動作は、これらのいずれかでなければなりません：end.dx2、end.dx2v、またはend.dt2u。
EVPN Route Type 2 is used to advertise unicast traffic Media Access Control (MAC) + IP address reachability through MP-BGP to all other PEs in a given EVPN instance.
EVPNルートタイプ2は、特定のEVPNインスタンスのMP-BGPを介してMP-BGPを介してUnicast Traffic Media Access Control（Mac）IPアドレスの到達可能性を宣伝するために使用されます。
As a reminder, EVPN Route Type 2 is encoded as follows:
リマインダーとして、EVPNルートタイプ2は次のようにエンコードされます。
+-----------------------------------------+
| RD (8 octets) |
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------------+
| MAC Address Length (1 octet) |
+-----------------------------------------+
| MAC Address (6 octets) |
+-----------------------------------------+
| IP Address Length (1 octet) |
+-----------------------------------------+
| IP Address (0, 4, or 16 octets) |
+-----------------------------------------+
| MPLS Label1 (3 octets) |
+-----------------------------------------+
| MPLS Label2 (0 or 3 octets) |
+-----------------------------------------+
Figure 7: EVPN Route Type 2
図7：EVPNルートタイプ2
NLRI encoding over SRv6 core is similar to what is described in [RFC7432] with the following changes:
SRV6コアを介したNLRIエンコードは、[RFC7432]で説明されているものと類似しています。
MPLS Label1: This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLS Label1：これはSRV6 L2サービスTLVに関連付けられています。この24ビットフィールドは、エンコードの転置スキーム（セクション4）を使用する場合、SRV6 SIDの関数部分の全体または一部を搭載しています。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
MPLS Label2: This is associated with the SRv6 L3 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLS Label2：これはSRV6 L3サービスTLVに関連付けられています。この24ビットフィールドは、エンコードの転置スキーム（セクション4）を使用する場合、SRV6 SIDの関数部分の全体または一部を搭載しています。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
Service SIDs enclosed in the SRv6 L2 Service TLV and optionally in the SRv6 L3 Service TLV within the BGP Prefix-SID attribute are advertised along with the MAC/IP Advertisement route.
SRV6 L2サービスTLVに囲まれたサービスSID、およびBGPプレフィックスSID属性内のSRV6 L3サービスTLVには、MAC/IP広告ルートとともに宣伝されています。
Described below are different types of Route Type 2 advertisements.
以下で説明します。ルートタイプ2の広告のさまざまなタイプです。
MPLS Label1: This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLS Label1：これはSRV6 L2サービスTLVに関連付けられています。この24ビットフィールドは、エンコードの転置スキーム（セクション4）を使用する場合、SRV6 SIDの関数部分の全体または一部を搭載しています。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the route. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX2 or End.DT2U.
BGPプレフィックスSID属性内のSRV6 L2サービスTLVに囲まれたサービスSIDは、ルートとともに宣伝されています。SRV6エンドポイントの動作は、これらのいずれかでなければなりません：end.dx2またはend.dt2u。
MPLS Label1: This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLS Label1：これはSRV6 L2サービスTLVに関連付けられています。この24ビットフィールドは、エンコードの転置スキーム（セクション4）を使用する場合、SRV6 SIDの関数部分の全体または一部を搭載しています。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
MPLS Label2: This is associated with the SRv6 L3 Service TLV. This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLS Label2：これはSRV6 L3サービスTLVに関連付けられています。この24ビットフィールドは、エンコードの転置スキーム（セクション4）を使用する場合、SRV6 SIDの関数部分の全体または一部を搭載しています。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
An L2 Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the route. In addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV within the BGP Prefix-SID attribute MAY also be advertised along with the route. The SRv6 Endpoint Behavior SHOULD be one of these: for the L2 Service SID, End.DX2 or End.DT2U and for the L3 Service SID, End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6.
BGPプレフィックスSID属性内のSRV6 L2サービスTLVに囲まれたL2サービスSIDは、ルートとともに宣伝されています。さらに、BGPプレフィックス-SID属性内のSRV6 L3サービスTLVに囲まれたL3サービスSIDも、ルートとともに宣伝される場合があります。SRV6エンドポイントの動作は、これらのいずれかである必要があります。L2サービスSID、End.DX2またはEnd.DT2Uの場合、およびL3サービスSID、End.DT46、End.DT4、End.DT6、End.DX4、またはEnd.DX6。
EVPN Route Type 3 is used to advertise multicast traffic reachability information through MP-BGP to all other PEs in a given EVPN instance.
EVPNルートタイプ3は、MP-BGPを介して特定のEVPNインスタンスの他のすべてのPESにマルチキャストトラフィックリーチビリティ情報を宣伝するために使用されます。
As a reminder, EVPN Route Type 3 is encoded as follows:
リマインダーとして、EVPNルートタイプ3は次のようにエンコードされます。
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| Originating Router's IP Address |
| (4 or 16 octets) |
+---------------------------------------+
Figure 8: EVPN Route Type 3
図8：EVPNルートタイプ3
NLRI encoding over SRv6 core is similar to what is described in [RFC7432].
SRV6コアを介したNLRIエンコードは、[RFC7432]で説明されているものと似ています。
The P-Multicast Service Interface (PMSI) Tunnel Attribute [RFC6514] is used to identify the Provider tunnel (P-tunnel) used for sending Broadcast, Unknown Unicast, or Multicast (BUM) traffic. The format of the PMSI Tunnel Attribute is encoded as follows over SRv6 core:
P-Multicast Service Interface（PMSI）トンネル属性[RFC6514]を使用して、放送、不明なユニキャスト、またはマルチキャスト（バム）トラフィックの送信に使用されるプロバイダートンネル（Pトンネル）を識別します。PMSIトンネル属性の形式は、SRV6コアを介して次のようにエンコードされます。
+---------------------------------------+
| Flag (1 octet) |
+---------------------------------------+
| Tunnel Type (1 octet) |
+---------------------------------------+
| MPLS label (3 octets) |
+---------------------------------------+
| Tunnel Identifier (variable) |
+---------------------------------------+
Figure 9: PMSI Tunnel Attribute
図9：PMSIトンネル属性
Flag: This field has a value of 0, as defined per [RFC7432].
フラグ：[RFC7432]ごとに定義されているように、このフィールドの値は0です。
Tunnel Type: This field is defined per [RFC6514].
トンネルタイプ：このフィールドは[RFC6514]に従って定義されています。
MPLS label: This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when ingress replication is used and the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set as defined in [RFC6514]. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLSラベル：この24ビットフィールドには、侵入レプリケーションが使用され、エンコードの転置スキーム（セクション4）が使用されると、SRV6 SIDの関数部分の全体または一部が使用されます。それ以外の場合、[RFC6514]で定義されているように設定されています。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
Tunnel Identifier: This field is the IP address of egress PE.
トンネル識別子：このフィールドは、出力PEのIPアドレスです。
A Service SID enclosed in an SRv6 L2 Service TLV within the BGP Prefix-SID attribute is advertised along with the route. The SRv6 Endpoint Behavior SHOULD be End.DT2M.
BGPプレフィックスSID属性内のSRV6 L2サービスTLVに囲まれたサービスSIDは、ルートとともに宣伝されています。SRV6エンドポイントの動作はend.dt2mでなければなりません。
* When ESI-based filtering is used for multihoming or Ethernet Tree (E-Tree) procedures, the ESI Filtering Argument (the Arg.FE2 notation introduced in [RFC8986]) of the Service SID carried along with EVPN Route Type 1 SHOULD be merged with the applicable End.DT2M SID of Route Type 3 advertised by the remote PE by doing a bitwise logical-OR operation to create a single SID on the ingress PE. Details of split-horizon, ESI-based filtering mechanisms for multihoming are described in [RFC7432]. Details of filtering mechanisms for Leaf-originated BUM traffic in EVPN E-Tree services are provided in [RFC8317].
* MultihomingまたはEthernet Tree（E-Tree）手順にESIベースのフィルタリングが使用される場合、SIDのEVPNルートタイプ1とともに運ばれるサービスのESIフィルタリング引数（[RFC8986]で[RFC8986]で導入されたArg.fe2表記）を融合する必要があります。該当するend.dt2m sidは、リモートPEによって宣伝されているルートタイプ3のsid sid bitise elgical-or操作を行い、侵入PEに単一のSIDを作成します。マルチホミングのためのESIベースのフィルタリングメカニズムのスプリットホリゾンの詳細については、[RFC7432]で説明されています。EVPN E-Treeサービスにおける葉誘発性のバムトラフィックのフィルタリングメカニズムの詳細は、[RFC8317]に記載されています。
* When "local-bias" is used as the multihoming split-horizon method, the ESI Filtering Argument SHOULD NOT be merged with the corresponding End.DT2M SID on the ingress PE. Details of the local-bias procedures are described in [RFC8365].
* 「ローカルバイアス」がマルチホームスプリットホリゾン法として使用される場合、ESIフィルタリング引数は、侵入PEの対応するend.dt2m sidと統合しないでください。ローカルBIAS手順の詳細は[RFC8365]で説明されています。
Usage of multicast trees as P-tunnels is outside the scope of this document.
P-Tunnelsとしてのマルチキャストツリーの使用は、このドキュメントの範囲外です。
As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4) is encoded as follows:
リマインダーとして、イーサネットセグメントルート（つまり、EVPNルートタイプ4）が次のようにエンコードされます。
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| Originating Router's IP Address |
| (4 or 16 octets) |
+---------------------------------------+
Figure 10: EVPN Route Type 4
図10：EVPNルートタイプ4
NLRI encoding over SRv6 core is similar to what is described in [RFC7432].
SRV6コアを介したNLRIエンコードは、[RFC7432]で説明されているものと似ています。
SRv6 Service TLVs within the BGP Prefix-SID attribute are not advertised along with this route. The processing of the route has not changed -- it remains as described in [RFC7432].
BGPプレフィックスSID属性内のSRV6サービスTLVは、このルートとともに宣伝されていません。ルートの処理は変更されていません。[RFC7432]に記載されているとおりです。
EVPN Route Type 5 is used to advertise IP address reachability through MP-BGP to all other PEs in a given EVPN instance. The IP address may include a host IP prefix or any specific subnet.
EVPNルートタイプ5は、特定のEVPNインスタンスのMP-BGPを介して他のすべてのPESにIPアドレスの到達可能性を宣伝するために使用されます。IPアドレスには、ホストIPプレフィックスまたは特定のサブネットが含まれる場合があります。
As a reminder, EVPN Route Type 5 is encoded as follows:
リマインダーとして、EVPNルートタイプ5は次のようにエンコードされます。
+-----------------------------------------+
| RD (8 octets) |
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------------+
| IP Prefix Length (1 octet) |
+-----------------------------------------+
| IP Prefix (4 or 16 octets) |
+-----------------------------------------+
| GW IP Address (4 or 16 octets) |
+-----------------------------------------+
| MPLS Label (3 octets) |
+-----------------------------------------+
Figure 11: EVPN Route Type 5
図11：EVPNルートタイプ5
NLRI encoding over SRv6 core is similar to what is described in [RFC9136] with the following change:
SRV6コアを介したNLRIエンコードは、次の変更を受けて[RFC9136]で説明されているものと似ています。
MPLS Label: This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLSラベル：この24ビットフィールドには、エンコード（セクション4）の転置スキーム（セクション4）が使用された場合、SRV6 SIDの関数部分の全体または一部が搭載されています。それ以外の場合は、高次の20ビット（つまり、0x000030）で暗黙のヌルに設定されています。どちらの場合でも、値は24ビットで設定されます。転置スキームを使用する場合、転置長は24以下であり、FL以下でなければなりません。
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DT4, End.DT6, End.DT46, End.DX4, or End.DX6.
SRV6サービスSIDは、SRV6 L3サービスTLVの一部としてエンコードされています。SRV6エンドポイントの動作は、これらのいずれかでなければなりません：end.dt4、end.dt6、end.dt46、end.dx4、またはend.dx6。
These routes do not require the advertisement of SRv6 Service TLVs along with them. Similar to EVPN Route Type 4, the BGP next hop is equal to the IPv6 address of egress PE.
これらのルートでは、SRV6サービスTLVの広告を必要としません。EVPNルートタイプ4と同様に、BGP Next Hopは、出力PEのIPv6アドレスに等しくなります。
In case of any errors encountered while processing SRv6 Service TLVs, the details of the error SHOULD be logged for further analysis.
SRV6サービスTLVの処理中に発生したエラーが発生した場合、さらに分析するためにエラーの詳細を記録する必要があります。
If multiple instances of the SRv6 L3 Service TLV are encountered, all but the first instance MUST be ignored.
SRV6 L3サービスTLVの複数のインスタンスが発生した場合、最初のインスタンスを除くすべてを無視する必要があります。
If multiple instances of the SRv6 L2 Service TLV are encountered, all but the first instance MUST be ignored.
SRV6 L2サービスTLVの複数のインスタンスが発生した場合、最初のインスタンスを除くすべてを無視する必要があります。
An SRv6 Service TLV is considered malformed in the following cases:
SRV6サービスTLVは、次の場合に奇形と見なされます。
* The TLV Length is less than 1.
* TLVの長さは1未満です。
* The TLV Length is inconsistent with the length of the BGP Prefix-SID attribute.
* TLVの長さは、BGPプレフィックス-SID属性の長さと矛盾しています。
* At least one of the constituent Sub-TLVs is malformed.
* 構成要素サブTLVの少なくとも1つは奇形です。
An SRv6 Service Sub-TLV is considered malformed in the following case:
SRV6サービスサブTLVは、次の場合に奇形と見なされます。
* The Sub-TLV Length is inconsistent with the length of the enclosing SRv6 Service TLV.
* サブTLVの長さは、囲まれたSRV6サービスTLVの長さと矛盾しています。
An SRv6 SID Information Sub-TLV is considered malformed in the following cases:
SRV6 SID情報サブTLVは、次の場合に奇形と見なされます。
* The Sub-TLV Length is less than 21.
* サブTLVの長さは21未満です。
* The Sub-TLV Length is inconsistent with the length of the enclosing SRv6 Service TLV.
* サブTLVの長さは、囲まれたSRV6サービスTLVの長さと矛盾しています。
* At least one of the constituent Sub-Sub-TLVs is malformed.
* 構成要素のサブサブTLVの少なくとも1つは奇形です。
An SRv6 Service Data Sub-Sub-TLV is considered malformed in the following case:
SRV6サービスデータサブサブ-TLVは、次の場合に奇形と見なされます。
* The Sub-Sub-TLV Length is inconsistent with the length of the enclosing SRv6 service Sub-TLV.
* サブサブ-TLVの長さは、囲まれたSRV6サービスサブTLVの長さと矛盾しています。
Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because its Type is unrecognized.
TLV、Sub-TLV、またはSub-Sub-TLVは、そのタイプが認識されていないため、奇形とは見なされません。
Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because of failing any semantic validation of its Value field.
TLV、Sub-TLV、またはSub-Sub-TLVは、その値フィールドのセマンティック検証に失敗したため、奇形とは見なされません。
The SRv6 overlay service requires the Service SID for forwarding. The treat-as-withdraw action [RFC7606] MUST be performed when at least one malformed SRv6 Service TLV is present in the BGP Prefix-SID attribute.
SRV6オーバーレイサービスには、転送にサービスSIDが必要です。少なくとも1つの奇形のSRV6サービスTLVがBGPプレフィックス-SID属性に存在する場合、withDrawの処理アクション[RFC7606]を実行する必要があります。
The SRv6 SID value in the SRv6 SID Information Sub-TLV is invalid when the SID Structure Sub-Sub-TLV transposition length is greater than the number of bits of the label field or if any of the conditions for the fields of the Sub-Sub-TLV, as specified in Section 3.2.1, is not met. The transposition offset and length MUST be 0 when the Sub-Sub-TLV is advertised along with routes where the Transposition Scheme is not applicable (e.g., for global IPv6 service [RFC2545] where there is no label field). The path having any such Prefix-SID attribute without any valid SRv6 SID information MUST be considered ineligible during the selection of the best path for the corresponding prefix.
SRV6 SID情報Sub-TLVのSRV6 SID値は、SID構造サブサブTLV転置長がラベルフィールドのビット数よりも大きい場合、またはサブサブのフィールドの条件のいずれかよりも大きい場合、無効です。-TLVは、セクション3.2.1で指定されているように、満たされていません。サブサブTLVが宣伝されている場合、転置オフセットと長さは0でなければなりません。転置スキームが適用されないルート（例：ラベルフィールドがないグローバルIPv6サービス[RFC2545]の場合）。有効なSRV6 SID情報のないそのようなプレフィックスSID属性を持つパスは、対応するプレフィックスに最適なパスの選択中に不適格と見なされる必要があります。
This document introduces two new TLV Types of the BGP Prefix-SID attribute. IANA has assigned Type values in the "BGP Prefix-SID TLV Types" subregistry as follows:
このドキュメントでは、2つの新しいTLVタイプのBGPプレフィックス-SID属性を紹介します。IANAは、次のように「BGPプレフィックス-SID TLVタイプ」サブレジストリにタイプ値を割り当てました。
+=======+=====================+===========+
| Value | Type | Reference |
+=======+=====================+===========+
| 4 | Deprecated | RFC 9252 |
+-------+---------------------+-----------+
| 5 | SRv6 L3 Service TLV | RFC 9252 |
+-------+---------------------+-----------+
| 6 | SRv6 L2 Service TLV | RFC 9252 |
+-------+---------------------+-----------+
Table 1: BGP Prefix-SID TLV Types Subregistry
表1：BGPプレフィックスSID TLVタイプのサブレジストリ
Value 4 previously corresponded to the SRv6-VPN SID TLV, which was specified in earlier draft versions of this document and used by early implementations of this specification. It was deprecated and replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs.
Value 4は、以前はSRV6-VPN SID TLVに対応していました。これは、このドキュメントの以前のドラフトバージョンで指定され、この仕様の早期実装で使用されていました。それは非推奨になり、SRV6 L3サービスとSRV6 L2サービスTLVに置き換えられました。
IANA has created and now maintains a new subregistry called "SRv6 Service Sub-TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedures, per [RFC8126], for this subregistry are according to Table 2.
IANAは、「Border Gateway Protocol（BGP）パラメーター」レジストリの下で、「SRV6 Service Sub-TLV型」と呼ばれる新しいサブレジストリを作成し、維持しています。このサブレジストリのための[RFC8126]ごとの登録手順は、表2に従っています。
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 1-127 | IETF Review |
+---------+-------------------------+
| 128-254 | First Come First Served |
+---------+-------------------------+
| 255 | IETF Review |
+---------+-------------------------+
Table 2: SRv6 Service Sub-TLV Types Subregistry Registration Procedures
表2：SRV6サービスサブTLVタイプサブレジストリ登録手順
IANA has populated this subregistry as follows. Note that the SRv6 SID Information Sub-TLV is defined in this document:
IANAは次のようにこのサブレジストリを埋め込んでいます。SRV6 SID Information Sub-TLVは、このドキュメントで定義されていることに注意してください。
+=======+==============================+===========+
| Value | Type | Reference |
+=======+==============================+===========+
| 0 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
| 1 | SRv6 SID Information Sub-TLV | RFC 9252 |
+-------+------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
Table 3: SRv6 Service Sub-TLV Types Subregistry Initial Contents
表3：SRV6サービスサブTLVタイプサブレジストリ初期コンテンツ
IANA has created and now maintains a new subregistry called "SRv6 Service Data Sub-Sub-TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedures for this subregistry are according to Table 4.
IANAは、「Border Gateway Protocol（BGP）パラメーター」レジストリの下で「SRV6サービスデータサブサブTLVタイプ」と呼ばれる新しいサブレジストリを作成し、維持しています。このサブレジストリの登録手順は、表4に従っています。
+=========+=========================+
| Range | Registration Procedure |
+=========+=========================+
| 1-127 | IETF Review |
+---------+-------------------------+
| 128-254 | First Come First Served |
+---------+-------------------------+
| 255 | IETF Review |
+---------+-------------------------+
Table 4: SRv6 Service Data Sub-Sub-TLV Types Subregistry Registration Procedures
表4：SRV6サービスデータサブサブ-TLVタイプサブレジストリ登録手順
The following Sub-Sub-TLV Type is defined in this document:
次のサブサブ-TLVタイプは、このドキュメントで定義されています。
+=======+================================+===========+
| Value | Type | Reference |
+=======+================================+===========+
| 0 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
| 1 | SRv6 SID Structure Sub-Sub-TLV | RFC 9252 |
+-------+--------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
Table 5: SRv6 Service Data Sub-Sub-TLV Types Subregistry Initial Contents
表5：SRV6サービスデータサブサブ-TLVタイプサブレジストリ初期コンテンツ
IANA has created and now maintains a new subregistry called "BGP SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedure for this subregistry is IETF Review, and all 8-bit positions of the flags are currently unassigned.
IANAは、「Border Gateway Protocol（BGP）パラメーター」レジストリの下で「BGP SRV6 Service SID Flags」と呼ばれる新しいサブレジストリを作成し、維持しています。このサブレジストリの登録手順はIETFレビューであり、フラグの8ビットのすべての位置は現在割り当てられていません。
IANA has added this document as a reference for value 128 ("MPLS-labeled VPN address") in the "SAFI Values" subregistry under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry.
IANAは、このドキュメントを「後続のアドレスファミリ識別子（SAFI）パラメーター」レジストリの下で「SAFI値」サブレジストリに値128（「MPLS標識VPNアドレス」）の参照として追加しました。
This document specifies extensions to the BGP protocol for the signaling of services for SRv6. These specifications leverage existing BGP protocol mechanisms for the signaling of various types of services. It also builds upon existing elements of the SR architecture (more specifically, SRv6). As such, this section largely provides pointers (as a reminder) to the security considerations of those existing specifications while also covering certain, newer security aspects for the specifications newly introduced by this document.
このドキュメントは、SRV6のサービスのシグナル伝達のためのBGPプロトコルへの拡張機能を指定します。これらの仕様は、さまざまな種類のサービスのシグナル伝達のために既存のBGPプロトコルメカニズムを活用しています。また、SRアーキテクチャの既存の要素（より具体的にはSRV6）に基づいています。そのため、このセクションは、これらの既存の仕様のセキュリティに関する考慮事項のポインター（リマインダーとして）を主に提供し、このドキュメントで新たに導入された仕様の特定の新しいセキュリティの側面をカバーします。
Techniques related to authentication of BGP sessions for securing messages between BGP peers, as discussed in the BGP specification [RFC4271] and in the security analysis for BGP [RFC4272], apply. The discussion of the use of the TCP Authentication Option to protect BGP sessions is found in [RFC5925], while [RFC6952] includes an analysis of BGP keying and authentication issues. This document does not introduce any additional BGP session security considerations.
BGP仕様[RFC4271]およびBGP [RFC4272]のセキュリティ分析で説明されているように、BGPピア間でメッセージを保護するためのBGPセッションの認証に関連する手法が適用されます。BGPセッションを保護するためのTCP認証オプションの使用に関する議論は[RFC5925]にあり、[RFC6952]にはBGPキーイングと認証の問題の分析が含まれています。このドキュメントでは、追加のBGPセッションセキュリティに関する考慮事項は導入されていません。
This document does not introduce new services or BGP NLRI types but extends the signaling of existing ones for SRv6. Therefore, the security considerations for the respective BGP services, such as BGP IPv4 over IPv6 NH [RFC8950], BGP IPv6 L3VPN [RFC4659], BGP IPv6 [RFC2545], BGP EVPN [RFC7432], and IP EVPN [RFC9136], apply as discussed in their respective documents. [RFC8669] discusses mechanisms to prevent the leaking of the BGP Prefix-SID attribute, which carries SR information, outside the SR domain.
このドキュメントでは、新しいサービスやBGP NLRIタイプを導入するのではなく、SRV6の既存のサービスのシグナル伝達を拡張します。したがって、IPv6 NH [RFC8950]、BGP IPv6 L3VPN [RFC4659]、BGP IPv6 [RFC2545]、BGP EVPN [RFC7432]、IP EVPN [RFC9136]、IP EVPN [RFC9136]、IPv6 L3VPN [RFC8950]、BGP IPv6 L3VPN [RFC4659]、IP EVPN [RFC9136]など、BGP IPv4など、それぞれのBGPサービスのセキュリティ上の考慮事項それぞれのドキュメントで議論されています。[RFC8669]は、SRドメインの外側にSR情報を運ぶBGPプレフィックスSID属性の漏れを防ぐメカニズムについて説明します。
As a reminder, several of the BGP services (i.e., the AFI/SAFI used for their signaling) were initially introduced for one encapsulation mechanism and later extended for others, e.g., EVPN MPLS [RFC7432] was extended for Virtual eXtensible Local Area Network (VXLAN) encapsulation and Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC8365]. [RFC9012] enables the use of various IP encapsulation mechanisms along with different BGP SAFIs for their respective services. The existing filtering mechanisms for preventing the leak of the encapsulation information (carried in BGP attributes) and preventing the advertisement of prefixes from the provider's internal address space (especially the SRv6 Block, as discussed in [RFC8986]) to external peers (or into the Internet) also apply in the case of SRv6.
リマインダーとして、BGPサービスのいくつか（つまり、シグナル伝達に使用されるAFI/SAFI）が最初に1つのカプセル化メカニズムに導入され、後に他のメカニズムに拡張されました。vxlan）汎用ルーティングカプセル化（nvgre）[RFC8365]を使用したカプセル化とネットワーク仮想化。[RFC9012]は、それぞれのサービスにさまざまなBGP SAFISとともに、さまざまなIPカプセル化メカニズムを使用できます。カプセル化情報の漏れを防止するための既存のフィルタリングメカニズム（BGP属性で運ばれる）およびプロバイダーの内部アドレス空間（特に[RFC8986]で説明されているSRV6ブロック）から外部ピア（または外部の）からのプレフィックスの広告を防ぐための既存のフィルタリングメカニズムインターネット）SRV6の場合にも適用されます。
Specific to SRv6, a misconfiguration or error in the BGP filtering mechanisms mentioned above may result in exposing information, such as SRv6 Service SIDs to external peers or other unauthorized entities. However, an attempt to exploit this information or to raise an attack by injecting packets into the network (e.g., customer networks in case of VPN services) is mitigated by the existing SRv6 data plane security mechanisms, as described in the next section.
SRV6に特有の場合、上記のBGPフィルタリングメカニズムの誤った構成またはエラーにより、SRV6サービスSIDなどの情報が外部のピアや他の不正なエンティティに公開される可能性があります。ただし、次のセクションで説明されているように、この情報を悪用したり、ネットワークにパケットを注入したりすることでパケットを注入して攻撃を提起しようとする試みは、既存のSRV6データプレーンセキュリティメカニズムによって軽減されます。
This section provides a brief reminder and an overview of the security considerations related to SRv6 with pointers to existing specifications. This document introduces no new security considerations of its own from the SRv6 data plane perspective.
このセクションでは、SRV6に関連するセキュリティに関する考慮事項の簡単なリマインダーと、既存の仕様へのポインターを備えた概要を説明します。このドキュメントでは、SRV6データプレーンの観点から独自の新しいセキュリティ上の考慮事項を紹介しません。
SRv6 operates within a trusted SR domain. The data packets corresponding to service flows between PE routers are encapsulated (using SRv6 SIDs advertised via BGP) and carried within this trusted SR domain (e.g., within a single AS or between multiple ASes within a single provider network).
SRV6は、信頼できるSRドメイン内で動作します。PEルーター間のサービスフローに対応するデータパケットは、この信頼できるSRドメイン内（たとえば、単一のプロバイダーネットワーク内の複数のASEの間で）内部で運ばれ（BGPを介して宣伝されたSRV6 SIDを使用）カプセル化されています。
The security considerations of the SR architecture are covered by [RFC8402]. More detailed security considerations, specifically of SRv6 and SRH, are covered by [RFC8754] as they relate to SR Attacks (Section 7.1), Service Theft (Section 7.2), and Topology Disclosure (Section 7.3). As such, an operator deploying SRv6 MUST follow the considerations described in Section 7 of [RFC8754] to implement the infrastructure Access Control Lists (ACLs) and the recommendations described in BCP 38 [RFC2827] and BCP 84 [RFC3704].
SRアーキテクチャのセキュリティ上の考慮事項は、[RFC8402]でカバーされています。より詳細なセキュリティに関する考慮事項、特にSRV6とSRHの考慮事項は、SR攻撃（セクション7.1）、サービス盗難（セクション7.2）、およびトポロジの開示（セクション7.3）に関連する[RFC8754]でカバーされています。そのため、SRV6を展開するオペレーターは、[RFC8754]のセクション7で説明されている考慮事項に従って、インフラストラクチャアクセス制御リスト（ACL）とBCP 38 [RFC2827]およびBCP 84 [RFC3704]で説明されている推奨事項を実装する必要があります。
The SRv6 deployment and SID allocation guidelines, as described in [RFC8986], simplify the deployment of the ACL filters (e.g., a single ACL corresponding to the SRv6 Block applied to the external interfaces on border nodes is sufficient to block packets destined to any SRv6 SID in the domain from external/unauthorized networks). While there is an assumed trust model within an SR domain, such that any node sending a packet to an SRv6 SID is assumed to be allowed to do so, there is also the option of using an SRH Hashed Message Authentication Code (HMAC) TLV [RFC8754], as described in [RFC8986], for validation.
[RFC8986]に記載されているSRV6の展開とSIDの割り当てガイドラインは、ACLフィルターの展開を簡素化します（たとえば、境界ノードの外部インターフェイスに適用されるSRV6ブロックに対応する単一のACLは、SRV6に誘導されるパケットをブロックするのに十分です。外部/不正なネットワークからドメイン内のSID）。SRドメイン内には想定される信頼モデルがありますが、SRV6 SIDにパケットを送信するノードがそうすることが許可されていると想定されていますが、SRHハッシュされたメッセージ認証コード（HMAC）TLVを使用するオプションもあります[[RFC8986]で説明されているように、RFC8754]、検証のため。
The SRv6 Endpoint Behaviors implementing the services signaled in this document are defined in [RFC8986]; hence, the security considerations of that document apply. These considerations are independent of the protocol used for service deployment, i.e., independent of BGP signaling of SRv6 services.
このドキュメントで合図されたサービスを実装するSRV6エンドポイントの動作は、[RFC8986]で定義されています。したがって、そのドキュメントのセキュリティ上の考慮事項が適用されます。これらの考慮事項は、サービスの展開に使用されるプロトコル、つまりSRV6サービスのBGPシグナル伝達とは無関係です。
These considerations help protect transit traffic as well as services, such as VPNs, to avoid service theft or injection of traffic into customer VPNs.
これらの考慮事項は、サービスの盗難や顧客VPNへのトラフィックの注入を避けるために、VPNなどのサービスだけでなく、輸送トラフィックとサービスを保護するのに役立ちます。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<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>.
[RFC2545] Marques、P。and F. Dupont、「IPv6 Inter-DomainルーティングのBGP-4マルチプロトコル拡張の使用」、RFC 2545、DOI 10.17487/RFC2545、1999年3月、<https：//ww.rfc-editor。org/info/rfc2545>。
[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>.
[RFC4271] Rekhter、Y.、ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487/RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、DOI 10.17487/RFC4364、2006年2月、<https://www.rfc-editor.org/info/RFC4364>。
[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>.
[RFC4456] Bates、T.、Chen、E。、およびR. Chandra、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、DOI 10.17487/RFC4456、2006年4月、<https：//www.rfc-editor.org/info/rfc4456>。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, <https://www.rfc-editor.org/info/rfc4659>.
[RFC4659] de Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP仮想ネットワーク（VPN）IPv6 VPNの拡張」、RFC 4659、DOI 10.17487/RFC4659、2006年9月、<https://www.rfc-editor.org/info/rfc4659>。
[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>.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、DOI 10.17487/RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS/BGP IP VPNSのマルチキャストのBGPエンコーディングと手順」、RFC 6514、DOI 10.17487/RFC6514、2012年2月、<<<<https://www.rfc-editor.org/info/rfc6514>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、およびW. Henderickx、「BGP MPLSベースのイーサネットVPN」、RFC 7432、DOI 10.17487/RFC7432、2015年2月、<https://www.rfc-editor.org/info/rfc7432>。
[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>.
[RFC7606] Chen、E.、Ed。、Scudder、J.、Ed。、Mohapatra、P.、およびK. Patel、「BGP更新メッセージの改訂エラー処理」、RFC 7606、DOI 10.17487/RFC7606、2015年8月、<https://www.rfc-editor.org/info/rfc7606>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487/RFC8200、2017年7月、<https://www.rfc-editor.org/info/rfc8200>。
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.
[RFC8214] Boutros、S.、Sajassi、A.、Salam、S.、Drake、J。、およびJ. Rabadan、「イーサネットVPNの仮想プライベートワイヤサービスサポート」、RFC 8214、DOI 10.17487/RFC8214、2017年8月、<https://www.rfc-editor.org/info/rfc8214>。
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
[RFC8277] Rosen、E。、「BGPを使用してプレフィックスに対処するためにMPLSラベルをバインドする」、RFC 8277、DOI 10.17487/RFC8277、2017年10月、<https://www.rfc-editor.org/info/rfc8277>
[RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, January 2018, <https://www.rfc-editor.org/info/rfc8317>.
[RFC8317] Sajassi、A.、Ed。、Salam、S.、Drake、J.、Uttaro、J.、Boutros、S.、およびJ. Rabadan、 "Ethernet-Tree（E-Tree）サポート（E-Tree）サポート（E-Tree）サポート（EVPN）およびプロバイダーバックボーンブリッジングEVPN（PBB-EVPN） "、RFC 8317、DOI 10.17487/RFC8317、2018年1月、<https://www.rfc-editor.org/info/rfc8317>。
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>.
[RFC8365] Sajassi、A.、Ed。、Drake、J.、Ed。、Bitar、N.、Shekhar、R.、Uttaro、J.、およびW. Henderickx、「Ethernet VPNを使用したネットワーク仮想化オーバーレイソリューション（EVPN））」、RFC 8365、DOI 10.17487/RFC8365、2018年3月、<https://www.rfc-editor.org/info/rfc8365>。
[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>.
[RFC8402] Filsfils、C.、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019, <https://www.rfc-editor.org/info/rfc8669>.
[RFC8669] Previdi、S.、Filsfils、C.、Lindem、A.、Ed。、Sreekantiah、A.、およびH. Gredler、「BGPのセグメントルーティングプレフィックスセグメント識別子拡張ング」、RFC 8669、DOI 10.17487/RFC869、2019年12月、<https://www.rfc-editor.org/info/rfc8669>。
[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>.
[RFC8754] Filsfils、C.、Ed。、Dukes、D.、Ed。、Previdi、S.、Leddy、J.、Matsushima、S.、およびD. Voyer、「IPv6セグメントルーティングヘッダー（SRH）」、RFC8754、doi 10.17487/rfc8754、2020年3月、<https://www.rfc-editor.org/info/rfc8754>。
[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. Patel, "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop", RFC 8950, DOI 10.17487/RFC8950, November 2020, <https://www.rfc-editor.org/info/rfc8950>.
[RFC8950] Litkowski、S.、Agrawal、S.、Ananthamurthy、K。、およびK. Patel、「IPv4ネットワークレイヤーリーチ可能性情報（NLRI）IPv6 Next Hop」、RFC 8950、DOI 10.17487/RFC8950、2020202020202020、<https://www.rfc-editor.org/info/rfc8950>。
[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>.
[RFC8986] Filsfils、C.、Ed。、Camarillo、P.、Ed。、Leddy、J.、Voyer、D.、Matsushima、S.、およびZ. Li、「IPv6（SRV6）ネットワークプログラミングを介したセグメントルーティング」、RFC 8986、DOI 10.17487/RFC8986、2021年2月、<https://www.rfc-editor.org/info/rfc8986>。
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, <https://www.rfc-editor.org/info/rfc9136>.
[RFC9136] Rabadan、J.、Ed。、Henderickx、W.、Drake、J.、Lin、W。、およびA. Sajassi、「イーサネットVPN（EVPN）のIPプレフィックス広告」、RFC 9136、DOI 10.17487/RFC91363636、2021年10月、<https://www.rfc-editor.org/info/rfc9136>。
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., and W. Lin, "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022, <https://www.rfc-editor.org/info/rfc9251>.
[RFC9251] Sajassi、A.、Thoria、S.、Mishra、M.、Patel、K.、Drake、J。、およびW. Lin、 "Internet Group Management Protocol（IGMP）およびMulticastリスナーDiscovery（MLD）プロキシイーサネットVPN（EVPN） "、RFC 9251、DOI 10.17487/RFC9251、2022年6月、<https://www.rfc-editor.org/info/rfc9251>。
[IGP-FLEX-ALGO] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-20, 18 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20>.
[Igp-flex-algo] Psenak、P.、Ed。、Hegde、S.、Filsfils、C.、Talaulikar、K。、およびA. Gulko、「IGP Flexible Algorithm」、進行中の作業、インターネットドラフト、ドラフト-ietf-lsr-flex-algo-20、2022年5月18日、<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、DOI 10.17487/RFC2827、2000年5月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc2827>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、DOI 10.17487/RFC3704、2004年3月、<https://www.rfc-editor.org/info/rfc3704>。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.
[RFC4272] Murphy、S。、「BGPセキュリティ脆弱性分析」、RFC 4272、DOI 10.17487/RFC4272、2006年1月、<https://www.rfc-editor.org/info/rfc4272>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、RFC 5925、DOI 10.17487/RFC5925、2010年6月、<https://www.rfc-editor.org/info/rfc5925>。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6513]ローゼン、E。、編およびR. Aggarwal、ed。、「MPLS/BGP IP VPNSのマルチキャスト」、RFC 6513、DOI 10.17487/RFC6513、2012年2月、<https://www.rfc-editor.org/info/rfc6513>。
[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>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDPの問題の分析（KARP）デザインガイドのキーイングと認証による問題」、RFC 6952、doi10.17487/rfc6952、2013年5月、<https://www.rfc-editor.org/info/rfc6952>。
[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>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[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>.
[RFC9012] Patel、K.、Van de Velde、G.、Sangli、S。、およびJ. Scudder、「BGPトンネルカプセル化属性」、RFC 9012、DOI 10.17487/RFC9012、2021年4月、<https：//.rfc-editor.org/info/rfc9012>。
[SEGMENT-ROUTING-POLICY] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-22, 22 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22>.
[セグメントルーティングポリティ] Filsfils、C.、Talaulikar、K.、ed。、Voyer、D.、Bogdanov、A。、およびP. Mattes、「セグメントルーティングポリシーアーキテクチャ」、進行中の作業、インターネットドラフト、ドラフト-ITET-SPRING-SEMING-ROUTING-POLICY-22、2022年3月22日、<https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22>。
Acknowledgements
謝辞
The authors of this document would like to thank Stephane Litkowski, Rishabh Parekh, Xiejingrong, Rajesh M., Mustapha Aissaoui, Alexander Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron Bonica, and Joel Halpern for their comments and review of this document. The authors would also like to thank Document Shepherd Matthew Bocci for his review and AD Martin Vigoureux for his review that resulted in helpful comments for improving this document.
この文書の著者は、ステファン・リトコフスキー、リシャブ・パレフ、Xiejingrong、Rajesh M.、Mustapha Aissaoui、Alexander Vainshtein、Eduard Metz、Shraddha Hegde、Eduard Vasilenko、Ron Bonica、およびJoel HalpernのコメントとJoel Halpernに感謝します。。著者はまた、Document Shepherd Matthew BocciのレビューとAd Martin Vigoureuxのレビューに感謝したいと思います。
Contributors
貢献者
Clarence Filsfils Cisco Email: cfilsfil@cisco.com
Clarence Filsfils Cisco Email：cfilsfil@cisco.com
Satoru Matsushima SoftBank Email: satoru.matsushima@g.softbank.co.jp
Satoru Matsushima SoftBankメール：satoru.matsushima@g.softbank.co.jp
Dirk Steinberg Steinberg Consulting Email: dirk@lapishills.com
Dirk Steinberg Steinbergコンサルティングメール：dirk@lapishills.com
Daniel Bernier Bell Canada Email: daniel.bernier@bell.ca
Daniel Bernier Bell Canada Email：daniel.bernier@bell.ca
Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca
Daniel Voyer Bell Canadaメール：daniel.voyer@bell.ca
Jonn Leddy Individual Email: john@leddy.net
Jonn Leddy個人メール：john@leddy.net
Swadesh Agrawal Cisco Email: swaagraw@cisco.com
Swadesh Agrawal Ciscoメール：swaagraw@cisco.com
Patrice Brissette Cisco Email: pbrisset@cisco.com
Patrice Brissette Ciscoメール：pbrisset@cisco.com
Ali Sajassi Cisco Email: sajassi@cisco.com
Ali Sajassi Ciscoメール：sajassi@cisco.com
Bart Peirens Proximus Belgium Email: bart.peirens@proximus.com
Bart Peirens Proximus Belgiumメール：bart.peirens@proximus.com
Darren Dukes Cisco Email: ddukes@cisco.com
Darren Dukes Cisco Email：ddukes@cisco.com
Pablo Camarilo Cisco Email: pcamaril@cisco.com
パブロカマリロシスコメール：pcamaril@cisco.com
Shyam Sethuram Cisco Email: shyam.ioml@gmail.com
Shyam Sethuram Ciscoメール：shyam.ioml@gmail.com
Zafar Ali Cisco Email: zali@cisco.com
Zafar Ali Ciscoメール：zali@cisco.com
Authors' Addresses
著者のアドレス
Gaurav Dawra (editor) LinkedIn United States of America Email: gdawra.ietf@gmail.com
Gaurav Dawra（編集者）LinkedInアメリカ合衆国電子メール：gdawra.ietf@gmail.com
Ketan Talaulikar (editor) Cisco Systems India Email: ketant.ietf@gmail.com
Ketan Talaulikar（編集者）Cisco Systems India Email：ketant.ietf@gmail.com
Robert Raszuk NTT Network Innovations 940 Stewart Dr. Sunnyvale, CA 94085 United States of America Email: robert@raszuk.net
Robert Raszuk NTT Network Innovations 940 Stewart Dr. Sunnyvale、CA 94085アメリカ合衆国電子メール：robert@raszuk.net
Bruno Decraene Orange France Email: bruno.decraene@orange.com
Bruno Decraene Orange Franceメール：bruno.decraene@orange.com
Shunwan Zhuang Huawei Technologies China Email: zhuangshunwan@huawei.com
Shunwan Zhuang Huawei Technologies China Email：Zhuangshunwan@huawei.com
Jorge Rabadan Nokia United States of America Email: jorge.rabadan@nokia.com
Jorge Rabadan Nokia United States of America Email：jorge.rabadan@nokia.com