Internet Engineering Task Force (IETF) A. Sajassi
Request for Comments: 9784 P. Brissette
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Schell
J. Drake
Independent
J. Rabadan
Nokia
June 2025
Ethernet VPN (EVPN) and Provider Backbone Bridge EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced multihoming capabilities. Specifically, they support Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multihomed device or network to a set of Provider Edge (PE) devices. This document extends the concept of an ES by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs), such as VLANs, or other entities, including MPLS Label Switched Paths (LSPs) or pseudowires (PWs). This extended concept is referred to as virtual Ethernet Segments (vESes). This document lists the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN.
イーサネットVPN（EVPN）およびプロバイダーバックボーンブリッジEVPN（PBB-EVPN）は、MPLS/IPネットワークを介してイーサネットサービスを提供するための包括的なソリューションスイートを導入します。これらのソリューションは、高度なマルチホーム機能を提供します。具体的には、マルチホームデバイスまたはネットワークをプロバイダーエッジ（PE）デバイスのセットに接続する物理リンクのコレクションとして定義されるイーサネットセグメント（ES）の単一活動的およびオールアクティブな冗長モードをサポートします。このドキュメントは、ESをVLANSなどのイーサネット仮想回路（EVC）のセットに関連付けることにより、ESの概念を拡張します。MPLSラベルスイッチ付きパス（LSP）またはプソイドワイヤ（PWS）を含む他のエンティティ。この拡張された概念は、仮想イーサネットセグメント（VESES）と呼ばれます。このドキュメントには、要件をリストし、EVPNとPBB-EVPNの両方のVEをサポートするために必要な拡張機能を指定します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9784.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9784で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
1.2. vESes in Access Ethernet Networks
1.3. vESes in Access MPLS Networks
2. Terminology
3. Requirements
3.1. Single-Homed and Multihomed vES
3.2. Local Switching
3.3. EVC Service Types
3.4. Designated Forwarder (DF) Election
3.5. EVC Monitoring
3.6. Failure and Recovery
3.7. Fast Convergence
4. Solution Overview
4.1. EVPN DF Election for vES
4.2. Grouping and Route Coloring for vES
4.2.1. EVPN Route Coloring for vES
4.2.2. PBB-EVPN Route Coloring for vES
5. Failure Handling and Recovery
5.1. EVC Failure Handling for Single-Active vES in EVPN
5.2. EVC Failure Handling for a Single-Active vES in PBB-EVPN
5.3. Port Failure Handling for Single-Active vESes in EVPN
5.4. Port Failure Handling for Single-Active vESes in PBB-EVPN
5.5. Fast Convergence in EVPN and PBB-EVPN
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
Ethernet VPN (EVPN) [RFC7432] and Provider Backbone Bridge EVPN (PBB-EVPN) [RFC7623] introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced multihoming capabilities. Specifically, they support Single-Active and All-Active redundancy modes for an Ethernet Segment (ES). As defined in [RFC7432], an ES represents a collection of Ethernet links that connect a customer site to one or more Provider Edge (PE) devices.
イーサネットVPN（EVPN）[RFC7432]およびプロバイダーバックボーンブリッジEVPN（PBB-EVPN）[RFC7623]は、MPLS/IPネットワークを介してイーサネットサービスを提供するための包括的なソリューションスイートを導入します。これらのソリューションは、高度なマルチホーム機能を提供します。具体的には、イーサネットセグメント（ES）に対して単一活性および全活性冗長モードをサポートしています。[RFC7432]で定義されているように、ESは、顧客サイトを1つ以上のプロバイダーエッジ（PE）デバイスに接続するイーサネットリンクのコレクションを表します。
This document extends the concept of an ES by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs) (such as VLANs) or other entities, including MPLS Label Switched Paths (LSPs) or pseudowires (PWs). This extended concept is referred to as virtual Ethernet Segments (vESes). This document lists the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN. The scope of this document includes PBB-EVPN [RFC7623], EVPN over MPLS [RFC7432], and EVPN over IP [RFC8365]; however, it excludes EVPN over SRv6 [RFC9252].
このドキュメントは、ESをイーサネット仮想回路（EVC）（VLANなど）またはMPLSラベルスイッチ付きパス（LSP）または擬似動物（PW）を含む他のエンティティに関連付けることを許可することにより、ESの概念を拡張します。この拡張された概念は、仮想イーサネットセグメント（VESES）と呼ばれます。このドキュメントには、要件をリストし、EVPNとPBB-EVPNの両方のVEをサポートするために必要な拡張機能を指定します。このドキュメントの範囲には、PBB-EVPN [RFC7623]、MPLS上のEVPN [RFC7432]、およびIPよりもEVPNが含まれます[RFC8365]。ただし、SRV6 [RFC9252]よりもEVPNを除外します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Some service providers (SPs) seek to extend the concept of physical Ethernet links in an ES to encompass EVCs, wherein multiple EVCs (such as VLANs) can be aggregated onto a single physical External Network-Network Interface (ENNI). An ES composed of a set of EVCs rather than physical links is referred to as a vES. Figure 1 illustrates two PE devices (PE1 and PE2), each with an ENNI aggregating several EVCs. Some of these EVCs on a given ENNI can be associated with vESes. For instance, the multihomed vES depicted in Figure 1 consists of EVC4 on ENNI1 and EVC5 on ENNI2.
一部のサービスプロバイダー（SPS）は、ESの物理イーサネットリンクの概念をEVCに拡張しようとします。これにより、複数のEVC（VLANなど）を単一の物理外部ネットワークネットワークインターフェイス（ENNI）に集約できます。物理リンクではなく、一連のEVCで構成されるESは、VEと呼ばれます。図1は、2つのPEデバイス（PE1とPE2）を示しています。特定のENNI上のこれらのEVCの一部は、ベースに関連付けられる可能性があります。たとえば、図1に示されている多目的VEは、ENNI1のEVC4とENNI2のEVC5で構成されています。
Third-Party
+-----+ EAP
| CE11|EVC1 +---------+
+-----+ \ | | +---+
Cust. A \-0=========0--ENNI1| |
+-----+ | | ENNI1| | +-------+ +---+
| CE12|EVC2--0=========0--ENNI1|PE1|---| | | |
+-----+ | | ENNI1| | |SP |---|PE3|-
| ==0--ENNI1| | |IP/MPLS| | | \ +---+
+-----+ | / | +---+ |Core | +---+ \-| |
| CE22|EVC3--0==== / | |Network| |CE4|
+-----+ | X | | | +---+ | |
Cust. B | / \ | +---+ | | | | /-| |
+-----+ -0=== ===0--ENNI2| | | |---|PE4|-/ +---+
| CE3 |EVC4/ | | ENNI2|PE2|---| | | |
| |EVC5--0=========0--ENNI2| | +-------+ +---+
+-----+ | | +---+
Cust. C +---------+ /\
/\ ||
|| ENNI
EVCs Interface
<--------802.1Q----------> <---- EVPN Network -----> <-802.1Q->
Figure 1: Single-Homed Devices and a Dual-Homed Device/Network on the Same ENNI
図1：同じenni上のシングルホームデバイスとデュアルホームデバイス/ネットワーク
ENNIs are commonly used to reach remote customer sites via independent Ethernet access networks or third-party Ethernet Access Providers (EAPs). ENNIs can aggregate traffic from many vESes (e.g., hundreds to thousands), where each vES is represented by its associated EVC on that ENNI. As a result, ENNIs and their associated EVCs are key elements of SP external boundaries that are carefully designed and closely monitored. As a reminder, the ENNI is the demarcation between the SP (IP/MPLS core network) and the third-party Ethernet Access Provider.
Ennisは、一般に、独立したイーサネットアクセスネットワークまたはサードパーティのイーサネットアクセスプロバイダー（EAPS）を介してリモートの顧客サイトに到達するために使用されます。Ennisは、トラフィックを多くのベース（たとえば、数百から数千）から集約することができます。各VEは、そのエニの関連するEVCで表されます。その結果、エニスとそれに関連するEVCは、慎重に設計され、綿密に監視されているSP外部境界の重要な要素です。リマインダーとして、ENNIはSP（IP/MPLSコアネットワーク）とサードパーティのイーサネットアクセスプロバイダーの間の境界です。
To meet customers' Service Level Agreements (SLAs), SPs build redundancy via multiple EVPN PEs and across multiple ENNIs (as shown in Figure 1), where a given vES can be multihomed to two or more EVPN PE devices (on two or more ENNIs) via their associated EVCs. Just like physical ESs in the solutions described in [RFC7432] and [RFC7623], these vESes can be single-homed or multihomed ESs, and when multihomed, they can operate in either Single-Active or All-Active redundancy modes. In a typical SP external-boundary scenario (e.g., with an EAP), an ENNI can be associated with several thousands of single-homed vESes, several hundreds of Single-Active vESes, and tens or hundreds of All-Active vESes. The specific figures used throughout this document reflect the relative quantities (hundreds, thousands, etc.) of various elements as understood at the time of writing.
顧客のサービスレベル契約（SLA）を満たすために、SPSは複数のEVPN PEを介して冗長性を構築し、複数のEnnis（図1に示すように）を構築します。ここでは、特定のVEが関連するEVCを介して2つ以上のEVPN PEデバイス（2つ以上のENNI）にマルチホームできます。[RFC7432]および[RFC7623]に記載されているソリューションの物理的なESSと同様に、これらのVESは単一貯留またはマルチホームのESSであり、マルチホームの場合、単一活動または全活性冗長モードで動作することができます。典型的なSP外部結合シナリオ（EAPなど）では、Enniは数千の単一給のves、数百の単一活動的なベース、および10または数百のすべてのすべての活性vesに関連付けることができます。このドキュメント全体で使用される特定の数字は、執筆時点で理解されているように、さまざまな要素の相対的な量（数百、数千など）を反映しています。
Other SPs want to extend the concept of physical links in an ES to individual PWs or to MPLS LSPs in Access MPLS networks, i.e., a vES consisting of a set of PWs or a set of LSPs. Figure 2 illustrates this concept.
他のSPは、ESの物理リンクの概念を個々のPWSまたはアクセスMPLSネットワークのMPLS LSP、つまりPWSのセットまたはLSPのセットで構成されるVEに拡張したいと考えています。図2は、この概念を示しています。
MPLS Aggregation
Network
+-----+ +-----------------+
| CE11|EVC1 | |
+-----+ \ +AG1-+ PW1 +-+---+
Cust. A -0----|===========| |
+-----+ | ---+===========| | +-------+ +---+
| CE12|EVC2-0/ | PW2 /\ | PE1 +---+ | | |
+-----+ ++---+ /=||=| | | +---+PE3+-
| //=||=| | |IP/MPLS| | | \ +---+
| // \/ +-+---+ |Core | +---+ \-+ |
+-----+EVC3 | PW3// LSP1 | |Network| |CE4|
| CE13| \+AG2-+==// | | | +---+ | |
+-----+ 0 |==/PW4 /\ +-+---+ | | | | /-+ |
0 |==PW5===||=| | | +---+PE4+-/ +---+
+-----+ /++---+==PW6===||=| PE2 +---+ | | |
| CE14|EVC4 | \/ | | +-------+ +---+
+-----+ | LSP2+-+---+
Cust. C +-----------------+
/\
||
EVCs
<--802.1Q--> <-----MPLS Agg----> <--- EVPN Network ---> <-802.1Q->
Figure 2: A Dual-Homed and Single-Homed Network on MPLS Aggregation Networks
図2：MPLS集約ネットワーク上のデュアルホームとシングルホームのネットワーク
In certain scenarios, SPs utilize MPLS Aggregation Networks that are managed by separate administrative entities or third-party organizations to gain access to their own IP/MPLS core network infrastructure. This situation is depicted in Figure 2.
特定のシナリオでは、SPSは、独自のIP/MPLSコアネットワークインフラストラクチャにアクセスするために、個別の管理エンティティまたはサードパーティ組織によって管理されるMPLS集約ネットワークを利用しています。この状況を図2に示します。
In such scenarios, a vES is defined as a set of individual PWs when aggregation is not feasible. If aggregation is possible, the vES can be associated with a group of PWs that share the same unidirectional LSP pair, where the LSP pair consists of the ingress and egress LSPs between the same endpoints.
このようなシナリオでは、集約が実行不可能な場合、VESは個々のPWSのセットとして定義されます。凝集が可能な場合、VEは同じ単方向LSPペアを共有するPWSのグループに関連付けられます。ここで、LSPペアは同じエンドポイント間の侵入と出口LSPで構成されます。
In Figure 2, EVC3 is connected to a VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and PW5, respectively. EVC4 is connected to another VPWS instance on AG2 that is connected to PE1 and PE2 via PW4 and PW6, respectively. Since the PWs for the two VPWS instances can be aggregated into the same LSP pair going to and coming from the MPLS network, a common vES can be defined for the four mentioned PWs. In Figure 2, LSP1 and LSP2 represent the two LSP pairs between PE1 and AG2 and between PE2 and AG2, respectively. The vES consists of these two LSP pairs (LSP1 and LSP2), and each LSP pair has two PWs. This vES will be shared by two separate EVPN instances (e.g., EVI-1 and EVI-2) in the EVPN network. PW3 and PW4 are associated with EVI-1 and EVI-2, respectively, on PE1, and PW5 and PW6 are associated with EVI-1 and EVI-2, respectively, on PE2.
図2では、EVC3は、それぞれPW3とPW5を介してPE1とPE2に接続されているAg2のVPWSインスタンスに接続されています。EVC4は、それぞれPW4とPW6を介してPE1とPE2に接続されているAG2の別のVPWSインスタンスに接続されています。2つのVPWSインスタンスのPWSは、MPLSネットワークに登場する同じLSPペアに集約できるため、言及された4つのPWSに対して共通のVEを定義できます。図2では、LSP1とLSP2は、それぞれPE1とAg2とPE2とAg2の間の2つのLSPペアを表しています。VESは、これら2つのLSPペア（LSP1およびLSP2）で構成され、各LSPペアには2つのPWがあります。このVEは、EVPNネットワーク内の2つの個別のEVPNインスタンス（EVI-1およびEVI-2など）によって共有されます。PW3およびPW4は、それぞれPE1およびPW5およびPW6でEVI-1およびEVI-2に関連しています。EVI-1およびEVI-2にそれぞれPE2で関連しています。
In some cases, the aggregation of PWs that share the same LSP pair may not be possible. For instance, if PW3 were terminated into a third PE, e.g., PE3, instead of PE1, the vES would need to be defined on each PW on each PE.
場合によっては、同じLSPペアを共有するPWSの集約は不可能かもしれません。たとえば、PW3が3番目のPE、たとえばPE3の代わりにPE3に終了した場合、各PEの各PWでVESを定義する必要があります。
For MPLS/IP access networks where a vES represents a set of LSP pairs or a set of PWs, this document extends the Single-Active multihoming procedures defined in [RFC7432] and [RFC7623] to accommodate vES. The extension of vES to support All-Active multihoming in MPLS/IP access networks is beyond the scope of this document.
VESがLSPペアのセットまたはPWSのセットを表すMPLS/IPアクセスネットワークの場合、このドキュメントは[RFC7432]および[RFC7623]で定義された単一活性マルチホーム手順を拡張してVESに対応します。MPLS/IPアクセスネットワークですべての活性マルチホームをサポートするVESの拡張は、このドキュメントの範囲を超えています。
This document defines the concept of a vES and specifies the additional extensions necessary to support a vES in accordance with [RFC7432] and [RFC7623]. Section 3 enumerates the set of requirements for a vES. Section 4 details the extensions for a vES applicable to EVPN solutions, including those specified in [RFC7432] and [RFC7209]. These extensions are designed to meet the requirements listed in Section 3. Section 4 also provides an overview of the solution, while Section 5 addresses failure handling, recovery, scalability, and fast convergence of [RFC7432] and [RFC7623] for vESes.
このドキュメントは、[RFC7432]および[RFC7623]に従ってVESをサポートするために必要な追加の拡張機能を指定し、指定します。セクション3では、VESの要件のセットを列挙しています。セクション4では、[RFC7432]および[RFC7209]で指定されているものを含むEVPNソリューションに適用されるVEの拡張機能の詳細について説明します。これらの拡張機能は、セクション3にリストされている要件を満たすように設計されています。セクション4では、ソリューションの概要も提供し、セクション5では、VESEの[RFC7432]および[RFC7623]の故障処理、回復、スケーラビリティ、および高速収束に対処します。
AC:
AC：
Attachment Circuit
アタッチメント回路
B-MAC:
b-mac：
Backbone MAC Address
バックボーンMACアドレス
CE:
CE：
Customer Edge
顧客のエッジ
C-MAC:
c-mac：
Customer/Client MAC Address
顧客/クライアントMacアドレス
DF:
DF：
Designated Forwarder
指定されたフォワーダー
ENNI:
エニ：
External Network-Network Interface
外部ネットワークネットワークインターフェイス
ES:
ES：
Ethernet Segment
イーサネットセグメント
ESI:
ESI：
Ethernet Segment Identifier
イーサネットセグメント識別子
Ethernet A-D:
イーサネットA-D：
Ethernet Auto-Discovery
イーサネットの自動ディスコーブリー
EVC:
EVC：
Ethernet Virtual Circuit [MEF63]
イーサネット仮想回路[MEF63]
EVI:
Evi：
EVPN Instance
EVPNインスタンス
EVPN:
EVPN：
Ethernet VPN
イーサネットvpn
I-SID:
i-sid：
Service Instance Identifier (24 bits and global within a PBB network; see [RFC7080]).
サービスインスタンス識別子（PBBネットワーク内の24ビットとグローバル。[RFC7080]を参照）。
MAC:
マック：
Media Access Control
メディアアクセス制御
PBB:
PBB：
Provider Backbone Bridge
プロバイダーバックボーンブリッジ
PBB-EVPN:
PBB-EVPN：
Provider Backbone Bridge EVPN
プロバイダーバックボーンブリッジEVPN
PE:
PE：
Provider Edge
プロバイダーエッジ
VPWS:
VPWS：
Virtual Private Wire Service
仮想プライベートワイヤーサービス
Single-Active (SA) Redundancy Mode:
シングルアクティブ（SA）冗長モード：
When only a single PE, among a group of PEs attached to an ES, is allowed to forward traffic to/from that ES, the ES is defined as operating in Single-Active redundancy mode.
ESに接続されたPEのグループの間で、単一のPEのみがそのESに出入りするトラフィックを許可されている場合、ESは単一活性冗長モードで動作するものとして定義されます。
All-Active (AA) Redundancy Mode:
オールアクティブ（AA）冗長モード：
When all PEs attached to an ES are allowed to forward traffic to/from that ES, the ES is defined as operating in All-Active redundancy mode.
ESに接続されているすべてのPEがそのESに出入りするトラフィックが許可されている場合、ESはすべての活性冗長モードで動作するものとして定義されます。
This section describes the requirements specific to vES for EVPN and PBB-EVPN solutions. These requirements are in addition to the ones described in [RFC8214], [RFC7432], and [RFC7623].
このセクションでは、EVPNおよびPBB-EVPNソリューションのVESに固有の要件について説明します。これらの要件は、[RFC8214]、[RFC7432]、および[RFC7623]に記載されている要件に追加されます。
A PE device MUST support the following types of vESes:
PEデバイスは、次の種類のvesをサポートする必要があります。
(R1a) The PE MUST handle single-homed vESes on a single physical port, such as a single ENNI.
（R1A）PEは、単一のEnniなどの単一の物理ポートで単一給施設のベースを処理する必要があります。
(R1b) The PE MUST support a combination of single-homed vESes and Single-Active multihomed vESes simultaneously on a single physical port, such as a single ENNI. Throughout this document, Single-Active multihomed vESes will be referred to as "Single-Active vESes".
（R1B）PEは、単一のEnniなどの単一の物理ポートで、単一給のvesesと単一活動的なマルチホームベースの組み合わせを同時にサポートする必要があります。このドキュメント全体で、単一活動的なマルチホームのvesesは「単一活性ves」と呼ばれます。
(R1c) The PE MAY support All-Active multihomed vESes on a single physical port. Throughout this document, All-Active multihomed vESes will be referred to as "All-Active vESes".
（R1C）PEは、単一の物理ポート上のオールアクティブなマルチホームベースをサポートする場合があります。このドキュメント全体を通して、すべて活性の多いマルチホームのvesesは「オールアクティブなベース」と呼ばれます。
(R1d) The PE MAY support a combination of All-Active vESes along with other types of vESes on a single physical port.
（R1D）PEは、単一の物理ポート上の他のタイプのvesとともに、すべての活性vesの組み合わせをサポートする場合があります。
(R1e) A multihomed vES, whether Single-Active or All-Active, can span across two or more ENNIs on any two or more PEs.
（R1E）単一活性であろうとオールアクティブであろうと、マルチホームのvesは、2つ以上のPEで2つ以上のエニスにまたがることがあります。
Many vESes of different types can be aggregated on a single physical port on a PE device and some of these vESes can belong to the same service instance (e.g., EVI). This translates into the need for supporting local switching among the vESes for the same service instance on the same physical port (e.g., ENNI) of the PE.
さまざまなタイプの多くのベースは、PEデバイス上の単一の物理ポートに集約でき、これらのベースの一部は同じサービスインスタンス（EVIなど）に属することができます。これは、PEの同じ物理ポート（ENNIなど）の同じサービスインスタンスのベース間のローカルスイッチングをサポートする必要性に変換されます。
(R2a) A PE device that supports the vES function MUST support local switching among different vESes associated with the same service instance on a single physical port. For instance, in Figure 1, PE1 must support local switching between CE11 and CE12, which are mapped to two single-homed vESes on ENNI1. In the case of Single-Active vESes, the local switching is performed among active EVCs associated with the same service instance on the same ENNI.
（R2A）VES関数をサポートするPEデバイスは、単一の物理ポート上の同じサービスインスタンスに関連する異なるVESEのローカルスイッチングをサポートする必要があります。たとえば、図1では、PE1はCE11とCE12の間のローカルスイッチングをサポートする必要があります。CE12は、ENNI1の2つの単一給のVESEにマッピングされます。単一活性科学の場合、同じENNI上の同じサービスインスタンスに関連付けられたアクティブなEVC間でローカルスイッチングが実行されます。
A physical port, such as an ENNI of a PE device, can aggregate numerous EVCs, each associated with a vES. An EVC may carry one or more VLANs. Typically, an EVC carries a single VLAN and is therefore associated with a single broadcast domain. However, there are no restrictions preventing an EVC from carrying multiple VLANs.
PEデバイスのエンニなどの物理ポートは、それぞれがVESに関連付けられている多数のEVCを集約できます。EVCは、1つ以上のVLANを運ぶ場合があります。通常、EVCは単一のVLANを運ぶため、単一のブロードキャストドメインに関連付けられています。ただし、EVCが複数のVLANを運ぶことを妨げる制限はありません。
(R3a) An EVC can be associated with a single broadcast domain, such as in a VLAN-based service or a VLAN bundle service.
（R3A）EVCは、VLANベースのサービスやVLANバンドルサービスなど、単一のブロードキャストドメインに関連付けることができます。
(R3b) An EVC MAY be associated with several broadcast domains, such as in a VLAN-aware bundle service.
（R3B）EVCは、VLAN認識バンドルサービスなど、いくつかのブロードキャストドメインに関連付けられている場合があります。
Similarly, a PE can aggregate multiple LSPs and PWs. In the case of individual PWs per vES, a PW is typically associated with a single broadcast domain, although there are no restrictions preventing a PW from carrying multiple VLANs if the PW is configured in Raw mode.
同様に、PEは複数のLSPとPWを集約できます。vesあたりの個々のPWの場合、PWは通常単一のブロードキャストドメインに関連付けられていますが、PWがRAWモードで構成されている場合、PWが複数のVLANを運ぶのを妨げる制限はありません。
(R3c) A PW can be associated with a single broadcast domain, such as in a VLAN-based service or a VLAN bundle service.
（R3C）PWは、VLANベースのサービスやVLANバンドルサービスなど、単一のブロードキャストドメインに関連付けることができます。
(R3d) A PW MAY be associated with several broadcast domains, such as in a VLAN-aware bundle service.
（R3D）PWは、VLANに認識されたバンドルサービスなど、いくつかのブロードキャストドメインに関連付けられている場合があります。
Section 8.5 of [RFC7432] specifies the default procedure for DF election in EVPN, which is also applied in [RFC7623] and [RFC8214]. [RFC8584] elaborates on additional procedures for DF election in EVPN. These DF election procedures are performed at the granularity of (ESI, Ethernet Tag). In the context of a vES, the same EVPN default procedure for DF election is applicable but at the granularity of (vESI, Ethernet Tag). In this context, the Ethernet Tag is represented by an I-SID in PBB-EVPN and by a VLAN ID (VID) in EVPN. As described in [RFC7432], this default procedure for DF election at the granularity of (vESI, Ethernet Tag) is also known as "service carving." The goal of service carving is to evenly distribute the DFs for different vESes among various PEs, thereby ensuring an even distribution of traffic across the PEs. The following requirements are applicable to the DF election of vESes for EVPN and PBB-EVPN.
[RFC7432]のセクション8.5は、[RFC7623]および[RFC8214]にも適用されているEVPNでのDF選挙のデフォルト手順を指定しています。[RFC8584] EVPNでのDF選挙の追加手順について詳しく説明します。これらのDF選挙手順は、（ESI、イーサネットタグ）の粒度で実行されます。VESのコンテキストでは、DF選挙の同じEVPNデフォルトの手順が適用されますが、（VESI、イーサネットタグ）の粒度に適用されます。これに関連して、イーサネットタグは、PBB-EVPNのI-SIDとEVPNのVLAN ID（VID）によって表されます。[RFC7432]で説明されているように、（VESI、イーサネットタグ）の粒度でのDF選挙のこのデフォルトの手順は、「サービスカービング」としても知られています。サービスの彫刻の目標は、さまざまなPESの間でさまざまなベースに対してDFSを均等に配布し、それによりPES全体のトラフィックの均等な分布を確保することです。以下の要件は、EVPNおよびPBB-EVPNのVESESのDF選挙に適用されます。
(R4a) A PE that supports vES function MUST support a vES with m EVCs among n ENNIs belonging to p PEs in any arbitrary order, where n >= p >= m >=2. For example, if there is a vES with 2 EVCs and there are 5 ENNIs on 5 PEs (PE1 through PE5), then vES can be dual-homed to PE2 and PE4, and the DF election must be performed between PE2 and PE4.
（R4a）VES関数をサポートするPEは、n> = p> = m> = 2で、あらゆる任意の順序で任意の順に属するn ennisの間でM evcを使用してvesをサポートする必要があります。たとえば、2つのEVCを持つVESがあり、5つのPE（PE1からPE5）に5つのエニスがある場合、VEはPE2とPE4にデュアルホームでき、DF選挙はPE2とPE4の間で実行する必要があります。
(R4b) Each vES MUST be identified by its own virtual ESI (vESI).
（R4B）各VEは、独自の仮想ESI（VESI）によって識別される必要があります。
To detect the failure of an individual EVC and subsequently perform DF election for its associated vES as a result of this failure, each EVC should be monitored independently.
個々のEVCの障害を検出し、その後、この障害の結果として関連するVEに対してDF選挙を実行するには、各EVCを個別に監視する必要があります。
(R5a) Each EVC SHOULD be independently monitored for its operational health.
（R5a）各EVCは、その運用の健康について独立して監視する必要があります。
(R5b) A failure in a single EVC, among many aggregated on a single physical port or ENNI, MUST trigger a DF election for its associated vES.
（R5b）単一のEVCでの失敗は、単一の物理的なポートまたはENNIに集約されている多くの人の中で、それに関連するVEのDF選挙をトリガーする必要があります。
(R6a) Failure and failure recovery of an EVC for a single-homed vES SHALL NOT impact any other EVCs within its service instance or any other service instances. In other words, for PBB-EVPN, it SHALL NOT trigger any MAC flushing within both its own I-SID and other I-SIDs.
（R6A）単一給施設のVEのEVCの障害および障害回収は、そのサービスインスタンスまたは他のサービスインスタンス内の他のEVCに影響を与えません。言い換えれば、PBB-EVPNの場合、独自のI-SIDと他のI-SIDの両方でフラッシュするMACをトリガーしてはなりません。
(R6b) In case of All-Active vES, failure and failure recovery of an EVC for that vES SHALL NOT impact any other EVCs within its service instance or any other service instances. In other words, for PBB-EVPN, it SHALL NOT trigger any MAC flushing within both its own I-SID and other I-SIDs.
（R6B）すべての活性vesの場合、そのVEのEVCの障害および障害回収は、そのサービスインスタンスまたは他のサービスインスタンス内の他のEVCに影響を与えません。言い換えれば、PBB-EVPNの場合、独自のI-SIDと他のI-SIDの両方でフラッシュするMACをトリガーしてはなりません。
(R6c) Failure and failure recovery of an EVC for a Single-Active vES SHALL impact only its own service instance. In other words, for PBB-EVPN, MAC flushing SHALL be limited to the associated I-SID only and SHALL NOT impact any other I-SIDs.
（R6C）単一活性vesのEVCの障害および障害回収は、独自のサービスインスタンスのみに影響を及ぼすものとします。言い換えれば、PBB-EVPNの場合、MACフラッシュは関連するI-SIDのみに限定され、他のI-SIDに影響を与えないものとします。
(R6d) Failure and failure recovery of an EVC for a Single-Active vES MUST only impact C-MACs associated with a multihomed device/ network for that service instance. In other words, MAC flushing MUST be limited to a single service instance (I-SID in the case of PBB-EVPN) and only C-MACs for a Single-Active multihomed device/network.
（R6D）単一活性vesのEVCの障害および障害回収は、そのサービスインスタンスのマルチホームデバイス/ネットワークに関連するC-Macsのみに影響を与える必要があります。言い換えれば、MACフラッシュは、単一のサービスインスタンス（PBB-EVPNの場合はI-SID）に制限され、単一活性マルチホームデバイス/ネットワークのC-Macのみに制限する必要があります。
Since many EVCs (and their associated vESes) are aggregated via a single physical port (e.g., ENNI), when there is a failure of that physical port, it impacts many vESes and equally triggers many ES route withdrawals. Formulating, sending, receiving, and processing such large numbers of BGP messages can introduce delay in DF election and convergence time. As such, it is highly desirable to have a mass-withdraw mechanism similar to the one in [RFC7432] for withdrawing many Ethernet A-D per ES routes.
多くのEVC（および関連するves）は単一の物理的なポート（ENNIなど）を介して集約されているため、その物理的なポートの障害が発生すると、多くのベースに影響を与え、多くのESルート引き出しを等しく引き起こします。このような多数のBGPメッセージを策定、送信、受信、および処理すると、DFの選挙と収束時間に遅延が発生する可能性があります。そのため、ESルートあたりの多くのイーサネットA-Dを引き出すために、[RFC7432]のマスウォートメカニズムと同様の質量波メカニズムを持つことが非常に望ましいです。
(R7a) There SHOULD be a mechanism equivalent to EVPN mass withdraw such that upon an ENNI failure, only a single BGP message to the PEs is needed to trigger DF election for all impacted vESes associated with that ENNI.
（R7A）EVPNの大量撤退に相当するメカニズムがあるはずで、ENNIの障害時に、そのENNIに関連するすべての影響を受けたVESEのDF選挙をトリガーするためにPESへの単一のBGPメッセージのみが必要です。
The solutions described in [RFC7432] and [RFC7623] are leveraged as is, with the modification that the ESI assignment is performed for an EVC or a group of EVCs or LSPs/PWs instead of a link or a group of physical links. In other words, the ESI is associated with a vES (hereby referred to as the "vESI").
[RFC7432]および[RFC7623]で説明されているソリューションは、ESI割り当てがEVCまたはEVCまたはLSPS/PWSのグループに対して実行されるか、リンクまたは物理リンクのグループで実行されるという修正とともに活用されています。言い換えれば、ESIはVESに関連付けられています（これは「VESI」と呼ばれます）。
In the EVPN solution, the overall procedures remain consistent, with the primary difference being the handling of physical port failures that can affect multiple vESes. Sections 5.1 and 5.3 describe the procedures for managing physical port or link failures in the context of EVPN. In a typical multihomed setup, MAC addresses learned behind a vES are advertised using the ESI associated with the vES (i.e., the vESI). EVPN aliasing and mass-withdraw operations are conducted with respect to the vES identifier. Specifically, the Ethernet A-D routes for these operations are advertised using the vESI instead of the ESI.
EVPNソリューションでは、全体的な手順が一貫しており、主な違いは、複数のベースに影響を与える可能性のある物理ポート障害の取り扱いです。セクション5.1および5.3は、EVPNのコンテキストで物理ポートまたはリンク障害を管理する手順について説明します。典型的なマルチホームのセットアップでは、VESの背後で学習したMACアドレスは、VES（つまり、VESI）に関連付けられたESIを使用して宣伝されています。VES識別子に関して、EVPNエイリアシングおよび質量波操作が実施されます。具体的には、これらの操作のイーサネットA-Dルートは、ESIの代わりにVESIを使用して宣伝されます。
For the PBB-EVPN solution, the main change is with respect to the B-MAC address assignment, which is performed in a similar way to what is described in Section 6.2.1.1 of [RFC7623], with the following refinements:
PBB-EVPNソリューションの場合、主な変更はB-MACアドレス割り当てに関するものであり、これは[RFC7623]のセクション6.2.1.1で説明されているものと同様の方法で実行され、次の改良があります。
* One shared B-MAC address SHOULD be used per PE for the single-homed vESes. In other words, a single B-MAC is shared for all single-homed vESes on that PE.
* 1つの共有B-MACアドレスをPEごとに使用する必要があります。言い換えれば、そのPE上のすべてのシングルホームのベースに対して単一のB-MACが共有されます。
* One shared B-MAC address SHOULD be used per PE, per physical port (e.g., ENNI) for the Single-Active vESes. In other words, a single B-MAC is shared for all Single-Active vESes that share the same ENNI.
* 1つの共有B-MACアドレスは、単一活性vESの物理ポート（ENNIなど）ごとに使用する必要があります。言い換えれば、同じEnniを共有するすべての単一活性科学科vesと単一のB-MACが共有されます。
* One shared B-MAC address MAY be used for all Single-Active vESes on that PE.
* 1つの共有B-MACアドレスは、そのPE上のすべての単一活性ベースに使用できます。
* One B-MAC address SHOULD be used per set of EVCs representing an All-Active vES. In other words, a single B-MAC address is used per vES for All-Active scenarios.
* 1つのB-MACアドレスは、すべて活性vesを表すEVCのセットごとに使用する必要があります。言い換えれば、すべての活性シナリオでは、VESごとに単一のB-MACアドレスが使用されます。
* A single B-MAC address MAY also be used per vES, per PE for Single-Active scenarios.
* 単一のB-MACアドレスは、単一活性シナリオのPEごとに、単一のB-MACアドレスを使用できます。
The service carving procedures for vESes are almost the same as the procedures outlined in Section 8.5 of [RFC7432] and in [RFC8584], except that ES is replaced with vES.
VESEのサービス彫刻手順は、ESがVESに置き換えられていることを除いて、[RFC7432]および[RFC8584]のセクション8.5および[RFC8584]で概説されている手順とほぼ同じです。
For the sake of clarity and completeness, the default DF election procedure of [RFC7432] is repeated below with the necessary changes:
明確さと完全性のために、[RFC7432]のデフォルトのDF選挙手続きを以下で繰り返します。
1. When a PE discovers the vESI or is configured with the vESI associated with its attached vES, it advertises an ES route with the associated ES-Import Route Target extended community attribute.
1. PEがVESIを発見するか、付着したVESに関連付けられたVESIで構成されている場合、関連するES-IMPORTルートターゲット拡張コミュニティ属性を持つESルートを宣伝します。
2. The PE then starts a timer (default value = 3 seconds) to allow the reception of ES routes from other PE nodes connected to the same vES. This timer value MUST be the same across all PEs connected to the same vES.
2. その後、PEはタイマー（デフォルト値= 3秒）を開始して、同じVESに接続された他のPEノードからESルートの受信を許可します。このタイマー値は、同じVEに接続されたすべてのPEで同じでなければなりません。
3. When the timer expires, each PE builds an ordered list of the IP addresses of all the PE nodes connected to the vES (including itself), in increasing numeric value. Each IP address in this list is extracted from the "Originator Router's IP address" field of the advertised ES route. Every PE is then given an ordinal indicating its position in the ordered list, starting with 0 as the ordinal for the PE with the numerically lowest IP address. The ordinals are used to determine which PE node will be the DF for a given EVPN instance on the vES using the following rule: Assuming a redundancy group of N PE nodes, the PE with ordinal i is the DF for an EVPN instance with an associated Ethernet Tag value of V when (V mod N) = i. It should be noted that using the "Originator Router's IP address" field in the ES route to get the PE IP address needed for the ordered list allows a CE to be multihomed across different ASes, if such need ever arises.
3. タイマーの有効期限が切れると、各PEは、数値を増やすために、VES（それ自体を含む）に接続されたすべてのPEノードのIPアドレスの順序付きリストを作成します。このリストの各IPアドレスは、広告されたESルートの「Originator RouterのIPアドレス」フィールドから抽出されます。次に、すべてのPEに、順序付きリストの位置を示す順序が与えられ、数値的に最も低いIPアドレスを持つPEの順序として0から始まります。ordinalは、次のルールを使用して、VES上の特定のEVPNインスタンスのDFになるPEノードを決定するために使用されます。NPEノードの冗長グループを仮定すると、標準Iは、関連するイーサネットタグ値を持つEVPNインスタンスのDFです。ESルートで「Originator RouterのIPアドレス」フィールドを使用して、順序付けられたリストに必要なPE IPアドレスを取得すると、そのような必要が発生した場合、CEを異なるASESでマルチホームすることができることに注意してください。
4. The PE that is elected as a DF for a given EVPN instance will unblock traffic for that EVPN instance. Note that the DF PE unblocks all traffic in both ingress and egress directions for Single-Active vESes and unblocks multi-destination in the egress direction for All-Active multihomed vESes. All non-DF PEs block all traffic in both ingress and egress directions for Single-Active vESes and block multi-destination traffic in the egress direction for All-Active vESes.
4. 特定のEVPNインスタンスのDFとして選出されたPEは、そのEVPNインスタンスのトラフィックのブロックを解除します。DF PEは、すべてのトラフィックを、単一活性vesesの侵入方向と出口方向の両方でブロックし、すべて活性の多いマルチホームベースの出口方向に多留置を解除することに注意してください。すべての非DF PESは、単一活性vesesの侵入方向と出口方向の両方ですべてのトラフィックをブロックし、すべての活性veseの出口方向に多降りのトラフィックをブロックします。
In case of an EVC failure, the affected PE withdraws its corresponding ES route if there are no more EVCs associated to the vES in the PE. This will re-trigger the DF election procedure on all the PEs in the redundancy group. For PE node failure, or upon PE commissioning or decommissioning, the PEs re-trigger the DF election procedure across all affected vESes. In case of a Single-Active scenario, when a service moves from one PE in the redundancy group to another PE because of DF re-election, the PE (which ends up being the elected DF for the service) MUST trigger a MAC address flush notification towards the associated vES if the multihoming device is a bridge or the multihoming network is an Ethernet bridged network.
EVC障害の場合、影響を受けるPEは、PEのVESに関連するEVCがもうない場合、対応するESルートを撤回します。これにより、冗長グループのすべてのPESのDF選挙手続きが再トリガーされます。PEノードの障害の場合、またはPEの試運転または廃止措置時に、PESは、影響を受けるすべてのVESESにわたってDF選挙手続きを再トリガーします。単一活性シナリオの場合、DFの再選のためにサービスが冗長グループの1つのPEから別のPEに移動する場合、PE（最終的にはサービスの選出されたDFになります）は、マルチホームデバイスがブリッジであるか、マルチホームネットワークである場合、関連するVEに向けてMACアドレスフラッシュ通知をトリガーする必要があります。
For LSP-based and PW-based vES, the non-DF PE SHOULD signal PW-status 'standby' to the Aggregation PE (e.g., AG1 and AG2 in Figure 2), and a new DF PE MAY send a Label Distribution Protocol (LDP) MAC withdraw message as a MAC address flush notification. It should be noted that the PW-status is signaled for the scenarios where there is a one-to-one mapping between EVI (EVPN instance) and the PW.
LSPベースのVESおよびPWベースのVESの場合、非DF PEは、集約PE（図2のAG1およびAG2など）にPW-Statusの「スタンバイ」を信号を送信する必要があり、新しいDF PEは、MACアドレスフラッシュ通知としてラベル分布プロトコル（LDP）MACの引き出しメッセージを送信する場合があります。EVI（EVPNインスタンス）とPWの間に1対1のマッピングがあるシナリオには、PW-STATUSが合図されることに注意する必要があります。
Physical ports (e.g., ENNI) that aggregate many EVCs are 'colored' to enable the grouping schemes described below.
多くのEVCを集約する物理ポート（ENNIなど）は、以下に説明するグループスキームを可能にするために「色が付けられています」。
By default, the MAC address of the corresponding port (e.g., ENNI) is used to represent the 'color' of the port, and the EVPN Router's MAC Extended Community defined in [RFC9135] is used to signal this color.
デフォルトでは、対応するポート（ENNIなど）のMACアドレスを使用してポートの「色」を表すために使用され、[RFC9135]で定義されているEVPNルーターのMac拡張コミュニティを使用してこの色を通知します。
The difference between coloring mechanisms for EVPN and PBB-EVPN is that the extended community is advertised with the Ethernet A-D per ES route for EVPN, whereas the extended community is advertised with the B-MAC route for PBB-EVPN.
EVPNとPBB-EVPNの着色メカニズムの違いは、拡張コミュニティがEVPNのES ES-DごとのイーサネットA-Dで宣伝されているのに対し、拡張コミュニティはPBB-EVPNのB-MACルートで宣伝されていることです。
The subsequent sections detailing Grouping of Ethernet A-D per ES routes and Grouping of B-MAC addresses will be essential for addressing port failure handling, as discussed in Sections 5.3, 5.4, and 5.5.
セクション5.3、5.4、および5.5で説明するように、ESルートごとのイーサネットA-Dのグループ化とB-MACアドレスのグループ化の詳細なセクションは、ポート障害の取り扱いに対処するために不可欠です。
When a PE discovers the vESI or is configured with the vESI associated with its attached vES, an ES route and Ethernet A-D per ES route are generated using the vESI identifier.
PEがVESIを発見するか、付着したVESに関連付けられたVESIで構成されている場合、VESI識別子を使用してESルートとイーサネットA-Dが生成されます。
These ES and Ethernet A-D per ES routes specific to each vES are colored with an attribute representing their association to a physical port (e.g., ENNI).
これらのESおよびイーサネットA-Dごとに、各VEに固有のルートは、物理ポート（ENNIなど）に関連する属性で色付けされています。
The corresponding port 'color' is encoded in the EVPN Router's MAC Extended Community defined in [RFC9135] and advertised along with the ES and Ethernet A-D per ES routes for this vES. The color (which is the MAC address of the port) MUST be unique.
対応するポート「色」は、[RFC9135]で定義されたEVPNルーターのMac拡張コミュニティにエンコードされ、このVEのESルートごとにESおよびイーサネットA-Dとともに宣伝されています。色（ポートのMACアドレス）は一意でなければなりません。
The PE also constructs a special Grouping Ethernet A-D per ES route that represents all the vESes associated with the port (e.g., ENNI). The corresponding port 'color' is encoded in the ESI field. For this encoding, Type 3 ESI (Section 5 of [RFC7432]) is used with the MAC field set to the color (MAC address) of the port and the 3-octet local discriminator field set to 0xFFFFFF.
また、PEは、ポートに関連付けられたすべてのvesを表す特別なグループ化イーサネットA-D（ENNIなど）も構築します。対応するポート「色」は、ESIフィールドにエンコードされています。このエンコーディングでは、ポートの色（MACアドレス）に設定されたMACフィールドと、0xFFFFFFに設定された3オクテットのローカル識別子フィールドで、タイプ3 ESI（[RFC7432]のセクション5）が使用されます。
The ESI label extended community (Section 7.5 of [RFC7432]) is not relevant to Grouping Ethernet A-D per ES route. The label value is not used for encapsulating Broadcast, Unknown Unicast, and Multicast (BUM) packets for any split-horizon function. The ESI label extended community MUST NOT be added to Grouping Ethernet A-D per ES route and MUST be ignored on receiving the PE.
ESIラベル拡張コミュニティ（[RFC7432]のセクション7.5）は、ESルートごとのイーサネットA-Dのグループ化には関係ありません。ラベル値は、分割ホリゾン関数の放送、不明なユニキャスト、およびマルチキャスト（バム）パケットのカプセル化には使用されません。ESIラベル拡張コミュニティは、ESルートごとのイーサネットA-Dのグループ化に追加してはならず、PEを受信すると無視する必要があります。
The Grouping Ethernet A-D per ES route is advertised with a list of Route Targets corresponding to the affected service instances. If the number of associated Route Targets exceeds the capacity of a single route, multiple Grouping Ethernet A-D per ES routes are advertised accordingly as specified in Section 8.2 of [RFC7432].
グループ化イーサネットA-Dあたりのルートは、影響を受けるサービスインスタンスに対応するルートターゲットのリストで宣伝されます。関連するルートターゲットの数が単一のルートの容量を超える場合、[RFC7432]のセクション8.2で指定されているように、それに応じて複数のグループ化イーサネットA-Dがそれに応じて宣伝されます。
In PBB-EVPN, particularly when there are large numbers of service instances (i.e., I-SIDs) associated with each EVC, the PE device MAY assign a color attribute to each vES B-MAC route, indicating their association with a physical port (e.g., an ENNI).
PBB-EVPNでは、特に各EVCに関連付けられた多数のサービスインスタンス（つまり、I-SIDS）がある場合、PEデバイスは各VES B-MACルートに色属性を割り当て、物理ポート（ENNIなど）との関連を示すことができます。
The corresponding port 'color' is encoded in the EVPN Router's MAC Extended Community defined in [RFC9135] and advertised along with the B-MAC for this vES in PBB-EVPN.
対応するポート「色」は、[RFC9135]で定義されたEVPNルーターのMac拡張コミュニティにエンコードされ、PBB-EVPNでこのVEのB-MACとともに宣伝されています。
The PE MAY also construct a special Grouping B-MAC route that represents all the vESes associated with the port (e.g., ENNI). The corresponding port 'color' is encoded directly into this special Grouping B-MAC route.
PEは、ポートに関連付けられたすべてのVESを表す特別なグループ化B-MACルート（ENNIなど）を構築する場合があります。対応するポート「色」は、この特別なグループB-MACルートに直接エンコードされています。
There are several failure scenarios to consider such as:
次のように考慮すべきいくつかの失敗シナリオがあります。
A:
A:
CE uplink port failure
CEアップリンクポート障害
B:
B:
Ethernet Access Network failure
イーサネットアクセスネットワークの障害
C:
C:
PE access-facing port or link failure
PEアクセス向けポートまたはリンクの障害
D:
D:
PE node failure
PEノード障害
E:
E:
PE isolation from IP/MPLS network
IP/MPLSネットワークからのPE分離
The solutions specified in [RFC7432], [RFC7623], and [RFC8214] provide protection against failures as described in these respective references. In the context of these solutions, the presence of vESes introduces an additional failure scenario beyond those already considered, specifically the failure of individual EVCs. Addressing vES failure scenarios necessitates the independent monitoring of EVCs or PWs. Upon detection of failure or service restoration, appropriate DF election and failure recovery mechanisms must be executed.
[RFC7432]、[RFC7623]、および[RFC8214]で指定されたソリューションは、これらのそれぞれの参照で説明されているように、障害に対する保護を提供します。これらのソリューションのコンテキストでは、VESESの存在は、すでに考慮されているもの、特に個々のEVCの障害を超えて追加の障害シナリオを導入します。VES障害シナリオに対処するには、EVCまたはPWSの独立した監視が必要です。失敗またはサービスの復元を検出すると、適切なDF選挙と障害回収メカニズムを実行する必要があります。
[RFC7023] is used for monitoring EVCs, and upon failure detection of a given EVC, the DF election procedure per Section 4.1 is executed. For PBB-EVPN, some extensions are needed to handle the failure and recovery procedures of [RFC7623] to meet the above requirements. These extensions are described in the next section.
[RFC7023]はEVCの監視に使用され、特定のEVCの障害検出時に、セクション4.1あたりのDF選挙手続きが実行されます。PBB-EVPNの場合、上記の要件を満たすために[RFC7623]の障害および回復手順を処理するためにいくつかの拡張機能が必要です。これらの拡張機能については、次のセクションで説明します。
[RFC4377] and [RFC6310] are used for monitoring the status of LSPs and/or PWs associated to vES.
[RFC4377]および[RFC6310]は、VESに関連付けられたLSPおよび/またはPWSの状態を監視するために使用されます。
B D
|| ||
\/ \/
+-----+
+-----+ | | +---+
| CE1 |EVC2--0=====0--ENNI1| | +-------+
+-----+ | =0--ENNI1|PE1|---| | +---+ +---+
Cust. A | / | | | |IP/MPLS|--|PE3|--|CE4|
+-----+ | / | +---+ |Network| | | +---+
| |EVC2--0== | | | +---+
| CE2 | | | +---+ | |
| |EVC3--0=====0--ENNI2|PE2|---| |
+-----+ | | | | +-------+
+-----+ +---+
/\ /\ /\
|| || ||
A C E
Figure 3: Failure Scenarios A, B, C, D, and E
図3：障害シナリオA、B、C、D、およびE
In [RFC7432], when a DF PE connected to a Single-Active multihomed ES loses connectivity to the segment, due to link or port failure, it signals the remote PEs to invalidate all MAC addresses associated with that ES. This is done by means of a mass-withdraw message, by withdrawing the Ethernet A-D per ES route. It should be noted that for dual-homing use cases where there is only a single backup path, MAC invalidating can be avoided by the remote PEs as they can update their next hop associated with the affected MAC entries to the backup path per the procedure described in Section 8.2 of [RFC7432].
[RFC7432]では、DF PEが単一活動的なマルチホームESに接続されている場合、リンクまたはポートの障害によりセグメントへの接続を失うと、リモートPEを指示して、そのESに関連するすべてのMACアドレスを無効にします。これは、ESルートごとにイーサネットA-Dを撤回することにより、大量withdrawメッセージによって行われます。単一のバックアップパスのみがあるデュアルホーミングユースケースでは、[RFC7432]のセクション8.2で説明されている手順に従って、影響を受けるMACエントリに関連付けられた次のホップをバックアップパスに更新できるため、Macの無効化をリモートPESによって無効にすることができることに注意してください。
In case of an EVC failure that impacts a single vES, this same EVPN procedure is used. In this case, the mass withdraw is conveyed by withdrawing the Ethernet A-D per vES route carrying the vESI representing the failed EVC. Upon receiving this message, the remote PEs perform the same procedures outlined in Section 8.2 of [RFC7432].
単一のVESに影響を与えるEVC障害の場合、この同じEVPN手順が使用されます。この場合、大量撤退は、失敗したEVCを表すVESIを運ぶVESルートごとにイーサネットA-Dを引き出すことにより伝えられます。このメッセージを受信すると、リモートPEは[RFC7432]のセクション8.2で概説されている同じ手順を実行します。
In [RFC7432], when a PE connected to a Single-Active ES loses connectivity to the segment, due to link or port failure, it signals the remote PE to flush all C-MAC addresses associated with that ES. This is done by updating the advertised B-MAC route's MAC Mobility extended community.
[RFC7432]では、PEが単一活性ESに接続されている場合、リンクまたはポートの障害により、セグメントへの接続性が失われると、リモートPEを通知して、そのESに関連付けられたすべてのC-MACアドレスをフラッシュします。これは、広告されたB-MACルートのMac Mobility Extended Communityを更新することによって行われます。
In case of an EVC failure that impacts a single vES, if the above PBB-EVPN procedure is used, it results in excessive C-MAC flushing because a single physical port can support a large number of EVCs (and their associated vESes); therefore, updating the advertised B-MAC corresponding to the physical port, with MAC Mobility extended community, will result in flushing C-MAC addresses not just for the impacted EVC but for all other EVCs on that port.
単一のVESに影響を与えるEVC障害の場合、上記のPBB-EVPN手順を使用すると、単一の物理ポートが多数のEVC（および関連するVESE）をサポートできるため、過剰なC-MACフラッシュが生じます。したがって、MACモビリティが拡張されたコミュニティを使用して、物理ポートに対応する広告B-MACを更新すると、影響を受けたEVCだけでなく、そのポート上の他のすべてのEVCについてC-MACアドレスを洗い流します。
To reduce the scope of C-MAC flushing to only the impacted service instances (the service instance(s) impacted by the EVC failure), the PBB-EVPN C-MAC flushing needs to be adapted on a per-service-instance basis (i.e., per I-SID). [RFC9541] introduces a B-MAC/I-SID route where the existing PBB-EVPN B-MAC route is modified to carry an I-SID, instead of a NULL value, in the "Ethernet Tag ID" field. To the receiving PE, this field indicates flushing all C-MAC addresses associated with that I-SID for that B-MAC. This C-MAC flushing mechanism per I-SID SHOULD be used in case of an EVC failure impacting a vES. Since an EVC typically maps to a single broadcast domain and thus a single service instance, the affected PE only needs to advertise a single B-MAC/I-SID route. However, if the failed EVC carries multiple VLANs each with its own broadcast domain, then the affected PE needs to advertise multiple B-MAC/I-SID routes, i.e., one route for each VLAN (broadcast domain), meaning one route for each I-SID. Each B-MAC/I-SID route basically instructs the remote PEs to perform flushing for C-MACs corresponding to the advertised B-MAC only for the advertised I-SID.
C-MACフラッシングの範囲を影響を受けたサービスインスタンス（EVC障害の影響を受けるサービスインスタンス）のみに削減するには、PBB-EVPN C-MACフラッシングを1サービスごとに適応させる必要があります（つまり、I-SIDあたり）。[RFC9541]は、既存のPBB-EVPN B-MACルートが「イーサネットタグID」フィールドにヌル値の代わりにI-SIDを運ぶように変更されるB-MAC/I-SIDルートを導入します。受信PEに、このフィールドは、そのb-macのI-SIDに関連するすべてのC-MACアドレスをフラッシングすることを示しています。I-SIDあたりのこのC-MACフラッシングメカニズムは、VESに影響を与えるEVC障害の場合に使用する必要があります。EVCは通常、単一のブロードキャストドメインにマッピングされ、したがって単一のサービスインスタンスにマッピングするため、影響を受けるPEは単一のB-MAC/I-SIDルートを宣伝する必要があります。ただし、故障したEVCが独自のブロードキャストドメインを備えた複数のVLANを搭載している場合、影響を受けるPEは複数のB-MAC/I-SIDルートを宣伝する必要があります。各B-MAC/I-SIDルートは、基本的に、広告I-SIDのみの広告B-MACに対応するC-MACのフラッシングを実行するようリモートPEに指示します。
The C-MAC flushing based on a B-MAC/I-SID route works fine when there are only a few VLANs (e.g., I-SIDs) per EVC. However, if the number of I-SIDs associated with a failed EVC is large, then it is RECOMMENDED to assign a B-MAC per vES, and upon EVC failure, the affected PE simply withdraws this B-MAC message to other PEs.
B-MAC/I-SIDルートに基づいたC-MACフラッシングは、EVCごとに少数のVLAN（I-SID）しかない場合に正常に機能します。ただし、故障したEVCに関連付けられたI-SIDの数が大きい場合は、VESあたりのB-MACを割り当てることをお勧めします。EVC障害時に、影響を受けるPEはこのB-MACメッセージを他のPESに引き出します。
When many EVCs are aggregated via a single physical port on a PE, where each EVC corresponds to a vES, then the port failure impacts all the associated EVCs and their corresponding vESes. If the number of EVCs corresponding to the Single-Active vESes for that physical port is in the thousands, then thousands of service instances are impacted. Therefore, the propagation of failure in BGP needs to address all these impacted service instances. In order to achieve this, the following extensions are added to the baseline EVPN mechanism:
多くのEVCが、各EVCがVESに対応するPE上の単一の物理ポートを介して集約されると、ポート障害は関連するすべてのEVCとそれらの対応するVESに影響します。その物理的なポートの単一活性vesに対応するEVCの数が数千にある場合、数千のサービスインスタンスが影響を受けます。したがって、BGPの障害の伝播は、これらすべての影響を受けたサービスインスタンスに対処する必要があります。これを達成するために、以下の拡張機能がベースラインEVPNメカニズムに追加されます。
1. The PE MAY color each Ethernet A-D per ES route for a given vES, as described in Section 4.2.1. The PE SHOULD use the MAC physical port by default. The receiving PEs take note of this color and create a list of vESes for this color.
1. PEは、セクション4.2.1で説明されているように、特定のVESの各イーサネットA-Dルートを着色することができます。PEは、デフォルトでMacの物理ポートを使用する必要があります。受信PESはこの色に注意し、この色のVESEのリストを作成します。
2. The PE MAY advertise a special Grouping Ethernet A-D per ES route for that color, which represents all the vESes associated with the port.
2. PEは、ポートに関連するすべての詩を表す、その色の特別なグループ化イーサネットA-sルートあたりのルートを宣伝する場合があります。
3. Upon a port failure (e.g., an ENNI failure), the PE MAY send a mass-withdraw message by withdrawing the Grouping Ethernet A-D per ES route.
3. ポートの障害（Enni障害など）の場合、PEは、ESルートごとにグループ化イーサネットA-Dを撤回することにより、質量波のメッセージを送信する場合があります。
4. When this message is received, the remote PE MAY detect the special vES mass-withdraw message by identifying the Grouping Ethernet A-D per ES route. The remote PEs MAY then access the list of vESes created per item 1 for the specified color and locally initiate MAC address invalidating procedures for each of the vESes in the list.
4. このメッセージが受信されると、リモートPEは、esルートごとにグループ化イーサネットA-Dを識別することにより、特別なvesマスウィットドローメッセージを検出する場合があります。リモートPESは、指定された色に対してアイテム1ごとに作成されたVESEのリストにアクセスし、リスト内の各VESEのMACアドレスの無効な手順をローカルに開始することができます。
In scenarios where a logical ENNI is used, the above procedure equally applies. The logical ENNI is represented by a Grouping Ethernet A-D per ES route where the Type 3 ESI and the 6 bytes used in the ENNI's ESI MAC address field are used as a color for the vESes as described above and in Section 4.2.1.
論理的なenniが使用されるシナリオでは、上記の手順が等しく適用されます。論理ENNIは、ENNIのESI MACアドレスフィールドで使用されるタイプ3 ESIと6バイトが上記のように、およびセクション4.2.1でvESEの色として使用されるグループイーサネットA-Dあたりのルートで表されます。
When many EVCs are aggregated via a single physical port on a PE, where each EVC corresponds to a vES, then the port failure impacts all the associated EVCs and their corresponding vESes. If the number of EVCs corresponding to the Single-Active vESes for that physical port is in the thousands, then thousands of service instances (I-SIDs) are impacted. In such failure scenarios, the following two MAC flushing mechanisms per [RFC7623] can be performed.
多くのEVCが、各EVCがVESに対応するPE上の単一の物理ポートを介して集約されると、ポート障害は関連するすべてのEVCとそれらの対応するVESに影響します。その物理的なポートの単一活動的vesに対応するEVCの数が数千にある場合、数千のサービスインスタンス（I-SID）が影響を受けます。このような障害シナリオでは、[RFC7623]あたりの次の2つのMACフラッシングメカニズムを実行できます。
1. If the MAC address of the physical port is used for PBB encapsulation as B-MAC SA, then upon the port failure, the PE MUST use the EVPN MAC route withdrawal message to signal the flush.
1. 物理ポートのMACアドレスがB-MAC SAとしてPBBカプセル化に使用されている場合、ポート障害時にPEはEVPN MACルートの引き出しメッセージを使用してフラッシュを通知する必要があります。
2. If the PE's shared MAC address is used for PBB encapsulation as B-MAC SA, then upon the port failure, the PE MUST re-advertise this MAC route with the MAC Mobility extended community to signal the flush.
2. PEの共有MACアドレスがB-MAC SAとしてのPBBカプセル化に使用されている場合、ポート障害時にPEは、MACモビリティ拡張コミュニティでこのMacルートを再承認してフラッシュを通知する必要があります。
The first method is recommended because it reduces the scope of flushing the most.
最初の方法は、最もフラッシングの範囲を削減するため推奨されます。
As noted above, the advertisement of the extended community along with the B-MAC route for coloring purposes is optional and only recommended when there are many vESes per physical port and each vES is associated with a very large number of service instances (i.e., a large number of I-SIDs).
上記のように、着色目的のためのB-MACルートとともに拡張コミュニティの広告はオプションであり、物理的なポートごとに多くのベースがあり、各VEが非常に多数のサービスインスタンス（つまり、多数のI-SID）に関連付けられている場合にのみ推奨されます。
If there are large numbers of service instances (i.e., I-SIDs) associated with each EVC, and if there is a B-MAC assigned per vES as recommended in the above section, then in order to handle port failure efficiently, the following extensions are added to the baseline PBB-EVPN mechanism:
各EVCに関連付けられた多数のサービスインスタンス（I-SIDS）があり、上記のセクションで推奨されているVESごとに割り当てられたB-MACがある場合、ポート障害を効率的に処理するために、以下の拡張機能をベースラインPBB-EVPNメカニズムに追加します：：
1. Each vES MAY be colored with a MAC address representing the physical port like the coloring mechanism for EVPN. In other words, each B-MAC representing a vES is advertised with the 'color' of the physical port per Section 4.2.2. The receiving PEs take note of this color being advertised along with the B-MAC route, and for each such color, they create a list of vESes associated with this color.
1. 各VEは、EVPNの着色メカニズムのような物理ポートを表すMACアドレスで着色できます。言い換えれば、VESを表す各B-MACは、セクション4.2.2ごとに物理ポートの「色」で宣伝されます。受信PEは、この色がB-MACルートとともに宣伝されていることに注意し、そのような色ごとに、この色に関連付けられたvesesのリストを作成します。
2. The PE MAY advertise a special Grouping B-MAC route for that color (consisting of a port MAC address by default), which represents all the vESes associated with the port.
2. PEは、その色の特別なグループ化B-MACルート（デフォルトではポートMACアドレスで構成される）を宣伝する場合があります。これは、ポートに関連付けられているすべてのVESを表します。
3. Upon a port failure (e.g., ENNI failure), the PE MAY send a mass-withdraw message by withdrawing the Grouping B-MAC route.
3. ポートの障害（Enni障害など）で、PEは、グループ化B-MACルートを撤回することにより、質量波のメッセージを送信する場合があります。
4. When this message is received, the remote PE MAY detect the special vES mass-withdraw message by identifying the Grouping B-MAC route. The remote PEs MAY then access the list created in (1) above for the specified color and flush all C-MACs associated with the failed physical port.
4. このメッセージが受信されると、リモートPEは、グループB-MACルートを識別することにより、特別なVES Mass-WithDrawメッセージを検出する場合があります。リモートPEは、指定された色について上記の（1）で作成されたリストにアクセスし、失敗した物理ポートに関連付けられたすべてのC-MACをフラッシュする場合があります。
As described above, when many EVCs are aggregated via a physical port on a PE, and where each EVC corresponds to a vES, the port failure impacts all the associated EVCs and their corresponding vESes. Two actions must be taken as the result of such a port failure:
上記のように、多くのEVCがPEの物理ポートを介して集約され、各EVCがVESに対応する場合、ポート障害は関連するすべてのEVCとそれらの対応するVESに影響します。このようなポート障害の結果として、2つのアクションを実行する必要があります。
* For EVPN, initiate the mass-withdraw procedure for all vESes associated with the failed port to invalidate MACs and for PBB-EVPN to flush all C-MACs associated with the failed port across all vESes and the impacted I-SIDs
* EVPNの場合、失敗したポートに関連付けられたすべてのベースの質量波プロシージャを開始して、MACを無効にし、PBB-EVPNがすべてのベースと影響を受けたI-SIDで失敗したポートに関連付けられたすべてのC-MACをフラッシュする
* Use DF election for all impacted vESes associated with the failed port
* 失敗したポートに関連するすべての影響を受けたすべての影響を与えるためにDF選挙を使用する
Section 5.3 already describes how to perform a mass withdraw for all affected vESes and invalidate MACs using a single BGP withdrawal of the Grouping Ethernet A-D per ES route. Section 5.4 describes how to only flush C-MAC addresses associated with the failed physical port (e.g., optimum C-MAC flushing) as well as, optionally, the withdrawal of a Grouping B-MAC route.
セクション5.3では、すべての影響を受けるVESEに対して大量撤退を実行し、ESルートごとのグループ化イーサネットA-Dの単一のBGP撤退を使用してMACを無効にする方法について説明します。セクション5.4では、失敗した物理ポートに関連付けられたC-MACアドレスのみをフラッシュする方法（たとえば、最適なC-MACフラッシング）と、オプションでグループ化B-MACルートの撤回について説明します。
This section describes how to perform DF election in the most optimal way, e.g., by triggering DF election for all impacted vESes (which can be very large) among the participating PEs via a single BGP message as opposed to sending a large number of BGP messages (one per vES). This section assumes that the MAC flushing mechanism described in Section 5.4 and route coloring are used.
このセクションでは、DF選挙を最も最適な方法で実行する方法について説明します。たとえば、多数のBGPメッセージ（1つごとに1つ）を送信するのではなく、単一のBGPメッセージを介して、すべての影響を受けたVESE（非常に大きくなる可能性がある）のDF選挙をトリガーすることにより。このセクションでは、セクション5.4で説明したMACフラッシングメカニズムとルートの着色が使用されることを前提としています。
+-----+
+----+ | | +---+
| CE1|AC1--0=====0--ENNI1| | +-------+
| |AC2--0 | |PE1|--| |
+----+ |\ ==0--ENNI2| | | |
| \/ | +---+ | |
| /\ | |IP/MPLS|
+----+ |/ \ | +---+ |Network| +---+ +---+
| CE2|AC4--0 =0--ENNI3| | | |---|PE4|--|CE4|
| |AC4--0=====0--ENNI3|PE2|--| | +---+ +---+
+----+ | ====0--ENNI3| | | |
|/ | +---+ | |
0 | | |
+----+ /| | +---+ | |
| CE3|AC5- | | |PE3|--| |
| |AC6--0=====0--ENNI4| | +-------+
+----+ | | +---+
+-----+
Figure 4: Fast Convergence Upon ENNI Failure
図4：enni故障時の速い収束
As discussed in Section 4.2, it is highly desirable to have a mass-withdraw mechanism similar to the one in [RFC7432]. Although such an optimization is desirable, it is OPTIONAL. If the optimization is implemented, the following procedures are used:
セクション4.2で説明したように、[RFC7432]のメカニズムと同様の質量腫瘍メカニズムを持つことが非常に望ましいです。このような最適化は望ましいものですが、オプションです。最適化が実装されている場合、次の手順が使用されます。
1. When a vES is configured, the PE advertises the ES route for this vES with a color that corresponds to the associated physical port.
1. VESが構成されている場合、PEは、関連する物理ポートに対応する色で、このVEのESルートを宣伝します。
2. All receiving PEs within the redundancy group record this color and compile a list of vESes associated with it.
2. 冗長グループ内のすべての受信PEは、この色を記録し、それに関連するベースのリストをコンパイルします。
3. Additionally, the PE advertises a Grouping Ethernet A-D per ES route for EVPN, and a Grouping B-MAC route for PBB-EVPN, which corresponds to the color and vES grouping.
3. さらに、PEは、EVPNのグループのグループイーサネットA-Dあたりのルートと、色とVESのグループ化に対応するPBB-EVPNのグループB-MACルートを宣伝します。
4. In the event of a port failure, such as an ENNI failure, the PE withdraws the previously advertised Grouping Ethernet A-D per ES route or Grouping B-MAC route associated with the failed port. The PE should prioritize sending these Grouping route withdrawal messages over the withdrawal of individual vES routes affected by the failure. For instance, as depicted in Figure 4, when the physical port associated with ENNI3 fails on PE2, it withdraws the previously advertised Grouping Ethernet A-D per ES route. Upon receiving this withdrawal message, other multihoming PEs (such as PE1 and PE3) recognize that the vESes associated with CE1 and CE3 are impacted, based on the associated color, and thus initiate the DF election procedure for these vESes. Furthermore, upon receiving this withdrawal message, remote PEs (such as PE4) initiate the failover procedure for the vESes associated with CE1 and CE3 and switch to the other PE for each vES redundancy group.
4. ENNI障害などのポート障害が発生した場合、PEは、故障したポートに関連付けられた以前に宣伝されていたグループ化イーサネットA-Dまたは障害のあるポートに関連付けられたB-MACルートのグループ化を撤回します。PEは、障害の影響を受けた個々のVESルートの引き出しに対するこれらのグループ化ルートの引き出しメッセージの送信を優先する必要があります。たとえば、図4に示すように、ENNI3に関連付けられた物理ポートがPE2で失敗すると、以前に宣伝されていたグループ化イーサネットA-DがESルートごとに撤回します。この撤退メッセージを受信すると、他のマルチホミングPE（PE1やPE3など）は、CE1およびCE3に関連するVESが関連する色に基づいて影響を受けていることを認識しているため、これらのVESEのDF選挙手続きを開始します。さらに、この引き出しメッセージを受信すると、リモートPE（PE4など）は、CE1およびCE3に関連付けられたVESEのフェールオーバー手順を開始し、各VES冗長グループの他のPEに切り替えます。
5. On reception of Grouping Ethernet A-D per ES route or Grouping B-MAC route withdrawal, other PEs in the redundancy group initiate DF election procedures across all their affected vESes.
5. ESルートごとにイーサネットA-Dのグループ化またはB-MACルート引き出しのグループ化を受信すると、冗長グループの他のPESは、影響を受けるすべてのVESでDF選挙手続きを開始します。
6. The PE with the physical port failure (ENNI failure) sends a vES route withdrawal for every impacted vES. Upon receiving these messages, the other PEs clear up their BGP tables. It should be noted that the vES route withdrawal messages are not used for executing DF election procedures by the receiving PEs when Grouping Ethernet A-D per ES route or Grouping B-MAC route withdrawal has been previously received.
6. 物理的なポート障害（ENNI障害）のPEは、衝撃を受けたすべてのVEに対してVESルート引き出しを送信します。これらのメッセージを受信すると、他のPEがBGPテーブルをクリアします。VESルートの引き出しメッセージは、ESルートごとのイーサネットA-Dまたはグループ化B-MACルートの引き出しが以前に受信されたときに、受信PESによるDF選挙手続きの実行には使用されないことに注意してください。
All the security considerations in [RFC7432] and [RFC7623] apply directly to this document because this document leverages the control and data plane procedures described in those documents.
[RFC7432]および[RFC7623]のすべてのセキュリティ上の考慮事項は、このドキュメントに記載されているコントロールおよびデータプレーンの手順を活用するため、このドキュメントに直接適用されます。
This document does not introduce any new security considerations beyond that of [RFC7432] and [RFC7623] because advertisements and the processing of ES routes for vES in this document follow that of physical ES in those RFCs.
このドキュメントでは、[RFC7432]および[RFC7623]を超えた新しいセキュリティ上の考慮事項を導入しません。なぜなら、このドキュメントのVESのESルートの広告と処理は、それらのRFCの物理ESのそれに従うからです。
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>.
[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>.
[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>.
[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>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
[RFC9541] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Miyake, M.,
and T. Matsuda, "Flush Mechanism for Customer MAC
Addresses Based on Service Instance Identifier (I-SID) in
Provider Backbone Bridging EVPN (PBB-EVPN)", RFC 9541,
DOI 10.17487/RFC9541, March 2024,
<https://www.rfc-editor.org/info/rfc9541>.
[MEF63] Metro Ethernet Forum, "Subscriber Ethernet Services
Definitions", MEF Standard, MEF 6.3, November 2019,
<https://www.mef.net/resources/mef-6-3-subscriber-
ethernet-service-definitions>.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks",
RFC 4377, DOI 10.17487/RFC4377, February 2006,
<https://www.rfc-editor.org/info/rfc4377>.
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
Nadeau, T., and Y. Stein, "Pseudowire (PW) Operations,
Administration, and Maintenance (OAM) Message Mapping",
RFC 6310, DOI 10.17487/RFC6310, July 2011,
<https://www.rfc-editor.org/info/rfc6310>.
[RFC7023] Mohan, D., Ed., Bitar, N., Ed., Sajassi, A., Ed., DeLord,
S., Niger, P., and R. Qiu, "MPLS and Ethernet Operations,
Administration, and Maintenance (OAM) Interworking",
RFC 7023, DOI 10.17487/RFC7023, October 2013,
<https://www.rfc-editor.org/info/rfc7023>.
[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>.
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet
VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
<https://www.rfc-editor.org/info/rfc7209>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
The authors would like to thank Mei Zhang, Jose Liste, and Luc André Burdet for their reviews of this document and their feedback.
著者は、この文書とフィードバックのレビューについて、Mei Zhang、Jose Liste、LucAndréBurdetに感謝したいと思います。
Ali Sajassi
Cisco Systems
Email: sajassi@cisco.com
Patrice Brissette
Cisco Systems
Email: pbrisset@cisco.com
Rick Schell
Independent
Email: rick_schell@outlook.com
John E. Drake
Independent
Email: je_drake@yahoo.com
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com