[要約] RFC 9469 は、EVPNを使用してNVO3ネットワークでの基本的なLayer 2およびLayer 3接続要件、MAC移動性、MAC保護、ループ保護、マルチホーミング、データセンター間接続（DCI）などの高度な機能に適用する方法を説明しています。EVPNは、NVO3ネットワーク向けのスケーラブルなソリューションであり、アンダーレイIPファブリックの独立性を維持します。
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9469 M. Bocci
Category: Informational Nokia
ISSN: 2070-1721 S. Boutros
Ciena
A. Sajassi
Cisco
September 2023
An Ethernet Virtual Private Network (EVPN) provides a unified control plane that solves the issues of Network Virtualization Edge (NVE) auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and advanced features in a scablable way as required by Network Virtualization over Layer 3 (NVO3) networks. EVPN is a scalable solution for NVO3 networks and keeps the independence of the underlay IP Fabric, i.e., there is no need to enable Protocol Independent Multicast (PIM) in the underlay network and maintain multicast states for tenant Broadcast Domains. This document describes the use of EVPN for NVO3 networks and discusses its applicability to basic Layer 2 and Layer 3 connectivity requirements and to advanced features such as MAC Mobility, MAC Protection and Loop Protection, multihoming, Data Center Interconnect (DCI), and much more. No new EVPN procedures are introduced.
イーサネット仮想プライベートネットワーク（EVPN）は、ネットワークが必要とするように、ネットワーク仮想エッジ（NVE）自動指定、テナントメディアアクセス制御（MAC） / IP普及、および高度な機能のスケーブルな方法での高度な機能の問題を解決する統一制御プレーンを提供します。レイヤー3（NVO3）ネットワーク上の仮想化。EVPNは、NVO3ネットワークのスケーラブルなソリューションであり、アンダーレイIPファブリックの独立性を維持します。つまり、アンダーレイネットワークでプロトコル独立マルチキャスト（PIM）を有効にし、テナントブロードキャストドメインのマルチキャスト状態を維持する必要はありません。このドキュメントでは、NVO3ネットワークへのEVPNの使用について説明し、基本的なレイヤー2およびレイヤー3接続要件、およびMACモビリティ、MAC保護とループ保護、マルチホーム、データセンターインターコネクト（DCI）などの高度な機能への適用性について説明します。。新しいEVPN手順は導入されていません。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9469.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9469で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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
2. EVPN and NVO3 Terminology
3. Why is EVPN Needed in NVO3 Networks?
4. Applicability of EVPN to NVO3 Networks
4.1. EVPN Route Types Used in NVO3 Networks
4.2. EVPN Basic Applicability for Layer 2 Services
4.2.1. Auto-Discovery and Auto-Provisioning
4.2.2. Remote NVE Auto-Discovery
4.2.3. Distribution of Tenant MAC and IP Information
4.3. EVPN Basic Applicability for Layer 3 Services
4.4. EVPN as Control Plane for NVO3 Encapsulations and Geneve
4.5. EVPN OAM and Application to NVO3
4.6. EVPN as the Control Plane for NVO3 Security
4.7. Advanced EVPN Features for NVO3 Networks
4.7.1. Virtual Machine (VM) Mobility
4.7.2. MAC Protection, Duplication Detection, and Loop
Protection
4.7.3. Reduction/Optimization of BUM Traffic in Layer 2
Services
4.7.4. Ingress Replication (IR) Optimization for BUM Traffic
4.7.5. EVPN Multihoming
4.7.6. EVPN Recursive Resolution for Inter-subnet Unicast
Forwarding
4.7.7. EVPN Optimized Inter-subnet Multicast Forwarding
4.7.8. Data Center Interconnect (DCI)
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
In Network Virtualization over Layer 3 (NVO3) networks, Network Virtualization Edge (NVE) devices sit at the edge of the underlay network and provide Layer 2 and Layer 3 connectivity among Tenant Systems (TSes) of the same tenant. The NVEs need to build and maintain mapping tables so they can deliver encapsulated packets to their intended destination NVE(s). While there are different options to create and disseminate the mapping table entries, NVEs may exchange that information directly among themselves via a control plane protocol, such as Ethernet Virtual Private Network (EVPN). EVPN provides an efficient, flexible, and unified control plane option that can be used for Layer 2 and Layer 3 Virtual Network (VN) service connectivity. This document does not introduce any new procedures in EVPN.
レイヤー3（NVO3）ネットワークを介したネットワーク仮想化では、ネットワーク仮想化エッジ（NVE）デバイスがアンダーレイネットワークの端にあり、同じテナントのテナントシステム（TSE）間でレイヤー2とレイヤー3接続を提供します。NVEは、マッピングテーブルを構築および維持し、目的の宛先NVEにカプセル化されたパケットを配信できるようにする必要があります。マッピングテーブルエントリを作成および普及させるにはさまざまなオプションがありますが、NVEはイーサネット仮想プライベートネットワーク（EVPN）などのコントロールプレーンプロトコルを介してその情報を直接交換する場合があります。EVPNは、レイヤー2およびレイヤー3仮想ネットワーク（VN）サービス接続に使用できる効率的で柔軟な、統一制御プレーンオプションを提供します。このドキュメントでは、EVPNに新しい手順を導入しません。
In this document, we assume that the EVPN control plane module resides in the NVEs. The NVEs can be virtual switches in hypervisors, Top-of-Rack (ToR) switches or Leaf switches, or Data Center Gateways. As described in [RFC7365], Network Virtualization Authorities (NVAs) may be used to provide the forwarding information to the NVEs, and in that case, EVPN could be used to disseminate the information across multiple federated NVAs. The applicability of EVPN would then be similar to the one described in this document. However, for simplicity, the description assumes control plane communication among NVE(s).
このドキュメントでは、EVPNコントロールプレーンモジュールがNVEに存在すると想定しています。NVEは、ハイパーバイザーの仮想スイッチ、最新のラック（TOR）スイッチまたはリーフスイッチ、またはデータセンターゲートウェイにすることができます。[RFC7365]で説明されているように、ネットワーク仮想化機関（NVA）を使用して転送情報をNVEに提供することができ、その場合、EVPNを使用して複数のフェデレーションNVAにわたって情報を広めることができます。EVPNの適用性は、このドキュメントで説明されているものと類似しています。ただし、簡単にするために、説明はNVE間のコントロールプレーン通信を想定しています。
This document uses the terminology of [RFC7365] in addition to the terms that follow.
このドキュメントでは、以下の用語に加えて、[RFC7365]の用語を使用します。
AC:
交流：
Attachment Circuit or logical interface associated with a given BT. To determine the AC on which a packet arrived, the NVE will examine the physical/logical port and/or VLAN tags (where the VLAN tags can be individual c-tags, s-tags, or ranges of both).
特定のBTに関連付けられたアタッチメント回路または論理インターフェイス。パケットが到着したACを決定するために、NVEは物理/論理ポートおよび/またはVLANタグ（VLANタグが個々のCタグ、Sタグ、または両方の範囲である可能性がある）を調べます。
ARP and NDP:
ARPとNDP：
Address Resolution Protocol (IPv4) and Neighbor Discovery Protocol (IPv6), respectively.
それぞれアドレス解像度プロトコル（IPv4）と隣接発見プロトコル（IPv6）。
BD:
BD：
Broadcast Domain that corresponds to a tenant IP subnet. If no suppression techniques are used, a BUM frame that is injected in a Broadcast Domain will reach all the NVEs that are attached to that Broadcast Domain. An EVI may contain one or multiple Broadcast Domains depending on the service model [RFC7432]. This document will use the term Broadcast Domain to refer to a tenant subnet.
テナントIPサブネットに対応するブロードキャストドメイン。抑制技術が使用されない場合、ブロードキャストドメインに注入されるバムフレームが、そのブロードキャストドメインに接続されているすべてのNVEに到達します。EVIには、サービスモデル[RFC7432]に応じて、1つまたは複数のブロードキャストドメインが含まれる場合があります。このドキュメントでは、Term Broadcast Domainを使用してテナントサブネットを参照します。
BT:
BT：
Bridge Table, as defined in [RFC7432]. A BT is the instantiation of a Broadcast Domain in an NVE. When there is a single Broadcast Domain on a given EVI, the MAC-VRF is equivalent to the BT on that NVE. Although a Broadcast Domain spans multiple NVEs and a BT is really the instantiation of a Broadcast Domain in an NVE, this document uses BT and Broadcast Domain interchangeably.
[RFC7432]で定義されているブリッジテーブル。BTは、NVEのブロードキャストドメインのインスタンス化です。特定のEVIに単一のブロードキャストドメインがある場合、MAC-VRFはそのNVEのBTと同等です。ブロードキャストドメインは複数のNVEとBTにまたがっていますが、実際にはNVEのブロードキャストドメインのインスタンス化ですが、このドキュメントではBTとブロードキャストドメインを互換的に使用します。
BUM:
お尻：
Broadcast, Unknown Unicast, and Multicast frames
ブロードキャスト、不明なユニキャスト、およびマルチキャストフレーム
Clos:
クロー：
A multistage network topology described in [CLOS1953], where all the edge switches (or Leafs) are connected to all the core switches (or Spines). Typically used in Data Centers.
[Clos1953]に記載されている多段階のネットワークトポロジーでは、すべてのエッジスイッチ（またはリーフ）がすべてのコアスイッチ（またはスパイン）に接続されています。通常、データセンターで使用されます。
DF and NDF:
DFとNDF：
Designated Forwarder and Non-Designated Forwarder, respectively. These are the roles that a given PE can have in a given ES.
指定されたフォワーダーと非指定されていないフォワーダー。これらは、特定のPEが特定のESで持つことができる役割です。
ECMP:
ECMP：
Equal-Cost Multipath
等しいコストマルチパス
ES:
ES：
Ethernet Segment. When a Tenant System (TS) is connected to one or more NVEs via a set of Ethernet links, that set of links is referred to as an "Ethernet Segment". Each ES is represented by a unique Ethernet Segment Identifier (ESI) in the NVO3 network, and the ESI is used in EVPN routes that are specific to that ES.
イーサネットセグメント。テナントシステム（TS）がイーサネットリンクのセットを介して1つ以上のNVEに接続されている場合、そのリンクのセットは「イーサネットセグメント」と呼ばれます。各ESは、NVO3ネットワークの一意のイーサネットセグメント識別子（ESI）で表され、ESIはそのESに固有のEVPNルートで使用されます。
Ethernet Tag:
イーサネットタグ：
Used to represent a Broadcast Domain that is configured on a given ES for the purpose of Designated Forwarder election. Note that any of the following may be used to represent a Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs, VNIs, normalized VIDs, Service Instance Identifiers (I-SIDs), etc., as long as the representation of the Broadcast Domains is configured consistently across the multihomed PEs attached to that ES.
指定されたフォワーダー選挙を目的として、特定のESで構成されているブロードキャストドメインを表すために使用されます。以下のいずれかを、ブロードキャストドメインを表すために使用できることに注意してください：VIDS（Q-in-Qタグを含む）、構成されたID、VNIS、正規化されたVIDS、サービスインスタンス識別子（I-SID）など。ブロードキャストドメインの表現は、そのESに接続されたマルチホームPE全体で一貫して構成されています。
EVI or EVPN Instance:
EVIまたはEVPNインスタンス：
A Layer 2 Virtual Network that uses an EVPN control plane to exchange reachability information among the member NVEs. It corresponds to a set of MAC-VRFs of the same tenant. See MAC-VRF in this section.
EVPNコントロールプレーンを使用して、メンバーNVEの間でリーチ性情報を交換するレイヤー2仮想ネットワーク。同じテナントのMAC-VRFのセットに対応します。このセクションのMAC-VRFを参照してください。
EVPN:
EVPN：
Ethernet Virtual Private Network, as described in [RFC7432].
[RFC7432]に記載されているように、イーサネット仮想プライベートネットワーク。
EVPN VLAN-Aware Bundle Service Interface:
EVPN VLAN-AWAREバンドルサービスインターフェイス：
Similar to the VLAN-bundle interface but each individual VLAN value is mapped to a different Broadcast Domain. In this interface, there are multiple Broadcast Domains per EVI for a given tenant. Each Broadcast Domain is identified by an "Ethernet Tag", which is a control plane value that identifies the routes for the Broadcast Domain within the EVI.
VLAN-Bundleインターフェイスと同様ですが、個々のVLAN値は別のブロードキャストドメインにマッピングされます。このインターフェースには、特定のテナントのEVIごとに複数のブロードキャストドメインがあります。各ブロードキャストドメインは、「イーサネットタグ」によって識別されます。これは、EVI内のブロードキャストドメインのルートを識別するコントロールプレーン値です。
EVPN VLAN-Based Service Interface:
EVPN VLANベースのサービスインターフェイス：
One of the three service interfaces defined in [RFC7432]. It is characterized as a Broadcast Domain that uses a single VLAN per physical access port to attach tenant traffic to the Broadcast Domain. In this service interface, there is only one Broadcast Domain per EVI.
[RFC7432]で定義されている3つのサービスインターフェイスの1つ。物理アクセスポートごとに単一のVLANを使用して、ブロードキャストドメインにテナントトラフィックを取り付けるブロードキャストドメインとして特徴付けられます。このサービスインターフェイスには、EVIごとにブロードキャストドメインが1つしかありません。
EVPN VLAN-Bundle Service Interface:
evpn vlan-bundleサービスインターフェイス：
Similar to the VLAN-based interface but uses a bundle of VLANs per physical port to attach tenant traffic to the Broadcast Domain. Like the VLAN-based interface, there is only one Broadcast Domain per EVI.
VLANベースのインターフェイスと同様ですが、物理ポートごとのVLANのバンドルを使用して、テナントトラフィックをブロードキャストドメインに取り付けます。VLANベースのインターフェイスと同様に、EVIごとにブロードキャストドメインは1つだけです。
Geneve:
Geneve：
Generic Network Virtualization Encapsulation. An NVO3 encapsulation defined in [RFC8926].
一般的なネットワーク仮想化カプセル化。[RFC8926]で定義されたNVO3カプセル化。
IP-VRF:
IP-VRF：
IP Virtual Routing and Forwarding table, as defined in [RFC4364]. It stores IP Prefixes that are part of the tenant's IP space and are distributed among NVEs of the same tenant by EVPN. A Route Distinguisher (RD) and one or more Route Targets (RTs) are required properties of an IP-VRF. An IP-VRF is instantiated in an NVE for a given tenant if the NVE is attached to multiple subnets of the tenant and local inter-subnet forwarding is required across those subnets.
[RFC4364]で定義されているIP仮想ルーティングと転送テーブル。テナントのIPスペースの一部であり、EVPNによって同じテナントのNVEに配布されるIPプレフィックスを保存します。ルート違い（RD）と1つ以上のルートターゲット（RT）がIP-VRFの必要なプロパティです。NVEがテナントの複数のサブネットに接続されている場合、IP-VRFは特定のテナントのNVEにインスタンス化され、これらのサブネット全体でローカルサブネット間転送が必要です。
IRB:
IRB：
Integrated Routing and Bridging. It refers to the logical interface that connects a Broadcast Domain instance (or a BT) to an IP-VRF and forwards packets with a destination in a different subnet.
統合されたルーティングとブリッジング。これは、ブロードキャストドメインインスタンス（またはBT）をIP-VRFに接続し、別のサブネットの宛先でパケットを転送する論理インターフェイスを指します。
MAC-VRF:
MAC-VRF：
A MAC Virtual Routing and Forwarding table, as defined in [RFC7432]. The instantiation of an EVI (EVPN Instance) in an NVE. A Route Distinguisher (RD) and one or more RTs are required properties of a MAC-VRF, and they are normally different from the ones defined in the associated IP-VRF (if the MAC-VRF has an IRB interface).
[RFC7432]で定義されているMAC仮想ルーティングと転送テーブル。NVEでのEVI（EVPNインスタンス）のインスタンス化。ルートの識別装置（RD）と1つ以上のRTは、MAC-VRFの必要なプロパティであり、通常は関連するIP-VRFで定義されているものとは異なります（MAC-VRFにIRBインターフェイスがある場合）。
NVE:
nve：
Network Virtualization Edge. A network entity that sits at the edge of an underlay network and implements Layer 2 and/or Layer 3 network virtualization functions. The network-facing side of the NVE uses the underlying Layer 3 network to tunnel tenant frames to and from other NVEs. The tenant-facing side of the NVE sends and receives Ethernet frames to and from individual Tenant Systems. In this document, an NVE could be implemented as a virtual switch within a hypervisor, a switch, or a router, and it runs EVPN in the control plane.
ネットワーク仮想化エッジ。アンダーレイネットワークの端に位置し、レイヤー2および/またはレイヤー3ネットワーク仮想化関数を実装するネットワークエンティティ。NVEのネットワーク向け側は、基礎となるレイヤー3ネットワークを使用して、他のNVEとの間でテナントフレームをトンネルします。NVEのテナント向け側は、個々のテナントシステムを送信および受信します。このドキュメントでは、NVEをハイパーバイザー、スイッチ、またはルーター内の仮想スイッチとして実装でき、コントロールプレーンでEVPNを実行します。
NVO3 tunnels:
NVO3トンネル：
Network Virtualization over Layer 3 tunnels. In this document, NVO3 tunnels refer to a way to encapsulate tenant frames or packets into IP packets, whose IP Source Addresses (SAs) or Destination Addresses (DAs) belong to the underlay IP address space, and identify NVEs connected to the same underlay network. Examples of NVO3 tunnel encapsulations are VXLAN [RFC7348], Geneve [RFC8926], or MPLSoUDP [RFC7510].
レイヤー3トンネル上のネットワーク仮想化。このドキュメントでは、NVO3トンネルは、IPソースアドレス（SAS）または宛先アドレス（DA）がアンダーレイIPアドレススペースに属し、同じアンダーレイネットワークに接続されているNVEを識別するIPソースアドレス（SAS）または宛先アドレス（DA）にIPパケットにテナントフレームまたはパケットをカプセル化する方法を指します。。NVO3トンネルのカプセルの例は、VXLAN [RFC7348]、Geneve [RFC8926]、またはMplSoudp [RFC7510]です。
PE:
PE：
Provider Edge
プロバイダーエッジ
PMSI:
PMSI：
Provider Multicast Service Interface
プロバイダーマルチキャストサービスインターフェイス
PTA:
PTA：
PMSI Tunnel Attribute
PMSIトンネル属性
RT and RD:
RTとRD：
Route Target and Route Distinguisher, respectively.
それぞれルートターゲットとルートの区別器。
RT-1, RT-2, RT-3, etc.:
RT-1、RT-2、RT-3など。
These refer to the Route Types followed by the type numbers as defined in the "EVPN Route Types" IANA registry (see <https://www.iana.org/assignments/evpn/>).
これらは、「EVPNルートタイプ」IANAレジストリで定義されているタイプ番号が続くルートタイプを指します（<https://www.iana.org/assignments/evpn/>を参照）。
SA and DA:
SAとDA：
Source Address and Destination Address, respectively. They are used along with MAC or IP, e.g., IP SA or MAC DA.
それぞれソースアドレスと宛先アドレス。それらは、MacまたはIP、例えばIP SAまたはMAC DAとともに使用されます。
SBD:
SBD：
Supplementary Broadcast Domain, as defined in [RFC9136]. It is a Broadcast Domain that does not have any Attachment Circuits, only has IRB interfaces, and provides connectivity among all the IP-VRFs of a tenant in the Interface-ful IP-VRF-to-IP-VRF models.
[RFC9136]で定義されている補足放送ドメイン。これは、アタッチメントサーキットがなく、IRBインターフェイスのみがあり、インターフェイスフルIP-VRFからIP-VRFモデルのテナントのすべてのIP-VRF間の接続を提供するブロードキャストドメインです。
TS:
TS：
Tenant System. A physical or virtual system that can play the role of a host or a forwarding element, such as a router, switch, firewall, etc. It belongs to a single tenant and connects to one or more Broadcast Domains of that tenant.
テナントシステム。ルーター、スイッチ、ファイアウォールなど、ホストまたは転送要素の役割を再生できる物理的または仮想システム。単一のテナントに属し、そのテナントの1つ以上のブロードキャストドメインに接続します。
VID:
ビデオ：
Virtual Local Area Network Identifier
仮想ローカルエリアネットワーク識別子
VNI:
VNI：
Virtual Network Identifier. Irrespective of the NVO3 encapsulation, the tunnel header always includes a VNI that is added at the ingress NVE (based on the mapping table lookup) and identifies the BT at the egress NVE. This VNI is called VNI in VXLAN or Geneve, Virtual Subnet ID (VSID) in nvGRE, or Label in MPLSoGRE or MPLSoUDP. This document refers to VNI as a generic VNI for any NVO3 encapsulation.
仮想ネットワーク識別子。NVO3のカプセル化に関係なく、トンネルヘッダーには常に、イングレスNVEに追加されるVNI（マッピングテーブルの検索に基づいて）が含まれ、出口NVEでBTを識別します。このVNIは、VXLANまたはGeneveのVNI、NVGREの仮想サブネットID（VSID）、またはmplsogreまたはmplsoudpのラベルと呼ばれます。このドキュメントでは、VNIをNVO3カプセル化の汎用VNIと呼んでいます。
VXLAN:
vxlan：
Virtual eXtensible Local Area Network. An NVO3 encapsulation defined in [RFC7348].
仮想拡張可能なローカルエリアネットワーク。[RFC7348]で定義されたNVO3カプセル化。
Data Centers have adopted NVO3 architectures mostly due to the issues discussed in [RFC7364]. The architecture of a Data Center is nowadays based on a Clos design, where every Leaf is connected to a layer of Spines and there is a number of ECMPs between any two Leaf nodes. All the links between Leaf and Spine nodes are routed links, forming what we also know as an underlay IP Fabric. The underlay IP Fabric does not have issues with loops or flooding (like old Spanning Tree Data Center designs did), convergence is fast, and ECMP generally distributes utilization well across all the links.
データセンターは、主に[RFC7364]で議論されている問題のためにNVO3アーキテクチャを採用しています。データセンターのアーキテクチャは、現在、すべての葉が背骨の層に接続されており、2つの葉のノードの間に多くのECMPがあります。リーフノードとスパインノードの間のすべてのリンクはルーティングされたリンクであり、アンダーレイIPファブリックとしても知っているものを形成します。アンダーレイIPファブリックには、ループや洪水の問題はありません（古いスパニングツリーデータセンターのデザインが行ったように）、収束は高速であり、ECMPは一般にすべてのリンクに使用率を十分に分配します。
On this architecture, and as discussed by [RFC7364], multi-tenant intra-subnet and inter-subnet connectivity services are provided by NVO3 tunnels. VXLAN [RFC7348] and Geneve [RFC8926] are two examples of such NVO3 tunnels.
このアーキテクチャでは、[RFC7364]で議論されているように、マルチテナント内部およびサブネット間接続サービスはNVO3トンネルによって提供されます。VXLAN [RFC7348]およびGeneve [RFC8926]は、そのようなNVO3トンネルの2つの例です。
Why is a control plane protocol along with NVO3 tunnels helpful? There are three main reasons:
NVO3トンネルとともにコントロールプレーンのプロトコルが役立つのはなぜですか？主な理由は3つあります。
a. Auto-discovery of the remote NVEs that are attached to the same VPN instance (Layer 2 and/or Layer 3) as the ingress NVE is.
a. 侵入NVEと同じVPNインスタンス（レイヤー2および/またはレイヤー3）に取り付けられているリモートNVEの自動発見。
b. Dissemination of the MAC/IP host information so that mapping tables can be populated on the remote NVEs.
b. マッピングテーブルをリモートNVEに入力できるように、MAC/IPホスト情報の普及。
c. Advanced features such as MAC Mobility, MAC Protection, BUM and ARP/ND traffic reduction/suppression, multihoming, functionality similar to Prefix Independent Convergence (PIC) [BGP-PIC], fast convergence, etc.
c. MACモビリティ、MAC保護、バム、ARP/ndトラフィックの削減/抑制などの高度な機能、マルチホーム、プレフィックス独立コンバージェンス（PIC）[BGP-PIC]、高速収束などと同様の機能。
"Flood and learn" is a possible approach to achieve points (a) and (b) above for multipoint Ethernet services. "Flood and learn" refers to "flooding" BUM traffic from the ingress NVE to all the egress NVEs attached to the same Broadcast Domain instead of using a specific control plane on the NVEs. The egress NVEs may then use data path source MAC address "learning" on the frames received over the NVO3 tunnels. When the destination host replies and the frames arrive at the NVE that initially flooded BUM frames, the NVE will also "learn" the source MAC address of the frame encapsulated on the NVO3 tunnel. This approach has the following drawbacks:
「洪水と学習」は、マルチポイントイーサネットサービスで上記のポイント（a）および（b）を達成するための可能なアプローチです。「Flood and Learn」とは、NVEで特定のコントロールプレーンを使用する代わりに、イングレスNVEから同じブロードキャストドメインに接続されたすべての出力NVEへの「洪水」のトラフィックを指します。Engress NVEは、NVO3トンネルで受信したフレームでデータパスソースMacアドレス「学習」を使用する場合があります。宛先ホストが応答し、フレームが最初にバムフレームを浸水させたNVEに到着すると、NVEはNVO3トンネルにカプセル化されたフレームのソースMACアドレスも「学習」します。このアプローチには次の欠点があります。
* In order to flood a given BUM frame, the ingress NVE must know the IP addresses of the remote NVEs attached to the same Broadcast Domain. This may be done as follows:
* 特定のバムフレームに浸水するために、侵入NVEは同じブロードキャストドメインに接続されたリモートNVEのIPアドレスを知る必要があります。これは次のように行うことができます：
- The remote tunnel IP addresses can be statically provisioned on the ingress NVE. If the ingress NVE receives a BUM frame for the Broadcast Domain on an ingress Attachment Circuit, it will do ingress replication and will send the frame to all the configured egress NVE destination IP addresses in the Broadcast Domain.
- リモートトンネルIPアドレスは、侵入NVEで静的にプロビジョニングできます。イングレスNVEがイングレスアタッチメント回路でブロードキャストドメインのバムフレームを受信すると、侵入レプリケーションが行われ、ブロードキャストドメイン内のすべての設定されたEgress NVE宛先IPアドレスにフレームが送信されます。
- All the NVEs attached to the same Broadcast Domain can subscribe to an underlay IP multicast group that is dedicated to that Broadcast Domain. When an ingress NVE receives a BUM frame on an ingress Attachment Circuit, it will send a single copy of the frame encapsulated into an NVO3 tunnel using the multicast address as the destination IP address of the tunnel. This solution requires PIM in the underlay network and the association of individual Broadcast Domains to underlay IP multicast groups.
- 同じブロードキャストドメインに接続されているすべてのNVEは、そのブロードキャストドメイン専用のアンダーレイIPマルチキャストグループに購読できます。イングレスNVEがイングレスアタッチメント回路でバムフレームを受信すると、トンネルの宛先IPアドレスとしてマルチキャストアドレスを使用して、NVO3トンネルにカプセル化されたフレームの単一のコピーを送信します。このソリューションでは、アンダーレイネットワーク内のPIMと、IPマルチキャストグループのアンダーレイに個々のブロードキャストドメインの関連付けが必要です。
* "Flood and learn" solves the issues of auto-discovery and the learning of the MAC to VNI/tunnel IP mapping on the NVEs for a given Broadcast Domain. However, it does not provide a solution for advanced features, and it does not scale well (mostly due to the need for constant flooding and the underlay PIM states that must be maintained).
* 「Flood and Learn」は、自動発見の問題と、特定のブロードキャストドメインのNVESでのVNI/トンネルIPマッピングへのMacの学習の問題を解決します。ただし、高度な機能のソリューションを提供するものではなく、適切にスケーリングすることはありません（主に、一定の洪水の必要性と、維持する必要があるアンダーレイPIM状態のため）。
EVPN provides a unified control plane that solves the issues of NVE auto-discovery, tenant MAC/IP dissemination, and advanced features in a scalable way and keeps the independence of the underlay IP Fabric; i.e., there is no need to enable PIM in the underlay network and maintain multicast states for tenant Broadcast Domains.
EVPNは、NVEオートディスコービリ、テナントMAC/IP普及、および高度な機能の問題をスケーラブルな方法で解決し、アンダーレイIPファブリックの独立性を維持する統一制御プレーンを提供します。つまり、アンダーレイネットワークでPIMを有効にし、テナントブロードキャストドメインのマルチキャスト状態を維持する必要はありません。
Section 4 describes how EVPN can be used to meet the control plane requirements in an NVO3 network.
セクション4では、EVPNを使用してNVO3ネットワークのコントロールプレーン要件を満たす方法について説明します。
This section discusses the applicability of EVPN to NVO3 networks. The intent is not to provide a comprehensive explanation of the protocol itself, but to give an introduction and point at the corresponding reference document so the reader can easily find more details if needed.
このセクションでは、EVPNのNVO3ネットワークへの適用性について説明します。意図は、プロトコル自体の包括的な説明を提供することではなく、対応する参照ドキュメントの紹介とポイントを提供して、読者が必要に応じて簡単に詳細を見つけることができるようにすることです。
EVPN supports multiple Route Types, and each type has a different function. For convenience, Table 1 shows a summary of all the existing EVPN Route Types and their usages. In this document, we may refer to these route types as RT-x routes, where x is the type number included in the first column of Table 1.
EVPNは複数のルートタイプをサポートし、各タイプの関数は異なります。便利なため、表1は、既存のすべてのEVPNルートタイプとその使用の要約を示しています。このドキュメントでは、これらのルートタイプをRT-Xルートと呼ぶことができます。ここで、xは表1の最初の列に含まれるタイプ番号です。
+======+================+=======================================+
| Type | Description | Usage |
+======+================+=======================================+
| 1 | Ethernet Auto- | Multihoming: Used for MAC mass- |
| | Discovery | withdraw when advertised per Ethernet |
| | | Segment and for aliasing/backup |
| | | functions when advertised per EVI. |
+------+----------------+---------------------------------------+
| 2 | MAC/IP | Host MAC/IP dissemination; supports |
| | Advertisement | MAC Mobility and protection. |
+------+----------------+---------------------------------------+
| 3 | Inclusive | NVE discovery and BUM flooding tree |
| | Multicast | setup. |
| | Ethernet Tag | |
+------+----------------+---------------------------------------+
| 4 | Ethernet | Multihoming: ES auto-discovery and DF |
| | Segment | election. |
+------+----------------+---------------------------------------+
| 5 | IP Prefix | IP Prefix dissemination. |
+------+----------------+---------------------------------------+
| 6 | Selective | Indicate interest for a multicast S,G |
| | Multicast | or *,G. |
| | Ethernet Tag | |
+------+----------------+---------------------------------------+
| 7 | Multicast Join | Multihoming: S,G or *,G state synch. |
| | Synch | |
+------+----------------+---------------------------------------+
| 8 | Multicast | Multihoming: S,G or *,G leave synch. |
| | Leave Synch | |
+------+----------------+---------------------------------------+
| 9 | Per-Region | BUM tree creation across regions. |
| | I-PMSI A-D | |
+------+----------------+---------------------------------------+
| 10 | S-PMSI A-D | Multicast tree for S,G or *,G states. |
+------+----------------+---------------------------------------+
| 11 | Leaf A-D | Used for responses to explicit |
| | | tracking. |
+------+----------------+---------------------------------------+
Table 1: EVPN Route Types
表1：EVPNルートタイプ
Although the applicability of EVPN to NVO3 networks spans multiple documents, EVPN's baseline specification is [RFC7432]. [RFC7432] allows multipoint Layer 2 VPNs to be operated as IP VPNs [RFC4364], where MACs and the information to set up flooding trees are distributed by Multiprotocol BGP (MP-BGP) [RFC4760]. Based on [RFC7432], [RFC8365] describes how to use EVPN to deliver Layer 2 services specifically in NVO3 networks.
NVO3ネットワークへのEVPNの適用性は複数のドキュメントに及びますが、EVPNのベースライン仕様は[RFC7432]です。[RFC7432]により、マルチポイントレイヤー2 VPNをIP VPNS [RFC4364]として動作させることができます。ここで、Macと洪水ツリーをセットアップする情報は、マルチプロトコルBGP（MP-BGP）[RFC4760]によって分布しています。[RFC7432]に基づいて、[RFC8365]は、EVPNを使用してNVO3ネットワークでレイヤー2サービスを提供する方法について説明します。
Figure 1 represents a Layer 2 service deployed with an EVPN Broadcast Domain in an NVO3 network.
図1は、NVO3ネットワークにEVPNブロードキャストドメインを使用して展開されたレイヤー2サービスを表しています。
+--TS2---+
* | Single-Active
* | ESI-1
+----+ +----+
|BD1 | |BD1 |
+-------------| |--| |-----------+
| +----+ +----+ |
| NVE2 NVE3 NVE4
| EVPN NVO3 Network +----+
NVE1(IP-A) | BD1|-----+
+-------------+ RT-2 | | |
| | +-------+ +----+ |
| +----+ | |MAC1 | NVE5 TS3
TS1--------|BD1 | | |IP1 | +----+ |
MAC1 | +----+ | |Label L|---> | BD1|-----+
IP1 | | |NH IP-A| | | All-Active
| Hypervisor | +-------+ +----+ ESI-2
+-------------+ |
+--------------------------------------+
Figure 1: EVPN for L2 in an NVO3 Network - Example
図1：NVO3ネットワークのL2のEVPN-例 - 例
In a simple NVO3 network, such as the example of Figure 1, these are the basic constructs that EVPN uses for Layer 2 services (or Layer 2 Virtual Networks):
図1の例などの単純なNVO3ネットワークでは、これらはEVPNがレイヤー2サービス（またはレイヤー2仮想ネットワーク）に使用する基本的な構成要素です。
* BD1 is an EVPN Broadcast Domain for a given tenant and TS1, TS2, and TS3 are connected to it. The five represented NVEs are attached to BD1 and are connected to the same underlay IP network. That is, each NVE learns the remote NVEs' loopback addresses via underlay routing protocol.
* BD1は、特定のテナントのEVPNブロードキャストドメインであり、TS1、TS2、およびTS3が接続されています。5つの表現されたNVEはBD1に接続され、同じアンダーレイIPネットワークに接続されています。つまり、各NVEは、アンダーレイルーティングプロトコルを介してリモートNVESのループバックアドレスを学習します。
* NVE1 is deployed as a virtual switch in a hypervisor with IP-A as underlay loopback IP address. The rest of the NVEs in Figure 1 are physical switches and TS2/TS3 are multihomed to them. TS1 is a virtual machine, identified by MAC1 and IP1. TS2 and TS3 are physically dual-connected to NVEs; hence, they are normally not considered virtual machines.
* NVE1は、IP-AをアンダーレイループバックIPアドレスとして、ハイパーバイザーの仮想スイッチとして展開されます。図1のNVEの残りの部分は物理スイッチで、TS2/TS3はそれらにマルチホームされています。TS1は仮想マシンで、MAC1とIP1によって識別されます。TS2とTS3は、物理的にNVESにデュアル接続されています。したがって、それらは通常、仮想マシンとは見なされません。
* The terms Single-Active and All-Active in Figure 1 refer to the mode in which the TS2 and TS3 are multihomed to the NVEs in BD1. In All-Active mode, all the multihoming links are active and can send or receive traffic. In Single-Active mode, only one link (of the set of links connected to the NVEs) is active.
* 図1の単一活動的ですべての活動的な用語は、TS2とTS3がBD1のNVESにマルチホームされているモードを指します。オールアクティブモードでは、すべてのマルチホームリンクがアクティブであり、トラフィックを送信または受信できます。シングルアクティブモードでは、（NVEに接続されたリンクのセットの）リンクのみがアクティブです。
Auto-discovery is one of the basic capabilities of EVPN. The provisioning of EVPN components in NVEs is significantly automated, simplifying the deployment of services and minimizing manual operations that are prone to human error.
自動発見は、EVPNの基本的な機能の1つです。NVESでのEVPNコンポーネントのプロビジョニングは大幅に自動化されており、サービスの展開を簡素化し、ヒューマンエラーが発生しやすい手動操作を最小限に抑えます。
These are some of the auto-discovery and auto-provisioning capabilities available in EVPN:
これらは、EVPNで利用可能な自動配置および自動プロビジョニング機能の一部です。
* Automation on Ethernet Segments (ESes): An Ethernet Segment is defined as a group of NVEs that are attached to the same Tenant System or network. An Ethernet Segment is identified by an Ethernet Segment Identifier (ESI) in the control plane, but neither the ESI nor the NVEs that share the same Ethernet Segment are required to be manually provisioned in the local NVE.
* イーサネットセグメント（ESE）の自動化：イーサネットセグメントは、同じテナントシステムまたはネットワークに接続されているNVEのグループとして定義されます。イーサネットセグメントは、コントロールプレーンのイーサネットセグメント識別子（ESI）によって識別されますが、同じイーサネットセグメントを共有するESIもNVEもローカルNVEで手動でプロビジョニングする必要はありません。
- If the multihomed Tenant System or network is running protocols, such as the Link Aggregation Control Protocol (LACP) [IEEE.802.1AX_2014], the Multiple Spanning Tree Protocol (MSTP), G.8032, etc., and all the NVEs in the Ethernet Segment can listen to the protocol PDUs to uniquely identify the multihomed Tenant System/network, then the ESI can be "auto-sensed" or "auto-provisioned" following the guidelines in Section 5 of [RFC7432]. The ESI can also be auto-derived out of other parameters that are common to all NVEs attached to the same Ethernet Segment.
- マルチホームテナントシステムまたはネットワークがリンク集約制御プロトコル（LACP）[IEEE.802.1AX_2014]などのプロトコルを実行している場合、多重スパニングツリープロトコル（MSTP）、G.8032など、およびすべてのNVEがイーサネットセグメントは、プロトコルPDUをリッスンしてマルチホームテナントシステム/ネットワークを一意に識別できます。その後、ESIは[RFC7432]のセクション5のガイドラインに従って「自動感覚」または「自動プロビジョニング」を行うことができます。ESIは、同じイーサネットセグメントに接続されているすべてのNVEに共通する他のパラメーターから自動化することもできます。
- As described in [RFC7432], EVPN can also auto-derive the BGP parameters required to advertise the presence of a local Ethernet Segment in the control plane (RT and RD). Local Ethernet Segments are advertised using Ethernet Segment routes, and the ESI-import Route Target used by Ethernet Segment routes can be auto-derived based on the procedures of Section 7.6 of [RFC7432].
- [RFC7432]で説明されているように、EVPNは、コントロールプレーン（RTおよびRD）のローカルイーサネットセグメントの存在を宣伝するために必要なBGPパラメーターを自動化することもできます。ローカルイーサネットセグメントはイーサネットセグメントルートを使用して宣伝されており、イーサネットセグメントルートで使用されるESI-Importルートターゲットは、[RFC7432]のセクション7.6の手順に基づいて自動由来することができます。
- By listening to other Ethernet Segment routes that match the local ESI and import Route Target, an NVE can also auto-discover the other NVEs participating in the multihoming for the Ethernet Segment.
- ローカルESIとインポートルートターゲットに一致する他のイーサネットセグメントルートを聴くことにより、NVEは、イーサネットセグメントのマルチホームに参加する他のNVEを自動discoverすることもできます。
- Once the NVE has auto-discovered all the NVEs attached to the same Ethernet Segment, the NVE can automatically perform the Designated Forwarder election algorithm (which determines the NVE that will forward traffic to the multihomed Tenant System/ network). EVPN guarantees that all the NVEs in the Ethernet Segment have a consistent Designated Forwarder election.
- NVEが同じイーサネットセグメントに接続されたすべてのNVEを自動分割すると、NVEは指定されたフォワーダー選挙アルゴリズムを自動的に実行できます（マルチホームテナントシステム/ネットワークにトラフィックを転送するNVEを決定します）。EVPNは、イーサネットセグメント内のすべてのNVEが一貫した指定されたフォワーダー選挙を持っていることを保証します。
* Auto-provisioning of services: When deploying a Layer 2 service for a tenant in an NVO3 network, all the NVEs attached to the same subnet must be configured with a MAC-VRF and the Broadcast Domain for the subnet, as well as certain parameters for them. Note that if the EVPN service interfaces are VLAN-based or VLAN-bundle, implementations do not normally have a specific provisioning for the Broadcast Domain since, in this case, it is the same construct as the MAC-VRF. EVPN allows auto-deriving as many MAC-VRF parameters as possible. As an example, the MAC-VRF's Route Target and Route Distinguisher for the EVPN routes may be auto-derived. Section 5.1.2.1 of [RFC8365] specifies how to auto-derive a MAC-VRF's Route Target as long as a VLAN-based service interface is implemented. [RFC7432] specifies how to auto-derive the Route Distinguisher.
* サービスの自動プロビジョニング：NVO3ネットワーク内のテナント用のレイヤー2サービスを展開する場合、同じサブネットに接続されたすべてのNVEをMAC-VRFとサブネット用のブロードキャストドメイン、および特定のパラメーターで構成する必要があります。彼ら。EVPNサービスインターフェイスがVLANベースまたはVLANバンドルである場合、実装には通常、ブロードキャストドメインの特定のプロビジョニングがないことに注意してください。この場合、MAC-VRFと同じ構成要素です。EVPNは、できるだけ多くのMAC-VRFパラメーターをできるだけ自動排出することができます。例として、EVPNルートのMAC-VRFのルートターゲットとルートの違いが自動化される場合があります。[RFC8365]のセクション5.1.2.1は、VLANベースのサービスインターフェイスが実装されている限り、MAC-VRFのルートターゲットを自動化する方法を指定します。[RFC7432]は、ルートの違いを自動化する方法を指定します。
Auto-discovery via MP-BGP [RFC4760] is used to discover the remote NVEs attached to a given Broadcast Domain, the NVEs participating in a given redundancy group, the tunnel encapsulation types supported by an NVE, etc.
MP-BGP [RFC4760]を介した自動発見は、特定のブロードキャストドメインに接続されているリモートNVE、特定の冗長グループに参加するNVE、NVEでサポートされるトンネルカプセル化タイプを発見するために使用されます。
In particular, when a new MAC-VRF and Broadcast Domain are enabled, the NVE will advertise a new Inclusive Multicast Ethernet Tag route. Besides other fields, the Inclusive Multicast Ethernet Tag route will encode the IP address of the advertising NVE, the Ethernet Tag (which is zero in the case of VLAN-based and VLAN-bundle interfaces), and a PMSI Tunnel Attribute (PTA) that indicates the information about the intended way to deliver BUM traffic for the Broadcast Domain.
特に、新しいMAC-VRFとブロードキャストドメインが有効になっている場合、NVEは新しい包括的マルチキャストイーサネットタグルートを宣伝します。他のフィールドに加えて、包括的なマルチキャストイーサネットタグルートは、広告NVEのIPアドレス、イーサネットタグ（VLANベースおよびVLANバンドルインターフェイスの場合はゼロ）、およびPMSIトンネル属性（PTA）をエンコードします。ブロードキャストドメインにバムトラフィックを配信するための意図された方法に関する情報を示します。
When BD1 is enabled in the example of Figure 1, NVE1 will send an Inclusive Multicast Ethernet Tag route including its own IP address, an Ethernet-Tag for BD1, and the PMSI Tunnel Attribute to the remote NVEs. Assuming Ingress Replication (IR) is used, the Inclusive Multicast Ethernet Tag route will include an identification for Ingress Replication in the PMSI Tunnel Attribute and the VNI that the other NVEs in the Broadcast Domain must use to send BUM traffic to the advertising NVE. The other NVEs in the Broadcast Domain will import the Inclusive Multicast Ethernet Tag route and will add NVE1's IP address to the flooding list for BD1. Note that the Inclusive Multicast Ethernet Tag route is also sent with a BGP encapsulation attribute [RFC9012] that indicates what NVO3 encapsulation the remote NVEs should use when sending BUM traffic to NVE1.
図1の例でBD1が有効になっている場合、NVE1は独自のIPアドレス、BD1のイーサネットタグ、およびリモートNVESのPMSIトンネル属性を含む包括的なマルチキャストイーサネットタグルートを送信します。Ingress Replication（IR）が使用されると仮定すると、包括的なマルチキャストイーサネットタグルートには、PMSIトンネル属性のイングレスレプリケーションの識別と、ブロードキャストドメインの他のNVEが広告NVEにバムトラフィックを送信するために使用する必要があるVNIが含まれます。ブロードキャストドメインの他のNVEは、包括的マルチキャストイーサネットタグルートをインポートし、NVE1のIPアドレスをBD1のフラッディングリストに追加します。インクルーシブマルチキャストイーサネットタグルートは、BGPカプセル化属性[RFC9012]で送信されることに注意してください。
Refer to [RFC7432] for more information about the Inclusive Multicast Ethernet Tag route and forwarding of BUM traffic. See [RFC8365] for its considerations on NVO3 networks.
包括的なマルチキャストイーサネットタグルートとバムトラフィックの転送の詳細については、[RFC7432]を参照してください。NVO3ネットワークに関する考慮事項については、[RFC8365]を参照してください。
Tenant MAC/IP information is advertised to remote NVEs using MAC/IP Advertisement routes. Following the example of Figure 1:
テナントMac/IP情報は、Mac/IP広告ルートを使用してリモートNVEに宣伝されます。図1の例に従ってください。
* In a given EVPN Broadcast Domain, the MAC addresses of TSes are first learned at the NVE they are attached to via data path or management plane learning. In Figure 1, we assume NVE1 learns MAC1/IP1 in the management plane (for instance, via Cloud Management System) since the NVE is a virtual switch. NVE2, NVE3, NVE4, and NVE5 are ToR/Leaf switches, and they normally learn MAC addresses via data path.
* 特定のEVPNブロードキャストドメインでは、TSEのMACアドレスは、データパスまたは管理プレーン学習を介して添付されているNVEで最初に学習されます。図1では、NVEが仮想スイッチであるため、NVE1が管理プレーン（たとえば、クラウド管理システムを介して）でMAC1/IP1を学習すると仮定します。NVE2、NVE3、NVE4、およびNVE5はTOR/リーフスイッチであり、通常、データパスを介してMACアドレスを学習します。
* Once NVE1's BD1 learns MAC1/IP1, NVE1 advertises that information along with a VNI and Next-Hop IP-A in a MAC/IP Advertisement route. The EVPN routes are advertised using the Route Distinguisher / Route Targets of the MAC-VRF where the Broadcast Domain belongs. Similarly, all the NVEs in BD1 learn local MAC/IP addresses and advertise them in MAC/IP Advertisement routes.
* NVE1のBD1がMAC1/IP1を学習すると、NVE1はMAC/IP広告ルートでVNIおよびNext-Hop IP-Aとともにその情報を宣伝します。EVPNルートは、ブロードキャストドメインが属しているMAC-VRFのルートdistiutisuriuther /ルートターゲットを使用して宣伝されます。同様に、BD1のすべてのNVEはローカルMAC/IPアドレスを学習し、Mac/IP広告ルートで広告します。
* The remote NVEs can then add MAC1 to their mapping table for BD1 (BT). For instance, when TS3 sends frames to NVE4 with the destination MAC address = MAC1, NVE4 does a MAC lookup on the Bridge Table that yields IP-A and Label L. NVE4 can then encapsulate the frame into an NVO3 tunnel with IP-A as the tunnel destination IP address and L as the VNI. Note that the MAC/IP Advertisement route may also contain the host's IP address (as shown in the example of Figure 1). While the MAC of the received MAC/IP Advertisement route is installed in the Bridge Table, the IP address may be installed in the Proxy ARP/ND table (if enabled) or in the ARP/IP-VRF tables if the Broadcast Domain has an IRB. See Section 4.7.3 for more information about Proxy ARP/ND and Section 4.3 for more details about IRB and Layer 3 services.
* リモートNVEは、BD1（BT）のマッピングテーブルにMac1を追加できます。たとえば、TS3が宛先MACアドレス= MAC1でフレームをNVE4に送信すると、NVE4はBridgeテーブルでMACルックアップを行い、IP-AとラベルL. NVE4がIP-Aを使用してNVO3トンネルにフレームをカプセル化できます。トンネルの宛先IPアドレスとlがVNIとして。Mac/IP広告ルートには、ホストのIPアドレスも含まれている場合があることに注意してください（図1の例に示すように）。受信したMac/IP広告ルートのMacがブリッジテーブルにインストールされていますが、IPアドレスはプロキシARP/NDテーブル（有効な場合）またはARP/IP-VRFテーブルにインストールされます。IRB。Proxy ARP/NDの詳細については、IRBおよびレイヤー3サービスの詳細については、セクション4.7.3およびセクション4.3を参照してください。
Refer to [RFC7432] and [RFC8365] for more information about the MAC/ IP Advertisement route and the forwarding of known unicast traffic.
MAC/ IP広告ルートと既知のユニキャストトラフィックの転送の詳細については、[RFC7432]および[RFC8365]を参照してください。
[RFC9136] and [RFC9135] are the reference documents that describe how EVPN can be used for Layer 3 services. Inter-subnet forwarding in EVPN networks is implemented via IRB interfaces between Broadcast Domains and IP-VRFs. An EVPN Broadcast Domain corresponds to an IP subnet. When IP packets generated in a Broadcast Domain are destined to a different subnet (different Broadcast Domain) of the same tenant, the packets are sent to the IRB attached to the local Broadcast Domain in the source NVE. As discussed in [RFC9135], depending on how the IP packets are forwarded between the ingress NVE and the egress NVE, there are two forwarding models: Asymmetric and Symmetric.
[RFC9136]および[RFC9135]は、レイヤー3サービスにEVPNを使用する方法を説明する参照ドキュメントです。EVPNネットワークでのサブネット間転送は、ブロードキャストドメインとIP-VRFの間のIRBインターフェイスを介して実装されます。EVPNブロードキャストドメインは、IPサブネットに対応します。ブロードキャストドメインで生成されたIPパケットが同じテナントの別のサブネット（異なるブロードキャストドメイン）に運命づけられる場合、パケットはソースNVEのローカルブロードキャストドメインに接続されたIRBに送信されます。[RFC9135]で説明したように、IPパケットがイングレスNVEと出口NVEの間にどのように転送されるかに応じて、非対称と対称の2つの転送モデルがあります。
The Asymmetric model is illustrated in the example of Figure 2, and it requires the configuration of all the Broadcast Domains of the tenant in all the NVEs attached to the same tenant. That way, there is no need to advertise IP Prefixes between NVEs since all the NVEs are attached to all the subnets. It is called "Asymmetric" because the ingress and egress NVEs do not perform the same number of lookups in the data plane. In Figure 2, if TS1 and TS2 are in different subnets and TS1 sends IP packets to TS2, the following lookups are required in the data path: a MAC lookup at BD1's table, an IP lookup at the IP-VRF, a MAC lookup at BD2's table at the ingress NVE1, and only a MAC lookup at the egress NVE. The two IP-VRFs in Figure 2 are not connected by tunnels, and all the connectivity between the NVEs is done based on tunnels between the Broadcast Domains.
非対称モデルは図2の例に示されており、同じテナントに取り付けられたすべてのNVEのテナントのすべての放送ドメインの構成が必要です。そうすれば、すべてのNVEがすべてのサブネットに接続されているため、NVE間でIPプレフィックスを宣伝する必要はありません。侵入と出口のnveがデータプレーンで同じ数のルックアップを実行しないため、「非対称」と呼ばれます。図2では、TS1とTS2が異なるサブネットにあり、TS1がIPパケットをTS2に送信する場合、次の検索がデータパスで必要です。BD1のテーブルのMACルックアップ、IP-VRFのIPルックアップ、MAC検索Ingress NVE1のBD2のテーブル、および出口NVEのMAC検索のみ。図2の2つのIP-VRFはトンネルで接続されておらず、NVE間のすべての接続性はブロードキャストドメイン間のトンネルに基づいて行われます。
+-------------------------------------+
| EVPN NVO3 |
| |
NVE1 NVE2
+--------------------+ +--------------------+
| +---+IRB +------+ | | +------+IRB +---+ |
TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD1| |
| +---+ | | | | | | +---+ |
| +---+ | | | | | | +---+ |
| |BD2|----| | | | | |----|BD2|----TS2
| +---+IRB +------+ | | +------+IRB +---+ |
+--------------------+ +--------------------+
| |
+-------------------------------------+
Figure 2: EVPN for L3 in an NVO3 Network - Asymmetric Model
図2：NVO3ネットワークのL3のEVPN-非対称モデル
In the Symmetric model, depicted in Figure 3, the same number of data path lookups is needed at the ingress and egress NVEs. For example, if TS1 sends IP packets to TS3, the following data path lookups are required: a MAC lookup at NVE1's BD1 table, an IP lookup at NVE1's IP-VRF, and an IP lookup and MAC lookup at NVE2's IP-VRF and BD3, respectively. In the Symmetric model, the inter-subnet connectivity between NVEs is done based on tunnels between the IP-VRFs.
図3に示す対称モデルでは、入り込みと出口の同じ数のデータパスルックアップが必要です。たとえば、TS1がIPパケットをTS3に送信する場合、次のデータパス検索が必要です。NVE1のBD1テーブルのMAC検索、NVE1のIP-VRFのIPルックアップ、NVE2のIP-VRFおよびBD3のIPルックアップおよびMAC検索、 それぞれ。対称モデルでは、NVE間のサブネット間接続は、IP-VRF間のトンネルに基づいて行われます。
+-------------------------------------+
| EVPN NVO3 |
| |
NVE1 NVE2
+--------------------+ +--------------------+
| +---+IRB +------+ | | +------+IRB +---+ |
TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD3|-----TS3
| +---+ | | | | | | +---+ |
| +---+IRB | | | | +------+ |
TS2-----|BD2|----| | | +--------------------+
| +---+ +------+ | |
+--------------------+ |
| |
+-------------------------------------+
Figure 3: EVPN for L3 in an NVO3 Network - Symmetric Model
図3：NVO3ネットワークのL3のEVPN-対称モデル
The Symmetric model scales better than the Asymmetric model because it does not require the NVEs to be attached to all the tenant's subnets. However, it requires the use of NVO3 tunnels on the IP-VRFs and the exchange of IP Prefixes between the NVEs in the control plane. EVPN uses MAC/IP Advertisement routes for the exchange of host IP routes and IP Prefix routes for the exchange of prefixes of any length, including host routes. As an example, in Figure 3, NVE2 needs to advertise TS3's host route and/or TS3's subnet so that the IP lookup on NVE1's IP-VRF succeeds.
対称モデルは、NVEをすべてのテナントのサブネットに接続する必要がないため、非対称モデルよりもスケーリングします。ただし、IP-VRFでNVO3トンネルを使用し、コントロールプレーンのNVE間のIPプレフィックスの交換が必要です。EVPNは、ホストルートを含む任意の長さのプレフィックスを交換するために、ホストIPルートとIPプレフィックスルートを交換するためにMac/IP広告ルートを使用します。例として、図3では、NVE2はTS3のホストルートおよび/またはTS3のサブネットを宣伝する必要があり、NVE1のIP-VRFのIPルックアップが成功するようにします。
[RFC9135] specifies the use of MAC/IP Advertisement routes for the advertisement of host routes. Section 4.4.1 of [RFC9136] specifies the use of IP Prefix routes for the advertisement of IP Prefixes in an "Interface-less IP-VRF-to-IP-VRF Model". The Symmetric model for host routes can be implemented following either approach:
[RFC9135]ホストルートの広告にMAC/IP広告ルートの使用を指定します。[RFC9136]のセクション4.4.1は、「インターフェイスのないIP-VRF-T-T-IP-VRFモデル」でIPプレフィックスの広告にIPプレフィックスルートを使用することを指定しています。ホストルートの対称モデルは、どちらのアプローチに従って実装できます。
a. [RFC9135] uses MAC/IP Advertisement routes to convey the information to populate Layer 2, ARP/ND, and Layer 3 Forwarding Information Base tables in the remote NVE. For instance, in Figure 3, NVE2 would advertise a MAC/IP Advertisement route with TS3's IP and MAC addresses and include two labels / VNIs: a label-3/VNI-3 that identifies BD3 for MAC lookup (that would be used for Layer 2 traffic in case NVE1 was attached to BD3 too) and a label-1/VNI-1 that identifies the IP-VRF for IP lookup (that would be used for Layer 3 traffic). NVE1 imports the MAC/ IP Advertisement route and installs TS3's IP in the IP-VRF route table with label-1/VNI-1. Traffic, e.g., from TS2 to TS3, would be encapsulated with label-1/VNI-1 and forwarded to NVE2.
a. [RFC9135]は、MAC/IP広告ルートを使用して、レイヤー2、ARP/ND、およびレイヤー3の転送情報ベーステーブルをリモートNVEに入力するために情報を伝達します。たとえば、図3では、NVE2はTS3のIPアドレスとMACアドレスを備えたMAC/IP広告ルートを宣伝し、2つのラベル/VNIを含みます。NVE1もBD3に接続された場合の2トラフィックと、IPルックアップのIP-VRFを識別するLABEL-1/VNI-1（レイヤー3トラフィックに使用されます）。NVE1はMAC/ IP広告ルートをインポートし、Label-1/ VNI-1を使用してIP-VRFルートテーブルにTS3のIPをインストールします。たとえば、TS2からTS3へのトラフィックは、Label-1/VNI-1でカプセル化され、NVE2に転送されます。
b. [RFC9136] uses MAC/IP Advertisement routes to convey the information to populate the Layer 2 Forwarding Information Base, ARP/ND tables, and IP Prefix routes to populate the IP-VRF Layer 3 Forwarding Information Base table. For instance, in Figure 3, NVE2 would advertise a MAC/IP Advertisement route including TS3's MAC and IP addresses with a single label-3/VNI-3. In this example, this MAC/IP Advertisement route wouldn't be imported by NVE1 because NVE1 is not attached to BD3. In addition, NVE2 would advertise an IP Prefix route with TS3's IP address and label-1/VNI-1. This IP Prefix route would be imported by NVE1's IP-VRF and the host route installed in the Layer 3 Forwarding Information Base associated with label-1/VNI-1. Traffic from TS2 to TS3 would be encapsulated with label-1/VNI-1.
b. [RFC9136]は、MAC/IP広告ルートを使用して情報を伝達してレイヤー2転送情報ベース、ARP/NDテーブル、およびIPプレフィックスルートを設定して、IP-VRFレイヤー3転送情報ベーステーブルに入力します。たとえば、図3では、NVE2はTS3のMACアドレスとIPアドレスを含むMAC/IP広告ルートを、単一のラベル-3/VNI-3を宣伝します。この例では、NVE1がBD3に接続されていないため、このMAC/IP広告ルートはNVE1によってインポートされません。さらに、NVE2は、TS3のIPアドレスとLABEL-1/VNI-1を備えたIPプレフィックスルートを宣伝します。このIPプレフィックスルートは、NVE1のIP-VRFによってインポートされ、ラベル1/VNI-1に関連付けられたレイヤー3転送情報ベースにインストールされます。TS2からTS3へのトラフィックは、LABEL-1/VNI-1でカプセル化されます。
[RFC8365] describes how to use EVPN for NVO3 encapsulations, such us VXLAN, nvGRE, or MPLSoGRE. The procedures can be easily applicable to any other NVO3 encapsulation, particularly Geneve.
[RFC8365]は、vxlan、nvgre、またはmplsogreなどのNVO3カプセルにEVPNを使用する方法について説明しています。手順は、他のNVO3カプセル化、特にGeneveに簡単に適用できます。
Geneve [RFC8926] is the proposed standard encapsulation specified in the IETF Network Virtualization Overlays Working Group. The EVPN control plane can signal the Geneve encapsulation type in the BGP Tunnel Encapsulation Extended Community (see [RFC9012]).
Geneve [RFC8926]は、IETFネットワーク仮想化オーバーレイワーキンググループで指定された提案された標準カプセル化です。EVPNコントロールプレーンは、BGPトンネルカプセル化拡張コミュニティのGeneveカプセル化タイプを信号することができます（[RFC9012]を参照）。
Geneve requires a control plane [NVO3-ENCAP] to:
Geneveは、コントロールプレーン[NVO3-ENCAP]を必要とします。
* Negotiate a subset of Geneve option TLVs that can be carried on a Geneve tunnel,
* Geneveトンネルで運ぶことができるGeneveオプションTLVのサブセットを交渉し、
* Enforce an order for Geneve option TLVs, and
* Geneve Option TLVSの注文を強制します
* Limit the total number of options that could be carried on a Geneve tunnel.
* Geneveトンネルで運ぶ可能性のあるオプションの総数を制限します。
The EVPN control plane can easily extend the BGP Tunnel Encapsulation attribute sub-TLV [RFC9012] to specify the Geneve tunnel options that can be received or transmitted over a Geneve tunnel by a given NVE. [EVPN-GENEVE] describes the EVPN control plane extensions to support Geneve.
EVPNコントロールプレーンは、BGPトンネルカプセル化属性サブTLV [RFC9012]を簡単に拡張して、特定のNVEによってGeneveトンネルを介して受信または送信できるGeneveトンネルオプションを指定できます。[EVPN-Geneve]は、GeneveをサポートするEVPNコントロールプレーンの拡張を説明しています。
EVPN Operations, Administration, and Maintenance (OAM), as described in [EVPN-LSP-PING], defines mechanisms to detect data plane failures in an EVPN deployment over an MPLS network. These mechanisms detect failures related to point-to-point (P2P) and Point-to-Multipoint (P2MP) connectivity, for multi-tenant unicast and multicast Layer 2 traffic, between multi-tenant access nodes connected to EVPN PE(s), and in a single-homed, Single-Active, or All-Active redundancy model.
[EVPN-LSP-Ping]で説明されているように、EVPNの操作、管理、およびメンテナンス（OAM）は、MPLSネットワーク上のEVPN展開でデータプレーンの障害を検出するメカニズムを定義します。これらのメカニズムは、EVPN PE（s）に接続されたマルチテナントアクセスノードの間、マルチテナントユニキャストとマルチキャストレイヤー2トラフィックのポイントツーポイント（P2P）およびポイントツーマルチポイント（P2MP）接続に関連する障害を検出します。そして、シングルホーム、単一活動、または全活性冗長モデルで。
In general, EVPN OAM mechanisms defined for EVPN deployed in MPLS networks are equally applicable for EVPN in NVO3 networks.
一般に、MPLSネットワークに展開されたEVPN用に定義されたEVPN OAMメカニズムは、NVO3ネットワークのEVPNに等しく適用できます。
EVPN can be used to signal the security protection capabilities of a sender NVE, as well as what portion of an NVO3 packet (taking a Geneve packet as an example) can be protected by the sender NVE, to ensure the privacy and integrity of tenant traffic carried over the NVO3 tunnels [SECURE-EVPN].
EVPNを使用して、送信者NVEのセキュリティ保護機能を信号することができます。また、NVO3パケットのどの部分（Geneveパケットを例として使用する）は、送信者NVEによって保護され、テナントトラフィックのプライバシーと整合性を確保することができますNVO3トンネル[Secure-EVPN]を介して運ばれます。
This section describes how EVPN can be used to deliver advanced capabilities in NVO3 networks.
このセクションでは、EVPNを使用してNVO3ネットワークで高度な機能を提供する方法について説明します。
[RFC7432] replaces the classic Ethernet "flood and learn" behavior among NVEs with BGP-based MAC learning. In return, this provides more control over the location of MAC addresses in the Broadcast Domain and consequently advanced features, such as MAC Mobility. If we assume that Virtual Machine (VM) Mobility means the VM's MAC and IP addresses move with the VM, EVPN's MAC Mobility is the required procedure that facilitates VM Mobility. According to Section 15 of [RFC7432], when a MAC is advertised for the first time in a Broadcast Domain, all the NVEs attached to the Broadcast Domain will store Sequence Number zero for that MAC. When the MAC "moves" to a remote NVE within the same Broadcast Domain, the NVE that just learned the MAC locally increases the Sequence Number in the MAC/IP Advertisement route's MAC Mobility extended community to indicate that it owns the MAC now. That makes all the NVEs in the Broadcast Domain change their tables immediately with no need to wait for any aging timer. EVPN guarantees a fast MAC Mobility without flooding or packet drops in the Broadcast Domain.
[RFC7432]は、古典的なイーサネットを、NVEの「洪水と学習」行動をBGPベースのMAC学習に置き換えます。その見返りに、これにより、ブロードキャストドメイン内のMACアドレスの位置と、その結果、MACモビリティなどの高度な機能をより強化します。Virtual Machine（VM）モビリティがVMのMACおよびIPアドレスがVMとともに移動することを意味すると仮定すると、EVPNのMACモビリティがVMモビリティを促進する必要な手順です。[RFC7432]のセクション15によると、Macがブロードキャストドメインで初めて宣伝されると、ブロードキャストドメインに接続されているすべてのNVEがそのMacのシーケンス番号ゼロを保存します。MACが同じブロードキャストドメイン内のリモートNVEに「移動」すると、Macを学習したばかりのNVEは、Mac/IP Advertisement RouteのMac Mobilityのシーケンス番号を増加させ、コミュニティがコミュニティを拡張し、Macを所有していることを示します。これにより、ブロードキャストドメイン内のすべてのNVEがテーブルをすぐに変更し、老化タイマーを待つ必要はありません。EVPNは、放送ドメインに洪水やパケットドロップなしで高速MACモビリティを保証します。
The advertisement of MACs in the control plane allows advanced features such as MAC Protection, Duplication Detection, and Loop Protection.
コントロールプレーンのMacの広告により、Mac保護、複製検出、ループ保護などの高度な機能が可能になります。
In a MAC/IP Advertisement route, MAC Protection refers to EVPN's ability to indicate that a MAC must be protected by the NVE receiving the route [RFC7432]. The Protection is indicated in the "Sticky bit" of the MAC Mobility extended community sent along the MAC/IP Advertisement route for a MAC. NVEs' Attachment Circuits that are connected to subject-to-be-protected servers or VMs may set the Sticky bit on the MAC/IP Advertisement routes sent for the MACs associated with the Attachment Circuits. Also, statically configured MAC addresses should be advertised as Protected MAC addresses since they are not subject to MAC Mobility procedures.
MAC/IP広告ルートでは、Mac Protectionは、MACがルートを受信することによってMacを保護する必要があることを示すEVPNの能力を指します[RFC7432]。MAC/IP広告ルートに沿って送信されるMACモビリティ拡張コミュニティの「粘着性ビット」に保護が示されています。保護されていないサーバーまたはVMに接続されているNVESのアタッチメントサーキットは、添付回路に関連付けられたMacに送信されるMAC/IP広告ルートに粘着性ビットを設定する場合があります。また、静的に構成されたMacアドレスは、MACモビリティ手順の対象ではないため、保護されたMacアドレスとして宣伝する必要があります。
MAC Duplication Detection refers to EVPN's ability to detect duplicate MAC addresses [RFC7432]. A "MAC move" is a relearn event that happens at an access Attachment Circuit or through a MAC/IP Advertisement route with a Sequence Number that is higher than the stored one for the MAC. When a MAC moves a number of times (N) within an M-second window between two NVEs, the MAC is declared as a duplicate and the detecting NVE does not re-advertise the MAC anymore.
MAC複製検出とは、重複したMACアドレスを検出するEVPNの能力を指します[RFC7432]。「Mac Move」は、Access Attachment CircuitまたはMac/IP広告ルートを介して行われるリラーンイベントです。これは、Macの保存されているものよりも高いシーケンス番号を備えています。Macが2つのNVEの間のm秒ウィンドウ内で何度も（n）移動すると、Macは重複として宣言され、検出されたNVEはMacを再承認しなくなります。
[RFC7432] provides MAC Duplication Detection, and with an extension, it can protect the Broadcast Domain against loops created by backdoor links between NVEs. The same principle (based on the Sequence Number) may be extended to protect the Broadcast Domain against loops. When a MAC is detected as a duplicate, the NVE may install it as a drop-MAC and discard received frames with source MAC address or the destination MAC address matching that duplicate MAC. The MAC Duplication extension to support Loop Protection is described in Section 15.3 of [RFC7432BIS].
[RFC7432]はMACの重複検出を提供し、拡張機能を使用すると、NVE間のバックドアリンクによって作成されたループからブロードキャストドメインを保護できます。同じ原理（シーケンス番号に基づいて）を拡張して、ブロードドメインをループから保護することができます。MACが複製として検出されると、NVEはドロップマックとしてインストールし、ソースMACアドレスまたはその宛先MACアドレスがMACを複製する宛先MACアドレスを装備することができます。ループ保護をサポートするためのMAC複製拡張は、[RFC7432BIS]のセクション15.3で説明されています。
In Broadcast Domains with a significant amount of flooding due to Unknown Unicast and broadcast frames, EVPN may help reduce and sometimes even suppress the flooding.
Unicastおよびブロードキャストフレームが不明であるため、かなりの量の洪水を伴う放送ドメインでは、EVPNは洪水を減らすことができ、時には洪水を抑制することさえあります。
In Broadcast Domains where most of the broadcast traffic is caused by the Address Resolution Protocol (ARP) and the Neighbor Discovery Protocol (NDP) on the Tenant Systems, EVPN's Proxy ARP and Proxy ND capabilities may reduce the flooding drastically. The use of Proxy ARP/ND is specified in [RFC9161].
ほとんどのブロードキャストトラフィックがアドレス解像度プロトコル（ARP）およびテナントシステムの近隣ディスカバリープロトコル（NDP）によって引き起こされるブロードキャストドメインでは、EVPNのプロキシARPとプロキシND機能が劇的に洪水を減らす可能性があります。プロキシARP/NDの使用は[RFC9161]で指定されています。
Proxy ARP/ND procedures, along with the assumption that Tenant Systems always issue a Gratuitous ARP (GARP) or an unsolicited Neighbor Advertisement message when they come up in the Broadcast Domain, may drastically reduce the Unknown Unicast flooding in the Broadcast Domain.
プロキシARP/ND手順は、テナントシステムが常に無償のARP（GARP）または未承諾の近隣広告メッセージを放送ドメインに登場するときに、未承諾の近隣広告メッセージを発行するという仮定とともに、ブロードキャストドメインの未知のユニキャスト洪水を大幅に減らす可能性があります。
The flooding caused by Tenant Systems' IGMP / Multicast Listener Discovery (MLD) or PIM messages in the Broadcast Domain may also be suppressed by the use of IGMP/MLD and PIM Proxy functions, as specified in [RFC9251] and [EVPN-PIM-PROXY]. These two documents also specify how to forward IP multicast traffic efficiently within the same Broadcast Domain, translate soft state IGMP/MLD/PIM messages into hard state BGP routes, and provide fast convergence redundancy for IP multicast on multihomed ESes.
[RFC9251]および[EVPN-PIM-[[EVPN-PIM-]で指定されているように、テナントシステムのIGMP /マルチキャストリスナーディスカバリー（MLD）またはPIMメッセージによって引き起こされる洪水も、IGMP / MLDおよびPIMプロキシ関数を使用することで抑制される場合があります。プロキシ]。また、これらの2つのドキュメントは、同じブロードキャストドメイン内でIPマルチキャストトラフィックを効率的に転送し、ソフトステートIGMP/MLD/PIMメッセージをハードステートBGPルートに変換する方法を指定し、マルチホームESEのIPマルチキャストに高速収束冗長性を提供します。
When an NVE attached to a given Broadcast Domain needs to send BUM traffic for the Broadcast Domain to the remote NVEs attached to the same Broadcast Domain, Ingress Replication is a very common option in NVO3 networks since it is completely independent of the multicast capabilities of the underlay network. Also, if the optimization procedures to reduce/suppress the flooding in the Broadcast Domain are enabled (Section 4.7.3) in spite of creating multiple copies of the same frame at the ingress NVE, Ingress Replication may be good enough. However, in Broadcast Domains where Multicast (or Broadcast) traffic is significant, Ingress Replication may be very inefficient and cause performance issues on virtual switch-based NVEs.
特定のブロードキャストドメインに接続されたNVEが、ブロードキャストドメインのバムトラフィックを同じブロードキャストドメインに接続されたリモートNVEに送信する必要がある場合、イングレスレプリケーションは、NVO3ネットワークでは非常に一般的なオプションです。アンダーレイネットワーク。また、イングレスNVEで同じフレームの複数のコピーを作成しているにもかかわらず、ブロードキャストドメインの洪水を削減/抑制する最適化手順が有効になっている場合（セクション4.7.3）、イングレスの複製で十分です。ただし、マルチキャスト（またはブロードキャスト）トラフィックが重要なブロードキャストドメインでは、イングレスレプリケーションは非常に非効率的であり、仮想スイッチベースのNVEでパフォーマンスの問題を引き起こす可能性があります。
[EVPN-OPT-IR] specifies the use of Assisted Replication (AR) NVO3 tunnels in EVPN Broadcast Domains. AR retains the independence of the underlay network while providing a way to forward Broadcast and multicast traffic efficiently. AR uses AR-REPLICATORs that can replicate the broadcast/multicast traffic on behalf of the AR-LEAF NVEs. The AR-LEAF NVEs are typically virtual switches or NVEs with limited replication capabilities. AR can work in a single-stage replication mode (Non-Selective Mode) or in a dual-stage replication mode (Selective Mode). Both modes are detailed in [EVPN-OPT-IR].
[EVPN-OPT-IR] EVPNブロードキャストドメインでの支援レプリケーション（AR）NVO3トンネルの使用を指定します。ARは、アンダーレイネットワークの独立性を維持しながら、放送とマルチキャストトラフィックを効率的に転送する方法を提供します。ARは、AR-Leaf NVESに代わって放送/マルチキャストトラフィックを複製できるARレプリケーターを使用します。ARリーフNVEは通常、レプリケーション機能が限られている仮想スイッチまたはNVEです。ARは、単一段階の複製モード（非選択モード）またはデュアル段階の複製モード（選択モード）で動作できます。両方のモードは[EVPN-OPT-IR]で詳しく説明されています。
In addition, [EVPN-OPT-IR] describes a procedure to avoid sending BUM to certain NVEs that do not need that type of traffic. This is done by enabling Pruned Flood Lists (PFLs) on a given Broadcast Domain. For instance, a virtual switch NVE that learns all its local MAC addresses for a Broadcast Domain via a Cloud Management System does not need to receive the Broadcast Domain's Unknown Unicast traffic. PFLs help optimize the BUM flooding in the Broadcast Domain.
さらに、[EVPN-OPT-IR]は、そのタイプのトラフィックを必要としない特定のNVEにバムを送信しないようにする手順を説明しています。これは、特定のブロードキャストドメインで剪定された洪水リスト（PFL）を有効にすることによって行われます。たとえば、クラウド管理システムを介してブロードキャストドメインのすべてのローカルMACアドレスを学習する仮想スイッチNVEは、ブロードキャストドメインの不明なユニキャストトラフィックを受信する必要はありません。PFLは、ブロードキャストドメインのバム洪水を最適化するのに役立ちます。
Another fundamental concept in EVPN is multihoming. A given Tenant System can be multihomed to two or more NVEs for a given Broadcast Domain, and the set of links connected to the same Tenant System is defined as an ES. EVPN supports Single-Active and All-Active multihoming. In Single-Active multihoming, only one link in the Ethernet Segment is active. In All-Active multihoming, all the links in the Ethernet Segment are active for unicast traffic. Both modes support load-balancing:
EVPNのもう1つの基本的な概念は、マルチホミングです。特定のテナントシステムは、特定のブロードキャストドメインに対して2つ以上のNVEにマルチホームすることができ、同じテナントシステムに接続されたリンクのセットはESとして定義されます。EVPNは、単一活動的でオールアクティブなマルチホームをサポートします。単一活動マルチホームでは、イーサネットセグメントの1つのリンクのみがアクティブです。オールアクティブなマルチホミングでは、イーサネットセグメントのすべてのリンクがユニキャストトラフィックにアクティブです。どちらのモードもロードバランスをサポートしています。
* Single-Active multihoming means per-service load-balancing to/from the Tenant System. For example, in Figure 1 for BD1, only one of the NVEs can forward traffic from/to TS2. For a different Broadcast Domain, the other NVE may forward traffic.
* テナントシステムとの間での積極的なマルチホームは、サービスごとの負荷バランスをとることを意味します。たとえば、BD1の図1では、NVEの1つのみがトラフィックをTS2から転送できます。別のブロードキャストドメインの場合、他のNVEはトラフィックを転送する可能性があります。
* All-active multihoming means per-flow load-balancing for unicast frames to/from the Tenant System. That is, in Figure 1 and for BD1, both NVE4 and NVE5 can forward known unicast traffic to/from TS3. For BUM traffic, only one of the two NVEs can forward traffic to TS3, and both can forward traffic from TS3.
* テナントシステムとの間のユニキャストフレームのための流量ごとの負荷分散をすべて活性型マルチホームとすること。つまり、図1およびBD1の場合、NVE4とNVE5の両方がTS3に既知のユニキャストトラフィックを転送できます。Bum Trafficの場合、2つのNVEのうち1つだけがTS3にトラフィックを転送でき、どちらもTS3からトラフィックを転送できます。
There are two key aspects in the EVPN multihoming procedures:
EVPNマルチホーム手順には2つの重要な側面があります。
Designated Forwarder (DF) election:
指定されたフォワーダー（DF）選挙：
The Designated Forwarder is the NVE that forwards the traffic to the Ethernet Segment in Single-Active mode. In the case of All-Active mode, the Designated Forwarder is the NVE that forwards the BUM traffic to the Ethernet Segment.
指定されたフォワーダーは、単一アクティブモードでトラフィックをイーサネットセグメントに転送するNVEです。オールアクティブモードの場合、指定されたフォワーダーは、バムトラフィックをイーサネットセグメントに転送するNVEです。
Split-horizon function:
スプリットホリゾン関数：
Prevents the Tenant System from receiving echoed BUM frames that the Tenant System itself sent to the Ethernet Segment. This is especially relevant in All-Active ESes where the TS may forward BUM frames to a Non-Designated Forwarder NVE that can flood the BUM frames back to the Designated Forwarder NVE and then back to the TS. As an example, assuming NVE4 is the Designated Forwarder for ESI-2 in BD1, Figure 1 shows that BUM frames sent from TS3 to NVE5 will be received at NVE4. NVE4 will forward them back to TS3 since NVE4 is the Designated Forwarder for BD1. Split-horizon allows NVE4 (and any multihomed NVE for that matter) to identify if an EVPN BUM frame is coming from the same Ethernet Segment or a different one. If the frame belongs to the same ESI-2, NVE4 will not forward the BUM frame to TS3 in spite of being the Designated Forwarder.
テナントシステムが、テナントシステム自体がイーサネットセグメントに送信したエコーされたバムフレームを受信するのを防ぎます。これは、TSがバムフレームを指定されたフォワーダーNVEに戻し、TSに戻る可能性がある非指定されたフォワーダーNVEにバムフレームを転送する可能性のあるすべての活動的なESEに特に関連しています。例として、NVE4がBD1のESI-2の指定されたフォワーダーであると仮定すると、図1は、TS3からNVE5に送信されたバムフレームがNVE4で受信されることを示しています。NVE4はBD1の指定されたフォワーダーであるため、NVE4はTS3に転送されます。Split-Horizonにより、NVE4（および任意のマルチホームNVE）は、EVPNバムフレームが同じイーサネットセグメントまたは別のセグメントから来ているかどうかを識別できます。フレームが同じESI-2に属している場合、NVE4は指定されたフォワーダーであるにもかかわらず、バムフレームをTS3に転送しません。
While [RFC7432] describes the default algorithm for the Designated Forwarder election, [RFC8584] and [EVPN-PREF-DF] specify other algorithms and procedures that optimize the Designated Forwarder election.
[RFC7432]は、指定されたフォワーダー選挙のデフォルトアルゴリズムを説明していますが、[RFC8584]および[EVPN-PREF-DF]は、指定されたフォワーダー選挙を最適化する他のアルゴリズムと手順を指定します。
The split-horizon function is specified in [RFC7432], and it is carried out by using a special ESI-label that it identifies in the data path with all the BUM frames originating from a given NVE and Ethernet Segment. Since the ESI-label is an MPLS label, it cannot be used in all the non-MPLS NVO3 encapsulations. Therefore, [RFC8365] defines a modified split-horizon procedure that is based on the source IP address of the NVO3 tunnel; it is known as "Local-Bias". It is worth noting that Local-Bias only works for All-Active multihoming, and not for Single-Active multihoming.
スプリットホリゾン関数は[RFC7432]で指定されており、特定のNVEおよびイーサネットセグメントに由来するすべてのバムフレームを使用してデータパスで識別する特別なESIラベルを使用して実行されます。ESI-LabelはMPLSラベルであるため、すべての非MPLS NVO3カプセルで使用することはできません。したがって、[RFC8365]は、NVO3トンネルのソースIPアドレスに基づいた修正されたスプリットホリゾン手順を定義します。「ローカルバイアス」として知られています。ローカルバイアスは、すべての活動的なマルチホームにのみ機能し、単一活動的なマルチホームでは機能しないことは注目に値します。
Section 4.3 describes how EVPN can be used for inter-subnet forwarding among subnets of the same tenant. MAC/IP Advertisement routes and IP Prefix routes allow the advertisement of host routes and IP Prefixes (IP Prefix route) of any length. The procedures outlined by Section 4.3 are similar to the ones in [RFC4364], but they are only for NVO3 tunnels. However, [RFC9136] also defines advanced inter-subnet forwarding procedures that allow the resolution of IP Prefix routes not only to BGP next hops but also to "overlay indexes" that can be a MAC, a Gateway IP (GW-IP), or an ESI, all of them in the tenant space.
セクション4.3では、同じテナントのサブネット間のサブネット間転送にEVPNを使用する方法について説明します。Mac/IP広告ルートとIPプレフィックスルートにより、任意の長さのホストルートとIPプレフィックス（IPプレフィックスルート）の広告が可能になります。セクション4.3で概説されている手順は、[RFC4364]の手順と類似していますが、NVO3トンネルのみです。ただし、[RFC9136]は、IPプレフィックスルートの解像度をBGP次のホップだけでなく、Mac、Gateway IP（GW-IP）、またはMAC、または「GW-IP）、または「オーバーレイインデックス」にも可能にする高度なサブネット間転送手順も定義しています。ESI、それらはすべてテナントスペースにあります。
Figure 4 illustrates an example that uses Recursive Resolution to a GW-IP as per Section 4.4.2 of [RFC9136]. In this example, IP-VRFs in NVE1 and NVE2 are connected by a Supplementary Broadcast Domain (SBD). An SBD is a Broadcast Domain that connects all the IP-VRFs of the same tenant via IRB and has no Attachment Circuits. NVE1 advertises the host route TS2-IP/L (IP address and Prefix Length of TS2) in an IP Prefix route with overlay index GW-IP=IP1. Also, IP1 is advertised in a MAC/IP Advertisement route associated with M1, VNI-S, and BGP next-hop NVE1. Upon importing the two routes, NVE2 installs TS2-IP/L in the IP-VRF with a next hop that is the GW-IP IP1. NVE2 also installs M1 in the Supplementary Broadcast Domain, with VNI-S and NVE1 as next hop. If TS3 sends a packet with IP DA=TS2, NVE2 will perform a Recursive Resolution of the IP Prefix route prefix information to the forwarding information of the correlated MAC/IP Advertisement route. The IP Prefix route's Recursive Resolution has several advantages, such as better convergence in scaled networks (since multiple IP Prefix routes can be invalidated with a single withdrawal of the overlay index route) or the ability to advertise multiple IP Prefix routes from an overlay index that can move or change dynamically. [RFC9136] describes a few use cases.
図4は、[RFC9136]のセクション4.4.2に従って、GW-IPに再帰解像度を使用する例を示しています。この例では、NVE1およびNVE2のIP-VRFSは、補足放送ドメイン（SBD）によって接続されています。SBDは、IRBを介して同じテナントのすべてのIP-VRFを接続する放送ドメインであり、アタッチメントサーキットはありません。NVE1は、オーバーレイインデックスGW-IP = IP1を備えたIPプレフィックスルートで、ホストルートTS2-IP/L（TS2のIPアドレスとプレフィックス長）を宣伝します。また、IP1は、M1、VNI-S、およびBGP Next-Hop NVE1に関連付けられたMAC/IP広告ルートで宣伝されています。2つのルートをインポートすると、NVE2はGW-IP IP1である次のホップでIP-VRFにTS2-IP/Lをインストールします。NVE2は、VNI-SとNVE1を次のホップとして、補足放送ドメインにM1をインストールします。TS3がIP DA = TS2でパケットを送信すると、NVE2は、IPプレフィックスルートプレフィックス情報の再帰解像度を相関MAC/IP広告ルートの転送情報に実行します。IPプレフィックスルートの再帰解像度には、スケーリングされたネットワークのより良い収束など、いくつかの利点があります（複数のIPプレフィックスルートは、オーバーレイインデックスルートの単一の引き出しで無効になる可能性があるため）、またはオーバーレイインデックスから複数のIPプレフィックスルートを宣伝する機能を備えています。動的に移動または変更できます。[RFC9136]は、いくつかのユースケースについて説明しています。
+-------------------------------------+
| EVPN NVO3 |
| +
NVE1 NVE2
+--------------------+ +--------------------+
| +---+IRB +------+ | | +------+IRB +---+ |
TS1-----|BD1|----|IP-VRF| | | |IP-VRF|----|BD3|-----TS3
| +---+ | |-(SBD)------(SBD)-| | +---+ |
| +---+IRB | |IRB(IP1/M1) IRB+------+ |
TS2-----|BD2|----| | | +-----------+--------+
| +---+ +------+ | |
+--------------------+ |
| RT-2(M1,IP1,VNI-S,NVE1)--> |
| RT-5(TS2-IP/L,GW-IP=IP1)--> |
+-------------------------------------+
Figure 4: EVPN for L3 - Recursive Resolution Example
図4：L3のEVPN-再帰解決の例
The concept of the Supplementary Broadcast Domain described in Section 4.7.6 is also used in [EVPN-IRB-MCAST] for the procedures related to inter-subnet multicast forwarding across Broadcast Domains of the same tenant. For instance, [EVPN-IRB-MCAST] allows the efficient forwarding of IP multicast traffic from any Broadcast Domain to any other Broadcast Domain (or even to the same Broadcast Domain where the source resides). The [EVPN-IRB-MCAST] procedures are supported along with EVPN multihoming and for any tree allowed on NVO3 networks, including IR or AR. [EVPN-IRB-MCAST] also describes the interoperability between EVPN and other multicast technologies such as Multicast VPN (MVPN) and PIM for inter-subnet multicast.
セクション4.7.6で説明されている補足放送ドメインの概念は、同じテナントのブロードキャストドメイン全体のサブネット間マルチキャスト間転送に関連する手順で[EVPN-IRB-Mcast]でも使用されています。たとえば、[EVPN-IRB-MCAST]により、ブロードキャストドメインから他のブロードキャストドメイン（またはソースが存在する同じブロードキャストドメイン）へのIPマルチキャストトラフィックの効率的な転送が可能になります。[EVPN-IRB-MCAST]手順は、EVPNマルチホミングとともに、IRまたはARを含むNVO3ネットワークで許可されている任意のツリーに対してサポートされています。[EVPN-IRB-MCAST]は、EVPNとマルチキャストVPN（MVPN）やPIMなどの他のマルチキャストテクノロジー間の相互運用性についても説明しています。
[EVPN-MVPN-SEAMLESS] describes another potential solution to support EVPN to MVPN interoperability.
[EVPN-MVPN-SEAMLESS]は、EVPNをMVPNの相互運用性をサポートする別の潜在的なソリューションについて説明します。
Tenant Layer 2 and Layer 3 services deployed on NVO3 networks must often be extended to remote NVO3 networks that are connected via non-NOV3 Wide Area Networks (WANs) (mostly MPLS-based WANs). [RFC9014] defines some architectural models that can be used to interconnect NVO3 networks via MPLS WANs.
NVO3ネットワークに展開されているテナントレイヤー2およびレイヤー3サービスは、多くの場合、非NOV3ワイドエリアネットワーク（WANS）（主にMPLSベースのWAN）を介して接続されたリモートNVO3ネットワークに拡張する必要があります。[RFC9014]は、MPLS WANを介してNVO3ネットワークを相互接続するために使用できるアーキテクチャモデルを定義します。
When NVO3 networks are connected by MPLS WANs, [RFC9014] specifies how EVPN can be used end to end in spite of using a different encapsulation in the WAN. [RFC9014] also supports the use of NVO3 or Segment Routing (encoding 32-bit or 128-bit Segment Identifiers into labels or IPv6 addresses, respectively) transport tunnels in the WAN.
NVO3ネットワークがMPLS WANによって接続されている場合、[RFC9014]は、WANで異なるカプセル化を使用しているにもかかわらず、EVPNを使用する方法を指定して終了します。[RFC9014]は、NVO3またはセグメントルーティングの使用もサポートしています（それぞれ32ビットまたは128ビットセグメント識別子をラベルまたはIPv6アドレスにエンコードする）トンネルをWANで輸送します。
Even if EVPN can also be used in the WAN for Layer 2 and Layer 3 services, there may be a need to provide a Gateway function between EVPN for NVO3 encapsulations and IP VPN for MPLS tunnels if the operator uses IP VPN in the WAN. [EVPN-IPVPN-INTERWORK] specifies the interworking function between EVPN and IP VPN for unicast inter-subnet forwarding. If inter-subnet multicast forwarding is also needed across an IP VPN WAN, [EVPN-IRB-MCAST] describes the required interworking between EVPN and MVPNs.
レイヤー2およびレイヤー3サービスのWANでもEVPNを使用できる場合でも、オペレーターがWANでIP VPNを使用する場合、NVO3カプセルのEVPNとMPLSトンネルのIP VPNの間にゲートウェイ関数を提供する必要があるかもしれません。[EVPN-IPVPNインターワーク] Unicast Inter-SubNet転送のために、EVPNとIP VPNの間のインターワーキング関数を指定します。IP VPN WAN全体でサブネット間のマルチキャスト転送も必要な場合、[EVPN-IRB-MCAST]は、EVPNとMVPNの間の必要なインターワーキングについて説明します。
This document does not introduce any new procedure or additional signaling in EVPN and relies on the security considerations of the individual specifications used as a reference throughout the document. In particular, and as mentioned in [RFC7432], control plane and forwarding path protection are aspects to secure in any EVPN domain when applied to NVO3 networks.
このドキュメントは、EVPNで新しい手順や追加のシグナル伝達を導入せず、ドキュメント全体で参照として使用される個々の仕様のセキュリティに関する考慮事項に依存しています。特に、[RFC7432]で述べたように、コントロールプレーンと転送パス保護は、NVO3ネットワークに適用される場合、任意のEVPNドメインで保護する側面です。
[RFC7432] mentions security techniques such as those discussed in [RFC5925] to authenticate BGP messages, and those included in [RFC4271], [RFC4272], and [RFC6952] to secure BGP are relevant for EVPN in NVO3 networks as well.
[RFC7432]は、[RFC5925]で議論されているものなどのセキュリティ手法に言及し、BGPメッセージを認証し、[RFC4271]、[RFC4272]、および[RFC6952]に含まれるものが、BGPを保護するためにNVO3ネットワークのEVPNにも関連しています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
Kreeger, L., and M. Napierala, "Problem Statement:
Overlays for Network Virtualization", RFC 7364,
DOI 10.17487/RFC7364, October 2014,
<https://www.rfc-editor.org/info/rfc7364>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <https://www.rfc-editor.org/info/rfc7365>.
[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>.
[BGP-PIC] Bashandy, A., Ed., Filsfils, C., and P. Mohapatra, "BGP
Prefix Independent Convergence", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-bgp-pic-19, 1 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
bgp-pic-19>.
[CLOS1953] Clos, C., "A study of non-blocking switching networks",
The Bell System Technical Journal, Vol. 32, Issue 2,
DOI 10.1002/j.1538-7305.1953.tb01433.x, March 1953,
<https://ieeexplore.ieee.org/document/6770468>.
[EVPN-GENEVE]
Boutros, S., Ed., Sajassi, A., Drake, J., Rabadan, J., and
S. Aldrin, "EVPN control plane for Geneve", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-geneve-06,
26 May 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-bess-evpn-geneve-06>.
[EVPN-IPVPN-INTERWORK]
Rabadan, J., Ed., Sajassi, A., Ed., Rosen, E., Drake, J.,
Lin, W., Uttaro, J., and A. Simpson, "EVPN Interworking
with IPVPN", Work in Progress, Internet-Draft, draft-ietf-
bess-evpn-ipvpn-interworking-08, 5 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-ipvpn-interworking-08>.
[EVPN-IRB-MCAST]
Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan,
J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast
(OISM) Forwarding", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-irb-mcast-09, 21 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-irb-mcast-09>.
[EVPN-LSP-PING]
Jain, P., Sajassi, A., Salam, S., Boutros, S., and G.
Mirsky, "LSP-Ping Mechanisms for EVPN and PBB-EVPN", Work
in Progress, Internet-Draft, draft-ietf-bess-evpn-lsp-
ping-11, 29 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-lsp-ping-11>.
[EVPN-MVPN-SEAMLESS]
Sajassi, A., Thiruvenkatasamy, K., Thoria, S., Gupta, A.,
and L. Jalil, "Seamless Multicast Interoperability between
EVPN and MVPN PEs", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-mvpn-seamless-interop-05, 13 March
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
bess-evpn-mvpn-seamless-interop-05>.
[EVPN-OPT-IR]
Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and
A. Sajassi, "Optimized Ingress Replication Solution for
Ethernet VPN (EVPN)", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-optimized-ir-12, 25 January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-optimized-ir-12>.
[EVPN-PIM-PROXY]
Rabadan, J., Ed., Kotalwar, J., Sathappan, S., Zhang, Z.,
and A. Sajassi, "PIM Proxy in EVPN Networks", Work in
Progress, Internet-Draft, draft-skr-bess-evpn-pim-proxy-
01, 30 October 2017,
<https://datatracker.ietf.org/doc/html/draft-skr-bess-
evpn-pim-proxy-01>.
[EVPN-PREF-DF]
Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and
A. Sajassi, "Preference-based EVPN DF Election", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-11,
6 July 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-bess-evpn-pref-df-11>.
[IEEE.802.1AX_2014]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Link Aggregation", IEEE Std 802.1AX-2014,
DOI 10.1109/IEEESTD.2014.7055197, December 2014,
<https://doi.org/10.1109/IEEESTD.2014.7055197>.
[NVO3-ENCAP]
Boutros, S., Ed. and D. Eastlake 3rd, Ed., "Network
Virtualization Overlays (NVO3) Encapsulation
Considerations", Work in Progress, Internet-Draft, draft-
ietf-nvo3-encap-09, 7 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-
encap-09>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[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>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[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>.
[RFC7432BIS]
Sajassi, A., Burdet, L., Drake, J., and J. Rabadan, "BGP
MPLS-Based Ethernet VPN", Work in Progress, Internet-
Draft, draft-ietf-bess-rfc7432bis-07, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
rfc7432bis-07>.
[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>.
[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>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
[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>.
[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>.
[RFC9014] Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi,
A., and J. Drake, "Interconnect Solution for Ethernet VPN
(EVPN) Overlay Networks", RFC 9014, DOI 10.17487/RFC9014,
May 2021, <https://www.rfc-editor.org/info/rfc9014>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
[RFC9161] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Hankins, G.,
and T. King, "Operational Aspects of Proxy ARP/ND in
Ethernet Virtual Private Networks", RFC 9161,
DOI 10.17487/RFC9161, January 2022,
<https://www.rfc-editor.org/info/rfc9161>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>.
[SECURE-EVPN]
Sajassi, A., Banerjee, A., Thoria, S., Carrel, D., Weis,
B., and J. Drake, "Secure EVPN", Work in Progress,
Internet-Draft, draft-ietf-bess-secure-evpn-00, 20 June
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
bess-secure-evpn-00>.
The authors thank Aldrin Isaac for his comments.
著者は、彼のコメントについてアルドリン・アイザックに感謝します。
Jorge Rabadan (editor)
Nokia
520 Almanor Ave
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Matthew Bocci
Nokia
Email: matthew.bocci@nokia.com
Sami Boutros
Ciena
Email: sboutros@ciena.com
Ali Sajassi
Cisco Systems, Inc.
Email: sajassi@cisco.com