Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9746 K. Nagaraj
Updates: 7432, 8365 Nokia
Category: Standards Track W. Lin
ISSN: 2070-1721 Juniper
A. Sajassi
Cisco
March 2025
An Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels as well as with MPLS and Segment Routing (SR) tunnels. The multihoming procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multihoming split-horizon procedures designed to prevent looped frames on multihomed Customer Edge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based procedure and the local-bias procedure. The ESI Label-based split-horizon procedure is applied to MPLS-based tunnels such as MPLS over UDP (MPLSoUDP), while the local-bias procedure is used for other tunnels such as Virtual eXtensible Local Area Network (VXLAN) tunnels.
イーサネット仮想プライベートネットワーク（EVPN）は、ネットワーク仮想化オーバーレイ（NVO）トンネルと、MPLSおよびセグメントルーティング（SR）トンネルで一般的に使用されます。EVPNのマルチホーム手順は、EVPNブロードキャストドメイン内で使用されるトンネルのタイプによって異なる場合があります。具体的には、マルチホームの顧客エッジ（CE）デバイスのループフレームを防ぐために設計された2つのマルチホームスプリットホリゾン手順があります。イーサネットセグメント識別子（ESI）ラベルベースの手順とローカルBIAS手順。ESIラベルベースのスプリットホリゾン手順は、UDP（MPLSOUDP）を介したMPLSなどのMPLSベースのトンネルに適用されますが、ローカルBIAS手順は、仮想拡張可能なローカルエリアネットワーク（VXLAN）トンネルなどの他のトンネルに使用されます。
Current specifications do not allow operators to choose which split-horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network Virtualization Encapsulation (Geneve), and Segment Routing over IPv6 (SRv6) tunnels. This document updates the EVPN multihoming procedures described in RFCs 7432 and 8365, enabling operators to select the split-horizon procedure that meets their specific requirements.
現在の仕様では、オペレーターが両方の方法をサポートするトンネルカプセルに使用するスプリットホリゾン手順を選択することはできません。両方の手順をサポートする可能性のあるトンネルの例には、Mplsoudp、GRE（Mplsogre）介したMPLS、ジェネリックネットワーク仮想化カプセル化（GeneVe）、およびIPv6（SRV6）トンネルのセグメントルーティングが含まれます。このドキュメントでは、RFCS 7432および8365で説明されているEVPNマルチホーム手順を更新し、オペレーターが特定の要件を満たすスプリットホリゾン手順を選択できるようにします。
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/rfc9746.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9746で取得できます。
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. Conventions and Terminology
1.2. Split-Horizon Filtering and Tunnel Encapsulations
2. BGP EVPN Extensions
2.1. The Split-Horizon Type
2.2. Use of the Split-Horizon Type in A-D per ES Routes
2.3. The ESI Label Value in A-D per ES Routes
2.4. Backwards Compatibility with NVEs from RFC 8365
3. Procedures for NVEs Supporting Multiple Encapsulations
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
Ethernet Virtual Private Networks (EVPNs) are commonly used with the following tunnel encapsulations:
イーサネット仮想プライベートネットワーク（EVPN）は、一般的に次のトンネルカプセルで使用されます。
* Network Virtualization Overlay (NVO) tunnels, where the EVPN procedures are specified in [RFC8365]. MPLSoGRE [RFC4023], MPLSoUDP [RFC7510], Geneve [RFC8926], or VXLAN [RFC7348] tunnels are considered NVO tunnels.
* ネットワーク仮想化オーバーレイ（NVO）トンネル。EVPN手順は[RFC8365]で指定されています。mplsogre [rfc4023]、mplsoudp [rfc7510]、geneve [rfc8926]、またはvxlan [rfc7348]トンネルはNvoトンネルと見なされます。
* MPLS and Segment Routing over MPLS (SR-MPLS) tunnels, where the relevant EVPN procedures are specified in [RFC7432]. SR-MPLS tunneling is specified in [RFC8660].
* MPLSおよびセグメントルーティングは、MPLS（SR-MPLS）トンネルを介して、[RFC7432]で関連するEVPN手順が指定されています。SR-MPLSトンネルは[RFC8660]で指定されています。
* Segment Routing over IPv6 (SRv6) tunnels, where the relevant EVPN procedures are specified in [RFC9252]. SRv6 is specified in [RFC8402] and [RFC8754].
* IPv6（SRV6）トンネルのセグメントルーティング。関連するEVPN手順は[RFC9252]で指定されています。SRV6は[RFC8402]および[RFC8754]で指定されています。
In this document, the term "split horizon" follows the definition in [RFC7432]. Split horizon refers to the EVPN multihoming procedure that prevents a Provider Edge (PE) from sending a frame back to a multihomed Customer Edge (CE) when that CE originated the frame in the first place.
このドキュメントでは、[RFC7432]の定義に従います。Split Horizonとは、CEが最初にフレームを発信したときに、プロバイダーエッジ（PE）がフレームをマルチホームの顧客エッジ（CE）に送信するのを防ぐEVPNマルチホーム手順を指します。
EVPN multihoming procedures may vary depending on the type of tunnel utilized within the EVPN Broadcast Domain. Specifically, there are two multihoming split-horizon procedures employed to prevent looped frames on multihomed CE devices: the ESI Label-based procedure and the local-bias procedure.
EVPNマルチホーム手順は、EVPNブロードキャストドメイン内で使用されるトンネルのタイプによって異なる場合があります。具体的には、Multihomed CEデバイスのループフレームを防ぐために採用されている2つのマルチホームスプリットホリゾン手順があります：ESIラベルベースの手順とローカルBias手順。
The ESI Label-based split-horizon procedure is used for MPLS or MPLS over X (MPLSoX) tunnels, such as MPLSoUDP, and its procedures are detailed in [RFC7432]. Conversely, the local-bias procedure is used for IP-based tunnels, such as VXLAN tunnels, and it is described in [RFC8365].
ESIラベルベースのスプリットホリゾン手順は、MPLSOUDPなどのX（MPLSOX）トンネルを介したMPLSまたはMPLSに使用され、その手順については[RFC7432]で詳しく説明しています。逆に、局所Bias手順は、VXLANトンネルなどのIPベースのトンネルに使用され、[RFC8365]に記載されています。
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] で説明されているように解釈されます。
AC:
AC:
Attachment Circuit
アタッチメント回路
A-D per ES route:
a-d s esルート：
Auto-Discovery per Ethernet Segment route (as defined in [RFC7432]).
イーサネットセグメントルートごとの自動発見（[RFC7432]で定義されています）。
Arg.FE2:
arg.fe2：
Refers to the ESI filtering argument used for split horizon as specified in [RFC9252].
[RFC9252]で指定されているように、スプリットホライズンに使用されるESIフィルタリング引数を指します。
BD:
BD:
Broadcast Domain. Refers to an emulated Ethernet, such that two systems on the same BD will receive each other's BUM traffic. In this document, BD also refers to the instantiation of a BD on an EVPN PE. An EVPN PE can be attached to one or multiple BDs of the same tenant.
ブロードキャストドメイン。同じBD上の2つのシステムが互いの尻のトラフィックを受け取るように、エミュレートされたイーサネットを指します。このドキュメントでは、BDはEVPN PE上のBDのインスタンス化についても指します。EVPN PEは、同じテナントの1つまたは複数のBDに接続できます。
BUM:
BUM:
Broadcast, Unknown Unicast, and Multicast
ブロードキャスト、不明なユニキャスト、マルチキャスト
CE:
CE:
Customer Edge
顧客のエッジ
DF:
DF:
Designated Forwarder. As defined in [RFC7432], an ES may be multihomed (attached to more than one PE). An ES may also contain multiple BDs of one or more EVIs. For each such EVI, one of the PEs attached to the segment becomes that EVI's DF for that segment. Since a BD may belong to only one EVI, we can speak unambiguously of the BD's DF for a given segment.
指定されたフォワーダー。[RFC7432]で定義されているように、ESはマルチホームになっている可能性があります（複数のPEに取り付けられています）。ESには、1つ以上のEVIの複数のBDが含まれる場合があります。そのようなEVIそれぞれについて、セグメントに接続されたPEの1つは、そのセグメントのEVIのDFになります。BDは1つのEVIのみに属する可能性があるため、特定のセグメントについてBDのDFを明確に話すことができます。
ES:
ES:
Ethernet Segment
イーサネットセグメント
ESI:
ESI:
Ethernet Segment Identifier
イーサネットセグメント識別子
EVI:
EVI:
EVPN Instance
EVPNインスタンス
EVI-RT:
EVI-RT：
EVI Route Target. Refers to a group of NVEs attached to the same EVI that will share the same EVI-RT.
EVIルートターゲット。同じEVI-RTを共有する同じEVIに取り付けられたNVEのグループを指します。
Geneve:
Geneve：
Generic Network Virtualization Encapsulation [RFC8926] (see tunnel type 19 in [TUNNEL-ENCAP]).
ジェネリックネットワーク仮想化カプセル化[RFC8926]（[トンネルエンコップ]のトンネルタイプ19を参照）。
MPLS tunnels and non-MPLS NVO tunnels:
MPLSトンネルと非MPLS NVOトンネル：
Refers to Multiprotocol Label Switching (or the absence of it) Network Virtualization Overlay tunnels. NVO tunnels use an IP encapsulation for overlay frames, where the source IP address identifies the ingress NVE and the destination IP address identifies the egress NVE.
マルチプロトコルラベルスイッチング（またはITの欠如）ネットワーク仮想化オーバーレイトンネルを指します。NVOトンネルは、オーバーレイフレームにIPカプセル化を使用します。ソースIPアドレスは、イングレスNVEを識別し、宛先IPアドレスが出口NVEを識別します。
MPLSoUDP:
mplsoudp：
Multiprotocol Label Switching over User Datagram Protocol [RFC7510] (see tunnel type 13 in [TUNNEL-ENCAP]).
ユーザーデータグラムプロトコル[RFC7510]を介したマルチプロトコルラベルスイッチング（[トンネルエンコップ]のトンネルタイプ13を参照）。
MPLSoGRE:
mplsogre：
Multiprotocol Label Switching over Generic Network Encapsulation [RFC4023] (see tunnel type 11 in [TUNNEL-ENCAP]).
ジェネリックネットワークカプセル化[RFC4023]のマルチプロトコルラベルスイッチング（[トンネルエンコップ]のトンネルタイプ11を参照）。
MPLSoX:
mplsox：
Refers to MPLS over any IP encapsulation, for example, MPLSoUDP or MPLSoGRE.
mplsoudpやmplsogreなど、IPカプセル化のMPLSを指します。
NVE:
NVE:
Network Virtualization Edge
ネットワーク仮想化エッジ
NVGRE:
nvgre：
Network Virtualization Using Generic Routing Encapsulation [RFC7637] (see tunnel type 9 in [TUNNEL-ENCAP]).
汎用ルーティングカプセル化[RFC7637]を使用したネットワーク仮想化（[トンネルエンコップ]のトンネルタイプ9を参照）。
PE:
PE:
Provider Edge
プロバイダーエッジ
RTs:
RTs:
Route Targets
ルートターゲット
VXLAN:
vxlan：
Virtual eXtensible Local Area Network [RFC7348] (see tunnel type 8 in [TUNNEL-ENCAP]).
仮想拡張可能なローカルエリアネットワーク[RFC7348]（[トンネルエンコップ]のトンネルタイプ8を参照）。
VXLAN-GPE:
vxlan-gpe：
VXLAN Generic Protocol Extension [VXLAN-GPE] (see tunnel type 12 in [TUNNEL-ENCAP]).
VXLANジェネリックプロトコル拡張[VXLAN-GPE]（[トンネルエンコップ]のトンネルタイプ12を参照）。
SHT:
SHT:
Split-Horizon Type. Refers to the split-horizon method that a PE intends to use and advertises in an A-D per ES route.
スプリットホリゾンタイプ。PEがA-d Per Routeで使用および宣伝することを目的としたスプリットホリゾン法を指します。
SRv6:
SRV6：
Segment Routing over IPv6 (see [RFC8402] and [RFC8754]).
IPv6を介したセグメントルーティング（[RFC8402]および[RFC8754]を参照）。
TLV:
TLV:
Type-Length-Value
タイプ長価値
This document also assumes familiarity with the terminology of [RFC7432] and [RFC8365].
この文書は、[RFC7432]および[RFC8365]の用語に精通していることも想定しています。
EVPN supports two split-horizon filtering mechanisms:
EVPNは、2つのスプリットホリゾンフィルタリングメカニズムをサポートしています。
1. ESI Label-based split-horizon filtering [RFC7432]:
1. ESIラベルベースのスプリットホリゾンフィルタリング[RFC7432]：
When EVPN is employed for MPLS transport tunnels, an MPLS label facilitates split-horizon filtering to support All-Active multihoming. The ingress NVE device appends a label corresponding to the source ESI (the ESI label) during packet encapsulation. The egress NVE verifies the ESI label when attempting to forward a multi-destination frame through a local ES interface. If the ESI label matches the site identifier (the ESI) associated with that ES interface, then the packet is not forwarded. This mechanism effectively prevents forwarding loops for BUM traffic.
EVPNがMPLS輸送トンネルに使用される場合、MPLSラベルは、すべての活性マルチホームをサポートするためにスプリットホリゾンフィルタリングを促進します。Ingress NVEデバイスは、パケットカプセル化中にソースESI（ESIラベル）に対応するラベルを追加します。出力NVEは、ローカルESインターフェイスを介して多降りフレームを転送しようとするときにESIラベルを検証します。ESIラベルがそのESインターフェイスに関連付けられたサイト識別子（ESI）と一致する場合、パケットは転送されません。このメカニズムは、バムトラフィックの転送ループを効果的に防ぎます。
ESI Label split-horizon filtering should also be utilized with Single-Active multihoming to prevent transient loops for in-flight packets when the egress NVE assumes the role of DF for an ES.
ESIラベルスプリットホリゾンフィルタリングは、EGRESS NVEがESのDFの役割を想定している場合、飛行中のパケットの過渡ループを防ぐために、単一活性マルチホームで使用する必要があります。
2. Local-bias filtering [RFC8365]:
2. ローカルバイアスフィルタリング[RFC8365]：
Since IP tunnels such as VXLAN or NVGRE do not support the ESI label or any MPLS label, an alternative split-horizon filtering procedure must be implemented for All-Active multihoming. This mechanism, known as local bias, relies on the source IP address of the tunnel to determine whether to forward BUM traffic to a local ES interface at the egress NVE.
VXLANやNVGREなどのIPトンネルはESIラベルまたはMPLSラベルをサポートしていないため、オールアクティブなマルチホームのために、代替のスプリットホリゾンフィルタリング手順を実装する必要があります。ローカルバイアスとして知られているこのメカニズムは、トンネルのソースIPアドレスに依存して、Egress NVEのローカルESインターフェイスにバムトラフィックを転送するかどうかを判断します。
In summary and as specified in [RFC8365], each NVE tracks the IP address(es) of other NVEs with which it shares multihomed ESs. Upon receiving a BUM frame encapsulated in an IP tunnel, the egress NVE inspects the source IP address in the tunnel header, which identifies the ingress NVE. The egress NVE then filters out the frame on all local interfaces connected to ESs that are shared with the ingress NVE.
要約および[RFC8365]で指定されているように、各nveは、マルチホームのESSを共有する他のNVEのIPアドレス（ES）を追跡します。IPトンネルにカプセル化されたバムフレームを受信すると、Egress NVEは、イングレスNVEを識別するトンネルヘッダーのソースIPアドレスを検査します。次に、出口NVEは、イングレスNVEと共有されるESSに接続されたすべてのローカルインターフェイス上のフレームを除外します。
Due to this behavior at the egress NVE, the ingress NVE is required to perform local replication to all directly attached ESs, regardless of the DF election state, for all BUM traffic ingressing from the access ACs. This local replication at the ingress NVE is the basis for the term "local bias".
出口NVEでのこの動作により、イングレスNVEは、アクセスACSから侵入するすべてのBUMトラフィックに対して、DF選挙状態に関係なく、直接接続されたすべてのESSにローカルレプリケーションを実行する必要があります。イングレスNVEでのこのローカルレプリケーションは、「ローカルバイアス」という用語の基礎です。
Local bias is not suitable for Single-Active multihoming, as the ingress NVE deactivates the ACs for which it is not the DF. Consequently, local replication to non-DF ACs cannot occur, leading to transient in-flight BUM packets being looped back to the originating site by newly elected DF egress NVEs.
イングレスNVEはDFではないACSを無効にするため、ローカルバイアスは単一活性マルチホームには適していません。したがって、非DF ACSへのローカルレプリケーションは発生できず、新たに選出されたDF出力NVEによって、一時的な飛行中のバムパケットが元のサイトにループされます。
[RFC8365] specifies that local bias is exclusively utilized for IP tunnels, while ESI Label-based split horizon is employed for IP-based MPLS tunnels. However, IP-based MPLS tunnels such as MPLSoGRE or MPLSoUDP are also categorized as IP tunnels and have the potential to support both procedures. These tunnels are capable of carrying ESI labels and also utilize a tunnel IP header in which the source IP address identifies the ingress NVE.
[RFC8365]は、局所バイアスがIPトンネルにのみ利用され、ESIラベルベースのスプリットホライズンがIPベースのMPLSトンネルに使用されることを指定しています。ただし、MplsogreやMplsoudpなどのIPベースのMPLSトンネルもIPトンネルに分類されており、両方の手順をサポートする可能性があります。これらのトンネルは、ESIラベルを運ぶことができ、ソースIPアドレスが侵入NVEを識別するトンネルIPヘッダーも利用できます。
Similarly, certain IP tunnels (those that include an identifier for the source ES in the tunnel header) may also potentially support either procedure. Examples of such tunnels include Geneve and SRv6:
同様に、特定のIPトンネル（トンネルヘッダーのソースESの識別子を含むもの）も、どちらの手順もサポートする可能性があります。そのようなトンネルの例には、GeneveとSRV6が含まれます。
* In a Geneve tunnel, the source IP address identifies the ingress NVE; therefore, local bias is possible. Also, Section 4.1 of [EVPN-GENEVE] defines an Ethernet option Type-Length-Value (TLV) to encode an ESI label value.
* Geneveトンネルでは、ソースIPアドレスが侵入NVEを識別します。したがって、局所的なバイアスが可能です。また、[evpn-geneve]のセクション4.1は、ESIラベル値をエンコードするイーサネットオプションタイプ-Length-Value（TLV）を定義します。
* In an SRv6 tunnel, the source IP address identifies the ingress NVE. By default, and as outlined in [RFC9252], the ingress PE adds specific information to the SRv6 packet to enable the egress PE to identify the source ES of the BUM packet. This information is the ESI filtering argument (Arg.FE2) (see Section 6.1.1 of [RFC9252] and Section 4.12 of [RFC8986]) of the service Segment Identifier (SID) received on an A-D per ES route from the egress PE.
* SRV6トンネルでは、ソースIPアドレスがイングレスNVEを識別します。デフォルトで、[RFC9252]で概説されているように、Ingress PEはSRV6パケットに特定の情報を追加して、出口PEがバムパケットのソースESを識別できるようにします。この情報は、ESIフィルタリング引数（Arg.Fe2）（[RFC9252]のセクション6.1.1および[RFC8986]のセクション4.12を参照）です。
Table 1 presents various tunnel encapsulations along with their supported and default split-horizon methods. For Geneve, the default SHT is contingent upon the negotiation of the Ethernet Option with the Source ID TLV. In the case of SRv6, the default SHT is specified as ESI Label filtering in the table, as its behavior is analogous to that of ESI Label filtering. In this document, "ESI Label filtering" refers to the split-horizon filtering based on the presence of a source ES identifier in the tunnel header.
表1は、さまざまなトンネルのカプセルと、サポートされているデフォルトのスプリットホリゾン法を示しています。Geneveの場合、デフォルトのSHTは、ソースID TLVを使用したイーサネットオプションのネゴシエーションを条件としています。SRV6の場合、デフォルトのSHTは、その動作がESIラベルフィルタリングの動作に類似しているため、テーブル内のESIラベルフィルタリングとして指定されています。このドキュメントでは、「ESIラベルフィルタリング」とは、トンネルヘッダー内のソースES識別子の存在に基づくスプリットホリゾンフィルタリングを指します。
This document classifies the tunnel encapsulations used by EVPN into:
このドキュメントは、EVPNが使用するトンネルのカプセルを次のように分類します。
1. IP-based MPLS tunnels
1. IPベースのMPLSトンネル
2. MPLS and SR-MPLS tunnels
2. MPLSおよびSR-MPLSトンネル
3. IP tunnels
3. IPトンネル
4. SRv6 tunnels
4. SRV6トンネル
Table 1 lists the encapsulations supported by this document. Any tunnel encapsulation not listed in Table 1 is out of scope. Tunnel encapsulations used by EVPN can be categorized into one of the four encapsulation groups mentioned above and support split-horizon filtering based on the following rules:
表1に、このドキュメントでサポートされているカプセルを示します。表1にリストされていないトンネルのカプセル化は範囲外です。EVPNが使用するトンネルのカプセル化は、上記の4つのカプセル化グループの1つに分類し、次のルールに基づいてスプリットホリゾンフィルタリングをサポートできます。
* IP-based MPLS tunnels and SRv6 tunnels are capable of supporting both split-horizon filtering methods.
* IPベースのMPLSトンネルとSRV6トンネルは、両方のスプリットホリゾンフィルタリング方法をサポートできます。
* MPLS and SR-MPLS tunnels only support ESI Label-based split-horizon filtering.
* MPLSおよびSR-MPLSトンネルは、ESIラベルベースのスプリットホリゾンフィルタリングのみをサポートしています。
* IP tunnels support local-bias split-horizon filtering and may also support ESI Label-based split-horizon filtering, provided they incorporate a mechanism to identify the source ESI in the header.
* IPトンネルは、ローカルバイアススプリットホリゾンフィルタリングをサポートし、ヘッダー内のソースESIを識別するメカニズムを組み込んでいれば、ESIラベルベースのスプリットホリゾンフィルタリングをサポートする場合があります。
+===============+====================+============+===========+
| Tunnel | Default Split- | Supports | Supports |
| Encapsulation | Horizon Type (SHT) | Local Bias | ESI Label |
+===============+====================+============+===========+
| MPLSoGRE (IP- | ESI Label | Yes | Yes |
| based MPLS) | filtering | | |
+---------------+--------------------+------------+-----------+
| MPLSoUDP (IP- | ESI Label | Yes | Yes |
| based MPLS) | filtering | | |
+---------------+--------------------+------------+-----------+
| MPLS and SR- | ESI Label | No | Yes |
| MPLS | filtering | | |
+---------------+--------------------+------------+-----------+
| VXLAN (IP | Local Bias | Yes | No |
| tunnels) | | | |
+---------------+--------------------+------------+-----------+
| NVGRE (IP | Local Bias | Yes | No |
| tunnels) | | | |
+---------------+--------------------+------------+-----------+
| VXLAN-GPE (IP | Local Bias | Yes | No |
| tunnels) | | | |
+---------------+--------------------+------------+-----------+
| Geneve (IP | Local Bias (if no | Yes | Yes |
| tunnels) | ESI Lb), ESI Label | | |
| | (if ESI lb) | | |
+---------------+--------------------+------------+-----------+
| SRv6 | ESI Label | Yes | Yes |
| | filtering | | |
+---------------+--------------------+------------+-----------+
Table 1: Tunnel Encapsulations and Split-Horizon Types
表1：トンネルのカプセルとスプリットホリゾンタイプ
The ESI Label method is applicable for both All-Active and Single-Active configurations, whereas the local-bias method is suitable only for All-Active configurations. Moreover, the ESI Label method is effective across different network domains, while local bias is constrained to networks where there is no change in the next hop between the NVEs attached to the same ES. Nonetheless, some operators favor the local-bias method due to its simplification of the encapsulation process, reduced resource consumption on NVEs, and the fact that the ingress NVE always forwards traffic locally to other interfaces, thereby decreasing the delay in reaching multihomed hosts.
ESIラベル法は、オールアクティブな構成と単一活動的な構成の両方に適用できますが、ローカルバイアス法はオールアクティブな構成にのみ適しています。さらに、ESIラベル法は異なるネットワークドメインで効果的ですが、ローカルバイアスは、同じESに接続されたNVE間の次のホップに変更がないネットワークに制約されます。それにもかかわらず、一部のオペレーターは、カプセル化プロセスの簡素化、NVEのリソース消費の減少、およびイングレスNVEが常に他のインターフェイスに局所的にトラフィックを転送し、それによってマルチホームのホストに到達する遅延を減らすという事実により、ローカルバイアス法を支持します。
This document extends the EVPN multihoming procedures to allow operators to select the preferred split-horizon method for a given NVO tunnel according to their specific requirements. The choice between local bias and ESI Label split horizon is now allowed (by configuration) for tunnel encapsulations that support both methods, and this selection is advertised along with the EVPN A-D per ES route. IP tunnels that do not support both methods, such as VXLAN or NVGRE, will continue to adhere to the procedures specified in [RFC8365]. Note that this document does not modify the local bias or the ESI Label split-horizon procedures themselves, just focuses on the signaling and selection of the split-horizon method to apply by the multihomed NVEs.
このドキュメントは、EVPNマルチホーム手順を拡張して、特定の要件に従って、特定のNVOトンネルの優先分割ホリゾン法を選択できるようにします。ローカルバイアスとESIラベルスプリットホライズンの選択は、両方の方法をサポートするトンネルカプセルのために（構成ごとに）許可されており、この選択はEVPN A-D Rルートとともに宣伝されています。VXLANやNVGREなどの両方の方法をサポートしていないIPトンネルは、[RFC8365]で指定された手順を引き続き遵守します。このドキュメントは、ローカルバイアスまたはESIラベルスプリットホリゾン手順自体を変更しないことに注意してください。マルチホームのNVEによって適用するためのスプリットホリゾン法のシグナルと選択に焦点を当てていることに注意してください。
Extensions to EVPN are required to enable NVEs to advertise their preferred split-horizon method for a given ES. Figure 1 illustrates the ESI Label extended community (Section 7.5 of [RFC7432]), which is consistently advertised alongside the EVPN A-D per ES route. All NVEs connected to an ES advertise an A-D per ES route for that ES, including the extended community, which communicates information regarding the multihoming mode (either All-Active or Single-Active) and, if necessary, specifies the ESI Label to be utilized.
EVPNへの拡張は、NVEが特定のESに対して好みのスプリットホリゾンメソッドを宣伝できるようにするために必要です。図1は、ESIラベル拡張コミュニティ（[RFC7432]のセクション7.5）を示しています。ESに接続されているすべてのNVEは、マルチホームモード（オールアクティブまたはシングルアクティブのいずれか）に関する情報を伝え、必要に応じて使用するESIラベルを指定する拡張コミュニティを含む、そのESのA-DごとのルートをそのESごとに宣伝します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ESI Label Extended Community
図1：ESIラベル拡張コミュニティ
[RFC7432] defines the low-order bit of the Flags octet (bit 0) as the "Single-Active" bit:
[RFC7432]は、フラグの低次ビットを「シングルアクティブ」ビットとしてflags octet（ビット0）と定義します。
* A value of 0 means that the multihomed ES is operating in All-Active multihoming redundancy mode.
* 0の値は、マルチホームESがオールアクティブなマルチホーム冗長モードで動作していることを意味します。
* A value of 1 means that the multihomed ES is operating in Single-Active multihoming redundancy mode.
* 1の値は、マルチホームESが単一活性の多発性冗長モードで動作していることを意味します。
Section 5 establishes a registry for the Flags octet, designating the "Single-Active" bit as the low-order bit of the newly defined Multihoming Redundancy Mode field.
セクション5では、フラグのオクテットのレジストリを確立し、新たに定義されたマルチホーム冗長モードフィールドの低次ビットとして「単一活性」ビットを指定します。
[RFC8365] does not include any explicit indication regarding the split-horizon method in the A-D per ES route. In this document, the split-horizon procedure defined in Section 8.3.1 of [RFC8365] is considered the default behavior, presuming that local bias is employed exclusively for IP tunnels, while ESI Label-based split horizon is used for IP-based MPLS tunnels. This document specifies that the two high-order bits in the Flags octet (bits 6 and 7) constitute the "Split-Horizon Type" or "SHT" field, where:
[RFC8365]には、a-d perルートのスプリットホリゾン法に関する明示的な兆候は含まれていません。このドキュメントでは、[RFC8365]のセクション8.3.1で定義されているスプリットホリゾンの手順はデフォルトの動作と見なされ、ローカルバイアスはIPトンネル専用に使用され、ESIラベルベースのスプリットホライズンはIPベースのMPLSトンネルに使用されます。このドキュメントは、フラグの2つの高次ビット（ビット6および7）が「スプリットホリゾンタイプ」または「sht」フィールドを構成することを指定しています。
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|SHT| |RED|
+-+-+-+-+-+-+-+-+
RED = "Multihoming Redundancy Mode" field (see Table 2)
SHT bit 7 6
-----------
0 0 --> Default SHT
Backwards compatible with [RFC8365] and [RFC7432]
0 1 --> Local Bias
1 0 --> ESI Label-based filtering
1 1 --> Unassigned
* SHT = 00 is backwards compatible with [RFC8365] and [RFC7432], and indicates that the advertising NVE intends to use the default or built-in SHT. The default SHT is shown in Table 1 for each encapsulation. An egress NVE that follows the [RFC8365] behavior and does not support this specification will ignore the SHT bits (which is equivalent to processing them as a value of 00).
* SHT = 00は[RFC8365]および[RFC7432]と後方互換性があり、広告NVEがデフォルトまたはビルトインSHTを使用するつもりであることを示しています。デフォルトのSHTは、各カプセル化の表1に示されています。[RFC8365]の動作に続き、この仕様をサポートしない出力NVEは、SHTビットを無視します（これは00の値としてそれらを処理することに相当）。
* SHT = 01 indicates that the advertising NVE intends to use local-bias procedures in the ES for which the AD per-ES route is advertised.
* SHT = 01は、広告NVEがAD PER-ESルートが宣伝されているESでローカルバイアス手順を使用する予定であることを示しています。
* SHT = 10 indicates that the advertising NVE intends to use the ESI Label-based split-horizon method procedures in the ES for which the AD per-ES route is advertised.
* SHT = 10は、広告NVEがAD PER-ESルートが宣伝されているESでESIラベルベースのスプリットホリゾンメソッド手順を使用する予定であることを示しています。
* SHT = 11 is Unassigned.
* SHT = 11は割り当てられていません。
The following behavior is observed:
次の動作が観察されます。
* An SHT value of 01 or 10 MUST NOT be used with encapsulations that support only one SHT in Table 1, and MAY be used by encapsulations that support the two SHTs in Table 1.
* 01または10のSHT値は、表1の1つのSHTのみをサポートするカプセルで使用してはならず、表1の2つのSHTをサポートするカプセルで使用できます。
* An SHT value different than 00 expresses the intent to use a specific split-horizon method, but does not reflect the actual operational SHT used by the advertising NVE, unless all the NVEs attached to the ES advertise the same SHT.
* 00とは異なるSHT値は、特定のスプリットホリゾン法を使用する意図を表しますが、ESに付随するすべてのNVEが同じSHTを広告しない限り、広告NVEで使用される実際の運用SHTを反映していません。
* In case of an inconsistency in the SHT value advertised by the NVEs attached to the same ES for a given EVI, all the NVEs MUST revert to the behavior in [RFC8365] and use the default SHT in Table 1, irrespective of the advertised SHT.
* 特定のEVIに対して同じESに接続されているNVEによって宣伝されているSHT値の矛盾がある場合、すべてのNVEは[RFC8365]の動作に戻り、宣伝されたSHTに関係なく表1のデフォルトSHTを使用する必要があります。
* An SHT different than 00 MUST NOT be set if the "Single-Active" bit is set. A received A-D per ES route where the "Single-Active" and SHT bits are different than zero MUST follow the treat-as-withdraw behavior in [RFC7606].
* 「単一アクティブ」ビットが設定されている場合、00とは異なるshtを設定しないでください。[RFC7606]の「単一活性」およびSHTビットがゼロとは異なるゼロがゼロとは異なる、受信したA-Dルートが受信されたA-Dルート。
* The SHT MUST have the same value in each Ethernet A-D per ES route that an NVE advertises for a given ES and a given encapsulation (see Section 3 for NVEs supporting multiple encapsulations).
* SHTは、特定のESおよび特定のカプセル化に対してNVEが宣伝する各イーサネットA-Dルートに同じ値を持っている必要があります（複数のカプセルをサポートするNVESについてはセクション3を参照）。
As an example, egress NVEs that support IP-based MPLS tunnels, such as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES along with the BGP Encapsulation Extended Community, as defined in [RFC9012]. This extended community indicates the encapsulation type (MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to signify the intent to use local bias or the ESI Label, respectively.
例として、[RFC9012]で定義されているように、MplSogreやMplsoudpなどのIPベースのMPLSトンネルをサポートするEgress NVEは、ESのESごとのルートとBGPカプセル化拡張コミュニティとともにA-D RORTESを宣伝します。この拡張されたコミュニティは、カプセル化タイプ（mplsogreまたはmplsoudp）を示し、01または10のSHT値を使用して、それぞれローカルバイアスまたはESIラベルを使用する意図を意味します。
An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with the following tunnel encapsulation types from [RFC9012]: VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP Tunnel Encapsulation Extended Community at all. In all these cases, it is presumed that there is no choice for the split-horizon method; therefore, the SHT value MUST be set to 00. If a route with any of the mentioned encapsulation options is received and has an SHT value different than 00, it SHOULD apply the treat-as-withdraw behavior, per [RFC7606].
出力NVEは、[RFC9012]の次のトンネルカプセル化タイプを使用してA-Dごとのルートを宣伝する場合、00以外のSHT値を使用してはなりません：VXLAN（タイプ8）、NVGRE（タイプ9）、MPLS（タイプ10）、またはBGPトンネルカプセル化が拡張されていない。これらすべての場合、スプリットホリゾン法には選択肢がないと推定されます。したがって、SHT値は00に設定する必要があります。上記のカプセル化オプションのいずれかを備えたルートが受信され、00とは異なるSHT値がある場合、[RFC7606]ごとに扱いやすい動作を適用する必要があります。
An egress NVE advertising A-D per ES route(s) for an ES with Geneve encapsulation (tunnel encapsulation type 19 in the BGP Tunnel Encapsulation attribute [RFC9012]) MAY use an SHT value of 01 or 10. A value of 01 indicates the intent to use local bias, regardless of the presence of an Ethernet option TLV with a non-zero Source-ID, as described in [EVPN-GENEVE]. A value of 10 indicates the intent to use ESI Label-based split horizon, and it is only valid if an Ethernet option TLV with a non-zero Source-ID is present. A value of 00 indicates the default behavior outlined in Table 1, which is to use local bias if:
Geneveカプセル化を伴うESのESの出力nve広告A-d（s）は、BGPトンネルカプセル化属性[RFC9012]のトンネルカプセル化タイプ19）のsht値を01または10のSHT値を使用することを示します。10の値は、ESIラベルベースのスプリットホライズンを使用する意図を示し、非ゼロSource-IDを持つイーサネットオプションTLVが存在する場合にのみ有効です。00の値は、表1に概説されているデフォルトの動作を示します。これは、次の場合のローカルバイアスを使用することです。
a. no ESI Label is present in the Ethernet option TLV, or
a. ESIラベルはイーサネットオプションTLVに存在しません。
b. there is no Ethernet option TLV.
b. イーサネットオプションTLVはありません。
Otherwise, the ESI Label split-horizon method is applied.
それ以外の場合、ESIラベルスプリットホリゾン法が適用されます。
These procedures assume a single encapsulation supported in the egress NVE. Section 3 describes additional procedures for NVEs supporting multiple encapsulations.
これらの手順では、出口nveでサポートされている単一のカプセル化が想定されています。セクション3では、複数のカプセルをサポートするNVEの追加手順について説明します。
This document also updates [RFC8365] regarding the value that is advertised in the ESI Label field of the ESI Label extended community, as follows:
このドキュメントは、次のように、ESIラベル拡張コミュニティのESIラベルフィールドで宣伝されている値に関して[RFC8365]を更新します。
* The A-D per ES route(s) for an ES MAY have an ESI Label value of zero if the SHT value is 01. Section 2.2 specifies the scenarios where the SHT can be 01. An ESI Label value of zero eliminates the need to allocate labels in cases where they are not utilized, such as in the local-bias method.
* SHT値が01である場合、ESのA-Dあたりのルートは、ESIラベル値がゼロになる場合があります。セクション2.2は、SHTが01になる可能性のあるシナリオを指定します。
* The A-D per ES route(s) for an ES MAY have an ESI Label value of zero for VXLAN or NVGRE encapsulations.
* ESのa-Dあたりのルートは、VXLANまたはNVGREカプセルの場合、ESIラベル値がゼロである場合があります。
As discussed in Section 2.2, this specification is backwards compatible with the split-horizon filtering behavior in [RFC8365] and a non-upgraded NVE can be attached to the same ES as other NVEs supporting this specification.
セクション2.2で説明したように、この仕様は[RFC8365]のスプリットホリゾンフィルタリング挙動との逆方向に互換性があり、アップグレードされていないNVEは、この仕様をサポートする他のNVEと同じESに接続できます。
An NVE maintains an administrative SHT value for an ES, which is advertised alongside the A-D per ES route, and an operational SHT value, which is the one actually used regardless of what the NVE has advertised. The administrative SHT matches the operational SHT if all the NVEs attached to the ES have the same administrative SHT.
nveは、esのa-dあたりのルートとともに宣伝されているesの管理上のsht値と、nveが宣伝しているものに関係なく実際に使用される運用上のsht値を維持します。管理SHTは、ESに接続されているすべてのNVEが同じ管理SHTを持っている場合、運用上のSHTと一致します。
This document assumes that an implementation of [RFC7432] or [RFC8365] that does not support the specifications in this document will ignore the values of all the Flags in the ESI Label extended community, except for the "Single-Active" bit. Based on this assumption, a non-upgraded NVE will disregard any SHT value other than 00. If an upgraded NVE receives at least one A-D per ES route for the ES with an SHT value of 00, it MUST revert its operational SHT to the default split-horizon method, as described in Table 1, irrespective of its administrative SHT.
このドキュメントは、[RFC7432]または[RFC8365]の実装は、このドキュメントの仕様をサポートしていない[RFC8365]は、「単一活性」ビットを除き、ESIラベル拡張コミュニティのすべてのフラグの値を無視すると想定しています。この仮定に基づいて、アップグレードされていないNVEは00以外のSHT値を無視します。アップグレードされたNVEが00のSHT値を持つESのESごとに少なくとも1つのA-Dを受信する場合、表1で説明されているように、その動作SHTをデフォルトのスプリットホリゾンメソッドに戻す必要があります。
For instance, consider an NVE attached to ES N that receives two A-D per ES routes for N from different NVEs, NVE1 and NVE2. If the route from NVE1 has an SHT value of 00 and the one from NVE2 has an SHT value of 01, the NVE MUST use the default split-horizon method specified in Table 1 as its operational SHT, regardless of its administrative SHT.
たとえば、異なるNVE、NVE1、およびNVE2からNの2つのA-Dルートを受け取るNVEをES Nに接続するNVEを検討してください。NVE1からのルートのsht値のルートが00で、NVE2からのルートのSHT値は01である場合、NVEは、管理SHTに関係なく、表1で指定されたデフォルトのスプリットホリゾンメソッドを動作SHTとして使用する必要があります。
All NVEs attached to an ES with an operational SHT value of 10 MUST advertise a valid, non-zero ESI Label. If the operational SHT value is 01, the ESI Label MAY be zero. If the operational SHT value is 00, the ESI Label may be zero only if the default encapsulation supports local bias exclusively, and the NVEs do not require the presence of a valid, non-zero ESI Label.
運用上のSHT値が10のESに接続されているすべてのNVEは、有効な非ゼロESIラベルを宣伝する必要があります。運用上のSHT値が01の場合、ESIラベルはゼロになる可能性があります。運用上のSHT値が00の場合、ESIラベルは、デフォルトのカプセル化がローカルバイアスのみをサポートし、NVEが有効な非ゼロESIラベルの存在を必要としない場合にのみゼロになる場合があります。
If an NVE changes its operational SHT value from 01 (Local Bias) to 00 (Default SHT) due to the presence of a new non-upgraded NVE in the ES, and it previously advertised a zero ESI Label, it MUST send an update with a valid, non-zero ESI Label, unless all the non-upgraded NVEs in the ES support only local bias. For example, consider NVE1 and NVE2 using MPLSoUDP as encapsulation, attached to the same Ethernet Segment ES1, and advertising an SHT value of 01 (Local Bias) with a zero ESI Label value. Suppose NVE3, which does not support this specification, joins ES1 and advertises an SHT value of 00 (default). Upon receiving NVE3's A-D per ES route, NVE1 and NVE2 MUST update their A-D per ES routes for ES1 to include a valid, non-zero ESI Label value. The assumption here is that NVE3 only supports the default ESI Label-based split-horizon filtering.
NVEがESに新しい非アップグレードされたNVEが存在するため、NVEが運用上のSHT値を01（ローカルバイアス）から00（デフォルトSHT）に変更し、ESIラベルのゼロラベルを以前に宣伝していた場合、ESのすべての非アップグレードNVEがローカルの存在のみをサポートしない限り、有効な非ゼロESIラベルで更新を送信する必要があります。たとえば、MPLSOUDPをカプセル化として使用して、同じイーサネットセグメントES1に取り付けられ、ESIラベル値がゼロの01（ローカルバイアス）のSHT値を宣伝するNVE1とNVE2を考慮してください。この仕様をサポートしていないNVE3がES1に結合し、00のSHT値を宣伝するとします（デフォルト）。NVE3のa-d per esルートを受信すると、nve1とnve2は、有効な非ゼロESIラベル値を含めるために、es1のa-d rortesを更新する必要があります。ここでの仮定は、NVE3がデフォルトのESIラベルベースのスプリットホリゾンフィルタリングのみをサポートするということです。
As specified in [RFC8365], an NVE that supports multiple data plane encapsulations (e.g., VXLAN, NVGRE, MPLS, MPLSoUDP, Geneve) must indicate all supported encapsulations using BGP Encapsulation extended communities as defined in [RFC9012] for all EVPN routes. This section provides clarification on the multihoming split-horizon behavior for NVEs that advertise and receive multiple BGP Encapsulation extended communities along with the A-D per ES routes. This section uses the notation {x, y} (more than two encapsulations is possible too) to denote the encapsulations advertised in BGP Encapsulation extended communities (or the BGP Tunnel Encapsulation Attribute), where x and y represent different encapsulation values. When Geneve is one of the encapsulations, the tunnel type is indicated in either a BGP Encapsulation extended community or a BGP Tunnel Encapsulation Attribute.
[RFC8365]で指定されているように、複数のデータプレーンカプセル（例：VXLAN、NVGRE、MPLS、MPLSOUDP、GENEVE）をサポートするNVEは、すべてのEVPNルートの[RFC9012]で定義されているBGPカプセル化の拡張コミュニティを使用してすべてのサポートされているカプセル化を示す必要があります。このセクションでは、複数のBGPカプセル化が拡張されたコミュニティを宣伝および受け取っているNVEのマルチホミングスプリットホリゾンの動作を説明し、A-Dごとのルートとともに拡張されたコミュニティを提供します。このセクションでは、表記{x、y}（2つ以上のカプセルも可能）を使用して、xとyが異なるカプセル化値を表すBGPカプセル化拡張コミュニティ（またはBGPトンネルカプセル化属性）で宣伝されているカプセル化を示します。Geneveがカプセルの1つである場合、トンネルタイプは、BGPカプセル化拡張コミュニティまたはBGPトンネルカプセル化属性のいずれかに示されています。
It is important to note that an NVE MAY advertise multiple A-D per ES routes for the same ES, rather than a single route, with each route conveying a set of Route Targets (RTs). The total set of RTs associated with a given ES is referred to as the RT-set for that ES. Each of the EVIs represented in the RT-set will have its RT included in one, and only one, A-D per ES route for the ES. When multiple A-D per ES routes are advertised for the same ES, each route must have a distinct Route Distinguisher.
NVEは、各ルートがルートターゲットのセット（RT）を運ぶだけで、単一のルートではなく、同じESに対して複数のA-Dルートを宣伝することができることに注意することが重要です。特定のESに関連付けられたRTSの合計セットは、そのESのRTセットと呼ばれます。RT-SETに表される各EVIには、RTが1つ、ESのESあたりのA-Dのみが1つだけに含まれています。同じESに対して複数のA-DがeSあたりのルートが宣伝されている場合、各ルートには異なるルートの区別器が必要です。
As per [RFC8365], an NVE that advertises multiple encapsulations in the A-D per ES route(s) for an ES MUST advertise encapsulations that use the same split-horizon filtering method in the same route. For example:
[RFC8365]によると、ESのA-DごとのA-Dルートで複数のカプセルを宣伝するNVEは、同じルートで同じスプリットホリゾンフィルタリング方法を使用するカプセルを宣伝する必要があります。例えば：
* An A-D per ES route for ES-x may be advertised with {VXLAN, NVGRE} encapsulations.
* ES-Xのa-Dあたりのルートは、{vxlan、nvgre}のカプセルで宣伝できます。
* An A-D per ES route for ES-y may be advertised with {MPLS, MPLSoUDP, MPLSoGRE} encapsulations (or a subset).
* ES-Yのa-Dあたりのルートは、{mpls、mplsoudp、mplsogre}カプセル（またはサブセット）で宣伝できます。
* However, an A-D per ES route for ES-z MUST NOT be advertised with {MPLS, VXLAN} encapsulations.
* ただし、ES-Zのa-Dあたりのルートは、{mpls、vxlan}のカプセルで宣伝してはなりません。
This document extends the described behavior as follows:
このドキュメントは、説明された動作を次のように拡張します。
a. An A-D per ES route for ES-x may be advertised with multiple encapsulations, some of which support a single split-horizon method. In this case, the SHT value MUST be 00. For instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN, Geneve}, or {MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In all these cases, the SHT value MUST be 00 and the treat-as-withdraw behavior [RFC7606] is applied in case of any other value.
a. ES-Xのa-Dあたりルートは、複数のカプセルで宣伝される場合があります。その一部は、単一のスプリットホリゾン法をサポートしています。この場合、sht値は00でなければなりません。たとえば、{vxlan、nvgre}、{vxlan、geneve}、{mpls、mplsogre、mplsoudp}などのカプセルは、ルートごとにA-dで宣伝できます。これらのすべての場合、SHT値は00でなければならず、withdrawの扱い方の動作[RFC7606]は、他の値の場合に適用されます。
b. An A-D per ES route for ES-y may be advertised with multiple encapsulations that all support both split-horizon methods. In this case, the SHT value MAY be 01 if the preferred method is local bias, or 10 if the ESI Label-based method is desired. For example, encapsulations such as {MPLSoGRE, MPLSoUDP, Geneve} (or a subset) MAY be advertised in an A-D per ES route with an SHT value of 01. The ESI Label value in this case MAY be zero.
b. ES-YのA-Dあたりのルートは、すべてがスプリットホリゾンの両方のメソッドをサポートする複数のカプセルで宣伝できます。この場合、優先方法がローカルバイアスの場合は01、またはESIラベルベースのメソッドが必要な場合は10になる場合があります。たとえば、{mplsogre、mplsoudp、geneve}（またはサブセット）などのカプセル化は、01のSHT値を持つa-d esルートで宣伝できます。この場合のESIラベル値はゼロになる場合があります。
c. If ES-z with an RT-set composed of (RT1, RT2, RT3.. RTn) supports multiple encapsulations requiring different split-horizon methods, a distinct A-D per ES route (or group of routes) per split-horizon method MUST be advertised. For example, consider an ES-z with n RTs, where:
c. （RT1、RT2、RT3 .. RTN）で構成されるRTセットを持つES-Zが異なるスプリットホリゾンメソッドを必要とする複数のカプセルをサポートする場合、スプリットホリゾンの方法ごとに異なるa-Dルート（またはルートのグループ）を宣伝する必要があります。たとえば、n rtsを持つES-zを検討してください。
* the EVIs corresponding to (RT1..RTi) support VXLAN,
* （rt1..rti）サポートvxlanに対応するevis、
* the ones for (RTi+1..RTm) (with i<m) support MPLSoUDP with local bias, and
* （rti+1..rtm）のもの（i <mで）は、ローカルバイアスでmplsoudpをサポートし、
* the ones for (RTm+1..RTn) (with m<n) support Geneve with ESI Label-based split horizon.
* （rtm+1..rtn）（m <nを使用）のものは、ESIラベルベースのスプリットホライズンを使用してGeneveをサポートします。
In this scenario, three groups of A-D per ES routes MUST be advertised for ES-z:
このシナリオでは、ES-Zに対して3つのA-DのA-Dグループを宣伝する必要があります。
* A-D per ES route group 1, including (RT1..RTi) with encapsulation {VXLAN} and an SHT value of 00. The ESI Label MAY be zero.
* （RT1..RTI）がカプセル化{vxlan}を含む（rt1..rti）および00のsht値を含むA-d。
* A-D per ES route group 2, including (RTi+1..RTm) with encapsulation {MPLSoUDP} and an SHT value of 01. The ESI Label MAY be zero.
* （rti+1..rtm）を含む（rti+1..rtm）{mplsoudp}と01のsht値を含むA-d。
* A-D per ES route group 3, including (RTm+1..RTn) with encapsulation {Geneve} and an SHT value of 10. The ESI Label MUST have a valid, non-zero value, and the Ethernet option as defined in [RFC8926] MUST be advertised.
* （rtm+1..rtn）を含む（rtm+1.. rtn）capsulsulation {geneve}と10のsht値を含むA-d。
As per [RFC8365], it is the responsibility of the operator of a given EVI to ensure that all of the NVEs within that EVI support a common encapsulation. Failure to meet this condition may result in service disruption or failure.
[RFC8365]によると、そのEVI内のすべてのNVEが共通のカプセル化をサポートすることを保証することは、特定のEVIのオペレーターの責任です。この状態を満たさないと、サービスの混乱または失敗が発生する可能性があります。
All the security considerations described in [RFC7432] are applicable to this document.
[RFC7432]で説明されているすべてのセキュリティ上の考慮事項は、このドキュメントに適用できます。
Additionally, this document modifies the procedures for split-horizon filtering as outlined in [RFC8365], offering operators a choice between local bias and ESI Label-based filtering for tunnels that support both methods. Misconfiguration of the desired SHT could lead to forwarding behaviors that differ from the intended configuration. Apart from this risk, this document describes procedures to ensure that all PE devices or NVEs connected to the same ES agree on a common SHT method, with a fallback to a default behavior in case of a mismatch in the SHT bits being advertised by any two PEs or NVEs in the ES. Consequently, unauthorized changes to the SHT configuration by an attacker on a single PE or NVE of the ES should not cause traffic disruption (as long as the SHT value is valid as per this document) but may result in alterations to forwarding behavior.
さらに、このドキュメントは、[RFC8365]で概説されているスプリットホリゾンフィルタリングの手順を変更し、両方の方法をサポートするトンネルのローカルバイアスとESIラベルベースのフィルタリングの選択をオペレーターに提供します。目的のSHTの誤解は、意図した構成とは異なる転送行動につながる可能性があります。このリスクとは別に、このドキュメントは、同じESに接続されたすべてのPEデバイスまたはNVEが共通のSHTメソッドに一致するようにする手順について説明します。SHTビットのミスマッチの場合、ESの任意の2つのPEまたはNVEによって宣伝されている場合、デフォルトの動作にフォールバックします。したがって、ESの単一のPEまたはNVEの攻撃者によるSHT構成の不正な変更は、トラフィックの破壊を引き起こすべきではありません（このドキュメントに従ってSHT値が有効である限り）が、転送挙動の変化につながる可能性があります。
Per this document, IANA has created the "EVPN ESI Label Extended Community Flags" registry for the 1-octet Flags field in the ESI Label Extended Community [RFC7432], as follows:
このドキュメントに従って、IANAは、ESIラベル拡張コミュニティ[RFC7432]の1-OCTETフラグフィールドの「EVPN ESIラベル拡張コミュニティフラグ」レジストリを作成しました。
+==============+=============================+===========+
| Bit Position | Name | Reference |
+==============+=============================+===========+
| 0-1 | Multihoming Redundancy Mode | [RFC7432] |
+--------------+-----------------------------+-----------+
| 2-5 | Unassigned | |
+--------------+-----------------------------+-----------+
| 6-7 | Split-Horizon Type | RFC 9746 |
+--------------+-----------------------------+-----------+
Table 2
IANA has also created the "Multihoming Redundancy Mode" registry for the related field of the "EVPN ESI Label Extended Community Flags". The registry has been populated with the following initial values:
IANAはまた、「EVPN ESIラベル拡張コミュニティフラグ」の関連フィールドに「マルチホーム冗長モード」レジストリを作成しました。レジストリには、以下の初期値が入力されています。
+=======+=============================+===========+
| Value | Multihoming Redundancy Mode | Reference |
+=======+=============================+===========+
| 00 | All-Active | [RFC7432] |
+-------+-----------------------------+-----------+
| 01 | Single-Active | [RFC7432] |
+-------+-----------------------------+-----------+
| 10 | Unassigned | |
+-------+-----------------------------+-----------+
| 11 | Unassigned | |
+-------+-----------------------------+-----------+
Table 3
Finally, IANA has created the "Split-Horizon Type" registry for the related field of the "EVPN ESI Label Extended Community Flags". The registry has been populated with the following initial values:
最後に、IANAは、「EVPN ESIラベル拡張コミュニティフラグ」の関連フィールドに「スプリットホリゾンタイプ」レジストリを作成しました。レジストリには、以下の初期値が入力されています。
+=======+===========================+===========+
| Value | Split-Horizon Type Value | Reference |
+=======+===========================+===========+
| 00 | Default SHT | RFC 9746 |
+-------+---------------------------+-----------+
| 01 | Local Bias | RFC 9746 |
+-------+---------------------------+-----------+
| 10 | ESI Label-based filtering | RFC 9746 |
+-------+---------------------------+-----------+
| 11 | Unassigned | |
+-------+---------------------------+-----------+
Table 4
New registrations in the "EVPN ESI Label Extended Community Flags", "Multihoming Redundancy Mode", and "Split-Horizon Type" registries will be made through the "IETF Review" procedure defined in [RFC8126]. These registries are located in the "Border Gateway Protocol (BGP) Extended Communities" registry group.
「EVPN ESIラベルの拡張コミュニティフラグ」、「マルチホーム冗長モード」、および「スプリットホーリゾンタイプ」レジストリの新しい登録は、[RFC8126]で定義された「IETFレビュー」手順を通じて行われます。これらのレジストリは、「Border Gateway Protocol（BGP）拡張コミュニティ」レジストリグループにあります。
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[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>.
[EVPN-GENEVE]
Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S.
Aldrin, "EVPN control plane for Geneve", Work in Progress,
Internet-Draft, draft-ietf-bess-evpn-geneve-08, 5 July
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
bess-evpn-geneve-08>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[TUNNEL-ENCAP]
IANA, "Border Gateway Protocol (BGP) Tunnel
Encapsulation", <https://www.iana.org/assignments/bgp-
tunnel-encapsulation>.
[VXLAN-GPE]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN (VXLAN-GPE)", Work in Progress,
Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
nvo3-vxlan-gpe-13>.
The authors would like to thank Anoop Ghanwani, Gyan Mishra, and Jeffrey Zhang for their review and useful comments. Thanks to Gunter Van de Velde and Sue Hares as well, for their thorough review.
著者は、Anoop Ghanwani、Gyan Mishra、Jeffrey Zhangに、レビューと有用なコメントをしてくれたことに感謝します。Gunter Van de VeldeとSue Haresにも感謝します。
Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Kiran Nagaraj
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: kiran.nagaraj@nokia.com
Wen Lin
Juniper Networks
Email: wlin@juniper.net
Ali Sajassi
Cisco Systems, Inc.
Email: sajassi@cisco.com