[要約] RFC 8388は、BGP MPLSベースのEthernet VPNの使用と適用に関するガイドラインです。このRFCの目的は、BGP MPLSベースのEthernet VPNの利点と制約を説明し、その使用方法とアプリケーションに関する指針を提供することです。
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 8388 S. Palislamovic
Category: Informational W. Henderickx
ISSN: 2070-1721 Nokia
A. Sajassi
Cisco
J. Uttaro
AT&T
May 2018
Usage and Applicability of BGP MPLS-Based Ethernet VPN
BGP MPLSベースのイーサネットVPNの使用法と適用性
Abstract
概要
This document discusses the usage and applicability of BGP MPLS-based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.
このドキュメントでは、シンプルでかなり一般的な導入シナリオにおけるBGP MPLSベースのイーサネットVPN（EVPN）の使用法と適用性について説明します。シナリオ例では、さまざまなEVPN手順が、各オプションの利点とトレードオフとともに説明されています。このドキュメントは、EVPNネットワークの展開に関する簡略化されたガイドを提供することを目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8388.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8388で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Case Scenario Description and Requirements . . . . . . . 5
3.1. Service Requirements . . . . . . . . . . . . . . . . . . 5
3.2. Why EVPN Is Chosen to Address This Use Case . . . . . . . 7
4. Provisioning Model . . . . . . . . . . . . . . . . . . . . . 7
4.1. Common Provisioning Tasks . . . . . . . . . . . . . . . . 8
4.1.1. Non-Service-Specific Parameters . . . . . . . . . . . 8
4.1.2. Service-Specific Parameters . . . . . . . . . . . . . 9
4.2. Service-Interface-Dependent Provisioning Tasks . . . . . 9
4.2.1. VLAN-Based Service Interface EVI . . . . . . . . . . 10
4.2.2. VLAN Bundle Service Interface EVI . . . . . . . . . . 10
4.2.3. VLAN-Aware Bundling Service Interface EVI . . . . . . 10
5. BGP EVPN NLRI Usage . . . . . . . . . . . . . . . . . . . . . 11
6. MAC-Based Forwarding Model Use Case . . . . . . . . . . . . . 11
6.1. EVPN Network Startup Procedures . . . . . . . . . . . . . 12
6.2. VLAN-Based Service Procedures . . . . . . . . . . . . . . 12
6.2.1. Service Startup Procedures . . . . . . . . . . . . . 13
6.2.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 13
6.3. VLAN Bundle Service Procedures . . . . . . . . . . . . . 17
6.3.1. Service Startup Procedures . . . . . . . . . . . . . 17
6.3.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 18
6.4. VLAN-Aware Bundling Service Procedures . . . . . . . . . 18
6.4.1. Service Startup Procedures . . . . . . . . . . . . . 18
6.4.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 19
7. MPLS-Based Forwarding Model Use Case . . . . . . . . . . . . 20
7.1. Impact of MPLS-Based Forwarding on the EVPN Network
Startup . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Impact of MPLS-Based Forwarding on the VLAN-Based Service
Procedures . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Impact of MPLS-Based Forwarding on the VLAN Bundle
Service Procedures . . . . . . . . . . . . . . . . . . . 22
7.4. Impact of MPLS-Based Forwarding on the VLAN-Aware Service
Procedures . . . . . . . . . . . . . . . . . . . . . . . 22
8. Comparison between MAC-Based and MPLS-Based Egress Forwarding
Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Traffic Flow Optimization . . . . . . . . . . . . . . . . . . 24
9.1. Control-Plane Procedures . . . . . . . . . . . . . . . . 24
9.1.1. MAC Learning Options . . . . . . . . . . . . . . . . 24
9.1.2. Proxy ARP/ND . . . . . . . . . . . . . . . . . . . . 25
9.1.3. Unknown Unicast Flooding Suppression . . . . . . . . 25
9.1.4. Optimization of Inter-Subnet Forwarding . . . . . . . 26
9.2. Packet Walk-Through Examples . . . . . . . . . . . . . . 27
9.2.1. Proxy ARP Example for CE2-to-CE3 Traffic . . . . . . 27
9.2.2. Flood Suppression Example for CE1-to-CE3 Traffic . . 27
9.2.3. Optimization of Inter-subnet Forwarding Example for
CE3-to-CE2 Traffic . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
This document complements [RFC7432] by discussing the applicability of the technology in a simple and fairly common deployment scenario, which is described in Section 3.
このドキュメントは、セクション3で説明されている、シンプルでかなり一般的な展開シナリオでのテクノロジーの適用性について説明することにより、[RFC7432]を補足しています。
After describing the topology and requirements of the use case scenario, Section 4 will describe the provisioning model.
ユースケースシナリオのトポロジと要件について説明した後、セクション4ではプロビジョニングモデルについて説明します。
Once the provisioning model is analyzed, Sections 5, 6, and 7 will describe the control-plane and data-plane procedures in the example scenario for the two potential disposition/forwarding models: MAC-based and MPLS-based models. While both models can interoperate in the same network, each one has different trade-offs that are analyzed in Section 8.
プロビジョニングモデルを分析したら、セクション5、6、および7で、MACベースモデルとMPLSベースモデルという2つの潜在的なディスポジション/転送モデルのシナリオ例のコントロールプレーンとデータプレーンの手順について説明します。両方のモデルは同じネットワークで相互運用できますが、セクション8で分析したトレードオフはそれぞれ異なります。
Finally, EVPN provides some potential traffic flow optimization tools that are also described in Section 9 in the context of the example scenario.
最後に、EVPNはいくつかの潜在的なトラフィックフロー最適化ツールを提供します。これらは、サンプルシナリオのコンテキストでセクション9でも説明されています。
The following terminology is used:
次の用語が使用されます。
VID: VLAN Identifier
VID：VLAN ID
CE: Customer Edge (device)
CE：カスタマーエッジ（デバイス）
EVI: EVPN Instance
EVI：EVPNインスタンス
MAC-VRF: A Virtual Routing and Forwarding (VRF) table for Media Access Control (MAC) addresses on a Provider Edge (PE) router.
MAC-VRF：プロバイダーエッジ（PE）ルーター上のメディアアクセス制御（MAC）アドレスの仮想ルーティングおよび転送（VRF）テーブル。
ES: An Ethernet Segment is a set of links through which a CE is connected to one or more PEs. Each ES is identified by an Ethernet Segment Identifier (ESI) in the control plane.
ES：イーサネットセグメントは、CEが1つ以上のPEに接続されるリンクのセットです。各ESは、コントロールプレーンのイーサネットセグメント識別子（ESI）によって識別されます。
CE-VIDs: The VLAN Identifier tags being used at CE1, CE2, and CE3 to tag customer traffic sent to the service provider EVPN network.
CE-VID：サービスプロバイダーのEVPNネットワークに送信された顧客トラフィックにタグを付けるためにCE1、CE2、およびCE3で使用されているVLAN IDタグ。
CE1-MAC, CE2-MAC, and CE3-MAC: The source MAC addresses "behind" each CE, respectively. These MAC addresses can belong to the CEs themselves or to devices connected to the CEs.
CE1-MAC、CE2-MAC、およびCE3-MAC：それぞれのCEの「背後」にある送信元MACアドレス。これらのMACアドレスは、CE自体またはCEに接続されたデバイスに属することができます。
CE1-IP, CE2-IP, and CE3-IP: The IP addresses associated with the above MAC addresses
CE1-IP、CE2-IP、およびCE3-IP：上記のMACアドレスに関連付けられたIPアドレス
LACP: Link Aggregation Control Protocol
LACP：リンク集約制御プロトコル
RD: Route Distinguisher
RD：ルート識別子
RT: Route Target
RT：ルートターゲット
PE: Provider Edge (router)
PE：プロバイダーエッジ（ルーター）
AS: Autonomous System
AS：自律システム
PE-IP: The IP address of a given PE
PE-IP：特定のPEのIPアドレス
Figure 1 depicts the scenario that will be referenced throughout the rest of the document.
図1は、ドキュメントの残りの部分で参照されるシナリオを示しています。
+--------------+
| |
+----+ +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE3|
+----+ /| PE1| | IP/MPLS | | PE3| +----+
/ +----+ | Network | +----+
/ | |
/ +----+ | |
+----+/ | | | |
| CE2|-----| PE2| | |
+----+ +----+ | |
+--------------+
Figure 1: EVPN Use Case Scenario
図1：EVPNユースケースシナリオ
There are three PEs and three CEs considered in this example: PE1, PE2, and PE3, as well as CE1, CE2, and CE3. Broadcast domains must be extended among the three CEs.
この例では、PE1、PE2、PE3、およびCE1、CE2、CE3の3つのPEと3つのCEが検討されています。ブロードキャストドメインは、3つのCE間で拡張する必要があります。
The following service requirements are assumed in this scenario:
このシナリオでは、次のサービス要件が想定されています。
o Redundancy requirements:
o 冗長性の要件：
- CE2 requires multihoming connectivity to PE1 and PE2, not only for redundancy purposes but also for adding more upstream/ downstream connectivity bandwidth to/from the network.
- CE2は、冗長性の目的だけでなく、ネットワークへの/からのアップストリーム/ダウンストリーム接続帯域幅を追加するためにも、PE1およびPE2へのマルチホーミング接続を必要とします。
- Fast convergence. For example, if the link between CE2 and PE1 goes down, a fast convergence mechanism must be supported so that PE3 can immediately send the traffic to PE2, irrespective of the number of affected services and MAC addresses.
- 高速収束。たとえば、CE2とPE1の間のリンクがダウンした場合、影響を受けるサービスとMACアドレスの数に関係なく、PE3がトラフィックをPE2にすぐに送信できるように、高速コンバージェンスメカニズムをサポートする必要があります。
o Service interface requirements:
o サービスインターフェイスの要件：
- The service definition must be flexible in terms of CE-VID-to-broadcast-domain assignment in the core.
- サービス定義は、コアでのCE-VIDからブロードキャストドメインへの割り当てに関して柔軟でなければなりません。
- The following three EVI services are required in this example:
- この例では、次の3つのEVIサービスが必要です。
EVI100 uses VLAN-based service interfaces in the three CEs with a 1:1 VLAN-to-EVI mapping. The CE-VIDs at the three CEs can be the same (for example, VID 100) or different at each CE (for instance, VID 101 in CE1, VID 102 in CE2, and VID 103 in CE3). A single broadcast domain needs to be created for EVI100 in any case; therefore, CE-VIDs will require translation at the egress PEs if they are not consistent across the three CEs. The case when the same CE-VID is used across the three CEs for EVI100 is referred to in [RFC7432] as the "Unique VLAN" EVPN case. This term will be used throughout this document too.
EVI100は、3つのCEでVLANベースのサービスインターフェイスを使用し、1：1のVLANからEVIへのマッピングを行います。 3つのCEのCE-VIDは同じ（たとえば、VID 100）でも、各CEで異なっていてもかまいません（たとえば、CE1のVID 101、CE2のVID 102、CE3のVID 103）。いずれの場合も、EVI100用に単一のブロードキャストドメインを作成する必要があります。したがって、3つのCE間で一貫性がない場合、CE-VIDは出力PEで変換が必要になります。 EVI100の3つのCEで同じCE-VIDが使用されるケースは、[RFC7432]で「ユニークなVLAN」EVPNケースと呼ばれています。この用語は、このドキュメント全体でも使用されます。
EVI200 uses VLAN bundle service interfaces in CE1, CE2, and CE3 based on an N:1 VLAN-to-EVI mapping. The operator needs to preconfigure a range of CE-VIDs and its mapping to the EVI, and this mapping should be consistent in all the PEs (no translation is supported). A single broadcast domain is created for the customer. The customer is responsible for keeping the separation between users in different CE-VIDs.
EVI200は、N：1 VLANからEVIへのマッピングに基づいて、CE1、CE2、およびCE3のVLANバンドルサービスインターフェイスを使用します。オペレーターは、CE-VIDの範囲とそのEVIへのマッピングを事前構成する必要があり、このマッピングはすべてのPEで一貫している必要があります（変換はサポートされていません）。顧客用に単一のブロードキャストドメインが作成されます。顧客は、異なるCE-VIDのユーザー間の分離を維持する責任があります。
EVI300 uses VLAN-aware bundling service interfaces in CE1, CE2, and CE3. As in the EVI200 case, an N:1 VLAN-to-EVI mapping is created at the ingress PEs; however, in this case, a separate broadcast domain is required per CE-VID. The CE-VIDs can be different (hence, CE-VID translation is required).
EVI300は、CE1、CE2、およびCE3のVLAN対応バンドルサービスインターフェイスを使用します。 EVI200の場合と同様に、N：1 VLANからEVIへのマッピングが入力PEで作成されます。ただし、この場合、CE-VIDごとに個別のブロードキャストドメインが必要です。 CE-VIDは異なる場合があります（したがって、CE-VID変換が必要です）。
Note that in Section 4.2.1, only EVI100 is used as an example of VLAN-based service provisioning. In Sections 6.2 and 7.2, 4k VLAN-based EVIs (EVI1 to EVI4k) are used so that the impact of MAC versus MPLS disposition models in the control plane can be evaluated. In the same way, EVI200 and EVI300 will be described with a 4k:1 mapping (CE-VIDs-to-EVI mapping) in Sections 6.3, 6.4, 7.3, and 7.4.
セクション4.2.1では、VLANベースのサービスプロビジョニングの例としてEVI100のみが使用されていることに注意してください。セクション6.2および7.2では、4k VLANベースのEVI（EVI1〜EVI4k）が使用されているため、コントロールプレーンにおけるMACとMPLSの配置モデルの影響を評価できます。同様に、セクション6.3、6.4、7.3、および7.4では、EVI200およびEVI300を4k：1マッピング（CE-VIDからEVIへのマッピング）で説明します。
o Broadcast, Unknown Unicast, Multicast (BUM) optimization requirements:
o ブロードキャスト、不明なユニキャスト、マルチキャスト（BUM）の最適化要件：
- The solution must support ingress replication or P2MP MPLS LSPs on a per EVI service. For example, we can use ingress replication for EVI100 and EVI200, assuming those EVIs will not carry much BUM traffic. On the contrary, if EVI300 is presumably carrying a significant amount of multicast traffic, P2MP MPLS LSPs can be used for this service.
- ソリューションは、EVIサービスごとに入力レプリケーションまたはP2MP MPLS LSPをサポートする必要があります。たとえば、EVI100とEVI200に入力レプリケーションを使用できます。これらのEVIはBUMトラフィックをあまり伝送しないと想定しています。逆に、EVI300がかなりの量のマルチキャストトラフィックを伝送していると思われる場合は、このサービスにP2MP MPLS LSPを使用できます。
- The benefit of ingress replication compared to P2MP LSPs is that the core routers will not need to maintain any multicast states.
- P2MP LSPと比較した入力レプリケーションの利点は、コアルーターがマルチキャスト状態を維持する必要がないことです。
Virtual Private LAN Service (VPLS) solutions based on [RFC4761], [RFC4762], and [RFC6074] cannot meet the requirements in Section 3, whereas EVPN can.
[RFC4761]、[RFC4762]、および[RFC6074]に基づく仮想プライベートLANサービス（VPLS）ソリューションは、セクション3の要件を満たすことができませんが、EVPNはできます。
For example:
例えば：
o If CE2 has a single CE-VID (or a few CE-VIDs), the current VPLS multihoming solutions (based on load-balancing per CE-VID or service) do not provide the optimized link utilization required in this example. EVPN provides the flow-based, load-balancing, multihoming solution required in this scenario to optimize the upstream/downstream link utilization between CE2 and PE1-PE2.
o CE2に単一のCE-VID（またはいくつかのCE-VID）がある場合、現在のVPLSマルチホーミングソリューション（CE-VIDまたはサービスごとのロードバランシングに基づく）は、この例に必要な最適化されたリンク使用率を提供しません。 EVPNは、CE2とPE1-PE2間のアップストリーム/ダウンストリームリンク使用率を最適化するために、このシナリオで必要なフローベースのロードバランシングマルチホーミングソリューションを提供します。
o EVPN provides a fast convergence solution that is independent of the CE-VIDs in the multihomed PEs. Upon failure on the link between CE2 and PE1, PE3 can immediately send the traffic to PE2 based on a single notification message being sent by PE1. This is not possible with VPLS solutions.
o EVPNは、マルチホームPEのCE-VIDから独立した高速コンバージェンスソリューションを提供します。 CE2とPE1の間のリンクで障害が発生すると、PE3は、PE1によって送信されている単一の通知メッセージに基づいて、トラフィックをPE2にすぐに送信できます。これはVPLSソリューションでは不可能です。
o With regard to service interfaces and mapping to broadcast domains, while VPLS might meet the requirements for EVI100 and EVI200, the VLAN-aware bundling service interfaces required by EVI300 are not supported by the current VPLS tools.
o サービスインターフェイスとブロードキャストドメインへのマッピングに関して、VPLSはEVI100およびEVI200の要件を満たす可能性がありますが、EVI300に必要なVLAN対応のバンドルサービスインターフェイスは、現在のVPLSツールではサポートされていません。
The rest of the document will describe how EVPN can be used to meet the service requirements described in Section 3 and even optimize the network further by:
ドキュメントの残りの部分では、EVPNを使用してセクション3で説明したサービス要件を満たし、さらにネットワークをさらに最適化する方法について説明します。
o providing the user with an option to reduce (and even suppress) ARP (Address Resolution Protocol) flooding; and
o ARP（アドレス解決プロトコル）フラッディングを削減（さらには抑制）するオプションをユーザーに提供します。そして
o supporting ARP termination and inter-subnet forwarding.
o ARP終端とサブネット間転送をサポートします。
One of the requirements stated in [RFC7209] is the ease of provisioning. BGP parameters and service context parameters should be auto-provisioned so that the addition of a new MAC-VRF to the EVI requires a minimum number of single-sided provisioning touches. However, this is possible only in a limited number of cases. This section describes the provisioning tasks required for the services described in Section 3, i.e., EVI100 (VLAN-based service interfaces), EVI200 (VLAN bundle service interfaces), and EVI300 (VLAN-aware bundling service interfaces).
[RFC7209]で述べられている要件の1つは、プロビジョニングの容易さです。 BGPパラメータとサービスコンテキストパラメータを自動プロビジョニングして、新しいMAC-VRFをEVIに追加するために必要な片側プロビジョニングタッチの数を最小限にする必要があります。ただし、これは限られた数の場合にのみ可能です。このセクションでは、セクション3で説明したサービスに必要なプロビジョニングタスクについて説明します。つまり、EVI100（VLANベースのサービスインターフェイス）、EVI200（VLANバンドルサービスインターフェイス）、およびEVI300（VLAN対応のバンドルサービスインターフェイス）
Regardless of the service interface type (VLAN-based, VLAN bundle, or VLAN-aware), the following subsections describe the parameters to be provisioned in the three PEs.
次のサブセクションでは、サービスインターフェイスタイプ（VLANベース、VLANバンドル、またはVLAN対応）に関係なく、3つのPEでプロビジョニングされるパラメータについて説明します。
The multihoming function in EVPN requires the provisioning of certain parameters that are not service specific and that are shared by all the MAC-VRFs in the node using the multihoming capabilities. In our use case, these parameters are only provisioned or auto-derived in PE1 and PE2 and are listed below:
EVPNのマルチホーミング機能では、サービス固有ではなく、マルチホーミング機能を使用してノード内のすべてのMAC-VRFによって共有される特定のパラメーターのプロビジョニングが必要です。私たちのユースケースでは、これらのパラメーターはPE1およびPE2でのみプロビジョニングまたは自動生成され、以下にリストされています。
o Ethernet Segment Identifier (ESI): Only the ESI associated with CE2 needs to be considered in our example. Single-homed CEs such as CE1 and CE3 do not require the provisioning of an ESI (the ESI will be coded as zero in the BGP Network Layer Reachability Information (NLRI)). In our example, a Link Aggregation Group (LAG) is used between CE2 and PE1-PE2 (since all-active multihoming is a requirement); therefore, the ESI can be auto-derived from the LACP information as described in [RFC7432]. Note that the ESI must be unique across all the PEs in the network; therefore, the auto-provisioning of the ESI is recommended only in case the CEs are managed by the operator. Otherwise, the ESI should be manually provisioned (Type 0, as in [RFC7432]) in order to avoid potential conflicts.
o イーサネットセグメント識別子（ESI）：この例では、CE2に関連付けられたESIのみを考慮する必要があります。 CE1やCE3などのシングルホームCEは、ESIのプロビジョニングを必要としません（ESIは、BGPネットワーク層到達可能性情報（NLRI）でゼロとしてコード化されます）。この例では、CE2とPE1-PE2の間でリンク集約グループ（LAG）が使用されています（オールアクティブマルチホーミングが要件であるため）。したがって、[RFC7432]で説明されているように、ESIはLACP情報から自動派生できます。 ESIはネットワーク内のすべてのPEで一意である必要があることに注意してください。したがって、ESIの自動プロビジョニングは、CEがオペレーターによって管理されている場合にのみ推奨されます。それ以外の場合は、潜在的な競合を回避するために、ESIを手動でプロビジョニングする必要があります（[RFC7432]のようにタイプ0）。
o ES-Import Route Target (ES-Import RT): This is the RT that will be sent by PE1 and PE2, along with the ES route. Regardless of how the ESI is provisioned in PE1 and PE2, the ES-Import RT must always be auto-derived from the 6-byte MAC address portion of the ESI value.
o ESインポートルートターゲット（ESインポートRT）：これは、ESルートとともにPE1およびPE2によって送信されるRTです。 ESIがPE1およびPE2でプロビジョニングされる方法に関係なく、ES-Import RTは常に、ESI値の6バイトのMACアドレス部分から自動的に派生する必要があります。
o Ethernet Segment Route Distinguisher (ES RD): This is the RD to be encoded in the ES route, and it is the Ethernet Auto-Discovery (A-D) route to be sent by PE1 and PE2 for the CE2 ESI. This RD should always be auto-derived from the PE-IP address, as described in [RFC7432].
o イーサネットセグメントルート識別子（ES RD）：これはESルートでエンコードされるRDであり、CE2 ESIのPE1およびPE2によって送信されるイーサネット自動検出（A-D）ルートです。 [RFC7432]で説明されているように、このRDは常にPE-IPアドレスから自動派生する必要があります。
o Multihoming type: The user must be able to provision the multihoming type to be used in the network. In our use case, the multihoming type will be set to all-active for the CE2 ESI. This piece of information is encoded in the ESI Label extended community flags and is sent by PE1 and PE2 along with the Ethernet A-D route for the CE2 ESI.
o マルチホーミングタイプ：ユーザーは、ネットワークで使用されるマルチホーミングタイプをプロビジョニングできる必要があります。この使用例では、CE2 ESIのマルチホーミングタイプがall-activeに設定されます。この情報は、ESIラベルの拡張コミュニティフラグにエンコードされ、CE2 ESIのイーサネットA-DルートとともにPE1およびPE2によって送信されます。
In addition, the same LACP parameters will be configured in PE1 and PE2 for the ES so that CE2 can send frames to PE1 and PE2 as though they were forming a single system.
さらに、ESのPE1とPE2で同じLACPパラメータが設定され、CE2がPE1とPE2にフレームを送信して、まるでそれらが単一のシステムを形成しているかのようになります。
The following parameters must be provisioned in PE1, PE2, and PE3 per EVI service:
次のパラメータは、EVIサービスごとにPE1、PE2、およびPE3でプロビジョニングする必要があります。
o EVI Identifier: The global identifier per EVI that is shared by all the PEs that are part of the EVI, i.e., PE1, PE2, and PE3 will be provisioned with EVI100, 200, and 300. The EVI identifier can be associated with (or be the same value as) the EVI default Ethernet Tag (4-byte default broadcast domain identifier for the EVI). The Ethernet Tag is different from zero in the EVPN BGP routes only if the service interface type (of the source PE) is a VLAN-aware bundle.
o EVI識別子：EVIの一部であるすべてのPEによって共有されるEVIごとのグローバル識別子、つまり、PE1、PE2、およびPE3は、EVI100、200、および300でプロビジョニングされます。EVI識別子は、（またはEVIのデフォルトのイーサネットタグ（EVIの4バイトのデフォルトのブロードキャストドメイン識別子）と同じ値。 （ソースPEの）サービスインターフェイスタイプがVLAN対応バンドルである場合にのみ、EVPN BGPルートのイーサネットタグがゼロと異なります。
o EVI Route Distinguisher (EVI RD): This RD is a unique value across all the MAC-VRFs in a PE. Auto-derivation of this RD might be possible depending on the service interface type being used in the EVI. The next section discusses the specifics of each service interface type.
o EVI Route Distinguisher（EVI RD）：このRDは、PE内のすべてのMAC-VRF全体で一意の値です。 EVIで使用されているサービスインターフェイスタイプによっては、このRDの自動派生が可能になる場合があります。次のセクションでは、各サービスインターフェイスタイプの詳細について説明します。
o EVI Route Target(s) (EVI RT): One or more RTs can be provisioned per MAC-VRF. The RT(s) imported and exported can be equal or different, just as the RT(s) in IP-VPNs. Auto-derivation of this RT(s) might be possible depending on the service interface type being used in the EVI. The next section discusses the specifics of each service interface type.
o EVIルートターゲット（EVI RT）：MAC-VRFごとに1つ以上のRTをプロビジョニングできます。インポートおよびエクスポートされるRTは、IP-VPNのRTと同様に、同じでも異なっていてもかまいません。 EVIで使用されているサービスインターフェイスタイプによっては、このRTの自動派生が可能になる場合があります。次のセクションでは、各サービスインターフェイスタイプの詳細について説明します。
o CE-VID and port/LAG binding to EVI identifier or Ethernet Tag: For more information, please see Section 4.2.
o EVI識別子またはイーサネットタグへのCE-VIDおよびポート/ LAGバインディング：詳細については、セクション4.2を参照してください。
Depending on the service interface type being used in the EVI, a given CE-VID binding provision must be specified.
EVIで使用されているサービスインターフェイスタイプに応じて、所定のCE-VIDバインディングプロビジョンを指定する必要があります。
In our use case, EVI100 is a VLAN-based service interface EVI.
このユースケースでは、EVI100はVLANベースのサービスインターフェイスEVIです。
EVI100 can be a "unique-VLAN" service if the CE-VID being used for this service in CE1, CE2, and CE3 is identical (for example, VID 100). In that case, the VID 100 binding must be provisioned in PE1, PE2, and PE3 for EVI100 and the associated port or LAG. The MAC-VRF RD and RT can be auto-derived from the CE-VID:
EVI100は、CE1、CE2、およびCE3でこのサービスに使用されているCE-VIDが同一である場合（「VID 100」など）、「一意のVLAN」サービスになることができます。その場合、VID 100バインディングは、EVI100および関連するポートまたはLAGのPE1、PE2、およびPE3でプロビジョニングする必要があります。 MAC-VRF RDおよびRTは、CE-VIDから自動派生できます。
o The auto-derived MAC-VRF RD will be a Type 1 RD, as recommended in [RFC7432], and it will be comprised of [PE-IP]:[zero-padded-VID]; where [PE-IP] is the IP address of the PE (a loopback address) and [zero-padded-VID] is a 2-byte value where the low-order 12 bits are the VID (VID 100 in our example) and the high-order 4 bits are zero.
o [RFC7432]で推奨されているように、自動派生MAC-VRF RDはタイプ1 RDであり、[PE-IP]：[zero-padded-VID]で構成されます。ここで、[PE-IP]はPE（ループバックアドレス）のIPアドレスであり、[zero-padded-VID]は2バイト値で、下位12ビットはVID（この例ではVID 100）であり、上位4ビットはゼロです。
o The auto-derived MAC-VRF RT will be composed of [AS]:[zero-padded-VID]; where [AS] is the Autonomous System that the PE belongs to and [zero-padded-VID] is a 2- or 4-byte value where the low-order 12 bits are the VID (VID 100 in our example) and the high-order bits are zero. Note that auto-deriving the RT implies supporting a basic any-to-any topology in the EVI and using the same import and export RT in the EVI.
o 自動派生MAC-VRF RTは、[AS]：[zero-padded-VID]で構成されます。ここで、[AS]はPEが属する自律システムであり、[zero-padded-VID]は2または4バイトの値で、下位12ビットはVID（この例ではVID 100）と高-orderビットはゼロです。 RTの自動派生は、EVIで基本的な多対多トポロジーをサポートし、EVIで同じインポートおよびエクスポートRTを使用することを意味することに注意してください。
If EVI100 is not a "unique-VLAN" instance, each individual CE-VID must be configured in each PE, and MAC-VRF RDs and RTs cannot be auto-derived; hence, they must be provisioned by the user.
EVI100が「固有のVLAN」インスタンスではない場合、個々のCE-VIDを各PEで構成する必要があり、MAC-VRF RDおよびRTは自動派生できません。したがって、ユーザーがプロビジョニングする必要があります。
Assuming EVI200 is a VLAN bundle service interface EVI, and VIDs 200-250 are assigned to EVI200, the CE-VID bundle 200-250 must be provisioned on PE1, PE2, and PE3. Note that this model does not allow CE-VID translation and the CEs must use the same CE-VIDs for EVI200. No auto-derived EVI RDs or EVI RTs are possible.
EVI200がVLANバンドルサービスインターフェイスEVIであり、VID 200〜250がEVI200に割り当てられている場合、CE-VIDバンドル200〜250はPE1、PE2、およびPE3でプロビジョニングする必要があります。このモデルではCE-VID変換が許可されておらず、CEはEVI200に対して同じCE-VIDを使用する必要があることに注意してください。自動派生EVI RDまたはEVI RTは使用できません。
If EVI300 is a VLAN-aware bundling service interface EVI, CE-VID binding to EVI300 does not have to match on the three PEs (only on PE1 and PE2, since they are part of the same ES). For example, PE1 and PE2 CE-VID binding to EVI300 can be set to the range 300-310 and PE3 to 321-330. Note that each individual CE-VID will be assigned to a different broadcast domain, which will be represented by an Ethernet Tag in the control plane.
EVI300がVLAN対応のバンドルサービスインターフェイスEVIである場合、EVI300へのCE-VIDバインディングは3つのPEで一致する必要はありません（同じESの一部であるため、PE1とPE2でのみ）。たとえば、EVI300へのPE1およびPE2 CE-VIDバインディングは、300〜310およびPE3〜321-330の範囲に設定できます。個々のCE-VIDはそれぞれ異なるブロードキャストドメインに割り当てられることに注意してください。これは、コントロールプレーンのイーサネットタグで表されます。
Therefore, besides the CE-VID bundle range bound to EVI300 in each PE, associations between each individual CE-VID and the corresponding EVPN Ethernet Tag must be provisioned by the user. No auto-derived EVI RDs/RTs are possible.
したがって、各PEのEVI300にバインドされたCE-VIDバンドル範囲に加えて、個々のCE-VIDと対応するEVPNイーサネットタグ間の関連付けをユーザーがプロビジョニングする必要があります。自動派生EVI RD / RTは使用できません。
[RFC7432] defines four different route types and four different extended communities. However, not all the PEs in an EVPN network must generate and process all the different routes and extended communities. Table 1 shows the routes that must be exported and imported in the use case described in this document. "Export", in this context, means that the PE must be capable of generating and exporting a given route, assuming there are no BGP policies to prevent it. In the same way, "Import" means the PE must be capable of importing and processing a given route, assuming the right RTs and policies. "N/A" means neither import nor export actions are required.
[RFC7432]は、4つの異なるルートタイプと4つの異なる拡張コミュニティを定義しています。ただし、EVPNネットワーク内のすべてのPEがすべての異なるルートおよび拡張コミュニティを生成および処理する必要があるわけではありません。表1は、このドキュメントで説明するユースケースでエクスポートおよびインポートする必要があるルートを示しています。この文脈での「エクスポート」とは、PEが特定のルートを生成およびエクスポートできる必要があることを意味します。これを防ぐためのBGPポリシーがないことを前提とします。同様に、「インポート」は、適切なRTとポリシーを前提として、PEが特定のルートをインポートおよび処理できる必要があることを意味します。 「N / A」は、インポートアクションもエクスポートアクションも必要ないことを意味します。
+-----------------+---------------+---------------+
| BGP EVPN Routes | PE1-PE2 | PE3 |
+-----------------+---------------+---------------+
| ES | Export/Import | N/A |
| A-D per ESI | Export/Import | Import |
| A-D per EVI | Export/Import | Import |
| MAC | Export/Import | Export/Import |
| Inclusive Mcast | Export/Import | Export/Import |
+-----------------+---------------+---------------+
Table 1: Base EVPN Routes and Export/Import Actions
表1：ベースEVPNルートとエクスポート/インポートアクション
PE3 is required to export only MAC and Inclusive Multicast (Mcast) routes and be able to import and process A-D routes as well as MAC and Inclusive Multicast routes. If PE3 did not support importing and processing A-D routes per ESI and per EVI, fast convergence and aliasing functions (respectively) would not be possible in this use case.
PE3は、MACおよび包括的マルチキャスト（Mcast）ルートのみをエクスポートし、A-DルートおよびMACおよび包括的マルチキャストルートをインポートして処理できる必要があります。 PE3がESIごとおよびEVIごとのA-Dルートのインポートおよび処理をサポートしていなかった場合、このユースケースでは（それぞれ）高速なコンバージェンスおよびエイリアシング機能は不可能です。
This section describes how the BGP EVPN routes are exported and imported by the PEs in our use case as well as how traffic is forwarded assuming that PE1, PE2, and PE3 support a MAC-based forwarding model. In order to compare the control- and data-plane impact in the two forwarding models (MAC-based and MPLS-based) and different service types, we will assume that CE1, CE2, and CE3 need to exchange traffic for up to 4k CE-VIDs.
このセクションでは、ユースケースでBGP EVPNルートがPEによってエクスポートおよびインポートされる方法と、PE1、PE2、およびPE3がMACベースの転送モデルをサポートしていると想定してトラフィックが転送される方法について説明します。 2つの転送モデル（MACベースとMPLSベース）と異なるサービスタイプでのコントロールプレーンとデータプレーンの影響を比較するために、CE1、CE2、およびCE3は最大4k CEのトラフィックを交換する必要があると想定します。 -VID。
Before any EVI is provisioned in the network, the following procedures are required:
ネットワークでEVIをプロビジョニングする前に、次の手順が必要です。
o Infrastructure setup: The proper MPLS infrastructure must be set up among PE1, PE2, and PE3 so that the EVPN services can make use of Point-to-Point (P2P) and P2MP LSPs. In addition to the MPLS transport, PE1 and PE2 must be properly configured with the same LACP configuration to CE2. Details are provided in [RFC7432]. Once the LAG is properly set up, the ESI for the CE2 Ethernet Segment (for example, ESI12) can be auto-generated by PE1 and PE2 from the LACP information exchanged with CE2 (ESI Type 1), as discussed in Section 4.1. Alternatively, the ESI can also be manually provisioned on PE1 and PE2 (ESI Type 0). PE1 and PE2 will auto-configure a BGP policy that will import any ES route matching the auto-derived ES-Import RT for ESI12.
o インフラストラクチャのセットアップ：EVPNサービスがポイントツーポイント（P2P）およびP2MP LSPを利用できるように、PE1、PE2、およびPE3の間に適切なMPLSインフラストラクチャをセットアップする必要があります。 MPLSトランスポートに加えて、PE1とPE2はCE2と同じLACP構成で適切に構成する必要があります。詳細は[RFC7432]で提供されています。 LAGが適切にセットアップされると、CE2イーサネットセグメント（ESI12など）のESIは、セクション4.1で説明したように、CE2（ESIタイプ1）と交換されるLACP情報からPE1およびPE2によって自動生成できます。または、PE1およびPE2（ESIタイプ0）でESIを手動でプロビジョニングすることもできます。 PE1とPE2は、ESI12の自動派生ESインポートRTに一致するESルートをインポートするBGPポリシーを自動構成します。
o Ethernet Segment route exchange and Designated Forwarder (DF) election: PE1 and PE2 will advertise a BGP Ethernet Segment route for ESI12, where the ESI RD and ES-Import RT will be auto-generated as discussed in Section 4.1.1. PE1 and PE2 will import the ES routes of each other and will run the DF election algorithm for any existing EVI (if any, at this point). PE3 will simply discard the route. Note that the DF election algorithm can support service carving so that the downstream BUM traffic from the network to CE2 can be load-balanced across PE1 and PE2 on a per-service basis.
o イーサネットセグメントルート交換および指定フォワーダー（DF）の選択：PE1およびPE2は、ESI12のBGPイーサネットセグメントルートをアドバタイズします。ここで、セクション4.1.1で説明されているように、ESI RDおよびESインポートRTが自動生成されます。 PE1とPE2は互いのESルートをインポートし、既存のEVIがある場合はこの時点でDF選出アルゴリズムを実行します。 PE3は単にルートを破棄します。 DF選出アルゴリズムはサービスカービングをサポートできるため、ネットワークからCE2へのダウンストリームBUMトラフィックを、サービスごとにPE1とPE2間で負荷分散できます。
At the end of this process, the network infrastructure is ready to start deploying EVPN services. PE1 and PE2 are aware of the existence of a shared Ethernet Segment, i.e., ESI12.
このプロセスの最後に、ネットワークインフラストラクチャはEVPNサービスの展開を開始する準備ができています。 PE1とPE2は、共有イーサネットセグメント、つまりESI12の存在を認識しています。
Assuming that the EVPN network must carry traffic among CE1, CE2, and CE3 for up to 4k CE-VIDs, the service provider can decide to implement VLAN-based service interface EVIs to accomplish it. In this case, each CE-VID will be individually mapped to a different EVI. While this means a total number of 4k MAC-VRFs are required per PE, the advantages of this approach are the auto-provisioning of most of the service parameters if no VLAN translation is needed (see Section 4.2.1) and great control over each individual customer broadcast domain. We assume in this section that the range of EVIs from 1 to 4k is provisioned in the network.
EVPNネットワークがCE1、CE2、およびCE3間で最大4kのCE-VIDのトラフィックを伝送する必要があると仮定すると、サービスプロバイダーは、VLANベースのサービスインターフェイスEVIを実装してそれを実現することを決定できます。この場合、各CE-VIDは個別に異なるEVIにマッピングされます。これは、PEごとに合計4kのMAC-VRFが必要であることを意味しますが、このアプローチの利点は、VLAN変換が必要ない場合（セクション4.2.1を参照）のほとんどのサービスパラメーターの自動プロビジョニングと、それぞれに対する優れた制御です。個々の顧客のブロードキャストドメイン。このセクションでは、1〜4kの範囲のEVIがネットワークにプロビジョニングされていると想定しています。
As soon as the EVIs are created in PE1, PE2, and PE3, the following control-plane actions are carried out:
EVIがPE1、PE2、およびPE3で作成されるとすぐに、次のコントロールプレーンアクションが実行されます。
o Flooding tree setup per EVI (4k routes): Each PE will send one Inclusive Multicast Ethernet Tag route per EVI (up to 4k routes per PE) so that the flooding tree per EVI can be set up. Note that ingress replication or P2MP LSPs can be optionally signaled in the Provider Multicast Service Interface (PMSI) Tunnel attribute and the corresponding tree can be created.
o EVIごとのフラッディングツリーのセットアップ（4kルート）：各PEは、EVIごとに1つの包括的マルチキャストイーサネットタグルート（PEごとに最大4kルート）を送信するため、EVIごとのフラッディングツリーをセットアップできます。入力レプリケーションまたはP2MP LSPは、オプションでプロバイダーマルチキャストサービスインターフェイス（PMSI）トンネル属性で通知でき、対応するツリーを作成できることに注意してください。
o Ethernet A-D routes per ESI (a set of routes for ESI12): A set of A-D routes with a total list of 4k RTs (one per EVI) for ESI12 will be issued from PE1 and PE2 (it has to be a set of routes so that the total number of RTs can be conveyed). As per [RFC7432], each Ethernet A-D route per ESI is differentiated from the other routes in the set by a different Route Distinguisher (ES RD). This set will also include ESI Label extended communities with the active-standby flag set to zero (all-active multihoming type) and an ESI Label different from zero (used for split-horizon functions). These routes will be imported by the three PEs, since the RTs match the locally configured EVI RTs. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as discussed in [RFC7432].
o ESIごとのイーサネットADルート（ESI12のルートのセット）：ESI12の4k RT（EVIごとに1つ）の合計リストを持つADルートのセットは、PE1およびPE2から発行されます（ルートのセットである必要があります） RTの総数を伝えることができること）。 [RFC7432]のとおり、ESIごとの各イーサネットA-Dルートは、異なるルート識別子（ES RD）によってセット内の他のルートと区別されます。このセットには、アクティブスタンバイフラグがゼロ（全アクティブマルチホーミングタイプ）に設定されたESIラベル拡張コミュニティと、ゼロ以外のESIラベル（スプリットホライズン機能に使用）も含まれます。 RTはローカルに構成されたEVI RTと一致するため、これらのルートは3つのPEによってインポートされます。 [RFC7432]で説明されているように、ESIごとのA-Dルートは高速収束とスプリットホライズン機能に使用されます。
o Ethernet A-D routes per EVI (4k routes): An A-D route per EVI will be sent by PE1 and PE2 for ESI12. Each individual route includes the corresponding EVI RT and an MPLS Label to be used by PE3 for the aliasing function. These routes will be imported by the three PEs.
o EVIごとのイーサネットA-Dルート（4kルート）：EVIごとのA-Dルートは、ESI12のPE1およびPE2によって送信されます。個々のルートには、対応するEVI RTと、エイリアシング機能のためにPE3が使用するMPLSラベルが含まれています。これらのルートは、3つのPEによってインポートされます。
Once the services are set up, the traffic can start flowing. Assuming there are no MAC addresses learned yet and that MAC learning at the access is performed in the data plane in our use case, this is the process followed upon receiving frames from each CE (for example, EVI1).
サービスが設定されると、トラフィックが流れ始めることができます。学習されたMACアドレスがまだなく、アクセスケースでのMAC学習がデータプレーンで実行されているとすると、これは、各CE（たとえば、EVI1）からフレームを受信したときに実行されるプロセスです。
BUM frame example from CE1:
CE1からのBUMフレームの例：
a. An ARP request with CE-VID=1 is issued from source MAC CE1-MAC (MAC address coming from CE1 or from a device connected to CE1) to find the MAC address of CE3-IP.
a. CE-VID = 1のARP要求は、ソースMAC CE1-MAC（CE1またはCE1に接続されたデバイスからのMACアドレス）から発行され、CE3-IPのMACアドレスを検索します。
b. Based on the CE-VID, the frame is identified to be forwarded in the MAC-VRF-1 (EVI1) context. A source MAC lookup is done in the MAC FIB, and the sender's CE1-IP is looked up in the proxy ARP table within the MAC-VRF-1 (EVI1) context. If CE1-MAC/CE1-IP are unknown in both tables, three actions are carried out (assuming the source MAC is accepted by PE1):
b. CE-VIDに基づいて、MAC-VRF-1（EVI1）コンテキストで転送されるフレームが識別されます。送信元MAC検索はMAC FIBで実行され、送信者のCE1-IPはMAC-VRF-1（EVI1）コンテキスト内のプロキシARPテーブルで検索されます。両方のテーブルでCE1-MAC / CE1-IPが不明の場合、3つのアクションが実行されます（ソースMACがPE1によって受け入れられていると想定）。
1. the forwarding state is added for the CE1-MAC associated with the corresponding port and CE-VID;
1. 転送状態は、対応するポートとCE-VIDに関連付けられたCE1-MACに追加されます。
2. the ARP request is snooped and the tuple CE1-MAC/CE1-IP is added to the proxy ARP table; and
2. ARP要求がスヌーピングされ、タプルCE1-MAC / CE1-IPがプロキシARPテーブルに追加されます。そして
3. a BGP MAC Advertisement route is triggered from PE1 containing the EVI1 RD and RT, ESI=0, Ethernet-Tag=0, and CE1-MAC/CE1-IP, along with an MPLS Label assigned to MAC-VRF-1 from the PE1 Label space. Note that depending on the implementation, the MAC FIB and proxy ARP learning processes can independently send two BGP MAC advertisements instead of one (one containing only the CE1-MAC and another one containing CE1-MAC/CE1-IP).
3. BVI MACアドバタイズメントルートは、PE1からMAC-VRF-1に割り当てられたMPLSラベルとともに、EVI1 RDおよびRT、ESI = 0、Ethernet-Tag = 0、およびCE1-MAC / CE1-IPを含むPE1からトリガーされます。ラベルスペース。実装によっては、MAC FIBおよびプロキシARP学習プロセスは、1つではなく2つのBGP MACアドバタイズを個別に送信できることに注意してください（1つはCE1-MACのみを含み、もう1つはCE1-MAC / CE1-IPを含みます）。
Since we assume a MAC forwarding model, a label per MAC-VRF is normally allocated and signaled by the three PEs for MAC Advertisement routes. Based on the RT, the route is imported by PE2 and PE3, and the forwarding state plus the ARP entry are added to their MAC-VRF-1 context. From this moment on, any ARP request from CE2 or CE3 destined to CE1-IP can be directly replied to by PE1, PE2, or PE3, and ARP flooding for CE1-IP is not needed in the core.
MAC転送モデルを想定しているため、MAC-VRFごとのラベルが通常割り当てられ、MACアドバタイズメントルートの3つのPEによってシグナリングされます。 RTに基づいて、ルートはPE2とPE3によってインポートされ、転送状態とARPエントリがそれぞれのMAC-VRF-1コンテキストに追加されます。この時点から、CE1-IP宛てのCE2またはCE3からのARP要求は、PE1、PE2、またはPE3によって直接応答でき、コアでCE1-IPのARPフラッディングは必要ありません。
c. Since the ARP frame is a broadcast frame, it is forwarded by PE1 using the Inclusive Multicast Tree for EVI1 (CE-VID=1 tag should be kept if translation is required). Depending on the type of tree, the label stack may vary. For example, assuming ingress replication, the packet is replicated to PE2 and PE3 with the downstream allocated labels and the P2P LSP transport labels. No other labels are added to the stack.
c. ARPフレームはブロードキャストフレームであるため、EVI1の包含マルチキャストツリーを使用してPE1によって転送されます（変換が必要な場合は、CE-VID = 1タグを保持する必要があります）。木の種類によって、ラベルスタックは異なる場合があります。たとえば、入力レプリケーションを想定すると、パケットはダウンストリームに割り当てられたラベルとP2P LSPトランスポートラベルを使用してPE2およびPE3に複製されます。他のラベルはスタックに追加されません。
d. Assuming PE1 is the DF for EVI1 on ESI12, the frame is locally replicated to CE2.
d. PE1がESI12上のEVI1のDFであるとすると、フレームはローカルでCE2に複製されます。
e. The MPLS-encapsulated frame gets to PE2 and PE3. Since PE2 is non-DF for EVI1 on ESI12, and there is no other CE connected to PE2, the frame is discarded. At PE3, the frame is de-encapsulated and the CE-VID is translated, if needed, and forwarded to CE3.
e. MPLSカプセル化フレームは、PE2およびPE3に到達します。 PE2はESI12上のEVI1の非DFであり、PE2に接続されている他のCEがないため、フレームは破棄されます。 PE3では、フレームのカプセル化が解除され、必要に応じてCE-VIDが変換され、CE3に転送されます。
Any other type of BUM frame from CE1 would follow the same procedures. BUM frames from CE3 would follow the same procedures too.
CE1からの他のタイプのBUMフレームは、同じ手順に従います。 CE3からのBUMフレームも同じ手順に従います。
BUM frame example from CE2:
CE2からのBUMフレームの例：
a. An ARP request with CE-VID=1 is issued from source MAC CE2-MAC to find the MAC address of CE3-IP.
a. CE-VID = 1のARP要求がソースMAC CE2-MACから発行され、CE3-IPのMACアドレスを見つけます。
b. CE2 will hash the frame and will forward it to, for example, PE2. Based on the CE-VID, the frame is identified to be forwarded in the EVI1 context. A source MAC lookup is done in the MAC FIB and the sender's CE2-IP is looked up in the proxy ARP table within the MAC-VRF-1 context. If both are unknown, three actions are carried out (assuming the source MAC is accepted by PE2):
b. CE2はフレームをハッシュし、それをたとえばPE2に転送します。 CE-VIDに基づいて、フレームはEVI1コンテキストで転送されるように識別されます。送信元MAC検索はMAC FIBで実行され、送信者のCE2-IPはMAC-VRF-1コンテキスト内のプロキシARPテーブルで検索されます。両方とも不明な場合は、3つのアクションが実行されます（ソースMACがPE2によって受け入れられると想定）。
1. the forwarding state is added for the CE2-MAC associated with the corresponding LAG/ESI and CE-VID;
1. 対応するLAG / ESIおよびCE-VIDに関連付けられたCE2-MACに転送状態が追加されます。
2. the ARP request is snooped and the tuple CE2-MAC/CE2-IP is added to the proxy ARP table; and
2. ARP要求がスヌーピングされ、タプルCE2-MAC / CE2-IPがプロキシARPテーブルに追加されます。そして
3. a BGP MAC Advertisement route is triggered from PE2 containing the EVI1 RD and RT, ESI=12, Ethernet-Tag=0, and CE2-MAC/CE2-IP, along with an MPLS Label assigned from the PE2 Label space (one label per MAC-VRF). Again, depending on the implementation, the MAC FIB and proxy ARP learning processes can independently send two BGP MAC advertisements instead of one.
3. BGP MACアドバタイズメントルートは、PE2ラベルスペースから割り当てられたMPLSラベルとともに、EVI1 RDおよびRT、ESI = 12、Ethernet-Tag = 0、およびCE2-MAC / CE2-IPを含むPE2からトリガーされますMAC-VRF）。この場合も、実装に応じて、MAC FIBおよびプロキシARP学習プロセスは、1つではなく2つのBGP MACアドバタイズを独立して送信できます。
Note that since PE3 is not part of ESI12, it will install the forwarding state for CE2-MAC as long as the A-D routes for ESI12 are also active on PE3. On the contrary, PE1 is part of ESI12, therefore PE1 will not modify the forwarding state for CE2-MAC if it has previously learned CE2-MAC locally attached to ESI12. Otherwise, it will add the forwarding state for CE2-MAC associated with the local ESI12 port.
PE3はESI12の一部ではないため、ESI12のA-DルートがPE3でもアクティブである限り、CE2-MACの転送状態をインストールすることに注意してください。逆に、PE1はESI12の一部であるため、PE2にローカルに接続されたCE2-MACを以前に学習している場合、PE1はCE2-MACの転送状態を変更しません。それ以外の場合は、ローカルESI12ポートに関連付けられたCE2-MACの転送状態を追加します。
c. Assuming PE2 does not have the ARP information for CE3-IP yet, and since the ARP is a broadcast frame and PE2 is the non-DF for EVI1 on ESI12, the frame is forwarded by PE2 in the Inclusive Multicast Tree for EVI1, thus adding the ESI Label for ESI12 at the bottom of the stack. The ESI Label has been previously allocated and signaled by the A-D routes for ESI12. Note that, as per [RFC7432], if the result of the CE2 hashing is different and the frame is sent to PE1, PE1 should add the ESI Label too (PE1 is the DF for EVI1 on ESI12).
c. PE2にはまだCE3-IPのARP情報がなく、ARPはブロードキャストフレームであり、PE2はESI12のEVI1の非DFであるため、フレームはEVI1の包括的マルチキャストツリーのPE2によって転送され、スタックの一番下にあるESI12のESIラベル。 ESIラベルは以前に割り当てられ、ESI12のA-Dルートによって通知されています。 [RFC7432]のように、CE2ハッシュの結果が異なり、フレームがPE1に送信される場合、PE1もESIラベルを追加する必要があることに注意してください（PE1はESI12上のEVI1のDFです）。
d. The MPLS-encapsulated frame gets to PE1 and PE3. PE1 de-encapsulates the Inclusive Multicast Tree Label(s) and, based on the ESI Label at the bottom of the stack, it decides to not forward the frame to the ESI12. It will pop the ESI Label and will replicate it to CE1, since CE1 is not part of the ESI identified by the ESI Label. At PE3, the Inclusive Multicast Tree Label is popped and the frame forwarded to CE3. If a P2MP LSP is used as the Inclusive Multicast Tree for EVI1, PE3 will find an ESI Label after popping the P2MP LSP Label. The ESI Label will simply be popped, since CE3 is not part of ESI12.
d. MPLSカプセル化フレームは、PE1およびPE3に到達します。 PE1は包含的マルチキャストツリーラベルのカプセル化を解除し、スタックの最下部のESIラベルに基づいて、フレームをESI12に転送しないことを決定します。 CE1はESIラベルで識別されるESIの一部ではないため、ESIラベルをポップしてCE1に複製します。 PE3では、包括的マルチキャストツリーラベルがポップされ、フレームがCE3に転送されます。 P2MP LSPがEVI1の包含マルチキャストツリーとして使用されている場合、PE3はP2MP LSPラベルをポップした後にESIラベルを見つけます。 CE3はESI12の一部ではないため、ESIラベルは単純にポップされます。
Unicast frame example from CE3 to CE1:
CE3からCE1へのユニキャストフレームの例：
a. A unicast frame with CE-VID=1 is issued from source MAC CE3-MAC and destination MAC CE1-MAC (we assume PE3 has previously resolved an ARP request from CE3 to find the MAC of CE1-IP and has added CE3-MAC/CE3-IP to its proxy ARP table).
a. CE-VID = 1のユニキャストフレームは、送信元MAC CE3-MACおよび宛先MAC CE1-MACから発行されます（PE3は以前にCE3からのARP要求を解決してCE1-IPのMACを検出し、CE3-MAC /を追加したと想定しますCE3-IPからプロキシARPテーブルへ）。
b. Based on the CE-VID, the frame is identified to be forwarded in the EVI1 context. A source MAC lookup is done in the MAC FIB within the MAC-VRF-1 context and this time, since we assume CE3-MAC is known, no further actions are carried out as a result of the source lookup. A destination MAC lookup is performed next and the label stack associated with the MAC CE1-MAC is found (including the label associated with MAC-VRF-1 in PE1 and the P2P LSP Label to get to PE1). The unicast frame is then encapsulated and forwarded to PE1.
b. CE-VIDに基づいて、フレームはEVI1コンテキストで転送されるように識別されます。送信元MACルックアップはMAC-VRF-1コンテキスト内のMAC FIBで行われ、今回はCE3-MACが既知であると想定しているため、送信元ルックアップの結果としてそれ以上のアクションは実行されません。次に宛先MAC検索が実行され、MAC CE1-MACに関連付けられたラベルスタックが検出されます（PE1のMAC-VRF-1に関連付けられたラベルとPE1に到達するためのP2P LSPラベルを含む）。ユニキャストフレームはカプセル化され、PE1に転送されます。
c. At PE1, the packet is identified to be part of EVI1 and a destination MAC lookup is performed in the MAC-VRF-1 context. The labels are popped and the frame is forwarded to CE1 with CE-VID=1.
c. PE1では、パケットはEVI1の一部であると識別され、宛先MACルックアップがMAC-VRF-1コンテキストで実行されます。ラベルがポップされ、フレームはCE-VID = 1でCE1に転送されます。
Unicast frames from CE1 to CE3 or from CE2 to CE3 follow the same procedures described above.
CE1からCE3へ、またはCE2からCE3へのユニキャストフレームは、上記と同じ手順に従います。
Unicast frame example from CE3 to CE2:
CE3からCE2へのユニキャストフレームの例：
a. A unicast frame with CE-VID=1 is issued from source MAC CE3-MAC and destination MAC CE2-MAC (we assume PE3 has previously resolved an ARP request from CE3 to find the MAC of CE2-IP).
a. CE-VID = 1のユニキャストフレームは、送信元MAC CE3-MACおよび宛先MAC CE2-MACから発行されます（PE3は、CE2-IPのMACを見つけるために、CE3からのARP要求を以前に解決したと想定しています）。
b. Based on the CE-VID, the frame is identified to be forwarded in the MAC-VRF-1 context. We assume CE3-MAC is known. A destination MAC lookup is performed next and PE3 finds CE2-MAC associated with PE2 on ESI12, an Ethernet Segment for which PE3 has two active A-D routes per ESI (from PE1 and PE2) and two active A-D routes for EVI1 (from PE1 and PE2). Based on a hashing function for the frame, PE3 may decide to forward the frame using the label stack associated with PE2 (label received from the MAC Advertisement route) or the label stack associated with PE1 (label received from the A-D route per EVI for EVI1). Either way, the frame is encapsulated and sent to the remote PE.
b。 CE-VIDに基づいて、MAC-VRF-1コンテキストで転送されるフレームが識別されます。 CE3-MACが既知であると想定します。次に宛先MACルックアップが実行され、PE3はESI12上のPE2に関連付けられたCE2-MACを見つけます。これは、PE3がESIごとに2つのアクティブなADルート（PE1とPE2から）とEVI1に対して2つのアクティブなADルート（PE1とPE2から）を持っているイーサネットセグメントです。 ）。フレームのハッシュ関数に基づいて、PE3は、PE2に関連付けられたラベルスタック（MAC広告ルートから受信したラベル）またはPE1に関連付けられたラベルスタック（EVI1のEVIごとにADルートから受信したラベル）を使用してフレームを転送することを決定できます。 ）。どちらの方法でも、フレームはカプセル化され、リモートPEに送信されます。
c. At PE2 (or PE1), the packet is identified to be part of EVI1 based on the bottom label, and a destination MAC lookup is performed. At either PE (PE2 or PE1), the FIB lookup yields a local ESI12 port to which the frame is sent.
c. PE2（またはPE1）では、パケットは最下部のラベルに基づいてEVI1の一部であると識別され、宛先MAC検索が実行されます。 PE（PE2またはPE1）のいずれかで、FIBルックアップにより、フレームの送信先となるローカルESI12ポートが生成されます。
Unicast frames from CE1 to CE2 follow the same procedures.
CE1からCE2へのユニキャストフレームは同じ手順に従います。
Instead of using VLAN-based interfaces, the operator can choose to implement VLAN bundle interfaces to carry the traffic for the 4k CE-VIDs among CE1, CE2, and CE3. If that is the case, the 4k CE-VIDs can be mapped to the same EVI (for example, EVI200) at each PE. The main advantage of this approach is the low control-plane overhead (reduced number of routes and labels) and easiness of provisioning at the expense of no control over the customer broadcast domains, i.e., a single Inclusive Multicast Tree for all the CE-VIDs and no CE-VID translation in the provider network.
オペレーターは、VLANベースのインターフェースを使用する代わりに、VLANバンドルインターフェースを実装して、CE1、CE2、およびCE3間で4k CE-VIDのトラフィックを伝送することを選択できます。その場合、4k CE-VIDは各PEで同じEVI（たとえば、EVI200）にマップできます。このアプローチの主な利点は、コントロールプレーンのオーバーヘッドが少なく（ルートとラベルの数が少ない）、プロビジョニングが容易で、顧客のブロードキャストドメインを制御できないことです。つまり、すべてのCE-VIDに単一の包括的マルチキャストツリーを使用できます。プロバイダーネットワークではCE-VID変換は行われません。
As soon as the EVI200 is created in PE1, PE2, and PE3, the following control-plane actions are carried out:
EVI200がPE1、PE2、およびPE3で作成されるとすぐに、次のコントロールプレーンアクションが実行されます。
o Flooding tree setup per EVI (one route): Each PE will send one Inclusive Multicast Ethernet Tag route per EVI (hence, only one route per PE) so that the flooding tree per EVI can be set up. Note that ingress replication or P2MP LSPs can optionally be signaled in the PMSI Tunnel attribute and the corresponding tree can be created.
o EVIごとのフラッディングツリーのセットアップ（1つのルート）：各PEは、EVIごとに1つの包括的マルチキャストイーサネットタグルートを送信するため（EVIごとに1つのルートのみ）、EVIごとのフラッディングツリーをセットアップできます。入力レプリケーションまたはP2MP LSPは、オプションでPMSIトンネル属性で通知でき、対応するツリーを作成できることに注意してください。
o Ethernet A-D routes per ESI (one route for ESI12): A single A-D route for ESI12 will be issued from PE1 and PE2. This route will include a single RT (RT for EVI200), an ESI Label extended community with the active-standby flag set to zero (all-active multihoming type), and an ESI Label different from zero (used by the non-DF for split-horizon functions). This route will be imported by the three PEs, since the RT matches the locally configured EVI200 RT. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as described in [RFC7432].
o ESIごとのイーサネットA-Dルート（ESI12の1つのルート）：ESI12の単一のA-DルートがPE1およびPE2から発行されます。このルートには、単一のRT（EVI200のRT）、アクティブスタンバイフラグがゼロに設定されたESIラベル拡張コミュニティ（すべてアクティブなマルチホーミングタイプ）、およびゼロ以外のESIラベル（非DFで使用される）が含まれますスプリットホライズン関数）。 RTはローカルに構成されたEVI200 RTと一致するため、このルートは3つのPEによってインポートされます。 [RFC7432]で説明されているように、ESIごとのA-Dルートは高速収束とスプリットホライズン機能に使用されます。
o Ethernet A-D routes per EVI (one route): An A-D route (EVI200) will be sent by PE1 and PE2 for ESI12. This route includes the EVI200 RT and an MPLS Label to be used by PE3 for the aliasing function. This route will be imported by the three PEs.
o EVIごとのイーサネットA-Dルート（1つのルート）：A-Dルート（EVI200）は、ESI12のPE1およびPE2によって送信されます。このルートには、PE3がエイリアシング機能に使用するEVI200 RTとMPLSラベルが含まれています。このルートは、3つのPEによってインポートされます。
The packet walk-through for the VLAN bundle case is similar to the one described for EVI1 in the VLAN-based case except for the way the CE-VID is handled by the ingress PE and the egress PE:
VLANバンドルの場合のパケットウォークスルーは、CE-VIDが入力PEと出力PEによって処理される方法を除いて、VLANベースの場合のEVI1について説明したものと同様です。
o No VLAN translation is allowed and the CE-VIDs are kept untouched from CE to CE, i.e., the ingress CE-VID must be kept at the imposition PE and at the disposition PE.
o VLAN変換は許可されず、CE-VIDはCEからCEにそのまま維持されます。つまり、入力CE-VIDはインポジションPEとディスポジションPEに保持される必要があります。
o The frame is identified to be forwarded in the MAC-VRF-200 context as long as its CE-VID belongs to the VLAN bundle defined in the PE1/PE2/PE3 port to CE1/CE2/CE3. Our example is a special VLAN bundle case since the entire CE-VID range is defined in the ports; therefore, any CE-VID would be part of EVI200.
o フレームは、そのCE-VIDがPE1 / PE2 / PE3ポートでCE1 / CE2 / CE3に定義されたVLANバンドルに属している限り、MAC-VRF-200コンテキストで転送されると識別されます。 CE-VID範囲全体がポートで定義されているため、この例は特別なVLANバンドルのケースです。したがって、CE-VIDはすべてEVI200の一部になります。
Please refer to Section 6.2.2 for more information about the control-plane and forwarding-plane interaction for BUM and unicast traffic from the different CEs.
異なるCEからのBUMおよびユニキャストトラフィックのコントロールプレーンとフォワーディングプレーンの相互作用の詳細については、セクション6.2.2を参照してください。
The last potential service type analyzed in this document is VLAN-aware bundling. When this type of service interface is used to carry the 4k CE-VIDs among CE1, CE2, and CE3, all the CE-VIDs will be mapped to the same EVI (for example, EVI300). The difference, compared to the VLAN bundle service type in the previous section, is that each incoming CE-VID will also be mapped to a different "normalized" Ethernet Tag in addition to EVI300. If no translation is required, the Ethernet Tag will match the CE-VID. Otherwise, a translation between CE-VID and Ethernet Tag will be needed at the imposition PE and at the disposition PE. The main advantage of this approach is the ability to control customer broadcast domains while providing a single EVI to the customer.
このドキュメントで分析される最後の潜在的なサービスタイプは、VLAN対応バンドルです。このタイプのサービスインターフェイスを使用して、CE1、CE2、およびCE3間で4k CE-VIDを伝送すると、すべてのCE-VIDが同じEVI（たとえば、EVI300）にマッピングされます。前のセクションのVLANバンドルサービスタイプとの違いは、各着信CE-VIDがEVI300に加えて異なる「正規化された」イーサネットタグにもマッピングされることです。変換が不要な場合、イーサネットタグはCE-VIDと一致します。それ以外の場合、CE-VIDとイーサネットタグ間の変換がインポジションPEとディスポジションPEで必要になります。このアプローチの主な利点は、単一のEVIを顧客に提供しながら、顧客のブロードキャストドメインを制御できることです。
As soon as the EVI300 is created in PE1, PE2, and PE3, the following control-plane actions are carried out:
EVI300がPE1、PE2、およびPE3で作成されるとすぐに、次のコントロールプレーンアクションが実行されます。
o Flooding tree setup per EVI per Ethernet Tag (4k routes): Each PE will send one Inclusive Multicast Ethernet Tag route per EVI and per Ethernet Tag (hence, 4k routes per PE) so that the flooding tree per customer broadcast domain can be set up. Note that ingress replication or P2MP LSPs can optionally be signaled in the PMSI Tunnel attribute and the corresponding tree be created. In the described use case, since all the CE-VIDs and Ethernet Tags are defined on the three PEs, multicast tree aggregation might make sense in order to save forwarding states.
oイーサネットタグごとのEVIごとのフラッディングツリーセットアップ（4kルート）：各PEは、EVIごとおよびイーサネットタグごと（したがって、PEごとに4kルート）の包括的マルチキャストイーサネットタグルートを1つ送信するため、顧客のブロードキャストドメインごとのフラッディングツリーを設定できます。アップ。入力レプリケーションまたはP2MP LSPは、オプションでPMSIトンネル属性で通知され、対応するツリーが作成されることに注意してください。説明されている使用例では、すべてのCE-VIDとイーサネットタグが3つのPEで定義されているため、転送状態を保存するためにマルチキャストツリー集約が意味をなす場合があります。
o Ethernet A-D routes per ESI (one route for ESI12): A single A-D route for ESI12 will be issued from PE1 and PE2. This route will include a single RT (RT for EVI300), an ESI Label extended community with the active-standby flag set to zero (all-active multihoming type), and an ESI Label different than zero (used by the non-DF for split-horizon functions). This route will be imported by the three PEs, since the RT matches the locally configured EVI300 RT. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as described in [RFC7432].
o ESIごとのイーサネットA-Dルート（ESI12の1つのルート）：ESI12の単一のA-DルートがPE1およびPE2から発行されます。このルートには、単一のRT（EVI300のRT）、アクティブスタンバイフラグがゼロに設定されたESIラベル拡張コミュニティ（すべてアクティブのマルチホーミングタイプ）、およびゼロ以外のESIラベル（非DFで使用される）が含まれますスプリットホライズン関数）。 RTはローカルに構成されたEVI300 RTと一致するため、このルートは3つのPEによってインポートされます。 [RFC7432]で説明されているように、ESIごとのA-Dルートは高速収束とスプリットホライズン機能に使用されます。
o Ethernet A-D routes per EVI: A single A-D route (EVI300) may be sent by PE1 and PE2 for ESI12 in case no CE-VID translation is required. This route includes the EVI300 RT and an MPLS Label to be used by PE3 for the aliasing function. This route will be imported by the three PEs. Note that if CE-VID translation is required, an A-D per EVI route is required per Ethernet Tag (4k).
o EVIごとのイーサネットA-Dルート：CE-VID変換が必要ない場合、単一のA-Dルート（EVI300）がESI12のPE1およびPE2によって送信されます。このルートには、PE3がエイリアシング機能に使用するEVI300 RTとMPLSラベルが含まれています。このルートは、3つのPEによってインポートされます。 CE-VID変換が必要な場合、EVIルートごとにA-Dがイーサネットタグ（4k）ごとに必要であることに注意してください。
The packet walk-through for the VLAN-aware case is similar to the one described before. Compared to the other two cases, VLAN-aware services allow for CE-VID translation and for an N:1 CE-VID to EVI mapping. Both things are not supported at once in either of the two other service interfaces. Some differences compared to the packet walk-through described in Section 6.2.2 are as follows:
VLAN対応の場合のパケットウォークスルーは、前に説明したものと同様です。他の2つのケースと比較して、VLAN対応サービスでは、CE-VID変換およびN：1 CE-VIDからEVIへのマッピングが可能です。他の2つのサービスインターフェイスのどちらでも、両方が同時にサポートされることはありません。セクション6.2.2で説明されているパケットウォークスルーとの違いは次のとおりです。
o At the ingress PE, the frames are identified to be forwarded in the EVI300 context as long as their CE-VID belong to the range defined in the PE port to the CE. In addition to it, CE-VID=x is mapped to a "normalized" Ethernet-Tag=y at the MAC-VRF-300 (where x and y might be equal if no translation is needed). Qualified learning is now required (a different bridge table is allocated within MAC-VRF-300 for each Ethernet Tag). Potentially, the same MAC could be learned in two different Ethernet Tag bridge tables of the same MAC-VRF.
o 入力PEで、フレームは、CE-VIDがCEポートへのPEポートで定義された範囲に属している限り、EVI300コンテキストで転送されると識別されます。これに加えて、CE-VID = xはMAC-VRF-300で「正規化された」Ethernet-Tag = yにマッピングされます（変換が必要ない場合、xとyは等しい場合があります）。適格な学習が必要になりました（イーサネットタグごとにMAC-VRF-300内に異なるブリッジテーブルが割り当てられます）。潜在的に、同じMACが、同じMAC-VRFの2つの異なるイーサネットタグブリッジテーブルで学習される可能性があります。
o Any new locally learned MAC on the MAC-VRF-300/Ethernet-Tag=y interface is advertised by the ingress PE in a MAC Advertisement route using the now Ethernet Tag field (Ethernet-Tag=y) so that the remote PE learns the MAC associated with the MAC-VRF-300/ Ethernet-Tag=y FIB. Note that the Ethernet Tag field is not used in advertisements of MACs learned on VLAN-based or VLAN-bundle service interfaces.
o MAC-VRF-300 / Ethernet-Tag = yインターフェイス上の新しいローカルに学習されたMACは、現在のイーサネットタグフィールド（Ethernet-Tag = y）を使用してMACアドバタイズメントルートの入力PEによってアドバタイズされ、リモートPEが学習します。 MAC-VRF-300 / Ethernet-Tag = y FIBに関連付けられたMAC。イーサネットタグフィールドは、VLANベースまたはVLANバンドルサービスインターフェイスで学習されたMACのアドバタイズメントでは使用されないことに注意してください。
o At the ingress PE, BUM frames are sent to the corresponding flooding tree for the particular Ethernet Tag they are mapped to. Each individual Ethernet Tag can have a different flooding tree within the same EVI300. For instance, Ethernet-Tag=y can use ingress replication to get to the remote PEs, whereas Ethernet-Tag=z can use a P2MP LSP.
o 入力PEでは、BUMフレームは、マップされている特定のイーサネットタグに対応するフラッディングツリーに送信されます。個々のイーサネットタグは、同じEVI300内で異なるフラッディングツリーを持つことができます。たとえば、Ethernet-Tag = yは入力レプリケーションを使用してリモートPEに到達できますが、Ethernet-Tag = zはP2MP LSPを使用できます。
o At the egress PE, Ethernet-Tag=y (for a given broadcast domain within MAC-VRF-300) can be translated to egress CE-VID=x. That is not possible for VLAN bundle interfaces. It is possible for VLAN-based interfaces, but it requires a separate MAC-VRF per CE-VID.
o 出力PEでは、Ethernet-Tag = y（MAC-VRF-300内の特定のブロードキャストドメインの場合）を出力CE-VID = xに変換できます。これは、VLANバンドルインターフェイスでは不可能です。 VLANベースのインターフェイスでも可能ですが、CE-VIDごとに個別のMAC-VRFが必要です。
EVPN supports an alternative forwarding model, usually referred to as the MPLS-based forwarding or disposition model, as opposed to the MAC-based forwarding or disposition model described in Section 6. Using the MPLS-based forwarding model instead of the MAC-based model might have an impact on the following:
EVPNは、セクション6で説明されているMACベースの転送または廃棄モデルとは対照的に、通常MPLSベースの転送または廃棄モデルと呼ばれる代替の転送モデルをサポートしています。MACベースのモデルの代わりにMPLSベースの転送モデルを使用する以下に影響を与える可能性があります。
o the number of forwarding states required; and
o 必要な転送状態の数。そして
o the FIB where the forwarding states are handled (MAC FIB or MPLS Label FIB (LFIB)).
o 転送状態が処理されるFIB（MAC FIBまたはMPLSラベルFIB（LFIB））。
The MPLS-based forwarding model avoids the destination MAC lookup at the egress PE MAC FIB at the expense of increasing the number of next-hop forwarding states at the egress MPLS LFIB. This also has an impact on the control plane and the label allocation model, since an MPLS-based disposition PE must send as many routes and labels as required next-hops in the egress MAC-VRF. This concept is equivalent to the forwarding models supported in IP-VPNs at the egress PE, where an IP lookup in the IP-VPN FIB may or may not be necessary depending on the available next-hop forwarding states in the LFIB.
MPLSベースの転送モデルは、出力MPLS LFIBでのネクストホップ転送状態の数を増やすことを犠牲にして、出力PE MAC FIBでの宛先MAC検索を回避します。 MPLSベースのディスポジションPEは、出力MAC-VRFで必要なネクストホップと同じ数のルートとラベルを送信する必要があるため、これはコントロールプレーンとラベル割り当てモデルにも影響を与えます。この概念は、出力PEのIP-VPNでサポートされている転送モデルと同等です。IP-VPNFIBでのIPルックアップは、LFIBで利用可能なネクストホップ転送状態に応じて必要な場合と必要でない場合があります。
The following subsections highlight the impact on the control- and data-plane procedures described in Section 6 when an MPLS-based forwarding model is used.
次のサブセクションでは、MPLSベースの転送モデルが使用されている場合の、セクション6で説明されているコントロールプレーンおよびデータプレーンの手順への影響について説明します。
Note that both forwarding models are compatible and interoperable in the same network. The implementation of either model in each PE is a local decision to the PE node.
どちらの転送モデルにも互換性があり、同じネットワークで相互運用できることに注意してください。各PEでのいずれかのモデルの実装は、PEノードに対するローカルな決定です。
The MPLS-based forwarding model has no impact on the procedures explained in Section 6.1.
MPLSベースの転送モデルは、セクション6.1で説明されている手順に影響を与えません。
7.2. Impact of MPLS-Based Forwarding on the VLAN-Based Service Procedures
7.2. VLANベースのサービス手順に対するMPLSベースの転送の影響
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of the number of routes when all the service interfaces are based on VLAN. The differences for the use case described in this document are summarized in the following list:
MACベースの転送モデルと比較して、MPLSベースの転送モデルは、すべてのサービスインターフェイスがVLANに基づいている場合、ルート数の点で影響を与えません。このドキュメントで説明するユースケースの違いを次のリストにまとめます。
o Flooding tree setup per EVI (4k routes per PE): There is no impact when compared to the MAC-based model.
o EVIごとのフラッディングツリーのセットアップ（PEごとに4kルート）：MACベースのモデルと比較した場合、影響はありません。
o Ethernet A-D routes per ESI (one set of routes for ESI12 per PE): There is no impact compared to the MAC-based model.
o ESIごとのイーサネットA-Dルート（PEごとのESI12の1セットのルート）：MACベースのモデルと比較して影響はありません。
o Ethernet A-D routes per EVI (4k routes per PE/ESI): There is no impact compared to the MAC-based model.
o EVIごとのイーサネットA-Dルート（PE / ESIごとに4kルート）：MACベースのモデルと比較して影響はありません。
o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. For example, if CE2 sends traffic from two different MACs to PE1, CE2-MAC1, and CE2-MAC2, the same MPLS Label=x can be re-used for both MAC advertisements, since they both share the same source ESI12. It is up to the PE1 implementation to use a different label per individual MAC within the same ES (even if only one label per ESI is enough).
o MACアドバタイズメントルート：同じMAC-VRFでローカルに学習されたすべての新しいMACに同じMPLSラベルを割り当ててアドバタイズする代わりに、CEネクストホップまたはMACごとに異なるラベルをアドバタイズし、MAC FIBルックアップが不要になるようにします。出力PE。一般に、これは別のラベル（少なくともCEごと）をアドバタイズする必要があることを意味しますが、転送状態に関してより細かい（したがって、スケーラビリティーが低い）が必要な場合、PEはMACごとにラベルを実装することを決定できます。たとえば、CE2が2つの異なるMACからPE1、CE2-MAC1、およびCE2-MAC2にトラフィックを送信する場合、両方が同じソースESI12を共有するため、両方のMACアドバタイズメントに同じMPLS Label = xを再利用できます。同じES内の個々のMACごとに異なるラベルを使用するのは、PE1実装次第です（たとえESIごとに1つのラベルで十分であっても）。
o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane but will rather add forwarding states to the MPLS LFIB.
o PE1、PE2、およびPE3は、データプレーンで新しいローカルCE MACアドレスを学習しても、MAC FIBに転送状態を追加せず、MPLS LFIBに転送状態を追加します。
7.3. Impact of MPLS-Based Forwarding on the VLAN Bundle Service Procedures
7.3. VLANバンドルサービス手順に対するMPLSベースの転送の影響
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of number of routes when all the service interfaces are VLAN bundle type. The differences for the use case described in this document are summarized in the following list:
MACベースの転送モデルと比較して、すべてのサービスインターフェイスがVLANバンドルタイプである場合、MPLSベースの転送モデルはルート数の点で影響を与えません。このドキュメントで説明するユースケースの違いを次のリストにまとめます。
o Flooding tree setup per EVI (one route): There is no impact compared to the MAC-based model.
o EVIごとのフラッディングツリーの設定（1つのルート）：MACベースのモデルと比較して影響はありません。
o Ethernet A-D routes per ESI (one route for ESI12 per PE): There is no impact compared to the MAC-based model.
o ESIごとのイーサネットA-Dルート（PEごとにESI12の1つのルート）：MACベースのモデルと比較して影響はありません。
o Ethernet A-D routes per EVI (one route per PE/ESI): There is no impact compared to the MAC-based model since no VLAN translation is required.
o EVIごとのイーサネットA-Dルート（PE / ESIごとに1つのルート）：VLAN変換が必要ないため、MACベースのモデルに比べて影響はありません。
o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. It is up to the PE1 implementation to use a different label per individual MAC within the same ES (even if only one label per ESI is enough).
o MACアドバタイズメントルート：同じMAC-VRFでローカルに学習されたすべての新しいMACに同じMPLSラベルを割り当ててアドバタイズする代わりに、CEネクストホップまたはMACごとに異なるラベルをアドバタイズし、MAC FIBルックアップが不要になるようにします。出力PE。一般に、これは別のラベル（少なくともCEごと）をアドバタイズする必要があることを意味しますが、転送状態に関してより細かい（したがって、スケーラビリティーが低い）が必要な場合、PEはMACごとにラベルを実装することを決定できます。同じES内の個々のMACごとに異なるラベルを使用するのは、PE1実装次第です（たとえESIごとに1つのラベルで十分であっても）。
o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane, but will rather add forwarding states to the MPLS LFIB.
o PE1、PE2、およびPE3は、データプレーン上の新しいローカルCE MACアドレスを学習するときに、MAC FIBに転送状態を追加しませんが、MPLS LFIBに転送状態を追加します。
7.4. Impact of MPLS-Based Forwarding on the VLAN-Aware Service Procedures
7.4. VLAN対応のサービス手順に対するMPLSベースの転送の影響
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of the number of A-D routes when all the service interfaces are of the VLAN-aware bundle type. The differences for the use case described in this document are summarized in the following list:
MACベースの転送モデルと比較して、すべてのサービスインターフェイスがVLAN対応のバンドルタイプである場合、MPLSベースの転送モデルは、A-Dルートの数に関して影響を与えません。このドキュメントで説明するユースケースの違いを次のリストにまとめます。
o Flooding tree setup per EVI (4k routes per PE): There is no impact compared to the MAC-based model.
o EVIごとのフラッディングツリーの設定（PEごとに4kルート）：MACベースのモデルと比較して影響はありません。
o Ethernet A-D routes per ESI (one route for ESI12 per PE): There is no impact compared to the MAC-based model.
o ESIごとのイーサネットA-Dルート（PEごとにESI12の1つのルート）：MACベースのモデルと比較して影響はありません。
o Ethernet A-D routes per EVI (1 route per ESI or 4k routes per PE/ ESI): PE1 and PE2 may send one route per ESI if no CE-VID translation is needed. However, 4k routes are normally sent for EVI300, one per <ESI, Ethernet Tag ID> tuple. This allows the egress PE to find out all the forwarding information in the MPLS LFIB and even support Ethernet Tag to CE-VID translation at the egress.
o EVIごとのイーサネットA-Dルート（ESIごとに1ルートまたはPE / ESIごとに4kルート）：CE-VID変換が必要ない場合、PE1およびPE2はESIごとに1ルートを送信できます。ただし、4Kルートは通常、<ESI、Ethernet Tag ID>タプルごとに1つ、EVI300に送信されます。これにより、出力PEはMPLS LFIB内のすべての転送情報を検出でき、出力でイーサネットタグからCE-VIDへの変換もサポートできます。
o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. It is up to the PE1 implementation to use a different label per individual MAC within the same ES. Note that the Ethernet Tag will be set to a non-zero value for the MAC Advertisement routes. The same MAC address can be announced with a different Ethernet Tag value. This will make the advertising PE install two different forwarding states in the MPLS LFIB.
o MACアドバタイズメントルート：同じMAC-VRFでローカルに学習されたすべての新しいMACに同じMPLSラベルを割り当ててアドバタイズする代わりに、CEネクストホップまたはMACごとに異なるラベルをアドバタイズし、MAC FIBルックアップが不要になるようにします。出力PE。一般に、これは別のラベル（少なくともCEごと）をアドバタイズする必要があることを意味しますが、転送状態に関してより細かい（したがって、スケーラビリティーが低い）が必要な場合、PEはMACごとにラベルを実装することを決定できます。同じES内の個々のMACごとに異なるラベルを使用するのは、PE1実装次第です。イーサネットタグはMACアドバタイズルートのゼロ以外の値に設定されることに注意してください。同じMACアドレスを異なるイーサネットタグ値でアナウンスできます。これにより、アドバタイジングPEは2つの異なる転送状態をMPLS LFIBにインストールします。
o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane but will rather add forwarding states to the MPLS LFIB.
o PE1、PE2、およびPE3は、データプレーンで新しいローカルCE MACアドレスを学習しても、MAC FIBに転送状態を追加せず、MPLS LFIBに転送状態を追加します。
Both forwarding models are possible in a network deployment, and each one has its own trade-offs.
どちらの転送モデルもネットワーク展開で可能であり、それぞれに独自のトレードオフがあります。
Both forwarding models can save A-D routes per EVI when VLAN-aware bundling services are deployed and no CE-VID translation is required. While this saves a significant amount of routes, customers normally require CE-VID translation; hence, we assume an A-D per EVI route per <ESI, Ethernet Tag> is needed.
VLAN対応のバンドルサービスが展開され、CE-VID変換が不要な場合、両方の転送モデルでEVIごとにA-Dルートを保存できます。これによりかなりの量のルートが節約されますが、お客様は通常CE-VID変換を必要とします。したがって、<ESI、イーサネットタグ>ごとにEVIルートごとにA-Dが必要であると想定します。
The MAC-based model saves a significant amount of MPLS Labels compared to the MPLS-based forwarding model. All the MACs and A-D routes for the same EVI can signal the same MPLS Label, saving labels from the local PE space. A MAC FIB lookup at the egress PE is required in order to do so.
MACベースのモデルは、MPLSベースの転送モデルと比較して、かなりの量のMPLSラベルを節約します。同じEVIのすべてのMACおよびA-Dルートは、同じMPLSラベルを通知し、ローカルPEスペースからのラベルを保存できます。そのためには、出力PEでのMAC FIBルックアップが必要です。
The MPLS-based forwarding model can save forwarding states at the egress PEs if labels per next-hop CE (as opposed to per MAC) are implemented. No egress MAC lookup is required. Also, a different label per next-hop CE per MAC-VRF is consumed, as opposed to a single label per MAC-VRF.
（MACごとではなく）ネクストホップCEごとのラベルが実装されている場合、MPLSベースの転送モデルは出力PEで転送状態を保存できます。出力MACルックアップは必要ありません。また、MAC-VRFごとに1つのラベルではなく、MAC-VRFごとにネクストホップCEごとに異なるラベルが消費されます。
Table 2 summarizes the resource implementation details of both models.
表2は、両方のモデルのリソース実装の詳細をまとめたものです。
+-----------------------------+-----------------+------------------+
| Resources | MAC-Based Model | MPLS-Based Model |
+-----------------------------+-----------------+------------------+
| MPLS Labels Consumed | 1 per MAC-VRF | 1 per CE/EVI |
| Egress PE Forwarding States | 1 per MAC | 1 per Next-Hop |
| Egress PE Lookups | 2 (MPLS+MAC) | 1 (MPLS) |
+-----------------------------+-----------------+------------------+
Table 2: Resource Comparison between MAC-Based and MPLS-Based Models
表2：MACベースのモデルとMPLSベースのモデルのリソース比較
The egress forwarding model is an implementation local to the egress PE and is independent of the model supported on the rest of the PEs; i.e., in our use case, PE1, PE2, and PE3 could have either egress forwarding model without any dependencies.
出力転送モデルは、出力PEにローカルな実装であり、残りのPEでサポートされているモデルとは無関係です。つまり、このユースケースでは、PE1、PE2、およびPE3は、依存関係のない出力転送モデルのいずれかを持つことができます。
In addition to the procedures described across Sections 3 through 8, EVPN [RFC7432] procedures allow for optimized traffic handling in order to minimize unnecessary flooding across the entire infrastructure. Optimization is provided through specific ARP termination and the ability to block unknown unicast flooding. Additionally, EVPN procedures allow for intelligent, close to the source, inter-subnet forwarding and solves the commonly known suboptimal routing problem. Besides the traffic efficiency, ingress-based inter-subnet forwarding also optimizes packet forwarding rules and implementation at the egress nodes as well. Details of these procedures are outlined in Sections 9.1 and 9.2.
セクション3〜8で説明されている手順に加えて、EVPN [RFC7432]手順では、インフラストラクチャ全体にわたる不要なフラッディングを最小限に抑えるために、トラフィック処理を最適化できます。最適化は、特定のARP終了と未知のユニキャストフラッディングをブロックする機能によって提供されます。さらに、EVPNプロシージャは、インテリジェントでソースに近いサブネット間転送を可能にし、一般的に知られている次善のルーティング問題を解決します。トラフィック効率に加えて、入力ベースのサブネット間転送は、パケット転送ルールと出力ノードでの実装も最適化します。これらの手順の詳細は、セクション9.1および9.2で概説されています。
The fundamental premise of [RFC7432] is the notion of a different approach to MAC address learning compared to traditional IEEE 802.1 bridge learning methods; specifically, EVPN differentiates between data and control-plane-driven learning mechanisms.
[RFC7432]の基本的な前提は、従来のIEEE 802.1ブリッジ学習方法と比較して、MACアドレス学習への異なるアプローチの概念です。具体的には、EVPNはデータとコントロールプレーン主導の学習メカニズムを区別します。
Data-driven learning implies that there is no separate communication channel used to advertise and propagate MAC addresses. Rather, MAC addresses are learned through IEEE-defined bridge learning procedures as well as by snooping on DHCP and ARP requests. As different MAC addresses show up on different ports, the Layer 2 (L2) FIB is populated with the appropriate MAC addresses.
データ駆動型学習は、MACアドレスのアドバタイズと伝搬に使用される個別の通信チャネルがないことを意味します。むしろ、MACアドレスは、IEEE定義のブリッジ学習手順を通じて、およびDHCPおよびARP要求をスヌーピングすることによって学習されます。異なるポートに異なるMACアドレスが表示されるため、レイヤー2（L2）FIBには適切なMACアドレスが入力されます。
Control-plane-driven learning implies a communication channel that could be either a control-plane protocol or a management-plane mechanism. In the context of EVPN, two different learning procedures are defined: local and remote procedures.
コントロールプレーン主導の学習は、コントロールプレーンプロトコルまたは管理プレーンメカニズムのいずれかである可能性がある通信チャネルを意味します。 EVPNのコンテキストでは、ローカルとリモートの2つの異なる学習手順が定義されています。
o Local learning defines the procedures used for learning the MAC addresses of network elements locally connected to a MAC-VRF. Local learning could be implemented through all three learning procedures: control plane, management plane, and data plane. However, the expectation is that for most of the use cases, local learning through the data plane should be sufficient.
o ローカル学習は、MAC-VRFにローカルに接続されているネットワーク要素のMACアドレスを学習するために使用される手順を定義します。ローカルラーニングは、コントロールプレーン、マネジメントプレーン、データプレーンの3つの学習手順すべてで実装できます。ただし、ほとんどのユースケースでは、データプレーンによるローカル学習で十分であると予想されます。
o Remote learning defines the procedures used for learning MAC addresses of network elements remotely connected to a MAC-VRF, i.e., far-end PEs. Remote learning procedures defined in [RFC7432] advocate using only control-plane learning, BGP specifically. Through the use of BGP EVPN NLRIs, the remote PE has the capability of advertising all the MAC addresses present in its local FIB.
o リモートラーニングは、MAC-VRF、つまり遠端のPEにリモート接続されているネットワーク要素のMACアドレスを学習するために使用される手順を定義します。 [RFC7432]で定義されているリモート学習手順は、コントロールプレーン学習、特にBGPのみを使用することを提唱しています。 BGP EVPN NLRIを使用することにより、リモートPEはローカルFIBに存在するすべてのMACアドレスをアドバタイズすることができます。
In EVPN, MAC addresses are advertised via the MAC/IP Advertisement route, as discussed in [RFC7432]. Optionally, an IP address can be advertised along with the MAC address advertisement. However, there are certain rules put in place in terms of IP address usage: if the MAC/IP Route contains an IP address, this particular IP address correlates directly with the advertised MAC address. Such advertisement allows us to build a proxy ARP / Neighbor Discovery (ND) table populated with the IP<->MAC bindings received from all the remote nodes.
EVPNでは、[RFC7432]で説明されているように、MACアドレスはMAC / IPアドバタイズルートを介してアドバタイズされます。オプションで、MACアドレスアドバタイズメントとともにIPアドレスをアドバタイズできます。ただし、IPアドレスの使用に関しては、特定のルールが適用されています。MAC/ IPルートにIPアドレスが含まれている場合、この特定のIPアドレスは、アドバタイズされたMACアドレスと直接相関します。このようなアドバタイズにより、すべてのリモートノードから受信したIP <-> MACバインディングが入力されたプロキシARP /近隣探索（ND）テーブルを構築できます。
Furthermore, based on these bindings, a local MAC-VRF can now provide proxy ARP/ND functionality for all ARP requests and ND solicitations directed to the IP address pool learned through BGP. Therefore, the amount of unnecessary L2 flooding (ARP/ND requests/solicitations in this case) can be further reduced by the introduction of proxy ARP/ND functionality across all EVI MAC-VRFs.
さらに、これらのバインディングに基づいて、ローカルMAC-VRFは、BGPを通じて学習されたIPアドレスプールに向けられたすべてのARP要求およびND要請にプロキシARP / ND機能を提供できるようになりました。したがって、すべてのEVI MAC-VRFにプロキシARP / ND機能を導入することで、不要なL2フラッディング（この場合はARP / ND要求/要請）の量をさらに削減できます。
Given that all locally learned MAC addresses are advertised through BGP to all remote PEs, suppressing flooding of any unknown unicast traffic towards the remote PEs is a feasible network optimization.
ローカルで学習したすべてのMACアドレスがBGPを介してすべてのリモートPEにアドバタイズされる場合、リモートPEへの不明なユニキャストトラフィックのフラッディングを抑制することは、実行可能なネットワーク最適化です。
The assumption in the use case is made that any network device that appears on a remote MAC-VRF will somehow signal its presence to the network. This signaling can be done through, for example, gratuitous ARPs. Once the remote PE acknowledges the presence of the node in the MAC-VRF, it will do two things: install its MAC address in its local FIB and advertise this MAC address to all other BGP speakers via EVPN NLRI. Therefore, we can assume that any active MAC address is propagated and learned through the entire EVI. Given that MAC addresses become prepopulated -- once nodes are alive on the network -- there is no need to flood any unknown unicast towards the remote PEs. If the owner of a given destination MAC is active, the BGP route will be present in the local RIB and FIB, assuming that the BGP import policies are successfully applied; otherwise, the owner of such destination MAC is not present on the network.
ユースケースでは、リモートMAC-VRFに表示されるネットワークデバイスはなんらかの理由でその存在をネットワークに通知すると想定されています。このシグナリングは、たとえば、無償のARPを介して行うことができます。リモートPEがMAC-VRF内のノードの存在を確認すると、ローカルPEBにMACアドレスをインストールし、EVPN NLRIを介して他のすべてのBGPスピーカーにこのMACアドレスをアドバタイズします。したがって、アクティブなMACアドレスはEVI全体に伝播および学習されると想定できます。 MACアドレスが事前に入力されている場合（ノードがネットワーク上でアクティブになると）、不明なユニキャストをリモートPEにフラッディングする必要はありません。特定の宛先MACの所有者がアクティブである場合、BGPインポートポリシーが正常に適用されていると想定して、BGPルートはローカルRIBおよびFIBに存在します。そうでなければ、そのような宛先MACの所有者はネットワーク上に存在しません。
It is worth noting that unknown unicast flooding must not be suppressed unless (at least) one of the following two statements is given: a) control- or management-plane learning is performed throughout the entire EVI for all the MACs or b) all the EVI-attached devices signal their presence when they come up (Gratuitous ARP (GARP) packets or similar).
（少なくとも）次の2つのステートメントのいずれかが与えられない限り、未知のユニキャストフラッディングを抑制してはならないことに注意してください。 EVIに接続されたデバイスは、起動時にその存在を知らせます（Gratuitous ARP（GARP）パケットなど）。
In a scenario in which both L2 and L3 services are needed over the same physical topology, some interaction between EVPN and IP-VPN is required. A common way of stitching the two service planes is through the use of an Integrated Routing and Bridging (IRB) interface, which allows for traffic to be either routed or bridged depending on its destination MAC address. If the destination MAC address is the one from the IRB interface, traffic needs to be passed through a routing module and potentially be either routed to a remote PE or forwarded to a local subnet. If the destination MAC address is not the one from the IRB interface, the MAC-VRF follows standard bridging procedures.
L2とL3の両方のサービスが同じ物理トポロジ上で必要とされるシナリオでは、EVPNとIP-VPN間の相互作用が必要です。 2つのサービスプレーンをつなぎ合わせる一般的な方法は、統合ルーティングおよびブリッジング（IRB）インターフェイスを使用することです。これにより、宛先MACアドレスに応じてトラフィックをルーティングまたはブリッジングできます。宛先MACアドレスがIRBインターフェイスからのものである場合、トラフィックはルーティングモジュールを通過する必要があり、リモートPEにルーティングされるか、ローカルサブネットに転送される可能性があります。宛先MACアドレスがIRBインターフェイスからのものではない場合、MAC-VRFは標準のブリッジング手順に従います。
A typical example of EVPN inter-subnet forwarding would be a scenario in which multiple IP subnets are part of a single or multiple EVIs, and they all belong to a single IP-VPN. In such topologies, it is desired that inter-subnet traffic can be efficiently routed without any tromboning effects in the network. Due to the overlapping physical and service topology in such scenarios, all inter-subnet connectivity will be locally routed through the IRB interface.
EVPNサブネット間転送の典型的な例は、複数のIPサブネットが単一または複数のEVIの一部であり、それらすべてが単一のIP-VPNに属しているシナリオです。このようなトポロジでは、サブネット間トラフィックをネットワークでトロンボーン効果なしに効率的にルーティングできることが望まれます。このようなシナリオでは物理トポロジとサービストポロジが重複しているため、サブネット間の接続はすべて、IRBインターフェイスを介してローカルにルーティングされます。
In addition to optimizing the traffic patterns in the network, local inter-subnet forwarding also greatly optimizes the amount of processing needed to cross the subnets. Through EVPN MAC advertisements, the local PE learns the real destination MAC address associated with the remote IP address and the inter-subnet forwarding can happen locally. When the packet is received at the egress PE, it is directly mapped to an egress MAC-VRF and bypasses any egress IP-VPN processing.
ネットワーク内のトラフィックパターンを最適化することに加えて、ローカルサブネット間転送は、サブネットを通過するために必要な処理量を大幅に最適化します。 EVPN MACアドバタイズを通じて、ローカルPEはリモートIPアドレスに関連付けられた実際の宛先MACアドレスを学習し、サブネット間転送がローカルで発生する可能性があります。パケットが出力PEで受信されると、出力MAC-VRFに直接マッピングされ、出力IP-VPN処理をバイパスします。
Please refer to [EVPN-INTERSUBNET] for more information about the IP inter-subnet forwarding procedures in EVPN.
EVPNでのIPサブネット間転送手順の詳細については、[EVPN-INTERSUBNET]を参照してください。
Assuming that the services are set up according to Figure 1 in Section 3, the following flow optimization processes will take place in terms of creating, receiving, and forwarding packets across the network.
セクション3の図1に従ってサービスが設定されていると仮定すると、ネットワーク全体でパケットを作成、受信、および転送することに関して、次のフロー最適化プロセスが行われます。
Using Figure 1 in Section 3, consider EVI400 residing on PE1, PE2, and PE3 connecting CE2 and CE3 networks. Also, consider that PE1 and PE2 are part of the all-active multihoming ES for CE2, and that PE2 is elected designated forwarder for EVI400. We assume that all the PEs implement the proxy ARP functionality in the MAC-VRF-400 context.
セクション3の図1を使用して、CE2およびCE3ネットワークを接続するPE1、PE2、およびPE3にあるEVI400を検討してください。また、PE1とPE2はCE2のすべてアクティブなマルチホーミングESの一部であり、PE2はEVI400の指定フォワーダーに選出されていることを考慮してください。すべてのPEがMAC-VRF-400コンテキストでプロキシARP機能を実装すると想定します。
In this scenario, PE3 will not only advertise the MAC addresses through the EVPN MAC Advertisement route but also IP addresses of individual hosts (i.e., /32 prefixes) behind CE3. Upon receiving the EVPN routes, PE1 and PE2 will install the MAC addresses in the MAC-VRF-400 FIB and, based on the associated received IP addresses, PE1 and PE2 can now build a proxy ARP table within the context of MAC-VRF-400.
このシナリオでは、PE3はEVPN MACアドバタイズルートを介してMACアドレスをアドバタイズするだけでなく、CE3の背後にある個々のホストのIPアドレス（つまり、/ 32プレフィックス）もアドバタイズします。 EVPNルートを受信すると、PE1とPE2はMACアドレスをMAC-VRF-400 FIBにインストールし、関連付けられた受信IPアドレスに基づいて、PE1とPE2はMAC-VRF-のコンテキスト内でプロキシARPテーブルを構築できるようになります。 400。
From the forwarding perspective, when a node behind CE2 sends a frame destined to a node behind CE3, it will first send an ARP request to, for example, PE2 (based on the result of the CE2 hashing). Assuming that PE2 has populated its proxy ARP table for all active nodes behind the CE3, and that the IP address in the ARP message matches the entry in the table, PE2 will respond to the ARP request with the actual MAC address on behalf of the node behind CE3.
転送の観点から見ると、CE2の背後にあるノードがCE3の背後にあるノードを宛先とするフレームを送信する場合、まずCE2のハッシュの結果に基づいて、PE2などにARP要求を送信します。 PE2がCE3の背後にあるすべてのアクティブノードのプロキシARPテーブルにデータを入力し、ARPメッセージのIPアドレスがテーブルのエントリと一致すると、PE2はノードに代わって実際のMACアドレスでARP要求に応答しますCE3の背後にあります。
Once the nodes behind CE2 learn the actual MAC address of the nodes behind CE3, all the MAC-to-MAC communications between the two networks will be unicast.
CE2の背後にあるノードがCE3の背後にあるノードの実際のMACアドレスを学習すると、2つのネットワーク間のすべてのMAC間通信はユニキャストになります。
Using Figure 1 in Section 3, consider EVI500 residing on PE1 and PE3 connecting CE1 and CE3 networks. Consider that both PE1 and PE3 have disabled unknown unicast flooding for this specific EVI context. Once the network devices behind CE3 come online, they will learn their MAC addresses and create local FIB entries for these devices. Note that local FIB entries could also be created through either a control or management plane between PE and CE as well. Consequently, PE3 will automatically create EVPN Type 2 MAC Advertisement routes and advertise all locally learned MAC addresses. The routes will also include the corresponding MPLS Label.
セクション3の図1を使用して、CE1およびCE3ネットワークを接続するPE1およびPE3にあるEVI500を検討してください。 PE1とPE3の両方で、この特定のEVIコンテキストの不明なユニキャストフラッディングが無効になっていることを考慮してください。 CE3の背後にあるネットワークデバイスがオンラインになると、MACデバイスを学習し、これらのデバイスのローカルFIBエントリを作成します。ローカルFIBエントリは、PEとCE間のコントロールプレーンまたは管理プレーンを介して作成することもできます。その結果、PE3は自動的にEVPNタイプ2 MACアドバタイズルートを作成し、ローカルで学習したすべてのMACアドレスをアドバタイズします。ルートには、対応するMPLSラベルも含まれます。
Given that PE1 automatically learns and installs all MAC addresses behind CE3, its MAC-VRF FIB will already be prepopulated with the respective next-hops and label assignments associated with the MAC addresses behind CE3. As such, as soon as the traffic sent by CE1 to nodes behind CE3 is received into the context of EVI500, PE1 will push the MPLS Label(s) onto the original Ethernet frame and send the packet to the MPLS network. As usual, once PE3 receives this packet, and depending on the forwarding model, PE3 will either do a next-hop lookup in the EVI500 context or just forward the traffic directly to the CE3. In the case that PE1 MAC-VRF-500 does not have a MAC entry for a specific destination that CE1 is trying to reach, PE1 will drop the frame since unknown unicast flooding is disabled.
PE1はCE3の背後にあるすべてのMACアドレスを自動的に学習してインストールするため、そのMAC-VRF FIBには、CE3の背後にあるMACアドレスに関連付けられたそれぞれのネクストホップとラベル割り当てがすでに入力されています。したがって、CE1によってCE3の背後にあるノードに送信されたトラフィックがEVI500のコンテキストに受信されるとすぐに、PE1はMPLSラベルを元のイーサネットフレームにプッシュし、パケットをMPLSネットワークに送信します。通常どおり、PE3がこのパケットを受信すると、転送モデルに応じて、PE3はEVI500コンテキストでネクストホップルックアップを実行するか、トラフィックを直接CE3に転送します。 PE1 MAC-VRF-500にCE1が到達しようとしている特定の宛先のMACエントリがない場合、未知のユニキャストフラッディングが無効になっているため、PE1はフレームをドロップします。
Based on the assumption that all the MAC entries behind the CEs are prepopulated through gratuitous ARP and/or DHCP requests, if one specific MAC entry is not present in the MAC-VRF-500 FIB on PE1, the owner of that MAC is not alive on the network behind the CE3; hence, the traffic can be dropped at PE1 instead of flooding and consuming network bandwidth.
CEの背後にあるすべてのMACエントリが無償のARPまたはDHCP要求、あるいはその両方を介して事前に入力されているという想定に基づいて、PE1のMAC-VRF-500 FIBに特定のMACエントリが1つも存在しない場合、そのMACの所有者は生存していませんCE3の背後にあるネットワーク上。したがって、トラフィックをフラッディングしてネットワーク帯域幅を消費する代わりに、PE1でトラフィックをドロップできます。
9.2.3. Optimization of Inter-subnet Forwarding Example for CE3-to-CE2 Traffic
9.2.3. CE3からCE2へのトラフィックのサブネット間転送の例の最適化
Using Figure 1 in Section 3, consider that there is an IP-VPN 666 context residing on PE1, PE2, and PE3, which connects CE1, CE2, and CE3 into a single IP-VPN domain. Also consider that there are two EVIs present on the PEs, EVI600 and EVI60. Each IP subnet is associated with a different MAC-VRF context. Thus, there is a single subnet (subnet 600) between CE1 and CE3 that is established through EVI600. Similarly, there is another subnet (subnet 60) between CE2 and CE3 that is established through EVI60. Since both subnets are part of the same IP-VPN, there is a mapping of each EVI (or individual subnet) to a local IRB interface on the three PEs.
セクション3の図1を使用して、PE1、PE2、およびPE3にIP-VPN 666コンテキストがあり、CE1、CE2、およびCE3を単一のIP-VPNドメインに接続することを検討してください。また、PEにはEVI600とEVI60の2つのEVIがあることも考慮してください。各IPサブネットは、異なるMAC-VRFコンテキストに関連付けられています。したがって、EVI600を介して確立されるCE1とCE3の間に単一のサブネット（サブネット600）があります。同様に、CE2とCE3の間には、EVI60を介して確立された別のサブネット（サブネット60）があります。両方のサブネットは同じIP-VPNの一部であるため、3つのPEのローカルIRBインターフェイスへの各EVI（または個別のサブネット）のマッピングがあります。
If a node behind CE2 wants to communicate with a node on the same subnet seating behind CE3, the communication flow will follow the standard EVPN procedures, i.e., FIB lookup within the PE1 (or PE2) after adding the corresponding EVPN label to the MPLS Label stack (downstream label allocation from PE3 for EVI60).
CE2の背後にあるノードがCE3の背後にある同じサブネット上のノードと通信する場合、通信フローは標準のEVPN手順に従います。つまり、対応するEVPNラベルをMPLSラベルに追加した後、PE1（またはPE2）内のFIBルックアップスタック（PE3からのEVI60のダウンストリームラベル割り当て）。
When it comes to crossing the subnet boundaries, the ingress PE implements local inter-subnet forwarding. For example, when a node behind CE2 (EVI60) sends a packet to a node behind CE1 (EVI600), the destination IP address will be in the subnet 600, but the destination MAC address will be the address of the source node's default gateway, which in this case will be an IRB interface on PE1 (connecting EVI60 to IP-VPN 666). Once PE1 sees the traffic destined to its own MAC address, it will route the packet to EVI600, i.e., it will change the source MAC address to the one of the IRB interface in EVI600 and change the destination MAC address to the address belonging to the node behind CE1, which is already populated in the MAC-VRF-600 FIB, either through data- or control-plane learning.
サブネット境界を越える場合、入力PEはローカルサブネット間転送を実装します。たとえば、CE2（EVI60）の背後にあるノードがCE1（EVI600）の背後にあるノードにパケットを送信すると、宛先IPアドレスはサブネット600にありますが、宛先MACアドレスはソースノードのデフォルトゲートウェイのアドレスになります。この場合、これはPE1のIRBインターフェイスになります（EVI60をIP-VPN 666に接続）。 PE1は、自身のMACアドレス宛てのトラフィックを確認すると、パケットをEVI600にルーティングします。つまり、送信元MACアドレスをEVI600のIRBインターフェイスの1つに変更し、宛先MACアドレスをに属するアドレスに変更します。データプレーンまたはコントロールプレーンの学習により、MAC-VRF-600 FIBにすでに入力されているCE1の背後のノード。
An important optimization to be noted is the local inter-subnet forwarding in lieu of IP-VPN routing. If the node from subnet 60 (behind CE2) is sending a packet to the remote end-node on subnet 600 (behind CE3), the mechanism in place still honors the local inter-subnet (inter-EVI) forwarding.
注意すべき重要な最適化は、IP-VPNルーティングの代わりにローカルのサブネット間転送です。サブネット60（CE2の背後）からのノードがサブネット600（CE3の背後）のリモートエンドノードにパケットを送信している場合でも、適切なメカニズムはローカルサブネット間（EVI間）の転送を受け入れます。
In our use case, therefore, when the node from subnet 60 behind CE2 sends traffic to the node on subnet 600 behind CE3, the destination MAC address is the PE1 MAC-VRF-60 IRB MAC address. However, once the traffic locally crosses EVIs to EVI600 (via the IRB interface on PE1), the source MAC address is changed to that of the IRB interface and the destination MAC address is changed to the one advertised by PE3 via EVPN and already installed in MAC-VRF-600. The rest of the forwarding through PE1 is using the MAC-VRF-600 forwarding context and label space.
したがって、このユースケースでは、CE2の背後にあるサブネット60のノードがCE3の背後にあるサブネット600のノードにトラフィックを送信する場合、宛先MACアドレスはPE1 MAC-VRF-60 IRB MACアドレスです。ただし、トラフィックがローカルでEVIからEVI600に（PE1のIRBインターフェイス経由で）通過すると、送信元MACアドレスはIRBインターフェイスのアドレスに変更され、宛先MACアドレスはEVPNを介してPE3によってアドバタイズされ、すでにインストールされているアドレスに変更されます。 MAC-VRF-600。 PE1を介した残りの転送は、MAC-VRF-600転送コンテキストとラベルスペースを使用しています。
Another very relevant optimization is due to the fact that traffic between PEs is forwarded through EVPN rather than through IP-VPN. In the example described above for traffic from EVI60 on CE2 to EVI600 on CE3, there is no need for IP-VPN processing on the egress PE3. Traffic is forwarded either to the EVI600 context in PE3 for further MAC lookup and next-hop processing or directly to the node behind CE3, depending on the egress forwarding model being used.
PE間のトラフィックがIP-VPNではなくEVPNを介して転送されるという事実が、もう1つの非常に関連する最適化です。上記のCE2のEVI60からCE3のEVI600へのトラフィックの例では、出力PE3でIP-VPN処理を行う必要はありません。トラフィックは、使用される出力転送モデルに応じて、PE3のEVI600コンテキストに転送され、さらにMACルックアップとネクストホップ処理が行われるか、CE3の背後にあるノードに直接転送されます。
Please refer to the "Security Considerations" section in [RFC7432]. The standards produced by the SIDR Working Group address secure route origin authentication (e.g., RFCs 6480 through 6493) and route advertisement security (e.g., RFCs 8205 through 8211). They protect the integrity and authenticity of IP address advertisements and ASN/ IP prefix bindings. This document and [RFC7432] use BGP to convey other info (e.g., MAC addresses); thus, the protections offered by the SIDR WG RFCs are not applicable in this context.
[RFC7432]の「セキュリティに関する考慮事項」セクションを参照してください。 SIDRワーキンググループによって作成された標準は、安全なルート発信元認証（RFC 6480から6493など）およびルートアドバタイズメントセキュリティ（RFC 8205から8211など）に対応しています。 IPアドレスアドバタイズメントとASN / IPプレフィックスバインディングの整合性と信頼性を保護します。このドキュメントと[RFC7432]は、BGPを使用して他の情報（MACアドレスなど）を伝えます。したがって、SIDR WG RFCによって提供される保護は、このコンテキストには適用されません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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>。
[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>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、Ed。およびY. Rekhter、Ed。、「Auto-Discovery and SignalingのためのBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<https://www.rfc-editor.org/ info / rfc4761>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762]ラッセール、M。、エド。およびV. Kompella編、「Label Distribution Protocol（LDP）Signalingを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<https://www.rfc-editor.org/ info / rfc4762>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、DOI 10.17487 / RFC6074 、2011年1月、<https://www.rfc-editor.org/info/rfc6074>。
[EVPN-INTERSUBNET] Sajassi, A., Salam, S., Thoria, S., Drake, J., Rabadan, J., and L. Yong, "Integrated Routing and Bridging in EVPN", Work in Progress, draft-ietf-bess-evpn-inter-subnet-forwarding-03, February 2017.
[EVPN-INTERSUBNET] Sajassi、A.、Salam、S.、Thoria、S.、Drake、J.、Rabadan、J。、およびL. Yong、「EVPNにおける統合ルーティングとブリッジング」、作業中、ドラフト- ietf-bess-evpn-inter-subnet-forwarding-03、2017年2月。
Acknowledgments
謝辞
The authors want to thank Giles Heron for his detailed review of the document. We also thank Stefan Plug and Eric Wunan for their comments.
著者は、ドキュメントの詳細なレビューを提供してくれたGiles Heronに感謝します。また、Stefan PlugとEric Wunanのコメントにも感謝します。
Contributors
貢献者
The following people contributed substantially to the content of this document and should be considered coauthors:
次の人々はこのドキュメントの内容に実質的に貢献し、共著者と見なされるべきです：
Florin Balus Keyur Patel Aldrin Isaac Truman Boyes
みんなのパルスキュアパテルアルドリンアイザックトルーマンボイジー
Authors' Addresses
著者のアドレス
Jorge Rabadan (editor) Nokia 777 E. Middlefield Road Mountain View, CA 94043 United States America
Jorge Rabadan（editor）Nokia 777 E. Middlefield Road Mountain View、CA 94043アメリカ合衆国アメリカ
Email: jorge.rabadan@nokia.com
Senad Palislamovic Nokia
セナドパリスラモビッチノキア
Email: senad.palislamovic@nokia.com
Wim Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium
Wim Henderickx Nokia Copernicuslaan 50 2018アントワープベルギー
Email: wim.henderickx@nokia.com
Ali Sajassi Cisco
アリサハシシスコ
Email: sajassi@cisco.com
James Uttaro AT&T
James Uttaro AT＆T
Email: uttaro@att.com