[要約] RFC 9014は、Ethernet VPN (EVPN) オーバーレイネットワークのための相互接続ソリューションに関する文書です。この文書の目的は、異なるEVPNネットワーク間での効率的なデータ交換と相互運用性を確保する方法を提供することにあります。主に、データセンター間の接続や異なる事業者間のネットワーク接続など、広範なネットワーク環境での利用が想定されています。
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9014 S. Sathappan
Category: Standards Track W. Henderickx
ISSN: 2070-1721 Nokia
A. Sajassi
Cisco
J. Drake
Juniper
May 2021
Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks
イーサネットVPN（EVPN）オーバーレイネットワーク用のインターコネクトソリューション
Abstract
概要
This document describes how Network Virtualization Overlays (NVOs) can be connected to a Wide Area Network (WAN) in order to extend the Layer 2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN, such as Virtual Private LAN Services (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN, or PBB-EVPN. It also describes how the existing technical specifications apply to the interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES), to provide multihoming. This document also describes the use of the Unknown MAC Route (UMR) to avoid issues of a Media Access Control (MAC) scale on Data Center Network Virtualization Edge (NVE) devices.
この文書では、一部のテナントに必要なレイヤ2接続性を拡張するために、ネットワーク仮想化オーバーレイ（NVOS）をワイドエリアネットワーク（WAN）に接続できる方法について説明します。このソリューションは、イーサネットバーチャルプライベートネットワーク（EVPNS）およびその他のレイヤ2 VPN（L2VPN）テクノロジを実行しているNVOネットワーク間の相互作用を分析します。 ）、EVPN、またはPBB-EVPN。また、既存の技術仕様が相互接続に適用される方法についても説明し、必要なEVPN手順を拡張します。特に、この文書では、EVPN-OverlayネットワークとEVPN-MPLSネットワークと相互接続するゲートウェイ（GWS）で処理される方法、および相互接続イーサネットセグメント（I-ES）がマルチホームを提供します。この文書では、データセンターネットワーク仮想化エッジ（NVE）デバイスのメディアアクセス制御（MAC）スケールの問題を回避するための未知のMACルート（UMR）の使用について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9014.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9014で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions and Terminology
3. Decoupled Interconnect Solution for EVPN-Overlay Networks
3.1. Interconnect Requirements
3.2. VLAN-Based Handoff
3.3. PW-Based Handoff
3.4. Multihoming Solution on the GWs
3.5. Gateway Optimizations
3.5.1. MAC Address Advertisement Control
3.5.2. ARP/ND Flooding Control
3.5.3. Handling Failures between GW and WAN Edge Routers
4. Integrated Interconnect Solution for EVPN-Overlay Networks
4.1. Interconnect Requirements
4.2. VPLS Interconnect for EVPN-Overlay Networks
4.2.1. Control/Data Plane Setup Procedures on the GWs
4.2.2. Multihoming Procedures on the GWs
4.3. PBB-VPLS Interconnect for EVPN-Overlay Networks
4.3.1. Control/Data Plane Setup Procedures on the GWs
4.3.2. Multihoming Procedures on the GWs
4.4. EVPN-MPLS Interconnect for EVPN-Overlay Networks
4.4.1. Control plane Setup Procedures on the GWs
4.4.2. Data Plane Setup Procedures on the GWs
4.4.3. Multihoming Procedure Extensions on the GWs
4.4.4. Impact on MAC Mobility Procedures
4.4.5. Gateway Optimizations
4.4.6. Benefits of the EVPN-MPLS Interconnect Solution
4.5. PBB-EVPN Interconnect for EVPN-Overlay Networks
4.5.1. Control/Data Plane Setup Procedures on the GWs
4.5.2. Multihoming Procedures on the GWs
4.5.3. Impact on MAC Mobility Procedures
4.5.4. Gateway Optimizations
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay Networks
4.6.1. Globally Unique VNIs in the Interconnect Network
4.6.2. Downstream-Assigned VNIs in the Interconnect Network
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
[RFC8365] discusses the use of Ethernet Virtual Private Networks (EVPNs) [RFC7432] as the control plane for Network Virtualization Overlays (NVOs), where VXLAN [RFC7348], NVGRE [RFC7637], or MPLS over GRE [RFC4023] can be used as possible data plane encapsulation options.
[RFC8365] Ethernet仮想プライベートネットワーク（EVPNS）[RFC7432]の使用について説明します。ネットワーク仮想化オーバーレイ（NVOS）のコントロールプレーン（NVOS）、ここでVXLAN [RFC7348]、NVGRE [RFC7637]、またはGRE [RFC4023]を介したMPLSを使用できるできるだけデータプレーンのカプセル化オプションとして。
While this model provides a scalable and efficient multitenant solution within the Data Center, it might not be easily extended to the Wide Area Network (WAN) in some cases, due to the requirements and existing deployed technologies. For instance, a Service Provider might have an already deployed Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762], VPLS extensions for Provider Backbone Bridging (PBB-VPLS) [RFC7041], EVPN [RFC7432], or PBB-EVPN [RFC7623] network that has to be used to interconnect Data Centers and WAN VPN users. A Gateway (GW) function is required in these cases. In fact, [RFC8365] discusses two main Data Center Interconnect (DCI) solution groups: "DCI using GWs" and "DCI using ASBRs". This document specifies the solutions that correspond to the "DCI using GWs" group.
このモデルはデータセンター内でスケーラブルで効率的なマルチテナントソリューションを提供しますが、要件と既存のデプロイされたテクノロジのために、場合によっては広域ネットワーク（WAN）に簡単に拡張されない可能性があります。たとえば、サービスプロバイダには、既にデプロイされた仮想プライベートLANサービス（VPLS）[RFC4761] [RFC4762]、プロバイダーバックボーンブリッジング（PBB-VPLS）[RFC7041]、EVPN [RFC7432]、またはPBB-EVPNのVPLSエクステンションがあります。RFC7623]データセンターとWAN VPNユーザーを相互接続するために使用されなければならないネットワーク。これらの場合、ゲートウェイ（GW）機能が必要です。実際、[RFC8365]は、2つの主要データセンター相互接続（DCI）ソリューショングループについて説明します。「GWSを使用したDCI」と「ASBRを使用してDCI」を説明します。このドキュメントは、「GWSを使用したDCI」グループに対応する解決策を指定します。
It is assumed that the NVO GW and the WAN Edge functions can be decoupled into two separate systems or integrated into the same system. The former option will be referred to as "decoupled interconnect solution" throughout the document, whereas the latter one will be referred to as "integrated interconnect solution".
NVO GWとWANエッジ関数を2つの別々のシステムに分離したり、同じシステムに統合することができます。前者のオプションは、文書全体を通して「切り離された相互接続ソリューション」と呼ばれ、後者は「統合インターコネクトソリューション」と呼ばれる。
The specified procedures are local to the redundant GWs connecting a DC to the WAN. The document does not preclude any combination across different DCs for the same tenant. For instance, a "Decoupled" solution can be used in GW1 and GW2 (for DC1), and an "Integrated" solution can be used in GW3 and GW4 (for DC2).
指定された手順は、DCをWANに接続する冗長GWSに対してローカルです。文書は、同じテナントのための異なるDCにまたがる任意の組み合わせを排除しません。例えば、「デカップリングされた」溶液をGW1およびGW2（DC1用）で使用することができ、「統合」溶液をGW3およびGW4（DC2用）に使用することができる。
While the Gateways and WAN Provider Edges (PEs) use existing specifications in some cases, the document also defines extensions that are specific to DCI. In particular, those extensions are:
ゲートウェイとWANプロバイダのエッジ（PES）が既存の仕様を使用する場合、文書はDCIに固有の拡張機能も定義します。特に、これらの拡張子は次のとおりです。
* The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that can be associated to a set of pseudowires (PWs) or other tunnels. The I-ES defined in this document is not associated with a set of Ethernet links, as per [RFC7432], but rather with a set of virtual tunnels (e.g., a set of PWs). This set of virtual tunnels is referred to as vES [VIRTUAL-ES].
* インターコネクトイーサネットセグメント（I-ES）、疑似回線（PWS）または他のトンネルに関連付けることができるイーサネットセグメント。この文書で定義されているI-ESは、[RFC7432]のセットですが、一連の仮想トンネル（例えば、PWSのセット）に関連しています。この仮想トンネルのセットはVES [Virtual-ES]と呼ばれます。
* The use of the Unknown MAC Route (UMR) in a DCI scenario.
* DCIシナリオにおける未知のMACルート（UMR）の使用
* The processing of EVPN routes on Gateways with MAC-VRFs connecting EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-Overlay networks.
* EVPNオーバーレイとEVPN-MPLSネットワーク、またはEVPNオーバーレイネットワークを接続するMAC-VRFSを使用したゲートウェイのEVPNルーズの処理。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
AC: Attachment Circuit
AC：取り付け回路
ARP: Address Resolution Protocol
ARP：アドレス解決プロトコル
BUM: Broadcast, Unknown Unicast and Multicast (traffic)
BUM：ブロードキャスト、不明ユニキャストとマルチキャスト（トラフィック）
CE: Customer Equipment
CE：顧客機器
CFM: Connectivity Fault Management
CFM：接続障害管理
DC: Data Center
DC：データセンター
DCI: Data Center Interconnect
DCI：データセンターインターコネクト
DF: Designated Forwarder
DF：指定されたフォワード
EVI: EVPN Instance
EVI：EVPNインスタンス
EVPN: Ethernet Virtual Private Network, as in [RFC7432]
EVPN：[RFC7432]のように、イーサネット仮想プライベートネットワーク
EVPN Tunnel binding: refers to a tunnel to a remote PE/NVE for a given EVI. Ethernet packets in these bindings are encapsulated with the Overlay or MPLS encapsulation and the EVPN label at the bottom of the stack.
EVPNトンネルバインディング：与えられたEVIのためのリモートPE / NVEへのトンネルを参照します。これらのバインディング内のイーサネットパケットは、オーバーレイまたはMPLSカプセル化、およびスタックの底部にあるEVPNラベルを封入しています。
ES: Ethernet Segment
ES：イーサネットセグメント
ESI: Ethernet Segment Identifier
ESI：イーサネットセグメントID
GW: Gateway or Data Center Gateway
GW：ゲートウェイまたはデータセンターゲートウェイ
I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect Ethernet Segment Identifier. An I-ES is defined on the GWs for multihoming to/from the WAN.
I-ESとI-ESI：インターコネクトイーサネットセグメントとインターコネクトイーサネットセグメント識別子。WANへのマルチホームのためのGWS上にI-ESが定義されています。
MAC Media Access Control
MACメディアアクセス制御
MAC-VRF: refers to an EVI instance in a particular node
MAC-VRF：特定のノード内のEVIインスタンスを参照します。
MP2P and LSM tunnels: refer to multipoint-to-point and label switched multicast tunnels
MP2PおよびLSMトンネル：マルチポイントツーポイントとラベルの切り替えマルチキャストトンネルを参照してください。
ND: Neighbor Discovery
ND：ネイバーディスカバリー
NDF: Non-Designated Forwarder
NDF：指定されていない転送先
NVE: Network Virtualization Edge
NVE：ネットワーク仮想化エッジ
NVGRE: Network Virtualization using Generic Routing Encapsulation
NVGRE：一般的なルーティングカプセル化を使用したネットワーク仮想化
NVO: Network Virtualization Overlay
NVO：ネットワーク仮想化オーバーレイ
OAM: Operations, Administration, and Maintenance
OAM：事業、管理、および保守
PBB: Provider Backbone Bridging
PBB：プロバイダーバックボーンブリッジング
PE: Provider Edge
PE：プロバイダのエッジ
PW: Pseudowire
PW：疑似回線
RD: Route Distinguisher
RD：ルート識別力
RR: Route Reflector
RR：ルートリフレクタ
RT: Route Target
RT：ルートターゲット
S/C-TAG: refers to a combination of Service Tag and Customer Tag in a 802.1Q frame
S / Cタグ：802.1Qフレーム内のサービスタグと顧客タグの組み合わせを指す
TOR: Top-Of-Rack
TOR：ラックのトップ
UMR: Unknown MAC Route
UMR：不明なMac Route
vES: virtual Ethernet Segment
VES：仮想イーサネットセグメント
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers
VPLS: Virtual Private LAN Service
VPLS：仮想プライベートLANサービス
VSI: Virtual Switch Instance or VPLS instance in a particular PE
VSI：特定のPE内の仮想スイッチインスタンスまたはVPLSインスタンス
VXLAN: Virtual eXtensible LAN
VXLAN：仮想拡張LAN.
This section describes the interconnect solution when the GW and WAN Edge functions are implemented in different systems. Figure 1 depicts the reference model described in this section. Note that, although not shown in Figure 1, GWs may have local Attachment Circuits (ACs).
このセクションでは、GWおよびWANエッジ機能が異なるシステムで実装されている場合の相互接続ソリューションについて説明します。図1は、このセクションに記載されている参照モデルを示しています。なお、図1には示されていないが、GWはローカルの取り付け回路（ACS）を有していてもよい。
+--+
|CE|
+--+
|
+----+
+----| PE |----+
+---------+ | +----+ | +---------+
+----+ | +---+ +----+ +----+ +---+ | +----+
|NVE1|--| | | |WAN | |WAN | | | |--|NVE3|
+----+ | |GW1|--|Edge| |Edge|--|GW3| | +----+
| +---+ +----+ +----+ +---+ |
| NVO-1 | | WAN | | NVO-2 |
| +---+ +----+ +----+ +---+ |
| | | |WAN | |WAN | | | |
+----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+
|NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4|
+----+ +---------+ | | +---------+ +----+
+--------------+
|<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->|
handoff handoff
Figure 1: Decoupled Interconnect Model
図1：デカップリングインターコネクトモデル
The following section describes the interconnect requirements for this model.
次のセクションでは、このモデルの相互接続要件について説明します。
The decoupled interconnect architecture is intended to be deployed in networks where the EVPN-Overlay and WAN providers are different entities and a clear demarcation is needed. This solution solves the following requirements:
デカップリングされたインターコネクトアーキテクチャは、EVPNオーバーレイとWANプロバイダが異なるエンティティであり、明確な境界が必要であるネットワークに展開することを目的としています。このソリューションは以下の要件を解決します。
* A simple connectivity handoff between the EVPN-Overlay network provider and the WAN provider so that QoS and security enforcement are easily accomplished.
* QoSとセキュリティの執行が容易に達成されるように、EVPNオーバーレイネットワークプロバイダとWANプロバイダ間の単純な接続ハンドオフ。
* Independence of the L2VPN technology deployed in the WAN.
* WANに展開されたL2VPN技術の独立性
* Multihoming between GW and WAN Edge routers, including per-service load balancing. Per-flow load balancing is not a strong requirement, since a deterministic path per service is usually required for an easy QoS and security enforcement.
* サービスごとの負荷分散を含むGWとWANエッジルータ間のマルチホーム化。1台のサービスあたりの決定論的パスとセキュリティの強制が必要なので、一流の負荷分散は強い要件ではありません。
* Support of Ethernet OAM and Connectivity Fault Management (CFM) [IEEE.802.1AG] [Y.1731] functions between the GW and the WAN Edge router to detect individual AC failures.
* イーサネットOAMおよび接続障害管理（CFM）[IEEE.802.1AG] [Y.1731]のサポート（Y.1731]個々のAC障害を検出するためのGWとWANエッジルータの間に機能します。
* Support for the following optimizations at the GW:
* GWで次の最適化をサポートします。
- Flooding reduction of unknown unicast traffic sourced from the DC Network Virtualization Edge (NVE) devices.
- DCネットワーク仮想化エッジ（NVE）デバイスから供給されていない未知のユニキャストトラフィックの洪水削減。
- Control of the WAN MAC addresses advertised to the DC.
- DCにアドバタイズされたWAN MACアドレスの制御。
- Address Resolution Protocol (ARP) and Neighbor Discovery (ND) flooding control for the requests coming from the WAN.
- WANから来る要求に対するアドレス解決プロトコル（ARP）およびNoible Discovery（ND）フラッディング制御。
In this option, the handoff between the GWs and the WAN Edge routers is based on VLANs [IEEE.802.1Q]. This is illustrated in Figure 1 (between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in the GW is connected to a different VSI/MAC-VRF instance in the WAN Edge router by using a different C-TAG VLAN ID or a different combination of S/C-TAG VLAN IDs that matches at both sides.
このオプションでは、GWSとWANエッジルータのハンドオフはVLANS [IEEE802.1Q]に基づいています。これを図1に示します（NVO-1のGWとWANエッジルータの間のGWの間）。GW内の各MAC-VRFは、異なるCタグVLAN IDまたは両側に一致するS / CタグVLAN IDの異なる組み合わせを使用して、WANエッジルータ内の異なるVSI / MAC-VRFインスタンスに接続されています。
This option provides the best possible demarcation between the DC and WAN providers, and it does not require control plane interaction between both providers. The disadvantage of this model is the provisioning overhead, since the service has to be mapped to a C-TAG or S/C-TAG VLAN ID combination at both GW and WAN Edge routers.
このオプションは、DCおよびWANプロバイダ間で最良の境界を提供し、両方のプロバイダ間の制御プレーンの相互作用を必要としません。このモデルの不利な点は、サービスがGWとWANエッジルータの両方でCタグまたはS / CタグVLAN IDの組み合わせにマッピングされなければならないため、プロビジョニングのオーバーヘッドです。
In this model, the GW acts as a regular Network Virtualization Edge (NVE) towards the DC. Its control plane, data plane procedures, and interactions are described in [RFC8365].
このモデルでは、GWはDCに向かって通常のネットワーク仮想化エッジ（NVE）として機能します。その制御プレーン、データプレーンの手順、および相互作用は[RFC8365]に記載されています。
The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with Attachment Circuits (ACs) to the GWs. Its functions are described in [RFC4761], [RFC4762], [RFC6074], [RFC7432], and [RFC7623].
WANエッジルータは、添付回路（ACS）がGWSに（PBB-）VPLSまたは（PBB-）EVPN PEとして機能します。その機能は[RFC4761]、[RFC4762]、[RFC6074]、[RFC7432]、[RFC7623]に記載されています。
If MPLS between the GW and the WAN Edge router is an option, a PW-based interconnect solution can be deployed. In this option, the handoff between both routers is based on FEC128-based PWs [RFC4762] or FEC129-based PWs (for a greater level of network automation) [RFC6074]. Note that this model still provides a clear demarcation between DC and WAN (since there is a single PW between each MAC-VRF and peer VSI), and security/QoS policies may be applied on a per-PW basis. This model provides better scalability than a C-TAG-based handoff and less provisioning overhead than a combined C/S-TAG handoff. The PW-based handoff interconnect is illustrated in Figure 1 (between the NVO-2 GWs and the WAN Edge routers).
GWとWANエッジルータの間のMPLSがオプションである場合は、PWベースの相互接続ソリューションをデプロイできます。このオプションでは、両方のルータ間のハンドオフはFEC128ベースのPWS [RFC4762]またはFEC129ベースのPWS（より大きなレベルのネットワーク自動化の場合）[RFC6074]に基づいています。このモデルはまだDCとWAN間の明確な境界を提供します（各MAC-VRFとピアVSIの間には単一のPWがあるため）、およびセキュリティ/ QoSポリシーがPWごとに適用される場合があります。このモデルは、C / S-TAGハンドオフよりもC-TAGベースのハンドオフよりも優れたスケーラビリティを提供します。PWベースのハンドオフ相互接続を図1に示します（NVO-2 GWSとWANエッジルータの間）。
In this model, besides the usual MPLS procedures between GW and WAN Edge router [RFC3031], the GW MUST support an interworking function in each MAC-VRF that requires extension to the WAN:
このモデルでは、GWとWANエッジルータの間の通常のMPLSプロシージャーのほかに[RFC3031]では、GWはWANへの拡張を必要とする各MAC-VRFのインターワーキング機能をサポートしなければなりません。
* If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI (WAN Edge), the corresponding Virtual Connection Identifier (VCID) MUST be provisioned on the MAC-VRF and match the VCID used in the peer VSI at the WAN Edge router.
* MAC - VRF（GW）とVSI（WANエッジ）の間でFEC128ベースのPWが使用されている場合、対応する仮想接続識別子（VCID）をMAC-VRFでプロビジョニングし、Peer VSIで使用されているVCIDと一致させる必要があります。WANエッジルーター。
* If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used between the GW MAC-VRF and the WAN Edge VSI, the provisioning of the VPLS-ID MUST be supported on the MAC-VRF and MUST match the VPLS-ID used in the WAN Edge VSI.
* GW MAC-VRFとWANエッジVSIの間にBGP Auto-Discovery [RFC6074]とFEC129ベースのPWが使用されている場合、VPLS-IDのプロビジョニングはMAC-VRFでサポートされており、使用されるVPLS-IDと一致する必要があります。WANエッジVSIで。
If a PW-based handoff is used, the GW's AC (or point of attachment to the EVPN instance) uses a combination of a PW label and VLAN IDs. PWs are treated as service interfaces, defined in [RFC7432].
PWベースのハンドオフが使用されている場合、GWのAC（またはEVPNインスタンスへの添付ポイント）はPWラベルとVLAN IDの組み合わせを使用します。PWSは[RFC7432]で定義されているサービスインターフェイスとして扱われます。
EVPN single-active multihoming -- i.e., per-service load-balancing multihoming -- is required in this type of interconnect.
このタイプの相互接続では、EVPN単一アクティブマルチホーム、すなわちサービスごとの負荷分散マルチホーム - が必要である。
The GWs will be provisioned with a unique ES for each WAN interconnect, and the handoff attachment circuits or PWs between the GW and the WAN Edge router will be assigned an ESI for each such ES. The ESI will be administratively configured on the GWs according to the procedures in [RFC7432]. This I-ES will be referred to as "I-ES" hereafter, and its identifier will be referred to as "I-ESI". Different ESI types are described in [RFC7432]. The use of Type 0 for the I-ESI is RECOMMENDED in this document.
GWSは各WANインターコネクトごとに固有のESをプロビジョニングし、GWとWANエッジルータとの間のハンドオフ接続回路またはPWには、そのようなESごとにESIが割り当てられます。ESIは[RFC7432]の手順に従ってGWS上で管理上設定されます。このI-ESを以後「I-ES」と呼び、その識別子を「I-ESI」と呼びます。[RFC7432]では、さまざまなESIタイプが記載されています。このドキュメントでは、I-ESIのタイプ0を使用することをお勧めします。
The solution (on the GWs) MUST follow the single-active multihoming procedures as described in [RFC8365] for the provisioned I-ESI -- i.e., Ethernet A-D routes per ES and per EVI will be advertised to the DC NVEs for the multihoming functions, and ES routes will be advertised so that ES discovery and Designated Forwarder (DF) procedures can be followed. The MAC addresses learned (in the data plane) on the handoff links will be advertised with the I-ESI encoded in the ESI field.
プロビジョニングされたI-ESIの[RFC8365]に記載されているように、（GWS上の）ソリューションは単一アクティブマルチホーム処理手順に従う必要があります。、ESの発見と指定フォワーダ（DF）手順に従うことができるように、ESルートがアドバタイズされます。ハンドオフリンク上の（データプレーン内）MACアドレスは、ESIフィールドにエンコードされたI-ESIでアドバタイズされます。
The following GW features are optional and optimize the control plane and data plane in the DC.
次のGW機能はオプションであり、DC内のコントロールプレーンとデータプレーンを最適化します。
The use of EVPN in NVO networks brings a significant number of benefits, as described in [RFC8365]. However, if multiple DCs are interconnected into a single EVI, each DC will have to import all of the MAC addresses from each of the other DCs.
NVOネットワークにおけるEVPNの使用は、[RFC8365]に記載されているように、かなりの利点をもたらします。ただし、複数のDCが単一のEVIに相互接続されている場合、各DCは他の各DCからすべてのMACアドレスをインポートする必要があります。
Even if optimized BGP techniques like RT constraint [RFC4684] are used, the number of MAC addresses to advertise or withdraw (in case of failure) by the GWs of a given DC could overwhelm the NVEs within that DC, particularly when the NVEs reside in the hypervisors.
RT制約[RFC4684]のような最適化されたBGP技術が使用されていても、所与のDCのGWSによってアドバタイズまたは退会するMACアドレスの数は、特にNVEが存在するときにそのDC内のNVSを圧倒する可能性がある。ハイパーバイザー。
The solution specified in this document uses the Unknown MAC Route (UMR) that is advertised into a given DC by each of the DC's GWs. This route is defined in [RFC7543] and is a regular EVPN MAC/IP Advertisement route in which the MAC Address Length is set to 48, the MAC address is set to 0, and the ESI field is set to the DC GW's I-ESI.
このドキュメントで指定された解決策は、DCの各GWによって特定のDCにアドバタイズされている未知のMACルート（UMR）を使用します。このルートは[RFC7543]で定義されており、MACアドレス長が48に設定されている通常のEVPN MAC / IPアドバタイズメントルートであり、MACアドレスは0に設定され、ESIフィールドはDC GWのI-ESIに設定されます。。
An NVE within that DC that understands and processes the UMR will send unknown unicast frames to one of the DC's GWs, which will then forward that packet to the correct egress PE. Note that, because the ESI is set to the DC GW's I-ESI, all-active multihoming can be applied to unknown unicast MAC addresses. An NVE that does not understand the Unknown MAC Route will handle unknown unicast as described in [RFC7432].
UMRを理解し処理するそのDC内のNVEは、未知のユニキャストフレームをDCのGWの1つに送信します。これにより、そのパケットを正しい出力PEに転送します。ESIはDC GWのI-ESIに設定されているため、すべてのアクティブマルチホームを未知のユニキャストMACアドレスに適用できます。未知のMacルートを理解していないNVEは、[RFC7432]に記載されているように未知のユニキャストを処理します。
This document proposes that local policy determine whether MAC addresses and/or the UMR are advertised into a given DC. As an example, when all the DC MAC addresses are learned in the control/ management plane, it may be appropriate to advertise only the UMR. Advertising all the DC MAC addresses in the control/management plane is usually the case when the NVEs reside in hypervisors. Refer to [RFC8365], Section 7.
この文書は、ローカルポリシーがMACアドレスおよび/またはUMRが所与のDCにアドバタイズされているかどうかを決定することを提案している。一例として、全てのDC MACアドレスが制御/管理プレーン内で学習された場合、UMRのみをアドバタイズすることが適切であり得る。制御/管理プレーン内のすべてのDC MACアドレスのアドレスの広告は通常、NVEがハイパーバイザーにある場合です。[RFC8365]、セクション7を参照してください。
It is worth noting that the UMR usage in [RFC7543] and the UMR usage in this document are different. In the former, a Virtual Spoke (V-spoke) does not necessarily learn all the MAC addresses pertaining to hosts in other V-spokes of the same network. The communication between two V-spokes is done through the Default MAC Gateway (DMG) until the V-spokes learn each other's MAC addresses. In this document, two leaf switches in the same DC are recommended for V-spokes to learn each other's MAC addresses for the same EVI. The leaf-to-leaf communication is always direct and does not go through the GW.
[RFC7543]のUMR使用量とこの文書のUMR使用量が異なることは注目に値します。前者では、仮想スポーク（Vスポーク）は必ずしも同じネットワークの他のVスポークのホストに関するすべてのMACアドレスを学習するわけではありません。V-Spokesが互いのMACアドレスを学習するまで、2つのVスポーク間の通信は、デフォルトのMACゲートウェイ（DMG）を介して行われます。このドキュメントでは、同じDC内の2つのリーフスイッチがV-Spokesに推奨されているため、同じEVIの互いのMACアドレスを学びます。葉からリーフの通信は常に直接的で、GWを通過しません。
Another optimization mechanism, naturally provided by EVPN in the GWs, is the Proxy ARP/ND function. The GWs should build a Proxy ARP/ ND cache table, as per [RFC7432]. When the active GW receives an ARP/ND request/solicitation coming from the WAN, the GW does a Proxy ARP/ND table lookup and replies as long as the information is available in its table.
GWS内のEVPNによって自然に提供される別の最適化メカニズムは、プロキシARP / ND機能です。GWは[RFC7432]と同様に、プロキシARP / NDキャッシュテーブルを作成する必要があります。アクティブGWがWANからのARP / ND要求/勧誘を受信すると、その表で情報が入手可能な限り、GWはプロキシARP / NDテーブルの検索および応答を実行します。
This mechanism is especially recommended on the GWs, since it protects the DC network from external ARP/ND-flooding storms.
このメカニズムは、外部ARP / NDフラッディングストームからDCネットワークを保護するため、GWS上で特に推奨されています。
Link/PE failures are handled on the GWs as specified in [RFC7432]. The GW detecting the failure will withdraw the EVPN routes, as per [RFC7432].
[RFC7432]に指定されているように、リンク/ PEの障害はGWSで処理されます。障害を検出するGWは、[RFC7432]に従って、EVPNルートを引き出します。
Individual AC/PW failures may be detected by OAM mechanisms. For instance:
個々のAC / PWの故障は、OAMメカニズムによって検出されてもよい。例えば：
* If the interconnect solution is based on a VLAN handoff, Ethernet-CFM [IEEE.802.1AG] [Y.1731] may be used to detect individual AC failures on both the GW and WAN Edge router. An individual AC failure will trigger the withdrawal of the corresponding A-D per EVI route as well as the MACs learned on that AC.
* インターコネクトソリューションがVLANハンドオフに基づいている場合、Ethernet-CFM [IEEE.802.1AG] [Y.1731]を使用して、GWとWANエッジルータの両方で個々のAC障害を検出できます。個々のAC障害は、そのACで学んだMACをEVIルートごとの対応するA-Dの撤退を引き起こします。
* If the interconnect solution is based on a PW handoff, the Label Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be used to detect individual PW failures on both the GW and WAN Edge router.
* インターコネクト解決策がPWハンドオフに基づいている場合は、GWとWANエッジルータの両方で個々のPWの障害を検出するために、Label Distribution Protocol（LDP）PWステータスBITS TLV [RFC6870]を使用することができます。
When the DC and the WAN are operated by the same administrative entity, the Service Provider can decide to integrate the GW and WAN Edge PE functions in the same router for obvious reasons to save as relates to Capital Expenditure (CAPEX) and Operating Expenses (OPEX). This is illustrated in Figure 2. Note that this model does not provide an explicit demarcation link between DC and WAN anymore. Although not shown in Figure 2, note that the GWs may have local ACs.
DCとWANが同じ管理エンティティによって操作されると、サービスプロバイダーは、設備投資（CAPEX）および営業費用に関するものとして保存する明らかな理由で、GWおよびWANエッジPE機能を同じルータに統合することを決定できます。）。これは図2に示されています。このモデルはDCとWANの間の明示的な境界リンクを提供していません。図2には示されていませんが、GWSはローカルACSを持つことができます。
+--+
|CE|
+--+
|
+----+
+----| PE |----+
+---------+ | +----+ | +---------+
+----+ | +---+ +---+ | +----+
|NVE1|--| | | | | |--|NVE3|
+----+ | |GW1| |GW3| | +----+
| +---+ +---+ |
| NVO-1 | WAN | NVO-2 |
| +---+ +---+ |
| | | | | |
+----+ | |GW2| |GW4| | +----+
|NVE2|--| +---+ +---+ |--|NVE4|
+----+ +---------+ | | +---------+ +----+
+--------------+
|<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->|
|<--PBB-VPLS-->|
Interconnect -> |<-EVPN-MPLS-->|
options |<--EVPN-Ovl-->|*
|<--PBB-EVPN-->|
* EVPN-Ovl stands for EVPN-Overlay (and it's an interconnect option).
* EVPN-OVLはEVPNオーバーレイを表します（そしてそれは相互接続オプションです）。
Figure 2: Integrated Interconnect Model
図2：統合インターコネクトモデル
The integrated interconnect solution meets the following requirements:
統合インターコネクトソリューションは、以下の要件を満たしています。
* Control plane and data plane interworking between the EVPN-Overlay network and the L2VPN technology supported in the WAN, irrespective of the technology choice -- i.e., (PBB-)VPLS or (PBB-)EVPN, as depicted in Figure 2.
* 図2に示すように、技術の選択に関係なく、EVPNオーバーレイネットワークとWANでサポートされているL2VPNテクノロジとの間のコントロールプレーンおよびデータプレーンインターワーキング。
* Multihoming, including single-active multihoming with per-service load balancing or all-active multihoming -- i.e., per-flow load-balancing -- as long as the technology deployed in the WAN supports it.
* サービスごとの負荷分散または全アクティブなマルチホームを持つ単一アクティブマルチホームを含むマルチホーム化 - すなわち、WANに展開された技術がそれをサポートしている限り。
* Support for end-to-end MAC Mobility, Static MAC protection and other procedures (e.g., proxy-arp) described in [RFC7432] as long as EVPN-MPLS is the technology of choice in the WAN.
* EVPN-MPLSがWANに選択する技術である限り、エンドツーエンドMACモビリティ、スタティックMAC保護、および[RFC7432]に記載されている静的MAC保護およびその他の手順（PROXY-ARP）のサポート。
* Independent inclusive multicast trees in the WAN and in the DC. That is, the inclusive multicast tree type defined in the WAN does not need to be the same as in the DC.
* WANおよびDCの独立した包括的なマルチキャストツリー。つまり、WANで定義されている包括的なマルチキャストツリータイプはDCと同じである必要はありません。
Regular MPLS tunnels and Targeted LDP (tLDP) / BGP sessions will be set up to the WAN PEs and RRs as per [RFC4761], [RFC4762], and [RFC6074], and overlay tunnels and EVPN will be set up as per [RFC8365]. Note that different route targets for the DC and the WAN are normally required (unless [RFC4762] is used in the WAN, in which case no WAN route target is needed). A single type-1 RD per service may be used.
通常のMPLSトンネルとターゲットLDP（TLDP）/ BGPセッションは、[RFC4761]、[RFC4762]、[RFC6074]、[RFC6074]、およびオーバーレイトンネルとEVPNは[RFC8365]に従って設定されます。]。DCおよびWANのさまざまなルート目標は通常必要です（WANで[RFC4762]が使用されていない限り、WANルートターゲットが必要な場合）。1台のサービスあたり1タイプ1 RDを使用することができます。
In order to support multihoming, the GWs will be provisioned with an I-ESI (see Section 3.4), which will be unique for each interconnection. In this case, the I-ES will represent the group of PWs to the WAN PEs and GWs. All the [RFC7432] procedures are still followed for the I-ES -- e.g., any MAC address learned from the WAN will be advertised to the DC with the I-ESI in the ESI field.
マルチホームをサポートするために、GWSはI-ESIを使用してプロビジョニングされます（セクション3.4を参照）、各相互接続に固有のものがあります。この場合、I-ESはPWのグループをWAN PESとGWSに表します。すべての[RFC7432]プロシージャには、I-ES-E.-e.が続きます.WANから学んだMACアドレスは、ESIフィールドにI-ESIを使用してDCにアドバタイズされます。
A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have two different types of tunnel bindings instantiated in two different split-horizon groups:
各GWにEVIごとのMAC-VRFが作成されます。MAC-VRFには、2つの異なるスプリットホライズングループでインスタンス化された2つの異なるタイプのトンネルバインディングがあります。
* VPLS PWs will be instantiated in the WAN split-horizon group.
* VPLS PWは、WANスプリットホライズングループでインスタンス化されます。
* Overlay tunnel bindings (e.g., VXLAN, NVGRE) will be instantiated in the DC split-horizon group.
* オーバーレイトンネルバインディング（例えば、VXLAN、NVGRE）は、DCスプリットホライズングループでインスタンス化されます。
Attachment circuits are also supported on the same MAC-VRF (although not shown in Figure 2), but they will not be part of any of the above split-horizon groups.
添付回路は同じMAC-VRFでもサポートされています（図2には示されていません）が、上記のスプリットホライズングループのいずれかの一部ではありません。
Traffic received in a given split-horizon group will never be forwarded to a member of the same split-horizon group.
特定のスプリットホライズングループで受信されたトラフィックは、同じスプリットホライズングループのメンバーに転送されません。
As far as BUM flooding is concerned, a flooding list will be composed of the sublist created by the inclusive multicast routes and the sublist created for VPLS in the WAN. BUM frames received from a local Attachment Circuit (AC) will be forwarded to the flooding list. BUM frames received from the DC or the WAN will be forwarded to the flooding list, observing the split-horizon group rule described above.
バムフラッディングに関する限り、フラッディングリストは、包括的なマルチキャストルートによって作成されたサブリストとWAN内のVPLS用に作成されたサブリストから構成されます。ローカル接続回路（AC）から受信したバムフレームはフラッディングリストに転送されます。DCまたはWANから受信したバムフレームは、上記のスプリットホライズングループルールを観察して、フラッディングリストに転送されます。
Note that the GWs are not allowed to have an EVPN binding and a PW to the same far end within the same MAC-VRF, so that loops and packet duplication are avoided. In case a GW can successfully establish both an EVPN binding and a PW to the same far-end PE, the EVPN binding will prevail, and the PW will be brought down operationally.
GWは、同じMAC-VRF内でEVPNバインディングとPWを同じ端末に持つことができないため、ループとパケットの重複が回避されます。GWがEVPNバインディングとPWの両方を同じ遠端PEに首尾よく確立できる場合、EVPNバインディングが優先され、PWは動作上解除されます。
The optimization procedures described in Section 3.5 can also be applied to this model.
セクション3.5に記載されている最適化手順もこのモデルに適用できます。
This model supports single-active multihoming on the GWs. All-active multihoming is not supported by VPLS; therefore, it cannot be used on the GWs.
このモデルはGWSの単一アクティブマルチホームをサポートしています。全アクティブマルチホームはVPLSではサポートされていません。したがって、GWSでは使用できません。
In this case, for a given EVI, all the PWs in the WAN split-horizon group are assigned to I-ES. All the single-active multihoming procedures as described by [RFC8365] will be followed for the I-ES.
この場合、特定のEVIの場合、WANスプリットホライズングループ内のすべてのPWSがI-ESに割り当てられます。[RFC8365]で説明されているすべての単一アクティブマルチホーム処理は、I-ESの後に続きます。
The non-DF GW for the I-ES will block the transmission and reception of all the PWs in the WAN split-horizon group for BUM and unicast traffic.
I-ES用の非DF GWは、BUMおよびユニキャストトラフィックのWANスプリットホライズングループ内のすべてのPWSの送受信をブロックします。
In this case, there is no impact on the procedures described in [RFC7041] for the B-component. However, the I-component instances become EVI instances with EVPN-Overlay bindings and potentially local attachment circuits. A number of MAC-VRF instances can be multiplexed into the same B-component instance. This option provides significant savings in terms of PWs to be maintained in the WAN.
この場合、B成分の[RFC7041]に記載されている手順に影響を及ぼさない。ただし、IコンポーネントのインスタンスはEVPNオーバーレイバインディングと潜在的に局所的な取り付け回路を持つEVIインスタンスになります。いくつかのMAC-VRFインスタンスを同じBコンポーネントインスタンスに多重化できます。このオプションは、WAN内で維持されるPWSの点で大きな節約を提供します。
The I-ESI concept described in Section 4.2.1 will also be used for the PBB-VPLS-based interconnect.
4.2.1項で説明されているI-ESIの概念もPBB-VPLSベースの相互接続に使用されます。
B-component PWs and I-component EVPN-Overlay bindings established to the same far end will be compared. The following rules will be observed:
同じ遠端に確立されたB成分PWSおよびI成分EVPNオーバーレイ結合を比較する。以下の規則が観察されます。
* Attempts to set up a PW between the two GWs within the B-component context will never be blocked.
* Bコンポーネントのコンテキスト内の2つのGW間にPWを設定しようとすると、ブロックされることはありません。
* If a PW exists between two GWs for the B-component and an attempt is made to set up an EVPN binding on an I-component linked to that B-component, the EVPN binding will be kept down operationally. Note that the BGP EVPN routes will still be valid but not used.
* B - コンポーネントの2つのGWの間にPWが存在し、そのBコンポーネントにリンクされたIコンポーネント上でEVPNバインディングを設定しようとした場合、EVPNバインディングは動作上解除されます。BGP EVPNルートは依然として有効ではなく使用されません。
* The EVPN binding will only be up and used as long as there is no PW to the same far end in the corresponding B-component. The EVPN bindings in the I-components will be brought down before the PW in the B-component is brought up.
* 対応するB-成分の同じ遠端にPWがない限り、EVPNバインディングはアップされ使用されます。I成分中のEVPN結合は、B成分中のPWが育てられる前に停止されるであろう。
The optimization procedures described in Section 3.5 can also be applied to this interconnect option.
セクション3.5に記載されている最適化手順は、この相互接続オプションにも適用できます。
This model supports single-active multihoming on the GWs. All-active multihoming is not supported by this scenario.
このモデルはGWSの単一アクティブマルチホームをサポートしています。すべてのアクティブマルチホームはこのシナリオではサポートされていません。
The single-active multihoming procedures as described by [RFC8365] will be followed for the I-ES for each EVI instance connected to the B-component. Note that in this case, for a given EVI, all the EVPN bindings in the I-component are assigned to the I-ES. The non-DF GW for the I-ES will block the transmission and reception of all the I-component EVPN bindings for BUM and unicast traffic. When learning MACs from the WAN, the non-DF MUST NOT advertise EVPN MAC/IP routes for those MACs.
[RFC8365]で説明されているシングルアクティブマルチホーム処理は、Bコンポーネントに接続されている各EVIインスタンスのI-ESの後に続きます。この場合、所与のEVIの場合、iコンポーネント内のすべてのEVPNバインディングがI-ESに割り当てられます。I-ESの非DF GWは、BUMトラフィックとユニキャストトラフィックのすべてのIコンポーネントEVPNバインディングの送受信をブロックします。WANからMACを学習するとき、非DFはそれらのMACのEVPN MAC / IPルートをアドバタイズしてはいけません。
If EVPN for MPLS tunnels (referred to as "EVPN-MPLS" hereafter) are supported in the WAN, an end-to-end EVPN solution can be deployed. The following sections describe the proposed solution as well as its impact on the procedures from [RFC7432].
MPLSトンネルのEVPN（以下、「EVPN-MPLS」と呼ばれる）がWANでサポートされている場合は、エンドツーエンドEVPNソリューションをデプロイできます。以下のセクションでは、提案されたソリューションとその手順への影響を[RFC7432]の影響について説明します。
The GWs MUST establish separate BGP sessions for sending/receiving EVPN routes to/from the DC and to/from the WAN. Normally, each GW will set up one BGP EVPN session to the DC RR (or two BGP EVPN sessions if there are redundant DC RRs) and one session to the WAN RR (or two sessions if there are redundant WAN RRs).
GWSは、DCとWANへの/ /からのEVPNルートを送受信するための別々のBGPセッションを確立する必要があります。通常、各GWはDC RR（または冗長DC RRSがある場合は2つのBGP EVPNセッション）に1つのBGP EVPNセッションを設定し、WAN RR（または冗長WAN RRSがある場合は2つのセッション）に1つのセッションを設定します。
In order to facilitate separate BGP processes for DC and WAN, EVPN routes sent to the WAN SHOULD carry a different Route Distinguisher (RD) than the EVPN routes sent to the DC. In addition, although reusing the same value is possible, different route targets are expected to be handled for the same EVI in the WAN and the DC. Note that the EVPN service routes sent to the DC RRs will normally include a [RFC9012] BGP encapsulation extended community with a different tunnel type than the one sent to the WAN RRs.
DCおよびWANのための別々のBGPプロセスを容易にするために、WANに送信されたEVPNルートは、DCに送信されたEVPNルートより異なるルート識別子（RD）を持つべきです。さらに、同じ値を再利用することが可能であるが、WANおよびDCの同じEVIについて異なる経路ターゲットが処理されると予想される。DC RRSに送信されたEVPNサービスルートは通常、WAN RRSに送信されたものよりも異なるトンネルタイプを持つ[RFC9012] BGPカプセル拡張コミュニティを含みます。
As in the other discussed options, an I-ES and its assigned I-ESI will be configured on the GWs for multihoming. This I-ES represents the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to the WAN. Optionally, different I-ESI values are configured for representing the WAN and the DC. If different EVPN-Overlay networks are connected to the same group of GWs, each EVPN-Overlay network MUST get assigned a different I-ESI.
他の議論されたオプションのように、I-ESと割り当てられたI-ESIはマルチホームのためのGWS上に設定されます。このI-ESは、DCへのWAN EVPN-MPLS PESを表しますが、DC EVPNオーバーレイNVESへのWANへのものです。任意選択で、異なるI - ESI値は、WANおよびDCを表すように構成されている。異なるEVPNオーバーレイネットワークがGWの同じグループに接続されている場合、各EVPNオーバーレイネットワークは異なるI-ESIを割り当てる必要があります。
Received EVPN routes will never be reflected on the GWs but instead will be consumed and re-advertised (if needed):
受信したEVPNルートはGWSに反映されませんが、代わりに消費されて再広告されます（必要な場合）。
* Ethernet A-D routes, ES routes, and Inclusive Multicast routes are consumed by the GWs and processed locally for the corresponding [RFC7432] procedures.
* イーサネットA-Dルート、ESルート、および包括的なマルチキャストルートはGWSによって消費され、対応する[RFC7432]プロシージャに対してローカルに処理されます。
* MAC/IP advertisement routes will be received and imported, and if they become active in the MAC-VRF, the information will be re-advertised as new routes with the following fields:
* MAC / IPアドバタイズメントルートを受信してインポートします.MAC-VRFでアクティブになった場合、情報は次のフィールドを持つ新しいルートとして再アドバタイズされます。
- The RD will be the GW's RD for the MAC-VRF.
- RDはMAC-VRFのGWのRDになります。
- The ESI will be set to the I-ESI.
- ESIはI-ESIに設定されます。
- The Ethernet-tag value will be kept from the received NLRI the received NLRI.
- Ethernet-Tagの値は、受信したNLRIから受信したNLRIから保持されます。
- The MAC length, MAC address, IP Length, and IP address values will be kept from the received NLRI.
- MAC長、MACアドレス、IP長、およびIPアドレスの値は、受信したNLRIから保持されます。
- The MPLS label will be a local 20-bit value (when sent to the WAN) or a DC-global 24-bit value (when sent to the DC for encapsulations using a VNI).
- MPLSラベルは、ローカルの20ビット値（WANに送信されたとき）またはDCグローバル24ビット値（VNIを使用してカプセル化する場合はDCに送信された場合）になります。
- The appropriate Route Targets (RTs) and [RFC9012] BGP encapsulation extended community will be used according to [RFC8365].
- [RFC8365]に従って、適切な経路ターゲット（RTS）および[RFC9012] BGPカプセル拡張コミュニティが使用されます。
The GWs will also generate the following local EVPN routes that will be sent to the DC and WAN, with their corresponding RTs and [RFC9012] BGP encapsulation extended community values:
GWSは、DCおよびWANに送信される次のローカルEVPNルートも生成され、対応するRTSおよび[RFC9012] BGPカプセル化コミュニティ値：
* ES route(s) for the I-ESI(s).
* I-ESIのためのESルート（S）。
* Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D per-EVI routes sent to the WAN and the DC will have consistent Ethernet-Tag values.
* I-ESIのESとEVIあたりのイーサネットA-Dルート。WANおよびDCに送信されたA-DあたりのEVIルートは、一貫したEthernet-Tag値を持ちます。
* Inclusive Multicast routes with independent tunnel-type value for the WAN and DC. For example, a P2MP Label Switched Path (LSP) may be used in the WAN, whereas ingress replication may be used in the DC. The routes sent to the WAN and the DC will have a consistent Ethernet-Tag.
* WANとDCの独立したトンネル型の値を含む包括的なマルチキャストルート。例えば、P2MPラベルスイッチパス（LSP）をWANに使用することができ、一方、入力複製はDCに使用されてもよい。WANとDCに送信されたルートには、一貫したEthernetタグがあります。
* MAC/IP advertisement routes for MAC addresses learned in local attachment circuits. Note that these routes will not include the I-ESI value in the ESI field. These routes will include a zero ESI or a non-zero ESI for local multihomed Ethernet Segments (ES). The routes sent to the WAN and the DC will have a consistent Ethernet-Tag.
* ローカル接続回路で学習されたMACアドレスのMAC / IPアドバタイズメントルート。これらの経路はESIフィールドにI-ESI値を含まないことに注意してください。これらのルートには、ローカルのマルチホームイーサネットセグメント（ES）用のゼロESIまたは非ゼロESIが含まれます。WANとDCに送信されたルートには、一貫したEthernetタグがあります。
Assuming GW1 and GW2 are peer GWs of the same DC, each GW will generate two sets of the above local service routes: set-DC will be sent to the DC RRs and will include an A-D per EVI, Inclusive Multicast, and MAC/IP routes for the DC encapsulation and RT. Set-WAN will be sent to the WAN RRs and will include the same routes but using the WAN RT and encapsulation. GW1 and GW2 will receive each other's set-DC and set-WAN. This is the expected behavior on GW1 and GW2 for locally generated routes:
GW1とGW2が同じDCのピアGWであると仮定すると、各GWは上記のローカルサービスルートの2セットを生成します.Set-DCはDC RRSに送信され、EVIごとのAD、INS含めるマルチキャスト、MAC / IPが含まれます。DCカプセル化とRTのルートSet-WanはWAN RRSに送信され、同じルートが含まれますが、WAN RTとカプセル化を使用します。GW1とGW2は互いのSET-DCとSET-WANを受け取ります。これが、ローカルに生成されたルートのGW1とGW2の予想される動作です。
* Inclusive multicast routes: When setting up the flooding lists for a given MAC-VRF, each GW will include its DC peer GW only in the EVPN-MPLS flooding list (by default) and not the EVPN-Overlay flooding list. That is, GW2 will import two Inclusive Multicast routes from GW1 (from set-DC and set-WAN) but will only consider one of the two, giving the set-WAN route higher priority. An administrative option MAY change this preference so that the set-DC route is selected first.
* 包括的なマルチキャストルート：特定のMAC-VRFのフラッディングリストを設定するとき、各GWはEVPN-MPLSフラッディングリスト（デフォルトで）のみDCピアGWを含み、EVPNオーバーレイフラッディングリストではありません。つまり、GW2はGW1から2つの包括的なマルチキャストルートをインポートします（Set-DCからSet-WAN）、2つのうちの1つだけを考慮して、セットWANルートをより高い優先順位にします。管理オプションは、SET-DCルートが最初に選択されるように、この設定を変更することができます。
* MAC/IP advertisement routes for local attachment circuits: As above, the GW will select only one, giving the route from the set-WAN a higher priority. As with the Inclusive multicast routes, an administrative option MAY change this priority.
* ローカル接続回路のMAC / IPアドバタイズメントルート：上記のように、GWは1つだけ選択され、セットWANからの経路が高い優先順位になります。包括的なマルチキャストルートと同様に、管理オプションはこの優先順位を変更することがあります。
The procedure explained at the end of the previous section will make sure there are no loops or packet duplication between the GWs of the same EVPN-Overlay network (for frames generated from local ACs), since only one EVPN binding per EVI (or per Ethernet Tag in the case of VLAN-aware bundle services) will be set up in the data plane between the two nodes. That binding will by default be added to the EVPN-MPLS flooding list.
前のセクションの最後に説明されている手順で、EVIごとのEVPNごとのEVPNバインディング（またはイーサネットごとに）1つのEVPNバインディングのみから、同じEVPNオーバーレイネットワークのGW（ローカルACSから生成されたフレーム用）の間にループまたはパケットの重複がないことを確認します。VLAN対応バンドルサービスの場合のタグは、2つのノード間のデータプレーンに設定されます。そのバインディングはデフォルトでEVPN-MPLSフラッディングリストに追加されます。
As for the rest of the EVPN tunnel bindings, they will be added to one of the two flooding lists that each GW sets up for the same MAC-VRF:
残りのEVPNトンネルバインディングに関しては、各GWが同じMAC-VRFを設定する2つのフラッディングリストのいずれかに追加されます。
* EVPN-Overlay flooding list (composed of bindings to the remote NVEs or multicast tunnel to the NVEs).
* EVPNオーバーレイフラッディングリスト（リモートNVESまたはNVESへのマルチキャストトンネルへのバインディングで構成されています）。
* EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the remote PEs).
* EVPN-MPLSフラッディングリスト（MP2PまたはLSMトンネルからリモートPESへのLSMトンネル）。
Each flooding list will be part of a separate split-horizon group: the WAN split-horizon group or the DC split-horizon group. Traffic generated from a local AC can be flooded to both split-horizon groups. Traffic from a binding of a split-horizon group can be flooded to the other split-horizon group and local ACs, but never to a member of its own split-horizon group.
各フラッディングリストは別のスプリットホライズングループの一部になります.WANスプリットホライズングループまたはDCスプリットホライズングループ。ローカルACから生成されたトラフィックは、両方のスプリットホライズングループにフラッディングできます。スプリットホライズングループのバインディングからのトラフィックは、他のスプリットホライズングループおよびローカルACSにフラッディングできますが、独自のスプリットホライズングループのメンバーにはなりません。
When either GW1 or GW2 receives a BUM frame on an MPLS tunnel, including an ESI label at the bottom of the stack, they will perform an ESI label lookup and split-horizon filtering as per [RFC7432], in case the ESI label identifies a local ESI (I-ESI or any other nonzero ESI).
gw1またはgw2のどちらかが、スタックの下部のESIラベルを含むMPLSトンネルでBUMフレームを受信すると、ESIラベルが識別される場合、[RFC7432]に従ってESIラベルルックアップとスプリットホライズンフィルタリングを実行します。ローカルESI（I-ESIまたはその他のゼロ以外のESI）。
This model supports single-active as well as all-active multihoming.
このモデルは、すべてのアクティブなマルチホームをサポートします。
All the [RFC7432] multihoming procedures for the DF election on I-ES(s), as well as the backup-path (single-active) and aliasing (all-active) procedures, will be followed on the GWs. Remote PEs in the EVPN-MPLS network will follow regular [RFC7432] aliasing or backup-path procedures for MAC/IP routes received from the GWs for the same I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes received with the same I-ESI.
すべての[RFC7432]すべての[RFC7432] I-ES上のDF Electionのマルチホーム・プロシージャー、およびバックアップ・パス（シングルアクティブ）およびエイリアス（全アクティブ）手順に従って、GWSが続きます。EVPN-MPLSネットワーク内のリモートPEは、GWSから受信したMAC / IPルートのaliasingまたはbackup-pathプロシージャーを、同じI-ESIに従って実行します。そのため、同じI-ESIで受信されたMAC / IPルート用のEVPNオーバーレイネットワークにNVEがあります。
As far as the forwarding plane is concerned, by default, the EVPN-Overlay network will have an analogous behavior to the access ACs in [RFC7432] multihomed Ethernet Segments.
転送面に関する限り、デフォルトでは、EVPNオーバーレイネットワークは[RFC7432]マルチホームイーサネットセグメント内のアクセスACSに類似の動作をします。
The forwarding behavior on the GWs is described below:
GWSの転送動作については後述する。
* Single-active multihoming; assuming a WAN split-horizon group (comprised of EVPN-MPLS bindings), a DC split-horizon group (comprised of EVPN-Overlay bindings), and local ACs on the GWs:
* 単一活性マルチホームWANスプリットホライズングループ（EVPN-MPLSバインディングから構成される）、DCスプリットホライズングループ（EVPNオーバーレイバインディングからなる）、およびGWS上のローカルACSを仮定します。
- Forwarding behavior on the non-DF: The non-DF MUST block ingress and egress forwarding on the EVPN-Overlay bindings associated to the I-ES. The EVPN-MPLS network is considered to be the core network, and the EVPN-MPLS bindings to the remote PEs and GWs will be active.
- 非DFの転送動作：非DFは、I-ESに関連付けられているEVPNオーバーレイバインディングで入力と出力転送をブロックする必要があります。EVPN-MPLSネットワークはコアネットワークであると見なされ、リモートPESおよびGWSへのEVPN-MPLSバインディングはアクティブになります。
- Forwarding behavior on the DF: The DF MUST NOT forward BUM or unicast traffic received from a given split-horizon group to a member of its own split-horizon group. Forwarding to other split-horizon groups and local ACs is allowed (as long as the ACs are not part of an ES for which the node is non-DF). As per [RFC7432] and for split-horizon purposes, when receiving BUM traffic on the EVPN-Overlay bindings associated to an I-ES, the DF GW SHOULD add the I-ESI label when forwarding to the peer GW over EVPN-MPLS.
- DFの転送動作：DFは、特定のスプリットホライズングループから受信したバラムまたはユニキャストトラフィックを独自のスプリットホライズングループのメンバーに転送してはなりません。他のスプリットホライズングループとローカルACSへの転送は（ACSがノードが非DFの一部ではない限り）許可されます。[RFC7432]とスプリットホライズン目的のために、I-ESに関連付けられているEVPNオーバーレイバインディングでBUMトラフィックを受信すると、DF GWはEVPN-MPLS上でピアGWに転送するときにI-ESIラベルを追加する必要があります。
- When receiving EVPN MAC/IP routes from the WAN, the non-DF MUST NOT reoriginate the EVPN routes and advertise them to the DC peers. In the same way, EVPN MAC/IP routes received from the DC MUST NOT be advertised to the WAN peers. This is consistent with [RFC7432] and allows the remote PE/NVEs to know who the primary GW is, based on the reception of the MAC/IP routes.
- WANからEVPN MAC / IPルートを受信すると、非DFはEVPNルートを再度有してはならず、それらをDCピアにアドバタイズしてください。同様に、DCから受信したEVPN MAC / IPルートをWANピアにアドバタイズしてはいけません。これは[RFC7432]と一致しており、MAC / IPルートの受信に基づいて、リモートPE / NVESがプライマリGWが誰であるかを知ることができます。
* All-active multihoming; assuming a WAN split-horizon group (comprised of EVPN-MPLS bindings), a DC split-horizon group (comprised of EVPN-Overlay bindings), and local ACs on the GWs:
* 全アクティブマルチホームWANスプリットホライズングループ（EVPN-MPLSバインディングから構成される）、DCスプリットホライズングループ（EVPNオーバーレイバインディングからなる）、およびGWS上のローカルACSを仮定します。
- Forwarding behavior on the non-DF: The non-DF follows the same behavior as the non-DF in the single-active case, but only for BUM traffic. Unicast traffic received from a split-horizon group MUST NOT be forwarded to a member of its own split-horizon group but can be forwarded normally to the other split-horizon groups and local ACs. If a known unicast packet is identified as a "flooded" packet, the procedures for BUM traffic MUST be followed.
- 非DFの転送動作：非DFは、単一アクティブな場合の非DFと同じ動作に従いますが、BUMトラフィックのみに従います。スプリットホライズングループから受信したユニキャストトラフィックは、独自のスプリットホライズングループのメンバーに転送されてはいけませんが、他のスプリットホライズングループとローカルACSに正常に転送できません。既知のユニキャストパケットが「フラッド」パケットとして識別された場合、バムトラフィックの手順に従う必要があります。
- Forwarding behavior on the DF: The DF follows the same behavior as the DF in the single-active case, but only for BUM traffic. Unicast traffic received from a split-horizon group MUST NOT be forwarded to a member of its own split-horizon group but can be forwarded normally to the other split-horizon group and local ACs. If a known unicast packet is identified as a "flooded" packet, the procedures for BUM traffic MUST be followed. As per [RFC7432] and for split-horizon purposes, when receiving BUM traffic on the EVPN-Overlay bindings associated to an I-ES, the DF GW MUST add the I-ESI label when forwarding to the peer GW over EVPN-MPLS.
- DFの転送動作：DFは、単一アクティブな場合のDFと同じ動作に従いますが、BUMトラフィックのみに従います。スプリットホライズングループから受信したユニキャストトラフィックは、独自のスプリットホライズングループのメンバーに転送されてはいけませんが、他のスプリットホライズングループとローカルACSに正常に転送できます。既知のユニキャストパケットが「フラッド」パケットとして識別された場合、バムトラフィックの手順に従う必要があります。[RFC7432]とスプリットホライズン目的のために、I-ESに関連付けられているEVPNオーバーレイバインディングでバムトラフィックを受信すると、DF GWはEVPN-MPLS上でピアGWに転送するときにI-ESIラベルを追加する必要があります。
- Contrary to the single-active multihoming case, both DF and non-DF reoriginate and advertise MAC/IP routes received from the WAN/DC peers, adding the corresponding I-ESI so that the remote PE/NVEs can perform regular aliasing, as per [RFC7432].
- 単一アクティブマルチホームケースとは反対に、DFと非DFの両方がWAN / DCピアから受信され、WAN / DCピアから受信したMAC / IPルートをアドバタイズして、リモートPE / NVESが通常のエイリアシングを実行できるようにします。[RFC7432]。
The example in Figure 3 illustrates the forwarding of BUM traffic originated from an NVE on a pair of all-active multihoming GWs.
図3の例は、全アクティブマルチホームGWのペア上のNVEから発生したバムトラフィックの転送を示しています。
|<--EVPN-Overlay--->|<--EVPN-MPLS-->|
+---------+ +--------------+
+----+ BUM +---+ |
|NVE1+----+----> | +-+-----+ |
+----+ | | DF |GW1| | | |
| | +-+-+ | | ++--+
| | | | +--> |PE1|
| +--->X +-+-+ | ++--+
| NDF| | | |
+----+ | |GW2<-+ |
|NVE2+--+ +-+-+ |
+----+ +--------+ | +------------+
v
+--+
|CE|
+--+
Figure 3: Multihoming BUM Forwarding
図3：マルチホームバム転送
GW2 is the non-DF for the I-ES and blocks the BUM forwarding. GW1 is the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2 will include the ESI label for the I-ES. Based on the ESI label, GW2 identifies the packets as I-ES-generated packets and will only forward them to local ACs (CE in the example) and not back to the EVPN-Overlay network.
GW2は、I-ESの非DFであり、BUM転送をブロックします。GW1はDFで、トラフィックをPE1とGW2に転送します。GW2に送信されたパケットには、I-ESのESIラベルが含まれます。ESIラベルに基づいて、GW2はパケットをI-ES生成パケットとして識別し、それらをローカルACS（例ではCE）に転送し、EVPNオーバーレイネットワークに戻りません。
MAC Mobility procedures described in [RFC7432] are not modified by this document.
[RFC7432]で説明されているMACモビリティ手順はこの文書によって変更されません。
Note that an intra-DC MAC move still leaves the MAC attached to the same I-ES, so under the rules of [RFC7432], this is not considered a MAC Mobility event. Only when the MAC moves from the WAN domain to the DC domain (or from one DC to another) will the MAC be learned from a different ES, and the MAC Mobility procedures will kick in.
DC内MACの移動はまだ同じI-ESに接続されているMACを残しているので、[RFC7432]の規則では、これはMACモビリティイベントとは見なされません。MACがWANドメインからDCドメインへ移動するとき（または1つのDCから別のDCへ）の場合のみ、MACは異なるESから学習され、MACモビリティプロシージャがキックインします。
The sticky-bit indication in the MAC Mobility extended community MUST be propagated between domains.
MACモビリティ拡張コミュニティのスティッキビット表示はドメイン間で伝播されなければなりません。
All the Gateway optimizations described in Section 3.5 MAY be applied to the GWs when the interconnect is based on EVPN-MPLS.
インターコネクトがEVPN-MPLSに基づいている場合、セクション3.5に記載されているすべてのゲートウェイの最適化はGWSに適用できます。
In particular, the use of the Unknown MAC Route, as described in Section 3.5.1, solves some transient packet-duplication issues in cases of all-active multihoming, as explained below.
特に、セクション3.5.1で説明されているように、未知のMACルートの使用は、以下に説明するように、全アクティブマルチホームの場合には一時的なパケット複製の問題を解決します。
Consider the diagram in Figure 2 for EVPN-MPLS interconnect and all-active multihoming, and the following sequence:
EVPN-MPLSインターコネクトおよびすべてのアクティブマルチホームのための図2の図を考察し、次のシーケンスを検討してください。
(a) MAC Address M1 is advertised from NVE3 in EVI-1.
(a) MACアドレスM1はEVI-1のNVE3から宣伝されています。
(b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN with I-ESI-2 in the ESI field.
(b) GW3とGW4はEVI-1のM1を学び、ESIフィールドのI-ESI-2でM1をWANに再宣伝します。
(c) GW1 and GW2 learn M1 and install GW3/GW4 as next hops following the EVPN aliasing procedures.
(c) GW1とGW2 EVPNエイリアシング手順に従って、GW3 / GW4を次のホップとしてインストールします。
(d) Before NVE1 learns M1, a packet arrives at NVE1 with destination M1. If the Unknown MAC Route had not been advertised into the DC, NVE1 would have flooded the packet throughout the DC, in particular to both GW1 and GW2. If the same VNI/VSID is used for both known unicast and BUM traffic, as is typically the case, there is no indication in the packet that it is a BUM packet, and both GW1 and GW2 would have forwarded it, creating packet duplication. However, because the Unknown MAC Route had been advertised into the DC, NVE1 will unicast the packet to either GW1 or GW2.
(d) NVE1がM1を習得する前に、パケットは宛先M1とNVE1に到着する。未知のMACルートがDCにアドバタイズされていない場合、NVE1はDC全体にパケットをフラッディングし、特にGW1とGW2の両方にあふれています。同じVNI / VSIDが既知のユニキャストとBUMトラフィックの両方に使用されている場合は、通常、パケットにはパケットではありません.GW1とGW2の両方がそれを転送し、パケットの重複を作成しました。ただし、未知のMACルートはDCにアドバタイズされていたため、NVE1はパケットをGW1またはGW2のいずれかにユニキャストします。
(e) Since both GW1 and GW2 know M1, the GW receiving the packet will forward it to either GW3 or GW4.
(e) GW1とGW2の両方がM1を知っているので、パケットを受信したGWはそれをGW3またはGW4に転送します。
The "DCI using ASBRs" solution described in [RFC8365] and the GW solution with EVPN-MPLS interconnect may be seen as similar, since they both retain the EVPN attributes between Data Centers and throughout the WAN. However, the EVPN-MPLS interconnect solution on the GWs has significant benefits compared to the "DCI using ASBRs" solution:
[RFC8365]に記載されている「DCIを使用しているDCIを使用したDCIを使用したDCIを使用したDCIを使用したDCIを使用したDCIを使用したDCI-MPLSインターコネクトは、データセンターとWAN全体にわたってEVPN属性を保持しているため、類似している可能性があります。ただし、GWS上のEVPN-MPLS相互接続ソリューションは、「ASBRを使用したDCI」ソリューションと比較して大きな利点があります。
* As in any of the described GW models, this solution supports the connectivity of local attachment circuits on the GWs. This is not possible in a "DCI using ASBRs" solution.
* 記載されたGWモデルのいずれかのように、この解決策はGWS上のローカルアタッチメント回路の接続性をサポートします。これは「ASBRを使用したDCI」ソリューションではできません。
* Different data plane encapsulations can be supported in the DC and the WAN, while a uniform encapsulation is needed in the "DCI using ASBRs" solution.
* DCおよびWAN内で異なるデータプレーンカプセル化をサポートすることができ、一方では均一なカプセル化が「ASBRを使用したDCI」ソリューションで必要とされる。
* Optimized multicast solution, with independent inclusive multicast trees in DC and WAN.
* DCとWANの独立した包括的なマルチキャストツリーを持つ、マルチキャストソリューションを最適化しました。
* MPLS label aggregation: For the case where MPLS labels are signaled from the NVEs for MAC/IP advertisement routes, this solution provides label aggregation. A remote PE MAY receive a single label per GW MAC-VRF, as opposed to a label per NVE/MAC-VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE would receive only one label for all the routes advertised for a given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF.
* MPLSラベル集約：MPLSラベルがMAC / IPアドバタイズメントルートのNVESからシグナリングされている場合、このソリューションはラベル集計を提供します。GW MAC - VRFに接続されたNVE / MAC - VRFあたりのラベルとは対照的に、リモートPEはGW MAC - VRFごとに単一のラベルを受信することができる。たとえば、図2では、PEは、NVE / MAC-VRFごとのラベルとは対照的に、GW1から特定のMAC-VRFに対してアドバタイズされたすべてのルートに対して1つのラベルだけを受信します。
* The GW will not propagate MAC Mobility for the MACs moving within a DC. Mobility intra-DC is solved by all the NVEs in the DC. The MAC Mobility procedures on the GWs are only required in case of mobility across DCs.
* GWは、DC内で移動するMACのMACモビリティを伝播しません。Mobility Intra-DCは、DC内のすべてのNVEによって解かれます。GW上のMACモビリティ手順は、DCS全体のモビリティの場合にのみ必要です。
* Proxy-ARP/ND function on the DC GWs can be leveraged to reduce ARP/ND flooding in the DC or/and the WAN.
* DC GWS上のProxy-ARP / ND機能は、DCまたは/およびWANのARP / NDフラッディングを減らすために活用できます。
PBB-EVPN [RFC7623] is yet another interconnect option. It requires the use of GWs where I-components and associated B-components are part of EVI instances.
PBB-EVPN [RFC7623]はまだ別の相互接続オプションです。Iコンポーネントと関連するBコンポーネントがEVIインスタンスの一部であるGWの使用を必要とします。
EVPN will run independently in both components, the I-component MAC-VRF and B-component MAC-VRF. Compared to [RFC7623], the DC customer MACs (C-MACs) are no longer learned in the data plane on the GW but in the control plane through EVPN running on the I-component. Remote C-MACs coming from remote PEs are still learned in the data plane. B-MACs in the B-component will be assigned and advertised following the procedures described in [RFC7623].
EVPNは両方のコンポーネント、iコンポーネントのMAC-VRF、およびBコンポーネントのMAC-VRFの両方で独立して実行されます。[RFC7623]と比較して、DC顧客MAC（C-MACS）は、GW上のデータプレーンではなく、Iコンポーネント上で実行されているEVPNを介して制御プレーンではもはや学習されません。リモートPESからのリモートC-MACはまだデータプレーンで学習されています。B-ComponentのB-MACは、[RFC7623]に記載されている手順に従って割り当てられて宣伝されます。
An I-ES will be configured on the GWs for multihoming, but its I-ESI will only be used in the EVPN control plane for the I-component EVI. No unreserved ESIs will be used in the control plane of the B-component EVI, as per [RFC7623]. That is, the I-ES will be represented to the WAN PBB-EVPN PEs using shared or dedicated B-MACs.
I-ESはマルチホームのGWS上に設定されますが、そのI-ESIはIコンポーネントEVIのEVPNコントロールプレーンでのみ使用されます。[RFC7623]と同様に、BコンポーネントEVIの制御面には、未保持されていない存在は使用されません。つまり、I-ESは、共有または専用のB-MACを使用してWAN PBB-EVPN PESに表されます。
The rest of the control plane procedures will follow [RFC7432] for the I-component EVI and [RFC7623] for the B-component EVI.
残りの管理プレーン手順は、BコンポーネントEVIのIコンポーネントEVIおよび[RFC7623]の[RFC7432]に続きます。
From the data plane perspective, the I-component and B-component EVPN bindings established to the same far end will be compared, and the I-component EVPN-Overlay binding will be kept down following the rules described in Section 4.3.1.
データプレーンの観点からは、同じ遠端に確立されたIコンポーネントとBコンポーネントEVPNバインディングが比較され、IコンポーネントEVPNオーバーレイバインディングは4.3.1項に記載されている規則に従って保持されます。
This model supports single-active as well as all-active multihoming.
このモデルは、すべてのアクティブなマルチホームをサポートします。
The forwarding behavior of the DF and non-DF will be changed based on the description outlined in Section 4.4.3, substituting the WAN split-horizon group for the B-component, and using [RFC7623] procedures for the traffic sent or received on the B-component.
DFと非DFの転送動作は、4.4.3項で概説されている説明に基づいて、B-ComponentのWANスプリットホライズングループの代わりに、送受信されたトラフィックの[RFC7623]の手順を使用して、4.4.3項で変更されます。B成分
C-MACs learned from the B-component will be advertised in EVPN within the I-component EVI scope. If the C-MAC was previously known in the I-component database, EVPN would advertise the C-MAC with a higher sequence number, as per [RFC7432]. From the perspective of Mobility and the related procedures described in [RFC7432], the C-MACs learned from the B-component are considered local.
Bコンポーネントから学んだC-MACは、IコンポーネントEVIスコープ内でEVPNでアドバタイズされます。C-MACがIコンポーネントデータベースで以前に知られていた場合、EVPNは[RFC7432]に従って、より高いシーケンス番号でC-MACをアドバタイズします。[RFC7432]に記載されている移動性と関連手順の観点からは、B - コンポーネントから学んだC-MACSはローカルと見なされます。
All the considerations explained in Section 4.4.5 are applicable to the PBB-EVPN interconnect option.
セクション4.4.5で説明されているすべての考慮事項は、PBB-EVPN Interconnectオプションに適用されます。
If EVPN for Overlay tunnels is supported in the WAN, and a GW function is required, an end-to-end EVPN solution can be deployed. While multiple Overlay tunnel combinations at the WAN and the DC are possible (MPLSoGRE, NVGRE, etc.), VXLAN is described here, given its popularity in the industry. This section focuses on the specific case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the [RFC7432] procedures.
オーバーレイトンネルのEVPNがWANでサポートされており、GW機能が必要な場合は、エンドツーエンドEVPNソリューションを展開できます。WANとDCでの複数のオーバーレイトンネルの組み合わせが可能である（Mplsogre、Nvgreなど）、業界での人気を考えると、VXLANについて説明します。このセクションでは、VXLAN（以降EVPN-VXLAN）のEVPNの特定の場合と[RFC7432]の手順に焦点を当てています。
The procedures described in Section 4.4 apply to this section, too, only substituting EVPN-MPLS for EVPN-VXLAN control plane specifics and using [RFC8365] "Local Bias" procedures instead of Section 4.4.3. Since there are no ESI labels in VXLAN, GWs need to rely on "Local Bias" to apply split horizon on packets generated from the I-ES and sent to the peer GW.
4.4節で説明されている手順もこのセクションに適用され、EVPN-VXLAN Control Plane Scaticsおよび[RFC8365]「RFC8365」の「ローカルバイアス」手順をセクション4.4.3で代用しています。VXLANにESIラベルがないため、GWSはI-ESから生成されたパケットに分割してピアGWに送信されるように、「ローカルバイアス」に頼る必要があります。
This use case assumes that NVEs need to use the VNIs or VSIDs as globally unique identifiers within a Data Center, and a Gateway needs to be employed at the edge of the Data-Center network to translate the VNI or VSID when crossing the network boundaries. This GW function provides VNI and tunnel-IP-address translation. The use case in which local downstream-assigned VNIs or VSIDs can be used (like MPLS labels) is described by [RFC8365].
このユースケースは、データセンター内のグローバルに一意の識別子としてVNISまたはVSIDを使用する必要があると仮定し、ネットワーク境界を横切るときにVNIまたはVSIDを変換するためにゲートウェイをデータセンターネットワークのエッジで採用する必要があります。このGW関数は、VNIとTunnel-IPアドレス変換を提供します。ローカルダウンストリーム割り当てされたVNISまたはVSIDを使用できるユースケース（MPLSラベルのように）は、[RFC8365]によって説明されています。
While VNIs are globally significant within each DC, there are two possibilities in the interconnect network:
VNISは各DC内でグローバルに重要ですが、インターコネクトネットワークには2つの可能性があります。
1. Globally unique VNIs in the interconnect network. In this case, the GWs and PEs in the interconnect network will agree on a common VNI for a given EVI. The RT to be used in the interconnect network can be autoderived from the agreed-upon interconnect VNI. The VNI used inside each DC MAY be the same as the interconnect VNI.
1. インターコネクトネットワーク内のグローバルに一意のVNI。この場合、相互接続ネットワーク内のGWSとPEは、特定のEVIのための一般的なVNIについて一致するでしょう。相互接続ネットワークで使用されるRTは、合意された相互接続VNIから自己指定され得る。各DC内に使用されるVNIは、相互接続VNIと同じであり得る。
2. Downstream-assigned VNIs in the interconnect network. In this case, the GWs and PEs MUST use the proper RTs to import/export the EVPN routes. Note that even if the VNI is downstream assigned in the interconnect network, and unlike option (a), it only identifies the <Ethernet Tag, GW> pair and not the <Ethernet Tag, egress PE> pair. The VNI used inside each DC MAY be the same as the interconnect VNI. GWs SHOULD support multiple VNI spaces per EVI (one per interconnect network they are connected to).
2. インターコネクトネットワーク内のダウンストリーム割り当てVNI。この場合、GWSとPESはEVPNルートをインポート/エクスポートするために適切なRTSを使用する必要があります。インターコネクトネットワークでVNIが割り当てられている場合でも、オプション（A）とは異なり、<Ethernet Tag GW>ペアではなく、<ethernetタグ、Egress PE>ペアを識別します。各DC内に使用されるVNIは、相互接続VNIと同じであり得る。GWは、EVIごとに複数のVNIスペースをサポートする必要があります（接続されている相互接続ネットワークごとに1つ）。
In both options, NVEs inside a DC only have to be aware of a single VNI space, and only GWs will handle the complexity of managing multiple VNI spaces. In addition to VNI translation above, the GWs will provide translation of the tunnel source IP for the packets generated from the NVEs, using their own IP address. GWs will use that IP address as the BGP next hop in all the EVPN updates to the interconnect network.
どちらのオプションでも、DC内のNVESは単一のVNIスペースを認識しなければならず、GWSだけが複数のVNIスペースを管理する複雑さを処理します。上記のVNI変換に加えて、GWは、NVESから生成されたパケットのトンネルソースIPの翻訳を提供します。GWSは、InterConnectネットワークへのすべてのEVPN更新でBGPネクストホップとしてそのIPアドレスを使用します。
The following sections provide more details about these two options.
次のセクションでは、これら2つのオプションに関する詳細について説明します。
Considering Figure 2, if a host H1 in NVO-1 needs to communicate with a host H2 in NVO-2, and assuming that different VNIs are used in each DC for the same EVI (e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2), then the VNIs MUST be translated to a common interconnect VNI (e.g., VNI-100) on the GWs. Each GW is provisioned with a VNI translation mapping so that it can translate the VNI in the control plane when sending BGP EVPN route updates to the interconnect network. In other words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the BGP update messages for H1's MAC route. This mapping is also used to translate the VNI in the data plane in both directions: that is, VNI-10 to VNI-100 when the packet is received from NVO-1 and the reverse mapping from VNI-100 to VNI-10 when the packet is received from the remote NVO-2 network and needs to be forwarded to NVO-1.
図2を考慮して、NVO - 1内のホストH1がNVO - 2のホストH2と通信する必要がある場合、および同じEVIの各DCで異なるVNIを使用していると仮定して（例えば、NVO - 1およびVNIのVNI - 10-20 NVO-2では、VNISはGWS上の共通の相互接続VNI（例えばVNI-100）に変換されなければなりません。各GWは、BGP EVPN経路更新を相互接続ネットワークに送信するときに、制御プレーン内のVNIを変換することができるように、VNI変換マッピングを使用してプロビジョニングされます。言い換えれば、GW1とGW2は、H1のMACルートのBGP更新メッセージでVNI-10をVNI-100にマッピングするように構成されている必要があります。このマッピングは、データプレーン内のVNIを両方向に翻訳するためにも使用されます。つまり、パケットがNVO-1から受信されたときにVNI-10からVNI-100へ、およびVNI-100からVNI-10までの逆マッピングがある場合パケットはリモートNVO-2ネットワークから受信され、NVO-1に転送される必要があります。
The procedures described in Section 4.4 will be followed, considering that the VNIs advertised/received by the GWs will be translated accordingly.
節4.4に記載されている手順に従うと、GWSによって宣伝/受信されたVNIがそれに応じて翻訳されることを考慮して説明される。
In this case, if a host H1 in NVO-1 needs to communicate with a host H2 in NVO-2, and assuming that different VNIs are used in each DC for the same EVI, e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs MUST be translated as in Section 4.6.1. However, in this case, there is no need to translate to a common interconnect VNI on the GWs. Each GW can translate the VNI received in an EVPN update to a locally assigned VNI advertised to the interconnect network. Each GW can use a different interconnect VNI; hence, this VNI does not need to be agreed upon on all the GWs and PEs of the interconnect network.
この場合、NVO - 2のホストH1がNVO - 2のホストH2と通信する必要がある場合、および同じEVIの各DCで異なるVNIが使用されていると仮定して、例えばNVO - 1およびVNIのVNI - 10-20 NVO-2では、VNISはセクション4.6.1のように変換する必要があります。ただし、この場合、GWS上の共通の相互接続VNIに変換する必要はありません。各GWは、EVPNアップデートで受信されたVNIを、インターコネクトネットワークにアドバタイズされたローカルに割り当てられたVNIに翻訳することができる。各GWは異なる相互接続VNIを使用できます。したがって、このVNIは、相互接続ネットワークのすべてのGWおよびPESについて合意する必要はない。
The procedures described in Section 4.4 will be followed, taking into account the considerations above for the VNI translation.
VNI翻訳についての上記の考慮事項を考慮して、セクション4.4に記載されている手順に従います。
This document applies existing specifications to a number of interconnect models. The security considerations included in those documents, such as [RFC7432], [RFC8365], [RFC7623], [RFC4761], and [RFC4762] apply to this document whenever those technologies are used.
この文書は既存の仕様を多数の相互接続モデルに適用します。[RFC7432]、[RFC8365]、[RFC7623]、[RFC4761]、[RFC4761]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4761]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]、[RFC4762]）が適用されます。
As discussed, [RFC8365] discusses two main DCI solution groups: "DCI using GWs" and "DCI using ASBRs". This document specifies the solutions that correspond to the "DCI using GWs" group. It is important to note that the use of GWs provides a superior level of security on a per-tenant basis, compared to the use of ASBRs. This is due to the fact that GWs need to perform a MAC lookup on the frames being received from the WAN, and they apply security procedures, such as filtering of undesired frames, filtering of frames with a source MAC that matches a protected MAC in the DC, or application of MAC-duplication procedures defined in [RFC7432]. On ASBRs, though, traffic is forwarded based on a label or VNI swap, and there is usually no visibility of the encapsulated frames, which can carry malicious traffic.
説明したように、[RFC8365]は2つの主要なDCIソリューショングループについて説明します。「GWSを使用したDCI」と「ASBRを使用してDCI」を説明します。このドキュメントは、「GWSを使用したDCI」グループに対応する解決策を指定します。GWSの使用は、ASBRの使用と比較して、テナントごとに優れたレベルのセキュリティを提供することに注意することが重要です。これは、GWがWANから受信されているフレーム上でMACルックアップを実行する必要があり、望ましくないフレームのフィルタリングなどのセキュリティ手順を適用し、保護されたMacと一致するソースMACを使用してフレームのフィルタリングを適用します。DC、または[RFC7432]で定義されているMAC複製手順の適用。ただし、ASBRでは、トラフィックはラベルまたはVNIスワップに基づいて転送され、通常はカプセル化されたフレームの可視性はありません。
In addition, the GW optimizations specified in this document provide additional protection of the DC tenant systems. For instance, the MAC-address advertisement control and Unknown MAC Route defined in Section 3.5.1 protect the DC NVEs from being overwhelmed with an excessive number of MAC/IP routes being learned on the GWs from the WAN. The ARP/ND flooding control described in Section 3.5.2 can reduce/suppress broadcast storms being injected from the WAN.
さらに、この文書で指定されているGW最適化は、DCテナントシステムの追加保護を提供します。たとえば、セクション3.5.1で定義されているMACアドレス広告制御と未知のMACルートは、DC NVESがWANからGWS上で多数のMAC / IPルートを習得していることから圧倒されます。セクション3.5.2に記載されているARP / NDフラッディング制御は、WANから放送されているブロードキャストストームを削減/抑制することができます。
Finally, the reader should be aware of the potential security implications of designing a DCI with the decoupled interconnect solution (Section 3) or the integrated interconnect solution (Section 4). In the decoupled interconnect solution, the DC is typically easier to protect from the WAN, since each GW has a single logical link to one WAN PE, whereas in the Integrated solution, the GW has logical links to all the WAN PEs that are attached to the tenant. In either model, proper control plane and data plane policies should be put in place in the GWs in order to protect the DC from potential attacks coming from the WAN.
最後に、リーダーは、DCIをデカップリングした相互接続ソリューション（セクション3）または統合インターコネクトソリューションを使用してDCIを設計する潜在的なセキュリティの意味を認識する必要があります（セクション4）。デカップリングされた相互接続ソリューションでは、各GWが1つのWAN PEへの単一の論理リンクを持つのに対し、WANからDCを保護しやすく、GWはに接続されているすべてのWAN PEへの論理リンクを持ちます。テナント。どちらのモデルでも、WANからの潜在的な攻撃からDCを保護するために、適切なコントロールプレーンとデータプレーンのポリシーをGWSに配置する必要があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、ED。そして、rekhter、ed。、 "Virtual Private Lan Service（VPLS）、「自動検出およびシグナリングのためのBGPを使用したVPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<https：//www.rfc-editor.org/情報/ RFC4761>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M.、Ed。V. Kompella、ed。、「ラベル配布プロトコル（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（VPLS）、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<https：//www.rfc-editor.org/情報/ RFC4762>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E.、Davie、B.、Radoaca、V.、およびW.Luo、「レイヤ2仮想プライベートネットワークにおけるプロビジョニング、自動発見、およびシグナリング（L2VPNS）」、RFC 6074、DOI 10.17487 / RFC6074、2011年1月、<https://www.rfc-editor.org/info/rfc6074>。
[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 10.17487/RFC7041, November 2013, <https://www.rfc-editor.org/info/rfc7041>.
[RFC7041] Sajassi、A.、ED。、SAJASSI、A.、ED。、「バーチャルプライベートLANサービス（VPLS）プロバイダへの拡張（Provider Backbone Bridging用PE）モデル」RFC 7041、DOI 10.17487 / RFC7041、2013年11月、<https：//www.rfc-editor.org/info/rfc7041>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、およびW.HenderickX、「BGP MPLSベースのイーサネットVPN」、RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https：//www.rfc-editor.org/info/rfc7432>。
[RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, "Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI 10.17487/RFC7543, May 2015, <https://www.rfc-editor.org/info/rfc7543>.
[RFC7543] Jeng、H.、Jalil、L.、BGP-4の「カバープレフィックスアウトバウンドルートフィルタ」、RFC 7543、DOI 10.17487 / RFC7543、2015年5月<https：//www.rfc-editor.org/info/rfc7543>。
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC7623] Sajassi、A.、Ed。、Salam、S、Bitar、N.、ISAAC、A.、およびW.HenderickX、「イーサネットVPNと組み合わせたプロバイダバックボーンブリッジング（PBB-EVPN）」、RFC 7623、DOI10.17487 / RFC7623、2015年9月、<https：//www.rfc-editor.org/info/rfc7623>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>.
[RFC8365] Sajassi、A.、ED。、Drake、J.、Ed。、Bitar、N.、Shekhar、R.、Uttaro、J.、およびW.HenderickX、「イーサネットVPNを使用したネットワーク仮想化オーバーレイソリューション（EVPN） "、RFC 8365、DOI 10.17487 / RFC8365、2018年3月、<https：//www.rfc-editor.org/info/rfc8365>。
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.
[RFC9012]聖母、K.、Van de Velde、G.、Sangli、S.、およびJ.Scudder、「BGPトンネルカプセル化属性」、RFC 9012、DOI 10.17487 / RFC9012、2021年4月、<https：// www.rfc-editor.org / info / rfc9012>。
[IEEE.802.1AG] IEEE, "IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", IEEE standard 802.1ag-2007, January 2008.
[IEEE.802.1AG] IEEE、「地元およびメトロポリタン地域ネットワークのIEEE規格仮想ブリッジローカルエリアネットワークアフション5：接続障害管理」、IEEE規格802.1AG-2007、2007年1月。
[IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE standard 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December 2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
[IEEE.802.1Q] IEEE、「地元の地域と首都圏ネットワークのIEEE規格 - ブリッジ＆ブリッジネットワーク」、IEEE規格802.1Q-2014、DOI 10.1109 / IEEESTD.2014.6991462、2014年12月、<https：//doi.org/ 10.1109/ieeestd.2014.6991462>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]ローゼン、E.、Viswanathan、A.およびR.Callon、 "Multiprotocol Label Switche Architecture"、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https：//www.rfc-editor.org/info/ RFC3031>。
[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>.
[RFC4023]深夜、T.、Rekhter、Y.、E.Rosen、ED、「IPまたはGeneric Routing Clackapulation（GRE）」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<https：//www.rfc-editor.org/info/rfc4023>。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ.Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングのための制約付きルート配布（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPNS） "、RFC 4684、DOI 10.17487 / RFC4684、2006年11月、<https://www.rfc-editor.org/info/rfc4684>。
[RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, February 2013, <https://www.rfc-editor.org/info/rfc6870>.
[RFC6870] Muley、P.、ED。2013年2月、<https://www.rfc-editor.org/info/rfc6870、<https://www.rfc-editor.org/info/rfc6870、<https：//www.rfc-editor.org/info/rfc6870>。
[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>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M.、およびC.ライト「仮想拡張ローカルエリアネットワーク（VXLAN）：Layer 3ネットワーク上の仮想化レイヤ2ネットワークを重ねるフレームワーク「RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https：//www.rfc-editor.org/info/rfc7348>。
[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>.
[RFC7637] Garg、P.、ED。Y。、「NVGRE：汎用ルーティングカプセル化を使用したネットワーク仮想化」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<https：//www.rfc-editor.org/info/rfc7637>。
[VIRTUAL-ES] Sajassi, A., Brissette, P., Schell, R., Drake, J. E., and J. Rabadan, "EVPN Virtual Ethernet Segment", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-eth-segment-06, 9 March 2020, <https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-eth-segment-06>.
[Virtual-ES] Sajassi、A.、ブッケ、P.、Schell、R.、Drake、J.. Rabadan、「EVPN仮想イーサネットセグメント」、進行中の作業、インターネットドラフト、Draft-IETF-Bess-evpn-virtual-eth-06,06,200月9日、<https：//tools.ietf.org/html/draft-ietf-bess-evpn-virtual-eth-segment-06>。
[Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation Y.1731, August 2019.
[Y.1731] 2019年8月、「イーサネットベースのネットワークのためのOAMの機能とメカニズム」、ITU-T勧告Y.1731。
Acknowledgments
謝辞
The authors would like to thank Neil Hart, Vinod Prabhu, and Kiran Nagaraj for their valuable comments and feedback. We would also like to thank Martin Vigoureux and Alvaro Retana for their detailed reviews and comments.
著者らは、貴重なコメントとフィードバックについてNeil Hart、Vinod Prabhu、およびKiran Nagarajに感謝します。また、Martin VigoueuxとAlvaro Retanaに彼らの詳細なレビューとコメントを与えてくれてありがとう。
Contributors
貢献者
In addition to the authors listed on the front page, the following coauthors have also contributed to this document:
フロントページに記載されている作者に加えて、次のCoAuthorsもこの文書に貢献しています。
Ravi Shekhar Juniper Networks
Ravi Shekhar Juniperネットワーク
Anil Lohiya Juniper Networks
Anil Lohiya Juniperネットワーク
Wen Lin Juniper Networks
WEN LINジュニパーネットワーク
Florin Balus Cisco
フロリンブラウスシスコ
Patrice Brissette Cisco
Patrice Brissette Cisco.
Senad Palislamovic Nokia
セネドパリマウのノキア
Dennis Cai Alibaba
デニスカイアリババ
Authors' Addresses
著者の住所
Jorge Rabadan (editor) Nokia 777 E. Middlefield Road Mountain View, CA 94043 United States of America
Jorge Rabadan（編集）ノキア777 E.ミドルフィールドロードマウンテンビュー、CA 94043アメリカ
Email: jorge.rabadan@nokia.com
Senthil Sathappan Nokia
Senthil Sathappan Nokia.
Email: senthil.sathappan@nokia.com
Wim Henderickx Nokia
Wim Henderickx Nokia.
Email: wim.henderickx@nokia.com
Ali Sajassi Cisco
アリ・サジャシCisco.
Email: sajassi@cisco.com
John Drake Juniper
ジョン・ドレイク・ジュニパー
Email: jdrake@juniper.net