Internet Engineering Task Force (IETF) K. Talaulikar
Request for Comments: 9819 K. Raza
Updates: 9252 Cisco Systems
Category: Standards Track J. Rabadan
ISSN: 2070-1721 Nokia
W. Lin
Juniper Networks
July 2025
RFC 9252 defines procedures and messages for BGP overlay services for Segment Routing over IPv6 (SRv6), including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and global Internet routing. This document updates RFC 9252 and provides more detailed specifications for the signaling and processing of SRv6 Segment Identifier advertisements for BGP overlay service routes associated with SRv6 Endpoint Behaviors that support arguments.
RFC 9252は、レイヤー3仮想プライベートネットワーク（L3VPN）、イーサネットVPN（EVPN）、グローバルインターネットルーティングを含むIPv6（SRV6）を介したセグメントルーティングのBGPオーバーレイサービスの手順とメッセージを定義します。このドキュメントはRFC 9252を更新し、SRV6セグメント識別子広告のシグナル伝達と処理のためのより詳細な仕様を提供します。
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/rfc9819.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9819で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Advertisement of SRv6 SID and Arguments
3. End.DT2M Signaling for EVPN ESI Filtering
3.1. Advertisement of Ethernet A-D per ES Route
3.2. Advertisement of Inclusive Multicast Ethernet Tag Route
3.3. Processing at Ingress PE
4. Backward Compatibility
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
SRv6 refers to Segment Routing instantiated over the IPv6 data plane [RFC8402]. An SRv6 Segment Identifier (SID) [RFC8402] can be associated with one of the service-specific SRv6 Endpoint Behaviors on the advertising Provider Edge (PE) router for Layer 3 Virtual Private Network (L3VPN), global Internet routing, and Ethernet VPN (EVPN) services as defined in [RFC8986]. Such SRv6 SIDs are referred to as SRv6 Service SIDs. [RFC9252] defines the procedures and messages for the signaling of BGP overlay services including L3VPN, EVPN, and Internet services using SRv6.
SRV6とは、IPv6データプレーン[RFC8402]を介してインスタンス化されたセグメントルーティングを指します。SRV6セグメント識別子（SID）[RFC8402]は、レイヤー3仮想プライベートネットワーク（L3VPN）、グローバルインターネットルーティング、およびイーサネットVPN（EVPN）サービスの広告プロバイダーエッジ（PE）ルーターのサービス固有のSRV6エンドポイント動作の1つに関連付けられます。このようなSRV6 SIDは、SRV6サービスSIDと呼ばれます。[RFC9252]は、L3VPN、EVPN、およびSRV6を使用したインターネットサービスを含むBGPオーバーレイサービスのシグナル伝達に関する手順とメッセージを定義します。
For certain EVPN services, Section 4.12 of [RFC8986] introduced the End.DT2M SRv6 Endpoint Behavior, which utilizes arguments (i.e., Arg.FE2). [RFC9252] subsequently specified the encoding and signaling procedures for the SRv6 SID and its associated argument via the Inclusive Multicast Ethernet Tag route (EVPN Route Type 3) and the Ethernet A-D (Auto-Discovery) per ES route (EVPN Route Type 1), respectively. However, during implementation and interoperability testing, it was observed that the specifications outlined in [RFC9252] lack sufficient detail, leading to ambiguities in interpretation and implementation.
特定のEVPNサービスについて、[RFC8986]のセクション4.12では、and.dt2m srv6エンドポイントの動作を導入しました。[RFC9252]その後、SRV6 SIDのエンコーディングおよびシグナル伝達手順と、それぞれ包括的マルチキャストイーサネットタグルート（EVPNルートタイプ3）およびESルートあたりのイーサネットA-D（Auto-Discoveryvery）（EVPN Routeタイプ1）を介して関連する引数を指定しました。ただし、実装および相互運用性テスト中に、[RFC9252]で概説されている仕様には十分な詳細がなく、解釈と実装のあいまいさにつながることが観察されました。
This document updates [RFC9252] by providing additional details and clarifications regarding the signaling of SRv6 Service SIDs associated with SRv6 Endpoint Behaviors that utilize arguments. While the focus is primarily on the signaling of the End.DT2M SRv6 Endpoint Behavior via the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route, the procedures described herein are also applicable to other similar SRv6 Endpoint Behaviors with arguments that may be signaled using BGP.
このドキュメントは、引数を利用するSRV6エンドポイント動作に関連するSRV6サービスSIDのシグナル伝達に関する追加の詳細と説明を提供することにより、[RFC9252]を更新します。焦点は主にend.dt2m srv6エンドポイントの動作に焦点を合わせていますが、ESルートごとのイーサネットA-Dおよび包括的なマルチキャストイーサネットタグルートを介したエンドポイントの動作ですが、本明細書に記載されている手順は、BGPを使用してシグナルを使用する可能性のある他のSRV6エンドポイント動作にも適用できます。
Section 6.3 of [RFC9252] specifies that the SRv6 Service SID used in the data plane is derived by applying a bitwise logical-OR operation between the SID with an argument signaled via the Ethernet A-D per ES route and the SID with the 'Locator + Function' components signaled via the Inclusive Multicast Ethernet Tag route. However, this approach assumes a uniform SID structure across all SIDs advertised via the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route. This assumption is not universally valid, and the procedures in this document remove this restriction, ensuring greater flexibility in SRv6 SID signaling.
[RFC9252]のセクション6.3は、データプレーンで使用されるSRV6サービスSIDが、SID間のビットワイズロジカルまたは操作を適用することにより導出されることを指定しています。ただし、このアプローチでは、ESルートごとのイーサネットA-Dおよび包括的なマルチキャストイーサネットタグルートを介して宣伝されているすべてのSIDにわたって均一なSID構造を想定しています。この仮定は普遍的に有効ではなく、このドキュメントの手順はこの制限を削除し、SRV6 SIDシグナリングの柔軟性を高めます。
The descriptions and examples presented in this document do not utilize the Transposition Scheme (see Section 4 of [RFC9252]). Consequently, the Transposition Offset (TPOS-O) and Transposition Length (TPOS-L) are set to zero, and references to MPLS label fields where the function or argument portions may be transposed are omitted. However, the same examples could be applied with the Transposition Scheme. This document does not introduce any modifications to the use of the Transposition Scheme in the signaling of EVPN routes. Implementations are expected to adhere to the procedures and recommendations specified in [RFC9252] concerning the Transposition Scheme.
このドキュメントに示されている説明と例は、転置スキームを利用していません（[RFC9252]のセクション4を参照）。その結果、転置オフセット（TPOS-O）および転置長（TPOS-L）はゼロに設定され、関数または引数の部分が転置される可能性のあるMPLSラベルフィールドへの参照が省略されます。ただし、転置スキームでも同じ例を適用できます。このドキュメントでは、EVPNルートのシグナル伝達に転置スキームの使用に関する変更は導入されていません。実装は、転置スキームに関して[RFC9252]で指定された手順と推奨事項を順守することが期待されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Section 3.1 of [RFC8986] defines the format of an SRv6 SID as consisting of three components: Locator (LOC), Function (FUNC), and Argument (ARG). For SRv6 SIDs associated with SRv6 Endpoint Behaviors that do not support arguments, the ARG component is not present. Consequently, all bits following the FUNC portion MUST be set to zero, and the Argument Length (AL) MUST be zero.
[RFC8986]のセクション3.1は、SRV6 SIDの形式を、ロケーター（LOC）、関数（FUNC）、および引数（ARG）の3つのコンポーネントで構成されると定義しています。引数をサポートしていないSRV6エンドポイントの動作に関連するSRV6 SIDSの場合、ARGコンポーネントは存在しません。したがって、FUNC部分に続くすべてのビットはゼロに設定する必要があり、引数の長さ（AL）はゼロでなければなりません。
Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) support arguments. As specified in Section 3.2.1 of [RFC9252], the SRv6 SID Structure Sub-Sub-TLV MUST be included when signaling an SRv6 SID corresponding to an SRv6 Endpoint Behavior that supports argument. This ensures that the receiving router can perform consistency verification of the argument and correctly encode the ARG value within the SRv6 SID.
特定のSRV6エンドポイントの動作（例：End.DT2M）が引数をサポートしています。[RFC9252]のセクション3.2.1で指定されているように、議論をサポートするSRV6エンドポイントの動作に対応するSRV6 SIDをシグナル伝えるときは、SRV6 SID構造サブサブTLVを含める必要があります。これにより、受信ルーターが引数の一貫性検証を実行し、SRV6 SID内のARG値を正しくエンコードできるようになります。
In certain use cases, the SRv6 SID can be signaled as a complete structure, with the LOC:FUNC:ARG components fully encoded within the SID. However, there are scenarios where the SRv6 SID, consisting only of the LOC:FUNC portion, is signaled in one advertisement, while the ARG value is either signaled through a separate advertisement or learned via an alternative mechanism. It is the responsibility of the SRv6 source node to append the ARG component to the LOC:FUNC portion, thereby constructing the complete SRv6 SID (LOC:FUNC:ARG). This fully formed SID can then be utilized in the data plane, either as the IPv6 destination address of a packet or as a segment within the Segment Routing Header (SRH) [RFC8754], as required.
特定のユースケースでは、SRV6 SIDは、loc：func：argコンポーネントがSID内で完全にエンコードされた完全な構造として信号を送信できます。ただし、loc：func部分のみで構成されるSRV6 SIDが1つの広告で信号を送るシナリオがありますが、arg値は別の広告を介して信号されるか、代替メカニズムを介して学習されます。SRV6ソースノードの責任は、argコンポーネントをloc：func部分に追加する責任であり、それによって完全なsrv6 sid（loc：func：arg）を構築します。この完全に形成されたSIDは、必要に応じて、パケットのIPv6宛先アドレスとして、またはセグメントルーティングヘッダー（SRH）[RFC8754]内のセグメントとしてデータプレーンで使用できます。
Since arguments may be optional, the SRv6 endpoint node that owns the SID MUST advertise the SRv6 SID Structure Sub-Sub-TLV along with the LOC:FUNC portion of the SRv6 SID to indicate whether arguments are supported for that specific SID. A zero AL value indicates that the node does not accept an argument for the given SRv6 SID. Conversely, a non-zero AL value specifies the size of the supported argument, along with the Locator Block Length (LBL), Locator Node Length (LNL), and Function Length (FL) parameters, which define the offset from which the node expects the ARG to be encoded. All bits beyond LBL + LNL + FL + AL MUST be set to zero.
引数はオプションである可能性があるため、SIDを所有するSRV6エンドポイントノードは、SRV6 SID Structure Sub-Sub-TLVとSRV6 SIDのFUNC部分を宣伝する必要があります。ゼロAL値は、ノードが指定されたSRV6 SIDの引数を受け入れないことを示します。逆に、非ゼロAL値は、ロケーターブロック長（LBL）、ロケーターノード長（LNL）、および関数長（FL）パラメーターとともに、サポートされた引数のサイズを指定します。LBL + LNL + FL + ALを超えるすべてのビットは、ゼロに設定する必要があります。
The advertisement of the ARG value may be performed either by the node that owns the SRv6 SID and is advertising the LOC:FUNC portion of that SID or by another node/mechanism. The advertisement of the ARG value MUST specify the size of the argument, its value, and the associated SRv6 Endpoint Behavior of the SID. Additionally, the specification of the association of the ARG advertisement with the corresponding SID(s) for which the argument applies is REQUIRED.
ARG値の広告は、SRV6 SIDを所有し、そのSIDのloc：FUNC部分を宣伝するノードまたは別のノード/メカニズムのいずれかによって実行される場合があります。ARG値の広告は、議論のサイズ、その値、およびSIDの関連するSRV6エンドポイントの動作を指定する必要があります。さらに、ARG広告の関連付けの仕様と、引数が適用される対応するSIDが必要です。
As specified in [RFC9252], the LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via the Inclusive Multicast Ethernet Tag route, while the Ethernet Segment Identifier (ESI) Filtering ARG (denoted as Arg.FE2 in [RFC8986]) is signaled via the Ethernet A-D per ES route. The following subsections provide a more detailed specification of the signaling and processing mechanisms compared to [RFC9252].
[rfc9252]で指定されているように、end.dt2mの動作を伴うsrv6 sidのloc：func部分は、包括的なマルチキャストイーサネットタグルートを介してシグナル伝達されますが、イーサネットセグメント識別子（ESI）フィルタリングARG（[RFC8986のarg.fe2として示されます]）次のサブセクションは、[RFC9252]と比較して、シグナルおよび処理メカニズムのより詳細な仕様を提供します。
ESI Filtering is a split-horizon mechanism used for multihoming [RFC7432] or Ethernet-Tree (E-Tree) procedures [RFC8317]. ESI Filtering is not applicable in scenarios where:
ESIフィルタリングは、マルチホミング[RFC7432]またはイーサネットツリー（E-Tree）手順[RFC8317]に使用される分割ホリゾンメカニズムです。ESIフィルタリングは、次のシナリオでは適用されません。
* No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM) traffic exists,
* E-Tree Leafの放送、不明なユニキャスト、またはマルチキャスト（Bum）トラフィックは存在しません。
* No multihoming is present,
* マルチホームは存在しません、
* No split-horizon mechanism is required, or
* スプリットホリゾンメカニズムは必要ありません
* The "Local Bias" method (as specified in [RFC8365]) is employed.
* [localバイアス]メソッド（[RFC8365]で指定）が採用されています。
In this document, "ESI Filtering" is used as a general reference to the procedure performed by the disposition Provider Edge (PE) router to prevent forwarding of BUM traffic to local Ethernet Segments or local leaf attachment circuits, based on the presence of the ESI Filtering ARG.
このドキュメントでは、「ESIフィルタリング」は、ESIフィルタリングARGの存在に基づいて、ローカルイーサネットセグメントまたはローカルリーフアタッチメントサーキットへのパムトラフィックの転送を防ぐために、気質プロバイダーエッジ（PE）ルーターによって実行される手順への一般的な参照として使用されます。
The signaling and processing descriptions outlined in the following sections also apply to End.DT2M behavior flavors designed for SRv6 SID list compression [RFC9800]. In deployments where a mix of compressed and uncompressed SIDs is present, the behaviors advertised in the Ethernet A-D per ES routes and Inclusive Multicast Ethernet Tag routes MAY consist of a combination of compressed and uncompressed End.DT2M behavior flavors. The procedures in this document remain valid for such deployments provided that the AL consistency checks between the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route, as described in the following subsections, are satisfied.
次のセクションで概説されているシグナルおよび処理の説明は、SRV6 SIDリスト圧縮[RFC9800]向けに設計されたDT2Mの動作フレーバーにも適用されます。圧縮されていないSIDの混合が存在する展開では、ESルートごとのイーサネットA-Dおよび包括的なマルチキャストイーサネットタグルートで宣伝されている動作は、圧縮と非圧縮END.DT2Mの動作フレーバーの組み合わせで構成されている場合があります。このドキュメントの手順は、以下のサブセクションで説明されているように、ESERNET A-DごとのA-Dと包括的なマルチキャストイーサネットタグルート間のAL一貫性チェックが満たされていることを条件に、そのような展開に対して有効なままです。
Ethernet A-D per ES routes, as defined in [RFC7432], are utilized to enable split-horizon filtering and fast convergence in multihoming scenarios. Additionally, Ethernet A-D per ES routes facilitate egress filtering of BUM traffic originating from a leaf, as specified in [RFC8317].
[RFC7432]で定義されているように、ESルートごとのイーサネットA-Dは、マルチホームシナリオでスプリットホリゾンフィルタリングと高速収束を可能にするために使用されます。さらに、ESルートあたりのイーサネットA-Dは、[RFC8317]で指定されているように、葉に由来するバムトラフィックの出力フィルタリングを容易にします。
When ESI Filtering is not in use, no ESI Filtering ARG is required to be conveyed. However, for backward compatibility and consistency with [RFC9252], the advertisement of this route SHOULD include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV carrying an SRv6 Service SID set to ::0 in the SRv6 SID Information Sub-TLV, with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLV MUST be included. As no ARG value is required to be signaled in this case, the AL MUST be set to 0.
ESIフィルタリングが使用されていない場合、ESIフィルタリングARGを伝える必要はありません。ただし、[RFC9252]との後方互換性と一貫性のために、このルートの広告には、SRV6 SID Information Sub-TLVに設定されたSRV6 SID SID SID SIDを運ぶSRV6 L2サービスTLVを備えたBGPプレフィックスSID属性を含める必要があります。end.DT2Mの動作はARGの使用をサポートするため、SRV6 SID構造サブサブ-TLVを含める必要があります。この場合、ALは0に設定する必要があるため、ARG値を合図する必要はありません。
The following is an example representation of the BGP Prefix-SID attribute encoding in this case:
以下は、この場合にエンコードするBGPプレフィックス-SID属性の表現の例です。
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: ::
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
Figure 1: Ethernet A-D per ES Route Without ARG for ESI Filtering
図1：ESIフィルタリングのためのARGなしのETHERNET A-Dルートごと
When ESI Filtering is in use, the advertisement of this route MUST include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV carrying the SRv6 Service SID that contains the ESI Filtering ARG value within the SRv6 SID Information Sub-TLV (when not using the Transposition Scheme), with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLV MUST be included. Additionally, as a non-zero ARG value is being signaled, the AL MUST be set to the size of the ARG, and the size SHOULD be a multiple of 8 to ensure consistency across implementations for ease of operations. The SRv6 SID Structure Sub-Sub-TLV MUST set the LBL, LNL, and FL fields with values that indicate the offset at which the ARG value is encoded within the 128-bit SRv6 SID.
ESIフィルタリングが使用されている場合、このルートの広告には、SRV6 SID Information Sub-TLV内のESIフィルタリングのARG値を含むSRV6サービスSIDを運ぶSRV6 L2サービスTLVを備えたBGPプレフィックス-SID属性を含める必要があります（転置スキームを使用しない場合）、SRV6エンドポイント動作を終了します。end.DT2Mの動作はARGの使用をサポートするため、SRV6 SID構造サブサブ-TLVを含める必要があります。さらに、ゼロ以外のARG値が通知されているため、ALはARGのサイズに設定する必要があり、操作を容易にするために実装全体で一貫性を確保するためにサイズは8の倍数でなければなりません。SRV6 SID構造サブサブ-TLVは、LBL、LNL、およびFLフィールドを設定する必要があり、128ビットSRV6 SID内でARG値がエンコードされるオフセットを示す値を示しています。
The following is an example representation of the BGP Prefix-SID attribute encoding in this scenario for a 16-bit argument value of 'aaaa':
以下は、「AAAA」の16ビット引数値のこのシナリオでエンコードするBGPプレフィックス-SID属性の表現の例です。
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: ::aaaa:0:0:0
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
Figure 2: Ethernet A-D per ES Route with ARG for ESI Filtering
図2：ESIフィルタリング用のARGを使用したETHERNET A-D RORTE
In the examples above, it would have been possible to set the LBL, LNL, and FL values to 0 and to encode the SRv6 SID as either ::0 or aaaa::. However, such an encoding would not be backward compatible with [RFC9252], as further detailed in Section 4.
上記の例では、LBL、LNL、およびFLの値を0に設定し、SRV6SIDを:: 0またはAAAA ::のいずれかとしてエンコードすることが可能でした。ただし、セクション4でさらに詳述しているように、このようなエンコーディングは[RFC9252]との後方互換性がありません。
Therefore, it is REQUIRED that the LBL, LNL, and FL values be set in accordance with the SID structure for End.DT2M SRv6 Service SIDs, ensuring compliance with [RFC9252].
したがって、LBL、LNL、およびFLの値は、END.DT2M SRV6サービスSIDSのSID構造に従って設定し、[RFC9252]のコンプライアンスを確保する必要があります。
The Inclusive Multicast Ethernet Tag route, as defined in [RFC7432], is used to advertise multicast traffic reachability information via Multiprotocol BGP (MP-BGP) to all other PE routers within a given EVPN instance. When utilizing SRv6 transport, the advertisement of this route MUST include the BGP Prefix-SID attribute with an SRv6 L2 Service TLV to indicate the use of SRv6.
[RFC7432]で定義されている包括的なマルチキャストイーサネットタグルートは、マルチプロトコルBGP（MP-BGP）を介して特定のEVPNインスタンス内の他のすべてのPEルーターにマルチキャストトラフィックリーチビリティ情報を宣伝するために使用されます。SRV6トランスポートを使用する場合、このルートの広告には、SRV6 L2サービスTLVを備えたBGPプレフィックス-SID属性をSRV6の使用を示す必要があります。
Regardless of whether ESI Filtering is in use, the SRv6 Service SID MUST include only the LOC:FUNC portion within the SRv6 SID Information Sub-TLV (when not utilizing the Transposition Scheme), with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure Sub-Sub-TLV MUST be included. The LBL, LNL, and FL fields MUST be set to indicate the structure of the SRv6 Service SID being advertised.
ESIフィルタリングが使用されているかどうかに関係なく、SRV6サービスSIDには、SRV6 Endpointの動作がend.DT2Mに設定されているSRV6 SID Information Sub-TLV内のLOC：FUNC部分（転置スキームを使用していない場合）のみを含める必要があります。end.DT2Mの動作はARGの使用をサポートするため、SRV6 SID構造サブサブ-TLVを含める必要があります。LBL、LNL、およびFLフィールドは、宣伝されているSRV6サービスSIDの構造を示すように設定する必要があります。
When ESI Filtering is not in use, no ARG is expected to be received by the router along with the advertised SRv6 Service SID. Therefore, the AL MUST be set to 0.
ESIフィルタリングが使用されていない場合、広告されたSRV6サービスSIDとともに、ルーターによってARGが受信されることは予想されません。したがって、ALは0に設定する必要があります。
The following is an example representation of the BGP Prefix-SID attribute encoding in this case:
以下は、この場合にエンコードするBGPプレフィックス-SID属性の表現の例です。
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: 2001:db8:1:fbd1::
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0
Figure 3: Inclusive Multicast Ethernet Tag Route Without ESI Filtering
図3：ESIフィルタリングなしの包括的なマルチキャストイーサネットタグルート
When ESI Filtering is in use, the router expects to receive traffic in the data path to the SRv6 Service SID that it has signaled along with the ARG portion embedded in it. Consequently, the AL MUST be set to the size of the ARG supported by the advertising router for the specific SRv6 Service SID. The AL value is unique per End.DT2M behavior signaled by the egress PE. Therefore, the egress PE MUST use the same AL for all local Ethernet Segments with attachment circuits within the same broadcast domain.
ESIフィルタリングが使用されている場合、ルーターは、SRV6サービスSIDへのデータパスでトラフィックを受け取ることを期待しており、それが埋め込まれたARG部分とともに合図しました。その結果、ALは、特定のSRV6サービスSIDの広告ルーターによってサポートされているARGのサイズに設定する必要があります。AL値は、End.DT2Mの動作ごとに一意です。したがって、出口PEは、同じブロードキャストドメイン内にアタッチメント回路を備えたすべてのローカルイーサネットセグメントに同じALを使用する必要があります。
The following is an example representation of the BGP Prefix-SID attribute encoding for this scenario with a 16-bit argument:
以下は、16ビットの引数を使用して、このシナリオのBGPプレフィックス-SID属性エンコードの表現の例です。
BGP Prefix-SID attribute:
SRv6 L2 Service TLV:
SRv6 SID Information Sub-TLV:
SID: 2001:db8:1:fbd1::
Behavior: End.DT2M
SRv6 SID Structure Sub-Sub-TLV:
LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0
Figure 4: Inclusive Multicast Ethernet Tag Route with ESI Filtering
図4：ESIフィルタリングを備えた包括的なマルチキャストイーサネットタグルート
When ESI Filtering is in use, the advertising router MUST ensure that the AL signaled in the Inclusive Multicast Ethernet Tag route is equal to the AL signaled in the corresponding Ethernet A-D per ES route.
ESIフィルタリングが使用されている場合、広告ルーターは、包括的なマルチキャストイーサネットタグルートでALが対応するイーサネットA-DでのALに等しいことを確認する必要があります。
An ingress PE receives the LOC:FUNC portion of the SRv6 Service SID to be used for BUM traffic through Inclusive Multicast Ethernet Tag route advertisements.
Ingress PEは、包括的なマルチキャストイーサネットタグルート広告を介してバムトラフィックに使用されるSRV6サービスSIDのLOC：FUNC部分を受け取ります。
When ESI Filtering is not in use, the SRv6 Service SID to be used consists solely of the LOC:FUNC portion received via the Inclusive Multicast Ethernet Tag route.
ESIフィルタリングが使用されていない場合、使用されるSRV6サービスSIDは、包括的マルチキャストイーサネットタグルートを介して受信したLOC：FUNC部分のみで構成されています。
When ESI Filtering is in use, the ESI Filtering ARG of the SRv6 Service SID is signaled through the Ethernet A-D per ES route. The ARG, in combination with the LOC:FUNC portion received via the Inclusive Multicast Ethernet Tag route, forms the SRv6 Service SID to be used.
ESIフィルタリングが使用されている場合、SRV6サービスSIDのESIフィルタリングARGは、ESルートごとにイーサネットA-Dを介して通知されます。ARGは、包括的マルチキャストイーサネットタグルートを介して受信したLOC：FUNC部分と組み合わせて、使用するSRV6サービスSIDを形成します。
Since the LOC:FUNC and ARG portions of the SRv6 Service SID are signaled via different route advertisements, there may be cases where the ingress PE receives inconsistent AL values from the two route types. If the ingress PE expects ESI Filtering to be in use (i.e., when forwarding BUM traffic to other PEs attached to a shared Ethernet Segment) but does not receive a usable ARG value during processing, it SHOULD log a message to facilitate troubleshooting.
SRV6サービスSIDのloc：funcおよびarg部分は、異なるルート広告を介して通知されるため、イングレスPEが2つのルートタイプから一貫性のないAL値を受信する場合があります。Ingress PEがESIフィルタリングが使用されることを期待している場合（つまり、共有イーサネットセグメントに接続された他のPESにバムトラフィックを転送するとき）、処理中に使用可能なARG値を受け取らない場合、メッセージをログにしてトラブルシューティングを促進する必要があります。
The ingress PE router MUST follow the processing steps outlined below when handling SRv6 Service SID advertisements:
SRV6サービスSID広告を処理する際には、以下の処理手順に従う必要があります。
1. If AL=0 is signaled via the Inclusive Multicast Ethernet Tag route, then the egress PE either does not support ESI Filtering or does not require an ESI Filtering ARG for the specific SID. In this case, the SRv6 Service SID is formed using only the LOC:FUNC portion, and all bits after LBL + LNL + FL MUST be set to zero for encoding on the data path. Additionally, the router MUST ignore the SID value and its SID structure advertised in the corresponding Ethernet A-D per ES route.
1. Al = 0が包括的マルチキャストイーサネットタグルートを介して信号を送信した場合、Egress PEはESIフィルタリングをサポートしないか、特定のSIDのESIフィルタリングARGを必要としません。この場合、SRV6サービスSIDはLOC：FUNC部分のみを使用して形成され、LBL + LNL + FLの後のすべてのビットは、データパスでエンコードするためにゼロに設定する必要があります。さらに、ルーターは、対応するイーサネットa-Dあたりのルートで宣伝されているSID値とそのSID構造を無視する必要があります。
2. If a non-zero AL is signaled via the Inclusive Multicast Ethernet Tag route, then the matching Ethernet A-D per ES route for the Ethernet Segment is located and the presence of an SRv6 SID advertisement with the End.DT2M behavior is verified.
2. ゼロ以外のALが包括的マルチキャストイーサネットタグルートを介して信号が表示される場合、イーサネットセグメントの一致するイーサネットA-Dルートが配置され、end.DT2Mの動作を備えたSRV6 SID広告の存在が検証されます。
a. If the presence of such a SRv6 SID is not verified, or if the AL is zero in the Ethernet A-D per ES route, then no usable ARG value is available. The SRv6 Service SID MUST be formed as described in (1) above.
a. そのようなSRV6 SIDの存在が検証されていない場合、またはALがESルートごとにイーサネットA-Dでゼロである場合、使用可能なARG値は利用できません。上記の（1）に記載されているように、SRV6サービスSIDを形成する必要があります。
b. If the AL values in the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route are both non-zero but not equal, then no usable ARG value is available. This inconsistency in signaling from the egress PE indicates a configuration error. To prevent potential looping, BUM traffic MUST NOT be forwarded for such routes from the specific Ethernet Segment. Implementations SHOULD log an error message for troubleshooting this condition.
b. イーサネットA-Dあたりのルートと包括的なマルチキャストイーサネットタグルートのAL値が両方ともゼロではないが等しくない場合、使用可能なarg値は利用できません。出口PEからのシグナリングのこの矛盾は、構成エラーを示します。潜在的なループを防ぐために、特定のイーサネットセグメントからそのようなルートのために、バムトラフィックを転送してはなりません。実装は、この条件のトラブルシューティングのためのエラーメッセージを記録する必要があります。
c. If the AL values in the Ethernet A-D per ES route and Inclusive Multicast Ethernet Tag route are both non-zero and equal, then the ARG value from the Ethernet A-D per ES route is considered valid. This ARG value MUST be encoded within the SRv6 SID (LOC:FUNC) at the ARG offset as specified in the SID structure (i.e., LBL + LNL + FL) in the Inclusive Multicast Ethernet Tag route. All bits beyond LBL + LNL + FL + AL MUST be set to zero.
c. イーサネットA-Dあたりのルートと包括的なマルチキャストイーサネットタグルートのAL値がゼロ以外と等しい場合、ESルートごとのイーサネットA-DのARG値は有効と見なされます。このARG値は、包括的なマルチキャストイーサネットタグルートのSID構造（つまり、LBL + LNL + FL）で指定されているように、ARGオフセットのSRV6 SID（LOC：FUNC）内でエンコードする必要があります。LBL + LNL + FL + ALを超えるすべてのビットは、ゼロに設定する必要があります。
Using the procedures above with the examples in Figures 1 and 3, the SRv6 Service SID encoding for the data plane without an ESI Filtering ARG is as follows:
図1および3の例で上記の手順を使用して、ESIフィルタリングARGを使用せずにデータプレーンにエンコードするSRV6サービスSIDは次のとおりです。
Inclusive Multicast Ethernet Tag route:
SID: 2001:db8:1:fbd1::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 0
SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1::
Figure 5: SRv6 Service SID Encoding for Data Plane Without ARG
図5：SRV6サービスSIDは、ARGなしでデータプレーンのエンコード
Using the procedures above with the examples in Figures 2 and 4, the SRv6 Service SID encoding for the data plane along with an ESI Filtering ARG is as follows:
図2および4の例で上記の手順を使用して、データプレーン用のSRV6サービスSIDとESIフィルタリングARGのエンコードは次のとおりです。
Ethernet A-D per ES route:
SID: ::aaaa:0:0:0
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Inclusive Multicast Ethernet Tag route:
SID: 2001:db8:1:fbd1::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
SRv6 Service SID Encoded for Datapath: 2001:db8:1:fbd1:aaaa::
Figure 6: SRv6 Service SID Encoding for Data Plane with ARG
図6：SRV6サービスSID ARGを使用したデータプレーンのエンコード
Figure 7 provides another example that illustrates the signaling and processing of multiple bridge domains in a deployment design.
図7は、展開設計における複数のブリッジドメインのシグナルと処理を示す別の例を示しています。
+--------------------------------+
| |
PE1 | |
+---------+ |
BUM on BD1 | +-----+ | |
+----------------> | BD1 |-------------+ |
| | +-----+ | | |
| BUM on BD2 | +-----+ | v PE3 |
| +--------------> | BD2 |-------+ +---------+
| | +-----| +-----+ | | | +-----+ |
+----+ | +---------+ v ^ | | BD1 |-----CE31
| | | | | | +-----+ |
|CE12|-----+ ESI-1 | ^ | | +-----+ |
| |-----+ | | | | | BD2 |-----CE32
+----+ | +---------+ ^ RT3 RT3 | +-----+ |
+-----| +-----+ | | dt2m dt2m +---------+
| | BD1 | | | BD2 BD1 |
| +-----+ | | FL:16 FL:32 |
| +-----+ | RT1 |
| | BD2 | | ESI-1 |
| +-----+ | AL:16 |
+---------+ |
PE2 | |
| |
| |
+-------------------------------+
Ethernet A-D per ES route for ESI-1:
SID: ::aaaa:0:0:0
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
Inclusive Multicast Ethernet Tag route from BD1:
SID: 2001:db8:1:fbd1:fbd1:
Structure: LBL: 32, LNL: 16, FL: 32, AL: 16
Inclusive Multicast Ethernet Tag route from BD2:
SID: 2001:db8:1:fbd2::
Structure: LBL: 32, LNL: 16, FL: 16, AL: 16
SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD1:
2001:db8:1:fbd1:fbd1:aaaa::
SRv6 Service SID for datapath from ingress PE1 to egress PE2 on BD2:
2001:db8:1:fbd2:aaaa::
Figure 7: Example with Multiple Bridge Domains
図7：複数のブリッジドメインを備えた例
Existing implementations that rely on the bitwise logical-OR operation, as specified in Section 6.3 of [RFC9252], function correctly only when the SID structures of the two EVPN route types are identical.
[RFC9252]のセクション6.3で指定されているように、ビットワイズの論理または操作に依存する既存の実装は、2つのEVPNルートタイプのSID構造が同一の場合にのみ正しく機能します。
Backward compatibility with implementations performing the bitwise logical-OR operation is maintained when the Inclusive Multicast Ethernet Tag route and its corresponding Ethernet A-D per ES route advertise SIDs with the same SID structure, as outlined in Sections 3.1 and 3.2.
ビットワイズの論理または操作を実行する実装との逆方向の互換性は、包括的なマルチキャストイーサネットタグルートとその対応するイーサネットA-Dがセクション3.1および3.2で概説したように、同じSID構造を持つSIDを宣伝するときに維持されます。
However, when the SID structures of the two route types are not identical, the bitwise logical-OR operation specified in [RFC9252] cannot be applied. Instead, the alternative method specified in Section 3.3 MUST be used to correctly derive the SRv6 Service SID in such cases.
ただし、2つのルートタイプのSID構造が同一でない場合、[RFC9252]で指定されているビットワイズの論理または操作を適用できません。代わりに、セクション3.3で指定された代替方法を使用して、そのような場合にSRV6サービスSIDを正しく導出する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document provides a more detailed specification related to the signaling and processing of SRv6 SID advertisements for SRv6 Endpoint Behaviors with arguments. As such, it does not introduce any new security considerations over and above those already covered by [RFC9252].
このドキュメントは、SRV6エンドポイントの動作のSRV6 SID広告のシグナルと処理に関連するより詳細な仕様を、引数を提供します。そのため、[RFC9252]で既にカバーされているもの以上の新しいセキュリティ上の考慮事項は導入されていません。
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[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>.
[RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding",
RFC 9800, DOI 10.17487/RFC9800, June 2025,
<https://www.rfc-editor.org/info/rfc9800>.
The authors would like to acknowledge Jayshree Subramanian, Sonal Agarwal, Swadesh Agrawal, Dongling Duan, Luc André Burdet, Patrice Brissette, Senthil Sathappan, Erel Ortacdag, Neil Hart, Will Lockhart, and Vinod Prabhu for their review of the document and input on aspects related to the signaling of the End.DT2M SRv6 Endpoint Behavior that required clarification. The authors thank Jeffrey Zhang for his shepherd review and suggestions for improving the document. The authors would also like to thank Gunter Van de Velde for his extensive review and suggestions for improving the readability of the document.
著者は、Jayshree Subramanian、Sonal Agarwal、Swadesh Agrawal、Dongling Duan、LucAndréBurdet、Patrice Brissette、Senthil Sathappan、Erel Ortacdag、Neil Hart、Will Lockhart、およびVinod Prabhuのエンドのレビューのレビューのレビューのレビューのために、Vinod Prabhuを認めたいと思います。明確化を必要とする行動。著者は、ジェフリー・チャンが彼の羊飼いのレビューと文書を改善するための提案に感謝します。著者はまた、Gunter Van de Veldeに、ドキュメントの読みやすさを改善するための彼の広範なレビューと提案に感謝したいと思います。
Ketan Talaulikar
Cisco Systems
India
Email: ketant.ietf@gmail.com
Kamran Raza
Cisco Systems
Canada
Email: skraza@cisco.com
Jorge Rabadan
Nokia
United States of America
Email: jorge.rabadan@nokia.com
Wen Lin
Juniper Networks
United States of America
Email: wlin@juniper.net