[要約] RFC 7623は、PBB-EVPN（Provider Backbone Bridging Combined with Ethernet VPN）の仕様を定義しています。このRFCの目的は、スケーラブルなイーサネットベースのVPNソリューションを提供することです。
Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 7623 S. Salam
Category: Standards Track Cisco
ISSN: 2070-1721 N. Bitar
Verizon
A. Isaac
Juniper
W. Henderickx
Alcatel-Lucent
September 2015
Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)
イーサネットVPNと組み合わせたプロバイダーバックボーンブリッジング（PBB-EVPN）
Abstract
概要
This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN.
このドキュメントでは、プロバイダーバックボーンMAC（B-）を介してカスタマー/クライアントMAC（C-MAC）アドレスを集約することにより、BGP MACアドバタイズメントルートの数を減らすために、イーサネットプロバイダーバックボーンブリッジング（PBB）をイーサネットVPN（EVPN）と組み合わせる方法について説明します。 MAC）アドレス、C-MAC集約を使用したクライアントMACアドレスモビリティの提供、C-MAC学習のスコープのアクティブフローのみへの限定、サイトごとのポリシーの提供、トポロジー変更時のC-MACアドレスのフラッシュの回避。組み合わせたソリューションはPBB-EVPNと呼ばれます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7623.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7623で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://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. Requirements ....................................................4
3.1. MAC Advertisement Route Scalability ........................5
3.2. C-MAC Mobility Independent of B-MAC Advertisements .........5
3.3. C-MAC Address Learning and Confinement .....................5
3.4. Per-Site Policy Support ....................................6
3.5. No C-MAC Address Flushing for All-Active Multihoming .......6
4. Solution Overview ...............................................6
5. BGP Encoding ....................................................7
5.1. Ethernet Auto-Discovery Route ..............................7
5.2. MAC/IP Advertisement Route .................................7
5.3. Inclusive Multicast Ethernet Tag Route .....................8
5.4. Ethernet Segment Route .....................................8
5.5. ESI Label Extended Community ...............................8
5.6. ES-Import Route Target .....................................9
5.7. MAC Mobility Extended Community ............................9
5.8. Default Gateway Extended Community .........................9
6. Operation .......................................................9
6.1. MAC Address Distribution over Core .........................9
6.2. Device Multihoming .........................................9
6.2.1. Flow-Based Load-Balancing ...........................9
6.2.1.1. PE B-MAC Address Assignment ...............10
6.2.1.2. Automating B-MAC Address Assignment .......11
6.2.1.3. Split Horizon and Designated
Forwarder Election ........................12
6.2.2. Load-Balancing based on I-SID ......................12
6.2.2.1. PE B-MAC Address Assignment ...............12
6.2.2.2. Split Horizon and Designated
Forwarder Election ........................13
6.2.2.3. Handling Failure Scenarios ................13
6.3. Network Multihoming .......................................14
6.4. Frame Forwarding ..........................................14
6.4.1. Unicast ............................................15
6.4.2. Multicast/Broadcast ................................15
6.5. MPLS Encapsulation of PBB Frames ..........................16
7. Minimizing ARP/ND Broadcast ....................................16
8. Seamless Interworking with IEEE 802.1aq / 802.1Qbp .............17
8.1. B-MAC Address Assignment ..................................17
8.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement .......17
8.3. Operation: ................................................17
9. Solution Advantages ............................................18
9.1. MAC Advertisement Route Scalability .......................18
9.2. C-MAC Mobility Independent of B-MAC Advertisements ........18
9.3. C-MAC Address Learning and Confinement ....................19
9.4. Seamless Interworking with 802.1aq Access Networks ........19
9.5. Per-Site Policy Support ...................................20
9.6. No C-MAC Address Flushing for All-Active Multihoming ......20
10. Security Considerations .......................................20
11. IANA Considerations ...........................................20
12. References ....................................................21
12.1. Normative References .....................................21
12.2. Informative References ...................................21
Acknowledgements ..................................................22
Contributors ......................................................22
Authors' Addresses ................................................23
[RFC7432] introduces a solution for multipoint Layer 2 Virtual Private Network (L2VPN) services, with advanced multihoming capabilities, using BGP for distributing customer/client MAC address reachability information over the core MPLS/IP network. [PBB] defines an architecture for Ethernet Provider Backbone Bridging (PBB), where MAC tunneling is employed to improve service instance and MAC address scalability in Ethernet as well as VPLS networks [RFC7080].
[RFC7432]は、コアMPLS / IPネットワークを介して顧客/クライアントMACアドレス到達可能性情報を配信するためにBGPを使用する、高度なマルチホーミング機能を備えたマルチポイントレイヤー2仮想プライベートネットワーク（L2VPN）サービスのソリューションを紹介します。 [PBB]は、イーサネットプロバイダーバックボーンブリッジング（PBB）のアーキテクチャを定義します。MACトンネリングは、イーサネットおよびVPLSネットワーク[RFC7080]のサービスインスタンスとMACアドレスのスケーラビリティを向上させるために使用されます。
In this document, we discuss how PBB can be combined with EVPN in order to: reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN.
このドキュメントでは、PBBをEVPNと組み合わせる方法について説明します。プロバイダーバックボーンMAC（B-MAC）アドレスを介してカスタマー/クライアントMAC（C-MAC）アドレスを集約し、BGP MACアドバタイズメントルートの数を減らし、クライアントを提供します。 C-MACアグリゲーションを使用したMACアドレスモビリティ、C-MAC学習のスコープをアクティブフローのみに制限し、サイトごとのポリシーを提供し、トポロジ変更時のC-MACアドレスのフラッシュを回避します。組み合わせたソリューションはPBB-EVPNと呼ばれます。
ARP: Address Resolution Protocol BEB: Backbone Edge Bridge B-MAC: Backbone MAC B-VID: Backbone VLAN ID CE: Customer Edge C-MAC: Customer/Client MAC ES: Ethernet Segment ESI: Ethernet Segment Identifier EVI: EVPN Instance EVPN: Ethernet VPN I-SID: Service Instance Identifier (24 bits and global within a PBB network see [RFC7080]) LSP: Label Switched Path MP2MP: Multipoint to Multipoint MP2P: Multipoint to Point NA: Neighbor Advertisement ND: Neighbor Discovery P2MP: Point to Multipoint P2P: Point to Point PBB: Provider Backbone Bridge PE: Provider Edge RT: Route Target VPLS: Virtual Private LAN Service
ARP：アドレス解決プロトコルBEB：バックボーンエッジブリッジB-MAC：バックボーンMAC B-VID：バックボーンVLAN ID CE：カスタマーエッジC-MAC：カスタマー/クライアントMAC ES：イーサネットセグメントESI：イーサネットセグメント識別子EVI：EVPNインスタンスEVPN：イーサネットVPN I-SID：サービスインスタンス識別子（PBBネットワーク内の24ビットおよびグローバル[RFC7080]を参照）LSP：ラベルスイッチドパスMP2MP：マルチポイントからマルチポイントMP2P：マルチポイントからポイントNA：ネイバーアドバタイズメントND：ネイバー探索P2MP：ポイントからマルチポイントP2P：ポイントツーポイントPBB：プロバイダーバックボーンブリッジPE：プロバイダーエッジRT：ルートターゲットVPLS：仮想プライベートLANサービス
Single-Active Redundancy Mode: When only a single PE, among a group of PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet segment, then the Ethernet segment is defined to be operating in Single-Active redundancy mode.
単一アクティブ冗長モード：イーサネットセグメントに接続されたPEのグループのうち、単一のPEのみがそのイーサネットセグメントとの間でトラフィックを転送できる場合、イーサネットセグメントは単一アクティブ冗長モードで動作するように定義されます。 。
All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward traffic to/from that Ethernet segment, then the Ethernet segment is defined to be operating in All-Active redundancy mode.
オールアクティブ冗長モード：イーサネットセグメントに接続されているすべてのPEがそのイーサネットセグメントとの間でトラフィックを転送できる場合、イーサネットセグメントはオールアクティブ冗長モードで動作するように定義されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14 [RFC2119]で説明されているように解釈されます。
The requirements for PBB-EVPN include all the requirements for EVPN that were described in [RFC7209], in addition to the following:
PBB-EVPNの要件には、以下に加えて、[RFC7209]で説明されているEVPNのすべての要件が含まれます。
In typical operation, an EVPN PE sends a BGP MAC Advertisement route per C-MAC address. In certain applications, this poses scalability challenges, as is the case in data center interconnect (DCI) scenarios where the number of virtual machines (VMs), and hence the number of C-MAC addresses, can be in the millions. In such scenarios, it is required to reduce the number of BGP MAC Advertisement routes by relying on a 'MAC summarization' scheme, as is provided by PBB.
通常の操作では、EVPN PEはC-MACアドレスごとにBGP MACアドバタイズメントルートを送信します。特定のアプリケーションでは、これにより、仮想マシン（VM）の数、つまりC-MACアドレスの数が数百万になる可能性のあるデータセンター相互接続（DCI）シナリオの場合のように、スケーラビリティの課題が生じます。このようなシナリオでは、PBBが提供する「MAC要約」スキームに依存して、BGP MACアドバタイズメントルートの数を減らす必要があります。
Certain applications, such as virtual machine mobility, require support for fast C-MAC address mobility. For these applications, when using EVPN, the virtual machine MAC address needs to be transmitted in BGP MAC Advertisement route. Otherwise, traffic would be forwarded to the wrong segment when a virtual machine moves from one ES to another. This means MAC address prefixes cannot be used in data center applications.
仮想マシンモビリティなどの特定のアプリケーションでは、高速C-MACアドレスモビリティのサポートが必要です。これらのアプリケーションでは、EVPNを使用する場合、仮想マシンのMACアドレスをBGP MACアドバタイズメントルートで送信する必要があります。そうしないと、仮想マシンがあるESから別のESに移動するときに、トラフィックが間違ったセグメントに転送されます。つまり、MACアドレスプレフィックスはデータセンターアプリケーションでは使用できません。
In order to support C-MAC address mobility, while retaining the scalability benefits of MAC summarization, PBB technology is used. It defines a B-MAC address space that is independent of the C-MAC address space, and aggregates C-MAC addresses via a single B-MAC address.
C-MACアドレスモビリティをサポートするために、MAC集約のスケーラビリティの利点を維持しながら、PBBテクノロジーが使用されます。 C-MACアドレススペースから独立したB-MACアドレススペースを定義し、単一のB-MACアドレスを介してC-MACアドレスを集約します。
In EVPN, all the PE nodes participating in the same EVPN instance are exposed to all the C-MAC addresses learned by any one of these PE nodes because a C-MAC learned by one of the PE nodes is advertised in BGP to other PE nodes in that EVPN instance. This is the case even if some of the PE nodes for that EVPN instance are not involved in forwarding traffic to, or from, these C-MAC addresses. Even if an implementation does not install hardware forwarding entries for C-MAC addresses that are not part of active traffic flows on that PE, the device memory is still consumed by keeping record of the C-MAC addresses in the routing information base (RIB) table. In network applications with millions of C-MAC addresses, this introduces a non-trivial waste of PE resources. As such, it is required to confine the scope of visibility of C-MAC addresses to only those PE nodes that are actively involved in forwarding traffic to, or from, these addresses.
EVPNでは、同じEVPNインスタンスに参加しているすべてのPEノードは、これらのPEノードのいずれかによって学習されたすべてのC-MACアドレスに公開されます。これは、PEノードの1つによって学習されたC-MACが、BGPで他のPEノードにアドバタイズされるためです。そのEVPNインスタンスで。これは、そのEVPNインスタンスの一部のPEノードがこれらのC-MACアドレスとの間のトラフィックの転送に関与していない場合でも当てはまります。実装が、そのPE上のアクティブなトラフィックフローの一部ではないC-MACアドレスのハードウェア転送エントリをインストールしない場合でも、ルーティング情報ベース（RIB）にC-MACアドレスの記録を保持することにより、デバイスメモリが消費されます。テーブル。数百万のC-MACアドレスを持つネットワークアプリケーションでは、これはPEリソースの重要な無駄をもたらします。そのため、C-MACアドレスの可視性の範囲を、これらのアドレスとの間のトラフィック転送に積極的に関与しているPEノードのみに限定する必要があります。
In many applications, it is required to be able to enforce connectivity policy rules at the granularity of a site (or segment). This includes the ability to control which PE nodes in the network can forward traffic to, or from, a given site. Both EVPN and PBB-EVPN are capable of providing this granularity of policy control. In the case where the policy needs to be at the granularity of per C-MAC address, then the C-MAC address should be learned in the control plane (in BGP) per [RFC7432].
多くのアプリケーションでは、サイト（またはセグメント）の粒度で接続ポリシールールを適用できる必要があります。これには、ネットワーク内のどのPEノードが特定のサイトとの間でトラフィックを転送できるかを制御する機能が含まれます。 EVPNとPBB-EVPNはどちらも、このようなきめ細かいポリシー制御を提供できます。ポリシーがC-MACアドレスごとの細かさである必要がある場合、C-MACアドレスは[RFC7432]に従って（BGPの）コントロールプレーンで学習される必要があります。
Just as in [RFC7432], it is required to avoid C-MAC address flushing upon link, port, or node failure for All-Active multihomed segments.
[RFC7432]と同様に、All-Activeマルチホームセグメントのリンク、ポート、またはノードの障害時にC-MACアドレスのフラッシュを回避する必要があります。
The solution involves incorporating IEEE Backbone Edge Bridge (BEB) functionality on the EVPN PE nodes similar to PBB-VPLS, where BEB functionality is incorporated in the VPLS PE nodes. The PE devices would then receive 802.1Q Ethernet frames from their attachment circuits, encapsulate them in the PBB header, and forward the frames over the IP/MPLS core. On the egress EVPN PE, the PBB header is removed following the MPLS disposition, and the original 802.1Q Ethernet frame is delivered to the customer equipment.
このソリューションには、BEB機能がVPLS PEノードに組み込まれているPBB-VPLSと同様に、EVPN PEノードにIEEEバックボーンエッジブリッジ（BEB）機能を組み込むことが含まれます。次に、PEデバイスは、接続回路から802.1Qイーサネットフレームを受信し、それらをPBBヘッダーにカプセル化して、IP / MPLSコアを介してフレームを転送します。出力EVPN PEでは、MPLSの後処理に続いてPBBヘッダーが削除され、元の802.1Qイーサネットフレームが顧客の機器に配信されます。
BEB +--------------+ BEB
|| | | ||
\/ | | \/
+----+ AC1 +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE2|
+----+\ | PE1| | IP/MPLS | | PE3| +----+
\ +----+ | Network | +----+
\ | |
AC2\ +----+ | |
\| | | |
| PE2| | |
+----+ | |
/\ +--------------+
||
BEB
<-802.1Q-> <------PBB over MPLS------> <-802.1Q->
Figure 1: PBB-EVPN Network
図1：PBB-EVPNネットワーク
The PE nodes perform the following functions:
PEノードは次の機能を実行します。
- Learn customer/client MAC addresses (C-MACs) over the attachment circuits in the data plane, per normal bridge operation.
- 通常のブリッジ操作ごとに、データプレーンの接続回線を介して顧客/クライアントMACアドレス（C-MAC）を学習します。
- Learn remote C-MAC to B-MAC bindings in the data plane for traffic received from the core per the bridging operation described in [PBB].
- [PBB]で説明されているブリッジング操作に従ってコアから受信したトラフィックのデータプレーンで、リモートC-MACからB-MACへのバインディングを学習します。
- Advertise local B-MAC address reachability information in BGP to all other PE nodes in the same set of service instances. Note that every PE has a set of B-MAC addresses that uniquely identifies the device. B-MAC address assignment is described in details in Section 6.2.2.
- BGPのローカルB-MACアドレス到達可能性情報を、同じサービスインスタンスのセット内の他のすべてのPEノードにアドバタイズします。すべてのPEには、デバイスを一意に識別する一連のB-MACアドレスがあることに注意してください。 B-MACアドレスの割り当てについては、セクション6.2.2で詳しく説明します。
- Build a forwarding table from remote BGP advertisements received associating remote B-MAC addresses with remote PE IP addresses and the associated MPLS label(s).
- リモートB-MACアドレスをリモートPE IPアドレスおよび関連するMPLSラベルに関連付けて受信したリモートBGPアドバタイズメントから転送テーブルを作成します。
PBB-EVPN leverages the same BGP routes and attributes defined in [RFC7432], adapted as described below.
PBB-EVPNは、[RFC7432]で定義されているものと同じBGPルートと属性を利用して、以下に説明するように調整されています。
This route and all of its associated modes are not needed in PBB-EVPN because PBB encapsulation provides the required level of indirection for C-MAC addresses -- i.e., an ES can be represented by a B-MAC address for the purpose of data-plane learning/forwarding.
PBBカプセル化はC-MACアドレスに必要なレベルの間接化を提供するため、このルートとそれに関連するすべてのモードはPBB-EVPNでは必要ありません。つまり、ESはデータの目的でB-MACアドレスで表すことができます。平面学習/転送。
The receiving PE knows that it need not wait for the receipt of the Ethernet A-D (auto-discovery) route for route resolution by means of the reserved ESI encoded in the MAC Advertisement route: the ESI values of 0 and MAX-ESI indicate that the receiving PE can resolve the path without an Ethernet A-D route.
受信側のPEは、MACアドバタイズメントルートでエンコードされた予約済みESIを使用して、ルート解決のためにイーサネットAD（自動検出）ルートの受信を待つ必要がないことを認識しています。0とMAX-ESIのESI値は、受信PEは、イーサネットADルートなしでパスを解決できます。
The EVPN MAC/IP Advertisement route is used to distribute B-MAC addresses of the PE nodes instead of the C-MAC addresses of end-stations/hosts. This is because the C-MAC addresses are learned in the data plane for traffic arriving from the core. The MAC Advertisement route is encoded as follows:
EVPN MAC / IPアドバタイズメントルートは、エンドステーション/ホストのC-MACアドレスではなく、PEノードのB-MACアドレスを配布するために使用されます。これは、C-MACアドレスがコアから到着するトラフィックのデータプレーンで学習されるためです。 MACアドバタイズメントルートは次のようにエンコードされます。
- The MAC address field contains the B-MAC address.
- MACアドレスフィールドには、B-MACアドレスが含まれます。
- The Ethernet Tag field is set to 0.
- イーサネットタグフィールドは0に設定されています。
- The Ethernet Segment Identifier field must be set to either 0 (for single-homed segments or multihomed segments with per-I-SID load-balancing) or to MAX-ESI (for multihomed segments with per-flow load-balancing). All other values are not permitted.
- イーサネットセグメント識別子フィールドは、0（シングルホームセグメントまたはI-SIDごとのロードバランシングを持つマルチホームセグメントの場合）またはMAX-ESI（フローごとのロードバランシングを持つマルチホームセグメントの場合）に設定する必要があります。他のすべての値は許可されていません。
- All other fields are set as defined in [RFC7432].
- 他のすべてのフィールドは、[RFC7432]の定義に従って設定されます。
This route is tagged with the RT corresponding to its EVI. This EVI is analogous to a B-VID.
このルートには、そのEVIに対応するRTがタグ付けされています。このEVIはB-VIDに類似しています。
This route is used for multicast pruning per I-SID. It is used for auto-discovery of PEs participating in a given I-SID so that a multicast tunnel (MP2P, P2P, P2MP, or MP2MP LSP) can be set up for that I-SID. [RFC7080] uses multicast pruning per I-SID based on [MMRP], which is a soft-state protocol. The advantages of multicast pruning using this BGP route over [MMRP] are that a) it scales very well for a large number of PEs and b) it works with any type of LSP (MP2P, P2P, P2MP, or MP2MP); whereas, [MMRP] only works over P2P pseudowires. The Inclusive Multicast Ethernet Tag route is encoded as follows:
このルートは、I-SIDごとのマルチキャストプルーニングに使用されます。マルチキャストトンネル（MP2P、P2P、P2MP、またはMP2MP LSP）をそのI-SIDに設定できるように、特定のI-SIDに参加しているPEの自動検出に使用されます。 [RFC7080]は、ソフトステートプロトコルである[MMRP]に基づくI-SIDごとのマルチキャストプルーニングを使用します。 [MMRP]を介してこのBGPルートを使用するマルチキャストプルーニングの利点は、a）多数のPEに対して非常に適切にスケーリングされ、b）任意のタイプのLSP（MP2P、P2P、P2MP、またはMP2MP）で機能することです。一方、[MMRP]はP2P疑似配線でのみ機能します。包括的マルチキャストイーサネットタグルートは次のようにエンコードされます。
- The Ethernet Tag field is set with the appropriate I-SID value.
- イーサネットタグフィールドには、適切なI-SID値が設定されます。
- All other fields are set as defined in [RFC7432].
- 他のすべてのフィールドは、[RFC7432]の定義に従って設定されます。
This route is tagged with an RT. This RT SHOULD be set to a value corresponding to its EVI (which is analogous to a B-VID). The RT for this route MAY also be auto-derived from the corresponding Ethernet Tag (I-SID) based on the procedure specified in Section 5.1.2.1 of [OVERLAY].
このルートはRTでタグ付けされています。このRTは、そのEVIに対応する値に設定する必要があります（B-VIDに類似しています）。このルートのRTも、[OVERLAY]のセクション5.1.2.1で指定された手順に基づいて、対応するイーサネットタグ（I-SID）から自動導出される場合があります。
This route is used for auto-discovery of PEs belonging to a given redundancy group (e.g., attached to a given ES) per [RFC7432].
このルートは、[RFC7432]に基づいて、特定の冗長グループ（特定のESに接続されているなど）に属するPEの自動検出に使用されます。
This extended community is not used in PBB-EVPN. In [RFC7432], this extended community is used along with the Ethernet A-D route to advertise an MPLS label for the purpose of split-horizon filtering. Since in PBB-EVPN, the split-horizon filtering is performed natively using B-MAC source address, there is no need for this extended community.
この拡張コミュニティはPBB-EVPNでは使用されません。 [RFC7432]では、この拡張コミュニティはイーサネットA-Dルートと共に使用され、スプリットホライズンフィルタリングの目的でMPLSラベルをアドバタイズします。 PBB-EVPNでは、スプリットホライズンフィルタリングはB-MAC送信元アドレスを使用してネイティブに実行されるため、この拡張コミュニティは必要ありません。
This RT is used as defined in [RFC7432].
このRTは、[RFC7432]で定義されているとおりに使用されます。
This extended community is defined in [RFC7432] and it is used with a MAC route (B-MAC route in case of PBB-EVPN). The B-MAC route is tagged with the RT corresponding to its EVI (which is analogous to a B-VID). When this extended community is used along with a B-MAC route in PBB-EVPN, it indicates that all C-MAC addresses associated with that B-MAC address across all corresponding I-SIDs must be flushed.
この拡張コミュニティは[RFC7432]で定義されており、MACルート（PBB-EVPNの場合はB-MACルート）で使用されます。 B-MACルートには、そのEVI（B-VIDに類似）に対応するRTがタグ付けされています。この拡張コミュニティがPBB-EVPNのB-MACルートとともに使用される場合、対応するすべてのI-SIDでそのB-MACアドレスに関連付けられているすべてのC-MACアドレスをフラッシュする必要があることを示します。
When a PE first advertises a B-MAC, it MAY advertise it with this extended community where the sticky/static flag is set to 1 and the sequence number is set to zero. In such cases where the PE wants to signal the stickiness of a B-MAC, then when a flush indication is needed, the PE advertises the B-MAC along with the MAC Mobility extended community where the sticky/static flag remains set and the sequence number is incremented.
PEが最初にB-MACをアドバタイズするとき、スティッキ/スタティックフラグが1に設定され、シーケンス番号がゼロに設定されているこの拡張コミュニティでPEをアドバタイズする場合があります。 PEがB-MACのスティッキ性をシグナリングする必要がある場合、フラッシュ表示が必要なときに、PEはスティッキ/スタティックフラグが設定されたままのMACモビリティ拡張コミュニティとシーケンスとともにB-MACをアドバタイズします。番号が増加します。
This extended community is not used in PBB-EVPN.
この拡張コミュニティはPBB-EVPNでは使用されません。
This section discusses the operation of PBB-EVPN, specifically in areas where it differs from [RFC7432].
このセクションでは、特に[RFC7432]とは異なる領域でのPBB-EVPNの操作について説明します。
In PBB-EVPN, host MAC addresses (i.e., C-MAC addresses) need not be distributed in BGP. Rather, every PE independently learns the C-MAC addresses in the data plane via normal bridging operation. Every PE has a set of one or more unicast B-MAC addresses associated with it, and those are the addresses distributed over the core in MAC Advertisement routes.
PBB-EVPNでは、ホストMACアドレス（つまり、C-MACアドレス）をBGPで配布する必要はありません。むしろ、すべてのPEは、通常のブリッジング操作を介して、データプレーン内のC-MACアドレスを個別に学習します。すべてのPEには、1つ以上のユニキャストB-MACアドレスのセットが関連付けられています。これらのアドレスは、MACアドバタイズメントルートのコア全体に配布されるアドレスです。
This section describes the procedures for supporting device multihoming in an All-Active redundancy mode (i.e., flow-based load-balancing).
このセクションでは、All-Active冗長モード（つまり、フローベースの負荷分散）でデバイスのマルチホーミングをサポートする手順について説明します。
In [PBB], every BEB is uniquely identified by one or more B-MAC addresses. These addresses are usually locally administered by the service provider. For PBB-EVPN, the choice of B-MAC address(es) for the PE nodes must be examined carefully as it has implications on the proper operation of multihoming. In particular, for the scenario where a CE is multihomed to a number of PE nodes with All-Active redundancy mode, a given C-MAC address would be reachable via multiple PE nodes concurrently. Given that any given remote PE will bind the C-MAC address to a single B-MAC address, then the various PE nodes connected to the same CE must share the same B-MAC address. Otherwise, the MAC address table of the remote PE nodes will keep oscillating between the B-MAC addresses of the various PE devices. For example, consider the network of Figure 1, and assume that PE1 has B-MAC address BM1 and PE2 has B-MAC address BM2. Also, assume that both links from CE1 to the PE nodes are part of the same Ethernet link aggregation group. If BM1 is not equal to BM2, the consequence is that the MAC address table on PE3 will keep oscillating such that the C-MAC address M1 of CE1 would flip-flop between BM1 or BM2, depending on the load-balancing decision on CE1 for traffic destined to the core.
[PBB]では、すべてのBEBは1つ以上のB-MACアドレスによって一意に識別されます。これらのアドレスは通常、サービスプロバイダーによってローカルに管理されます。 PBB-EVPNの場合、マルチホーミングの適切な動作に影響を与えるため、PEノードのB-MACアドレスの選択は慎重に検討する必要があります。特に、CEがAll-Active冗長性モードで多数のPEノードにマルチホーム化されているシナリオでは、特定のC-MACアドレスは複数のPEノードを介して同時に到達可能です。特定のリモートPEがC-MACアドレスを単一のB-MACアドレスにバインドする場合、同じCEに接続されているさまざまなPEノードは同じB-MACアドレスを共有する必要があります。そうでない場合、リモートPEノードのMACアドレステーブルは、さまざまなPEデバイスのB-MACアドレス間で変動し続けます。たとえば、図1のネットワークを考えて、PE1にB-MACアドレスBM1があり、PE2にB-MACアドレスBM2があると仮定します。また、CE1からPEノードへの両方のリンクが同じイーサネットリンク集約グループの一部であると想定します。 BM1がBM2と等しくない場合、結果はPE3のMACアドレステーブルが発振し続け、CE1のC-MACアドレスM1がBM1またはBM2の間でフリップフロップし、CE1のロードバランシングの決定に応じてコア宛てのトラフィック。
Considering that there could be multiple sites (e.g., CEs) that are multihomed to the same set of PE nodes, then it is required for all the PE devices in a redundancy group to have a unique B-MAC address per site. This way, it is possible to achieve fast convergence in the case where a link or port failure impacts the attachment circuit connecting a single site to a given PE.
同じPEノードのセットにマルチホーム化された複数のサイト（CEなど）が存在する可能性があることを考慮すると、冗長グループ内のすべてのPEデバイスがサイトごとに一意のB-MACアドレスを持つ必要があります。このようにして、リンクまたはポートの障害が、単一サイトを特定のPEに接続している接続回線に影響を与える場合に、高速コンバージェンスを実現できます。
+---------+
+-------+ PE1 | IP/MPLS |
/ | |
CE1 | Network | PEr
M1 \ | |
+-------+ PE2 | |
/-------+ | |
/ | |
CE2 | |
M2 \ | |
\ | |
+------+ PE3 +---------+
Figure 2: B-MAC Address Assignment
図2：B-MACアドレスの割り当て
In the example network shown in Figure 2 above, two sites corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3, respectively. Assume that BM1 is the B-MAC used for the site corresponding to CE1. Similarly, BM2 is the B-MAC used for the site corresponding to CE2. On PE1, a single B-MAC address (BM1) is required for the site corresponding to CE1. On PE2, two B-MAC addresses (BM1 and BM2) are required, one per site. Whereas on PE3, a single B-MAC address (BM2) is required for the site corresponding to CE2. All three PE nodes would advertise their respective B-MAC addresses in BGP using the MAC Advertisement routes defined in [RFC7432]. The remote PE, PEr, would learn via BGP that BM1 is reachable via PE1 and PE2, whereas BM2 is reachable via both PE2 and PE3. Furthermore, PEr establishes, via the PBB bridge learning procedure, that C-MAC M1 is reachable via BM1, and C-MAC M2 is reachable via BM2. As a result, PEr can load-balance traffic destined to M1 between PE1 and PE2, as well as traffic destined to M2 between both PE2 and PE3. In the case of a failure that causes, for example, CE1 to be isolated from PE1, the latter can withdraw the route it has advertised for BM1. This way, PEr would update its path list for BM1 and will send all traffic destined to M1 over to PE2 only.
上記の図2のネットワーク例では、CE1とCE2に対応する2つのサイトが、それぞれPE1 / PE2とPE2 / PE3にデュアルホーム接続されています。 BM1がCE1に対応するサイトに使用されるB-MACであると想定します。同様に、BM2はCE2に対応するサイトに使用されるB-MACです。 PE1では、CE1に対応するサイトに単一のB-MACアドレス（BM1）が必要です。 PE2では、サイトごとに1つ、2つのB-MACアドレス（BM1およびBM2）が必要です。一方、PE3では、CE2に対応するサイトに単一のB-MACアドレス（BM2）が必要です。 3つのPEノードはすべて、[RFC7432]で定義されているMACアドバタイズメントルートを使用して、BGPでそれぞれのB-MACアドレスをアドバタイズします。リモートPE、PErは、BGPを介して、BM1がPE1とPE2を介して到達可能であるのに対し、BM2はPE2とPE3の両方を介して到達可能であることを学習します。さらに、Prは、PBBブリッジ学習手順を介して、C-MAC M1がBM1を介して到達可能であり、C-MAC M2がBM2を介して到達可能であることを確立します。その結果、PErは、PE1とPE2の間のM1宛てのトラフィックと、PE2とPE3の両方の間のM2宛てのトラフィックを負荷分散できます。たとえば、CE1がPE1から分離される原因となる障害の場合、後者は、BM1にアドバタイズしたルートを撤回できます。このようにして、PErはBM1のパスリストを更新し、M1宛てのすべてのトラフィックをPE2のみに送信します。
The PE B-MAC address used for single-homed or Single-Active sites can be automatically derived from the hardware (using for example the backplane's address and/or PE's reserved MAC pool ). However, the B-MAC address used for All-Active sites must be coordinated among the redundancy group members. To automate the assignment of this latter address, the PE can derive this B-MAC address from the MAC address portion of the CE's Link Aggregation Control Protocol (LACP) System Identifier by flipping the 'Locally Administered' bit of the CE's address. This guarantees the uniqueness of the B-MAC address within the network, and ensures that all PE nodes connected to the same All-Active CE use the same value for the B-MAC address.
シングルホームサイトまたはシングルアクティブサイトに使用されるPE B-MACアドレスは、ハードウェアから自動的に取得できます（たとえば、バックプレーンのアドレスやPEの予約済みMACプールを使用）。ただし、All-Activeサイトに使用されるB-MACアドレスは、冗長グループメンバー間で調整する必要があります。この後者のアドレスの割り当てを自動化するために、PEはCEのアドレスの「ローカル管理」ビットを反転することにより、CEのリンク集約制御プロトコル（LACP）システム識別子のMACアドレス部分からこのB-MACアドレスを取得できます。これにより、ネットワーク内のB-MACアドレスの一意性が保証され、同じAll-Active CEに接続されているすべてのPEノードがB-MACアドレスに同じ値を使用することが保証されます。
Note that with this automatic provisioning of the B-MAC address associated with All-Active CEs, it is not possible to support the uncommon scenario where a CE has multiple link bundles within the same LACP session towards the PE nodes, and the service involves hair-pinning traffic from one bundle to another. This is because the split-horizon filtering relies on B-MAC addresses rather than Site-ID Labels (as will be described in the next section). The operator must explicitly configure the B-MAC address for this fairly uncommon service scenario.
All-Active CEに関連付けられたB-MACアドレスのこの自動プロビジョニングでは、CEがPEノードへの同じLACPセッション内に複数のリンクバンドルを持ち、サービスにヘアが含まれるという珍しいシナリオをサポートできないことに注意してくださいあるバンドルから別のバンドルへのトラフィックの固定。これは、スプリットホライズンフィルタリングがサイトIDラベルではなくB-MACアドレスに依存しているためです（次のセクションで説明します）。オペレーターは、このかなり一般的ではないサービスシナリオのB-MACアドレスを明示的に構成する必要があります。
Whenever a B-MAC address is provisioned on the PE, either manually or automatically (as an outcome of CE auto-discovery), the PE MUST transmit a MAC Advertisement route for the B-MAC address with a downstream assigned MPLS label that uniquely identifies that address on the advertising PE. The route is tagged with the RTs of the associated EVIs as described above.
B-MACアドレスが手動または自動で（CE自動検出の結果として）PEにプロビジョニングされるときは常に、PEは、一意に識別するダウンストリーム割り当てMPLSラベルを使用して、B-MACアドレスのMACアドバタイズメントルートを送信する必要があります。広告PE上のアドレス。上記のように、ルートには関連するEVIのRTがタグ付けされます。
[RFC7432] relies on split-horizon filtering for a multi-homed ES,
where the ES label is used for egress filtering on the attachment
circuit in order to prevent forwarding loops. In PBB-EVPN, the B-MAC
source address can be used for the same purpose, as it uniquely
identifies the originating site of a given frame. As such, ES labels
are not used in PBB-EVPN, and the egress split-horizon filtering is
done based on the B-MAC source address. It is worth noting here that
[PBB] defines this B-MAC address-based filtering function as part of
the I-Component options; hence, no new functions are required to
support split-horizon filtering beyond what is already defined in
[PBB].
The Designated Forwarder (DF) election procedures are defined in [RFC7432].
Designated Forwarder（DF）選出手順は[RFC7432]で定義されています。
This section describes the procedures for supporting device multihoming in a Single-Active redundancy mode with per-I-SID load-balancing.
このセクションでは、I-SIDごとのロードバランシングを使用するシングルアクティブ冗長モードでデバイスマルチホーミングをサポートする手順について説明します。
In the case where per-I-SID load-balancing is desired among the PE nodes in a given redundancy group, multiple unicast B-MAC addresses are allocated per multihomed ES: Each PE connected to the multihomed segment is assigned a unique B-MAC. Every PE then advertises its B-MAC address using the BGP MAC Advertisement route. In this mode of operation, two B-MAC address-assignment models are possible:
特定の冗長グループ内のPEノード間でI-SIDごとのロードバランシングが必要な場合、マルチホームESごとに複数のユニキャストB-MACアドレスが割り当てられます。マルチホームセグメントに接続された各PEには、一意のB-MACが割り当てられます。次に、すべてのPEがBGP MACアドバタイズルートを使用してB-MACアドレスをアドバタイズします。この動作モードでは、2つのB-MACアドレス割り当てモデルが可能です。
- The PE may use a shared B-MAC address for all its single-homed segments and/or all its multi-homed Single-Active segments (e.g., segments operating in per-I-SID load-balancing mode).
- PEは、すべてのシングルホームセグメントおよび/またはすべてのマルチホームシングルアクティブセグメント（I-SIDごとのロードバランシングモードで動作するセグメントなど）に共有B-MACアドレスを使用できます。
- The PE may use a dedicated B-MAC address for each ES operating with per-I-SID load-balancing mode.
- PEは、I-SIDごとのロードバランシングモードで動作するESごとに専用のB-MACアドレスを使用できます。
A PE implementation MAY choose to support either the shared B-MAC address model or the dedicated B-MAC address model without causing any interoperability issues. The advantage of the dedicated B-MAC over the shared B-MAC address for multi-homed Single-Active segments, is that when C-MAC flushing is needed, fewer C-MAC addresses are impacted. Furthermore, it gives the disposition PE the ability to avoid C-MAC destination address lookup even though source C-MAC learning is still required in the data plane. Its disadvantage is that there are additional B-MAC advertisements in BGP.
PE実装は、相互運用性の問題を引き起こすことなく、共有B-MACアドレスモデルまたは専用B-MACアドレスモデルをサポートすることを選択できます。マルチホームのシングルアクティブセグメントの共有B-MACアドレスに対する専用B-MACの利点は、C-MACフラッシュが必要な場合に、影響を受けるC-MACアドレスが少なくなることです。さらに、データプレーンでソースC-MAC学習が依然として必要である場合でも、ディスポジションPEにC-MAC宛先アドレスルックアップを回避する機能を提供します。その欠点は、BGPに追加のB-MACアドバタイズがあることです。
A remote PE initially floods traffic to a destination C-MAC address, located in a given multihomed ES, to all the PE nodes configured with that I-SID. Then, when reply traffic arrives at the remote PE, it learns (in the data path) the B-MAC address and associated next-hop PE to use for said C-MAC address.
リモートPEは、最初に、特定のマルチホームESにある宛先C-MACアドレスへのトラフィックを、そのI-SIDで構成されたすべてのPEノードにフラッディングします。次に、応答トラフィックがリモートPEに到着すると、B-MACアドレスと、そのC-MACアドレスに使用する関連するネクストホップPEを（データパスで）学習します。
The procedures are similar to the flow-based load-balancing case, with the only difference being that the DF filtering must be applied to unicast as well as multicast traffic, and in both core-to-segment as well as segment-to-core directions.
手順はフローベースのロードバランシングの場合と似ていますが、唯一の違いは、DFフィルタリングをマルチキャストトラフィックだけでなくユニキャストトラフィックにも適用し、コアからセグメントおよびセグメントからコアの両方に適用する必要があることです。行き方。
When a PE connected to a multihomed ES loses connectivity to the segment, due to link or port failure, it needs to notify the remote PEs to trigger C-MAC address flushing. This can be achieved in one of two ways, depending on the B-MAC assignment model:
マルチホームESに接続されているPEがセグメントへの接続を失うと、リンクまたはポートの障害により、リモートPEに通知してC-MACアドレスフラッシュをトリガーする必要があります。これは、B-MAC割り当てモデルに応じて、次の2つの方法のいずれかで実現できます。
- If the PE uses a shared B-MAC address for multiple Ethernet segments, then the C-MAC flushing is signaled by means of having the failed PE re-advertise the MAC Advertisement route for the associated B-MAC, tagged with the MAC Mobility extended community attribute. The value of the Counter field in that attribute must be incremented prior to advertisement. This causes the remote PE nodes to flush all C-MAC addresses associated with the B-MAC in question. This is done across all I-SIDs that are mapped to the EVI of the withdrawn MAC route.
- PEが複数のイーサネットセグメントに共有B-MACアドレスを使用している場合、C-MACフラッシュは、失敗したPEが、関連付けられたB-MACのMACアドバタイズメントルートを再アドバタイズし、MACモビリティ拡張でタグ付けすることで通知されます。コミュニティ属性。その属性のCounterフィールドの値は、アドバタイズの前にインクリメントされる必要があります。これにより、リモートPEノードは、問題のB-MACに関連付けられたすべてのC-MACアドレスをフラッシュします。これは、撤回されたMACルートのEVIにマップされているすべてのI-SIDで行われます。
- If the PE uses a dedicated B-MAC address for each ES operating under per-I-SID load-balancing mode, the failed PE simply withdraws the B-MAC route previously advertised for that segment. This causes the remote PE nodes to flush all C-MAC addresses associated with the B-MAC in question. This is done across all I-SIDs that are mapped to the EVI of the withdrawn MAC route.
- PEがI-SID単位のロードバランシングモードで動作する各ESに専用のB-MACアドレスを使用する場合、障害が発生したPEは、そのセグメントに対して以前にアドバタイズされたB-MACルートを単に撤回します。これにより、リモートPEノードは、問題のB-MACに関連付けられたすべてのC-MACアドレスをフラッシュします。これは、撤回されたMACルートのEVIにマップされているすべてのI-SIDで行われます。
When a PE connected to a multihomed ES fails (i.e., node failure) or when the PE becomes completely isolated from the EVPN network, the remote PEs will start purging the MAC Advertisement routes that were advertised by the failed PE. This is done either as an outcome of the remote PEs detecting that the BGP session to the failed PE has gone down, or by having a Route Reflector withdrawing all the routes that were advertised by the failed PE. The remote PEs, in this case, will perform C-MAC address flushing as an outcome of the MAC Advertisement route withdrawals.
マルチホームESに接続されているPEに障害（ノード障害など）が発生した場合、またはPEがEVPNネットワークから完全に分離された場合、リモートPEは、障害が発生したPEによってアドバタイズされたMACアドバタイズメントルートのパージを開始します。これは、障害が発生したPEへのBGPセッションがダウンしたことをリモートPEが検出した結果として、またはルートリフレクターに、障害が発生したPEによってアドバタイズされたすべてのルートを撤回させることによって行われます。この場合、リモートPEは、MACアドバタイズメントルートの撤回の結果として、C-MACアドレスフラッシュを実行します。
For all failure scenarios (link/port failure, node failure, and PE node isolation), when the fault condition clears, the recovered PE re-advertises the associated ES route to other members of its redundancy group. This triggers the backup PE(s) in the redundancy group to block the I-SIDs for which the recovered PE is a DF. When a backup PE blocks the I-SIDs, it triggers a C-MAC address flush notification to the remote PEs by re-advertising the MAC Advertisement route for the associated B-MAC, with the MAC Mobility extended community attribute. The value of the Counter field in that attribute must be incremented prior to advertisement. This causes the remote PE nodes to flush all C-MAC addresses associated with the B-MAC in question. This is done across all I-SIDs that are mapped to the EVI of the withdrawn/re-advertised MAC route.
すべての障害シナリオ（リンク/ポート障害、ノード障害、およびPEノード分離）では、障害状態が解消すると、回復されたPEは関連するESルートをその冗長グループの他のメンバーに再アドバタイズします。これにより、冗長グループ内のバックアップPEがトリガーされ、リカバリされたPEがDFであるI-SIDがブロックされます。バックアップPEがI-SIDをブロックすると、関連付けられたB-MACのMACアドバタイズメントルートをMACモビリティ拡張コミュニティ属性で再アドバタイズすることにより、リモートPEへのC-MACアドレスフラッシュ通知をトリガーします。その属性のCounterフィールドの値は、アドバタイズの前にインクリメントされる必要があります。これにより、リモートPEノードは、問題のB-MACに関連付けられたすべてのC-MACアドレスをフラッシュします。これは、撤回/再アドバタイズされたMACルートのEVIにマップされているすべてのI-SIDで行われます。
When an Ethernet network is multihomed to a set of PE nodes running PBB-EVPN, Single-Active redundancy model can be supported with per-service instance (i.e., I-SID) load-balancing. In this model, DF election is performed to ensure that a single PE node in the redundancy group is responsible for forwarding traffic associated with a given I-SID. This guarantees that no forwarding loops are created. Filtering based on DF state applies to both unicast and multicast traffic, and in both access-to-core as well as core-to-access directions just like a Single-Active multihomed device scenario (but unlike an All-Active multihomed device scenario where DF filtering is limited to multi-destination frames in the core-to-access direction). Similar to a Single-Active multihomed device scenario, with load-balancing based on I-SID, a unique B-MAC address is assigned to each of the PE nodes connected to the multihomed network (segment).
イーサネットネットワークがPBB-EVPNを実行しているPEノードのセットにマルチホーム化されている場合、シングルアクティブ冗長モデルは、サービスインスタンス（I-SIDなど）のロードバランシングでサポートできます。このモデルでは、DF選出が実行され、冗長グループ内の単一のPEノードが、特定のI-SIDに関連付けられたトラフィックの転送を確実に担当します。これにより、転送ループが作成されないことが保証されます。 DF状態に基づくフィルタリングは、ユニキャストトラフィックとマルチキャストトラフィックの両方に適用され、シングルアクティブマルチホームデバイスシナリオと同様に、アクセスからコアへのアクセスとコアからアクセスへのアクセスの両方の方向に適用されます（ただし、 DFフィルタリングは、コアからアクセス方向への複数の宛先フレームに制限されています。シングルアクティブマルチホームデバイスシナリオと同様に、I-SIDに基づいたロードバランシングにより、マルチホームネットワーク（セグメント）に接続されている各PEノードに一意のB-MACアドレスが割り当てられます。
The frame-forwarding functions are divided in between the Bridge Module, which hosts the [PBB] BEB functionality, and the MPLS Forwarder which handles the MPLS imposition/disposition. The details of frame forwarding for unicast and multi-destination frames are discussed next.
フレーム転送機能は、[PBB] BEB機能をホストするブリッジモジュールと、MPLSインポジション/ディスポジションを処理するMPLSフォワーダーに分かれています。次に、ユニキャストフレームとマルチ宛先フレームのフレーム転送の詳細について説明します。
Known unicast traffic received from the Attachment Circuit (AC) will be PBB-encapsulated by the PE using the B-MAC source address corresponding to the originating site. The unicast B-MAC destination address is determined based on a lookup of the C-MAC destination address (the binding of the two is done via transparent learning of reverse traffic). The resulting frame is then encapsulated with an LSP tunnel label and an EVPN label associated with the B-MAC destination address. If per flow load-balancing over ECMPs in the MPLS core is required, then a flow label is added below the label associated with the B-MAC address in the label stack.
接続回線（AC）から受信した既知のユニキャストトラフィックは、発信元サイトに対応するB-MAC送信元アドレスを使用して、PEによってPBBカプセル化されます。ユニキャストB-MAC宛先アドレスは、C-MAC宛先アドレスのルックアップに基づいて決定されます（2つのバインディングは、逆トラフィックの透過的な学習によって行われます）。結果のフレームは、LSPトンネルラベルとB-MAC宛先アドレスに関連付けられたEVPNラベルでカプセル化されます。 MPLSコアのECMPを介したフローごとのロードバランシングが必要な場合、フローラベルがラベルスタックのB-MACアドレスに関連付けられたラベルの下に追加されます。
For unknown unicast traffic, the PE forwards these frames over the MPLS core. When these frames are to be forwarded, then the same set of options used for forwarding multicast/broadcast frames (as described in next section) are used.
不明なユニキャストトラフィックの場合、PEはこれらのフレームをMPLSコアを介して転送します。これらのフレームが転送される場合、マルチキャスト/ブロードキャストフレームの転送に使用されるのと同じオプションセット（次のセクションで説明）が使用されます。
Multi-destination frames received from the AC will be PBB-encapsulated by the PE using the B-MAC source address corresponding to the originating site. The multicast B-MAC destination address is selected based on the value of the I-SID as defined in [PBB]. The resulting frame is then forwarded over the MPLS core using one of the following two options:
ACから受信したマルチ宛先フレームは、発信元サイトに対応するB-MAC送信元アドレスを使用して、PEによってPBBカプセル化されます。マルチキャストB-MAC宛先アドレスは、[PBB]で定義されているI-SIDの値に基づいて選択されます。結果のフレームは、次の2つのオプションのいずれかを使用してMPLSコアを介して転送されます。
Option 1: the MPLS Forwarder can perform ingress replication over a set of MP2P or P2P tunnel LSPs. The frame is encapsulated with a tunnel LSP label and the EVPN ingress replication label advertised in the Inclusive Multicast Ethernet Tag [RFC7432].
オプション1：MPLSフォワーダーは、一連のMP2PまたはP2PトンネルLSPを介して入力レプリケーションを実行できます。フレームは、トンネルLSPラベルと包括的マルチキャストイーサネットタグ[RFC7432]でアドバタイズされるEVPN入力レプリケーションラベルでカプセル化されます。
Option 2: the MPLS Forwarder can use P2MP tunnel LSP per the procedures defined in [RFC7432]. This includes either the use of Inclusive or Aggregate Inclusive trees. Furthermore, the MPLS Forwarder can use MP2MP tunnel LSP if Inclusive trees are used.
オプション2：MPLSフォワーダーは、[RFC7432]で定義されている手順に従ってP2MPトンネルLSPを使用できます。これには、包含ツリーまたは集約包含ツリーの使用が含まれます。さらに、包括的ツリーが使用されている場合、MPLSフォワーダーはMP2MPトンネルLSPを使用できます。
Note that the same procedures for advertising and handling the Inclusive Multicast Ethernet Tag defined in [RFC7432] apply here.
[RFC7432]で定義されている包括的マルチキャストイーサネットタグをアドバタイズおよび処理する同じ手順がここでも適用されることに注意してください。
The encapsulation for the transport of PBB frames over MPLS is similar to that of classical Ethernet, albeit with the additional PBB header, as shown in the figure below:
次の図に示すように、MPLSを介したPBBフレームの転送のカプセル化は、PBBヘッダーが追加されているにもかかわらず、従来のイーサネットのカプセル化と同様です。
+------------------+
| IP/MPLS Header |
+------------------+
| PBB Header |
+------------------+
| Ethernet Header |
+------------------+
| Ethernet Payload |
+------------------+
| Ethernet FCS |
+------------------+
Figure 3: PBB over MPLS Encapsulation
図3：PBB over MPLSカプセル化
The PE nodes MAY implement an ARP/ND-proxy function in order to minimize the volume of ARP/ND traffic that is broadcasted over the MPLS network. In case of ARP proxy, this is achieved by having each PE node snoop on ARP request and response messages received over the access interfaces or the MPLS core. The PE builds a cache of IP/MAC address bindings from these snooped messages. The PE then uses this cache to respond to ARP requests ingress on access ports and target hosts that are in remote sites. If the PE finds a match for the IP address in its ARP cache, it responds back to the requesting host and drops the request. Otherwise, if it does not find a match, then the request is flooded over the MPLS network using either ingress replication or P2MP LSPs. In case of ND proxy, this is achieved similar to the above but with ND/NA messages per [RFC4389].
PEノードは、MPLSネットワークを介してブロードキャストされるARP / NDトラフィックの量を最小限にするために、ARP / NDプロキシ機能を実装してもよい（MAY）。 ARPプロキシの場合、これは、各PEノードがアクセスインターフェイスまたはMPLSコアを介して受信したARP要求および応答メッセージをスヌープすることによって実現されます。 PEは、これらのスヌーピングされたメッセージからIP / MACアドレスバインディングのキャッシュを構築します。次に、PEはこのキャッシュを使用して、リモートサイトにあるアクセスポートとターゲットホストへのARP要求の進入に応答します。 PEがARPキャッシュでIPアドレスの一致を検出すると、PEは要求元のホストに応答し、要求をドロップします。それ以外の場合、一致が見つからない場合、要求は入力レプリケーションまたはP2MP LSPを使用してMPLSネットワーク上でフラッディングされます。 NDプロキシの場合、これは上記と同様に達成されますが、[RFC4389]によるND / NAメッセージを使用します。
+--------------+
| |
+---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
|SW1 |--| | | PE1| | PE2| | |--| SW3|
+----+ | 802.1aq |---| | | |--| 802.1aq | +----+
+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+
|SW2 |--| | | Backbone | | |--| SW4|
+----+ +---------+ +--------------+ +---------+ +----+
|<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP
|<------------------------- PBB -------------------------->| DP
|<----MPLS----->|
Legend: CP = Control-Plane View DP = Data-Plane View
凡例：CP =コントロールプレーンビューDP =データプレーンビュー
Figure 4: Interconnecting 802.1aq / 802.1Qbp Networks with PBB-EVPN
図4：PBB-EVPNを使用した802.1aq / 802.1Qbpネットワークの相互接続
The B-MAC addresses need to be globally unique across all networks including PBB-EVPN and IEEE 802.1aq / 802.1Qbp networks. The B-MAC addresses used for single-homed and Single-Active Ethernet segments should be unique because they are typically auto-derived from the PE's pools of reserved MAC addresses that are unique. The B-MAC addresses used for All-Active Ethernet segments should also be unique given that each network operator typically has its own assigned Organizationally Unique Identifier (OUI) and thus can assign its own unique MAC addresses.
B-MACアドレスは、PBB-EVPNおよびIEEE 802.1aq / 802.1Qbpネットワークを含むすべてのネットワークにわたってグローバルに一意である必要があります。シングルホームおよびシングルアクティブイーサネットセグメントに使用されるB-MACアドレスは、通常、一意である予約済みMACアドレスのPEのプールから自動派生されるため、一意である必要があります。オールアクティブイーサネットセグメントに使用されるB-MACアドレスも一意である必要があります。これは、各ネットワークオペレーターが通常、独自の割り当てられた組織固有識別子（OUI）を持ち、したがって独自の一意のMACアドレスを割り当てることができる場合です。
B-MAC addresses associated with 802.1aq / 802.1Qbp switches are advertised using the EVPN MAC/IP route advertisement already defined in [RFC7432].
802.1aq / 802.1Qbpスイッチに関連付けられたB-MACアドレスは、[RFC7432]ですでに定義されているEVPN MAC / IPルートアドバタイズメントを使用してアドバタイズされます。
8.3. Operation:
8.3. 操作：
When a PE receives a PBB-encapsulated Ethernet frame from the access side, it performs a lookup on the B-MAC destination address to identify the next hop. If the lookup yields that the next hop is a remote PE, the local PE would then encapsulate the PBB frame in MPLS. The label stack comprises of the VPN label (advertised by the remote PE), followed by an LSP/IGP label. From that point onwards, regular MPLS forwarding is applied.
PEがアクセス側からPBBカプセル化イーサネットフレームを受信すると、B-MAC宛先アドレスでルックアップを実行して、ネクストホップを識別します。ルックアップの結果、ネクストホップがリモートPEである場合、ローカルPEはPBBフレームをMPLSにカプセル化します。ラベルスタックは、VPNラベル（リモートPEによってアドバタイズされる）と、それに続くLSP / IGPラベルで構成されます。その時点以降、通常のMPLS転送が適用されます。
On the disposition PE, assuming penultimate-hop-popping is employed, the PE receives the MPLS-encapsulated PBB frame with a single label: the VPN label. The value of the label indicates to the disposition PE that this is a PBB frame, so the label is popped, the TTL field (in the 802.1Qbp F-Tag) is reinitialized, and normal PBB processing is employed from this point onwards.
ディスポジションPEでは、最後から2番目のホップポッピングが採用されていると想定して、PEは、MPLSカプセル化PBBフレームを1つのラベル、つまりVPNラベルで受信します。ラベルの値は、これがPBBフレームであることを廃棄PEに示すため、ラベルがポップされ、（802.1Qbp Fタグ内の）TTLフィールドが再初期化され、この時点以降、通常のPBB処理が採用されます。
In this section, we discuss the advantages of the PBB-EVPN solution in the context of the requirements set forth in Section 3.
このセクションでは、PBB-EVPNソリューションの利点について、セクション3に記載されている要件のコンテキストで説明します。
In PBB-EVPN, the number of MAC Advertisement routes is a function of the number of Ethernet segments (e.g., sites) rather than the number of hosts/servers. This is because the B-MAC addresses of the PEs, rather than C-MAC addresses (of hosts/servers), are being advertised in BGP. As discussed above, there's a one-to-one mapping between All-Active multihomed segments and their associated B-MAC addresses; there can be either a one-to-one or many-to-one mapping between Single-Active multihomed segments and their associated B-MAC addresses; and finally there is a many-to-one mapping between single-home sites and their associated B-MAC addresses on a given PE. This means a single B-MAC is associated with one or more segments where each segment can be associated with many C-MAC addresses. As a result, the volume of MAC Advertisement routes in PBB-EVPN may be multiple orders of magnitude less than EVPN.
PBB-EVPNでは、MACアドバタイズメントルートの数は、ホスト/サーバーの数ではなく、イーサネットセグメント（サイトなど）の数の関数です。これは、（ホスト/サーバーの）C-MACアドレスではなく、PEのB-MACアドレスがBGPでアドバタイズされているためです。上記で説明したように、All-Activeマルチホームセグメントとそれらに関連付けられたB-MACアドレスの間には1対1のマッピングがあります。シングルアクティブマルチホームセグメントとそれらに関連付けられたB-MACアドレスの間には、1対1または多対1のマッピングが存在します。そして最後に、特定のPE上のシングルホームサイトとそれに関連付けられたB-MACアドレスの間に多対1のマッピングがあります。つまり、1つのB-MACが1つ以上のセグメントに関連付けられ、各セグメントは多くのC-MACアドレスに関連付けることができます。その結果、PBB-EVPNのMACアドバタイズメントルートの量は、EVPNよりも数桁少ない場合があります。
As described above, in PBB-EVPN, a single B-MAC address can aggregate many C-MAC addresses. Given that B-MAC addresses are associated with segments attached to a PE or to the PE itself, their locations are fixed and thus not impacted what so ever by C-MAC mobility. Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any re-advertisements of them). This is because the association of C-MAC address to B-MAC address is learned in the data-plane and C-MAC addresses are not advertised in BGP. Aggregation via B-MAC addresses in PBB-EVPN performs much better than EVPN.
上記のように、PBB-EVPNでは、単一のB-MACアドレスが多数のC-MACアドレスを集約できます。 B-MACアドレスがPEまたはPE自体に接続されたセグメントに関連付けられている場合、それらの場所は固定されているため、C-MACモビリティによる影響はありません。したがって、C-MACモビリティはB-MACアドレス（たとえば、それらの再アドバタイズメント）に影響を与えません。これは、C-MACアドレスとB-MACアドレスの関連付けがデータプレーンで学習され、C-MACアドレスがBGPでアドバタイズされないためです。 PBB-EVPNのB-MACアドレスによる集約は、EVPNよりもはるかに優れています。
To illustrate how this compares to EVPN, consider the following example:
これがEVPNとどのように比較されるかを説明するために、次の例を検討してください。
If a PE running EVPN advertises reachability for N MAC addresses via a particular segment, and then 50% of the MAC addresses in that segment move to other segments (e.g., due to virtual machine mobility), then N/2 additional MAC Advertisement routes need to be sent for the MAC addresses that have moved. With PBB-EVPN, on the other hand, the B-MAC addresses that are statically associated with PE nodes are not subject to mobility. As C-MAC addresses move from one segment to another, the binding of C-MAC to B-MAC addresses is updated via data-plane learning in PBB-EVPN.
EVPNを実行しているPEが特定のセグメントを介してN個のMACアドレスの到達可能性をアドバタイズし、そのセグメントのMACアドレスの50％が他のセグメントに移動する場合（仮想マシンのモビリティなどにより）、N / 2個の追加のMACアドバタイズルートが必要です。移動したMACアドレスに対して送信されます。一方、PBB-EVPNでは、PEノードに静的に関連付けられているB-MACアドレスはモビリティの影響を受けません。 C-MACアドレスが1つのセグメントから別のセグメントに移動すると、C-MACのB-MACアドレスへのバインディングは、PBB-EVPNのデータプレーンラーニングを介して更新されます。
In PBB-EVPN, C-MAC address reachability information is built via data-plane learning. As such, PE nodes not participating in active conversations involving a particular C-MAC address will purge that address from their forwarding tables. Furthermore, since C-MAC addresses are not distributed in BGP, PE nodes will not maintain any record of them in the control-plane routing table.
PBB-EVPNでは、C-MACアドレス到達可能性情報は、データプレーン学習を介して構築されます。そのため、特定のC-MACアドレスを含むアクティブな会話に参加していないPEノードは、そのアドレスを転送テーブルから削除します。さらに、C-MACアドレスはBGPで配布されないため、PEノードはコントロールプレーンルーティングテーブルにそれらのレコードを維持しません。
Consider the scenario where two access networks, one running MPLS and the other running 802.1aq, are interconnected via an MPLS backbone network. The figure below shows such an example network.
一方がMPLSを実行し、もう一方が802.1aqを実行している2つのアクセスネットワークがMPLSバックボーンネットワークを介して相互接続されているシナリオを考えます。次の図は、このようなネットワークの例を示しています。
+--------------+
| |
+---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| | | PE1| | PE2| | |--| CE |
+----+ | 802.1aq |---| | | |--| MPLS | +----+
+----+ | | +----+ +----+ | | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
Figure 5: Interoperability with 802.1aq
図5：802.1aqとの相互運用性
If the MPLS backbone network employs EVPN, then the 802.1aq data-plane encapsulation must be terminated on PE1 or the edge device connecting to PE1. Either way, all the PE nodes that are part of the associated service instances will be exposed to all the C-MAC addresses of all hosts/servers connected to the access networks. However, if the MPLS backbone network employs PBB-EVPN, then the 802.1aq encapsulation can be extended over the MPLS backbone, thereby maintaining C-MAC address transparency on PE1. If PBB-EVPN is also extended over the MPLS access network on the right, then C-MAC addresses would be transparent to PE2 as well.
MPLSバックボーンネットワークがEVPNを採用している場合、802.1aqデータプレーンカプセル化は、PE1またはPE1に接続するエッジデバイスで終端する必要があります。どちらの方法でも、関連するサービスインスタンスの一部であるすべてのPEノードは、アクセスネットワークに接続されているすべてのホスト/サーバーのすべてのC-MACアドレスに公開されます。ただし、MPLSバックボーンネットワークがPBB-EVPNを採用している場合、802.1aqカプセル化はMPLSバックボーン上で拡張できるため、PE1でC-MACアドレスの透過性を維持できます。 PBB-EVPNが右側のMPLSアクセスネットワークにも拡張されている場合、C-MACアドレスはPE2にも透過的です。
In PBB-EVPN, the per-site policy can be supported via B-MAC addresses via assigning a unique B-MAC address for every site/segment (typically multihomed but can also be single-homed). Given that the B-MAC addresses are sent in BGP MAC/IP route advertisement, it is possible to define per-site (i.e., B-MAC) forwarding policies including policies for E-TREE service.
PBB-EVPNでは、サイトごとのポリシーは、すべてのサイト/セグメント（通常マルチホームですが、シングルホームにすることもできます）に一意のB-MACアドレスを割り当てることにより、B-MACアドレスを介してサポートできます。 B-MACアドレスがBGP MAC / IPルートアドバタイズメントで送信される場合、E-TREEサービスのポリシーを含むサイトごと（つまり、B-MAC）の転送ポリシーを定義できます。
Just as in [RFC7432], with PBB-EVPN, it is possible to avoid C-MAC address flushing upon topology change affecting an All-Active multihomed segment. To illustrate this, consider the example network of Figure 1. Both PE1 and PE2 advertise the same B-MAC address (BM1) to PE3. PE3 then learns the C-MAC addresses of the servers/hosts behind CE1 via data-plane learning. If AC1 fails, then PE3 does not need to flush any of the C-MAC addresses learned and associated with BM1. This is because PE1 will withdraw the MAC Advertisement routes associated with BM1, thereby leading PE3 to have a single adjacency (to PE2) for this B-MAC address. Therefore, the topology change is communicated to PE3 and no C-MAC address flushing is required.
[RFC7432]と同様に、PBB-EVPNを使用すると、All-Activeマルチホームセグメントに影響を与えるトポロジ変更時にC-MACアドレスがフラッシュするのを回避できます。これを説明するために、図1のネットワーク例を検討してください。PE1とPE2の両方が同じB-MACアドレス（BM1）をPE3にアドバタイズします。次に、PE3は、データプレーン学習を通じてCE1の背後にあるサーバー/ホストのC-MACアドレスを学習します。 AC1に障害が発生した場合、PE3は学習し、BM1に関連付けられたC-MACアドレスをフラッシュする必要はありません。これは、PE1がBM1に関連付けられたMACアドバタイズメントルートを取り消すため、PE3がこのB-MACアドレスに対して（PE2への）隣接を1つ持つためです。したがって、トポロジの変更はPE3に伝達され、C-MACアドレスのフラッシュは必要ありません。
All the security considerations in [RFC7432] apply directly to this document because this document leverages the control plane described in [RFC7432] and their associated procedures -- although not the complete set but rather a subset.
[RFC7432]のセキュリティに関するすべての考慮事項は、このドキュメントに直接適用されます。これは、このドキュメントが[RFC7432]で説明されているコントロールプレーンとそれに関連する手順を利用するためです。
This document does not introduce any new security considerations beyond that of [RFC7432] and [RFC4761] because advertisements and processing of B-MAC addresses follow that of [RFC7432] and processing of C-MAC addresses follow that of [RFC4761] -- i.e, B-MAC addresses are learned in the control plane and C-MAC addresses are learned in data plane.
B-MACアドレスのアドバタイズと処理は[RFC7432]のアドバタイズおよび処理に従い、C-MACアドレスの処理は[RFC4761]のアドバンテージに従うため、このドキュメントでは、[RFC7432]および[RFC4761]を超える新しいセキュリティの考慮事項を紹介しません。 、B-MACアドレスはコントロールプレーンで学習され、C-MACアドレスはデータプレーンで学習されます。
There are no additional IANA considerations for PBB-EVPN beyond what is already described in [RFC7432].
[RFC7432]ですでに説明されている以上に、PBB-EVPNに関するIANAの考慮事項はありません。
[PBB] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146.
[PBB] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、Clauses 25 and 26、Clause 25 and 26、IEEE Std 802.1Q、DOI 10.1109 / IEEESTD.2011.6009146。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://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月、<http://www.rfc-editor.org/info/rfc7432>。
[MMRP] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", Clause 10, IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146.
[MMRP] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、Clause 10、IEEE Std 802.1Q、DOI 10.1109 / IEEESTD.2011.6009146。
[OVERLAY] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Isaac, A., Uttaro, J., Henderickx, W., Shekhar, R., Salam, S., Patel, K., Rao, D., and S. Thoria, "A Network Virtualization Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01, February 2015.
[OVERLAY] Sajassi、A.、Ed。、Drake、J.、Ed。、Bitar、N.、Isaac、A.、Uttaro、J.、Henderickx、W.、Shekhar、R.、Salam、S.、Patel 、K.、Rao、D。、およびS. Thoria、「EVPNを使用したネットワーク仮想化オーバーレイソリューション」、draft-ietf-bess-evpn-overlay-01、2015年2月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、DOI 10.17487 / RFC4389、2006年4月、<http：//www.rfc-editor。 org / info / rfc4389>。
[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, <http://www.rfc-editor.org/info/rfc4761>.
[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、2007年1月、<http ：//www.rfc-editor.org/info/rfc4761>。
[RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080, December 2013, <http://www.rfc-editor.org/info/rfc7080>.
[RFC7080] Sajassi、A.、Salam、S.、Bitar、N。、およびF. Balus、「プロバイダーバックボーンブリッジとの仮想プライベートLANサービス（VPLS）の相互運用性」、RFC 7080、DOI 10.17487 / RFC7080、2013年12月、< http://www.rfc-editor.org/info/rfc7080>。
[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, <http://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月、<http://www.rfc-editor.org/info/rfc7209>。
Acknowledgements
謝辞
The authors would like to thank Jose Liste and Patrice Brissette for their reviews and comments of this document. We would also like to thank Giles Heron for several rounds of reviews and providing valuable inputs to get this document ready for IESG submission.
このドキュメントのレビューとコメントを提供してくれたJose ListeとPatrice Brissetteに感謝します。また、このドキュメントをIESGに提出する準備を整えるために、何度かレビューを行い、貴重な情報を提供してくれたGiles Heronにも感謝します。
Contributors
貢献者
In addition to the authors listed, the following individuals also contributed to this document.
リストされた著者に加えて、以下の個人もこの文書に貢献しました。
Lizhong Jin, ZTE Sami Boutros, Cisco Dennis Cai, Cisco Keyur Patel, Cisco Sam Aldrin, Huawei Himanshu Shah, Ciena Jorge Rabadan, ALU
Lijhong Jin、Zate Sami Botross、Cisco Denis Kay、Cisco Kayur Patel、Cisco San Aldrin、Huawei Himanshu Shah、Ina Jorge Rabadan、Potato
Authors' Addresses
著者のアドレス
Ali Sajassi, editor Cisco 170 West Tasman Drive San Jose, CA 95134 United States Email: sajassi@cisco.com
Ali Sajassi、編集者Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国メール：sajassi@cisco.com
Samer Salam Cisco 595 Burrard Street, Suite # 2123 Vancouver, BC V7X 1J1 Canada Email: ssalam@cisco.com
Samer Salam Cisco 595 Burrard Street、Suite＃2123バンクーバー、BC V7X 1J1カナダメール：ssalam@cisco.com
Nabil Bitar Verizon Communications Email: nabil.n.bitar@verizon.com
Nabil Bitar Verizonコミュニケーションメール：nabil.n.bitar@verizon.com
Aldrin Isaac Juniper Email: aisaac@juniper.net
アルドリンアイザックジュニパーメール：aisaac@juniper.net
Wim Henderickx Alcatel-Lucent Email: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucentメール：wim.henderickx@alcatel-lucent.com