[要約] RFC 7209は、Ethernet VPN（EVPN）の要件を定義するものであり、EVPNの目的は、異なる場所にあるイーサネットセグメントを仮想的に接続することです。
Internet Engineering Task Force (IETF) A. Sajassi
Request for Comments: 7209 Cisco
Category: Informational R. Aggarwal
ISSN: 2070-1721 Arktan
J. Uttaro
AT&T
N. Bitar
Verizon
W. Henderickx
Alcatel-Lucent
A. Isaac
Bloomberg
May 2014
Requirements for Ethernet VPN (EVPN)
イーサネットVPN（EVPN）の要件
Abstract
概要
The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.
イーサネットL2VPNサービスの広範な採用とテクノロジー（データセンター相互接続など）の新しいアプリケーションの出現により、現在の仮想プライベートLANサービス（VPLS）ソリューションでは容易に対応できない新しい一連の要件に至りました。特に、オールアクティブ転送によるマルチホーミングはサポートされておらず、マルチポイントツーマルチポイント（MP2MP）ラベルスイッチドパス（LSP）を利用してマルチ宛先フレームの配信を最適化するための既存のソリューションはありません。さらに、VPLSのプロビジョニングでは、BGPベースの自動検出のコンテキストでも、ネットワークオペレーターがアクセス構成に加えてさまざまなネットワークパラメーターを指定する必要があります。このドキュメントでは、上記の問題に対処するイーサネットVPN（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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7209.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7209で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Specification of Requirements ...................................4
3. Terminology .....................................................4
4. Redundancy Requirements .........................................5
4.1. Flow-Based Load Balancing ..................................5
4.2. Flow-Based Multipathing ....................................6
4.3. Geo-redundant PE Nodes .....................................7
4.4. Optimal Traffic Forwarding .................................7
4.5. Support for Flexible Redundancy Grouping ...................8
4.6. Multihomed Network .........................................8
5. Multicast Optimization Requirements .............................9
6. Ease of Provisioning Requirements ...............................9
7. New Service Interface Requirements .............................10
8. Fast Convergence ...............................................12
9. Flood Suppression ..............................................12
10. Supporting Flexible VPN Topologies and Policies ...............12
11. Security Considerations .......................................13
12. Normative References ..........................................13
13. Informative References ........................................14
14. Contributors ..................................................15
Virtual Private LAN Service (VPLS), as defined in [RFC4664], [RFC4761], and [RFC4762], is a proven and widely deployed technology. However, the existing solution has a number of limitations when it comes to redundancy, multicast optimization, and provisioning simplicity. Furthermore, new applications are driving several new requirements for other L2VPN services such as Ethernet Tree (E-Tree) and Virtual Private Wire Service (VPWS).
[RFC4664]、[RFC4761]、および[RFC4762]で定義されているVirtual Private LAN Service（VPLS）は、実績のある広く展開されているテクノロジーです。ただし、既存のソリューションには、冗長性、マルチキャスト最適化、プロビジョニングの簡素化に関して、多くの制限があります。さらに、新しいアプリケーションは、イーサネットツリー（Eツリー）や仮想プライベートワイヤサービス（VPWS）などの他のL2VPNサービスに対するいくつかの新しい要件を推進しています。
In the area of multihoming, current VPLS can only support multihoming with the single-active redundancy mode (defined in Section 3), for example, as described in [VPLS-BGP-MH]. Flexible multihoming with all-active redundancy mode (defined in Section 3) cannot be supported by the current VPLS solution.
マルチホーミングの領域では、たとえば[VPLS-BGP-MH]で説明されているように、現在のVPLSはシングルアクティブ冗長モード（セクション3で定義）でのマルチホーミングのみをサポートできます。オールアクティブ冗長モード（セクション3で定義）による柔軟なマルチホーミングは、現在のVPLSソリューションではサポートできません。
In the area of multicast optimization, [RFC7117] describes how multicast LSPs can be used in conjunction with VPLS. However, this solution is limited to Point-to-Multipoint (P2MP) LSPs, as there's no defined solution for leveraging Multipoint-to-Multipoint (MP2MP) LSPs with VPLS.
マルチキャスト最適化の分野では、[RFC7117]は、マルチキャストLSPをVPLSと組み合わせて使用する方法を説明しています。ただし、VPLSでマルチポイントツーマルチポイント（MP2MP）LSPを活用するための定義されたソリューションがないため、このソリューションはポイントツーマルチポイント（P2MP）LSPに限定されます。
In the area of provisioning simplicity, current VPLS does offer a mechanism for single-sided provisioning by relying on BGP-based service auto-discovery [RFC4761] [RFC6074]. This, however, still requires the operator to configure a number of network-side parameters on top of the access-side Ethernet configuration.
プロビジョニングの簡素化の領域では、現在のVPLSは、BGPベースのサービスの自動検出[RFC4761] [RFC6074]に依存することにより、片側プロビジョニングのメカニズムを提供します。ただし、この場合でも、オペレーターはアクセス側のイーサネット構成に加えていくつかのネットワーク側のパラメーターを構成する必要があります。
In the area of data-center interconnect, applications are driving the need for new service interface types that are a hybrid combination of VLAN bundling and VLAN-based service interfaces. These are referred to as "VLAN-aware bundling" service interfaces.
データセンター相互接続の分野では、アプリケーションが、VLANバンドリングとVLANベースのサービスインターフェイスのハイブリッドの組み合わせである新しいサービスインターフェイスタイプの必要性を高めています。これらは、「VLAN対応バンドル」サービスインターフェイスと呼ばれます。
Virtualization applications are also fueling an increase in the volume of MAC (Media Access Control) addresses that are to be handled by the network; this gives rise to the requirement for having the network reconvergence upon failure be independent of the number of MAC addresses learned by the Provider Edge (PE).
仮想化アプリケーションは、ネットワークで処理されるMAC（Media Access Control）アドレスの量の増加にも拍車をかけています。これにより、障害発生時にネットワークを再収束させ、プロバイダーエッジ（PE）が学習したMACアドレスの数に依存しないようにする必要があります。
There are requirements for minimizing the amount of flooding of multi-destination frames and localizing the flooding to the confines of a given site.
複数の宛先フレームのフラッディングの量を最小限に抑え、特定のサイトの範囲にフラッディングをローカライズするための要件があります。
There are also requirements for supporting flexible VPN topologies and policies beyond those currently covered by VPLS and Hierarchical VPLS (H-VPLS).
また、現在VPLSおよび階層VPLS（H-VPLS）でカバーされているものを超える柔軟なVPNトポロジおよびポリシーをサポートするための要件もあります。
The focus of this document is on defining the requirements for a new solution, namely, Ethernet VPN (EVPN), which addresses the above issues.
このドキュメントでは、上記の問題に対処する新しいソリューション、つまりイーサネットVPN（EVPN）の要件を定義することに焦点を当てています。
Section 4 discusses the redundancy requirements. Section 5 describes the multicast optimization requirements. Section 6 articulates the ease of provisioning requirements. Section 7 focuses on the new service interface requirements. Section 8 highlights the fast convergence requirements. Section 9 describes the flood suppression requirement, and finally Section 10 discusses the requirements for supporting flexible VPN topologies and policies.
セクション4では、冗長性の要件について説明します。セクション5では、マルチキャスト最適化の要件について説明します。セクション6は、プロビジョニングの容易さの要件を明確に示しています。セクション7では、新しいサービスインターフェイスの要件について説明します。セクション8では、高速コンバージェンスの要件について説明します。セクション9ではフラッド抑制の要件について説明し、最後にセクション10では柔軟なVPNトポロジとポリシーをサポートするための要件について説明します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document is not a protocol specification and the key words in this document are used for clarity and emphasis of requirements language.
このドキュメントはプロトコル仕様ではありません。このドキュメントのキーワードは、要件言語を明確かつ強調するために使用されています。
AS: Autonomous System
AS：自律システム
CE: Customer Edge
CE：カスタマーエッジ
E-Tree: Ethernet Tree
Eツリー：イーサネットツリー
MAC address: Media Access Control address - referred to as MAC
MACアドレス：メディアアクセスコントロールアドレス-MACと呼ばれます
LSP: Label Switched Path
LSP：ラベルスイッチドパス
PE: Provider Edge
PE：プロバイダーエッジ
MP2MP: Multipoint to Multipoint
MP2MP：マルチポイントからマルチポイント
VPLS: Virtual Private LAN Service
VPLS：仮想プライベートLANサービス
Single-Active Redundancy Mode: When a device or a network is multihomed to a group of two or more PEs and when only a single PE in such a redundancy group can forward traffic to/from the multihomed device or network for a given VLAN, such multihoming is referred to as "Single-Active".
シングルアクティブ冗長モード：デバイスまたはネットワークが2つ以上のPEのグループにマルチホーム化されている場合、およびそのような冗長性グループの単一のPEのみが、特定のVLANなどのマルチホームデバイスまたはネットワークとの間でトラフィックを転送できる場合マルチホーミングは「シングルアクティブ」と呼ばれます。
All-Active Redundancy Mode: When a device is multihomed to a group of two or more PEs and when all PEs in such redundancy group can forward traffic to/from the multihomed device or network for a given VLAN, such multihoming is referred to as "All-Active".
オールアクティブ冗長モード：デバイスが2つ以上のPEのグループにマルチホーム化されており、そのような冗長性グループのすべてのPEが特定のVLANのマルチホーム化されたデバイスまたはネットワークとの間でトラフィックを転送できる場合、そのようなマルチホーミングは「オールアクティブ」。
A common mechanism for multihoming a CE node to a set of PE nodes involves leveraging multi-chassis Ethernet link aggregation groups (LAGs) based on [802.1AX]. [PWE3-ICCP] describes one such scheme. In Ethernet link aggregation, the load-balancing algorithms by which a CE distributes traffic over the Attachment Circuits connecting to the PEs are quite flexible. The only requirement is for the algorithm to ensure in-order frame delivery for a given traffic flow. In typical implementations, these algorithms involve selecting an outbound link within the bundle based on a hash function that identifies a flow based on one or more of the following fields:
CEノードをPEノードのセットにマルチホーミングするための一般的なメカニズムには、[802.1AX]に基づくマルチシャーシイーサネットリンク集約グループ（LAG）の活用が含まれます。 [PWE3-ICCP]は、そのようなスキームの1つを説明しています。イーサネットリンク集約では、CEがPEに接続する接続回線にトラフィックを分散するロードバランシングアルゴリズムは、非常に柔軟です。唯一の要件は、アルゴリズムが所定のトラフィックフローに対してフレームの順序どおりの配信を保証することです。一般的な実装では、これらのアルゴリズムは、次の1つ以上のフィールドに基づいてフローを識別するハッシュ関数に基づいて、バンドル内のアウトバウンドリンクを選択することを含みます。
i. Layer 2: Source MAC Address, Destination MAC Address, VLAN ii. Layer 3: Source IP Address, Destination IP Address iii. Layer 4: UDP or TCP Source Port, Destination Port
i. レイヤー2：送信元MACアドレス、宛先MACアドレス、VLAN ii。レイヤー3：送信元IPアドレス、宛先IPアドレスiii。レイヤー4：UDPまたはTCP送信元ポート、宛先ポート
A key point to note here is that [802.1AX] does not define a standard load-balancing algorithm for Ethernet bundles, and, as such, different implementations behave differently. As a matter of fact, a bundle operates correctly even in the presence of asymmetric load balancing over the links. This being the case, the first requirement for all-active multihoming is the ability to accommodate flexible flow-based load balancing from the CE node based on L2, L3, and/or L4 header fields.
ここで注意すべき重要な点は、[802.1AX]がイーサネットバンドルの標準ロードバランシングアルゴリズムを定義していないため、実装が異なると動作が異なることです。実際のところ、リンク上で非対称のロードバランシングが存在する場合でも、バンドルは正しく動作します。そのため、すべてアクティブなマルチホーミングの最初の要件は、L2、L3、L4ヘッダーフィールドに基づいてCEノードからの柔軟なフローベースのロードバランシングに対応する機能です。
(R1a) A solution MUST be capable of supporting flexible flow-based load balancing from the CE as described above.
（R1a）ソリューションは、上記のようにCEからの柔軟なフローベースのロードバランシングをサポートできる必要があります。
(R1b) A solution MUST also be able to support flow-based load balancing of traffic destined to the CE, even when the CE is connected to more than one PE. Thus, the solution MUST be able to exercise multiple links connected to the CE, irrespective of the number of PEs that the CE is connected to.
（R1b）ソリューションは、CEが複数のPEに接続されている場合でも、CE宛てのトラフィックのフローベースのロードバランシングもサポートできる必要があります。したがって、ソリューションは、CEが接続されているPEの数に関係なく、CEに接続された複数のリンクを実行できる必要があります。
It should be noted that when a CE is multihomed to several PEs, there could be multiple Equal-Cost Multipath (ECMP) paths from each remote PE to each multihoming PE. Furthermore, for an all-active multihomed CE, a remote PE can choose any of the multihoming PEs for sending traffic destined to the multihomed CE. Therefore, when a solution supports all-active multihoming, it MUST exercise as many of these paths as possible for traffic destined to a multihomed CE.
CEが複数のPEにマルチホーム化されている場合、各リモートPEから各マルチホーミングPEへの複数の等価コストマルチパス（ECMP）パスが存在する可能性があることに注意してください。さらに、すべてアクティブなマルチホームCEの場合、リモートPEは、マルチホームCE宛てのトラフィックを送信するために、マルチホーミングPEのいずれかを選択できます。したがって、ソリューションがすべてアクティブなマルチホーミングをサポートする場合、マルチホームCE宛てのトラフィックに対してこれらのパスをできるだけ多く実行する必要があります。
(R1c) A solution SHOULD support flow-based load balancing among PEs that are members of a redundancy group spanning multiple Autonomous Systems.
（R1c）ソリューションは、複数の自律システムにまたがる冗長グループのメンバーであるPE間のフローベースのロードバランシングをサポートする必要があります（SHOULD）。
Any solution that meets the all-active redundancy mode (e.g., flow-based load balancing) described in Section 4.1, also needs to exercise multiple paths between a given pair of PEs. For instance, if there are two or more LSPs between a remote PE and a pair of PEs in an all-active redundancy group, then the solution needs to be capable of load balancing traffic among those LSPs on a per-flow basis for traffic destined to the PEs in the redundancy group. Furthermore, if there are two or more ECMP paths between a remote PE and one of the PEs in the redundancy group, then the solution needs to leverage all the equal-cost LSPs. For the latter, the solution can also leverage the load-balancing capabilities based on entropy labels [RFC6790].
セクション4.1で説明したすべてアクティブな冗長モード（フローベースのロードバランシングなど）を満たすソリューションも、PEの特定のペア間で複数のパスを実行する必要があります。たとえば、リモートPEと、すべてアクティブな冗長グループ内のPEのペアの間に2つ以上のLSPがある場合、ソリューションは、宛先のトラフィックについて、フローごとにこれらのLSP間でトラフィックを負荷分散できる必要があります。冗長グループ内のPEに。さらに、リモートPEと冗長グループ内のPEの1つとの間に2つ以上のECMPパスがある場合、ソリューションはすべての等コストLSPを活用する必要があります。後者の場合、ソリューションはエントロピーラベル[RFC6790]に基づく負荷分散機能を活用することもできます。
(R2a) A solution MUST be able to exercise all LSPs between a remote PE and all the PEs in the redundancy group with all-active multihoming.
（R2a）ソリューションは、リモートPEと冗長グループ内のすべてのPE間のすべてのLSPを、すべてアクティブなマルチホーミングで実行できる必要があります。
(R2b) A solution MUST be able to exercise all ECMP paths between a remote PE and any of the PEs in the redundancy group with all-active multihoming.
（R2b）ソリューションは、リモートPEと冗長グループ内の任意のPEの間のすべてのECMPパスを、すべてアクティブなマルチホーミングで実行できる必要があります。
For example, consider a scenario in which CE1 is multihomed to PE1 and PE2, and CE2 is multihomed to PE3 and PE4 running in all-active redundancy mode. Furthermore, consider that there exist three ECMP paths between any of the CE1's and CE2's multihomed PEs. Traffic from CE1 to CE2 can be forwarded on twelve different paths over the MPLS/IP core as follows: CE1 load balances traffic to both PE1 and PE2. Each of PE1 and PE2 have three ECMP paths to PE3 and PE4 for a total of twelve paths. Finally, when traffic arrives at PE3 and PE4, it gets forwarded to CE2 over the Ethernet channel (aka link bundle).
たとえば、CE1がPE1およびPE2にマルチホーム化され、CE2がオールアクティブ冗長モードで実行されているPE3およびPE4にマルチホーム化されるシナリオを考えてみます。さらに、CE1とCE2のマルチホームPEの間に3つのECMPパスが存在することを考慮してください。 CE1からCE2へのトラフィックは、次のようにMPLS / IPコアを介して12の異なるパスで転送できます。CE1は、PE1とPE2の両方へのトラフィックの負荷を分散します。 PE1とPE2のそれぞれには、PE3とPE4への3つのECMPパスがあり、合計12のパスがあります。最後に、トラフィックがPE3およびPE4に到着すると、イーサネットチャネル（別名リンクバンドル）を介してCE2に転送されます。
It is worth pointing out that flow-based multipathing complements flow-based load balancing described in the previous section.
フローベースのマルチパスは、前のセクションで説明したフローベースのロードバランシングを補完することに注意してください。
The PE nodes offering multihomed connectivity to a CE or access network may be situated in the same physical location (co-located), or may be spread geographically (e.g., in different Central Offices (COs) or Points of Presence (POPs)). The latter is needed when offering a geo-redundant solution that ensures business continuity for critical applications in the case of power outages, natural disasters, etc. An all-active multihoming mechanism needs to support both co-located as well as geo-redundant PE placement. The latter scenario often means that requiring a dedicated link between the PEs, for the operation of the multihoming mechanism, is not appealing from a cost standpoint. Furthermore, the IGP cost from remote PEs to the pair of PEs in the dual-homed setup cannot be assumed to be the same when those latter PEs are geo-redundant.
CEまたはアクセスネットワークへのマルチホーム接続を提供するPEノードは、同じ物理的な場所（同じ場所にある）に配置することも、地理的に分散させることもできます（たとえば、異なるセントラルオフィス（CO）またはポイントオブプレゼンス（POP）にあります）。後者は、停電や自然災害などの場合に重要なアプリケーションのビジネス継続性を確保する地理冗長ソリューションを提供するときに必要です。すべてアクティブなマルチホーミングメカニズムは、同じ場所に配置されたPEと地理冗長PEの両方をサポートする必要があります配置。後者のシナリオは、マルチホーミングメカニズムの動作のためにPE間の専用リンクを必要とすることが、コストの観点から魅力的でないことを意味します。さらに、リモートPEからデュアルホーム構成のPEのペアまでのIGPコストは、後者のPEが地理的に冗長である場合、同じであるとは想定できません。
(R3a) A solution MUST support all-active multihoming without the need for a dedicated control/data link among the PEs in the multihomed group.
（R3a）ソリューションは、マルチホームグループ内のPE間の専用の制御/データリンクを必要とせずに、すべてアクティブなマルチホーミングをサポートする必要があります。
(R3b) A solution MUST support different IGP costs from a remote PE to each of the PEs in a multihomed group.
（R3b）ソリューションは、リモートPEからマルチホームグループ内の各PEへのさまざまなIGPコストをサポートする必要があります。
(R3c) A solution MUST support multihoming across different IGP domains within the same Autonomous System.
（R3c）ソリューションは、同じ自律システム内の異なるIGPドメイン間のマルチホーミングをサポートする必要があります。
(R3d) A solution SHOULD support multihoming across multiple Autonomous Systems.
（R3d）ソリューションは、複数の自律システムにわたるマルチホーミングをサポートする必要があります（SHOULD）。
In a typical network, when considering a designated pair of PEs, it is common to find both single-homed as well as multihomed CEs being connected to those PEs.
一般的なネットワークでは、指定されたPEのペアを検討する場合、それらのPEに接続されているシングルホームCEとマルチホームCEの両方を見つけるのが一般的です。
(R4) An all-active multihoming solution SHOULD support optimal forwarding of unicast traffic for all the following scenarios. By "optimal forwarding", we mean that traffic will not be forwarded between PE devices that are members of a multihomed group unless the destination CE is attached to one of the multihoming PEs.
（R4）オールアクティブマルチホーミングソリューションは、以下のすべてのシナリオでユニキャストトラフィックの最適な転送をサポートする必要があります（SHOULD）。 「最適な転送」とは、宛先CEがマルチホーミングPEの1つに接続されていない限り、マルチホームグループのメンバーであるPEデバイス間でトラフィックが転送されないことを意味します。
i. single-homed CE to multihomed CE ii. multihomed CE to single-homed CE iii. multihomed CE to multihomed CE
i. シングルホームCEからマルチホームCE ii。マルチホームCEからシングルホームCEへiii。マルチホームCEからマルチホームCE
This is especially important in the case of geo-redundant PEs, where having traffic forwarded from one PE to another within the same multihomed group introduces additional latency, on top of the inefficient use of the PE node's and core nodes' switching capacity. A multihomed group (also known as a multi-chassis LAG) is a group of PEs supporting a multihomed CE.
これは、地理的に冗長なPEの場合に特に重要です。同じマルチホームグループ内のあるPEから別のPEにトラフィックを転送すると、PEノードとコアノードのスイッチング容量の非効率的な使用に加えて、追加のレイテンシが発生します。マルチホームグループ（マルチシャーシLAGとも呼ばれます）は、マルチホームCEをサポートするPEのグループです。
(R5) In order to support flexible redundancy grouping, the multihoming mechanism SHOULD allow arbitrary grouping of PE nodes into redundancy groups where each redundancy group represents all multihomed devices/networks that share the same group of PEs.
（R5）柔軟な冗長グループ化をサポートするために、マルチホーミングメカニズムは、各PEグループが同じPEグループを共有するすべてのマルチホームデバイス/ネットワークを表す冗長グループへのPEノードの任意のグループ化を許可する必要があります。
This is best explained with an example: consider three PE nodes -- PE1, PE2, and PE3. The multihoming mechanism MUST allow a given PE, say, PE1, to be part of multiple redundancy groups concurrently. For example, there can be a group (PE1, PE2), a group (PE1, PE3), and another group (PE2, PE3) where CEs could be multihomed to any one of these three redundancy groups.
これは、例で最もよく説明されています。PE1、PE2、およびPE3の3つのPEノードを検討してください。マルチホーミングメカニズムは、特定のPE、たとえばPE1が同時に複数の冗長グループの一部になることを許可する必要があります。たとえば、グループ（PE1、PE2）、グループ（PE1、PE3）、および別のグループ（PE2、PE3）があり、これらの3つの冗長グループのいずれかにCEをマルチホーム化できます。
There are applications that require an Ethernet network, rather than a single device, to be multihomed to a group of PEs. The Ethernet network would typically run a resiliency mechanism such as Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection Switching [G.8032]. The PEs may or may not participate in the control protocol of the Ethernet network. For a multihomed network running [802.1Q] or [G.8032], these protocols require that each VLAN to be active only on one of the multihomed links.
PEのグループにマルチホーム化するために、単一のデバイスではなくイーサネットネットワークを必要とするアプリケーションがあります。イーサネットネットワークは通常、マルチスパニングツリープロトコル[802.1Q]やイーサネットリング保護スイッチング[G.8032]などの復元メカニズムを実行します。 PEは、イーサネットネットワークの制御プロトコルに参加してもしなくてもかまいません。 [802.1Q]または[G.8032]を実行しているマルチホームネットワークの場合、これらのプロトコルでは、各VLANがマルチホームリンクの1つでのみアクティブである必要があります。
(R6a) A solution MUST support multihomed network connectivity with single-active redundancy mode where all VLANs are active on one PE.
（R6a）ソリューションは、すべてのVLANが1つのPEでアクティブであるシングルアクティブ冗長モードでマルチホームネットワーク接続をサポートする必要があります。
(R6b) A solution MUST also support multihomed networks with single-active redundancy mode where disjoint VLAN sets are active on disparate PEs.
（R6b）ソリューションは、分離したVLANセットが異種のPEでアクティブであるシングルアクティブ冗長モードでマルチホームネットワークもサポートする必要があります。
(R6c) A solution SHOULD support single-active redundancy mode among PEs that are members of a redundancy group spanning multiple ASes.
（R6c）ソリューションは、複数のASにまたがる冗長グループのメンバーであるPE間のシングルアクティブ冗長モードをサポートする必要があります（SHOULD）。
(R6d) A solution MAY support all-active redundancy mode for a multihomed network with MAC-based load balancing (i.e., different MAC addresses on a VLAN are reachable via different PEs).
（R6d）ソリューションは、MACベースのロードバランシングを備えたマルチホームネットワークのオールアクティブ冗長モードをサポートする可能性があります（つまり、VLAN上の異なるMACアドレスは、異なるPEを介して到達可能です）。
There are environments where the use of MP2MP LSPs may be desirable for optimizing multicast, broadcast, and unknown unicast traffic in order to reduce the amount of multicast states in the core routers. [RFC7117] precludes the use of MP2MP LSPs since current VPLS solutions require an egress PE to perform learning when it receives unknown unicast packets over an LSP. This is challenging when MP2MP LSPs are used, as they do not have inherent mechanisms to identify the sender. The use of MP2MP LSPs for multicast optimization becomes tractable if the need to identify the sender for performing learning is lifted.
コアルータのマルチキャストステートの量を減らすために、MP2MP LSPの使用がマルチキャスト、ブロードキャスト、および未知のユニキャストトラフィックを最適化するために望ましい環境があります。 [RFC7117]は、現在のVPLSソリューションがLSPを介して不明なユニキャストパケットを受信したときに、出力PEが学習を実行する必要があるため、MP2MP LSPの使用を排除します。 MP2MP LSPを使用する場合、送信者を識別する固有のメカニズムがないため、これは困難です。 MP2MP LSPをマルチキャストの最適化に使用することは、学習を実行するための送信者を識別する必要がなくなると扱いやすくなります。
(R7a) A solution MUST be able to provide a mechanism that does not require MAC learning against MPLS LSPs when packets are received over a MP2MP LSP.
（R7a）ソリューションは、パケットがMP2MP LSP経由で受信されたときに、MPLS LSPに対するMAC学習を必要としないメカニズムを提供できなければなりません（MUST）。
(R7b) A solution SHOULD be able to provide procedures to use MP2MP LSPs for optimizing delivery of multicast, broadcast, and unknown unicast traffic.
（R7b）ソリューションは、MP2MP LSPを使用して、マルチキャスト、ブロードキャスト、および未知のユニキャストトラフィックの配信を最適化する手順を提供できる必要があります（SHOULD）。
As L2VPN technologies expand into enterprise deployments, ease of provisioning becomes paramount. Even though current VPLS has an auto-discovery mechanism, which enables automated discovery of member PEs belonging to a given VPN instance over the MPLS/IP core network, further simplifications are required, as outlined below:
L2VPNテクノロジーがエンタープライズ展開に拡大するにつれて、プロビジョニングの容易さが最も重要になります。現在のVPLSには、MPLS / IPコアネットワークを介して特定のVPNインスタンスに属するメンバーPEの自動検出を可能にする自動検出メカニズムがありますが、以下に概説するように、さらに簡素化する必要があります。
(R8a) The solution MUST support auto-discovery of VPN member PEs over the MPLS/IP core network, similar to the VPLS auto-discovery mechanism described in [RFC4761] and [RFC6074].
（R8a）ソリューションは、[RFC4761]と[RFC6074]で説明されているVPLS自動検出メカニズムと同様に、MPLS / IPコアネットワークを介したVPNメンバーPEの自動検出をサポートする必要があります。
(R8b) The solution SHOULD support auto-discovery of PEs belonging to a given redundancy or multihomed group.
（R8b）ソリューションは、特定の冗長性またはマルチホームグループに属するPEの自動検出をサポートする必要があります（SHOULD）。
(R8c) The solution SHOULD support auto-sensing of the site ID for a multihomed device or network and support auto-generation of the redundancy group ID based on the site ID.
（R8c）ソリューションは、マルチホームデバイスまたはネットワークのサイトIDの自動検知をサポートし、サイトIDに基づく冗長グループIDの自動生成をサポートする必要があります（SHOULD）。
(R8d) The solution SHOULD support automated Designated Forwarder (DF) election among PEs participating in a redundancy (multihoming) group and be able to divide service instances (e.g., VLANs) among member PEs of the redundancy group.
（R8d）ソリューションは、冗長（マルチホーミング）グループに参加しているPE間の自動Designated Forwarder（DF）選定をサポートし、冗長インスタンスのメンバーPE間でサービスインスタンス（VLANなど）を分割できるようにする必要があります（SHOULD）。
(R8e) For deployments where VLAN identifiers are global across the MPLS network (i.e., the network is limited to a maximum of 4K services), the PE devices SHOULD derive the MPLS-specific attributes (e.g., VPN ID, BGP Route Target, etc.) from the VLAN identifier. This way, it is sufficient for the network operator to configure the VLAN identifier(s) for the access circuit, and all the MPLS and BGP parameters required for setting up the service over the core network would be automatically derived without any need for explicit configuration.
（R8e）VLAN識別子がMPLSネットワーク全体でグローバルである展開（つまり、ネットワークが最大4Kサービスに制限されている）の場合、PEデバイスはMPLS固有の属性（VPN ID、BGPルートターゲットなど）を導出する必要があります（SHOULD）。 。）VLAN識別子から。このように、ネットワークオペレーターはアクセス回線のVLAN識別子を構成するだけで十分であり、コアネットワークを介してサービスをセットアップするために必要なすべてのMPLSおよびBGPパラメーターは、明示的な構成を必要とせずに自動的に導出されます。
(R8f) Implementations SHOULD revert to using default values for parameters for which no new values are configured.
（R8f）実装は、新しい値が構成されていないパラメーターのデフォルト値を使用するように戻す必要があります（SHOULD）。
[MEF] and [802.1Q] have the following services specified:
[MEF]と[802.1Q]には、次のサービスが指定されています。
- Port mode: in this mode, all traffic on the port is mapped to a single bridge domain and a single corresponding L2VPN service instance. Customer VLAN transparency is guaranteed end to end.
- ポートモード：このモードでは、ポートのすべてのトラフィックが単一のブリッジドメインと対応する単一のL2VPNサービスインスタンスにマッピングされます。お客様のVLAN透過性はエンドツーエンドで保証されます。
- VLAN mode: in this mode, each VLAN on the port is mapped to a unique bridge domain and corresponding L2VPN service instance. This mode allows for service multiplexing over the port and supports optional VLAN translation.
- VLANモード：このモードでは、ポートの各VLANは一意のブリッジドメインと対応するL2VPNサービスインスタンスにマッピングされます。このモードでは、ポートを介したサービスの多重化が可能になり、オプションのVLAN変換がサポートされます。
- VLAN bundling: in this mode, a group of VLANs on the port are collectively mapped to a unique bridge domain and corresponding L2VPN service instance. Customer MAC addresses must be unique across all VLANs mapped to the same service instance.
- VLANバンドリング：このモードでは、ポート上のVLANのグループは、一意のブリッジドメインと対応するL2VPNサービスインスタンスにまとめてマッピングされます。カスタマーMACアドレスは、同じサービスインスタンスにマッピングされたすべてのVLANで一意である必要があります。
For each of the above services, a single bridge domain is assigned per service instance on the PE supporting the associated service. For example, in case of the port mode, a single bridge domain is assigned for all the ports belonging to that service instance, regardless of the number of VLANs coming through these ports.
上記の各サービスについて、関連するサービスをサポートするPE上のサービスインスタンスごとに1つのブリッジドメインが割り当てられます。たとえば、ポートモードの場合、これらのポートを経由するVLANの数に関係なく、そのサービスインスタンスに属するすべてのポートに単一のブリッジドメインが割り当てられます。
It is worth noting that the term 'bridge domain' as used above refers to a MAC forwarding table as defined in the IEEE bridge model and does not denote or imply any specific implementation.
上記で使用されている「ブリッジドメイン」という用語は、IEEEブリッジモデルで定義されているMAC転送テーブルを指し、特定の実装を示したり示唆したりするものではないことに注意してください。
[RFC4762] defines two types of VPLS services based on "unqualified and qualified learning", which in turn maps to port mode and VLAN mode, respectively.
[RFC4762]は、「非修飾学習と修飾学習」に基づいて2つのタイプのVPLSサービスを定義します。これは、それぞれポートモードとVLANモードにマッピングされます。
(R9a) A solution MUST support the above three service types (port mode, VLAN mode, and VLAN bundling).
（R9a）ソリューションは、上記の3つのサービスタイプ（ポートモード、VLANモード、およびVLANバンドリング）をサポートする必要があります。
For hosted applications for data-center interconnect, network operators require the ability to extend Ethernet VLANs over a WAN using a single L2VPN instance while maintaining data-plane separation between the various VLANs associated with that instance. This is referred to as 'VLAN-aware bundling service'.
データセンター相互接続用のホスト型アプリケーションの場合、ネットワークオペレーターは、そのインスタンスに関連付けられたさまざまなVLAN間のデータプレーンの分離を維持しながら、単一のL2VPNインスタンスを使用してWAN経由でイーサネットVLANを拡張する機能を必要とします。これは、「VLAN対応バンドルサービス」と呼ばれます。
(R9b) A solution MAY support VLAN-aware bundling service.
（R9b）ソリューションは、VLAN対応バンドルサービスをサポートする場合があります。
This gives rise to two new service interface types: VLAN-aware bundling without translation and VLAN-aware bundling with translation.
これにより、2つの新しいサービスインターフェイスタイプが発生します。変換なしのVLAN対応バンドルと変換ありのVLAN対応バンドリングです。
The service interface for VLAN-aware bundling without translation has the following characteristics:
変換なしのVLAN対応バンドリングのサービスインターフェイスには、次の特性があります。
- The service interface provides bundling of customer VLANs into a single L2VPN service instance.
- サービスインターフェイスは、カスタマーVLANを単一のL2VPNサービスインスタンスにバンドルすることを提供します。
- The service interface guarantees customer VLAN transparency end to end.
- サービスインターフェイスは、カスタマーVLANの透過性をエンドツーエンドで保証します。
- The service interface maintains data-plane separation between the customer VLANs (i.e., creates a dedicated bridge-domain per VLAN).
- サービスインターフェイスは、カスタマーVLAN間のデータプレーンの分離を維持します（つまり、VLANごとに専用のブリッジドメインを作成します）。
In the special case of all-to-one bundling, the service interface must not assume any a priori knowledge of the customer VLANs. In other words, the customer VLANs shall not be configured on the PE; rather, the interface is configured just like a port-based service.
all-to-oneバンドリングの特別なケースでは、サービスインターフェイスは、カスタマーVLANに関する事前の知識を前提としてはなりません。つまり、カスタマーVLANはPEで設定されません。むしろ、インターフェースはポートベースのサービスのように構成されています。
The service interface for VLAN-aware bundling with translation has the following characteristics:
変換を伴うVLAN対応バンドルのサービスインターフェイスには、次の特性があります。
- The service interface provides bundling of customer VLANs into a single L2VPN service instance.
- サービスインターフェイスは、カスタマーVLANを単一のL2VPNサービスインスタンスにバンドルすることを提供します。
- The service interface maintains data-plane separation between the customer VLANs (i.e., creates a dedicated bridge-domain per VLAN).
- サービスインターフェイスは、カスタマーVLAN間のデータプレーンの分離を維持します（つまり、VLANごとに専用のブリッジドメインを作成します）。
- The service interface supports customer VLAN ID translation to handle the scenario where different VLAN Identifiers (VIDs) are used on different interfaces to designate the same customer VLAN.
- サービスインターフェイスは、カスタマーVLAN ID変換をサポートし、異なるインターフェイスで異なるVLAN ID（VID）を使用して同じカスタマーVLANを指定するシナリオを処理します。
The main difference, in terms of service-provider resource allocation, between these new service types and the previously defined three types is that the new services require several bridge domains to be allocated (one per customer VLAN) per L2VPN service instance as opposed to a single bridge domain per L2VPN service instance.
これらの新しいサービスタイプと以前に定義された3つのタイプの間のサービスプロバイダーリソース割り当ての主な違いは、新しいサービスでは、L2VPNサービスインスタンスごとに複数のブリッジドメインを割り当てる必要があることです（カスタマーVLANごとに1つ）。 L2VPNサービスインスタンスごとに単一のブリッジドメイン。
(R10a) A solution MUST provide the ability to recover from PE-CE attachment circuit failures as well as PE node failure for the cases of both multihomed device and multihomed network.
（R10a）ソリューションは、マルチホームデバイスとマルチホームネットワークの両方のケースで、PE-CE接続回線の障害とPEノードの障害から回復する機能を提供する必要があります。
(R10b) The recovery mechanism(s) MUST provide convergence time that is independent of the number of MAC addresses learned by the PE. This is particularly important in the context of virtualization applications, which are fueling an increase in the number of MAC addresses to be handled by the Layer 2 network.
（R10b）回復メカニズムは、PEによって学習されたMACアドレスの数に依存しない収束時間を提供する必要があります。これは、レイヤー2ネットワークで処理されるMACアドレスの数の増加に拍車をかけている仮想化アプリケーションのコンテキストで特に重要です。
(R10c) Furthermore, the recovery mechanism(s) SHOULD provide convergence time that is independent of the number of service instances associated with the attachment circuit or the PE.
（R10c）さらに、回復メカニズムは、接続回線またはPEに関連付けられたサービスインスタンスの数に依存しない収束時間を提供する必要があります（SHOULD）。
(R11a) The solution SHOULD allow the network operator to choose whether unknown unicast frames are to be dropped or to be flooded. This attribute needs to be configurable on a per-service-instance basis.
（R11a）ソリューションは、ネットワークオペレーターが不明なユニキャストフレームをドロップするかフラッディングするかを選択できるようにする必要があります（SHOULD）。この属性は、サービスインスタンスごとに構成可能である必要があります。
(R11b) In addition, for the case where the solution is used for data-center interconnect, the solution SHOULD minimize the flooding of broadcast frames outside the confines of a given site. Of particular interest is periodic Address Resolution Protocol (ARP) traffic.
（R11b）さらに、ソリューションがデータセンター相互接続に使用される場合、ソリューションは、特定のサイトの範囲外のブロードキャストフレームのフラッディングを最小限に抑える必要があります。特に興味深いのは、定期的なアドレス解決プロトコル（ARP）トラフィックです。
(R11c) Furthermore, the solution SHOULD eliminate any unnecessary flooding of unicast traffic upon topology changes, especially in the case of a multihomed site where the PEs have a priori knowledge of the backup paths for a given MAC address.
（R11c）さらに、ソリューションは、特にPEが特定のMACアドレスのバックアップパスを事前に認識しているマルチホームサイトの場合、トポロジ変更時にユニキャストトラフィックの不要なフラッディングを排除する必要があります（SHOULD）。
(R12a) A solution MUST be capable of supporting flexible VPN topologies that are not constrained by the underlying mechanisms of the solution.
（R12a）ソリューションは、ソリューションの基礎となるメカニズムによって制約されない柔軟なVPNトポロジをサポートできなければなりません（MUST）。
One example of this is E-Tree topology, where one or more sites in the VPN are roots and the others are leaves. The roots are allowed to send traffic to other roots and to leaves, while leaves can communicate only with the roots. The solution MUST provide the ability to support E-Tree topology.
これの1つの例は、VPN内の1つ以上のサイトがルートであり、他のサイトがリーフであるEツリートポロジです。ルートは他のルートとリーフにトラフィックを送信できますが、リーフはルートとのみ通信できます。ソリューションは、Eツリートポロジをサポートする機能を提供する必要があります。
(R12b) The solution MAY provide the ability to apply policies at the granularity of the MAC address to control which PEs in the VPN learn which MAC address and how a specific MAC address is forwarded. It should be possible to apply policies to allow only some of the member PEs in the VPN to send or receive traffic for a particular MAC address.
（R12b）ソリューションは、VPN内のどのPEがどのMACアドレスを学習し、特定のMACアドレスがどのように転送されるかを制御するために、MACアドレスの粒度でポリシーを適用する機能を提供する場合があります。 VPNの一部のメンバーPEだけが特定のMACアドレスのトラフィックを送受信できるようにするポリシーを適用できるはずです。
(R12c) A solution MUST be capable of supporting both inter-AS option-C and inter-AS option-B scenarios as described in [RFC4364].
（R12c）ソリューションは、[RFC4364]で説明されているように、AS間オプションCとAS間オプションBの両方のシナリオをサポートできる必要があります。
Any protocol extensions developed for the EVPN solution shall include the appropriate security analysis. Besides the security requirements covered in [RFC4761] and [RFC4762] when MAC learning is performed in data-plane and in [RFC4364] when MAC learning is performed in control plane, the following additional requirements need to be covered.
EVPNソリューション用に開発されたプロトコル拡張には、適切なセキュリティ分析が含まれます。データプレーンでMAC学習が実行される場合は[RFC4761]と[RFC4762]でカバーされ、コントロールプレーンでMAC学習が実行される場合は[RFC4364]でカバーされるセキュリティ要件に加えて、次の追加要件をカバーする必要があります。
(R13) A solution MUST be capable of detecting and properly handling a situation where the same MAC address appears behind two different Ethernet segments (whether inadvertently or maliciously).
（R13）ソリューションは、同じMACアドレスが2つの異なるイーサネットセグメントの背後にある（不注意または悪意にかかわらず）状況を検出して適切に処理できなければなりません（MUST）。
(R14) A solution MUST be capable of associating a MAC address to a specific Ethernet segment (aka "sticky MAC") in order to help limit malicious traffic into a network for that MAC address. This capability can limit the appearance of spoofed MAC addresses on a network. When this feature is enabled, the MAC mobility for such sticky MAC addresses are disallowed, and the traffic for such MAC addresses from any other Ethernet segment MUST be discarded.
（R14）ソリューションは、MACアドレスのネットワークへの悪意のあるトラフィックを制限するために、MACアドレスを特定のイーサネットセグメント（別名「スティッキーMAC」）に関連付けることができる必要があります。この機能により、ネットワーク上のスプーフィングされたMACアドレスの出現を制限できます。この機能が有効になっている場合、そのようなスティッキMACアドレスのMACモビリティは許可されず、他のイーサネットセグメントからのそのようなMACアドレスのトラフィックは破棄する必要があります。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", Std. 802.1AX-2008, IEEE Computer Society, November 2008.
[802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Link Aggregation」、Std。 802.1AX-2008、IEEE Computer Society、2008年11月。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", Std. 802.1Q-2011, 2011.
[802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Virtual Bridged Local Area Networks」、Std。 802.1Q-2011、2011。
[G.8032] ITU-T, "Ethernet ring protection switching", ITU-T Recommendation G.8032, February 2012.
[G.8032] ITU-T、「イーサネットリング保護スイッチング」、ITU-T勧告G.8032、2012年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4364] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007.
[RFC4364] Bersani、F。およびH. Tschofenig、「EAP-PSK Protocol：A Pre-Shared Key Extensible Authentication Protocol（EAP）Method」、RFC 4764、2007年1月。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "Virtual Private LAN Service（VPLS）Using BGP for Auto-Discovery and Signaling"、RFC 4761、2007年1月。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、2007年1月。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6074]ローゼン、E。、デービー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、2011年1月。
[VPLS-BGP-MH] Kothari, B., Kompella, K., Henderickx, W., Balue, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2013.
[VPLS-BGP-MH] Kothari、B.、Kompella、K.、Henderickx、W.、Balue、F.、Uttaro、J.、Palislamovic、S。、およびW. Lin、「仮想のBGPベースのマルチホーミングプライベートLANサービス」、Work in Progress、2013年7月。
[PWE3-ICCP] Martini, L., Salam, S., Sajassi, A., and S. Matsushima, "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Work in Progress, March 2014.
[PWE3-ICCP] Martini、L.、Salam、S.、Sajassi、A.、およびS. Matsushima、「L2VPN PE冗長性のためのシャーシ間通信プロトコル」、Work in Progress、2014年3月。
[MEF] Metro Ethernet Forum, "Ethernet Service Definitions", MEF 6.1 Technical Specification, April 2008.
[MEF]メトロイーサネットフォーラム、「イーサネットサービス定義」、MEF 6.1技術仕様、2008年4月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L.、Ed。およびE. Rosen、Ed。、 "Framework for Layer 2 Virtual Private Networks（L2VPNs）"、RFC 4664、2006年9月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W。、およびL. Yong、「The Use of Entropy Labels in MPLS Forwarding」、RFC 6790、2012年11月。
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014.
[RFC7117] Aggarwal、R.、Ed。、Kamite、Y.、Fang、L.、Rekhter、Y。、およびC. Kodeboniya、「Multicast in Virtual Private LAN Service（VPLS）」、RFC 7117、2014年2月。
Samer Salam, Cisco, ssalam@cisco.com John Drake, Juniper, jdrake@juniper.net Clarence Filsfils, Cisco, cfilsfil@cisco.com
Samer Salam、Cisco、ssalam @ cisco.com John Drake、Juniper、jdrake @ juniper.net Clarence Filsfils、Cisco、cfilsfil @ cisco.com
Authors' Addresses
著者のアドレス
Ali Sajassi Cisco EMail: sajassi@cisco.com
Ali Sajassi Cisco EMail：sajassi@cisco.com
Rahul Aggarwal Arktan EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Arktan Eメール：raggarwa_1@yahoo.com
James Uttaro AT&T EMail: uttaro@att.com
James Answer：たくさんのメール：Answer：AT.com
Nabil Bitar Verizon Communications EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon Communications Eメール：nabil.n.bitar@verizon.com
Wim Henderickx Alcatel-Lucent EMail: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucentメール：wim.henderickx@alcatel-lucent.com
Aldrin Isaac Bloomberg EMail: aisaac71@bloomberg.net
アルドリンアイザックブルームバーグEメール：aisaac71@bloomberg.net