[要約] RFC 8986は、IPv6ネットワーク上でセグメントルーティング（SRv6）を実装するための方法を定義します。この技術は、ネットワークの柔軟性と効率性を高めることを目的としており、データセンター、広域ネットワーク、エッジコンピューティングなど、さまざまな環境での利用が想定されています。
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8986 P. Camarillo, Ed.
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 J. Leddy
Akamai Technologies
D. Voyer
Bell Canada
S. Matsushima
SoftBank
Z. Li
Huawei Technologies
February 2021
Segment Routing over IPv6 (SRv6) Network Programming
IPv6（SRV6）ネットワークプログラミングを介したセグメントルーティング
Abstract
概要
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.
IPv6（SRV6）ネットワークプログラミングフレームワークを介してセグメントルーティングを使用すると、ネットワークオペレータまたはアプリケーションがIPv6パケットヘッダー内の一連の命令をエンコードすることによってパケット処理プログラムを指定することができます。
Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.
各命令は、ネットワーク内の1つまたは複数のノードに実装され、パケット内のSRV6セグメント識別子によって識別されます。
This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.
このドキュメントはSRV6ネットワークプログラミングの概念を定義し、アンダーライン最適化を伴う相互運用可能なオーバーレイの作成を可能にするSRV6動作のベースセットを指定します。
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/rfc8986.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frofc8986で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Requirements Language
3. SRv6 SID
3.1. SID Format
3.2. SID Allocation within an SR Domain
3.3. SID Reachability
4. SR Endpoint Behaviors
4.1. End: Endpoint
4.1.1. Upper-Layer Header
4.2. End.X: L3 Cross-Connect
4.3. End.T: Specific IPv6 Table Lookup
4.4. End.DX6: Decapsulation and IPv6 Cross-Connect
4.5. End.DX4: Decapsulation and IPv4 Cross-Connect
4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup
4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup
4.8. End.DT46: Decapsulation and Specific IP Table Lookup
4.9. End.DX2: Decapsulation and L2 Cross-Connect
4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup
4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup
4.12. End.DT2M: Decapsulation and L2 Table Flooding
4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy with
Encapsulation
4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH
4.15. End.BM: Endpoint Bound to an SR-MPLS Policy
4.16. Flavors
4.16.1. PSP: Penultimate Segment Pop of the SRH
4.16.2. USP: Ultimate Segment Pop of the SRH
4.16.3. USD: Ultimate Segment Decapsulation
5. SR Policy Headend Behaviors
5.1. H.Encaps: SR Headend with Encapsulation in an SR Policy
5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation
5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames
5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 Frames
6. Counters
7. Flow-Based Hash Computation
8. Control Plane
8.1. IGP
8.2. BGP-LS
8.3. BGP IP/VPN/EVPN
8.4. Summary
9. Security Considerations
10. IANA Considerations
10.1. Ethernet Next Header Type
10.2. SRv6 Endpoint Behaviors Registry
10.2.1. Registration Procedures
10.2.2. Initial Registrations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Segment Routing [RFC8402] leverages the source routing paradigm. An ingress node steers a packet through an ordered list of instructions, called "segments". Each one of these instructions represents a function to be called at a specific location in the network. A function is locally defined on the node where it is executed and may range from simply moving forward in the segment list to any complex user-defined behavior. Network Programming combines Segment Routing functions, both simple and complex, to achieve a networking objective that goes beyond mere packet routing.
セグメントルーティング[RFC8402]ソースルーティングパラダイムを活用します。入力ノードは、「セグメント」と呼ばれる「セグメント」と呼ばれる命令の順序付きリストを介してパケットを開きます。これらの命令のそれぞれは、ネットワーク内の特定の場所で呼び出される機能を表します。関数はローカルに実行されるノード上でローカルに定義されており、セグメントリスト内で単純に複雑なユーザー定義の動作に及ぶことができます。ネットワークプログラミングは、単純で複雑なセグメントルーティング関数を組み合わせて、単なるパケットルーティングを超えるネットワーキングの目的を達成します。
This document defines the SRv6 Network Programming concept and specifies the main Segment Routing behaviors to enable the creation of interoperable overlays with underlay optimization.
このドキュメントはSRV6ネットワークプログラミングの概念を定義し、アンダーレイ最適化との相互運用可能なオーバーレイの作成を可能にするためのメインセグメントルーティング動作を指定します。
[SRV6-NET-PGM-ILLUST] illustrates the concepts defined in this document.
[SRV6-Net-PGM-ILLUST]は、この文書で定義されている概念を示しています。
Familiarity with the Segment Routing Header [RFC8754] is expected.
セグメントルーティングヘッダー[RFC8754]に精通していることが予想されます。
The following terms used within this document are defined in [RFC8402]: Segment Routing (SR), SR Domain, Segment ID (SID), SRv6, SRv6 SID, SR Policy, Prefix-SID, and Adj-SID.
この文書内で使用されている以下の用語は、[RFC8402]：セグメントルーティング（SR）、SRドメイン、セグメントID（SID）、SRV6、SRV6 SID、SRポリシー、プレフィックスSID、およびADJ-SIDで定義されています。
The following terms used within this document are defined in [RFC8754]: Segment Routing Header (SRH), SR source node, transit node, SR Segment Endpoint Node, Reduced SRH, Segments Left, and Last Entry.
この文書内で使用されている以下の用語は、[RFC8754]：Segment Routing Header（SRH）、SRソースノード、トランジットノード、SRセグメントエンドポイントノード、SRH、SEGMENTS LEFT、および最後のエントリで定義されています。
The following terms are used in this document as defined below:
以下に定義されているように、次の用語がこの文書で使用されています。
FIB: Forwarding Information Base. A FIB lookup is a lookup in the forwarding table.
FIB：転送情報ベースFIBルックアップは転送テーブルのルックアップです。
SA: Source Address
SA：送信元アドレス
DA: Destination Address
DA：宛先アドレス
L3: Layer 3
L3：レイヤ3
L2: Layer 2
L2：レイヤ2
MAC: Media Access Control
Mac：メディアアクセス制御
EVPN: Ethernet VPN
EVPN：イーサネットVPN
ESI: Ethernet Segment Identifier
ESI：イーサネットセグメントID
Per-CE VPN label: A single label for each attachment circuit that is shared by all routes with the same "outgoing attachment circuit" (Section 4.3.2 of [RFC4364])
CEごとのVPNラベル：すべてのルートで同じ「発信接続回路」を持つすべてのルートで共有されている単一ラベル（[RFC4364]のセクション4.3.2）
Per-VRF VPN label: A single label for the entire VPN Routing and Forwarding (VRF) table that is shared by all routes from that VRF (Section 4.3.2 of [RFC4364])
VRFごとのVPNラベル：そのVRFからのすべてのルートで共有されているVPNルーティングおよび転送（VRF）テーブルの単一ラベル（[RFC4364]のセクション4.3.2）
SL: The Segments Left field of the SRH
SL：SRHのセグメントの左側のフィールド
SRv6 SID function: The function part of the SID is an opaque identification of a local behavior bound to the SID. It is formally defined in Section 3.1 of this document.
SRV6 SID機能：SIDの機能部分は、SIDにバインドされたローカル動作の不透明な識別です。この文書のセクション3.1で正式に定義されています。
SRv6 Endpoint behavior: A packet processing behavior executed at an SRv6 Segment Endpoint Node. Section 4 of this document defines SRv6 Endpoint behaviors related to traffic-engineering and overlay use cases. Other behaviors (e.g., service programming) are outside the scope of this document.
SRV6エンドポイントの動作SRV6セグメントエンドポイントノードで実行されるパケット処理動作。このドキュメントの4章では、トラフィックエンジニアリングおよびオーバーレイユースケースに関連するSRV6エンドポイントビヘイビアを定義します。他の行動（例えば、サービスプログラミング）はこの文書の範囲外です。
An SR Policy is resolved to a SID list. A SID list is represented as <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit along the SR path.
SRポリシーはSIDリストに解決されます。S1は<S1、S2、S3>で表され、S1は訪問する最初のSID、S2は2番目のSIDであり、S3はSRパスに沿って訪れる最後のSIDです。
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
（SA、DA）（S3、S2、S1; SL）は、以下のIPv6パケットを表す。
* Source Address (SA), Destination Address (DA), and next header (SRH).
* 送信元アドレス（SA）、宛先アドレス（DA）、および次のヘッダー（SRH）。
* SRH with SID list <S1, S2, S3> with Segments Left = SL.
* SID LIST <S1、S2、S3>セグメントを持つSRH。
Note the difference between the <> and () symbols: <S1, S2, S3> represents a SID list where S1 is the first SID and S3 is the last SID to traverse. (S3, S2, S1; SL) represents the same SID list but encoded in the SRH format where the rightmost SID in the SRH is the first SID and the leftmost SID in the SRH is the last SID. When referring to an SR Policy in a high-level use case, it is simpler to use the <S1, S2, S3> notation. When referring to an illustration of the detailed packet behavior, the (S3, S2, S1; SL) notation is more convenient.
<>記号と（）シンボルの違いは、<S1、S2、S3>がS1が最初のSIDであり、S3がトラバースする最後のSIDであるSIDリストを表します。（S3、S2、S1; SL）は同じSIDリストを表しているが、SRH内の右端SIDが最初のSIDであり、SRHの最後のSIDが最後のSIDであるSRHフォーマットで符号化されている。高レベルのユースケースでSRポリシーを参照する場合は、<S1、S2、S3>表記を使用するのが簡単です。詳細なパケット動作の説明を参照すると、（S3、S2、S1; SL）表記がより便利である。
* The payload of the packet is omitted.
* パケットのペイロードは省略されています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
[RFC8402] defines an SRv6 Segment Identifier as an IPv6 address explicitly associated with the segment.
[RFC8402] SRV6セグメントIDを、そのセグメントに明示的に関連付けられているIPv6アドレスとして定義します。
When an SRv6 SID is in the Destination Address field of an IPv6 header of a packet, it is routed through transit nodes in an IPv6 network as an IPv6 address.
SRV6 SIDがパケットのIPv6ヘッダーの宛先アドレスフィールドにある場合は、IPv6ネットワーク内のトランジットノードを介してIPv6アドレスとしてルーティングされます。
Its processing is defined in Section 4.3 of [RFC8754] and reproduced here as a reminder:
その処理は[RFC8754]のセクション4.3で定義され、ここではリマインダーとして再現されています。
| Without constraining the details of an implementation, the SR
| segment endpoint node creates Forwarding Information Base (FIB)
| entries for its local SIDs.
|
| When an SRv6-capable node receives an IPv6 packet, it performs a
| longest-prefix-match lookup on the packet's destination address.
| This lookup can return any of the following:
| * A FIB entry that represents a locally instantiated SRv6 SID
|
| * A FIB entry that represents a local interface, not locally
| instantiated as an SRv6 SID
|
| * A FIB entry that represents a nonlocal route
|
| * No Match
Section 4 of this document defines a new set of SRv6 SID behaviors in addition to that defined in Section 4.3.1 of [RFC8754].
このドキュメントの4章では、[RFC8754]のセクション4.3.1で定義されているものに加えて、新しいSRV6 SID動作セットを定義します。
This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). L, the locator length, is flexible, and an operator is free to use the locator length of their choice. F and A may be any value as long as L+F+A <= 128. When L+F+A is less than 128, then the remaining bits of the SID MUST be zero.
この文書は、loc：funct：argからなるSRV6 SIDを定義します。ここで、ロケータ（loc）はSIDの最上位ビット、その後にFビット（FUNCT）と引数のビット（arg）が続きます。。L、ロケータ長は柔軟であり、オペレータは選択のロケータ長を自由に使用することができます。fおよびaは、l f a≦128である限り任意の値であり得る.1 f aが128未満のとき、前記SIDの残りのビットはゼロでなければならない。
A locator may be represented as B:N where B is the SRv6 SID block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID.
ロケータは、b：nとして表されてもよい。ここで、bはSRV6 SIDブロック（演算子によるSRV6 SIDに割り当てられたIPv6プレフィックス）、nはSIDをインスタンス化する親ノードの識別子です。
When the LOC part of the SRv6 SIDs is routable, it leads to the node, which instantiates the SID.
SRV6 SIDSのLOC部分がルーティング可能な場合は、SIDをインスタンス化するノードにつながります。
The FUNCT is an opaque identification of a local behavior bound to the SID.
FUNCTは、SIDにバインドされているローカル行動の不透明な識別です。
The term "function" refers to the bit string in the SRv6 SID. The term "behavior" identifies the behavior bound to the SID. Some behaviors are defined in Section 4 of this document.
「関数」という用語は、SRV6 SIDのビット文字列を指します。「動作」という用語は、SIDにバインドされている動作を識別します。このドキュメントのセクション4にはいくつかの動作が定義されています。
An SRv6 Endpoint behavior may require additional information for its processing (e.g., related to the flow or service). This information may be encoded in the ARG bits of the SID.
SRV6エンドポイントの動作は、その処理のための追加情報（例えば、フローまたはサービスに関連する）を必要とし得る。この情報は、SIDのARGビットに符号化されてもよい。
In such a case, the semantics and format of the ARG bits are defined as part of the SRv6 Endpoint behavior specification.
そのような場合、ARGビットのセマンティクスとフォーマットは、SRV6エンドポイント動作仕様の一部として定義されています。
The ARG value of a routed SID SHOULD remain constant among packets in a given flow. Varying ARG values among packets in a flow may result in different ECMP hashing and cause reordering.
ルーテッドSIDのarg値は、特定のフロー内のパケット間で一定のままです。フロー内のパケット間でarg値を変えると、異なるECMPハッシュと並べ替えが発生する可能性があります。
Locators are assigned consistent with IPv6 infrastructure allocation. For example, a network operator may:
ロケータは、IPv6インフラストラクチャ割り当てと一致して割り当てられています。たとえば、ネットワークオペレータは次のようになります。
* Assign block B::/48 to the SR domain
* SRドメインにブロックB :: / 48を割り当てる
* Assign a unique B:N::/64 block to each SRv6-enabled node in the domain
* ドメイン内の各SRV6対応ノードに固有のB :: / 64ブロックを割り当てます。
As an example, one mobile service provider has commercially deployed SRv6 across more than 1000 commercial routers and 1800 whitebox routers. All these devices are enabled for SRv6 and advertise SRv6 SIDs. The provider historically deployed IPv6 and assigned infrastructure addresses from the Unique Local Address (ULA) space [RFC4193]. They specifically allocated three /48 prefixes (Country X, Country Y, Country Z) to support their SRv6 infrastructure. From those /48 prefixes, each router was assigned a /64 prefix from which all SIDs of that router are allocated.
一例として、1つのモバイルサービスプロバイダは、1000以上の商業ルータおよび1800のホワイトボックスルータにわたって市販されているSRV6を展開している。これらすべてのデバイスはSRV6に対して有効になり、SRV6 SIDSをアドバタイズします。プロバイダは歴史的にIPv6と固有のローカルアドレス（ULA）スペース[RFC4193]からインフラストラクチャアドレスを割り当てました。彼らは、それらのSRV6インフラストラクチャをサポートするために、3/48のプレフィックス（国X、国Y、国Z）を特に割り当てた。これら/ 48プレフィックスから、各ルータには、そのルータのすべてのSIDが割り当てられている/ 64プレフィックスが割り当てられました。
In another example, a large mobile and fixed-line service provider has commercially deployed SRv6 in their country-wide network. This provider is assigned a /20 prefix by a Regional Internet Registry (RIR). They sub-allocated a few /48 prefixes to their infrastructure to deploy SRv6. Each router is assigned a /64 prefix from which all SIDs of that router are allocated.
別の例では、大型のモバイルおよび固定ラインサービスプロバイダは、その国全体のネットワークにおいてSRV6を市販されている。このプロバイダには、地域インターネットレジストリ（RIR）によって/ 20プレフィックスが割り当てられています。それらは、SRV6を展開するために、インフラストラクチャに数/ 48の接頭辞を割り当てた。各ルータには、そのルータのすべてのSIDが割り当てられる/ 64プレフィックスが割り当てられています。
IPv6 address consumption in both these examples is minimal, representing less than one billionth and one millionth of the available address space, respectively.
IPv6アドレス消費量の両方の例では、それぞれ10億、百万分の百億以上の利用可能なアドレス空間を表します。
A service provider receiving the current minimum allocation of a /32 prefix from an RIR may assign a /48 prefix to their infrastructure deploying SRv6 and subsequently allocate /64 prefixes for SIDs at each SRv6 node. The /48 assignment is one sixty-five thousandth (1/2^16) of the usable IPv6 address space available for assignment by the provider.
RIRからの/ 32プレフィックスの現在の最小割り当てを受信するサービスプロバイダは、SRV6を展開するインフラストラクチャにA / 48プレフィックスを割り当て、それ以降のSRV6ノードでSIDの割り当て/ 64プレフィックスを割り当てることができます。/ 48の割り当ては、プロバイダによる割り当てに利用可能な使用可能なIPv6アドレス空間の165000（1/2 ^ 16）です。
When an operator instantiates a SID at a node, they specify a SID value B:N:FUNCT and the behavior bound to the SID using one of the SRv6 Endpoint Behavior codepoints of the registry defined in this document (see Table 6).
オペレータがノードでSIDをインスタンス化すると、このドキュメントで定義されているレジストリのSRV6エンドポイント動作コードポイントのいずれかを使用して、SID値B：N：FUNCTおよびSIDにバインドされているSID値B：N：FUNCTおよびSIDにバインドされている動作を指定します（表6参照）。
The node advertises the SID, B:N:FUNCT, in the control plane (see Section 8) together with the SRv6 Endpoint Behavior codepoint identifying the behavior of the SID.
ノードは、SRV6エンドポイントの動作コードポイントを識別するSRV6エンドポイント動作コードポイントとともに、SID、B：N：FUNCTを制御プレーン（セクション8参照）にアドバタイズします。
An SR source node cannot infer the behavior by examination of the FUNCT value of a SID.
SRソースノードは、SIDのFUNCT値を検討することによって行動を推測することはできません。
Therefore, the SRv6 Endpoint Behavior codepoint is advertised along with the SID in the control plane.
したがって、SRV6エンドポイント動作コードポイントは、制御プレーン内のSIDと共にアドバタイズされます。
An SR source node uses the SRv6 Endpoint Behavior codepoint to map the received SID (B:N:FUNCT) to a behavior.
SRソースノードは、SRV6エンドポイント動作コードポイントを使用して、受信したSID（B：N：FUNCT）を動作にマッピングします。
An SR source node selects a desired behavior at an advertising node by selecting the SID (B:N:FUNCT) advertised with the desired behavior.
SRソースノードは、所望の動作でアドバタイズされたSID（B：N：Funct）を選択することによって、広告ノードで所望の動作を選択する。
As an example:
例として：
* A network operator may assign an SRv6 SID block 2001:db8:bbbb::/48 from their in-house operation block for their SRv6 infrastructure.
* ネットワークオペレータは、SRV6インフラストラクチャのために、社内操作ブロックからSRV6 SIDブロック2001：DB8：BBBB :: / 48を割り当てることができる。
* A network operator may assign an SRv6 Locator 2001:db8:bbbb:3::/64 to one particular router, for example Router 3, in their SR Domain.
* ネットワークオペレータは、SRドメイン内で、SRV6ロケータ2001：DB8：BBBB：3 :: / 64に、1つの特定のルータ、例えばルータ3に割り当てることができる。
* At Router 3, within the locator 2001:db8:bbbb:3::/64, the network operator or the router performs dynamic assignment for:
* ルータ3で、Locator 2001内で：DB8：BBBB：3 :: / 64、ネットワーク演算子またはルータは次のために動的割り当てを実行します。
- Function 0x0100 associated with the behavior End.X (Endpoint with L3 cross-connect) between router 3 and its connected neighbor router (e.g., Router 4). This function is encoded as a 16-bit value and has no arguments (F=16, A=0).
- ルータ3とその接続された隣接ルータ（例えば、ルータ4）の間の動作end.x（L3クロスコネクトを含むエンドポイント）に関連付けられている機能0x0100。この関数は16ビット値として符号化され、引数がない（f = 16、a = 0）。
This SID is advertised in the control plane as 2001:db8:bbbb:3:100:: with an SRv6 Endpoint Behavior codepoint value of 5.
このSIDは、2001としてコントロールプレーンでアドバタイズされています.DB8：BBBB：3：100 :: SRV6エンドポイントの動作コードポイント値5。
- Function 0x0101 associated with the behavior End.X (Endpoint with L3 cross-connect) between router 3 and its connected neighbor router (e.g., Router 2). This function is encoded as a 16-bit value and has no arguments (F=16, A=0).
- ルータ3とその接続されている隣接ルータ（例えば、ルータ2）の間の動作end.x（L3クロスコネクトを含むエンドポイント）に関連付けられている機能0x0101。この関数は16ビット値として符号化され、引数がない（f = 16、a = 0）。
This SID is advertised in the control plane as 2001:db8:bbbb:3:101:: with an SRv6 Endpoint Behavior codepoint value of 5.
このSIDはコントロールプレーンで2001としてアドバタイズされています.DB8：BBBB：3：101 :: SRV6エンドポイントの動作コードポイント値5。
These examples do not preclude any other IPv6 addressing allocation scheme.
これらの例では、他のIPv6アドレッシング割り当て方式を排除しないでください。
Most often, the node N would advertise IPv6 prefix(es) matching the LOC parts covering its SIDs or shorter-mask prefix. The distribution of these advertisements and calculation of their reachability are specific to the routing protocol and are outside of the scope of this document.
ほとんどの場合、ノードNは、そのSIDSまたは短いマスクプレフィックスをカバーするLOCパーツと一致するIPv6プレフィックスをアドバタイズします。これらの広告の分布とそれらの到達可能性の計算は、ルーティングプロトコルに固有のものであり、この文書の範囲外です。
An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix advertised via a routing protocol. An SRv6 SID that does not fulfill this condition is non-routed.
SRV6 SIDは、そのSIDがルーティングプロトコルを介してアドバタイズされたIPv6プレフィックスに属する場合、ルーティングされると言われています。この状態を満たさないSRV6 SIDは、ルーティングされません。
Let's provide a classic illustration:
古典的なイラストを提供しましょう。
Node N is configured explicitly with two SIDs: 2001:db8:b:1:100:: and 2001:db8:b:2:101::.
ノードNは、2つのSIDS：2001：DB8：B：1：100 ::および2001：DB8：B ::：。
The network learns about a path to 2001:db8:b:1::/64 via the IGP; hence, a packet destined to 2001:db8:b:1:100:: would be routed up to N. The network does not learn about a path to 2001:db8:b:2::/64 via the IGP; hence, a packet destined to 2001:db8:b:2:101:: would not be routed up to N.
ネットワークは、IGPを介して2001へのパスについて学習します.DB8：B :: / 64。したがって、2001：DB8：B：1：100 ::がNまでにルーティングされるパケットはNにルーティングされます。ネットワークは2001へのパスについては、IGPを介してDB8：B :: / 64の経路については説明しません。したがって、2001年に宛てられたパケット：DB8：B：2：101 ::はNにルーティングされません。
A packet could be steered through a non-routed SID 2001:db8:b:2:101:: by using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...> where the non-routed SID is preceded by a routed SID to the same node. A packet could also be steered to a node instantiating a non-routed SID by preceding it in the SID list with an Adj-SID to that node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of global and local segments, respectively [RFC8402].
パケットは、ルーティングされていないSID 2001を介して操縦することができます.DB8：B ::：101 :: SIDリスト<... ,:：DB8：B：1：100 ::,2001：DB8：B：2：101 ::、...>非ルーティングされていないSIDの前に、ルーティングされたSIDが同じノードに配置されます。パケットは、そのノードへのADJ-SIDを含むSIDリスト内のそれに先行することによって、ルーティングされていないSIDをインスタンス化するノードに操作することもできます。ルーティングされていないSRV6 SIDは、それぞれグローバルセグメントとローカルセグメントのSRV6インスタンス化です[RFC8402]。
The following is a set of well-known behaviors that can be associated with a SID.
以下は、SIDに関連付けることができる周知の動作のセットです。
+-------------------+---------------------------------------------+
| End | Endpoint |
| | |
| | The SRv6 instantiation of a Prefix-SID |
| | [RFC8402] |
+-------------------+---------------------------------------------+
| End.X | Endpoint with L3 cross-connect |
| | |
| | The SRv6 instantiation of an Adj-SID |
| | [RFC8402] |
+-------------------+---------------------------------------------+
| End.T | Endpoint with specific IPv6 table lookup |
+-------------------+---------------------------------------------+
| End.DX6 | Endpoint with decapsulation and IPv6 cross- |
| | connect |
| | |
| | e.g., IPv6-L3VPN (equivalent to per-CE VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DX4 | Endpoint with decapsulation and IPv4 cross- |
| | connect |
| | |
| | e.g., IPv4-L3VPN (equivalent to per-CE VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DT6 | Endpoint with decapsulation and specific |
| | IPv6 table lookup |
| | |
| | e.g., IPv6-L3VPN (equivalent to per-VRF VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DT4 | Endpoint with decapsulation and specific |
| | IPv4 table lookup |
| | |
| | e.g., IPv4-L3VPN (equivalent to per-VRF VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DT46 | Endpoint with decapsulation and specific IP |
| | table lookup |
| | |
| | e.g., IP-L3VPN (equivalent to per-VRF VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DX2 | Endpoint with decapsulation and L2 cross- |
| | connect |
| | |
| | e.g., L2VPN use case |
+-------------------+---------------------------------------------+
| End.DX2V | Endpoint with decapsulation and VLAN L2 |
| | table lookup |
| | |
| | e.g., EVPN Flexible Cross-connect use case |
+-------------------+---------------------------------------------+
| End.DT2U | Endpoint with decapsulation and unicast MAC |
| | L2 table lookup |
| | |
| | e.g., EVPN Bridging Unicast use case |
+-------------------+---------------------------------------------+
| End.DT2M | Endpoint with decapsulation and L2 table |
| | flooding |
| | |
| | e.g., EVPN Bridging Broadcast, Unknown |
| | Unicast, and Multicast (BUM) use case with |
| | Ethernet Segment Identifier (ESI) filtering |
+-------------------+---------------------------------------------+
| End.B6.Encaps | Endpoint bound to an SRv6 Policy with |
| | encapsulation |
| | |
| | SRv6 instantiation of a Binding SID |
+-------------------+---------------------------------------------+
| End.B6.Encaps.Red | End.B6.Encaps with reduced SRH |
| | |
| | SRv6 instantiation of a Binding SID |
+-------------------+---------------------------------------------+
| End.BM | Endpoint bound to an SR-MPLS Policy |
| | |
| | SRv6 instantiation of an SR-MPLS Binding |
| | SID |
+-------------------+---------------------------------------------+
Table 1: Endpoint Behaviors
表1：エンドポイントビヘイビアー
The list is not exhaustive. In practice, any behavior can be attached to a local SID; for example, a node N can bind a SID to a local Virtual Machine (VM) or container that can apply any complex processing on the packet, provided there is an SRv6 Endpoint Behavior codepoint allocated for the processing.
リストは網羅的なものではありません。実際には、任意の動作をローカルSIDに接続することができます。例えば、ノードNは、処理のために割り当てられたSRV6エンドポイント動作コードポイントが提供されるように、パケット上で複雑な処理を適用することができるローカル仮想マシン（VM）またはコンテナにSIDをバインドすることができる。
When an SRv6-capable node (N) receives an IPv6 packet whose destination address matches a FIB entry that represents a locally instantiated SRv6 SID (S), the IPv6 header chain is processed as defined in Section 4 of [RFC8200]. For SRv6 SIDs associated with an Endpoint behavior defined in this document, the SRH and Upper-Layer header are processed as defined in the following subsections.
SRV6対応ノード（N）が、宛先アドレスがローカルにインスタンス化されたSRV6 SIDを表すFIBエントリと一致するIPv6パケットを受信すると、[RFC8200]のセクション4で定義されているようにIPv6ヘッダーチェーンが処理されます。このドキュメントで定義されているエンドポイントの動作に関連するSRV6 SIDの場合、SRHと上位レイヤのヘッダーは、次のサブセクションで定義されているとおりに処理されます。
The pseudocode describing these behaviors details local processing at a node. An implementation of the pseudocode is compliant as long as the externally observable wire protocol is as described by the pseudocode.
これらの動作を記述する擬似コードは、ノードでのローカル処理を詳細に説明します。疑似コードの実装は、外部観測可能なワイヤプロトコルが擬似コードによって記述されている限り準拠している。
Section 4.16 defines flavors of some of these behaviors.
セクション4.16はこれらの動作のいくつかのフレーバーを定義します。
Section 10.2 of this document defines the IANA registry used to maintain all these behaviors as well as future ones defined in other documents.
この文書のセクション10.2は、これらすべての動作を維持するために使用されるIANAレジストリと、他の文書で定義されている将来のものを定義しています。
The Endpoint behavior ("End" for short) is the most basic behavior. It is the instantiation of a Prefix-SID [RFC8402].
エンドポイントの動作（短縮のための "end"）は最も基本的な動作です。プレフィックスSID [RFC8402]のインスタンス化です。
When N receives a packet whose IPv6 DA is S and S is a local End SID, N does the following:
n ipv6 daがsおよびsがローカルエンドSIDのパケットを受信すると、nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S11. }
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S16. }
| Note:
|
| The End behavior operates on the same FIB table (i.e.,
| identified by VRF or L3 relay ID) associated to the packet.
| Hence, the FIB lookup on line S15 is done in the same FIB table
| as the ingress interface.
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End SID, N does the following:
End SIDとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上位層ヘッダを処理する場合、nは次のことを行います。
S01. If (Upper-Layer header type is allowed by local configuration) {
S02. Proceed to process the Upper-Layer header
S03. } Else {
S04. Send an ICMP Parameter Problem to the Source Address
with Code 4 (SR Upper-layer Header Error)
and Pointer set to the offset of the Upper-Layer header,
interrupt packet processing, and discard the packet.
S05 }
Allowing the processing of specific Upper-Layer header types is useful for Operations, Administration, and Maintenance (OAM). As an example, an operator might permit pinging of SIDs. To do this, they may enable local configuration to allow Upper-Layer header type 58 (ICMPv6).
特定の上位層のヘッダータイプの処理を許可することは、操作、管理、および保守（OAM）に役立ちます。一例として、オペレータはSIDのPingを許可するかもしれない。これを行うために、ローカル構成を有効にして上位層のヘッダータイプ58（ICMPv6）を許可することがあります。
It is RECOMMENDED that an implementation of local configuration only allows Upper-Layer header processing of types that do not result in the packet being forwarded (e.g., ICMPv6).
ローカル構成の実装は、転送されているパケットが転送されないタイプの上位レイヤーヘッダ処理（例えば、ICMPv6）のみを可能にすることをお勧めします。
The "Endpoint with L3 cross-connect" behavior ("End.X" for short) is a variant of the End behavior.
「L3クロスコネクト付きエンドポイント」動作（短縮のための "end.x"）は終了動作の変形です。
It is the SRv6 instantiation of an Adj-SID [RFC8402], and its main use is for traffic-engineering policies.
ADJ-SID [RFC8402]のSRV6インスタンス化であり、その主な用途はトラフィックエンジニアリングポリシー用です。
Any SID instance of this behavior is associated with a set, J, of one or more L3 adjacencies.
この動作のSIDインスタンスは、1つ以上のL3隣接関係のセットjに関連付けられています。
When N receives a packet destined to S and S is a local End.X SID, the line S15 from the End processing is replaced by the following:
SおよびS宛のパケットをNに受信すると、SIDがローカルend.x SIDである場合、終了処理からの行S15は以下に置き換えられる。
S15. Submit the packet to the IPv6 module for transmission to the new destination via a member of J
S15。jのメンバーを介して新しい宛先への送信のために、ipv6モジュールにパケットを送信する
| Note:
|
| S15. If the set J contains several L3 adjacencies, then one
| element of the set is selected based on a hash of the packet's
| header (see Section 7).
If a node N has 30 outgoing interfaces to 30 neighbors, usually the operator would explicitly instantiate 30 End.X SIDs at N: one per L3 adjacency to a neighbor. Potentially, more End.X could be explicitly defined (groups of L3 adjacencies to the same neighbor or to different neighbors).
ノードNが30個の隣接に30個の発信インターフェースを持つ場合、通常、オペレータはN：L3隣接ごとにN個のend.x SIDを明示的にインスタンス化します。潜在的に、より多くのEnd.xは明示的に定義され得る（同じ隣接または異なる隣人へのL3隣接のグループ）。
Note that if N has an outgoing interface bundle I to a neighbor Q made of 10 member links, N might allocate up to 11 End.X local SIDs: one for the bundle itself and then up to one for each L2 member link. The flows steered using the End.X SID corresponding to the bundle itself get load-balanced across the member links via hashing while the flows steered using the End.X SID corresponding to a member link get steered over that specific member link alone.
Nが10のメンバーリンクで作られた隣接QにN個のInterface Bundle Iを持っている場合、Nは最大11のEnd.xローカルSIDを割り当てることがあります.1つはバンドル自体に1つ、次にL2メンバーリンクごとに1つまでです。バンドル自体に対応するend.x SIDを使用して操縦されたフローは、メンバーリンクに対応するend.x SIDを使用して操縦されたフローがハッシュを介してメンバーリンクを介して負荷分散されます。
When the End.X behavior is associated with a BGP Next-Hop, it is the SRv6 instantiation of the BGP peering segments [RFC8402].
end.xの動作がBGPネクストホップに関連付けられている場合、それはBGPピアリングセグメント[RFC8402]のSRV6インスタンス化です。
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.X SID, process the packet as per Section 4.1.1.
end.x SIDとしてローカルにインスタンス化されたFIBエントリと一致するパケットの上位ヘッダを処理する場合は、セクション4.1.1に従ってパケットを処理してください。
The "Endpoint with specific IPv6 table lookup" behavior ("End.T" for short) is a variant of the End behavior.
「特定のIPv6テーブルルックアップを含むエンドポイント」の動作（短縮のための "end.t"）は、終了動作の変形です。
The End.T behavior is used for multi-table operation in the core. For this reason, an instance of the End.T behavior is associated with an IPv6 FIB table T.
end.tの動作は、コア内のマルチテーブル操作に使用されます。このため、end.tの動作のインスタンスはIPv6 FIBテーブルTに関連付けられています。
When N receives a packet destined to S and S is a local End.T SID, the line S15 from the End processing is replaced by the following:
NがSおよびS宛のパケットを受信すると、ローカルend.t SIDである場合、終了処理からの行S15は以下に置き換えられる。
S15.1. Set the packet's associated FIB table to T S15.2. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination
S15.1。パケットの関連のFIBテーブルをT S15.2に設定します。新しい宛先への送信のための出力IPv6 FIB検索にパケットを送信する
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.T SID, process the packet as per Section 4.1.1.
end.t sidとして局所的にインスタンス化されたFIBエントリと一致するパケットの上位ヘッダを処理するときは、セクション4.1.1に従ってパケットを処理する。
The "Endpoint with decapsulation and IPv6 cross-connect" behavior ("End.DX6" for short) is a variant of the End.X behavior.
「デカプセル化とIPv6クロスコネクトのエンドポイント」（「短縮」の「end.dx6」）は、end.xの動作の変形です。
One of the applications of the End.DX6 behavior is the L3VPNv6 use case where a FIB lookup in a specific tenant table at the egress Provider Edge (PE) is not required. This is equivalent to the per-CE VPN label in MPLS [RFC4364].
end.dx6動作のアプリケーションの1つは、出力プロバイダーエッジ（PE）の特定のテナントテーブル内のFIBルックアップが必要ないL3VPNV6ユースケースです。これはMPLS [RFC4364]のCEごとのVPNラベルに相当します。
The End.DX6 SID MUST be the last segment in an SR Policy, and it is associated with one or more L3 IPv6 adjacencies J.
end.dx6 SIDはSRポリシーの最後のセグメントでなければならず、1つ以上のL3 IPv6隣接関係Jに関連付けられています。
When N receives a packet destined to S and S is a local End.DX6 SID, N does the following:
nがSおよびS宛のパケットを受信すると、Local End.dx6 SID、Nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX6 SID, N does the following:
end.dx6 SIDとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上位レイヤーヘッダーを処理する場合、nは次のようにします。
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the exposed IPv6 packet to the L3 adjacency J
S04. } Else {
S05. Process as per Section 4.1.1
S06. }
| Note:
|
| S01. "41" refers to "IPv6 encapsulation" as defined in the IANA
| "Assigned Internet Protocol Numbers" registry.
|
| S03. If the End.DX6 SID is bound to an array of L3
| adjacencies, then one entry of the array is selected based on
| the hash of the packet's header (see Section 7).
The "Endpoint with decapsulation and IPv4 cross-connect" behavior ("End.DX4" for short) is a variant of the End.X behavior.
「デカプセル化とIPv4クロスコネクトのエンドポイント」（短縮のための "end.dx4"）は、end.xの動作の変数です。
One of the applications of the End.DX4 behavior is the L3VPNv4 use case where a FIB lookup in a specific tenant table at the egress PE is not required. This is equivalent to the per-CE VPN label in MPLS [RFC4364].
end.dx4の動作のアプリケーションの1つは、出力PEの特定のテナントテーブル内のFIBルックアップが必要ないL3VPNV4ユースケースです。これはMPLS [RFC4364]のCEごとのVPNラベルに相当します。
The End.DX4 SID MUST be the last segment in an SR Policy, and it is associated with one or more L3 IPv4 adjacencies J.
end.dx4 SIDはSRポリシーの最後のセグメントでなければならず、1つ以上のL3 IPv4隣接関係J.に関連付けられています。
When N receives a packet destined to S and S is a local End.DX4 SID, N does the following:
nがsおよびs宛のパケットを受信すると、local end.dx4 sidが次のようになります。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX4 SID, N does the following:
end.dx4 SIDとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上位レイヤーヘッダーを処理する場合、nは次のことを行います。
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the exposed IPv4 packet to the L3 adjacency J
S04. } Else {
S05. Process as per Section 4.1.1
S06. }
| Note:
|
| S01. "4" refers to "IPv4 encapsulation" as defined in the IANA
| "Assigned Internet Protocol Numbers" registry.
|
| S03. If the End.DX4 SID is bound to an array of L3
| adjacencies, then one entry of the array is selected based on
| the hash of the packet's header (see Section 7).
The "Endpoint with decapsulation and specific IPv6 table lookup" behavior ("End.DT6" for short) is a variant of the End.T behavior.
「デカプセル化と特定のIPv6テーブルルックアップ」の動作（短縮のための "end.dt6"）は、end.tの動作の変形です。
One of the applications of the End.DT6 behavior is the L3VPNv6 use case where a FIB lookup in a specific tenant table at the egress PE is required. This is equivalent to the per-VRF VPN label in MPLS [RFC4364].
END.DT6の動作のアプリケーションの1つは、出力PEの特定のテナントテーブル内のFIBルックアップが必要なL3VPNV6ユースケースです。これは、MPLS [RFC4364]のVRFごとのVPNラベルに相当します。
Note that an End.DT6 may be defined for the main IPv6 table, in which case an End.DT6 supports the equivalent of an IPv6-in-IPv6 decapsulation (without VPN/tenant implication).
END.DT6は、メインIPv6テーブルに対して定義されている可能性があります。その場合、end.dt6はIPv6-in-IPv6カプセル化（VPN /テナント含意なし）の等価をサポートします。
The End.DT6 SID MUST be the last segment in an SR Policy, and a SID instance is associated with an IPv6 FIB table T.
END.DT6 SIDはSRポリシーの最後のセグメントでなければならず、SIDインスタンスはIPv6 FIBテーブルTに関連付けられています。
When N receives a packet destined to S and S is a local End.DT6 SID, N does the following:
nがSおよびS宛のパケットを受信すると、Local End.dt6 SID、nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT6 SID, N does the following:
end.dt6 sidとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上位レイヤーヘッダーを処理する場合、nは次のようにします。
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S05. } Else {
S06. Process as per Section 4.1.1
S07. }
The "Endpoint with decapsulation and specific IPv4 table lookup" behavior ("End.DT4" for short) is a variant of the End.T behavior.
「デカプセル化と特定のIPv4テーブルルックアップ」の動作（短縮のための "end.dt4"）はend.tの動作の変形です。
One of the applications of the End.DT4 behavior is the L3VPNv4 use case where a FIB lookup in a specific tenant table at the egress PE is required. This is equivalent to the per-VRF VPN label in MPLS [RFC4364].
end.dt4の動作のアプリケーションの1つは、出力PEの特定のテナントテーブル内のFIBルックアップが必要なL3VPNV4ユースケースです。これは、MPLS [RFC4364]のVRFごとのVPNラベルに相当します。
Note that an End.DT4 may be defined for the main IPv4 table, in which case an End.DT4 supports the equivalent of an IPv4-in-IPv6 decapsulation (without VPN/tenant implication).
END.DT4はメインIPv4テーブルに対して定義されていてもよいため、end.dt4はIPv4-in-IPv6カプセル化（VPN /テナント含意なし）の等価をサポートします。
The End.DT4 SID MUST be the last segment in an SR Policy, and a SID instance is associated with an IPv4 FIB table T.
END.DT4 SIDはSRポリシーの最後のセグメントでなければならず、SIDインスタンスはIPv4 FIBテーブルTに関連付けられています。
When N receives a packet destined to S and S is a local End.DT4 SID, N does the following:
nがsおよびs宛のパケットを受信すると、local end.dt4 sid、nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT4 SID, N does the following:
end.dt4 sidとしてローカルにインスタンス化されたFIBエントリと一致するパケットの上位レイヤーヘッダーを処理する場合、nは次のことを行います。
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S05. } Else {
S06. Process as per Section 4.1.1
S07. }
The "Endpoint with decapsulation and specific IP table lookup" behavior ("End.DT46" for short) is a variant of the End.DT4 and End.DT6 behavior.
「デカプセル化のエンドポイントと特定のIPテーブルルックアップ」の動作（短縮の「end.dt46」）は、end.dt4とend.dt6の動作の変形です。
One of the applications of the End.DT46 behavior is the L3VPN use case where a FIB lookup in a specific IP tenant table at the egress PE is required. This is equivalent to the single per-VRF VPN label (for IPv4 and IPv6) in MPLS [RFC4364].
END.DT46の動作のアプリケーションの1つは、出力PEの特定のIPテナントテーブル内のFIBルックアップが必要なL3VPNユースケースです。これは、MPLS [RFC4364]の単一VRFごとのVPNラベル（IPv4およびIPv6の場合）に相当します。
Note that an End.DT46 may be defined for the main IP table, in which case an End.DT46 supports the equivalent of an IP-in-IPv6 decapsulation (without VPN/tenant implication).
END.DT46はメインIPテーブルに対して定義されてもよいことに注意して、その場合、end.dt46はIP-IN-IPv6デカプセル化（VPN /テナント含意なし）の等価をサポートしています。
The End.DT46 SID MUST be the last segment in an SR Policy, and a SID instance is associated with an IPv4 FIB table T4 and an IPv6 FIB table T6.
END.DT46 SIDはSRポリシーの最後のセグメントでなければならず、SIDインスタンスはIPv4 FIBテーブルT4とIPv6 FIBテーブルT6に関連付けられています。
When N receives a packet destined to S and S is a local End.DT46 SID, N does the following:
nがsおよびs宛のパケットを受信すると、local end.dt46 sid、nは次のようになります。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT46 SID, N does the following:
end.dt46 sidとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上位レイヤーヘッダーを処理する場合、nは次のことを行います。
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T4
S04. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S05. } Else if (Upper-Layer header type == 41(IPv6) ) {
S06. Remove the outer IPv6 header with all its extension headers
S07. Set the packet's associated FIB table to T6
S08. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S09. } Else {
S10. Process as per Section 4.1.1
S11. }
The "Endpoint with decapsulation and L2 cross-connect" behavior ("End.DX2" for short) is a variant of the Endpoint behavior.
「デカプセル化およびL2クロスコネクトのエンドポイント」（短縮のための "end.dx2"）は、エンドポイント動作の変形です。
One of the applications of the End.DX2 behavior is the L2VPN [RFC4664] / EVPN Virtual Private Wire Service (VPWS) [RFC7432] [RFC8214] use case.
end.dx2の動作のアプリケーションの1つは、L2VPN [RFC4664] / EVPN仮想プライベート・サービス（VPWS）[RFC7432] [RFC8214]ユースケースです。
The End.DX2 SID MUST be the last segment in an SR Policy, and it is associated with one outgoing interface I.
end.dx2 SIDはSRポリシーの最後のセグメントでなければならず、1つの発信インターフェースIに関連付けられています。
When N receives a packet destined to S and S is a local End.DX2 SID, N does the following:
nがSおよびS宛のパケットを受信すると、ローカルend.dx2 SID、nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX2 SID, N does the following:
end.dx2 SIDとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上位レイヤーヘッダーを処理する場合、nは次のようにします。
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the Ethernet frame to the OIF I
S04. } Else {
S05. Process as per Section 4.1.1
S06. }
| Note:
|
| S01. IANA has allocated value "143" for "Ethernet"
| [IEEE.802.3_2018] in the "Assigned Internet Protocol Numbers"
| registry (see Section 10.1).
|
| S03. An End.DX2 behavior could be customized to expect a
| specific IEEE header (e.g., VLAN tag) and rewrite the egress
| IEEE header before forwarding on the outgoing interface.
Note that an End.DX2 SID may also be associated with a bundle of outgoing interfaces.
END.DX2 SIDは、発信インターフェースのバンドルに関連付けることもできます。
The "Endpoint with decapsulation and VLAN L2 table lookup" behavior ("End.DX2V" for short) is a variant of the End.DX2 behavior.
「デカプセル化とVLAN L2テーブルルックアップ」の動作（短縮のための "end.dx2v"）は、end.dx2の動作の変形です。
One of the applications of the End.DX2V behavior is the EVPN Flexible Cross-connect use case. The End.DX2V behavior is used to perform a lookup of the Ethernet frame VLANs in a particular L2 table. Any SID instance of this behavior is associated with an L2 table T.
END.DX2Vの動作のアプリケーションの1つはEVPNフレキシブルクロスコネクトユースケースです。end.dx2vの動作は、特定のL2テーブル内のイーサネットフレームVLANのルックアップを実行するために使用されます。この動作のSIDインスタンスは、L2テーブルTに関連付けられています。
When N receives a packet whose IPv6 DA is S and S is a local End.DX2 SID, the processing is identical to the End.DX2 behavior except for the Upper-Layer header processing, which is modified as follows:
IPv6 DAがSおよびSがローカルend.dx2 SIDであるパケットを受信すると、次のように変更された上位レイヤーヘッダー処理を除くend.dx2の動作と同じです。
S03. Look up the exposed VLANs in L2 table T, and forward via the matched table entry.
S03。露出したVLANをL2テーブルTに見上げ、一致したテーブルエントリを介して前方に調べます。
| Note:
|
| S03. An End.DX2V behavior could be customized to expect a
| specific VLAN format and rewrite the egress VLAN header before
| forwarding on the outgoing interface.
The "Endpoint with decapsulation and unicast MAC L2 table lookup" behavior ("End.DT2U" for short) is a variant of the End behavior.
「カプセル化とユニキャストMAC L2テーブルルックアップ」の動作（短縮のための "end.dt2u"は終了動作の変形です。
One of the applications of the End.DT2U behavior is the EVPN Bridging Unicast [RFC7432]. Any SID instance of the End.DT2U behavior is associated with an L2 table T.
END.DT2Uの動作のアプリケーションの1つはEVPNブリッジングユニキャスト[RFC7432]です。end.dt2uの動作のSIDインスタンスは、L2テーブルTに関連付けられています。
When N receives a packet whose IPv6 DA is S and S is a local End.DT2U SID, the processing is identical to the End.DX2 behavior except for the Upper-Layer header processing, which is as follows:
IPv6 DAがSおよびSがローカルend.dt2U SIDであるパケットを受信すると、次のような上位レイヤヘッダー処理を除くend.dx2の動作と同じです。
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 table T
S04. Look up the exposed MAC Destination Address in L2 table T
S05. If (matched entry in T) {
S06. Forward via the matched table T entry
S07. } Else {
S08. Forward via all L2 OIFs in table T
S09. }
S10. } Else {
S11. Process as per Section 4.1.1
S12. }
| Note:
|
| S01. IANA has allocated value "143" for "Ethernet" in the
| "Assigned Internet Protocol Numbers" registry (see
| Section 10.1).
|
| S03. In EVPN [RFC7432], the learning of the exposed MAC Source
| Address is done via the control plane. In L2VPN Virtual
| Private LAN Service (VPLS) [RFC4761] [RFC4762], reachability is
| obtained by standard learning bridge functions in the data
| plane.
The "Endpoint with decapsulation and L2 table flooding" behavior ("End.DT2M" for short) is a variant of the End.DT2U behavior.
「デカプセル化およびL2テーブルフラッディングのエンドポイント」（短縮のための "end.dt2m"）は、end.dt2uの動作の変形です。
Two of the applications of the End.DT2M behavior are the EVPN Bridging of Broadcast, Unknown Unicast, and Multicast (BUM) traffic with Ethernet Segment Identifier (ESI) filtering [RFC7432] and the EVPN Ethernet-Tree (E-Tree) [RFC8317] use cases.
End.DT2Mの動作の2つのアプリケーションは、ブロードキャスト、不明なユニキャスト、およびイーサネットセグメント識別子（ESI）フィルタリング[RFC7432]とEVPNイーサネットツリー（E-Tree）[RFC8317]のEVPNブリッジングです。]ユースケース。
Any SID instance of this behavior is associated with an L2 table T. The behavior also takes an argument: "Arg.FE2". This argument provides a local mapping to ESI for split-horizon filtering of the received traffic to exclude a specific OIF (or set of OIFs) from L2 table T flooding. The allocation of the argument values is local to the SR Segment Endpoint Node instantiating this behavior, and the signaling of the argument to other nodes for the EVPN functionality occurs via the control plane.
この動作のSIDインスタンスは、L2テーブルTに関連付けられています。この動作には引数も取ります。 "arg.fe2"。この引数は、受信したトラフィックのスプリットホライズンフィルタリングのためのESIへのローカルマッピングを提供し、L2テーブルTフラッディングから特定のOIF（またはOIFのセット）を除外します。引数値の割り当ては、この動作をインスタンス化するSRセグメントエンドポイントノードに対してローカルであり、EVPN機能に対する他のノードへの引数のシグナリングは制御プレーンを介して行われます。
When N receives a packet whose IPv6 DA is S and S is a local End.DT2M SID, the processing is identical to the End.DX2 behavior except for the Upper-Layer header processing, which is as follows:
NiPv6 DAがSおよびSがローカルend.dt2M SIDのパケットを受信すると、次のような上位レイヤヘッダー処理を除くend.dx2の動作と同じです。
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 table T
S04. Forward via all L2 OIFs excluding those associated with the
identifier Arg.FE2
S05. } Else {
S06. Process as per Section 4.1.1
S07. }
| Note:
|
| S01. IANA has allocated value "143" for "Ethernet" in the
| "Assigned Internet Protocol Numbers" registry (see
| Section 10.1).
|
| S03. In EVPN [RFC7432], the learning of the exposed MAC Source
| Address is done via the control plane. In L2VPN VPLS [RFC4761]
| [RFC4762], reachability is obtained by standard learning bridge
| functions in the data plane.
4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy with Encapsulation
4.13. end.b6.encaps：カプセル化を使用したSRV6ポリシーにバインドされたエンドポイント
This is a variation of the End behavior.
これは終了行動の変化です。
One of its applications is to express scalable traffic-engineering policies across multiple domains. It is one of the SRv6 instantiations of a Binding SID [RFC8402].
そのアプリケーションの1つは、複数のドメイン間でスケーラブルなトラフィックエンジニアリングポリシーを表現することです。それはバインディングSID [RFC8402]のSRV6インスタンス化の1つです。
Any SID instance of this behavior is associated with an SR Policy B and a source address A.
この動作のSIDインスタンスは、SRポリシーBと送信元アドレスAに関連付けられています。
When N receives a packet whose IPv6 DA is S and S is a local End.B6.Encaps SID, N does the following:
n ipv6 daがsおよびsがローカルend.b6.encaps sidであるパケットを受信すると、nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S11. }
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Push a new IPv6 header with its own SRH containing B
S16. Set the outer IPv6 SA to A
S17. Set the outer IPv6 DA to the first SID of B
S18. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next Header fields
S19. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S20. }
| Note:
|
| S15. The SRH MAY be omitted when the SRv6 Policy B only
| contains one SID and there is no need to use any flag, tag, or
| TLV.
|
| S18. The Payload Length, Traffic Class, Hop Limit, and Next
| Header fields are set as per [RFC2473]. The Flow Label is
| computed as per [RFC6437].
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.B6.Encaps SID, process the packet as per Section 4.1.1.
end.b6.encaps SIDとしてローカルにインスタンス化されたFIBエントリと一致するパケットの上位ヘッダを処理する場合は、セクション4.1.1に従ってパケットを処理してください。
This is an optimization of the End.B6.Encaps behavior.
これはend.b6.encapsの動作の最適化です。
End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding the first SID in the SRH of the new IPv6 header. Thus, the first segment is only placed in the IPv6 Destination Address of the new IPv6 header, and the packet is forwarded according to it.
end.b6.encaps.redは、新しいIPv6ヘッダーのSRHの最初のSIDを除外することによって、SRHのサイズを1つのSIDに縮小します。したがって、最初のセグメントは新しいIPv6ヘッダーのIPv6宛先アドレスにのみ配置され、パケットはそれに従って転送されます。
The SRH Last Entry field is set as defined in Section 4.1.1 of [RFC8754].
SRH Last Entryフィールドは、[RFC8754]の4.1.1項で定義されているとおりに設定されています。
The SRH MAY be omitted when the SRv6 Policy only contains one SID and there is no need to use any flag, tag, or TLV.
SRV6ポリシーに1つのSIDのみが含まれていて、任意のフラグ、タグ、またはTLVを使用する必要がない場合、SRHは省略できます。
The "Endpoint bound to an SR-MPLS Policy" behavior ("End.BM" for short) is a variant of the End behavior.
「SR-MPLSポリシーにバインドされているエンドポイント」の動作（短縮の「end.bm」）は、終了動作の変形です。
The End.BM behavior is required to express scalable traffic-engineering policies across multiple domains where some domains support the MPLS instantiation of Segment Routing. This is an SRv6 instantiation of an SR-MPLS Binding SID [RFC8402].
end.bmの動作は、一部のドメインがセグメントルーティングのMPLSインスタンス化をサポートする複数のドメインにわたってスケーラブルなトラフィックエンジニアリングポリシーを表現するために必要です。これはSR-MPLSバインディングSID [RFC8402]のSRV6インスタンス化です。
Any SID instance of this behavior is associated with an SR-MPLS Policy B.
この動作のSIDインスタンスは、SR-MPLSポリシーBに関連付けられています。
When N receives a packet whose IPv6 DA is S and S is a local End.BM SID, N does the following:
n ipv6 daがsおよびsがlocal end.bm sidであるパケットを受信すると、nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S11. }
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Push the MPLS label stack for B
S16. Submit the packet to the MPLS engine for transmission
S17. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.BM SID, process the packet as per Section 4.1.1.
end.bm SIDとしてローカルにインスタンス化されたFIBエントリと一致するパケットの上位ヘッダを処理する場合は、セクション4.1.1に従ってパケットを処理してください。
The Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (USP) of the SRH, and Ultimate Segment Decapsulation (USD) flavors are variants of the End, End.X, and End.T behaviors. The End, End.X, and End.T behaviors can support these flavors either individually or in combinations.
SRH、究極のセグメントPOP（USP）の最後から2,6級セグメントPOP（PSP）、および最終的なセグメントのカプセル化（USD）の香りは、最終的、end.x、およびend.tの動作の変形です。最後、end.x、およびend.tの動作は、個別にまたは組み合わせでこれらのフレーバーをサポートできます。
SR Segment Endpoint Nodes advertise the SIDs instantiated on them via control-plane protocols as described in Section 8. Different behavior IDs are allocated for flavored and unflavored SIDs (see Table 6).
SRセグメントエンドポイントノードは、セクション8で説明されているように、それらにインスタンス化されたSIDを制御プレーンプロトコルを介してアドバタイズします。
An SR Segment Endpoint Node that offers both PSP- and non-PSP-flavored behavior advertises them as two different SIDs.
PSPおよび非PSP風味の行動の両方を提供するSRセグメントエンドポイントノードは、それらを2つの異なるSIDとしてアドバタイズします。
The SR Segment Endpoint Node only advertises the PSP flavor if the operator enables this capability at the node.
オペレータがノードでこの機能を有効にした場合、SRセグメントエンドポイントノードはPSPフレーバーのみをアドバタイズします。
The PSP operation is deterministically controlled by the SR source node.
PSP操作は、SRソースノードによって決定的に制御されています。
A PSP-flavored SID is used by the SR source node when it needs to instruct the penultimate SR Segment Endpoint Node listed in the SRH to remove the SRH from the IPv6 header.
PSP風味のSIDは、SRHにリストされている最後から集中SRセグメントエンドポイントノードをIPv6ヘッダーから削除するように指示する必要があるときにSRソースノードによって使用されます。
SR Segment Endpoint Nodes receive the IPv6 packet with the Destination Address field of the IPv6 header equal to its SID address.
SRセグメントエンドポイントノードは、IPv6ヘッダーの宛先アドレスフィールドをSIDアドレスに等しいIPv6パケットを受け取ります。
A penultimate SR Segment Endpoint Node is one that, as part of the SID processing, copies the last SID from the SRH into the IPv6 Destination Address and decrements the Segments Left value from one to zero.
最後から集中的なSRセグメントエンドポイントノードは、SID処理の一部として、SRHから最後のSIDをIPv6宛先アドレスにコピーし、セグメントの左の値を1からゼロに縮小することです。
The PSP operation only takes place at a penultimate SR Segment Endpoint Node and does not happen at any transit node. When a SID of PSP flavor is processed at a non-penultimate SR Segment Endpoint Node, the PSP behavior is not performed as described in the pseudocode below since Segments Left would not be zero.
PSP操作は、最後から2番目のSRセグメントエンドポイントノードでのみ行われ、任意のトランジットノードでは発生しません。PSPフレーバーのSIDが、最後から最後のSRセグメントエンドポイントノードで処理されると、セグメントが残っていないため、下の疑似コードで説明されているようにPSPの動作は実行されません。
The SRH processing of the End, End.X, and End.T behaviors are modified: after the instruction "S14. Update IPv6 DA with Segment List[Segments Left]" is executed, the following instructions must be executed as well:
終了、end.x、およびend.tの動作は変更されます。
S14.1. If (Segments Left == 0) {
S14.2. Update the Next Header field in the preceding header to
the Next Header value from the SRH
S14.3. Decrease the IPv6 header Payload Length by
8*(Hdr Ext Len+1)
S14.4. Remove the SRH from the IPv6 extension header chain
S14.5. }
The usage of PSP does not increase the MTU of the IPv6 packet and hence does not have any impact on the Path MTU (PMTU) discovery mechanism.
PSPの使用方法はIPv6パケットのMTUを増やしていないため、PATU MTU（PMTU）発見メカニズムに影響を与えません。
As a reminder, Section 5 of [RFC8754] defines the SR Deployment Model within the SR Domain [RFC8402]. Within this framework, the Authentication Header (AH) is not used to secure the SRH as described in Section 7.5 of [RFC8754]. Hence, the discussion of applicability of PSP along with AH usage is beyond the scope of this document.
リマインダーとして、[RFC8754]のセクション5は、SRドメイン[RFC8402]内のSR展開モデルを定義します。このフレームワーク内では、[RFC8754]のセクション7.5で説明されているように、認証ヘッダー（AH）はSRHを保護するために使用されません。したがって、AH使用法とともにPSPの適用性の説明はこの文書の範囲を超えています。
In the context of this specification, the End, End.X, and End.T behaviors with PSP do not contravene Section 4 of [RFC8200] because the destination address of the incoming packet is the address of the node executing the behavior.
この仕様の文脈では、PSPとの末尾、end.x、およびend.tの動作は、着信パケットの宛先アドレスが動作を実行するノードのアドレスであるため、[RFC8200]の区間4ではありません。
One use case for the PSP functionality is streamlining the operation of an egress border router.
PSP機能のための1つのユースケースは、出力境界ルータの動作を合理化することです。
+----------------------------------------------------+
| |
+-+-+ +--+ +--+ +--+ +-+-+
|iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE|
| R1| +--+ +--+ +--+ |R5 |
+-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+
| |IPv6 | |IPv6 | |IPv6 | |IPv6 | |
| |DA=R3| |DA=R3| |DA=R5| |DA=R5| |
| +-----+ +-----+ +-----+ +-----+ |
| | SRH | | SRH | | IP | | IP | |
| |SL=1 | |SL=1 | +-----+ +-----+ |
| | R5 | | R5 | |
| +-----+ +-----+ |
| | IP | | IP | |
| +-----+ +-----+ |
| |
+----------------------------------------------------+
Figure 1: PSP Use Case Topology
図1：PSPユースケーストポロジ
In the above illustration, for a packet sent from the ingress provider edge (iPE) to the egress provider edge (ePE), node R3 is an intermediate traffic-engineering waypoint and is the penultimate segment endpoint router; this node copies the last segment from the SRH into the IPv6 Destination Address and decrements Segments Left to 0. The Software-Defined Networking (SDN) controller knows that no other node after R3 needs to inspect the SRH, and it instructs R3 to remove the exhausted SRH from the packet by using a PSP-flavored SID.
上の図では、入力プロバイダエッジ（IPE）から出力プロバイダエッジ（EPE）へ送信されたパケットの場合、ノードR3は中間トラフィックエンジニアリングウェイポイントであり、最後から集中セグメントエンドポイントルータである。このノードはSRHからの最後のセグメントをIPv6宛先アドレスにコピーし、セグメントを左から0にします。ソフトウェア定義ネットワーキング（SDN）コントローラは、R3後の他のノードがSRHを検査する必要があり、R3に削除するように指示します。PSP風味のSIDを使用して、パケットからSRHを使い果たしました。
The benefits for the egress PE are straightforward:
出口PEの利点は簡単です。
* As part of the decapsulation process, the egress PE is required to parse and remove fewer bytes from the packet.
* カプセル化プロセスの一部として、出力PEはパケットからより少ないバイトを解析および削除するために必要です。
* If a lookup on an upper-layer IP header is required (e.g., per-VRF VPN), the header is more likely to be within the memory accessible to the lookup engine in the forwarding ASIC (Application-Specific Integrated Circuit).
* 上層IPヘッダに対するルックアップが（例えばVRFごとのVPNあたり）、ヘッダは、転送ASIC（アプリケーション固有の集積回路）内のルックアップエンジンにアクセス可能なメモリ内にある可能性が高い。
The SRH processing of the End, End.X, and End.T behaviors are modified; the instructions S02-S04 are substituted by the following ones:
最後のSRH処理、end.x、およびend.tの動作は変更されています。命令S02~S04は以下のもので置き換えられている。
S02. If (Segments Left == 0) {
S03.1. Update the Next Header field in the preceding header to
the Next Header value of the SRH
S03.2. Decrease the IPv6 header Payload Length by
8*(Hdr Ext Len+1)
S03.3. Remove the SRH from the IPv6 extension header chain
S03.4. Proceed to process the next header in the packet
S04. }
One of the applications of the USP flavor is when a packet with an SRH is destined to an application on hosts with smartNICs ("Smart Network Interface Cards") implementing SRv6. The USP flavor is used to remove the consumed SRH from the extension header chain before sending the packet to the host.
USPフレーバーのアプリケーションの1つは、SRHを持つパケットがSSRV6を実装するSMARTNICS（「スマートネットワークインタフェースカード」）を使用してホスト上のアプリケーションに運ばれている場合です。USPフレーバーは、パケットをホストに送信する前に、拡張ヘッダーチェーンから消費されたSRHを削除するために使用されます。
The Upper-Layer header processing of the End, End.X, and End.T behaviors are modified as follows:
最終的な、end.x、およびend.tの動作の上位層ヘッダー処理は次のように修正されています。
End:
終わり：
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S04. } Else if (Upper-Layer header type == 4(IPv4) ) {
S05. Remove the outer IPv6 header with all its extension headers
S06. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S07. Else {
S08. Process as per Section 4.1.1
S09. }
End.T:
end.t：
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S05. } Else if (Upper-Layer header type == 4(IPv4) ) {
S06. Remove the outer IPv6 header with all its extension headers
S07. Set the packet's associated FIB table to T
S08. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S09. Else {
S10. Process as per Section 4.1.1
S11. }
End.X:
end.x：
S01. If (Upper-Layer header type == 41(IPv6) ||
Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the exposed IP packet to the L3 adjacency J
S04. } Else {
S05. Process as per Section 4.1.1
S06. }
One of the applications of the USD flavor is the case of a Topology Independent Loop-Free Alternate (TI-LFA) in P routers with encapsulation. The USD flavor allows the last SR Segment Endpoint Node in the repair path list to decapsulate the IPv6 header added at the TI-LFA Point of Local Repair and forward the inner packet.
USDフレーバーのアプリケーションの1つは、カプセル化を備えたPルータのトポロジ独立ループフリーの代替（TI-LFA）の場合です。USDのフレーバーは、REPUAL PATHリスト内の最後のSRセグメントエンドポイントノードが、LOCAL REPAIRのTI-LFAポイントで追加されたIPv6ヘッダーをカプセル化し、内部パケットを転送します。
This section describes a set of SRv6 Policy Headend [RFC8402] behaviors.
このセクションでは、一連のSRV6ポリシーヘッドエンド[RFC8402]ビヘイビアについて説明します。
+-----------------+-----------------------------------------------+
| H.Encaps | SR Headend with Encapsulation in an SR Policy |
+-----------------+-----------------------------------------------+
| H.Encaps.Red | H.Encaps with Reduced Encapsulation |
+-----------------+-----------------------------------------------+
| H.Encaps.L2 | H.Encaps Applied to Received L2 Frames |
+-----------------+-----------------------------------------------+
| H.Encaps.L2.Red | H.Encaps.Red Applied to Received L2 Frames |
+-----------------+-----------------------------------------------+
Table 2: SR Policy Headend Behaviors
表2：SRポリシーヘッドエンドビヘイビアー
This list is not exhaustive, and future documents may define additional behaviors.
このリストは網羅的なものではなく、将来の文書は追加の行動を定義するかもしれません。
Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; SL=1). B2 is neither a local address nor SID of N.
ノードNは、P1 =（A、A、B2）、P2 =（A、B2）（B3、B2、B1; SL = 1）の2つのパケットを受信する。B2はNのローカルアドレスもSIDでもない。
Node N is configured with an IPv6 address T (e.g., assigned to its loopback).
ノードNは、IPv6アドレスT（例えば、そのループバックに割り当てられている）で構成されている。
N steers the transit packets P1 and P2 into an SRv6 Policy with a Source Address T and a segment list <S1, S2, S3>.
Nは、送信パケットP1、P2を送信元アドレスTおよびセグメントリスト<S1、S2、S3>を用いてSRV6ポリシーに固定する。
The H.Encaps encapsulation behavior is defined as follows:
H.Encapsカプセル化動作は次のように定義されています。
S01. Push an IPv6 header with its own SRH S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID in the segment list S03. Set outer Payload Length, Traffic Class, Hop Limit, and Flow Label fields S04. Set the outer Next Header value S05. Decrement inner IPv6 Hop Limit or IPv4 TTL S06. Submit the packet to the IPv6 module for transmission to S1
S01。IPv6ヘッダーを独自のSRH S02で押します。セグメントリストS03の第1のSIDに、外部IPv6 SA = Tおよび外部IPv6 DAを設定する。外部ペイロード長、トラフィッククラス、ホップ制限、およびフローラベルフィールドS04を設定します。次のヘッダ値S05を設定します。内部IPv6ホップ制限またはIPv4 TTL S06を減少させる。S1への送信のためにパケットをIPv6モジュールに送信する
| Note:
|
| S03: As described in [RFC2473] and [RFC6437].
After the H.Encaps behavior, P1' and P2' respectively look like:
h.encapsの動作の後、P1 'とP2'は次のようになります。
* (T, S1) (S3, S2, S1; SL=2) (A, B2)
* (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)
The received packet is encapsulated unmodified (with the exception of the IPv4 TTL or IPv6 Hop Limit that is decremented as described in [RFC2473]).
受信したパケットは、非変更にカプセル化されていません（[RFC2473]に記載されているように、IPv4 TTLまたはIPv6ホップ制限を除いて）。
The H.Encaps behavior is valid for any kind of L3 traffic. This behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. It may be also used for TI-LFA [SR-TI-LFA] at the Point of Local Repair.
H.EncAPS動作は、いかなる種類のL3トラフィックにも有効です。この現象は、IPv4およびIPv6展開を備えたL3VPNに一般的に使用されています。局所修理の時点でTi-LFA [SR-Ti-LFA]にも使用できます。
The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV.
SRHのプッシュは、SRV6ポリシーに1つのセグメントのみが含まれていて、任意のフラグ、タグ、またはTLVを使用する必要がない場合は、省略できます。
The H.Encaps.Red behavior is an optimization of the H.Encaps behavior.
h.encaps.redの動作は、H.encapsの動作の最適化です。
H.Encaps.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. The first SID is only placed in the Destination Address field of the pushed IPv6 header.
h.encaps.redは、プッシュされたIPv6ヘッダーのSRHの最初のSIDを除外することによってSRHの長さを短縮します。最初のSIDは、プッシュされたIPv6ヘッダーの宛先アドレスフィールドにのみ配置されます。
After the H.Encaps.Red behavior, P1' and P2' respectively look like:
h.encaps.redの動作の後、P1 'とP2'はそれぞれ次のようになります。
* (T, S1) (S3, S2; SL=2) (A, B2)
* (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1)
The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV.
SRHのプッシュは、SRV6ポリシーに1つのセグメントのみが含まれていて、任意のフラグ、タグ、またはTLVを使用する必要がない場合は、省略できます。
The H.Encaps.L2 behavior encapsulates a received Ethernet [IEEE.802.3_2018] frame and its attached VLAN header, if present, in an IPv6 packet with an SRH. The Ethernet frame becomes the payload of the new IPv6 packet.
h.encaps.l2の動作は、受信したイーサネット[IEEE802.3_2018]フレームとその添付のVLANヘッダーをSRHでIPv6パケットでカプセル化します。イーサネットフレームは新しいIPv6パケットのペイロードになります。
The Next Header field of the SRH MUST be set to 143.
SRHの次のヘッダーフィールドは143に設定する必要があります。
The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV.
SRHのプッシュは、SRV6ポリシーに1つのセグメントのみが含まれていて、任意のフラグ、タグ、またはTLVを使用する必要がない場合は、省略できます。
The encapsulating node MUST remove the preamble (if any) and frame check sequence (FCS) from the Ethernet frame upon encapsulation, and the decapsulating node MUST regenerate, as required, the preamble and FCS before forwarding the Ethernet frame.
カプセル化ノードは、カプセル化時にイーサネットフレームからプリアンブル（存在する場合）とフレームチェックシーケンス（FCS）を削除し、デカプセル化ノードは、イーサネットフレームを転送する前にプリアンブルとFCSを再生成する必要があります。
The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 behavior.
h.encaps.l2.redの動作は、h.encaps.l2の動作の最適化です。
H.Encaps.L2.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. The first SID is only placed in the Destination Address field of the pushed IPv6 header.
h.encaps.l2.redは、プッシュされたIPv6ヘッダーのSRHの最初のSIDを除くことによってSRHの長さを短縮します。最初のSIDは、プッシュされたIPv6ヘッダーの宛先アドレスフィールドにのみ配置されます。
The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV.
SRHのプッシュは、SRV6ポリシーに1つのセグメントのみが含まれていて、任意のフラグ、タグ、またはTLVを使用する必要がない場合は、省略できます。
A node supporting this document SHOULD implement a pair of traffic counters (one for packets and one for bytes) per local SID entry, for traffic that matched that SID and was processed successfully (i.e., packets that generate ICMP Error Messages or are dropped are not counted). The retrieval of these counters from MIB, NETCONF/YANG, or any other data structure is outside the scope of this document.
このドキュメントをサポートするノードは、SIDと一致するトラフィックについて、SIDと正常に処理されたトラフィックについて（すなわち、ICMPエラーメッセージを生成するか、またはドロップされているパケットの場合）、ローカルSIDエントリごとに一対のトラフィックカウンタ（パケット用、1つ用の1つ）を実装する必要があります。カウントされました）。MIB、NETCONF / YANG、またはその他のデータ構造からのこれらのカウンタの検索は、この文書の範囲外です。
When a flow-based selection within a set needs to be performed, the IPv6 Source Address, the IPv6 Destination Address, and the IPv6 Flow Label of the outer IPv6 header MUST be included in the flow-based hash.
セット内のフローベースの選択を実行する必要がある場合は、IPv6の送信元アドレス、IPv6の宛先アドレス、および外部IPv6ヘッダーのIPv6フローラベルをフローベースのハッシュに含める必要があります。
This may occur in any of the following scenarios:
これは、次のシナリオのいずれかで発生する可能性があります。
* A FIB lookup is performed and multiple ECMP paths exist to the updated destination address.
* FIBルックアップが実行され、更新された宛先アドレスに複数のECMPパスが存在します。
* End.X, End.DX4, or End.DX6 is bound to an array of adjacencies.
* end.x、end.dx4、またはend.dx6は、隣接関係の配列にバインドされています。
* The packet is steered in an SR Policy whose selected path has multiple SID lists.
* パケットは、選択されたパスに複数のSIDリストがあるSRポリシーで操縦されています。
Additionally, any transit router in an SRv6 domain includes the outer flow label in its ECMP flow-based hash [RFC6437].
さらに、SRV6ドメイン内のトランジットルータは、ECMPフローベースのハッシュ[RFC6437]の外側フローラベルを含みます。
In an SDN environment, one expects the controller to explicitly provision the SIDs and/or discover them as part of a service discovery function. Applications residing on top of the controller could then discover the required SIDs and combine them to form a distributed network program.
SDN環境では、コントローラがSIDSを明示的にプロビジョニングしたり、サービス検出機能の一部としてそれらを発見することを期待しています。コントローラの上に存在するアプリケーションは、必要なSIDを発見し、それらを組み合わせて分散ネットワークプログラムを形成することができます。
The concept of "SRv6 Network Programming" refers to the capability of an application to encode any complex program as a set of individual functions distributed through the network. Some functions relate to underlay SLA, others to overlay/tenant, and others to complex applications residing in VMs and containers.
「SRV6ネットワークプログラミング」の概念は、ネットワークを介して分散された個々の機能のセットとして、複雑なプログラムを符号化するためのアプリケーションの機能を指す。いくつかの関数は、アンダーレイSLAに関連しています。その他、VMやコンテナに存在する複雑なアプリケーションへのオーバーレイ/テナントなどに関連しています。
While not necessary for an SDN control plane, the remainder of this section provides a high-level illustrative overview of how control-plane protocols may be involved with SRv6. Their specification is outside the scope of this document.
SDN制御プレーンには必要ではないが、このセクションの残りの部分は、制御プレーンプロトコルがSRV6にどのように関わっているかの高レベルの例示的な概要を提供する。彼らの仕様はこの文書の範囲外です。
The End, End.T, and End.X SIDs express topological behaviors and hence are expected to be signaled in the IGP together with the flavors PSP, USP, and USD. The IGP should also advertise the Maximum SID Depth (MSD) capability of the node for each type of SRv6 operation -- in particular, the SR source (e.g., H.Encaps), intermediate endpoint (e.g., End and End.X), and final endpoint (e.g., End.DX4 and End.DT6) behaviors. These capabilities are factored in by an SR source node (or a controller) during the SR Policy computation.
最後、end.t、およびend.xのSIDSはトポロジの動作を発現し、したがってFLAVORS PSP、USP、およびUSDと共にIGP内でシグナリングされると予想されます。IGPはまた、特にSRソース（例えば、h.encaps）、中間エンドポイント（例えば、end.x）の各タイプのノードの最大SID深度（MSD）能力をアドバタイズする必要があります。そして最終的なエンドポイント（例えば、end.dx4とend.dt6）の動作。これらの機能は、SRポリシーの計算中にSRソースノード（またはコントローラ）によって因ります。
The presence of SIDs in the IGP does not imply any routing semantics to the addresses represented by these SIDs. The routing reachability to an IPv6 address is solely governed by the non-SID-related IGP prefix reachability information that includes locators. Routing is neither governed nor influenced in any way by a SID advertisement in the IGP.
IGP内のSIDSの存在は、これらのSIDによって表されるアドレスへのルーティングセマンティクスを意味するものではありません。IPv6アドレスへのルーティング到達可能性は、ロケータを含む非SID関連のIGPプレフィックス到達可能性情報によってのみ支配されます。ルーティングは、IGP内のSID広告によって決して管理も影響も影響しません。
These SIDs provide important topological behaviors for the IGP to build Fast Reroute (FRR) solutions based on TI-LFA [SR-TI-LFA] and for TE processes relying on an IGP topology database to build SR Policies.
これらのSIDSは、IGPがTI-LFA [SR-TI-LFA]に基づく高速再ルーチ（FRR）ソリューションを構築し、SRポリシーを構築するためのIGPトポロジーデータベースに依存するTEプロセスについての重要なトポロジー・動作を提供します。
BGP-LS provides the functionality for topology discovery that includes the SRv6 capabilities of the nodes, their locators, and locally instantiated SIDs. This enables controllers or applications to build an inter-domain topology that can be used for computation of SR Policies using the SRv6 SIDs.
BGP-LSは、ノードのSRV6機能、それらのロケータ、および局所的にインスタンス化されたSIDを含むトポロジ検出の機能を提供します。これにより、コントローラまたはアプリケーションは、SRV6 SIDSを使用したSRポリシーの計算に使用できるドメイン間トポロジを構築することができます。
The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, End.DT2U, and End.DT2M SIDs can be signaled in BGP.
end.dx4、end.dx6、end.dt4、end.dt6、end.dt46、end.dx2、end.dx2v、end.dt2u、およびend.dt2u、およびend.dt2u、およびend.dt2u、およびend.dt2u、およびend.dt2u、およびend.dt2u、およびend.dt2u、およびend.dt2u
In some scenarios, an egress PE advertising a VPN route might wish to abstract the specific behavior bound to the SID from the ingress PE and other routers in the network. In such case, the SID may be advertised using the Opaque SRv6 Endpoint Behavior codepoint defined in Table 6. The details of such control-plane signaling mechanisms are out of the scope of this document.
いくつかのシナリオでは、VPNルートを広告する出力PEは、Ingress PEおよびネットワーク内の他のルータからSIDにバインドされている特定の動作を抽象化することができます。そのような場合、SIDは表6に定義されている不透明SRV6エンドポイント動作コードポイントを使用してアドバタイズされてもよい。そのような制御プレーンシグナリングメカニズムの詳細はこの文書の範囲外である。
The following table summarizes which SID behaviors may be signaled in which control-plane protocol.
次の表は、制御面プロトコルがどのSID動作をシグナリングすることができるかを要約している。
+=======================+=====+========+=================+
| | IGP | BGP-LS | BGP IP/VPN/EVPN |
+=======================+=====+========+=================+
| End (PSP, USP, USD) | X | X | |
+-----------------------+-----+--------+-----------------+
| End.X (PSP, USP, USD) | X | X | |
+-----------------------+-----+--------+-----------------+
| End.T (PSP, USP, USD) | X | X | |
+-----------------------+-----+--------+-----------------+
| End.DX6 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DX4 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT6 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT4 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT46 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DX2 | | X | X |
+-----------------------+-----+--------+-----------------+
| End.DX2V | | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT2U | | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT2M | | X | X |
+-----------------------+-----+--------+-----------------+
| End.B6.Encaps | | X | |
+-----------------------+-----+--------+-----------------+
| End.B6.Encaps.Red | | X | |
+-----------------------+-----+--------+-----------------+
| End.B6.BM | | X | |
+-----------------------+-----+--------+-----------------+
Table 3: SRv6 Locally Instantiated SIDs Signaling
表3：SRV6ローカルにインスタンス化されたSIDシグナリング
The following table summarizes which SR Policy Headend capabilities may be signaled in which control-plane protocol.
次の表は、どのSRポリシーヘッドエンド機能がどの制御プレーンプロトコルでシグナリングされているかをまとめたものです。
+=================+=====+========+=================+
| | IGP | BGP-LS | BGP IP/VPN/EVPN |
+=================+=====+========+=================+
| H.Encaps | X | X | |
+-----------------+-----+--------+-----------------+
| H.Encaps.Red | X | X | |
+-----------------+-----+--------+-----------------+
| H.Encaps.L2 | | X | |
+-----------------+-----+--------+-----------------+
| H.Encaps.L2.Red | | X | |
+-----------------+-----+--------+-----------------+
Table 4: SRv6 Policy Headend Behaviors Signaling
表4：SRV6ポリシーヘッドエンドビヘイビアシグナリング
The previous table describes generic capabilities. It does not describe specific instantiated SR Policies.
前の表に汎用機能について説明します。特定のインスタンス化されたSRポリシーについては説明していません。
For example, a BGP-LS advertisement of H.Encaps behavior would describe the capability of node N to perform H.Encaps behavior. Specifically, it would describe how many SIDs could be pushed by N without significant performance degradation.
たとえば、H.Encapsの動作のBGP-LS広告は、H.encapsの動作を実行するためのノードNの機能を説明します。具体的には、パフォーマンスが大幅に劣化することなく、Nによって数のSIDを押すことができるかについて説明します。
As a reminder, an SR Policy is always assigned a Binding SID [RFC8402]. Binding SIDs are also advertised in BGP-LS as shown in Table 3. Hence, Table 4 only focuses on the generic capabilities related to H.Encaps.
リマインダーとして、SRポリシーには常にバインディングSID [RFC8402]が割り当てられています。バインディングSIDも表3に示すようにBGP-LSで宣伝されているため、表4はH.EncAPSに関連する一般的な機能に焦点を当てています。
The security considerations for Segment Routing are discussed in [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model and the requirements for securing the SR Domain. The security considerations of [RFC8754] also cover topics such as attack vectors and their mitigation mechanisms that also apply the behaviors introduced in this document. Together, they describe the required security mechanisms that allow establishment of an SR domain of trust. Having such a well-defined trust boundary is necessary in order to operate SRv6-based services for internal traffic while preventing any external traffic from accessing or exploiting the SRv6-based services. Care and rigor in IPv6 address allocation for use for SRv6 SID allocations and network infrastructure addresses, as distinct from IPv6 addresses allocated for end users and systems (as illustrated in Section 5.1 of [RFC8754]), can provide the clear distinction between internal and external address space that is required to maintain the integrity and security of the SRv6 Domain. Additionally, [RFC8754] defines a Hashed Message Authentication Code (HMAC) TLV permitting SR Segment Endpoint Nodes in the SR domain to verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation, regardless of the number of segments in the segment list. When enabled by local configuration, HMAC processing occurs at the beginning of SRH processing as defined in Section 2.1.2.1 of [RFC8754].
セグメントルーティングのセキュリティ上の考慮事項は[RFC8402]で説明されています。 [RFC8754]のセクション5では、SR展開モデルとSRドメインを保護するための要件について説明します。 [RFC8754]のセキュリティ上の考慮事項は、攻撃ベクトルやその軽減メカニズムなどのトピックもカバーしています。一緒に、彼らは信頼のSRドメインの確立を可能にする必要なセキュリティメカニズムを説明します。このような明確に定義された信頼境界を持つことは、SRV6ベースのサービスへのアクセスまたは利用による外部トラフィックのために内部トラフィックのためにSRV6ベースのサービスを操作するために必要です。 End UsersおよびSystemsに割り当てられたIPv6アドレスおよびネットワークインフラストラクチャアドレスに使用するためのIPv6アドレス割り当て（RFC8754のセクション5.1のセクション5.1に示すように）は、内部と外部の間の明確な区別を提供できます。 SRV6ドメインの整合性とセキュリティを維持するために必要なアドレススペース。さらに、[RFC8754]は、SRドメイン内のSRセグメントエンドポイントノードを許可し、SRドメイン内のSRセグメントエンドポイントノードを許可し、パケットに適用されたSRHが許可された当事者によって選択され、セグメントリストが後に変更されないことを確認することを可能にするハッシュメッセージ認証コード（HMAC）TLVを定義します。セグメントリスト内のセグメント数に関係なく、生成。ローカル構成で有効にすると、[RFC8754]のセクション2.1.2.1で定義されているSRH処理の開始時にHMAC処理が行われます。
This document introduces SRv6 Endpoint and SR Policy Headend behaviors for implementation on SRv6-capable nodes in the network. The definition of the SR Policy Headend should be consistent with the specific behavior used and any local configuration (as specified in Section 4.1.1). As such, this document does not introduce any new security considerations.
このドキュメントでは、ネットワーク内のSRV6対応ノード上の実装のためにSRV6エンドポイントとSRポリシーヘッドエンド動作を紹介します。SRポリシーヘッドエンドの定義は、使用される特定の動作とローカル構成と一致する必要があります（セクション4.1.1で指定されているように）。そのため、この文書では新しいセキュリティ上の考慮事項を導入していません。
The SID behaviors specified in this document have the same HMAC TLV handling and mutability properties with regard to the Flags, Tag, and Segment List field as the SID behavior specified in [RFC8754].
この文書で指定されているSID動作は、[RFC8754]で指定されたSID動作として、フラグ、タグ、およびセグメントリストフィールドに関して同じHMAC TLVの処理と変異性のプロパティを持ちます。
IANA has allocated "Ethernet" (value 143) in the "Assigned Internet Protocol Numbers" registry (see <https://www.iana.org/assignments/ protocol-numbers/>). Value 143 in the Next Header field of an IPv6 header or any extension header indicates that the payload is an Ethernet frame [IEEE.802.3_2018].
IANAは、「割り当てられたインターネットプロトコル番号」レジストリに「イーサネット」（値143）を割り当てました（<https：//www.iana.org/assignments/ protocol-numbers />を参照）。値143 IPv6ヘッダーまたは任意の拡張ヘッダーの次のヘッダーフィールドでは、ペイロードがイーサネットフレームであることが[IEEE.802.3_2018]であることを示します。
IANA has created a new top-level registry called "Segment Routing" (see <https://www.iana.org/assignments/segment-routing/>). This registry serves as a top-level registry for all Segment Routing subregistries.
IANAは、「セグメントルーティング」という新しいトップレベルのレジストリを作成しました（<https：//www.iana.org/ashignments / segming-routing/>）。このレジストリは、すべてのセグメントルーティングサブレジステリの最上位レジストリとして機能します。
Additionally, IANA has created a new subregistry called "SRv6 Endpoint Behaviors" under the top-level "Segment Routing" registry. This subregistry maintains 16-bit identifiers for the SRv6 Endpoint behaviors. This registry is established to provide consistency for control-plane protocols that need to refer to these behaviors. These values are not encoded in the function bits within a SID.
さらに、IANAは、最上位の「セグメントルーティング」レジストリの下にある「SRV6エンドポイントビヘイビア」と呼ばれる新しいサブレジストを作成しました。このサブレジストは、SRV6エンドポイントビヘイビアの16ビット識別子を維持します。このレジストリは、これらの動作を参照する必要がある制御プレーンプロトコルの一貫性を提供するために確立されています。これらの値は、SID内の関数ビットでは符号化されていません。
The range of the registry is 0-65535 (0x0000-0xFFFF). The table below contains the allocation ranges and registration policies [RFC8126] for each:
レジストリの範囲は0から65535（0x0000-0xFFFF）です。以下の表に、各項目の割り当て範囲と登録ポリシー[RFC8126]が含まれています。
+=============+===============+=========================+===========+
| Range | Range (Hex) | Registration | Note |
| | | Procedures | |
+=============+===============+=========================+===========+
| 0 | 0x0000 | Reserved | Not to be |
| | | | allocated |
+-------------+---------------+-------------------------+-----------+
| 1-32767 | 0x0001-0x7FFF | First Come | |
| | | First Served | |
+-------------+---------------+-------------------------+-----------+
| 32768-34815 | 0x8000-0x87FF | Private Use | |
+-------------+---------------+-------------------------+-----------+
| 34816-65534 | 0x8800-0xFFFE | Reserved | |
+-------------+---------------+-------------------------+-----------+
| 65535 | 0xFFFF | Reserved | Opaque |
+-------------+---------------+-------------------------+-----------+
Table 5: Registration Procedures
表5：登録手順
The initial registrations for the subregistry are as follows:
サブレジストの初期登録は次のとおりです。
+=============+===============+=========================+===========+
| Value | Hex | Endpoint Behavior | Reference |
+=============+===============+=========================+===========+
| 0 | 0x0000 | Reserved | |
+-------------+---------------+-------------------------+-----------+
| 1 | 0x0001 | End | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 2 | 0x0002 | End with PSP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 3 | 0x0003 | End with USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 4 | 0x0004 | End with PSP & USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 5 | 0x0005 | End.X | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 6 | 0x0006 | End.X with PSP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 7 | 0x0007 | End.X with USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 8 | 0x0008 | End.X with PSP & USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 9 | 0x0009 | End.T | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 10 | 0x000A | End.T with PSP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 11 | 0x000B | End.T with USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 12 | 0x000C | End.T with PSP & USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 13 | 0x000D | Unassigned | |
+-------------+---------------+-------------------------+-----------+
| 14 | 0x000E | End.B6.Encaps | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 15 | 0x000F | End.BM | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 16 | 0x0010 | End.DX6 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 17 | 0x0011 | End.DX4 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 18 | 0x0012 | End.DT6 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 19 | 0x0013 | End.DT4 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 20 | 0x0014 | End.DT46 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 21 | 0x0015 | End.DX2 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 22 | 0x0016 | End.DX2V | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 23 | 0x0017 | End.DT2U | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 24 | 0x0018 | End.DT2M | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 25 | 0x0019 | Reserved | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 26 | 0x001A | Unassigned | |
+-------------+---------------+-------------------------+-----------+
| 27 | 0x001B | End.B6.Encaps.Red | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 28 | 0x001C | End with USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 29 | 0x001D | End with PSP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 30 | 0x001E | End with USP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 31 | 0x001F | End with PSP, USP & | RFC 8986 |
| | | USD | |
+-------------+---------------+-------------------------+-----------+
| 32 | 0x0020 | End.X with USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 33 | 0x0021 | End.X with PSP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 34 | 0x0022 | End.X with USP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 35 | 0x0023 | End.X with PSP, USP | RFC 8986 |
| | | & USD | |
+-------------+---------------+-------------------------+-----------+
| 36 | 0x0024 | End.T with USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 37 | 0x0025 | End.T with PSP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 38 | 0x0026 | End.T with USP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 39 | 0x0027 | End.T with PSP, USP | RFC 8986 |
| | | & USD | |
+-------------+---------------+-------------------------+-----------+
| 40-32766 | 0x0028-0x7FFE | Unassigned | |
+-------------+---------------+-------------------------+-----------+
| 32767 | 0x7FFF | The SID defined in | RFC 8986, |
| | | RFC 8754 | RFC 8754 |
+-------------+---------------+-------------------------+-----------+
| 32768-34815 | 0x8000-0x87FF | Reserved for Private | RFC 8986 |
| | | Use | |
+-------------+---------------+-------------------------+-----------+
| 34816-65534 | 0x8800-0xFFFE | Reserved | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 65535 | 0xFFFF | Opaque | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
Table 6: Initial Registrations
表6：初期登録
[IEEE.802.3_2018] IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, DOI 10.1109/IEEESTD.2018.8457469, 31 August 2018, <https://ieeexplore.ieee.org/document/8457469>.
[IEEE.802.3_2018] IEEE、「イーサネットのためのIEEEスタンダード」、IEEE 802.3-2018、DOI 10.1109 / IEEESTD.2018.8457469,2018,2018、<https://ieeexplore.ieee.org/document/8457469>。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2473] Conta、A.およびS.THERER、「IPv6仕様の一般的なパケットトンネリング」、RFC 2473、DOI 10.17487 / RFC2473、1998年12月、<https：//www.rfc-editor.org/info/rfc2473>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、およびJ.Rajahalme、「IPv6フローラベル仕様」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc-editor.org/info/rfc6437>。
[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] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[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>。
[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>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R.およびB.B.Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https：//www.rfc-editor.org/info/rfc4193>。
[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>。
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.
[RFC4664]アンダーソン、L.、ED。E.ローゼン、「レイヤ2仮想プライベートネットワーク（L2VPNS）」、RFC 4664、DOI 10.17487 / RFC4664、2006年9月、<https://www.rfc-editor.org/info/rfc4664>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、ED。そして、rekhter、ed。、 "Virtual Private Lan Service（VPLS）、「自動検出およびシグナリングのためのBGPを使用したVPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<https：//www.rfc-editor.org/情報/ RFC4761>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M.、Ed。V. Kompella、ed。、「ラベル配布プロトコル（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（VPLS）、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<https：//www.rfc-editor.org/情報/ RFC4762>。
[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>。
[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]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[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 VPNでのイーサネットツリー（E-Tree）サポートEVPN）およびプロバイダーバックボーンブリッジEVPN（PBB-EVPN） "、RFC 8317、DOI 10.17487 / RFC8317、2018年1月、<https：//www.rfc-editor.org/info/rfc8317>。
[SR-TI-LFA] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-06, 1 February 2021, <https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-06>.
[SR-TI-LFA] Litkowski、S.、Bashandy、A.、Filsfils、C.、Francois、P.、Decraene、B.、D.航海、「トポロジー独立型REROUTE」、進行中の作業、インターネットドラフト、ドラフト - IETF-RTGWG-SEMPLAT-rout-ti-lfa-06,2021、<https：//tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-LFA-06>。
[SRV6-NET-PGM-ILLUST] Filsfils, C., Camarillo, P., Ed., Li, Z., Matsushima, S., Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and J. Leddy, "Illustrations for SRv6 Network Programming", Work in Progress, Internet-Draft, draft-filsfils-spring-srv6-net-pgm-illustration-03, 25 September 2020, <https://tools.ietf.org/html/draft-filsfils-spring-srv6- net-pgm-illustration-03>.
[SRV6-NET-PGM-ILLUST] Filsfils、C、Camarillo、P.、Ed。、Li、Z.、松島、S。、Decraene、B.、Steinberg、D.、Lebrun、D.、Raszuk、R。、およびJ.Leddy、「SRV6ネットワークプログラミングのためのイラスト」、進行中の作業、インターネットドラフト、Draft-Filsfils-Spring-SRV6-Net-PGM-ILOGN-SRV6-NET-PGM-ILOGNES-03,20 <https：//ツール。ietf.org/html/draft-filsfils-spring-srv6 - net-pgm-模様 - 03>。
Acknowledgements
謝辞
The authors would like to acknowledge Stefano Previdi, Dave Barach, Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, Jisu Bhattacharya, Saleem Hafeez, and Brian Carpenter.
著者らは、Stefano Previdi、Dave Barach、Mark Townsley、Peter Psenak、Thierry Couture、Kris Michielsen、Paul Wells、ロバートハンツル、Dan Ye、Gaurav Dawra、ファイサル・イッサル・ラジャマニッカム、David Toscano、Asif Islam、Jianda Liu、Yunpeng Zhang、Jiaoming Li、Narendra AK、マイクマックゴーリー、Bhupendra Yadav、Sherif Toulan、Satish Damaran、John Bettink、Kishore Nandyala Veera Venk、Jisu Bhattacharya、Saleem Hafez、Brian Carpenter。
Contributors
貢献者
Daniel Bernier Bell Canada Canada
ダニエルバーニアベルカナダカナダ
Email: daniel.bernier@bell.ca
Dirk Steinberg Lapishills Consulting Limited Cyprus
Dirk Steinberg Lapishills Consulting Limited Cyprus.
Email: dirk@lapishills.com
Robert Raszuk Bloomberg LP United States of America
Robert Raszuk Bloomberg LPアメリカ合衆国
Email: robert@raszuk.net
Bruno Decraene Orange France
ブルーノデコレインオレンジフランス
Email: bruno.decraene@orange.com
Bart Peirens Proximus Belgium
Bart Peirens Proximus Belgium
Email: bart.peirens@proximus.com
Hani Elmalky Google United States of America
Hani Elmalky Googleアメリカ合衆国
Email: helmalky@google.com
Prem Jonnalagadda Barefoot Networks United States of America
裸足ネットワークズアメリカ合衆国
Email: prem@barefootnetworks.com
Milad Sharif SambaNova Systems United States of America
Milad Sharif Sambanova Systemsアメリカ合衆国
Email: milad.sharif@sambanova.ai
David Lebrun Google Belgium
デビッドレブラングーグルベルギー
Email: dlebrun@google.com
Stefano Salsano Universita di Roma "Tor Vergata" Italy
Stefano Salsano Universita di Roma "Tor Vergata"イタリア
Email: stefano.salsano@uniroma2.it
Ahmed AbdelSalam Gran Sasso Science Institute Italy
Ahmed Abdelsalam Gran Sasso Science Instituteイタリア
Email: ahmed.abdelsalam@gssi.it
Gaurav Naik Drexel University United States of America
Gaurav Naik Drexel大学アメリカ合衆国
Email: gn@drexel.edu
Arthi Ayyangar Arrcus, Inc United States of America
Arthi Ayyangar Arrcus、Incアメリカ合衆国
Email: arthi@arrcus.com
Satish Mynam Arrcus, Inc United States of America
Satish Mynam Arrcus、Inc米国
Email: satishm@arrcus.com
Wim Henderickx Nokia Belgium
Wim Henderickx Nokia Belgium
Email: wim.henderickx@nokia.com
Shaowen Ma Juniper Singapore
Shaowen Ma Juniperシンガポール
Email: mashao@juniper.net
Ahmed Bashandy Individual United States of America
Ahmed Bashandy個人アメリカ合衆国
Email: abashandy.ietf@gmail.com
Francois Clad Cisco Systems, Inc. France
Francois Clad Cisco Systems、Inc。フランス
Email: fclad@cisco.com
Kamran Raza Cisco Systems, Inc. Canada
カンランラザシスコシステムズ社カナダ
Email: skraza@cisco.com
Darren Dukes Cisco Systems, Inc. Canada
Darren Dukes Cisco Systems、Inc
Email: ddukes@cisco.com
Patrice Brissete Cisco Systems, Inc. Canada
カナダのPatrice Brissete Cisco Systems
Email: pbrisset@cisco.com
Zafar Ali Cisco Systems, Inc. United States of America
Zafar Ali Cisco Systems、Inc。アメリカ合衆国
Email: zali@cisco.com
Ketan Talaulikar Cisco Systems, Inc. India
Ketan Talaulikar Cisco Systems、Inc
Email: ketant@cisco.com
Authors' Addresses
著者の住所
Clarence Filsfils (editor) Cisco Systems, Inc. Belgium
Clarence Filsfils（編集）Cisco Systems、Inc。ベルギー
Email: cf@cisco.com
Pablo Camarillo Garvia (editor) Cisco Systems, Inc. Spain
Pablo Camarillo Garvia（編集）Cisco Systems、Inc。スペイン
Email: pcamaril@cisco.com
John Leddy Akamai Technologies United States of America
John Leddy Akamai Technologiesアメリカ合衆国
Email: john@leddy.net
Daniel Voyer Bell Canada Canada
ダニエル航海ベルカナダカナダ
Email: daniel.voyer@bell.ca
Satoru Matsushima SoftBank Japan
松島悟ソフトバンク日本
Email: satoru.matsushima@g.softbank.co.jp
Zhenbin Li Huawei Technologies China
Zhenbin Li Huawei Technologies China.
Email: lizhenbin@huawei.com