[要約] RFC 8365は、Ethernet VPN（EVPN）を使用したネットワーク仮想化オーバーレイソリューションに関するものです。このRFCの目的は、EVPNを使用してネットワーク仮想化を実現するためのガイドラインと手法を提供することです。
Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 8365 Cisco
Category: Standards Track J. Drake, Ed.
ISSN: 2070-1721 Juniper
N. Bitar
Nokia
R. Shekhar
Juniper
J. Uttaro
AT&T
W. Henderickx
Nokia
March 2018
A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)
イーサネットVPN（EVPN）を使用したネットワーク仮想化オーバーレイソリューション
Abstract
概要
This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.
このドキュメントでは、イーサネットVPN（EVPN）をネットワーク仮想化オーバーレイ（NVO）ソリューションとして使用する方法を指定し、IPを介したさまざまなトンネルカプセル化オプションと、それらがEVPNコントロールプレーンと手順に与える影響について説明します。特に、次のカプセル化オプションが分析されます。仮想拡張LAN（VXLAN）、Generic Routing Encapsulation（NVGRE）を使用したネットワーク仮想化、およびMPLS over GRE。この仕様は、Generic Network Virtualization Encapsulation（GENEVE）にも適用されます。ただし、いくつかの増分作業が必要です。これについては、別のドキュメントで説明します。このドキュメントでは、スプリットホライズンフィルタリングと大量回収のための新しいマルチホーミング手順についても説明しています。また、VXLAN / NVGREカプセル化のEVPNルート構成と、ネットワーク仮想化エッジ（NVE）デバイスのマルチホーミング用の自律システム境界ルーター（ASBR）手順も指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8365.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8365で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Requirements Notation and Conventions ...........................5
3. Terminology .....................................................5
4. EVPN Features ...................................................7
5. Encapsulation Options for EVPN Overlays .........................8
5.1. VXLAN/NVGRE Encapsulation ..................................8
5.1.1. Virtual Identifiers Scope ...........................9
5.1.2. Virtual Identifiers to EVI Mapping .................11
5.1.3. Constructing EVPN BGP Routes .......................13
5.2. MPLS over GRE .............................................15
6. EVPN with Multiple Data-Plane Encapsulations ...................15
7. Single-Homing NVEs - NVE Residing in Hypervisor ................16
7.1. Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE ....16
7.2. Impact on EVPN Procedures for VXLAN/NVGRE Encapsulations ..17
8. Multihoming NVEs - NVE Residing in ToR Switch ..................18
8.1. EVPN Multihoming Features .................................18
8.1.1. Multihomed ES Auto-Discovery .......................18
8.1.2. Fast Convergence and Mass Withdrawal ...............18
8.1.3. Split-Horizon ......................................19
8.1.4. Aliasing and Backup Path ...........................19
8.1.5. DF Election ........................................20
8.2. Impact on EVPN BGP Routes and Attributes ..................20
8.3. Impact on EVPN Procedures .................................20
8.3.1. Split Horizon ......................................21
8.3.2. Aliasing and Backup Path ...........................22
8.3.3. Unknown Unicast Traffic Designation ................22
9. Support for Multicast ..........................................23
10. Data-Center Interconnections (DCIs) ...........................24
10.1. DCI Using GWs ............................................24
10.2. DCI Using ASBRs ..........................................24
10.2.1. ASBR Functionality with Single-Homing NVEs ........25
10.2.2. ASBR Functionality with Multihoming NVEs ..........26
11. Security Considerations .......................................28
12. IANA Considerations ...........................................29
13. References ....................................................29
13.1. Normative References .....................................29
13.2. Informative References ...................................30
Acknowledgements ..................................................32
Contributors ......................................................32
Authors' Addresses ................................................33
This document specifies how Ethernet VPN (EVPN) [RFC7432] can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN) [RFC7348], Network Virtualization using Generic Routing Encapsulation (NVGRE) [RFC7637], and MPLS over Generic Routing Encapsulation (GRE) [RFC4023]. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE) [GENEVE]; however, some incremental work is required, which will be covered in a separate document [EVPN-GENEVE]. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.
このドキュメントでは、イーサネットVPN（EVPN）[RFC7432]をネットワーク仮想化オーバーレイ（NVO）ソリューションとして使用する方法を指定し、IPを介したさまざまなトンネルカプセル化オプションと、それらがEVPNコントロールプレーンと手順に与える影響について説明します。特に、次のカプセル化オプションが分析されます：仮想拡張LAN（VXLAN）[RFC7348]、汎用ルーティングカプセル化を使用したネットワーク仮想化（NVGRE）[RFC7637]、およびMPLS over Generic Routing Encapsulation（GRE）[RFC4023]。この仕様は、Generic Network Virtualization Encapsulation（GENEVE）[GENEVE]にも適用されます。ただし、追加の作業が必要です。これについては、別のドキュメント[EVPN-GENEVE]で説明します。このドキュメントでは、スプリットホライズンフィルタリングと大量回収のための新しいマルチホーミング手順についても説明しています。また、VXLAN / NVGREカプセル化のEVPNルート構成と、ネットワーク仮想化エッジ（NVE）デバイスのマルチホーミング用の自律システム境界ルーター（ASBR）手順も指定します。
In the context of this document, an NVO is a solution to address the requirements of a multi-tenant data center, especially one with virtualized hosts, e.g., Virtual Machines (VMs) or virtual workloads. The key requirements of such a solution, as described in [RFC7364], are the following:
このドキュメントのコンテキストでは、NVOはマルチテナントデータセンターの要件に対処するためのソリューションであり、特に仮想マシン（VM）または仮想ワークロードなどの仮想化ホストを備えたものです。 [RFC7364]で説明されている、このようなソリューションの主要な要件は次のとおりです。
- Isolation of network traffic per tenant
- テナントごとのネットワークトラフィックの分離
- Support for a large number of tenants (tens or hundreds of thousands)
- 多数のテナント（数万または数十万）のサポート
- Extension of Layer 2 (L2) connectivity among different VMs belonging to a given tenant segment (subnet) across different Points of Delivery (PoDs) within a data center or between different data centers
- データセンター内または異なるデータセンター間の異なる配信ポイント（PoD）にわたる特定のテナントセグメント（サブネット）に属する異なるVM間のレイヤー2（L2）接続の拡張
- Allowing a given VM to move between different physical points of attachment within a given L2 segment
- 特定のVMが特定のL2セグメント内の接続の異なる物理ポイント間を移動できるようにする
The underlay network for NVO solutions is assumed to provide IP connectivity between NVO endpoints.
NVOソリューションのアンダーレイネットワークは、NVOエンドポイント間のIP接続を提供すると想定されています。
This document describes how EVPN can be used as an NVO solution and explores applicability of EVPN functions and procedures. In particular, it describes the various tunnel encapsulation options for EVPN over IP and their impact on the EVPN control plane as well as procedures for two main scenarios:
このドキュメントでは、EVPNをNVOソリューションとして使用する方法を説明し、EVPNの機能と手順の適用性を探ります。特に、EVPN over IPのさまざまなトンネルカプセル化オプションと、EVPNコントロールプレーンへの影響、および2つの主なシナリオの手順について説明します。
(a) single-homing NVEs - when an NVE resides in the hypervisor, and
（a）シングルホーミングNVE-NVEがハイパーバイザーに存在する場合、および
(b) multihoming NVEs - when an NVE resides in a Top-of-Rack (ToR) device.
（b）マルチホーミングNVE-NVEがトップオブラック（ToR）デバイスに存在する場合。
The possible encapsulation options for EVPN overlays that are analyzed in this document are:
このドキュメントで分析されているEVPNオーバーレイの可能なカプセル化オプションは次のとおりです。
- VXLAN and NVGRE
- VXLANおよびNVGRE
- MPLS over GRE
- MPLS over GRE
Before getting into the description of the different encapsulation options for EVPN over IP, it is important to highlight the EVPN solution's main features, how those features are currently supported, and any impact that the encapsulation has on those features.
EVPN over IPのさまざまなカプセル化オプションの説明に入る前に、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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Most of the terminology used in this documents comes from [RFC7432] and [RFC7365].
このドキュメントで使用されている用語のほとんどは、[RFC7432]と[RFC7365]に由来しています。
VXLAN: Virtual Extensible LAN
VXLAN：仮想拡張可能LAN
GRE: Generic Routing Encapsulation
GRE：ジェネリックルーティングカプセル化
NVGRE: Network Virtualization using Generic Routing Encapsulation
NVGRE：Generic Routing Encapsulationを使用したネットワーク仮想化
GENEVE: Generic Network Virtualization Encapsulation
GENEVE：汎用ネットワーク仮想化カプセル化
PoD: Point of Delivery
PoD：配達時点
NV: Network Virtualization NVO: Network Virtualization Overlay
NV：ネットワーク仮想化NVO：ネットワーク仮想化オーバーレイ
NVE: Network Virtualization Edge
NVE：ネットワーク仮想化エッジ
VNI: VXLAN Network Identifier
VNI：VXLANネットワーク識別子
VSID: Virtual Subnet Identifier (for NVGRE)
VSID：仮想サブネット識別子（NVGRE用）
I-SID: Service Instance Identifier
I-SID：サービスインスタンス識別子
EVPN: Ethernet VPN
EVPN：イーサネットVPN
EVI: EVPN Instance. An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN
EVI：EVPNインスタンス。そのEVPNに参加しているプロバイダーエッジ（PE）デバイスにまたがるEVPNインスタンス
MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE
MAC-VRF：PE上のメディアアクセスコントロール（MAC）アドレス用の仮想ルーティングおよび転送テーブル
IP-VRF: A Virtual Routing and Forwarding table for Internet Protocol (IP) addresses on a PE
IP-VRF：PE上のインターネットプロトコル（IP）アドレスの仮想ルーティングおよび転送テーブル
ES: Ethernet Segment. When a customer site (device or network) is connected to one or more PEs via a set of Ethernet links, then that set of links is referred to as an 'Ethernet segment'.
ES：イーサネットセグメント。カスタマーサイト（デバイスまたはネットワーク）がイーサネットリンクのセットを介して1つ以上のPEに接続されている場合、そのリンクのセットは「イーサネットセグメント」と呼ばれます。
Ethernet Segment Identifier (ESI): A unique non-zero identifier that identifies an Ethernet segment is called an 'Ethernet Segment Identifier'.
イーサネットセグメント識別子（ESI）：イーサネットセグメントを識別するゼロ以外の一意の識別子は、「イーサネットセグメント識別子」と呼ばれます。
Ethernet Tag: An Ethernet tag identifies a particular broadcast domain, e.g., a VLAN. An EVPN instance consists of one or more broadcast domains.
イーサネットタグ：イーサネットタグは、VLANなどの特定のブロードキャストドメインを識別します。 EVPNインスタンスは、1つ以上のブロードキャストドメインで構成されます。
PE: Provider Edge
PE：プロバイダーエッジ
Single-Active Redundancy Mode: When only a single PE, among all the PEs attached to an ES, is allowed to forward traffic to/from that ES for a given VLAN, then the Ethernet segment is defined to be operating in Single-Active redundancy mode.
シングルアクティブ冗長モード：ESに接続されているすべてのPEのうち、1つのPEのみが特定のVLANのESとの間でトラフィックを転送できる場合、イーサネットセグメントはシングルアクティブ冗長で動作するように定義されます。モード。
All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward known unicast traffic to/from that ES for a given VLAN, then the ES is defined to be operating in All-Active redundancy mode.
オールアクティブ冗長モード：イーサネットセグメントに接続されているすべてのPEが、特定のVLANのそのESとの間で既知のユニキャストトラフィックを転送できる場合、ESはオールアクティブ冗長モードで動作するように定義されます。
PIM-SM: Protocol Independent Multicast - Sparse-Mode PIM-SSM: Protocol Independent Multicast - Source-Specific Multicast
PIM-SM：プロトコルに依存しないマルチキャスト-スパースモードPIM-SSM：プロトコルに依存しないマルチキャスト-ソース固有のマルチキャスト
BIDIR-PIM: Bidirectional PIM
BIDIR-PIM：双方向PIM
EVPN [RFC7432] was originally designed to support the requirements detailed in [RFC7209] and therefore has the following attributes which directly address control-plane scaling and ease of deployment issues.
EVPN [RFC7432]は元々[RFC7209]で詳述されている要件をサポートするように設計されていたため、コントロールプレーンのスケーリングと展開の容易さの問題に直接対処する次の属性があります。
1. Control-plane information is distributed with BGP and broadcast and multicast traffic is sent using a shared multicast tree or with ingress replication.
1. コントロールプレーン情報はBGPとブロードキャストで配信され、マルチキャストトラフィックは共有マルチキャストツリーを使用して、または入力レプリケーションで送信されます。
2. Control-plane learning is used for MAC (and IP) addresses instead of data-plane learning. The latter requires the flooding of unknown unicast and Address Resolution Protocol (ARP) frames; whereas, the former does not require any flooding.
2. コントロールプレーンラーニングは、データプレーンラーニングの代わりにMAC（およびIP）アドレスに使用されます。後者では、不明なユニキャストおよびアドレス解決プロトコル（ARP）フレームのフラッディングが必要です。一方、前者は洪水を必要としません。
3. Route Reflector (RR) is used to reduce a full mesh of BGP sessions among PE devices to a single BGP session between a PE and the RR. Furthermore, RR hierarchy can be leveraged to scale the number of BGP routes on the RR.
3. ルートリフレクター（RR）は、PEデバイス間のBGPセッションのフルメッシュをPEとRR間の単一のBGPセッションに削減するために使用されます。さらに、RR階層を活用して、RR上のBGPルートの数をスケーリングできます。
4. Auto-discovery via BGP is used to discover PE devices participating in a given VPN, PE devices participating in a given redundancy group, tunnel encapsulation types, multicast tunnel types, multicast members, etc.
4. BGPによる自動検出は、特定のVPNに参加しているPEデバイス、特定の冗長グループに参加しているPEデバイス、トンネルカプセル化タイプ、マルチキャストトンネルタイプ、マルチキャストメンバーなどを検出するために使用されます。
5. All-Active multihoming is used. This allows a given Customer Edge (CE) device to have multiple links to multiple PEs, and traffic to/from that CE fully utilizes all of these links.
5. オールアクティブマルチホーミングが使用されます。これにより、特定のカスタマーエッジ（CE）デバイスは複数のPEへの複数のリンクを持つことができ、そのCEとの間のトラフィックはこれらのリンクをすべて完全に利用します。
6. When a link between a CE and a PE fails, the PEs for that EVI are notified of the failure via the withdrawal of a single EVPN route. This allows those PEs to remove the withdrawing PE as a next hop for every MAC address associated with the failed link. This is termed "mass withdrawal".
6. CEとPE間のリンクに障害が発生すると、そのEVIのPEに、単一のEVPNルートの撤回によって障害が通知されます。これにより、これらのPEは、障害が発生したリンクに関連付けられているすべてのMACアドレスのネクストホップとして、撤回するPEを削除できます。これは「大量回収」と呼ばれます。
7. BGP route filtering and constrained route distribution are leveraged to ensure that the control-plane traffic for a given EVI is only distributed to the PEs in that EVI.
7. BGPルートフィルタリングと制約付きルート配信は、特定のEVIのコントロールプレーントラフィックがそのEVI内のPEにのみ配信されるようにするために活用されます。
8. When an IEEE 802.1Q [IEEE.802.1Q] interface is used between a CE and a PE, each of the VLAN IDs (VIDs) on that interface can be mapped onto a bridge table (for up to 4094 such bridge tables). All these bridge tables may be mapped onto a single MAC-VRF (in case of VLAN-aware bundle service).
8. IEEE 802.1Q [IEEE.802.1Q]インターフェイスがCEとPEの間で使用されている場合、そのインターフェイスの各VLAN ID（VID）をブリッジテーブルにマッピングできます（そのようなブリッジテーブルは最大4094まで）。これらすべてのブリッジテーブルは、単一のMAC-VRFにマッピングできます（VLAN対応バンドルサービスの場合）。
9. VM Mobility mechanisms ensure that all PEs in a given EVI know the ES with which a given VM, as identified by its MAC and IP addresses, is currently associated.
9. VMモビリティメカニズムは、特定のEVIのすべてのPEが、MACおよびIPアドレスで識別される特定のVMが現在関連付けられているESを確実に認識するようにします。
10. RTs are used to allow the operator (or customer) to define a spectrum of logical network topologies including mesh, hub and spoke, and extranets (e.g., a VPN whose sites are owned by different enterprises), without the need for proprietary software or the aid of other virtual or physical devices.
10. RTは、オペレーター（または顧客）が、メッシュ、ハブアンドスポーク、エクストラネット（たとえば、サイトが異なる企業によって所有されているVPN）などの論理ネットワークトポロジのスペクトルを定義できるようにするために使用されます。他の仮想または物理デバイスの支援。
Because the design goal for NVO is millions of instances per common physical infrastructure, the scaling properties of the control plane for NVO are extremely important. EVPN and the extensions described herein, are designed with this level of scalability in mind.
NVOの設計目標は一般的な物理インフラストラクチャあたり数百万のインスタンスであるため、NVOのコントロールプレーンのスケーリングプロパティは非常に重要です。 EVPNとここで説明する拡張機能は、このレベルのスケーラビリティを念頭に置いて設計されています。
Both VXLAN and NVGRE are examples of technologies that provide a data plane encapsulation which is used to transport a packet over the common physical IP infrastructure between Network Virtualization Edges (NVEs) - e.g., VXLAN Tunnel End Points (VTEPs) in VXLAN network. Both of these technologies include the identifier of the specific NVO instance, VNI in VXLAN and VSID in NVGRE, in each packet. In the remainder of this document we use VNI as the representation for NVO instance with the understanding that VSID can equally be used if the encapsulation is NVGRE unless it is stated otherwise.
VXLANとNVGREはどちらも、ネットワーク仮想化エッジ（NVE）（VXLANネットワークのVXLANトンネルエンドポイント（VTEP）など）間の共通の物理IPインフラストラクチャを介してパケットを転送するために使用されるデータプレーンカプセル化を提供するテクノロジーの例です。これらの両方のテクノロジーには、特定のNVOインスタンスの識別子、VXLANのVNI、NVGREのVSIDが各パケットに含まれています。このドキュメントの残りの部分では、特に明記されていない限り、カプセル化がNVGREであればVSIDも同様に使用できることを理解しながら、NVOインスタンスの表現としてVNIを使用します。
Note that a PE is equivalent to an NVE/VTEP.
PEはNVE / VTEPと同等であることに注意してください。
VXLAN encapsulation is based on UDP, with an 8-byte header following the UDP header. VXLAN provides a 24-bit VNI, which typically provides a one-to-one mapping to the tenant VID, as described in [RFC7348]. In this scenario, the ingress VTEP does not include an inner VLAN tag on the encapsulated frame, and the egress VTEP discards the frames with an inner VLAN tag. This mode of operation in [RFC7348] maps to VLAN-Based Service in [RFC7432], where a tenant VID gets mapped to an EVI.
VXLANカプセル化はUDPに基づいており、UDPヘッダーの後に8バイトのヘッダーがあります。 [RFC7348]で説明されているように、VXLANは24ビットVNIを提供します。これは通常、テナントVIDへの1対1のマッピングを提供します。このシナリオでは、入力VTEPはカプセル化されたフレームに内部VLANタグを含まず、出力VTEPは内部VLANタグを持つフレームを破棄します。 [RFC7348]のこの動作モードは、[RFC7432]のVLANベースのサービスにマッピングされ、テナントVIDがEVIにマッピングされます。
VXLAN also provides an option of including an inner VLAN tag in the encapsulated frame, if explicitly configured at the VTEP. This mode of operation can map to VLAN Bundle Service in [RFC7432] because all the tenant's tagged frames map to a single bridge table / MAC-VRF, and the inner VLAN tag is not used for lookup by the disposition PE when performing VXLAN decapsulation as described in Section 6 of [RFC7348].
VXLANは、VTEPで明示的に構成されている場合、カプセル化されたフレームに内部VLANタグを含めるオプションも提供します。この操作モードは、[RFC7432]のVLANバンドルサービスにマッピングできます。これは、すべてのテナントのタグ付きフレームが単一のブリッジテーブル/ MAC-VRFにマッピングされ、VXLANカプセル化解除を実行するときに、内部VLANタグがディスポジションPEによるルックアップに使用されないためです。 [RFC7348]のセクション6で説明されています。
[RFC7637] encapsulation is based on GRE encapsulation, and it mandates the inclusion of the optional GRE Key field, which carries the VSID. There is a one-to-one mapping between the VSID and the tenant VID, as described in [RFC7637]. The inclusion of an inner VLAN tag is prohibited. This mode of operation in [RFC7637] maps to VLAN Based Service in [RFC7432].
[RFC7637]カプセル化はGREカプセル化に基づいており、VSIDを運ぶオプションのGREキーフィールドを含めることを義務付けています。 [RFC7637]で説明されているように、VSIDとテナントVIDの間には1対1のマッピングがあります。内部VLANタグを含めることは禁止されています。 [RFC7637]のこの動作モードは、[RFC7432]のVLANベースのサービスにマッピングされます。
As described in the next section, there is no change to the encoding of EVPN routes to support VXLAN or NVGRE encapsulation, except for the use of the BGP Encapsulation Extended Community to indicate the encapsulation type (e.g., VXLAN or NVGRE). However, there is potential impact to the EVPN procedures depending on where the NVE is located (i.e., in hypervisor or ToR) and whether multihoming capabilities are required.
次のセクションで説明するように、BGPカプセル化拡張コミュニティを使用してカプセル化の種類（VXLANやNVGREなど）を示すことを除いて、VXLANまたはNVGREカプセル化をサポートするためのEVPNルートのエンコーディングに変更はありません。ただし、NVEが配置されている場所（ハイパーバイザーやToRなど）やマルチホーミング機能が必要かどうかによっては、EVPN手順に影響を与える可能性があります。
Although VNIs are defined as 24-bit globally unique values, there are scenarios in which it is desirable to use a locally significant value for the VNI, especially in the context of a data-center interconnect.
VNIは24ビットのグローバルに一意の値として定義されていますが、特にデータセンター相互接続のコンテキストでは、VNIにローカルで重要な値を使用することが望ましいシナリオがあります。
In the case where NVEs in different data centers need to be interconnected, and the NVEs need to use VNIs as globally unique identifiers within a data center, then a Gateway (GW) needs to be employed at the edge of the data-center network (DCN). This is because the Gateway will provide the functionality of translating the VNI when crossing network boundaries, which may align with operator span-of-control boundaries. As an example, consider the network of Figure 1. Assume there are three network operators: one for each of the DC1, DC2, and WAN networks. The Gateways at the edge of the data centers are responsible for translating the VNIs between the values used in each of the DCNs and the values used in the WAN.
異なるデータセンターのNVEを相互接続する必要があり、NVEがデータセンター内でグローバルに一意の識別子としてVNIを使用する必要がある場合、ゲートウェイ（GW）をデータセンターネットワークのエッジで使用する必要があります（ DCN）。これは、ゲートウェイがネットワークの境界を越えるときにVNIを変換する機能を提供するためです。これは、オペレーターの制御範囲の境界に合わせることができます。例として、図1のネットワークを考えます。DC1、DC2、およびWANネットワークのそれぞれに1つずつ、3つのネットワークオペレーターがいるとします。データセンターの端にあるゲートウェイは、各DCNで使用される値とWANで使用される値の間でVNIを変換する責任があります。
+--------------+
| |
+---------+ | WAN | +---------+
+----+ | +---+ +----+ +----+ +---+ | +----+
|NVE1|--| | | |WAN | |WAN | | | |--|NVE3|
+----+ |IP |GW |--|Edge| |Edge|--|GW | IP | +----+
+----+ |Fabric +---+ +----+ +----+ +---+ Fabric | +----+
|NVE2|--| | | | | |--|NVE4|
+----+ +---------+ +--------------+ +---------+ +----+
|<------ DC 1 ------> <------ DC2 ------>|
Figure 1: Data-Center Interconnect with Gateway
図1：ゲートウェイを使用したデータセンター相互接続
In the case where NVEs in different data centers need to be interconnected, and the NVEs need to use locally assigned VNIs (e.g., similar to MPLS labels), there may be no need to employ Gateways at the edge of the DCN. More specifically, the VNI value that is used by the transmitting NVE is allocated by the NVE that is receiving the traffic (in other words, this is similar to a "downstream-assigned" MPLS label). This allows the VNI space to be decoupled between different DCNs without the need for a dedicated Gateway at the edge of the data centers. This topic is covered in Section 10.2.
異なるデータセンターのNVEを相互接続する必要があり、NVEがローカルに割り当てられたVNI（たとえば、MPLSラベルと同様）を使用する必要がある場合は、DCNのエッジでゲートウェイを使用する必要がない場合があります。より具体的には、送信NVEによって使用されるVNI値は、トラフィックを受信しているNVEによって割り当てられます（つまり、これは「ダウンストリーム割り当て」MPLSラベルに類似しています）。これにより、データセンターのエッジに専用のゲートウェイを必要とせずに、VNIスペースを異なるDCN間で分離できます。このトピックについては、セクション10.2で説明します。
+--------------+
| |
+---------+ | WAN | +---------+
+----+ | | +----+ +----+ | | +----+
|NVE1|--| | |ASBR| |ASBR| | |--|NVE3|
+----+ |IP Fabric|---| | | |--|IP Fabric| +----+
+----+ | | +----+ +----+ | | +----+
|NVE2|--| | | | | |--|NVE4|
+----+ +---------+ +--------------+ +---------+ +----+
|<------ DC 1 -----> <---- DC2 ------>|
Figure 2: Data-Center Interconnect with ASBR
図2：ASBRを使用したデータセンター相互接続
Just like in [RFC7432], where two options existed for mapping broadcast domains (represented by VLAN IDs) to an EVI, when the EVPN control plane is used in conjunction with VXLAN (or NVGRE encapsulation), there are also two options for mapping broadcast domains represented by VXLAN VNIs (or NVGRE VSIDs) to an EVI:
[RFC7432]と同様に、ブロードキャストドメイン（VLAN IDで表される）をEVIにマッピングするための2つのオプションが存在し、EVPNコントロールプレーンがVXLAN（またはNVGREカプセル化）と組み合わせて使用される場合、ブロードキャストをマッピングするための2つのオプションもあります。 VXLAN VNI（またはNVGRE VSID）で表されるドメインをEVIに：
Option 1: A Single Broadcast Domain per EVI
オプション1：EVIごとに単一のブロードキャストドメイン
In this option, a single Ethernet broadcast domain (e.g., subnet) represented by a VNI is mapped to a unique EVI. This corresponds to the VLAN-Based Service in [RFC7432], where a tenant-facing interface, logical interface (e.g., represented by a VID), or physical interface gets mapped to an EVI. As such, a BGP Route Distinguisher (RD) and Route Target (RT) are needed per VNI on every NVE. The advantage of this model is that it allows the BGP RT constraint mechanisms to be used in order to limit the propagation and import of routes to only the NVEs that are interested in a given VNI. The disadvantage of this model may be the provisioning overhead if the RD and RT are not derived automatically from the VNI.
このオプションでは、VNIによって表される単一のイーサネットブロードキャストドメイン（サブネットなど）が一意のEVIにマッピングされます。これは、[RFC7432]のVLANベースのサービスに対応します。テナントに面するインターフェース、論理インターフェース（VIDで表されるなど）、または物理インターフェースがEVIにマッピングされます。そのため、すべてのNVEのVNIごとにBGPルート識別子（RD）とルートターゲット（RT）が必要です。このモデルの利点は、ルートの伝播とインポートを特定のVNIに関係するNVEのみに制限するためにBGP RT制約メカニズムを使用できることです。このモデルの欠点は、RDとRTがVNIから自動的に派生しない場合、プロビジョニングのオーバーヘッドになる可能性があります。
In this option, the MAC-VRF table is identified by the RT in the control plane and by the VNI in the data plane. In this option, the specific MAC-VRF table corresponds to only a single bridge table.
このオプションでは、MAC-VRFテーブルは、コントロールプレーンのRTとデータプレーンのVNIによって識別されます。このオプションでは、特定のMAC-VRFテーブルは単一のブリッジテーブルにのみ対応します。
Option 2: Multiple Broadcast Domains per EVI
オプション2：EVIごとに複数のブロードキャストドメイン
In this option, multiple subnets, each represented by a unique VNI, are mapped to a single EVI. For example, if a tenant has multiple segments/subnets each represented by a VNI, then all the VNIs for that tenant are mapped to a single EVI; for example, the EVI in this case represents the tenant and not a subnet. This corresponds to the VLAN-aware bundle service in [RFC7432]. The advantage of this model is that it doesn't require the provisioning of an RD/RT per VNI. However, this is a moot point when compared to Option 1 where auto-derivation is used. The disadvantage of this model is that routes would be imported by NVEs that may not be interested in a given VNI.
このオプションでは、それぞれが一意のVNIで表される複数のサブネットが単一のEVIにマッピングされます。たとえば、テナントに複数のセグメント/サブネットがあり、それぞれがVNIで表されている場合、そのテナントのすべてのVNIは単一のEVIにマッピングされます。たとえば、この場合のEVIはサブネットではなくテナントを表します。これは、[RFC7432]のVLAN対応バンドルサービスに対応しています。このモデルの利点は、VNIごとにRD / RTをプロビジョニングする必要がないことです。ただし、自動派生を使用するオプション1と比較すると、これは問題点です。このモデルの欠点は、特定のVNIに関係のないNVEによってルートがインポートされることです。
In this option, the MAC-VRF table is identified by the RT in the control plane; a specific bridge table for that MAC-VRF is identified by the <RT, Ethernet Tag ID> in the control plane. In this option, the VNI in the data plane is sufficient to identify a specific bridge table.
このオプションでは、MAC-VRFテーブルはコントロールプレーンのRTによって識別されます。そのMAC-VRFの特定のブリッジテーブルは、コントロールプレーンで<RT、イーサネットタグID>によって識別されます。このオプションでは、データプレーンのVNIで特定のブリッジテーブルを識別できます。
In order to simplify configuration, when the option of a single VNI per EVI is used, the RT used for EVPN can be auto-derived. RD can be auto-generated as described in [RFC7432], and RT can be auto-derived as described next.
構成を簡素化するために、EVIごとに単一のVNIのオプションを使用する場合、EVPNに使用されるRTを自動派生させることができます。 [RFC7432]で説明されているようにRDを自動生成でき、次に説明されているようにRTを自動生成できます。
Since a Gateway PE as depicted in Figure 1 participates in both the DCN and WAN BGP sessions, it is important that, when RT values are auto-derived from VNIs, there be no conflict in RT spaces between DCNs and WANs, assuming that both are operating within the same Autonomous System (AS). Also, there can be scenarios where both VXLAN and NVGRE encapsulations may be needed within the same DCN, and their corresponding VNIs are administered independently, which means VNI spaces can overlap. In order to avoid conflict in RT spaces, the 6-byte RT values with 2-octet AS number for DCNs can be auto-derived as follow:
図1に示されているゲートウェイPEはDCNとWAN BGPセッションの両方に参加するため、RT値がVNIから自動派生される場合、DCNとWANの間のRTスペースに矛盾がないことが重要です。同じ自律システム（AS）内で動作します。また、同じDCN内でVXLANとNVGREの両方のカプセル化が必要になるシナリオがあり、対応するVNIが独立して管理されるため、VNIスペースが重複する可能性があります。 RTスペースでの競合を回避するために、DCNの2オクテットAS番号を持つ6バイトのRT値は、次のように自動派生できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator | Local Administrator |
+-----------------------------------------------+---------------+
| Local Administrator (Cont.) |
+-------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator |A| TYPE| D-ID | Service ID |
+-----------------------------------------------+---------------+
| Service ID (Cont.) |
+-------------------------------+
The 6-octet RT field consists of two sub-fields:
6オクテットのRTフィールドは2つのサブフィールドで構成されます。
- Global Administrator sub-field: 2 octets. This sub-field contains an AS number assigned by IANA <https://www.iana.org/assignments/ as-numbers/>.
- グローバル管理者サブフィールド：2オクテット。このサブフィールドには、IANA <https://www.iana.org/assignments/ as-numbers />によって割り当てられたAS番号が含まれています。
- Local Administrator sub-field: 4 octets
- ローカル管理者サブフィールド：4オクテット
* A: A single-bit field indicating if this RT is auto-derived
* A：このRTが自動派生であるかどうかを示す単一ビットフィールド
0: auto-derived 1: manually derived
0：自動派生1：手動で派生
* Type: A 3-bit field that identifies the space in which the other 3 bytes are defined. The following spaces are defined:
* タイプ：他の3バイトが定義されているスペースを識別する3ビットのフィールド。次のスペースが定義されています。
0 : VID (802.1Q VLAN ID) 1 : VXLAN 2 : NVGRE 3 : I-SID 4 : EVI 5 : dual-VID (QinQ VLAN ID)
0：VID（802.1Q VLAN ID）1：VXLAN 2：NVGRE 3：I-SID 4：EVI 5：デュアルVID（QinQ VLAN ID）
* D-ID: A 4-bit field that identifies domain-id. The default value of domain-id is zero, indicating that only a single numbering space exist for a given technology. However, if more than one number space exists for a given technology (e.g., overlapping VXLAN spaces), then each of the number spaces need to be identified by its corresponding domain-id starting from 1.
* D-ID：ドメインIDを識別する4ビットのフィールド。 domain-idのデフォルト値はゼロであり、特定のテクノロジーに対して単一の番号付けスペースのみが存在することを示します。ただし、特定のテクノロジーに複数の番号スペースが存在する場合（VXLANスペースのオーバーラップなど）、各番号スペースは、1から始まる対応するドメインIDで識別する必要があります。
* Service ID: This 3-octet field is set to VNI, VSID, I-SID, or VID.
* サービスID：この3オクテットのフィールドは、VNI、VSID、I-SID、またはVIDに設定されます。
It should be noted that RT auto-derivation is applicable for 2-octet AS numbers. For 4-octet AS numbers, the RT needs to be manually configured because 3-octet VNI fields cannot be fit within the 2-octet local administrator field.
RT自動派生は2オクテットAS番号に適用できることに注意してください。 4オクテットのAS番号の場合、3オクテットのVNIフィールドを2オクテットのローカル管理者フィールド内に収めることができないため、RTを手動で構成する必要があります。
In EVPN, an MPLS label, for instance, identifying the forwarding table is distributed by the egress PE via the EVPN control plane and is placed in the MPLS header of a given packet by the ingress PE. This label is used upon receipt of that packet by the egress PE for disposition of that packet. This is very similar to the use of the VNI by the egress NVE, with the difference being that an MPLS label has local significance while a VNI typically has global significance. Accordingly, and specifically to support the option of locally assigned VNIs, the MPLS Label1 field in the MAC/IP Advertisement route, the MPLS label field in the Ethernet A-D per EVI route, and the MPLS label field in the P-Multicast Service Interface (PMSI) Tunnel attribute of the Inclusive Multicast Ethernet Tag (IMET) route are used to carry the VNI. For the balance of this memo, the above MPLS label fields will be referred to as the VNI field. The VNI field is used for both local and global VNIs; for either case, the entire 24-bit field is used to encode the VNI value.
EVPNでは、たとえば、転送テーブルを識別するMPLSラベルがEVPNコントロールプレーンを介して出力PEによって配布され、入力PEによって特定のパケットのMPLSヘッダーに配置されます。このラベルは、出力PEがそのパケットを受信したときに、そのパケットの後処理に使用されます。これは、出力NVEによるVNIの使用と非常に似ていますが、MPLSラベルはローカルで重要であるのに対し、VNIは通常グローバルで重要です。したがって、特にローカルに割り当てられたVNIのオプションをサポートするために、MAC / IPアドバタイズメントルートのMPLS Label1フィールド、EVIルートごとのイーサネットADのMPLSラベルフィールド、およびPマルチキャストサービスインターフェイスのMPLSラベルフィールド（ PMSI）インクルーシブマルチキャストイーサネットタグ（IMET）ルートのトンネル属性は、VNIの伝送に使用されます。このメモの残りの部分では、上記のMPLSラベルフィールドはVNIフィールドと呼ばれます。 VNIフィールドは、ローカルVNIとグローバルVNIの両方に使用されます。どちらの場合も、24ビットフィールド全体がVNI値のエンコードに使用されます。
For the VLAN-Based Service (a single VNI per MAC-VRF), the Ethernet Tag field in the MAC/IP Advertisement, Ethernet A-D per EVI, and IMET route MUST be set to zero just as in the VLAN-Based Service in [RFC7432].
VLANベースのサービス（MAC-VRFごとに1つのVNI）の場合、MAC / IPアドバタイズメントのイーサネットタグフィールド、EVIごとのイーサネットAD、およびIMETルートは、[のVLANベースのサービスと同様にゼロに設定する必要があります。 RFC7432]。
For the VLAN-Aware Bundle Service (multiple VNIs per MAC-VRF with each VNI associated with its own bridge table), the Ethernet Tag field in the MAC Advertisement, Ethernet A-D per EVI, and IMET route MUST identify a bridge table within a MAC-VRF; the set of Ethernet Tags for that EVI needs to be configured consistently on all PEs within that EVI. For locally assigned VNIs, the value advertised in the Ethernet Tag field MUST be set to a VID just as in the VLAN-aware bundle service in [RFC7432]. Such setting must be done consistently on all PE devices participating in that EVI within a given domain. For global VNIs, the value advertised in the Ethernet Tag field SHOULD be set to a VNI as long as it matches the existing semantics of the Ethernet Tag, i.e., it identifies a bridge table within a MAC-VRF and the set of VNIs are configured consistently on each PE in that EVI.
VLAN対応バンドルサービス（MAC-VRFごとに複数のVNIがあり、各VNIが独自のブリッジテーブルに関連付けられている）の場合、MACアドバタイズメントのイーサネットタグフィールド、EVIごとのイーサネットAD、およびIMETルートは、MAC内のブリッジテーブルを識別する必要があります。 -VRF;そのEVIのイーサネットタグのセットは、そのEVI内のすべてのPEで一貫して構成する必要があります。ローカルに割り当てられたVNIの場合、[RFC7432]のVLAN対応バンドルサービスと同じように、イーサネットタグフィールドでアドバタイズされる値をVIDに設定する必要があります。このような設定は、特定のドメイン内のそのEVIに参加するすべてのPEデバイスで一貫して行う必要があります。グローバルVNIの場合、イーサネットタグフィールドでアドバタイズされる値は、イーサネットタグの既存のセマンティクスと一致する限り、つまりMAC-VRF内のブリッジテーブルを識別し、VNIのセットが構成されている限り、VNIに設定する必要があります（SHOULD）。そのEVIの各PEで一貫して。
In order to indicate which type of data-plane encapsulation (i.e., VXLAN, NVGRE, MPLS, or MPLS in GRE) is to be used, the BGP Encapsulation Extended Community defined in [RFC5512] is included with all EVPN routes (i.e., MAC Advertisement, Ethernet A-D per EVI, Ethernet A-D per ESI, IMET, and Ethernet Segment) advertised by an egress PE. Five new values have been assigned by IANA to extend the list of encapsulation types defined in [RFC5512]; they are listed in Section 11.
どのタイプのデータプレーンカプセル化（つまり、VXLAN、NVGRE、MPLS、またはGREのMPLS）を使用するかを示すために、[RFC5512]で定義されているBGPカプセル化拡張コミュニティは、すべてのEVPNルート（つまり、MACアドバタイズ、EVIごとのイーサネットAD、ESIごとのイーサネットAD、IMET、およびイーサネットセグメント）。出力PEによってアドバタイズされます。 [RFC5512]で定義されているカプセル化タイプのリストを拡張するために、IANAによって5つの新しい値が割り当てられました。それらはセクション11にリストされています。
The MPLS encapsulation tunnel type, listed in Section 11, is needed in order to distinguish between an advertising node that only supports non-MPLS encapsulations and one that supports MPLS and non-MPLS encapsulations. An advertising node that only supports MPLS encapsulation does not need to advertise any encapsulation tunnel types; i.e., if the BGP Encapsulation Extended Community is not present, then either MPLS encapsulation or a statically configured encapsulation is assumed.
セクション11に記載されているMPLSカプセル化トンネルタイプは、非MPLSカプセル化のみをサポートするアドバタイジングノードと、MPLSおよび非MPLSカプセル化をサポートするアドバタイズノードを区別するために必要です。 MPLSカプセル化のみをサポートするアドバタイズノードは、カプセル化トンネルタイプをアドバタイズする必要はありません。つまり、BGPカプセル化拡張コミュニティが存在しない場合、MPLSカプセル化または静的に構成されたカプセル化が想定されます。
The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the IPv4 or IPv6 address of the NVE. The remaining fields in each route are set as per [RFC7432].
ルートのMP_REACH_NLRI属性のNext Hopフィールドは、NVEのIPv4またはIPv6アドレスに設定する必要があります。各ルートの残りのフィールドは、[RFC7432]に従って設定されます。
Note that the procedure defined here -- to use the MPLS Label field to carry the VNI in the presence of a Tunnel Encapsulation Extended Community specifying the use of a VNI -- is aligned with the procedures described in Section 8.2.2.2 of [TUNNEL-ENCAP] ("When a Valid VNI has not been Signaled").
ここで定義されている手順（MPLSラベルフィールドを使用して、VNIの使用を指定するトンネルカプセル化拡張コミュニティの存在下でVNIを伝送する手順）は、[TUNNEL- ENCAP]（「有効なVNIが通知されていない場合」）。
The EVPN data plane is modeled as an EVPN MPLS client layer sitting over an MPLS PSN tunnel server layer. Some of the EVPN functions (split-horizon, Aliasing, and Backup Path) are tied to the MPLS client layer. If MPLS over GRE encapsulation is used, then the EVPN MPLS client layer can be carried over an IP PSN tunnel transparently. Therefore, there is no impact to the EVPN procedures and associated data-plane operation.
EVPNデータプレーンは、MPLS PSNトンネルサーバーレイヤーの上にあるEVPN MPLSクライアントレイヤーとしてモデル化されます。 EVPN機能の一部（スプリットホライズン、エイリアス、およびバックアップパス）は、MPLSクライアントレイヤーに関連付けられています。 MPLS over GREカプセル化が使用されている場合、EVPN MPLSクライアントレイヤーは、IP PSNトンネルを介して透過的に伝送できます。したがって、EVPNの手順と関連するデータプレーンの動作に影響はありません。
[RFC4023] defines the standard for using MPLS over GRE encapsulation, which can be used for this purpose. However, when MPLS over GRE is used in conjunction with EVPN, it is recommended that the GRE key field be present and be used to provide a 32-bit entropy value only if the P nodes can perform Equal-Cost Multipath (ECMP) hashing based on the GRE key; otherwise, the GRE header SHOULD NOT include the GRE key field. The Checksum and Sequence Number fields MUST NOT be included, and the corresponding C and S bits in the GRE header MUST be set to zero. A PE capable of supporting this encapsulation SHOULD advertise its EVPN routes along with the Tunnel Encapsulation Extended Community indicating MPLS over GRE encapsulation as described in the previous section.
[RFC4023]は、この目的で使用できるMPLS over GREカプセル化を使用するための標準を定義しています。ただし、MPLS over GREをEVPNと組み合わせて使用する場合、Pノードが等価コストマルチパス（ECMP）ハッシュベースを実行できる場合にのみ、GREキーフィールドを存在させ、32ビットエントロピー値を提供するために使用することをお勧めしますGREキーそれ以外の場合、GREヘッダーにはGREキーフィールドを含めないでください。チェックサムおよびシーケンス番号フィールドを含めてはならず（MUST NOT）、GREヘッダーの対応するCおよびSビットをゼロに設定する必要があります。このカプセル化をサポートできるPEは、前のセクションで説明したように、MPLS over GREカプセル化を示すトンネルカプセル化拡張コミュニティとともにEVPNルートをアドバタイズする必要があります（SHOULD）。
The use of the BGP Encapsulation Extended Community per [RFC5512] allows each NVE in a given EVI to know each of the encapsulations supported by each of the other NVEs in that EVI. That is, each of the NVEs in a given EVI may support multiple data-plane encapsulations. An ingress NVE can send a frame to an egress NVE only if the set of encapsulations advertised by the egress NVE forms a non-empty intersection with the set of encapsulations supported by the ingress NVE; it is at the discretion of the ingress NVE which encapsulation to choose from this intersection. (As noted in Section 5.1.3, if the BGP Encapsulation extended community is not present, then the default MPLS encapsulation or a locally configured encapsulation is assumed.)
[RFC5512]によるBGPカプセル化拡張コミュニティを使用すると、特定のEVI内の各NVEが、そのEVI内の他の各NVEによってサポートされている各カプセル化を知ることができます。つまり、特定のEVIの各NVEは、複数のデータプレーンカプセル化をサポートできます。入力NVEがアドバタイズするカプセル化のセットが、入力NVEがサポートするカプセル化のセットと空でない交差を形成する場合にのみ、入力NVEが出力NVEにフレームを送信できます。この交差点から選択するカプセル化は、入力NVEの裁量に委ねられています。 （セクション5.1.3で説明したように、BGPカプセル化拡張コミュニティが存在しない場合、デフォルトのMPLSカプセル化またはローカルに構成されたカプセル化が想定されます。）
When a PE advertises multiple supported encapsulations, it MUST advertise encapsulations that use the same EVPN procedures including procedures associated with split-horizon filtering described in Section 8.3.1. For example, VXLAN and NVGRE (or MPLS and MPLS over GRE) encapsulations use the same EVPN procedures; thus, a PE can advertise both of them and can support either of them or both of them simultaneously. However, a PE MUST NOT advertise VXLAN and MPLS encapsulations together because (a) the MPLS field of EVPN routes is set to either an MPLS label or a VNI, but not both and (b) some EVPN procedures (such as split-horizon filtering) are different for VXLAN/ NVGRE and MPLS encapsulations.
PEがサポートされている複数のカプセル化をアドバタイズする場合、セクション8.3.1で説明されているスプリットホライズンフィルタリングに関連する手順を含む同じEVPN手順を使用するカプセル化をアドバタイズする必要があります。たとえば、VXLANおよびNVGRE（またはMPLSおよびMPLS over GRE）カプセル化では、同じEVPN手順を使用します。したがって、PEはそれらの両方をアドバタイズし、それらのいずれかまたは両方を同時にサポートできます。ただし、PEはVXLANとMPLSのカプセル化を一緒にアドバタイズしてはなりません（a）EVPNルートのMPLSフィールドはMPLSラベルまたはVNIのいずれかに設定されていますが、両方には設定されていません。（b）一部のEVPN手順（スプリットホライズンフィルタリングなど） ）VXLAN / NVGREおよびMPLSカプセル化では異なります。
An ingress node that uses shared multicast trees for sending broadcast or multicast frames MAY maintain distinct trees for each different encapsulation type.
ブロードキャストまたはマルチキャストフレームを送信するために共有マルチキャストツリーを使用する入口ノードは、異なるカプセル化タイプごとに異なるツリーを維持する場合があります。
It is the responsibility of the operator of a given EVI to ensure that all of the NVEs in that EVI support at least one common encapsulation. If this condition is violated, it could result in service disruption or failure. The use of the BGP Encapsulation Extended Community provides a method to detect when this condition is violated, but the actions to be taken are at the discretion of the operator and are outside the scope of this document.
特定のEVIのオペレーターは、そのEVIのすべてのNVEが少なくとも1つの共通のカプセル化をサポートするようにする必要があります。この条件に違反すると、サービスの中断または障害が発生する可能性があります。 BGPカプセル化拡張コミュニティを使用すると、この条件に違反したことを検出する方法が提供されますが、実行するアクションはオペレーターの裁量によるものであり、このドキュメントの範囲外です。
When an NVE and its hosts/VMs are co-located in the same physical device, e.g., when they reside in a server, the links between them are virtual and they typically share fate. That is, the subject hosts/VMs are typically not multihomed or, if they are multihomed, the multihoming is a purely local matter to the server hosting the VM and the NVEs, and it need not be "visible" to any other NVEs residing on other servers. Thus, it does not require any specific protocol mechanisms. The most common case of this is when the NVE resides on the hypervisor.
NVEとそのホスト/ VMが同じ物理デバイスに共存している場合、たとえば、それらがサーバーに存在する場合、それらの間のリンクは仮想であり、通常は運命を共有します。つまり、サブジェクトホスト/ VMは通常マルチホーム化されていないか、マルチホーム化されている場合、マルチホーミングはVMとNVEをホストしているサーバーにとって純粋にローカルな問題であり、常駐している他のNVEから「見える」必要はありません。他のサーバー。したがって、特定のプロトコルメカニズムは必要ありません。これの最も一般的なケースは、NVEがハイパーバイザーに存在する場合です。
In the subsections that follow, we will discuss the impact on EVPN procedures for the case when the NVE resides on the hypervisor and the VXLAN (or NVGRE) encapsulation is used.
以下のサブセクションでは、NVEがハイパーバイザー上にあり、VXLAN（またはNVGRE）カプセル化が使用されている場合のEVPN手順への影響について説明します。
7.1. Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulations
7.1. VXLAN / NVGREカプセル化のEVPN BGPルートと属性への影響
In scenarios where different groups of data centers are under different administrative domains, and these data centers are connected via one or more backbone core providers as described in [RFC7365], the RD must be a unique value per EVI or per NVE as described in [RFC7432]. In other words, whenever there is more than one administrative domain for global VNI, a unique RD must be used; or, whenever the VNI value has local significance, a unique RD must be used. Therefore, it is recommended to use a unique RD as described in [RFC7432] at all times.
[RFC7365]で説明されているように、データセンターの異なるグループが異なる管理ドメインにあり、これらのデータセンターが1つ以上のバックボーンコアプロバイダーを介して接続されているシナリオでは、RDはEVIまたはNVEごとに一意の値である必要があります。 RFC7432]。つまり、グローバルVNIに複数の管理ドメインがある場合は常に、一意のRDを使用する必要があります。または、VNI値がローカルで重要な場合は常に、一意のRDを使用する必要があります。したがって、[RFC7432]で説明されているように、常に固有のRDを使用することをお勧めします。
When the NVEs reside on the hypervisor, the EVPN BGP routes and attributes associated with multihoming are no longer required. This reduces the required routes and attributes to the following subset of four out of the total of eight listed in Section 7 of [RFC7432]:
NVEがハイパーバイザー上にある場合、マルチホーミングに関連付けられたEVPN BGPルートと属性は不要になります。これにより、必要なルートと属性が、[RFC7432]のセクション7に記載されている合計8つのうち、次の4つのサブセットに削減されます。
- MAC/IP Advertisement Route
- MAC / IPアドバタイズメントルート
- Inclusive Multicast Ethernet Tag Route
- 包括的なマルチキャストイーサネットタグルート
- MAC Mobility Extended Community
- MACモビリティ拡張コミュニティ
- Default Gateway Extended Community
- デフォルトゲートウェイ拡張コミュニティ
However, as noted in Section 8.6 of [RFC7432], in order to enable a single-homing ingress NVE to take advantage of fast convergence, Aliasing, and Backup Path when interacting with multihomed egress NVEs attached to a given ES, the single-homing ingress NVE should be able to receive and process routes that are Ethernet A-D per ES and Ethernet A-D per EVI.
ただし、[RFC7432]のセクション8.6に記載されているように、シングルホーミング入力NVEが、特定のESに接続されたマルチホーム出力NVEとやり取りするときに高速コンバージェンス、エイリアス、およびバックアップパスを利用できるようにするために、シングルホーミング入力NVEは、ESごとのイーサネットADおよびEVIごとのイーサネットADであるルートを受信して処理できる必要があります。
When the NVEs reside on the hypervisors, the EVPN procedures associated with multihoming are no longer required. This limits the procedures on the NVE to the following subset.
NVEがハイパーバイザー上にある場合、マルチホーミングに関連するEVPN手順は必要なくなりました。これにより、NVEの手順が次のサブセットに制限されます。
1. Local learning of MAC addresses received from the VMs per Section 10.1 of [RFC7432].
1. [RFC7432]のセクション10.1に従ってVMから受信したMACアドレスのローカル学習。
2. Advertising locally learned MAC addresses in BGP using the MAC/IP Advertisement routes.
2. MAC / IPアドバタイズメントルートを使用して、BGPでローカルに学習したMACアドレスをアドバタイズします。
3. Performing remote learning using BGP per Section 9.2 of [RFC7432].
3. [RFC7432]のセクション9.2に従ってBGPを使用してリモートラーニングを実行する。
4. Discovering other NVEs and constructing the multicast tunnels using the IMET routes.
4. 他のNVEを検出し、IMETルートを使用してマルチキャストトンネルを構築します。
5. Handling MAC address mobility events per the procedures of Section 15 in [RFC7432].
5. [RFC7432]のセクション15の手順に従ってMACアドレスモビリティイベントを処理します。
However, as noted in Section 8.6 of [RFC7432], in order to enable a single-homing ingress NVE to take advantage of fast convergence, Aliasing, and Backup Path when interacting with multihomed egress NVEs attached to a given ES, a single-homing ingress NVE should implement the ingress node processing of routes that are Ethernet A-D per ES and Ethernet A-D per EVI as defined in Sections 8.2 ("Fast Convergence") and 8.4 ("Aliasing and Backup Path") of [RFC7432].
ただし、[RFC7432]のセクション8.6に記載されているように、単一ホーミングの入力NVEが、特定のESに接続されたマルチホーム出力NVEとやり取りするときに高速コンバージェンス、エイリアシング、およびバックアップパスを利用できるようにするため、シングルホーミング[RFC7432]のセクション8.2（「高速コンバージェンス」）および8.4（「エイリアスおよびバックアップパス」）で定義されている、ESごとのイーサネットADおよびEVIごとのイーサネットADであるルートの入口ノード処理を、入口NVEで実装する必要があります。
In this section, we discuss the scenario where the NVEs reside in the ToR switches AND the servers (where VMs are residing) are multihomed to these ToR switches. The multihoming NVE operates in All-Active or Single-Active redundancy mode. If the servers are single-homed to the ToR switches, then the scenario becomes similar to that where the NVE resides on the hypervisor, as discussed in Section 7, as far as the required EVPN functionality is concerned.
このセクションでは、NVEがToRスイッチに存在し、サーバー（VMが存在する）がこれらのToRスイッチにマルチホーム化されているシナリオについて説明します。マルチホーミングNVEは、All-ActiveまたはSingle-Active冗長モードで動作します。サーバーがToRスイッチにシングルホームされている場合、シナリオは、必要なEVPN機能に関する限り、セクション7で説明されているように、NVEがハイパーバイザーに存在する場合と同様になります。
[RFC7432] defines a set of BGP routes, attributes, and procedures to support multihoming. We first describe these functions and procedures, then discuss which of these are impacted by the VXLAN (or NVGRE) encapsulation and what modifications are required. As will be seen later in this section, the only EVPN procedure that is impacted by non-MPLS overlay encapsulation (e.g., VXLAN or NVGRE) where it provides space for one ID rather than a stack of labels, is that of split-horizon filtering for multihomed ESs described in Section 8.3.1.
[RFC7432]は、マルチホーミングをサポートするための一連のBGPルート、属性、および手順を定義しています。最初にこれらの機能と手順について説明し、次に、VXLAN（またはNVGRE）カプセル化の影響を受けるものと、必要な変更について説明します。このセクションで後述するように、ラベルのスタックではなく1つのIDにスペースを提供する非MPLSオーバーレイカプセル化（VXLANやNVGREなど）の影響を受ける唯一のEVPN手順は、スプリットホライズンフィルタリングの手順です。セクション8.3.1で説明されているマルチホームESの場合。
In this section, we will recap the multihoming features of EVPN to highlight the encapsulation dependencies. The section only describes the features and functions at a high level. For more details, the reader is to refer to [RFC7432].
このセクションでは、EVPNのマルチホーミング機能を要約して、カプセル化の依存関係を強調します。このセクションでは、機能の概要のみを説明します。詳細については、[RFC7432]を参照してください。
EVPN NVEs (or PEs) connected to the same ES (e.g., the same server via Link Aggregation Group (LAG)) can automatically discover each other with minimal to no configuration through the exchange of BGP routes.
同じES（たとえば、リンク集約グループ（LAG）を介して同じサーバー）に接続されたEVPN NVE（またはPE）は、BGPルートの交換を通じて、最小限の設定で、または設定なしで互いに自動的に検出できます。
EVPN defines a mechanism to efficiently and quickly signal, to remote NVEs, the need to update their forwarding tables upon the occurrence of a failure in connectivity to an ES (e.g., a link or a port failure). This is done by having each NVE advertise an Ethernet A-D route per ES for each locally attached segment. Upon a failure in connectivity to the attached segment, the NVE withdraws the corresponding Ethernet A-D route. This triggers all NVEs that receive the withdrawal to update their next-hop adjacencies for all MAC addresses associated with the ES in question. If no other NVE had advertised an Ethernet A-D route for the same segment, then the NVE that received the withdrawal simply invalidates the MAC entries for that segment. Otherwise, the NVE updates the next-hop adjacency list accordingly.
EVPNは、ESへの接続の障害（リンクやポートの障害など）が発生したときに転送テーブルを更新する必要性をリモートNVEに効率的かつ迅速に通知するメカニズムを定義しています。これは、各NVEに、ローカルに接続された各セグメントのESごとにイーサネットA-Dルートをアドバタイズさせることによって行われます。接続されたセグメントへの接続に失敗すると、NVEは対応するイーサネットA-Dルートを取り消します。これにより、撤回を受信したすべてのNVEがトリガーされ、問題のESに関連付けられているすべてのMACアドレスのネクストホップ隣接が更新されます。他のNVEが同じセグメントのイーサネットA-Dルートをアドバタイズしなかった場合、撤回を受け取ったNVEはそのセグメントのMACエントリを無効にするだけです。それ以外の場合、NVEはそれに応じてネクストホップ隣接リストを更新します。
If a server is multihomed to two or more NVEs (represented by an ES ES1) and operating in an All-Active redundancy mode, sends a BUM (i.e., Broadcast, Unknown unicast, or Multicast) packet to one of these NVEs, then it is important to ensure the packet is not looped back to the server via another NVE connected to this server. The filtering mechanism on the NVE to prevent such loop and packet duplication is called "split-horizon filtering".
サーバーが2つ以上のNVE（ES ES1で表される）にマルチホーム化され、All-Active冗長モードで動作している場合、BUM（つまり、ブロードキャスト、不明なユニキャスト、またはマルチキャスト）パケットをこれらのNVEの1つに送信します。パケットがこのサーバーに接続されている別のNVEを介してサーバーにループバックされないようにするために重要です。このようなループとパケットの重複を防ぐためのNVEのフィルタリングメカニズムは、「スプリットホライズンフィルタリング」と呼ばれます。
In the case where a station is multihomed to multiple NVEs, it is possible that only a single NVE learns a set of the MAC addresses associated with traffic transmitted by the station. This leads to a situation where remote NVEs receive MAC Advertisement routes, for these addresses, from a single NVE even though multiple NVEs are connected to the multihomed station. As a result, the remote NVEs are not able to effectively load-balance traffic among the NVEs connected to the multihomed ES. For example, this could be the case when the NVEs perform data-path learning on the access and the load-balancing function on the station hashes traffic from a given source MAC address to a single NVE. Another scenario where this occurs is when the NVEs rely on control-plane learning on the access (e.g., using ARP), since ARP traffic will be hashed to a single link in the LAG.
ステーションが複数のNVEにマルチホームしている場合、1つのNVEだけが、ステーションによって送信されたトラフィックに関連付けられたMACアドレスのセットを学習する可能性があります。これにより、複数のNVEがマルチホームステーションに接続されている場合でも、リモートNVEがこれらのアドレスのMACアドバタイズメントルートを単一のNVEから受信する状況になります。その結果、リモートNVEは、マルチホームESに接続されたNVE間でトラフィックを効果的に負荷分散できません。たとえば、NVEがアクセスに対してデータパス学習を実行し、ステーションのロードバランシング機能が特定の送信元MACアドレスから単一のNVEへのトラフィックをハッシュする場合などです。これが発生する別のシナリオは、ARPトラフィックがLAG内の単一のリンクにハッシュされるため、NVEが（たとえば、ARPを使用して）アクセスのコントロールプレーン学習に依存している場合です。
To alleviate this issue, EVPN introduces the concept of "Aliasing". This refers to the ability of an NVE to signal that it has reachability to a given locally attached ES, even when it has learned no MAC addresses from that segment. The Ethernet A-D route per EVI is used to that end. Remote NVEs that receive MAC Advertisement routes with non-zero ESIs should consider the MAC address as reachable via all NVEs that advertise reachability to the relevant Segment using Ethernet A-D routes with the same ESI and with the Single-Active flag reset.
この問題を軽減するために、EVPNは「エイリアス」の概念を導入しています。これは、NVEがそのセグメントからMACアドレスを学習していない場合でも、ローカルに接続された特定のESに到達可能であることを通知するNVEの機能を指します。そのため、EVIごとのイーサネットA-Dルートが使用されます。 ESIがゼロでないMACアドバタイズメントルートを受信するリモートNVEは、同じESIとシングルアクティブフラグがリセットされたイーサネットA-Dルートを使用して、関連するセグメントへの到達可能性をアドバタイズするすべてのNVE経由でMACアドレスが到達可能であると見なします。
Backup Path is a closely related function, albeit one that applies to the case where the redundancy mode is Single-Active. In this case, the NVE signals that it has reachability to a given locally attached ES using the Ethernet A-D route as well. Remote NVEs that receive the MAC Advertisement routes, with non-zero ESI, should consider the MAC address as reachable via the advertising NVE. Furthermore, the remote NVEs should install a Backup Path, for said MAC, to the NVE that had advertised reachability to the relevant segment using an Ethernet A-D route with the same ESI and with the Single-Active flag set.
バックアップパスは、冗長モードがシングルアクティブの場合に適用されますが、密接に関連する機能です。この場合、NVEは、イーサネットA-Dルートを使用して、ローカルに接続された特定のESにも到達可能であることを通知します。 ESIがゼロでないMACアドバタイズメントルートを受信するリモートNVEは、アドバタイズNVEを介して到達可能なMACアドレスと見なす必要があります。さらに、リモートNVEは、同じMACに対して、同じESIとシングルアクティブフラグが設定されたイーサネットA-Dルートを使用して、関連するセグメントへの到達可能性をアドバタイズしたNVEへのバックアップパスをインストールする必要があります。
If a host is multihomed to two or more NVEs on an ES operating in All-Active redundancy mode, then, for a given EVI, only one of these NVEs, termed the "Designated Forwarder" (DF) is responsible for sending it broadcast, multicast, and, if configured for that EVI, unknown unicast frames.
ホストがAll-Active冗長性モードで動作しているES上の2つ以上のNVEにマルチホーム化されている場合、特定のEVIでは、「Designated Forwarder」（DF）と呼ばれるこれらのNVEの1つだけがブロードキャストの送信を担当します。マルチキャスト、およびそのEVI用に構成されている場合、不明なユニキャストフレーム。
This is required in order to prevent duplicate delivery of multi-destination frames to a multihomed host or VM, in case of All-Active redundancy.
これは、All-Active冗長性の場合に、マルチホームホストまたはVMへのマルチ宛先フレームの重複配信を防ぐために必要です。
In NVEs where frames tagged as IEEE 802.1Q [IEEE.802.1Q] are received from hosts, the DF election should be performed based on host VIDs per Section 8.5 of [RFC7432]. Furthermore, multihoming PEs of a given ES MAY perform DF election using configured IDs such as VNI, EVI, normalized VIDs, and etc., as along the IDs are configured consistently across the multihoming PEs.
IEEE 802.1Q [IEEE.802.1Q]のタグが付けられたフレームがホストから受信されるNVEでは、DFの選択は、[RFC7432]のセクション8.5に基づくホストVIDに基づいて実行する必要があります。さらに、IDがマルチホーミングPE全体で一貫して構成されているため、特定のESのマルチホーミングPEは、VNI、EVI、正規化VIDなどの構成済みIDを使用してDF選定を実行できます（MAY）。
In GWs where VXLAN-encapsulated frames are received, the DF election is performed on VNIs. Again, it is assumed that, for a given Ethernet segment, VNIs are unique and consistent (e.g., no duplicate VNIs exist).
VXLANカプセル化フレームが受信されるGWでは、DF選定はVNIで実行されます。この場合も、所定のイーサネットセグメントに対して、VNIは一意で一貫していると想定されます（たとえば、重複するVNIは存在しません）。
Since multihoming is supported in this scenario, the entire set of BGP routes and attributes defined in [RFC7432] is used. The setting of the Ethernet Tag field in the MAC Advertisement, Ethernet A-D per EVI, and IMET) routes follows that of Section 5.1.3. Furthermore, the setting of the VNI field in the MAC Advertisement and Ethernet A-D per EVI routes follows that of Section 5.1.3.
このシナリオではマルチホーミングがサポートされているため、[RFC7432]で定義されているBGPルートと属性のセット全体が使用されます。 MACアドバタイズメント、EVIごとのイーサネットA-D、およびIMET）ルートのイーサネットタグフィールドの設定は、セクション5.1.3の設定に従います。さらに、EVIルートごとのMACアドバタイズメントおよびイーサネットA-DのVNIフィールドの設定は、セクション5.1.3の設定に従います。
Two cases need to be examined here, depending on whether the NVEs are operating in Single-Active or in All-Active redundancy mode.
NVEがシングルアクティブ冗長モードで動作しているか、オールアクティブ冗長モードで動作しているかに応じて、ここで2つのケースを調べる必要があります。
First, let's consider the case of Single-Active redundancy mode, where the hosts are multihomed to a set of NVEs; however, only a single NVE is active at a given point of time for a given VNI. In this case, the Aliasing is not required, and the split-horizon filtering may not be required, but other functions such as multihomed ES auto-discovery, fast convergence and mass withdrawal, Backup Path, and DF election are required.
まず、ホストがNVEのセットにマルチホーム化されているシングルアクティブ冗長モードの場合を考えてみましょう。ただし、特定のVNIの特定の時点でアクティブになるNVEは1つだけです。この場合、エイリアシングは不要であり、スプリットホライズンフィルタリングは必要ない場合がありますが、マルチホームES自動検出、高速コンバージェンスと大量撤退、バックアップパス、DF選出などの他の機能が必要です。
Second, let's consider the case of All-Active redundancy mode. In this case, out of all the EVPN multihoming features listed in Section 8.1, the use of the VXLAN or NVGRE encapsulation impacts the split-horizon and Aliasing features, since those two rely on the MPLS client layer. Given that this MPLS client layer is absent with these types of encapsulations, alternative procedures and mechanisms are needed to provide the required functions. Those are discussed in detail next.
次に、All-Active冗長モードの場合を考えてみましょう。この場合、セクション8.1にリストされているすべてのEVPNマルチホーミング機能のうち、VXLANまたはNVGREカプセル化の使用は、スプリットホライズンとエイリアシング機能に影響を与えます。これらの2つはMPLSクライアントレイヤーに依存しているためです。このMPLSクライアント層にこれらのタイプのカプセル化がないため、必要な機能を提供するには、代替の手順とメカニズムが必要です。これらについては、次に詳しく説明します。
In EVPN, an MPLS label is used for split-horizon filtering to support All-Active multihoming where an ingress NVE adds a label corresponding to the site of origin (aka an ESI label) when encapsulating the packet. The egress NVE checks the ESI label when attempting to forward a multi-destination frame out an interface, and if the label corresponds to the same site identifier (ESI) associated with that interface, the packet gets dropped. This prevents the occurrence of forwarding loops.
EVPNでは、MPLSラベルはスプリットホライズンフィルタリングに使用され、パケットをカプセル化するときに、イングレスNVEが発信元のサイトに対応するラベル（別名ESIラベル）を追加するオールアクティブマルチホーミングをサポートします。出力NVEは、マルチ宛先フレームをインターフェイスから転送しようとするときにESIラベルをチェックします。ラベルがそのインターフェイスに関連付けられている同じサイト識別子（ESI）に対応している場合、パケットはドロップされます。これにより、転送ループの発生が防止されます。
Since VXLAN and NVGRE encapsulations do not include the ESI label, other means of performing the split-horizon filtering function must be devised for these encapsulations. The following approach is recommended for split-horizon filtering when VXLAN (or NVGRE) encapsulation is used.
VXLANおよびNVGREカプセル化にはESIラベルが含まれていないため、これらのカプセル化のためにスプリットホライズンフィルタリング機能を実行する他の方法を考案する必要があります。 VXLAN（またはNVGRE）カプセル化が使用される場合、スプリットホライズンフィルタリングには次のアプローチが推奨されます。
Every NVE tracks the IP address(es) associated with the other NVE(s) with which it has shared multihomed ESs. When the NVE receives a multi-destination frame from the overlay network, it examines the source IP address in the tunnel header (which corresponds to the ingress NVE) and filters out the frame on all local interfaces connected to ESs that are shared with the ingress NVE. With this approach, it is required that the ingress NVE perform replication locally to all directly attached Ethernet segments (regardless of the DF election state) for all flooded traffic ingress from the access interfaces (i.e., from the hosts). This approach is referred to as "Local Bias", and has the advantage that only a single IP address need be used per NVE for split-horizon filtering, as opposed to requiring an IP address per Ethernet segment per NVE.
すべてのNVEは、マルチホームESを共有している他のNVEに関連付けられたIPアドレスを追跡します。 NVEはオーバーレイネットワークから複数の宛先フレームを受信すると、トンネルヘッダーの送信元IPアドレス（入力NVEに対応）を調べ、入力と共有されているESに接続されているすべてのローカルインターフェイス上のフレームをフィルターで除外しますNVE。このアプローチでは、アクセスインターフェイス（ホストなど）からのすべてのフラッディングトラフィック入力に対して、イングレスNVEが直接接続されたすべてのイーサネットセグメントに（DF選択状態に関係なく）ローカルでレプリケーションを実行する必要があります。このアプローチは「ローカルバイアス」と呼ばれ、NVEごとにイーサネットセグメントごとにIPアドレスを要求するのではなく、スプリットホライズンフィルタリングにNVEごとに単一のIPアドレスのみを使用する必要があるという利点があります。
In order to allow proper operation of split-horizon filtering among the same group of multihoming PE devices, a mix of PE devices with MPLS over GRE encapsulations running the procedures from [RFC7432] for split-horizon filtering on the one hand and VXLAN/NVGRE encapsulation running local-bias procedures on the other on a given Ethernet segment MUST NOT be configured.
マルチホーミングPEデバイスの同じグループ間でスプリットホライズンフィルタリングを適切に操作できるようにするために、一方のスプリットホライズンフィルタリング用の[RFC7432]の手順を実行するMPLS over GREカプセル化を備えたPEデバイスとVXLAN / NVGREのミックス与えられたイーサネットセグメント上のもう一方のローカルバイアスプロシージャを実行するカプセル化は構成してはなりません。
The Aliasing and the Backup Path procedures for VXLAN/NVGRE encapsulation are very similar to the ones for MPLS. In the case of MPLS, Ethernet A-D route per EVI is used for Aliasing when the corresponding ES operates in All-Active multihoming, and the same route is used for Backup Path when the corresponding ES operates in Single-Active multihoming. In the case of VXLAN/NVGRE, the same route is used for the Aliasing and the Backup Path with the difference that the Ethernet Tag and VNI fields in Ethernet A-D per EVI route are set as described in Section 5.1.3.
VXLAN / NVGREカプセル化のエイリアスとバックアップパスの手順は、MPLSの場合と非常によく似ています。 MPLSの場合、対応するESがオールアクティブマルチホーミングで動作する場合、EVIごとのイーサネットA-Dルートがエイリアシングに使用され、対応するESがシングルアクティブマルチホーミングで動作する場合、同じルートがバックアップパスに使用されます。 VXLAN / NVGREの場合、エイリアスとバックアップパスに同じルートが使用されますが、EVIルートごとのイーサネットA-DのイーサネットタグとVNIフィールドがセクション5.1.3で説明されているように設定されている点が異なります。
In EVPN, when an ingress PE uses ingress replication to flood unknown unicast traffic to egress PEs, the ingress PE uses a different EVPN MPLS label (from the one used for known unicast traffic) to identify such BUM traffic. The egress PEs use this label to identify such BUM traffic and, thus, apply DF filtering for All-Active multihomed sites. In absence of an unknown unicast traffic designation and in the presence of enabling unknown unicast flooding, there can be transient duplicate traffic to All-Active multihomed sites under the following condition: the host MAC address is learned by the egress PE(s) and advertised to the ingress PE; however, the MAC Advertisement has not been received or processed by the ingress PE, resulting in the host MAC address being unknown on the ingress PE but known on the egress PE(s). Therefore, when a packet destined to that host MAC address arrives on the ingress PE, it floods it via ingress replication to all the egress PE(s), and since they are known to the egress PE(s), multiple copies are sent to the All-Active multihomed site. It should be noted that such transient packet duplication only happens when a) the destination host is multihomed via All-Active redundancy mode, b) flooding of unknown unicast is enabled in the network, c) ingress replication is used, and d) traffic for the destination host is arrived on the ingress PE before it learns the host MAC address via BGP EVPN advertisement. If it is desired to avoid occurrence of such transient packet duplication (however low probability that may be), then VXLAN-GPE encapsulation needs to be used between these PEs and the ingress PE needs to set the BUM Traffic Bit (B bit) [VXLAN-GPE] to indicate that this is an ingress-replicated BUM traffic.
EVPNでは、入力PEが入力レプリケーションを使用して不明なユニキャストトラフィックを出力PEにフラッディングする場合、入力PEは（既知のユニキャストトラフィックに使用されるものとは異なる）別のEVPN MPLSラベルを使用して、そのようなBUMトラフィックを識別します。出力PEはこのラベルを使用してそのようなBUMトラフィックを識別し、したがって、すべてアクティブなマルチホームサイトにDFフィルタリングを適用します。不明なユニキャストトラフィックが指定されておらず、不明なユニキャストフラッディングが有効になっている場合、次の条件でAll-Activeマルチホームサイトへの一時的な重複トラフィックが発生する可能性があります。ホストのMACアドレスが出力PEによって学習され、アドバタイズされます。入力PEへ。ただし、MACアドバタイズが入力PEで受信または処理されていないため、ホストのMACアドレスは入力PEでは不明ですが、出力PEでは認識されています。したがって、そのホストMACアドレス宛のパケットが入力PEに到着すると、それは入力レプリケーションを介してすべての出力PEにフラッディングされ、それらは出力PEに認識されているため、複数のコピーがAll-Activeマルチホームサイト。このような一時的なパケットの複製は、a）宛先ホストがAll-Active冗長モードを介してマルチホーム化されている、b）不明なユニキャストのフラッディングがネットワークで有効になっている、c）入力レプリケーションが使用されている、およびd）トラフィックが宛先ホストは、BGP EVPNアドバタイズメントによってホストMACアドレスを学習する前に、入力PEに到着します。このような一時的なパケットの重複の発生を回避することが望まれる場合（可能性は低いですが）、VXLAN-GPEカプセル化をこれらのPE間で使用する必要があり、入力PEはBUMトラフィックビット（Bビット）を設定する必要があります[VXLAN -GPE]これが入力レプリケートされたBUMトラフィックであることを示します。
The EVPN IMET route is used to discover the multicast tunnels among the endpoints associated with a given EVI (e.g., given VNI) for VLAN-Based Service and a given <EVI, VLAN> for VLAN-Aware Bundle Service. All fields of this route are set as described in Section 5.1.3. The originating router's IP address field is set to the NVE's IP address. This route is tagged with the PMSI Tunnel attribute, which is used to encode the type of multicast tunnel to be used as well as the multicast tunnel identifier. The tunnel encapsulation is encoded by adding the BGP Encapsulation Extended Community as per Section 5.1.1. For example, the PMSI Tunnel attribute may indicate the multicast tunnel is of type Protocol Independent Multicast - Sparse-Mode (PIM-SM); whereas, the BGP Encapsulation Extended Community may indicate the encapsulation for that tunnel is of type VXLAN. The following tunnel types as defined in [RFC6514] can be used in the PMSI Tunnel attribute for VXLAN/NVGRE:
EVPN IMETルートは、VLANベースのサービスの特定のEVI（たとえば、特定のVNI）およびVLAN対応のバンドルサービスの特定の<EVI、VLAN>に関連付けられたエンドポイント間のマルチキャストトンネルを検出するために使用されます。このルートのすべてのフィールドは、セクション5.1.3で説明されているように設定されます。発信元ルーターのIPアドレスフィールドは、NVEのIPアドレスに設定されます。このルートにはPMSI Tunnel属性がタグ付けされます。これは、使用するマルチキャストトンネルのタイプとマルチキャストトンネル識別子をエンコードするために使用されます。トンネルカプセル化は、セクション5.1.1に従ってBGPカプセル化拡張コミュニティを追加することによってエンコードされます。たとえば、PMSIトンネル属性は、マルチキャストトンネルのタイプがプロトコル非依存マルチキャスト-スパースモード（PIM-SM）であることを示している場合があります。一方、BGPカプセル化拡張コミュニティは、そのトンネルのカプセル化がVXLANタイプであることを示す場合があります。 [RFC6514]で定義されている次のトンネルタイプは、VXLAN / NVGREのPMSIトンネル属性で使用できます。
+ 3 - PIM-SSM Tree
+ 4 - PIM-SM Tree
+ 5 - BIDIR-PIM Tree
+ 6 - Ingress Replication
In case of VXLAN and NVGRE encapsulations with locally assigned VNIs, just as in [RFC7432], each PE MUST advertise an IMET route to other PEs in an EVPN instance for the multicast tunnel type that it uses (i.e., ingress replication, PIM-SM, PIM-SSM, or BIDIR-PIM tunnel). However, for globally assigned VNIs, each PE MUST advertise an IMET route to other PEs in an EVPN instance for ingress replication or a PIM-SSM tunnel, and they MAY advertise an IMET route for a PIM-SM or BIDIR-PIM tunnel. In case of a PIM-SM or BIDIR-PIM tunnel, no information in the IMET route is needed by the PE to set up these tunnels.
[RFC7432]と同様に、ローカルに割り当てられたVNIを使用するVXLANおよびNVGREカプセル化の場合、各PEは、使用するマルチキャストトンネルタイプ（つまり、入力レプリケーション、PIM-SM）のEVPNインスタンス内の他のPEにIMETルートを通知する必要があります。 、PIM-SSM、またはBIDIR-PIMトンネル）。ただし、グローバルに割り当てられたVNIの場合、各PEは入力レプリケーションまたはPIM-SSMトンネルのEVPNインスタンス内の他のPEにIMETルートをアドバタイズする必要があり、PIM-SMまたはBIDIR-PIMトンネルのIMETルートをアドバタイズできます（MAY）。 PIM-SMまたはBIDIR-PIMトンネルの場合、PEがこれらのトンネルを設定するためにIMETルートの情報は必要ありません。
In the scenario where the multicast tunnel is a tree, both the Inclusive as well as the Aggregate Inclusive variants may be used. In the former case, a multicast tree is dedicated to a VNI. Whereas, in the latter, a multicast tree is shared among multiple VNIs. For VNI-Based Service, the Aggregate Inclusive mode is accomplished by having the NVEs advertise multiple IMET routes with different RTs (one per VNI) but with the same tunnel identifier encoded in the PMSI Tunnel attribute. For VNI-Aware Bundle Service, the Aggregate Inclusive mode is accomplished by having the NVEs advertise multiple IMET routes with different VNIs encoded in the Ethernet Tag field, but with the same tunnel identifier encoded in the PMSI Tunnel attribute.
マルチキャストトンネルがツリーであるシナリオでは、包括的バリアントと集約的包括的バリアントの両方を使用できます。前者の場合、マルチキャストツリーはVNI専用です。一方、後者では、マルチキャストツリーは複数のVNI間で共有されます。 VNIベースのサービスの場合、集約インクルーシブモードは、NRTが異なるRT（VNIごとに1つ）を持ち、同じトンネル識別子がPMSIトンネル属性にエンコードされた複数のIMETルートをアドバタイズすることで実現されます。 VNI対応バンドルサービスの場合、集約インクルーシブモードは、NVEがイーサネットタグフィールドにエンコードされた異なるVNIを持つ複数のIMETルートをアドバタイズするが、PMSIトンネル属性にエンコードされた同じトンネル識別子で実現されます。
For DCIs, the following two main scenarios are considered when connecting data centers running evpn-overlay (as described here) over an MPLS/IP core network:
DCIの場合、MPLS / IPコアネットワークを介してevpn-overlay（ここで説明）を実行しているデータセンターを接続するときに、次の2つの主要なシナリオが考慮されます。
- Scenario 1: DCI using GWs
- シナリオ1：GWを使用するDCI
- Scenario 2: DCI using ASBRs
- シナリオ2：ASBRを使用したDCI
The following two subsections describe the operations for each of these scenarios.
次の2つのサブセクションでは、これらの各シナリオの操作について説明します。
This is the typical scenario for interconnecting data centers over WAN. In this scenario, EVPN routes are terminated and processed in each GW and MAC/IP route are always re-advertised from DC to WAN but from WAN to DC, they are not re-advertised if unknown MAC addresses (and default IP address) are utilized in the NVEs. In this scenario, each GW maintains a MAC-VRF (and/or IP-VRF) for each EVI. The main advantage of this approach is that NVEs do not need to maintain MAC and IP addresses from any remote data centers when default IP routes and unknown MAC routes are used; that is, they only need to maintain routes that are local to their own DC. When default IP routes and unknown MAC routes are used, any unknown IP and MAC packets from NVEs are forwarded to the GWs where all the VPN MAC and IP routes are maintained. This approach reduces the size of MAC-VRF and IP-VRF significantly at NVEs. Furthermore, it results in a faster convergence time upon a link or NVE failure in a multihomed network or device redundancy scenario, because the failure-related BGP routes (such as mass withdrawal message) do not need to get propagated all the way to the remote NVEs in the remote DCs. This approach is described in detail in Section 3.4 of [DCI-EVPN-OVERLAY].
これは、WANを介してデータセンターを相互接続するための典型的なシナリオです。このシナリオでは、EVPNルートは終了され、各GWで処理されます。MAC/ IPルートは常にDCからWANに再アドバタイズされますが、WANからDCに再アドバタイズされます。不明なMACアドレス（およびデフォルトのIPアドレス）がある場合、それらは再アドバタイズされません。 NVEで使用されます。このシナリオでは、各GWは各EVIのMAC-VRF（および/またはIP-VRF）を維持します。このアプローチの主な利点は、デフォルトのIPルートと不明なMACルートが使用されている場合、NVEがリモートデータセンターからのMACアドレスとIPアドレスを維持する必要がないことです。つまり、自分のDCに対してローカルなルートを維持するだけで済みます。デフォルトのIPルートと不明なMACルートが使用されている場合、NVEからの不明なIPおよびMACパケットはすべてのVPN MACおよびIPルートが維持されているGWに転送されます。このアプローチにより、NVEでMAC-VRFおよびIP-VRFのサイズが大幅に削減されます。さらに、マルチホームネットワークまたはデバイスの冗長性シナリオでリンクまたはNVE障害が発生すると、コンバージェンス時間が短縮されます。これは、障害に関連するBGPルート（大量の撤回メッセージなど）がリモートに伝達される必要がないためです。リモートDCのNVE。このアプローチは、[DCI-EVPN-OVERLAY]のセクション3.4で詳細に説明されています。
This approach can be considered as the opposite of the first approach. It favors simplification at DCI devices over NVEs such that larger MAC-VRF (and IP-VRF) tables need to be maintained on NVEs; whereas DCI devices don't need to maintain any MAC (and IP) forwarding tables. Furthermore, DCI devices do not need to terminate and process routes related to multihoming but rather to relay these messages for the establishment of an end-to-end Label Switched Path (LSP). In other words, DCI devices in this approach operate similar to ASBRs for inter-AS Option B (see Section 10 of [RFC4364]). This requires locally assigned VNIs to be used just like downstream-assigned MPLS VPN labels where, for all practical purposes, the VNIs function like 24-bit VPN labels. This approach is equally applicable to data centers (or Carrier Ethernet networks) with MPLS encapsulation.
このアプローチは、最初のアプローチの逆と見なすことができます。より大きなMAC-VRF（およびIP-VRF）テーブルをNVEで維持する必要があるように、NVEよりもDCIデバイスでの簡素化を支持します。一方、DCIデバイスはMAC（およびIP）転送テーブルを維持する必要はありません。さらに、DCIデバイスは、マルチホーミングに関連するルートを終了して処理する必要はなく、エンドツーエンドのラベルスイッチドパス（LSP）の確立のためにこれらのメッセージを中継する必要があります。つまり、このアプローチのDCIデバイスは、AS間オプションBのASBRと同様に動作します（[RFC4364]のセクション10を参照）。これには、ローカルに割り当てられたVNIを、ダウンストリームに割り当てられたMPLS VPNラベルと同じように使用する必要があります。実際には、VNIは24ビットVPNラベルのように機能します。このアプローチは、MPLSカプセル化を使用するデータセンター（またはキャリアイーサネットネットワーク）にも同様に適用できます。
In inter-AS Option B, when ASBR receives an EVPN route from its DC over internal BGP (iBGP) and re-advertises it to other ASBRs, it re-advertises the EVPN route by re-writing the BGP next hops to itself, thus losing the identity of the PE that originated the advertisement. This rewrite of BGP next hop impacts the EVPN mass withdrawal route (Ethernet A-D per ES) and its procedure adversely. However, it does not impact the EVPN Aliasing mechanism/procedure because when the Aliasing routes (Ethernet A-D per EVI) are advertised, the receiving PE first resolves a MAC address for a given EVI into its corresponding <ES, EVI>, and, subsequently, it resolves the <ES, EVI> into multiple paths (and their associated next hops) via which the <ES, EVI> is reachable. Since Aliasing and MAC routes are both advertised on a per-EVI-basis and they use the same RD and RT (per EVI), the receiving PE can associate them together on a per-BGP-path basis (e.g., per originating PE). Thus, it can perform recursive route resolution, e.g., a MAC is reachable via an <ES, EVI> which in turn, is reachable via a set of BGP paths; thus, the MAC is reachable via the set of BGP paths. Due to the per-EVI basis, the association of MAC routes and the corresponding Aliasing route is fixed and determined by the same RD and RT; there is no ambiguity when the BGP next hop for these routes is rewritten as these routes pass through ASBRs. That is, the receiving PE may receive multiple Aliasing routes for the same EVI from a single next hop (a single ASBR), and it can still create multiple paths toward that <ES, EVI>.
AS間オプションBでは、ASBRがDCから内部BGP（iBGP）を介してEVPNルートを受信し、それを他のASBRに再アドバタイズする場合、BGPネクストホップをそれ自体に書き直すことにより、EVPNルートを再アドバタイズします。アドバタイズを発信したPEのIDを失う。 BGPネクストホップのこの書き換えは、EVPN大量撤退ルート（ESごとのイーサネットA-D）とその手順に悪影響を及ぼします。ただし、エイリアスルート（EVIごとのイーサネットAD）がアドバタイズされると、受信側PEは最初に特定のEVIのMACアドレスを対応する<ES、EVI>に解決し、その後、EVPNエイリアスメカニズム/手順には影響しません。 、それは<ES、EVI>に到達可能な複数のパス（およびそれらに関連付けられた次のホップ）に<ES、EVI>を解決します。エイリアシングとMACルートは両方ともEVIごとにアドバタイズされ、それらは同じRDとRT（EVIごと）を使用するため、受信PEはBGPパスごとに（たとえば、発信PEごとに）それらを関連付けることができます。 。したがって、再帰的なルート解決を実行できます。たとえば、MACは<ES、EVI>を介して到達可能であり、<ES、EVI>はBGPパスのセットを介して到達可能です。したがって、MACはBGPパスのセットを介して到達可能です。 EVI単位であるため、MACルートと対応するエイリアスルートの関連付けは固定され、同じRDとRTによって決定されます。これらのルートがASBRを通過するときに、これらのルートのBGPネクストホップが書き換えられても、あいまいさはありません。つまり、受信側のPEは、同じEVIの複数のエイリアスルートを単一のネクストホップ（単一のASBR）から受信し、その<ES、EVI>への複数のパスを作成できます。
However, when the BGP next-hop address corresponding to the originating PE is rewritten, the association between the mass withdrawal route (Ethernet A-D per ES) and its corresponding MAC routes cannot be made based on their RDs and RTs because the RD for the mass Withdrawal route is different than the one for the MAC routes. Therefore, the functionality needed at the ASBRs and the receiving PEs depends on whether the Mass Withdrawal route is originated and whether there is a need to handle route resolution ambiguity for this route. The following two subsections describe the functionality needed by the ASBRs and the receiving PEs depending on whether the NVEs reside in a hypervisors or in ToR switches.
ただし、元のPEに対応するBGPネクストホップアドレスが書き換えられた場合、大量のRDに基づいて、大量撤退ルート（ESごとのイーサネットAD）とそれに対応するMACルートを関連付けることはできません。引き出しルートは、MACルートの引き出しルートとは異なります。したがって、ASBRと受信側PEで必要な機能は、一括取り消しルートが作成されたかどうか、およびこのルートのルート解決のあいまいさを処理する必要があるかどうかによって異なります。次の2つのサブセクションでは、NVEがハイパーバイザーにあるかToRスイッチにあるかに応じて、ASBRと受信PEに必要な機能について説明します。
When NVEs reside in hypervisors as described in Section 7.1, there is no multihoming; thus, there is no need for the originating NVE to send Ethernet A-D per ES or Ethernet A-D per EVI routes. However, as noted in Section 7, in order to enable a single-homing ingress NVE to take advantage of fast convergence, Aliasing, and Backup Path when interacting with multihoming egress NVEs attached to a given ES, the single-homing NVE should be able to receive and process Ethernet A-D per ES and Ethernet A-D per EVI routes. The handling of these routes is described in the next section.
セクション7.1で説明されているように、NVEがハイパーバイザーに存在する場合、マルチホーミングはありません。したがって、元のNVEがESごとにイーサネットA-DまたはEVIごとにイーサネットA-Dを送信する必要はありません。ただし、セクション7に記載されているように、シングルホーミング入力NVEが特定のESに接続されたマルチホーミング出力NVEと対話するときに高速コンバージェンス、エイリアス、およびバックアップパスを利用できるようにするには、シングルホーミングNVEがESごとのイーサネットADおよびEVIごとのイーサネットADを受信して処理します。これらのルートの処理については、次のセクションで説明します。
When NVEs reside in ToR switches and operate in multihoming redundancy mode, there is a need, as described in Section 8, for the originating multihoming NVE to send Ethernet A-D per ES route(s) (used for mass withdrawal) and Ethernet A-D per EVI routes (used for Aliasing). As described above, the rewrite of BGP next hop by ASBRs creates ambiguities when Ethernet A-D per ES routes are received by the remote NVE in a different ASBR because the receiving NVE cannot associate that route with the MAC/IP routes of that ES advertised by the same originating NVE. This ambiguity inhibits the function of mass withdrawal per ES by the receiving NVE in a different AS.
NVEがToRスイッチに存在し、マルチホーミング冗長モードで動作している場合、セクション8で説明されているように、発信マルチホーミングNVEがESルートごとにイーサネットAD（大量の撤回に使用）およびEVIごとのイーサネットADを送信する必要があります。ルート（エイリアスに使用）。前述のように、ASBRによるBGPネクストホップの書き換えは、ESルートごとのイーサネットADが別のASBRのリモートNVEによって受信されるときにあいまいさを生じます。これは、受信NVEがそのルートを、同じ元のNVE。このあいまいさは、異なるASの受信NVEによるESごとの大量離脱の機能を阻害します。
As an example, consider a scenario where a CE is multihomed to PE1 and PE2, where these PEs are connected via ASBR1 and then ASBR2 to the remote PE3. Furthermore, consider that PE1 receives M1 from CE1 but not PE2. Therefore, PE1 advertises Ethernet A-D per ES1, Ethernet A-D per EVI1, and M1; whereas, PE2 only advertises Ethernet A-D per ES1 and Ethernet A-D per EVI1. ASBR1 receives all these five advertisements and passes them to ASBR2 (with itself as the BGP next hop). ASBR2, in turn, passes them to the remote PE3, with itself as the BGP next hop. PE3 receives these five routes where all of them have the same BGP next hop (i.e., ASBR2). Furthermore, the two Ethernet A-D per ES routes received by PE3 have the same information, i.e., same ESI and the same BGP next hop. Although both of these routes are maintained by the BGP process in PE3 (because they have different RDs and, thus, are treated as different BGP routes), information from only one of them is used in the L2 routing table (L2 RIB).
例として、CEがPE1およびPE2にマルチホーム化され、これらのPEがASBR1を介して、次にASBR2を介してリモートPE3に接続されているシナリオを考えます。さらに、PE1がCE1からM1を受信し、PE2は受信しないことを考慮してください。したがって、PE1はES1ごとにイーサネットA-D、EVI1ごとにイーサネットA-D、およびM1をアドバタイズします。一方、PE2は、ES1ごとのイーサネットA-DとEVI1ごとのイーサネットA-Dのみをアドバタイズします。 ASBR1は、これらの5つのアドバタイズをすべて受信し、それ自体をBBRネクストホップとしてASBR2に渡します。次に、ASBR2は自身をBGPネクストホップとして、リモートPE3に渡します。 PE3は、これらすべてのルートが同じBGPネクストホップ（つまり、ASBR2）を持つ5つのルートを受信します。さらに、PE3によって受信されたESルートごとの2つのイーサネットA-Dは、同じ情報、つまり同じESIと同じBGPネクストホップを持っています。これらのルートは両方ともPE3のBGPプロセスによって維持されます（それらは異なるRDを持っているため、異なるBGPルートとして扱われるため）、L2ルーティングテーブル（L2 RIB）ではそれらの1つからの情報のみが使用されます。
PE1
/ \
CE ASBR1---ASBR2---PE3
\ /
PE2
Figure 3: Inter-AS Option B
図3：Inter-ASオプションB
Now, when the AC between the PE2 and the CE fails and PE2 sends Network Layer Reachability Information (NLRI) withdrawal for Ethernet A-D per ES route, and this withdrawal gets propagated and received by the PE3, the BGP process in PE3 removes the corresponding BGP route; however, it doesn't remove the associated information (namely ESI and BGP next hop) from the L2 routing table (L2 RIB) because it still has the other Ethernet A-D per ES route (originated from PE1) with the same information. That is why the mass withdrawal mechanism does not work when doing DCI with inter-AS Option B. However, as described previously, the Aliasing function works and so does "mass withdrawal per EVI" (which is associated with withdrawing the EVPN route associated with Aliasing, i.e., Ethernet A-D per EVI route).
これで、PE2とCE間のACが失敗し、PE2がESルートごとにイーサネットADのネットワーク層到達可能性情報（NLRI）撤回を送信し、この撤回がPE3によって伝達および受信されると、PE3のBGPプロセスは対応するBGPを削除しますルート;ただし、L2ルーティングテーブル（L2 RIB）から関連情報（つまり、ESIおよびBGPネクストホップ）は削除されません。これは、同じ情報を持つ（PE1から発信された）ESルートごとに他のイーサネットA-Dがまだあるためです。そのため、AS間オプションBでDCIを実行すると、一括回収メカニズムは機能しません。ただし、前述のように、エイリアス機能は機能し、「EVIごとの大量回収」（これは、関連するEVPNルートの回収に関連しています）エイリアシング、つまりEVIルートごとのイーサネットAD）。
In the above example, the PE3 receives two Aliasing routes with the same BGP next hop (ASBR2) but different RDs. One of the Aliasing route has the same RD as the advertised MAC route (M1). PE3 follows the route resolution procedure specified in [RFC7432] upon receiving the two Aliasing routes; that is, it resolves M1 to <ES, EVI1>, and, subsequently, it resolves <ES, EVI1> to a BGP path list with two paths along with the corresponding VNIs/MPLS labels (one associated with PE1 and the other associated with PE2). It should be noted that even though both paths are advertised by the same BGP next hop (ASRB2), the receiving PE3 can handle them properly. Therefore, M1 is reachable via two paths. This creates two end-to-end LSPs, from PE3 to PE1 and from PE3 to PE2, for M1 such that when PE3 wants to forward traffic destined to M1, it can load-balance between the two LSPs. Although route resolution for Aliasing routes with the same BGP next hop is not explicitly mentioned in [RFC7432], this is the expected operation; thus, it is elaborated here.
上記の例では、PE3は、同じBGPネクストホップ（ASBR2）を持つがRDが異なる2つのエイリアシングルートを受信します。エイリアスルートの1つに、アドバタイズされたMACルート（M1）と同じRDがあります。 PE3は、2つのエイリアシングルートを受信すると、[RFC7432]で指定されたルート解決手順に従います。つまり、M1を<ES、EVI1>に解決し、その後、<ES、EVI1>を、対応するVNI / MPLSラベル（一方はPE1に関連付けられ、もう一方はPE2）。両方のパスが同じBGPネクストホップ（ASRB2）によってアドバタイズされていても、受信側のPE3はそれらを適切に処理できることに注意してください。したがって、M1には2つのパスを介して到達できます。これにより、PE3からPE1までとPE3からPE2までの2つのエンドツーエンドLSPがM1に作成され、PE3がM1宛てのトラフィックを転送するときに、2つのLSP間で負荷分散できるようになります。 [RFC7432]では、同じBGPネクストホップを持つエイリアスルートのルート解決については明示的に言及されていませんが、これは予想される操作です。したがって、ここで詳しく説明します。
When the AC between the PE2 and the CE fails and PE2 sends NLRI withdrawal for Ethernet A-D per EVI routes, and these withdrawals get propagated and received by the PE3, the PE3 removes the Aliasing route and updates the path list; that is, it removes the path corresponding to the PE2. Therefore, all the corresponding MAC routes for that <ES, EVI> that point to that path list will now have the updated path list with a single path associated with PE1. This action can be considered to be the mass withdrawal at the per-EVI level. The mass withdrawal at the per-EVI level has a longer convergence time than the mass withdrawal at the per-ES level; however, it is much faster than the convergence time when the withdrawal is done on a per-MAC basis.
PE2とCE間のACが失敗し、PE2がEVIルートごとにイーサネットA-DのNLRI撤回を送信し、これらの撤回がPE3によって伝播および受信されると、PE3はエイリアスルートを削除し、パスリストを更新します。つまり、PE2に対応するパスを削除します。したがって、そのパスリストを指すその<ES、EVI>に対応するすべてのMACルートには、PE1に関連付けられた単一のパスを持つ更新されたパスリストが含まれます。このアクションは、EVIレベルごとの大量撤退と見なすことができます。 EVIごとのレベルでの大量回収は、ESごとのレベルでの大量回収よりも収束時間が長くなります。ただし、撤回がMACごとに行われる場合、収束時間よりもはるかに高速です。
If a PE becomes detached from a given ES, then, in addition to withdrawing its previously advertised Ethernet A-D per ES routes, it MUST also withdraw its previously advertised Ethernet A-D per EVI routes for that ES. For a remote PE that is separated from the withdrawing PE by one or more EVPN inter-AS Option B ASBRs, the withdrawal of the Ethernet A-D per ES routes is not actionable. However, a remote PE is able to correlate a previously advertised Ethernet A-D per EVI route with any MAC/IP Advertisement routes also advertised by the withdrawing PE for that <ES, EVI, BD>. Hence, when it receives the withdrawal of an Ethernet A-D per EVI route, it SHOULD remove the withdrawing PE as a next hop for all MAC addresses associated with that <ES, EVI, BD>.
PEが特定のESから切り離される場合、ESルートごとに以前にアドバタイズされたイーサネットA-Dを撤回することに加えて、そのESのEVIルートごとに以前にアドバタイズされたイーサネットA-Dも撤回する必要があります。 1つ以上のEVPN Inter-ASオプションB ASBRによって撤退するPEから分離されているリモートPEの場合、ESルートごとのイーサネットA-Dの撤回は実行できません。ただし、リモートPEは、EVIルートごとに以前にアドバタイズされたイーサネットA-Dを、その<ES、EVI、BD>の撤退するPEによってアドバタイズされたMAC / IPアドバタイズメントルートと関連付けることができます。したがって、EVIルートごとにイーサネットA-Dの撤回を受信すると、その<ES、EVI、BD>に関連付けられているすべてのMACアドレスのネクストホップとして撤退するPEを削除する必要があります。
In the previous example, when the AC between PE2 and the CE fails, PE2 will withdraw its Ethernet A-D per ES and per EVI routes. When PE3 receives the withdrawal of an Ethernet A-D per EVI route, it removes PE2 as a valid next hop for all MAC addresses associated with the corresponding <ES, EVI, BD>. Therefore, all the MAC next hops for that <ES, EVI, BD> will now have a single next hop, viz. the LSP to PE1.
前の例では、PE2とCEの間のACに障害が発生すると、PE2はESおよびEVIルートごとにイーサネットA-Dを撤回します。 PE3は、EVIルートごとにイーサネットA-Dの撤回を受信すると、対応する<ES、EVI、BD>に関連付けられたすべてのMACアドレスの有効なネクストホップとしてPE2を削除します。したがって、その<ES、EVI、BD>のすべてのMACネクストホップには、単一のネクストホップ、つまり、1つがあります。 PE1へのLSP。
In summary, it can be seen that Aliasing (and Backup Path) functionality should work as is for inter-AS Option B without requiring any additional functionality in ASBRs or PEs. However, the mass withdrawal functionality falls back from per-ES mode to per-EVI mode for inter-AS Option B. That is, PEs receiving a mass withdrawal route from the same AS take action on Ethernet A-D per ES route; whereas, PEs receiving mass withdrawal routes from different ASes take action on the Ethernet A-D per EVI route.
要約すると、エイリアシング（およびバックアップパス）機能は、ASBRまたはPEで追加機能を必要とせずに、AS間オプションBと同様に機能する必要があることがわかります。ただし、AS間オプションBでは、一括撤退機能がES単位モードからEVI単位モードにフォールバックします。つまり、同じASから一括撤退ルートを受信するPEは、ESルートごとにイーサネットA-Dでアクションを実行します。一方、異なるASから大量の撤退ルートを受信するPEは、EVIルートごとにイーサネットA-Dでアクションを実行します。
This document uses IP-based tunnel technologies to support data-plane transport. Consequently, the security considerations of those tunnel technologies apply. This document defines support for VXLAN [RFC7348] and NVGRE encapsulations [RFC7637]. The security considerations from those RFCs apply to the data-plane aspects of this document.
このドキュメントでは、IPベースのトンネルテクノロジーを使用して、データプレーントランスポートをサポートしています。したがって、これらのトンネル技術のセキュリティに関する考慮事項が適用されます。このドキュメントでは、VXLAN [RFC7348]およびNVGREカプセル化[RFC7637]のサポートを定義しています。これらのRFCのセキュリティに関する考慮事項は、このドキュメントのデータプレーンの側面に適用されます。
As with [RFC5512], any modification of the information that is used to form encapsulation headers, to choose a tunnel type, or to choose a particular tunnel for a particular payload type may lead to user data packets getting misrouted, misdelivered, and/or dropped.
[RFC5512]と同様に、カプセル化ヘッダーの形成、トンネルタイプの選択、または特定のペイロードタイプの特定のトンネルの選択に使用される情報の変更により、ユーザーデータパケットの誤ルーティング、誤配信、および/または落とした。
More broadly, the security considerations for the transport of IP reachability information using BGP are discussed in [RFC4271] and [RFC4272] and are equally applicable for the extensions described in this document.
より広義には、BGPを使用したIP到達可能性情報の転送に関するセキュリティの考慮事項は、[RFC4271]と[RFC4272]で説明されており、このドキュメントで説明されている拡張にも同様に適用できます。
This document registers the following in the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry.
このドキュメントでは、「BGPトンネルカプセル化属性のトンネルタイプ」レジストリに以下を登録しています。
Value Name
----- ------------------------
8 VXLAN Encapsulation
9 NVGRE Encapsulation
10 MPLS Encapsulation
11 MPLS in GRE Encapsulation
12 VXLAN GPE Encapsulation
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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>。
[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。、編、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>。
[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. Wright、「Virtual eXtensible Local Area Network（ VXLAN）：A Layer over Overlaying Virtualized Layer 2 Networks over Layer 3 Networks」、RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https://www.rfc-editor.org/info/rfc7348>。
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, <https://www.rfc-editor.org/info/rfc5512>.
[RFC5512] Mohapatra、P。およびE. Rosen、「BGPカプセル化後続アドレスファミリ識別子（SAFI）およびBGPトンネルカプセル化属性」、RFC 5512、DOI 10.17487 / RFC5512、2009年4月、<https：//www.rfc -editor.org/info/rfc5512>。
[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] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<https：/ /www.rfc-editor.org/info/rfc4023>。
[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. Wang編、「NVGRE：Network Virtualization Using Generic Routing Encapsulation」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<https://www.rfc-editor.org/info/rfc7637>。
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>.
[RFC7209] Sajassi、A.、Aggarwal、R.、Uttaro、J.、Bitar、N.、Henderickx、W。、およびA. Isaac、「イーサネットVPN（EVPN）の要件」、RFC 7209、DOI 10.17487 / RFC7209 、2014年5月、<https://www.rfc-editor.org/info/rfc7209>。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.
[RFC4272]マーフィー、S。、「BGPセキュリティ脆弱性分析」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<https://www.rfc-editor.org/info/rfc4272>。
[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>.
[RFC7364] Narten、T.、Ed。、Gray、E.、Ed。、Black、D.、Fang、L.、Kreeger、L。、およびM. Napierala、「Problem Statement：Overlays for Network Virtualization」、RFC 7364、DOI 10.17487 / RFC7364、2014年10月、<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>.
[RFC7365] Lasserre、M.、Balus、F.、Morin、T.、Bitar、N。、およびY. Rekhter、「Framework for Data Center（DC）Network Virtualization」、RFC 7365、DOI 10.17487 / RFC7365、2014年10月、<https://www.rfc-editor.org/info/rfc7365>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、< https://www.rfc-editor.org/info/rfc6514>。
[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>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https://www.rfc-editor.org/info / rfc4364>。
[TUNNEL-ENCAP] Rosen, E., Ed., Patel, K., and G. Velde, "The BGP Tunnel Encapsulation Attribute", Work in Progress draft-ietf-idr-tunnel-encaps-09, February 2018.
[TUNNEL-ENCAP]ローゼン、E。、エド、パテル、K。、およびG.ベルデ、「BGPトンネルカプセル化属性」、Work in Progress、draft-ietf-idr-tunnel-encaps-09、2018年2月
[DCI-EVPN-OVERLAY] Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi, A., and J. Drake, "Interconnect Solution for EVPN Overlay networks", Work in Progress, draft-ietf-bess-dci-evpn-overlay-10, March 2018.
[DCI-EVPN-OVERLAY]ラバダン、J。、エド、サタパン、S。、ヘンダーリック、W、サジャシ、A.、J。ドレイク、「EVPNオーバーレイネットワークの相互接続ソリューション」、作業中、ドラフト- ietf-bess-dci-evpn-overlay-10、2018年3月。
[EVPN-GENEVE] Boutros, S., Sajassi, A., Drake, J., and J. Rabadan, "EVPN control plane for Geneve", Work in Progress, draft-boutros-bess-evpn-geneve-02, March 2018.
[EVPN-GENEVE] Boutros、S.、Sajassi、A.、Drake、J.、J。Rabadan、「GeneveのEVPNコントロールプレーン」、作業中、draft-boutros-bess-evpn-geneve-02、3月2018。
[VXLAN-GPE] Maino, F., Kreeger, L., Ed., and U. Elzur, Ed., "Generic Protocol Extension for VXLAN", Work in Progress, draft-ietf-nvo3-vxlan-gpe-05, October 2017.
[VXLAN-GPE] Maino、F.、Kreeger、L。、編、U。Elzur、編、「VXLAN用のGeneric Protocol Extension」、Work in Progress、draft-ietf-nvo3-vxlan-gpe-05、 2017年10月。
[GENEVE] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-06, March 2018.
[GENEVE] Gross、J.、Ed。、Ganga、I.、Ed。、and T. Sridhar、Ed。、 "Geneve：Generic Network Virtualization Encapsulation"、Work in Progress、draft-ietf-nvo3-geneve-06、 2018年3月。
[IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q.
[IEEE.802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Bridges and Bridged Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q。
Acknowledgements
謝辞
The authors would like to thank Aldrin Isaac, David Smith, John Mullooly, Thomas Nadeau, Samir Thoria, and Jorge Rabadan for their valuable comments and feedback. The authors would also like to thank Jakob Heitz for his contribution on Section 10.2.
著者は、貴重なコメントとフィードバックを提供してくれたAldrin Isaac、David Smith、John Mullooly、Thomas Nadeau、Samir Thoria、およびJorge Rabadanに感謝します。著者はまた、セクション10.2への貢献に対してJakob Heitzに感謝します。
Contributors
貢献者
S. Salam K. Patel D. Rao S. Thoria D. Cai Cisco
S.サラムK.パテルD.ラオS.ソリアD.カイシスコ
Y. Rekhter A. Issac W. Lin N. Sheth Juniper
Y. Rekhter A. Issac W. Lin N. Sheth Juniper
L. Yong Huawei
l。ヨンフーAは
Authors' Addresses
著者のアドレス
Ali Sajassi (editor) Cisco United States of America
Ali Sajassi（編集者）Ciscoアメリカ合衆国
Email: sajassi@cisco.com
John Drake (editor) Juniper Networks United States of America
ジョンドレイク（編集者）ジュニパーネットワークスアメリカ合衆国
Email: jdrake@juniper.net
Nabil Bitar Nokia United States of America
Nabil Bitar Nokiaアメリカ合衆国
Email: nabil.bitar@nokia.com
R. Shekhar Juniper United States of America
R.シェカールジュニパーアメリカ合衆国
Email: rshekhar@juniper.net
James Uttaro AT&T United States of America
James Uttaro AT＆Tアメリカ合衆国
Email: uttaro@att.com
Wim Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium
Wim Henderickx Nokia Copernicuslaan 50 2018アントワープベルギー
Email: wim.henderickx@nokia.com