[要約] 要約：RFC 8560は、Ethernet VPN（EVPN）とVirtual Private LAN Service（VPLS）およびそれらのProvider Backbone Bridge（PBB）の統合に関するガイドラインを提供しています。目的：このRFCの目的は、EVPNとVPLSおよびそれらのPBBの相互運用性を向上させ、ネットワークのシームレスな統合を実現することです。
Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 8560 S. Salam
Category: Standards Track Cisco
ISSN: 2070-1721 N. Del Regno
Verizon
J. Rabadan
Nokia
May 2019
Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents
イーサネットVPN（EVPN）と仮想プライベートLANサービス（VPLS）およびそれらのプロバイダーバックボーンブリッジ（PBB）とのシームレスな統合
Abstract
概要
This document specifies mechanisms for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPN Provider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks. This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media Access Control (MAC) mobility operation. This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN PEs.
このドキュメントでは、イーサネットVPN（EVPN）およびプロバイダーバックボーンブリッジイーサネットVPN（PBB-EVPN）ソリューションと、仮想プライベートLANサービス（VPLS）およびプロバイダーバックボーンブリッジVPLS（PBB-VPLS）ソリューションの下位互換性のためのメカニズムについて説明します。また、VPNインスタンスごとに同じMPLS / IPネットワークにこれら2つのテクノロジーをシームレスに統合するためのメカニズムも提供します。このドキュメントの実装により、サービスプロバイダーは、VPLS / PBB-VPLSネットワークのブラウンフィールド展開にEVPN / PBB-EVPNプロバイダーエッジ（PE）を導入できます。このドキュメントでは、1）VPNインスタンス、2）マルチキャストおよびユニキャスト操作、3）メディアアクセスコントロール（MAC）モビリティ操作の自動検出に必要なコントロールプレーンと転送動作を指定します。これにより、EVPNとVPLS PEの間、およびPBB-VPLSとPBB-EVPN PEの間のシームレスな統合が可能になります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8560.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8560で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
3. VPLS Integration with EVPN . . . . . . . . . . . . . . . . . 7
3.1. Capability Discovery . . . . . . . . . . . . . . . . . . 7
3.2. Forwarding Setup and Unicast Operation . . . . . . . . . 8
3.3. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Multicast Operation . . . . . . . . . . . . . . . . . . . 10
3.4.1. Ingress Replication . . . . . . . . . . . . . . . . . 10
3.4.2. P2MP Tunnel . . . . . . . . . . . . . . . . . . . . . 10
4. PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . 10
4.1. Capability Discovery . . . . . . . . . . . . . . . . . . 11
4.2. Forwarding Setup and Unicast Operation . . . . . . . . . 11
4.3. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Multicast Operation . . . . . . . . . . . . . . . . . . . 12
4.4.1. Ingress Replication . . . . . . . . . . . . . . . . . 12
4.4.2. P2MP Tunnel: Inclusive Tree . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Virtual Private LAN Service (VPLS) and Provider Backbone Bridging VPLS (PBB-VPLS) are widely deployed Layer 2 VPN (L2VPN) technologies. Many service providers who are looking at adopting Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) want to preserve their investments in the VPLS and PBB-VPLS networks. Hence, they require mechanisms by which EVPN and PBB-EVPN technologies can be introduced into their brownfield VPLS and PBB-VPLS networks without requiring any upgrades (software or hardware) to these networks. This document specifies procedures for the seamless integration of the two technologies in the same MPLS/IP network. Throughout this document, we use the term "(PBB-)EVPN" to correspond to both EVPN and PBB-EVPN, and we use the term "(PBB-)VPLS" to correspond to both VPLS and PBB-VPLS. This document specifies the control-plane and forwarding behavior needed for 1) auto-discovery of a VPN instance, 2) multicast and unicast operations, and 3) a MAC mobility operation. This enables seamless integration between (PBB-)EVPN Provider Edge (PE) devices and (PBB-)VPLS PEs.
仮想プライベートLANサービス（VPLS）およびプロバイダーバックボーンブリッジングVPLS（PBB-VPLS）は、広く展開されているレイヤー2 VPN（L2VPN）テクノロジです。イーサネットVPN（EVPN）およびプロバイダーバックボーンブリッジングEVPN（PBB-EVPN）の採用を検討している多くのサービスプロバイダーは、VPLSおよびPBB-VPLSネットワークへの投資を維持したいと考えています。したがって、EVPNおよびPBB-EVPNテクノロジーをブラウンフィールドVPLSおよびPBB-VPLSネットワークに導入するためのメカニズムが必要です。これらのネットワークをアップグレード（ソフトウェアまたはハードウェア）する必要はありません。このドキュメントでは、2つのテクノロジーを同じMPLS / IPネットワークにシームレスに統合する手順を説明しています。このドキュメント全体で、「（PBB-）EVPN」という用語はEVPNとPBB-EVPNの両方に対応するために使用し、「（PBB-）VPLS」という用語はVPLSとPBB-VPLSの両方に対応するために使用します。このドキュメントでは、1）VPNインスタンスの自動検出、2）マルチキャストおよびユニキャスト操作、および3）MACモビリティ操作に必要なコントロールプレーンと転送動作を指定します。これにより、（PBB-）EVPNプロバイダーエッジ（PE）デバイスと（PBB-）VPLS PE間のシームレスな統合が可能になります。
VPLS PE
+---+
|PE1|
+---+
/
EVPN/VPLS PE +---------------+ EVPN/VPLS PE
+---+ | | +---+
|PE4|----| MPLS/IP |---|PE5|
+---+ | Core | +---+
| |
+---------------+
/ \
+---+ +---+
|PE2| |PE3|
+---+ +---+
VPLS PE VPLS PE
Figure 1: Seamless Integration of (PBB-)EVPN and (PBB-)VPLS
図1：（PBB-）EVPNと（PBB-）VPLSのシームレスな統合
Section 2 provides the details of the requirements. Section 3 specifies procedures for the seamless integration of VPLS and EVPN networks. Section 4 specifies procedures for the seamless integration of PBB-VPLS and PBB-EVPN networks.
セクション2では、要件の詳細について説明します。セクション3では、VPLSネットワークとEVPNネットワークのシームレスな統合の手順を指定します。セクション4では、PBB-VPLSおよびPBB-EVPNネットワークのシームレスな統合の手順を指定します。
It should be noted that the scenarios for both PBB-VPLS integration with EVPN and VPLS integration with PBB-EVPN are not covered in this document because there haven't been any requirements from service providers for these scenarios; deployments that employ PBB-VPLS typically require PBB encapsulation for various reasons. Hence, it is expected that for those deployments, the evolution path would move from PBB-VPLS towards PBB-EVPN. Furthermore, the evolution path from VPLS is expected to move towards EVPN.
EVPNとのPBB-VPLS統合とPBB-EVPNとのVPLS統合の両方のシナリオは、これらのシナリオに対してサービスプロバイダーからの要件がなかったため、このドキュメントでは説明されていません。 PBB-VPLSを使用する展開では、さまざまな理由により、通常PBBカプセル化が必要です。したがって、それらの展開では、進化のパスはPBB-VPLSからPBB-EVPNに移動すると予想されます。さらに、VPLSからの進化の道はEVPNに向かって進むと予想されます。
The seamless integration solution described in this document has the following attributes:
このドキュメントで説明するシームレスな統合ソリューションには、次の属性があります。
- When ingress replication is used for multi-destination traffic delivery, the solution reduces the scope of MMRP (which is a soft-state protocol defined in Clause 10 of [IEEE.802.1Q]) to only that of existing VPLS PEs and uses the more robust BGP-based mechanism for multicast pruning among new EVPN PEs.
- 複数の宛先のトラフィック配信に入力レプリケーションが使用される場合、ソリューションはMMRP（[IEEE.802.1Q]の条項10で定義されたソフトステートプロトコル）のスコープを既存のVPLS PEのスコープのみに減らし、より多くを使用します新しいEVPN PE間のマルチキャストプルーニング用の堅牢なBGPベースのメカニズム。
- It is completely backward compatible.
- 完全に下位互換性があります。
- New PEs can leverage the extensive multihoming mechanisms and provisioning simplifications of (PBB-)EVPN:
- 新しいPEは、（PBB-）EVPNの広範なマルチホーミングメカニズムとプロビジョニングの簡素化を活用できます。
(a) Auto-sensing of Multihomed Networks (MHNs) / Multihomed Devices (MHDs)
（a）マルチホームネットワーク（MHN）/マルチホームデバイス（MHD）の自動検知
(b) Auto-discovery of redundancy groups
（b）冗長グループの自動検出
(c) Auto-provisioning of Designated Forwarder election and VLAN carving
（c）指定フォワーダー選定とVLANカービングの自動プロビジョニング
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
B-MAC: Backbone MAC, e.g., the PE's MAC address
B-MAC：PEのMACアドレスなどのバックボーンMAC
C-MAC: Customer MAC, e.g., a host or CE's MAC address
C-MAC：ホストまたはCEのMACアドレスなどのカスタマーMAC
CE: A Customer Edge device, e.g., a host, router, or switch
CE：カスタマーエッジデバイス（ホスト、ルーター、スイッチなど）
ES: Ethernet Segment -- refers to the set of Ethernet links that connects a customer site (device or network) to one or more PEs
ES：イーサネットセグメント-カスタマーサイト（デバイスまたはネットワーク）を1つ以上のPEに接続するイーサネットリンクのセットを指します
FEC: Forwarding Equivalence Class FIB: Forwarding Information Base -- an instantiation of a forwarding table on a MAC-VRF
FEC：転送同等クラスFIB：転送情報ベース-MAC-VRF上の転送テーブルのインスタンス化
I-SID: Service Instance Identifier
I-SID：サービスインスタンス識別子
LSP: Label Switched Path
LSP：ラベルスイッチドパス
MAC: Media Access Control
MAC：メディアアクセスコントロール
MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on an EVPN PE
MAC-VRF：EVPN PE上のメディアアクセスコントロール（MAC）アドレスの仮想ルーティングおよび転送テーブル
MHD: Multihomed Device
MHD：マルチホームデバイス
MHN: Multihomed Network
MHN：マルチホームネットワーク
MP2P: Multipoint to Point -- an MP2P LSP typically refers to an LSP for unicast traffic as the result of a downstream-assigned label
MP2P：マルチポイントツーポイント-MP2P LSPは通常、ダウンストリーム割り当てラベルの結果としてのユニキャストトラフィックのLSPを指します
P2MP: Point to Multipoint -- a P2MP LSP typically refers to an LSP for multicast traffic
P2MP：ポイントツーマルチポイント-P2MP LSPは通常、マルチキャストトラフィックのLSPを指します
PBB: Provider Backbone Bridge
PBB：プロバイダーバックボーンブリッジ
(PBB-)EVPN: Both PBB-EVPN and EVPN -- this document uses this abbreviation when a given description applies to both technologies
（PBB-）EVPN：PBB-EVPNとEVPNの両方-このドキュメントでは、指定された説明が両方のテクノロジーに適用される場合に、この省略形を使用します
(PBB-)VPLS: Both PBB-VPLS and VPLS -- this document uses this abbreviation when a given description applies to both technologies
（PBB-）VPLS：PBB-VPLSとVPLSの両方-このドキュメントでは、指定された説明が両方のテクノロジーに適用される場合に、この省略形を使用します
PE: Provider Edge device
PE：プロバイダーエッジデバイス
PW: Pseudowire
説明：シュードビル
RIB: Routing Information Base -- an instantiation of a routing table on a MAC-VRF
RIB：ルーティング情報ベース-MAC-VRF上のルーティングテーブルのインスタンス化
VSI: Virtual Switch Instance
VSI：仮想スイッチインスタンス
VPLS: Virtual Private LAN Service
VPLS：仮想プライベートLANサービス
VPLS A-D: Virtual Private LAN Service with BGP-based auto-discovery as in [RFC6074]
VPLS A-D：[RFC6074]のようなBGPベースの自動検出を備えた仮想プライベートLANサービス
All-Active redundancy mode: When all PEs attached to an Ethernet segment are allowed to forward known unicast traffic to/from that Ethernet segment for a given VLAN, then the Ethernet segment is defined as operating in All-Active redundancy mode.
オールアクティブ冗長モード：イーサネットセグメントに接続されているすべてのPEが、特定のVLANのイーサネットセグメントとの間で既知のユニキャストトラフィックを転送できる場合、イーサネットセグメントはオールアクティブ冗長モードで動作していると定義されます。
Bridge table: An instantiation of a broadcast domain on a MAC-VRF (VPN Routing and Forwarding).
ブリッジテーブル：MAC-VRF（VPNルーティングおよび転送）上のブロードキャストドメインのインスタンス化。
Broadcast domain: In a bridged network, the broadcast domain corresponds to a Virtual LAN (VLAN), where a VLAN is typically represented by a single VLAN ID (VID) but can be represented by several VIDs where Shared VLAN Learning (SVL) is used, per [IEEE.802.1Q].
ブロードキャストドメイン：ブリッジネットワークでは、ブロードキャストドメインは仮想LAN（VLAN）に対応します。VLANは通常、単一のVLAN ID（VID）で表されますが、共有VLAN学習（SVL）が使用される複数のVIDで表すこともできます。 、[IEEE.802.1Q]に従います。
Ethernet Tag: An Ethernet Tag identifies a particular broadcast domain, e.g., a VLAN. An EVPN instance consists of one or more broadcast domains.
イーサネットタグ：イーサネットタグは、VLANなどの特定のブロードキャストドメインを識別します。 EVPNインスタンスは、1つ以上のブロードキャストドメインで構成されます。
Single-Active redundancy mode: When only a single PE, among all the PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet segment for a given VLAN, then the Ethernet segment is defined as operating in Single-Active redundancy mode.
シングルアクティブ冗長モード：イーサネットセグメントに接続されているすべてのPEのうち、単一のPEのみが特定のVLANのイーサネットセグメントとの間でトラフィックを転送できる場合、イーサネットセグメントはシングルアクティブで動作していると定義されます。冗長モード。
The following are the key requirements for backward compatibility between (PBB-)EVPN and (PBB-)VPLS:
（PBB-）EVPNと（PBB-）VPLS間の下位互換性のための主要な要件は次のとおりです。
1. The solution must allow for staged migration towards (PBB-)EVPN on a site-by-site basis per VPN instance, e.g., new EVPN sites to be provisioned on (PBB-)EVPN Provider Edge devices (PEs).
1. このソリューションでは、VPNインスタンスごとにサイトごとに（PBB-）EVPNへの段階的な移行を許可する必要があります。たとえば、（PBB-）EVPNプロバイダーエッジデバイス（PE）で新しいEVPNサイトをプロビジョニングする必要があります。
2. The solution must not require any changes to existing VPLS or PBB-VPLS PEs, not even a software upgrade.
2. ソリューションは、ソフトウェアのアップグレードでさえも、既存のVPLSまたはPBB-VPLS PEへの変更を必要としてはなりません。
3. The solution must allow for the coexistence of PE devices running (PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single-homed segments.
3. このソリューションでは、同じVPNインスタンスとシングルホームセグメントで（PBB-）EVPNと（PBB-）VPLSを実行しているPEデバイスの共存を許可する必要があります。
4. The solution must support single-active redundancy of multihomed networks and multihomed devices for (PBB-)EVPN PEs.
4. このソリューションは、（PBB-）EVPN PEのマルチホームネットワークおよびマルチホームデバイスのシングルアクティブ冗長性をサポートする必要があります。
5. In cases of single-active redundancy, the participant VPN instances may span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as the MHD or MHN is connected to (PBB-)EVPN PEs.
5. シングルアクティブ冗長性の場合、MHDまたはMHNが（PBB-）EVPN PEに接続されている限り、参加者VPNインスタンスは（PBB-）EVPN PEと（PBB-）VPLS PEの両方にまたがることができます。
6. Support of the All-Active redundancy mode across both (PBB-)EVPN PEs and (PBB-)VPLS PEs is outside the scope of this document. All-Active redundancy is not applicable to VPLS and PBB-VPLS. Therefore, when EVPN (or PBB-EVPN) PEs need to operate seamlessly with VPLS (or PBB-VPLS) PEs, they MUST use a redundancy mode that is applicable to VPLS (or PBB-VPLS). This redundancy mode is Single-Active.
6. （PBB-）EVPN PEと（PBB-）VPLS PEの両方でのAll-Active冗長モードのサポートは、このドキュメントの範囲外です。 All-Active冗長性は、VPLSおよびPBB-VPLSには適用されません。したがって、EVPN（またはPBB-EVPN）PEがVPLS（またはPBB-VPLS）PEとシームレスに動作する必要がある場合、VPLS（またはPBB-VPLS）に適用可能な冗長モードを使用する必要があります。この冗長モードはシングルアクティブです。
These requirements collectively allow for the seamless insertion of (PBB-)EVPN technology into brownfield (PBB-)VPLS deployments.
これらの要件により、ブラウンフィールド（PBB-）VPLS展開への（PBB-）EVPNテクノロジーのシームレスな挿入が集合的に可能になります。
In order to support seamless integration with VPLS PEs, this document requires that VPLS PEs support VPLS A-D per [RFC6074], and it requires EVPN PEs to support both BGP EVPN routes per [RFC7432] and VPLS A-D per [RFC6074]. All the logic for seamless integration shall reside on the EVPN PEs. If a VPLS instance is set up without the use of VPLS A-D, it is still possible (but cumbersome) for EVPN PEs to integrate that VPLS instance by manually configuring pseudowires (PWs) to all the VPLS PEs in that instance (i.e., the integration is no longer seamless).
VPLS PEとのシームレスな統合をサポートするために、このドキュメントでは、VPLS PEが[RFC6074]ごとにVPLS A-Dをサポートし、EVPN PEが[RFC7432]ごとのBGP EVPNルートと[RFC6074]ごとのVPLS A-Dの両方をサポートする必要があります。シームレスな統合のためのすべてのロジックは、EVPN PEに常駐します。 VPLS ADを使用せずにVPLSインスタンスをセットアップした場合でも、EVPN PEは、そのインスタンスのすべてのVPLS PEに疑似配線（PW）を手動で構成することにより（つまり、統合）、そのVPLSインスタンスを統合できます（つまり、統合シームレスではなくなりました）。
The EVPN PEs MUST advertise both the BGP VPLS auto-discovery (A-D) route as well as the BGP EVPN Inclusive Multicast Ethernet Tag (IMET) route for a given VPN instance. The VPLS PEs only advertise the BGP VPLS A-D route, per the procedures specified in [RFC4761], [RFC4762] and [RFC6074]. The operator may decide to use the same Route Target (RT) to identify a VPN on both EVPN and VPLS networks. In this case, when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the basis that it belongs to an unknown Subsequent Address Family Identifier (SAFI). However, the operator may choose to use two RTs -- one to identify the VPN on the VPLS network and another for the EVPN network -- and employ RT Constrain mechanisms [RFC4684] in order to prevent BGP EVPN routes from reaching the VPLS PEs.
EVPN PEは、特定のVPNインスタンスのBGP VPLS自動検出（A-D）ルートとBGP EVPNインクルーシブマルチキャストイーサネットタグ（IMET）ルートの両方をアドバタイズする必要があります。 VPLS PEは、[RFC4761]、[RFC4762]、および[RFC6074]で指定された手順に従って、BGP VPLS A-Dルートのみをアドバタイズします。オペレーターは、同じルートターゲット（RT）を使用して、EVPNネットワークとVPLSネットワークの両方でVPNを識別することを決定できます。この場合、VPLS PEがEVPN IMETルートを受信すると、それが未知の後続アドレスファミリ識別子（SAFI）に属していることに基づいて、それを無視する必要があります。ただし、オペレーターは2つのRTを使用することを選択できます-1つはVPLSネットワーク上のVPNを識別し、もう1つはEVPNネットワーク用です-RT制約メカニズム[RFC4684]を使用して、BGP EVPNルートがVPLS PEに到達しないようにします。
When an EVPN PE receives both a VPLS A-D route as well as an EVPN IMET route from a given remote PE for the same VPN instance, it MUST give preference to the EVPN route for the purpose of discovery. This ensures that, at the end of the route exchanges, all EVPN-capable PEs discover other EVPN-capable PEs in addition to the VPLS-only PEs for that VPN instance. Furthermore, all the VPLS-only PEs will discover the EVPN PEs as if they were standard VPLS PEs. In other words, when the discovery phase is complete, the EVPN PEs will have discovered all the PEs in the VPN instance along with their associated capability (EVPN or VPLS-only), whereas the VPLS PEs will have discovered all the PEs in the VPN instance as if they were all VPLS-only PEs.
EVPN PEが、同じVPNインスタンスの特定のリモートPEからVPLS A-DルートとEVPN IMETルートの両方を受信する場合、検出のためにEVPNルートを優先する必要があります。これにより、ルート交換の最後に、すべてのEVPN対応PEが、そのVPNインスタンスのVPLS専用PEに加えて、他のEVPN対応PEを確実に検出します。さらに、すべてのVPLS専用PEは、標準のVPLS PEであるかのようにEVPN PEを検出します。つまり、検出フェーズが完了すると、EVPN PEは関連する機能（EVPNまたはVPLSのみ）とともにVPNインスタンス内のすべてのPEを検出しますが、VPLS PEはVPN内のすべてのPEを検出しますすべてがVPLS専用PEであるかのようにインスタンスを作成します。
The procedures for the forwarding state setup and unicast operation on the VPLS PE are per [RFC8077], [RFC4761], and [RFC4762].
VPLS PEでの転送状態のセットアップとユニキャスト操作の手順は、[RFC8077]、[RFC4761]、および[RFC4762]に準拠しています。
The procedures for forwarding state setup and unicast operation on the EVPN PE are as follows:
EVPN PEでの転送状態設定とユニキャスト操作の手順は次のとおりです。
- The EVPN PE MUST establish a PW to each remote PE from which it has received only a VPLS A-D route for the corresponding VPN instance and MUST set up the label stack corresponding to the PW FEC. For seamless integration between EVPN and VPLS PEs, the PW that is set up between a pair of VPLS and EVPN PEs is between the VSI of the VPLS PE and the MAC-VRF of the EVPN PE.
- EVPN PEは、対応するVPNインスタンスのVPLS A-Dルートのみを受信した各リモートPEへのPWを確立する必要があり、PW FECに対応するラベルスタックをセットアップする必要があります。 EVPNとVPLS PE間のシームレスな統合のために、VPLSとEVPN PEのペア間に設定されるPWは、VPLS PEのVSIとEVPN PEのMAC-VRFの間にあります。
- The EVPN PE MUST set up the label stack corresponding to the MP2P VPN unicast FEC to any remote PE that has advertised an EVPN IMET route.
- EVPN PEは、EVPN IMETルートをアドバタイズしたリモートPEへのMP2P VPNユニキャストFECに対応するラベルスタックをセットアップする必要があります。
- If an EVPN PE receives a VPLS A-D route from a given PE, it sets up a PW to that PE. If it then receives an EVPN IMET route from the same PE, the EVPN PE MUST bring that PW operationally down.
- EVPN PEが特定のPEからVPLS A-Dルートを受信すると、そのPEにPWを設定します。その後、同じPEからEVPN IMETルートを受信した場合、EVPN PEはそのPWを操作上ダウンさせる必要があります。
- If an EVPN PE receives an EVPN IMET route followed by a VPLS A-D route from the same PE, then the EVPN PE will set up the PW but MUST keep it operationally down.
- EVPN PEがEVPN IMETルートを受信し、続いて同じPEからVPLS A-Dルートを受信した場合、EVPN PEはPWをセットアップしますが、運用的にダウン状態に維持する必要があります。
- In case VPLS A-D is not used in some VPLS PEs, the EVPN PEs need to be provisioned manually with PWs to those remote VPLS PEs for each VPN instance. In that case, if an EVPN PE receives an EVPN IMET route from a PE to which a PW exists, the EVPN PE MUST bring the PW operationally down.
- VPLS A-Dが一部のVPLS PEで使用されていない場合、EVPN PEは、各VPNインスタンスのリモートVPLS PEにPWを使用して手動でプロビジョニングする必要があります。その場合、EVPN PEがPWが存在するPEからEVPN IMETルートを受信した場合、EVPN PEはPWを操作上ダウンさせる必要があります。
When the EVPN PE receives traffic over the VPLS PWs, it learns the associated C-MAC addresses in the data plane. The C-MAC addresses learned over these PWs MUST be injected into the bridge table of the associated MAC-VRF on that EVPN PE. The learned C-MAC addresses MAY also be injected into the RIB/FIB tables of the associated MAC-VRF on that EVPN PE. For seamless integration between EVPN and VPLS PEs, because these PWs belong to the same split-horizon group (see [RFC4761] and [RFC4762]) as the MP2P EVPN service tunnels, the C-MAC addresses learned and associated with the PWs MUST NOT be advertised in the control plane to any remote EVPN PEs. This is because every EVPN PE can send and receive traffic directly to/from every VPLS PE belonging to the same VPN instance; thus, every EVPN PE can learn the C-MAC addresses over the corresponding PWs directly.
EVPN PEは、VPLS PW経由でトラフィックを受信すると、データプレーン内の関連するC-MACアドレスを学習します。これらのPWを介して学習されたC-MACアドレスは、そのEVPN PE上の関連するMAC-VRFのブリッジテーブルに挿入される必要があります。学習されたC-MACアドレスは、そのEVPN PE上の関連するMAC-VRFのRIB / FIBテーブルにも挿入される場合があります。 EVPNとVPLS PE間のシームレスな統合のために、これらのPWはMP2P EVPNサービストンネルと同じスプリットホライズングループ（[RFC4761]および[RFC4762]を参照）に属しているため、PWに関連付けられたC-MACアドレスはコントロールプレーンでリモートEVPN PEにアドバタイズされます。これは、すべてのEVPN PEが同じVPNインスタンスに属するすべてのVPLS PEと直接トラフィックを送受信できるためです。したがって、すべてのEVPN PEは、対応するPWを介してC-MACアドレスを直接学習できます。
The C-MAC addresses learned over local Attachment Circuits (ACs) by an EVPN PE are learned in the data plane. For EVPN PEs, these C-MAC addresses MUST be injected into the corresponding MAC-VRF and advertised in the control plane using BGP EVPN routes. Furthermore, the C-MAC addresses learned in the control plane via the BGP EVPN routes sent by remote EVPN PEs are injected into the corresponding MAC-VRF table.
EVPN PEによってローカル接続回路（AC）で学習されたC-MACアドレスは、データプレーンで学習されます。 EVPN PEの場合、これらのC-MACアドレスは対応するMAC-VRFに注入され、BGP EVPNルートを使用してコントロールプレーンでアドバタイズされる必要があります。さらに、リモートEVPN PEから送信されたBGP EVPNルートを介してコントロールプレーンで学習されたC-MACアドレスは、対応するMAC-VRFテーブルに挿入されます。
In case of a link failure in a single-active Ethernet segment, the EVPN PEs MUST perform both of the following tasks:
シングルアクティブイーサネットセグメントでリンク障害が発生した場合、EVPN PEは次の両方のタスクを実行する必要があります。
1. send a BGP mass withdraw to the EVPN peers
1. BGPマスウィズドロウをEVPNピアに送信する
2. follow existing VPLS MAC Flush procedures with the VPLS peers
2. VPLSピアで既存のVPLS MACフラッシュ手順に従います
In EVPN, host addresses (C-MAC addresses) can move around among EVPN PEs or even between EVPN and VPLS PEs.
EVPNでは、ホストアドレス（C-MACアドレス）はEVPN PE間で、またはEVPNとVPLS PE間でさえ移動できます。
When a C-MAC address moves from an EVPN PE to a VPLS PE, as soon as Broadcast, Unknown Unicast, and Multicast (BUM) traffic is initiated from that MAC address, it is flooded to all other PEs (both VPLS and EVPN PEs), and the receiving PEs update their MAC tables (VSI or MAC-VRF). The EVPN PEs do not advertise the C-MAC addresses learned over the PW to each other because every EVPN PE learns them directly over its associated PW to that VPLS PE. If only known unicast traffic is initiated from the moved C-MAC address toward a known C-MAC, the result can be the black-holing of traffic destined to the C-MAC that has moved until there is BUM traffic that has been originated with the moved C-MAC address as the source MAC address (e.g., as a result of the MAC age-out timer expiring). Such black-holing happens for traffic destined to the moved C-MAC from both EVPN and VPLS PEs and is typical for VPLS PEs.
C-MACアドレスがEVPN PEからVPLS PEに移動すると、そのMACアドレスからブロードキャスト、不明なユニキャスト、およびマルチキャスト（BUM）トラフィックが開始されるとすぐに、他のすべてのPE（VPLSとEVPN PEの両方）にフラッディングされます。 ）、受信PEはMACテーブル（VSIまたはMAC-VRF）を更新します。 EVPN PEは、PWを通じて学習したC-MACアドレスを相互にアドバタイズしません。これは、すべてのEVPN PEが、関連付けられたPWを通じてそのVPLS PEに直接学習するためです。既知のユニキャストトラフィックのみが、移動したC-MACアドレスから既知のC-MACに向けて開始された場合、BUMトラフィックが発生するまで移動したC-MAC宛てのトラフィックがブラックホールになる可能性があります。移動したC-MACアドレスをソースMACアドレスとして（たとえば、MACエージングアウトタイマーの期限切れの結果として）。このようなブラックホールは、EVPNとVPLS PEの両方から移動されたC-MAC宛てのトラフィックで発生し、VPLS PEで一般的です。
When a C-MAC address moves from a VPLS PE to an EVPN PE, then as soon as any traffic is initiated from that C-MAC address, the C-MAC is learned and advertised in the BGP to other EVPN PEs, and the MAC mobility procedure is performed among EVPN PEs. For BUM traffic, both EVPN and VPLS PEs learn the new location of the moved C-MAC address; however, if there is only known unicast traffic, then only EVPN PEs learn the new location of the C-MAC that has moved and not VPLS PEs. This can result in the black-holing of traffic sent from VPLS PEs destined to the C-MAC that has moved until there is BUM traffic originated with the moved C-MAC address as the source MAC address (e.g., as a result of the MAC age-out timer expiring). Such black-holing happens for traffic destined to the moved C-MAC for only VPLS PEs but not for EVPN PEs and is typical for VPLS PEs.
C-MACアドレスがVPLS PEからEVPN PEに移動すると、そのC-MACアドレスからトラフィックが開始されるとすぐに、C-MACが学習され、BGPで他のEVPN PEおよびMACにアドバタイズされます。 EVPN PE間でモビリティ手順が実行されます。 BUMトラフィックの場合、EVPNとVPLS PEの両方が、移動されたC-MACアドレスの新しい場所を学習します。ただし、既知のユニキャストトラフィックしかない場合、EVPN PEのみが移動したC-MACの新しい場所を学習し、VPLS PEは学習しません。これにより、移動したC-MACアドレスが送信元MACアドレスとして発信されたBUMトラフィックが存在するまで（たとえば、MACの結果として）、移動したC-MAC宛てのVPLS PEから送信されたトラフィックがブラックホール化する可能性がありますエージングアウトタイマーの期限切れ）。このようなブラックホールは、VPLS PEのみが移動したC-MAC宛てのトラフィックで発生し、EVPN PEは発生せず、VPLS PEで一般的です。
The procedures for multicast operation on the VPLS PE using ingress replication are per [RFC4761], [RFC4762], and [RFC7080].
入力レプリケーションを使用したVPLS PEでのマルチキャスト操作の手順は、[RFC4761]、[RFC4762]、および[RFC7080]に準拠しています。
The procedures for multicast operation on the EVPN PE for ingress replication are as follows:
入力レプリケーション用のEVPN PEでのマルチキャスト操作の手順は次のとおりです。
- The EVPN PE builds a replication sub-list to all the remote EVPN PEs per EVPN instance as the result of the exchange of the EVPN IMET routes per [RFC7432]. This will be referred to as sub-list A. It comprises MP2P service tunnels (for ingress replication) used for delivering EVPN BUM traffic [RFC7432].
- EVPN PEは、[RFC7432]によるEVPN IMETルートの交換の結果として、EVPNインスタンスごとにすべてのリモートEVPN PEへのレプリケーションサブリストを作成します。これはサブリストAと呼ばれます。これは、EVPN BUMトラフィック[RFC7432]の配信に使用されるMP2Pサービストンネル（入力レプリケーション用）で構成されます。
- The EVPN PE builds a replication sub-list per VPLS instance to all the remote VPLS PEs. This will be referred to as sub-list B. It comprises PWs from the EVPN PE in question to all the remote VPLS PEs in the same VPLS instance.
- EVPN PEは、すべてのリモートVPLS PEへのVPLSインスタンスごとにレプリケーションサブリストを作成します。これはサブリストBと呼ばれます。これは、問題のEVPN PEから、同じVPLSインスタンス内のすべてのリモートVPLS PEへのPWで構成されます。
The replication list, maintained per VPN instance, on a given EVPN PE will be the union of sub-list A and sub-list B. The EVPN PE MUST enable split horizon over all the entries in the replication list across both PWs and MP2P service tunnels.
特定のEVPN PE上のVPNインスタンスごとに維持されるレプリケーションリストは、サブリストAとサブリストBの結合になります。EVPNPEは、PWとMP2Pサービスの両方にわたるレプリケーションリストのすべてのエントリに対してスプリットホライズンを有効にする必要があります。トンネル。
The procedures for multicast operation on the EVPN PEs using P2MP tunnels are outside of the scope of this document.
P2MPトンネルを使用するEVPN PEでのマルチキャスト操作の手順は、このドキュメントの範囲外です。
In order to support seamless integration between PBB-VPLS and PBB-EVPN PEs, this document requires that PBB-VPLS PEs support VPLS A-D per [RFC6074] and PBB-EVPN PEs support both BGP EVPN routes per [RFC7432] and VPLS A-D per [RFC6074]. All the logic for this seamless integration shall reside on the PBB-EVPN PEs.
PBB-VPLSとPBB-EVPN PEの間のシームレスな統合をサポートするために、このドキュメントでは、PBB-VPLS PEが[RFC6074]ごとにVPLS ADをサポートし、PBB-EVPN PEが[RFC7432]ごとのBGP EVPNルートと[VPC ADごとRFC6074]。このシームレスな統合のすべてのロジックは、PBB-EVPN PEに常駐します。
The procedures for capability discovery are per Section 3.1.
機能検出の手順は、セクション3.1に記載されています。
The procedures for forwarding state setup and unicast operation on the PBB-VPLS PE are per [RFC8077] and [RFC7080].
PBB-VPLS PEでの転送状態設定とユニキャスト操作の手順は、[RFC8077]と[RFC7080]に準拠しています。
The procedures for forwarding state setup and unicast operation on the PBB-EVPN PE are as follows:
PBB-EVPN PEでの転送状態設定とユニキャスト操作の手順は次のとおりです。
- The PBB-EVPN PE MUST establish a PW to each remote PBB-VPLS PE from which it has received only a VPLS A-D route for the corresponding VPN instance and MUST set up the label stack corresponding to the PW FEC. For seamless integration between PBB-EVPN and PBB-VPLS PEs, the PW that is set up between a pair of PBB-VPLS and PBB-EVPN PEs is between the B-components of PBB-EVPN PE and PBB-VPLS PE per Section 4 of [RFC7041].
- PBB-EVPN PEは、対応するVPNインスタンスのVPLS A-Dルートのみを受信した各リモートPBB-VPLS PEへのPWを確立する必要があり、PW FECに対応するラベルスタックをセットアップする必要があります。 PBB-EVPN PEとPBB-VPLS PE間のシームレスな統合のために、PBB-VPLSとPBB-EVPN PEのペア間に設定されたPWは、セクション4に従って、PBB-EVPN PEとPBB-VPLS PEのBコンポーネント間にあります。 [RFC7041]の。
- The PBB-EVPN PE MUST set up the label stack corresponding to the MP2P VPN unicast FEC to any remote PBB-EVPN PE that has advertised an EVPN IMET route.
- PBB-EVPN PEは、MP2P VPNユニキャストFECに対応するラベルスタックを、EVPN IMETルートをアドバタイズしたリモートPBB-EVPN PEにセットアップする必要があります。
- If a PBB-EVPN PE receives a VPLS A-D route from a given PE, it sets up a PW to that PE. If it then receives an EVPN IMET route from the same PE, the PBB-EVPN PE MUST bring that PW operationally down.
- PBB-EVPN PEが特定のPEからVPLS A-Dルートを受信すると、そのPEにPWを設定します。その後、同じPEからEVPN IMETルートを受信した場合、PBB-EVPN PEはそのPWを運用上ダウンさせる必要があります。
- If a PBB-EVPN PE receives an EVPN IMET route followed by a VPLS A-D route from the same PE, then the PBB-EVPN PE will set up the PW but MUST keep it operationally down.
- PBB-EVPN PEがEVPN IMETルートを受信し、続いて同じPEからVPLS A-Dルートを受信した場合、PBB-EVPN PEはPWをセットアップしますが、運用上はダウンさせておく必要があります。
- In case VPLS A-D is not used in some PBB-VPLS PEs, the PBB-EVPN PEs need to be provisioned manually with PWs to those remote PBB-VPLS PEs for each VPN instance. In that case, if a PBB-EVPN PE receives an EVPN IMET route from a PE to which a PW exists, the PBB-EVPN PE MUST bring the PW operationally down.
- VPLS A-Dが一部のPBB-VPLS PEで使用されていない場合、PBB-EVPN PEは、各VPNインスタンスのそれらのリモートPBB-VPLS PEにPWを使用して手動でプロビジョニングする必要があります。その場合、PBB-EVPN PEがPWが存在するPEからEVPN IMETルートを受信した場合、PBB-EVPN PEはPWを運用上ダウンさせる必要があります。
- When the PBB-EVPN PE receives traffic over the PBB-VPLS PWs, it learns the associated B-MAC addresses in the data plane. The B-MAC addresses learned over these PWs MUST be injected into the bridge table of the associated MAC-VRF on that PBB-EVPN PE. The learned B-MAC addresses MAY also be injected into the RIB/FIB tables of the associated MAC-VRF on that BPP-EVPN PE. For seamless integration between PBB-EVPN and PBB-VPLS PEs, since these PWs belong to the same split-horizon group as the MP2P EVPN service tunnels, the B-MAC addresses learned and associated with the PWs MUST NOT be advertised in the control plane to any remote PBB-EVPN PEs. This is because every PBB-EVPN PE can send and receive traffic directly to/from every PBB-VPLS PE belonging to the same VPN instance.
-PBB-EVPN PEがPBB-VPLS PWを介してトラフィックを受信すると、データプレーン内の関連するB-MACアドレスを学習します。これらのPWを介して学習されたB-MACアドレスは、そのPBB-EVPN PE上の関連するMAC-VRFのブリッジテーブルに注入される必要があります。学習されたB-MACアドレスは、そのBPP-EVPN PE上の関連するMAC-VRFのRIB / FIBテーブルにも挿入される場合があります。 PBB-EVPNとPBB-VPLS PE間のシームレスな統合のために、これらのPWはMP2P EVPNサービストンネルと同じスプリットホライズングループに属しているため、PWに関連付けられたB-MACアドレスは、コントロールプレーンでアドバタイズされてはなりません任意のリモートPBB-EVPN PEに。これは、すべてのPBB-EVPN PEが、同じVPNインスタンスに属するすべてのPBB-VPLS PEと直接トラフィックを送受信できるためです。
- The C-MAC addresses learned over local Attachment Circuits (ACs) by a PBB-EVPN PE are learned in the data plane. For PBB-EVPN PEs, these C-MAC addresses are learned in the I-component of PBB-EVPN PEs and are not advertised in the control plane, per [RFC7623].
- PBB-EVPN PEによってローカル接続回路（AC）で学習されたC-MACアドレスは、データプレーンで学習されます。 PBB-EVPN PEの場合、これらのC-MACアドレスはPBB-EVPN PEのIコンポーネントで学習され、[RFC7623]に従ってコントロールプレーンでアドバタイズされません。
- The B-MAC addresses learned in the control plane via the BGP EVPN routes sent by remote PBB-EVPN PEs are injected into the corresponding MAC-VRF table.
- リモートPBB-EVPN PEから送信されたBGP EVPNルートを介してコントロールプレーンで学習されたB-MACアドレスは、対応するMAC-VRFテーブルに挿入されます。
In case of a link failure in a single-active Ethernet segment, the PBB-EVPN PEs MUST perform both of the following tasks:
シングルアクティブイーサネットセグメントでリンク障害が発生した場合、PBB-EVPN PEは次の両方のタスクを実行する必要があります。
1. send a BGP B-MAC withdraw message to the PBB-EVPN peers *or* MAC advertisement with the MAC Mobility extended community
1. BGP B-MAC withdrawメッセージをPBB-EVPNピアに送信する*または* MACモビリティ拡張コミュニティのあるMACアドバタイズメント
2. follow existing VPLS MAC Flush procedures with the PBB-VPLS peers
2. PBB-VPLSピアで既存のVPLS MACフラッシュ手順に従います
In PBB-EVPN, a given B-MAC address can be learned either over the BGP control plane from a remote PBB-EVPN PE or in the data plane over a PW from a remote PBB-VPLS PE. There is no mobility associated with B-MAC addresses in this context. Hence, when the same B-MAC address shows up behind both a remote PBB-VPLS PE as well as a PBB-EVPN PE, the local PE can deduce that it is an anomaly and SHOULD notify the operator.
PBB-EVPNでは、特定のB-MACアドレスは、リモートPBB-EVPN PEからBGPコントロールプレーンを介して、またはリモートPBB-VPLS PEからPWを介してデータプレーンで学習できます。このコンテキストでは、B-MACアドレスに関連付けられたモビリティはありません。したがって、同じB-MACアドレスがリモートPBB-VPLS PEとPBB-EVPN PEの両方の背後にある場合、ローカルPEはそれが異常であると推定し、オペレーターに通知する必要があります（SHOULD）。
The procedures for multicast operation on the PBB-VPLS PE using ingress replication are per [RFC7041] and [RFC7080].
入力レプリケーションを使用するPBB-VPLS PEでのマルチキャスト操作の手順は、[RFC7041]および[RFC7080]に準拠しています。
The procedures for multicast operation on the PBB-EVPN PE for ingress replication are as follows:
入力レプリケーション用のPBB-EVPN PEでのマルチキャスト操作の手順は次のとおりです。
- The PBB-EVPN PE builds a replication sub-list per I-SID to all the remote PBB-EVPN PEs in a given VPN instance as a result of the exchange of the EVPN IMET routes, as described in [RFC7623]. This will be referred to as sub-list A. It comprises MP2P service tunnels used for delivering PBB-EVPN BUM traffic.
- [RFC7623]で説明されているように、PVPN-EVPN PEは、EVPN IMETルートの交換の結果として、特定のVPNインスタンス内のすべてのリモートPBB-EVPN PEへのI-SIDごとの複製サブリストを作成します。これはサブリストAと呼ばれます。これは、PBB-EVPN BUMトラフィックの配信に使用されるMP2Pサービストンネルで構成されます。
- The PBB-EVPN PE builds a replication sub-list per VPN instance to all the remote PBB-VPLS PEs. This will be referred to as sub-list B. It comprises PWs from the PBB-EVPN PE in question to all the remote PBB-VPLS PEs in the same VPN instance.
- PBB-EVPN PEは、VPNインスタンスごとにすべてのリモートPBB-VPLS PEへの複製サブリストを作成します。これはサブリストBと呼ばれます。これは、問題のPBB-EVPN PEから、同じVPNインスタンス内のすべてのリモートPBB-VPLS PEへのPWで構成されます。
- The PBB-EVPN PE may further prune sub-list B on a per-I-SID basis by running MMRP (see Clause 10 of [IEEE.802.1Q]) over the PBB-VPLS network. This will be referred to as sub-list C. This list comprises a pruned set of the PWs in sub-list B.
- PBB-EVPN PEは、PBB-VPLSネットワーク上でMMRP（[IEEE.802.1Q]の条項10を参照）を実行することにより、サブリストBをI-SIDごとにさらにプルーニングできます。これはサブリストCと呼ばれます。このリストは、サブリストBのPWのプルーニングされたセットで構成されます。
The replication list maintained per I-SID on a given PBB-EVPN PE will be the union of sub-list A and sub-list B if MMRP is not used and the union of sub-list A and sub-list C if MMRP is used. Note that the PE MUST enable split horizon over all the entries in the replication list, across both pseudowires and MP2P service tunnels.
特定のPBB-EVPN PEのI-SIDごとに維持されるレプリケーションリストは、MMRPが使用されていない場合はサブリストAとサブリストBの結合、MMRPが使用されている場合はサブリストAとサブリストCの結合になります。中古。 PEは、疑似配線とMP2Pサービストンネルの両方で、レプリケーションリストのすべてのエントリに対してスプリットホライズンを有効にする必要があることに注意してください。
The procedures for multicast operation on the PBB-EVPN PEs using P2MP tunnels are outside of the scope of this document.
P2MPトンネルを使用したPBB-EVPN PEでのマルチキャスト操作の手順は、このドキュメントの範囲外です。
All the security considerations in [RFC4761], [RFC4762], [RFC7080], [RFC7432], and [RFC7623] apply directly to this document because it leverages the control-plane and data-plane procedures described in those RFCs.
[RFC4761]、[RFC4762]、[RFC7080]、[RFC7432]、および[RFC7623]のセキュリティに関するすべての考慮事項は、これらのRFCで説明されているコントロールプレーンおよびデータプレーンの手順を利用するため、このドキュメントに直接適用されます。
This document does not introduce any new security considerations beyond those of the above RFCs because the advertisements and processing of MAC addresses in BGP follow [RFC7432], and the processing of MAC addresses learned over PWs follows [RFC4761], [RFC4762], and [RFC7080].
BGPでのMACアドレスのアドバタイズと処理は[RFC7432]に従い、PWで学習されたMACアドレスの処理は[RFC4761]、[RFC4762]、[ RFC7080]。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、Ed。およびY. Rekhter編、「自動検出とシグナリングにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<https://www.rfc-editor.org/ info / rfc4761>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762]ラッセール、M。、エド。およびV. Kompella編、「Label Distribution Protocol（LDP）Signalingを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<https://www.rfc-editor.org/ info / rfc4762>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、DOI 10.17487 / RFC6074 、2011年1月、<https://www.rfc-editor.org/info/rfc6074>。
[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 10.17487/RFC7041, November 2013, <https://www.rfc-editor.org/info/rfc7041>.
[RFC7041] Balus、F.、Ed。、Sajassi、A.、Ed。、and N. Bitar、Ed。、 "Extensions to the Virtual Private LAN Service（VPLS）Provider Edge（PE）Model for Provider Backbone Bridging"、 RFC 7041、DOI 10.17487 / RFC7041、2013年11月、<https://www.rfc-editor.org/info/rfc7041>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、and W. Henderickx、 "BGP MPLS-Based Ethernet VPN"、 RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https://www.rfc-editor.org/info/rfc7432>。
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC7623] Sajassi、A。、編、Salam、S.、Bitar、N.、Isaac、A。、およびW. Henderickx、「Provider Backbone Bridging Combined with Ethernet VPN（PBB-EVPN）」、RFC 7623、DOI 10.17487 / RFC7623、2015年9月、<https://www.rfc-editor.org/info/rfc7623>。
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.
[RFC8077]マティーニ、L。、エド。 and G. Heron、Ed。、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、STD 84、RFC 8077、DOI 10.17487 / RFC8077、February 2017、<https://www.rfc-editor.org/ info / rfc8077>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[IEEE.802.1Q] IEEE, "IEEE Standard for Local and Metropolitan Area Network -- Bridges and Bridged Networks", IEEE Standard 802.1Q, DOI 10.1109/IEEESTD.2018.8403927, July 2018.
[IEEE.802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Bridges and Bridged Networks」、IEEE Standard 802.1Q、DOI 10.1109 / IEEESTD.2018.8403927、2018年7月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC4684] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、「ボーダーゲートウェイプロトコル/マルチプロトコルラベルスイッチングの制約付きルート配信（BGP / MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPN）」、RFC 4684、DOI 10.17487 / RFC4684、2006年11月、<https://www.rfc-editor.org/info/rfc4684>。
[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, <https://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月、< https://www.rfc-editor.org/info/rfc7080>。
Authors' Addresses
著者のアドレス
Ali Sajassi (editor) Cisco
Ali Sajassi（編集者）Cisco
Email: sajassi@cisco.com
Samer Salam Cisco
Samer Salem Cisco
Email: ssalam@cisco.com
Nick Del Regno Verizon
ベライゾン王国のニック
Email: nick.delregno@verizon.com
Jorge Rabadan Nokia
じょｒげ らばだん のきあ
Email: jorge.rabadan@nokia.com