Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 9744 P. Brissette
Category: Standards Track Cisco Systems
ISSN: 2070-1721 J. Uttaro
Individual
J. Drake
Independent
S. Boutros
Ciena
J. Rabadan
Nokia
March 2025
This document describes a new EVPN Virtual Private Wire Service (VPWS) service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments (ESs) and physical interfaces into a single EVPN-VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) service. This document specifies a solution based on extensions to EVPN-VPWS (RFC 8214), which in turn is based on extensions to EVPN (RFC 7432). Therefore, a thorough understanding of RFCs 7432 and 8214 are prerequisites for this document.
このドキュメントでは、異なるイーサネットセグメント（ESS）と物理インターフェイスにわたって複数のアタッチメントサーキットを多重化するための新しいEVPN仮想プライベートワイヤサービス（VPWS）サービスタイプについて説明し、単一のEVPN-VPWSサービストンネルに物理的なインターフェイスを提供し、単一活性およびすべてのマルチホミーを提供します。この新しいサービスは、EVPN-VPWS Flexible CrossConnect（FXC）サービスと呼ばれます。このドキュメントは、EVPN-VPWS（RFC 8214）への拡張に基づいたソリューションを指定します。これは、EVPN（RFC 7432）の拡張に基づいています。したがって、このドキュメントのRFCS 7432および8214の完全な理解が前提条件です。
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/rfc9744.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9744で取得できます。
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. Terminology
1.2. Requirements Language
2. Requirements
3. Solution
3.1. VPWS Service Identifiers
3.2. Default Flexible Cross-Connect
3.2.1. Multi-homing
3.3. VLAN-Signaled FXC
3.3.1. Local Switching
3.4. Service Instantiation
4. BGP Extensions
5. Failure Scenarios
5.1. EVPN-VPWS Service Failure
5.2. Attachment Circuit Failure
5.3. PE Port Failure
5.4. PE Node Failure
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Contributors
Authors' Addresses
[RFC8214] describes a solution to deliver point-to-point (P2P) services using BGP constructs defined in [RFC7432]. It delivers this P2P service between a pair of Attachment Circuits (ACs), where an AC on a PE can represent a port, a VLAN on a port, or a group of VLANs on a port. It also leverages multi-homing and fast convergence capabilities of [RFC7432] in delivering these VPWS services. Multi-homing capabilities include the support of Single-Active and All-Active redundancy mode, and fast convergence is provided using a "mass withdrawal" message in control plane and fast protection switching using prefix-independent convergence in a data plane upon node or link failure [BGP-PIC]. Furthermore, the use of EVPN BGP constructs eliminates the need for multi-segment pseudowire auto-discovery and signaling if the VPWS service need to span across multiple Autonomous Systems (ASes) [RFC5659].
[RFC8214]は、[RFC7432]で定義されたBGPコンストラクトを使用して、ポイントツーポイント（P2P）サービスを提供するソリューションを説明しています。このP2Pサービスは、PE上のACがポート、ポートのVLAN、またはポート上のVLANのグループを表すことができます。また、これらのVPWSサービスを提供する際に、[RFC7432]のマルチホミングおよび高速収束機能を活用しています。マルチホーミング機能には、単一アクティブおよびオールアクティブな冗長モードのサポートが含まれます。また、ノードまたはリンク障害[BGP-PIC]でのデータプレーンでのプレフィックスに依存しない収束を使用して、コントロールプレーンでの「大量離脱」メッセージと高速保護スイッチングを使用して高速収束が提供されます。さらに、EVPN BGPコンストラクトの使用は、VPWSサービスが複数の自律システム（ASES）にまたがる必要がある場合に、マルチセグメントの擬似ワイヤーの自動発見とシグナリングの必要性を排除します[RFC5659]。
Service providers have a very large number of ACs (in millions) that need to be backhauled across their MPLS/IP network. These ACs may or may not require tag manipulation (e.g., VLAN translation). These service providers want to multiplex a large number of ACs across several physical interfaces spread across one or more PEs (e.g., several ESs) onto a single VPWS service tunnel in order to a) reduce the number of EVPN service labels associated with EVPN-VPWS service tunnels and thus the associated Operations, Administration, and Maintenance (OAM) monitoring and b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is the case in [RFC8214]).
サービスプロバイダーには、MPLS/IPネットワーク全体でバックホールする必要がある非常に多くのACS（数百万）があります。これらのACSは、タグ操作を必要とする場合と必要な場合があります（例：VLAN翻訳）。これらのサービスプロバイダーは、1つまたは複数のPES（例えば、いくつかのESS）に広がるいくつかの物理的なインターフェイスにわたって多数のACSを単一のVPWSサービストンネルにマルチプレックスして、A）EVPN-VPWSサービストンネルに関連するEVPNサービスラベルの数を減らし、EVPNの監視（OAM）の監視（OAM）を削減したいと考えています。[RFC8214]の場合。
Service providers want the above functionality without sacrificing any of the capabilities of [RFC8214] including Single-Active and All-Active multi-homing and fast convergence.
サービスプロバイダーは、単一活動的でオールアクティブなマルチホミングおよび高速収束を含む[RFC8214]の機能を犠牲にすることなく、上記の機能を望んでいます。
This document specifies a solution based on extensions to EVPN-VPWS [RFC8214] to meet the above requirements. Furthermore, [RFC8214] is itself based on extensions to EVPN [RFC7432]. Therefore, a thorough understanding of [RFC7432] and [RFC8214] are prerequisites for this document.
このドキュメントは、上記の要件を満たすために、EVPN-VPWS [RFC8214]の拡張に基づくソリューションを指定します。さらに、[RFC8214]はそれ自体がEVPN [RFC7432]の拡張に基づいています。したがって、[RFC7432]と[RFC8214]の完全な理解は、このドキュメントの前提条件です。
AC:
AC:
Attachment Circuit
アタッチメント回路
ES:
ES:
Ethernet Segment
イーサネットセグメント
ESI:
ESI:
Ethernet Segment Identifier
イーサネットセグメント識別子
EVI:
EVI:
EVPN Instance Identifier
EVPNインスタンス識別子
EVPN:
EVPN：
Ethernet Virtual Private Network
イーサネット仮想プライベートネットワーク
Ethernet A-D:
イーサネットA-D：
Ethernet Auto-Discovery (per EVI or per Ethernet A-D per ESI routes, as defined in [RFC7432] and [RFC8214])
イーサネットの自動ディスコービリ（EVIあたりまたは[RFC7432]および[RFC8214]で定義されているESIルートごとのイーサネットA-Dごと））
FXC:
FXC:
Flexible Cross-Connect
柔軟なクロスコネクト
MAC:
MAC:
Media Access Control
メディアアクセス制御
MPLS:
MPLS：
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
OAM:
OAM:
Operations, Administration, and Maintenance
運用、管理、およびメンテナンス
PE:
PE:
Provider Edge
プロバイダーエッジ
VCCV:
VCCV：
Virtual Circuit Connectivity Verification
仮想回路接続の確認
VID:
VID:
VLAN ID
VLAN ID
VPWS:
VPWS：
Virtual Private Wire Service
仮想プライベートワイヤーサービス
VRF:
VRF:
VPN Routing and Forwarding
VPNルーティングと転送
IP-VRF:
IP-VRF：
VPN Routing and Forwarding for IP lookup
IP LookupのVPNルーティングと転送
MAC-VRF:
MAC-VRF：
VPN Routing and Forwarding for MAC lookup
MacルックアップのVPNルーティングと転送
VID-VRF:
VID-VRF：
VPN Routing and Forwarding for normalized VID lookup
正規化されたVIDルックアップのVPNルーティングと転送
VPWS Service Tunnel:
VPWSサービストンネル：
It is represented by a pair of EVPN service labels associated with a pair of endpoints. Each label is downstream assigned and advertised by the disposition PE through an Ethernet A-D per EVI route. The downstream label identifies the endpoint on the disposition PE. A VPWS service tunnel can be associated with many VPWS service identifiers where each identifier is a normalized VID.
これは、エンドポイントのペアに関連付けられた1ペアのEVPNサービスラベルで表されます。各ラベルは、EVIルートごとのイーサネットA-Dを介して、処分PEによって割り当てられ、宣伝されています。ダウンストリームラベルは、気質PEのエンドポイントを識別します。VPWSサービストンネルは、各識別子が正規化されたVIDである多くのVPWSサービス識別子に関連付けることができます。
Single-Active Redundancy Mode:
単一活動冗長モード：
When a device or a network is multi-homed to two or more PEs and when only a single PE in such redundancy group can forward traffic to/from the multi-homed device or network for a given VLAN, then such multi-homing or redundancy is referred to as "Single-Active".
デバイスまたはネットワークが2つ以上のPEにマルチホームされ、そのような冗長グループの単一のPEのみが、特定のVLANのマルチホームデバイスまたはネットワークに出入りするトラフィックを転送できる場合、そのようなマルチホームまたは冗長性は「単一活性」と呼ばれます。
All-Active Redundancy Mode:
オールアクティブな冗長モード：
When a device or a network is multi-homed to two or more PEs and when all PEs in such redundancy group can forward traffic to/from the multi-homed device or network for a given VLAN, then such multi-homing or redundancy is referred to as "All-Active".
デバイスまたはネットワークが2つ以上のPESにマルチホームされ、そのような冗長グループのすべてのPEが特定の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] で説明されているように解釈されます。
Two of the main motivations for service providers seeking a new solution are: 1) to reduce the number of VPWS service tunnels by multiplexing a large number of ACs across different physical interfaces instead of having one VPWS service tunnel per AC and 2) to reduce the signaling of ACs as much as possible. Besides these two requirements, they also want the multi-homing and fast convergence capabilities of [RFC8214].
新しいソリューションを求めているサービスプロバイダーの主な動機の2つは、1）ACごとに1つのVPWSサービストンネルを持つ代わりに、さまざまな物理インターフェイス全体で多数のACSを多重化することにより、VPWSサービストンネルの数を減らすことで、可能な限りACSのシグナルを減らすことです。これらの2つの要件に加えて、彼らはまた、[RFC8214]のマルチホーミングと高速の収束機能を望んでいます。
In [RFC8214], a PE signals an AC indirectly by first associating that AC to a VPWS service tunnel (e.g., a VPWS service instance) and then signaling the VPWS service tunnel via an Ethernet A-D per EVI route with the Ethernet Tag field set to a 24-bit VPWS service instance identifier (which is unique within the EVI) and the ESI field set to a 10-octet identifier of the ES corresponding to that AC.
[RFC8214]では、PEは最初にそのACをVPWSサービストンネル（例：VPWSサービスインスタンスなど）に関連付け、次にEtherNet AA-Dを介してEtherNet as a a dを介してEthernet a a dを介してEthernet a a dを介してEthernet servi fieldを介してEthernet dis a dを介して24ビットサービスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインスタンスインインスタンスに設定されています。そのACに対応するESの10-OCTET識別子。
Therefore, a PE device that receives such EVPN routes can associate the VPWS service tunnel to the remote ES using the ESI field. Additionally, when the remote ES fails and the PE receives the "mass withdrawal" message associated with the failed ES per [RFC7432], a PE device can quickly update its next-hop adjacency list (adjacency list) for all VPWS service tunnels sharing the ESI field and achieve fast convergence for multi-homing scenarios. Even if fast convergence were not needed, there would still be a need for signaling each AC failure (via its corresponding VPWS service tunnel) associated with the failed ES so that the adjacency list gets updated and the packets are sent to a backup PE (in case of Single-Active multi-homing) or to other PEs in the redundancy group (in case of All-Active multi-homing). In the absence of updating the adjacency list properly, the traffic for that VPWS service tunnel will be dropped by the egress PE with a failed ES/AC.
したがって、このようなEVPNルートを受信するPEデバイスは、ESIフィールドを使用してVPWSサービストンネルをリモートESに関連付けることができます。さらに、リモートESが故障し、PEが[RFC7432]あたりの故障に関連付けられた「質量引き出し」メッセージを受信すると、PEデバイスは、すべてのVPWSサービストンネルの次のホップ隣接リスト（隣接リスト）をESIフィールドを共有する隣の隣接リスト（隣接リスト）を迅速に更新し、マルチホミングシナリオの高速収束を達成できます。高速収束が必要でなかったとしても、隣接リストが更新され、パケットが（単一活性マルチホームの場合）または冗長性グループの他のPE（すべての活動的なマルチホームの場合）に送信されるように、各AC障害（対応するVPWSサービストンネルを介して）を[対応するVPWSサービストンネルを介して）シグナル伝達する必要があります。隣接リストを適切に更新していない場合、そのVPWSサービストンネルのトラフィックは、ES/ACの故障により出口PEによってドロップされます。
When a single VPWS service tunnel carries multiple ACs across various ESs (physical interfaces) without signaling the ACs via EVPN BGP to remote PE devices, those remote PE devices lack the information to associate the received ES with these ACs or with their local ACs. They also lack the association between the VPWS service tunnel (e.g., EVPN service label) and the far-end ACs. This means that, while the remote PEs can associate their local ACs with the VPWS service tunnel, they cannot make similar associations for the far-end ACs.
単一のVPWSサービストンネルが、EVPN BGPを介してACSをリモートPEデバイスに通知することなく、さまざまなESS（物理インターフェイス）にわたって複数のACSを運ぶ場合、これらのリモートPEデバイスには、受信したESをこれらのACSまたはローカルACSに関連付ける情報がありません。また、VPWSサービストンネル（EVPNサービスラベルなど）とファーエンドACSとの関連性もありません。これは、リモートPESがローカルACをVPWSサービストンネルに関連付けることができるが、ファーエンドACSと同様の関連性を作成できないことを意味します。
Consequently, in case of a connectivity failure to the ES, the remote PEs are unable to redirect traffic via another multi-homing PE to that ES. In other words, even if an ES failure is signaled via EVPN to the remote PE devices, they cannot effectively respond because they do not know the relationship between the remote ES, the remote ACs, and the VPWS service tunnel.
したがって、ESへの接続障害の場合、リモートPEはそのESに別のマルチホミングPEを介してトラフィックをリダイレクトできません。言い換えれば、EVPNを介してリモートPEデバイスにEVPNを介して通知されたとしても、リモートES、リモートACS、およびVPWSサービストンネルの関係を知らないため、効果的に応答することはできません。
To address this issue when multiplexing a large number of ACs onto a single VPWS service tunnel, two mechanisms have been developed: one to support VPWS services between two single-homed endpoints and another one to support VPWS services where one of the endpoints is multi-homed.
この問題に対処するために、多数のACSを単一のVPWSサービストンネルにマルチプレックスすると、2つのメカニズムが開発されました。1つは2つのシングルホームエンドポイント間のVPWSサービスをサポートし、もう1つはエンドポイントの1つがマルチホームであるVPWSサービスをサポートするためです。
For single-homed endpoints, it is acceptable not to signal each AC in BGP because, in the event of a connection failure to the ES, there is no alternative path to that endpoint. However, the implication of not signaling an AC failure is that the traffic destined for the failed AC is sent over the MPLS/IP core and then discarded at the destination PE, thereby potentially wasting network resources.
シングルホームのエンドポイントの場合、ESへの接続の障害が発生した場合、そのエンドポイントへの代替パスはないため、BGPの各ACを信号にしないことは許容できます。ただし、AC障害を通知しないことの意味は、故障したACに導かれたトラフィックがMPLS/IPコアに送信され、宛先PEで廃棄され、それによりネットワークリソースを無駄にする可能性があることです。
This waste of network resources during a connection failure may be transient, as it can be detected and prevented at the application layer in certain cases. Section 3.2 outlines a solution for such single-homing VPWS services.
接続障害中のネットワークリソースの廃棄物は、特定の場合にアプリケーション層で検出および防止できるため、一時的なものになる場合があります。セクション3.2では、このような単一宿主VPWSサービスのソリューションの概要を説明します。
For VPWS services where one of the endpoints is multi-homed, there are two options:
エンドポイントの1つがマルチホームにあるVPWSサービスの場合、2つのオプションがあります。
1. Signal each AC via BGP, allowing the adjacency list to be updated upon a failure affecting those ACs. This solution is described in Section 3.3 and is referred to as the "VLAN-signaled FXC service".
1. BGPを介して各ACを信号し、それらのACSに影響を与える障害時に隣接リストを更新できるようにします。このソリューションはセクション3.3で説明されており、「VLANシグナルFXCサービス」と呼ばれます。
2. Bundle several ACs on an ES together per destination endpoint (e.g., ES, MAC-VRF, etc.) and associate such a bundle with a single VPWS service tunnel. This approach is similar to the VLAN bundle service interface described in [RFC8214]. This solution is described in Section 3.2.1.
2. 宛先エンドポイント（ES、MAC-VRFなど）ごとにESで複数のACSをバンドルし、そのようなバンドルを単一のVPWSサービストンネルに関連付けます。このアプローチは、[RFC8214]で説明されているVLANバンドルサービスインターフェイスに似ています。このソリューションについては、セクション3.2.1で説明しています。
This section specifies how to provide a new VPWS service between two PE devices where a large number of ACs (such as VLANs) that span across multiple ESs (physical interfaces) on each PE are multiplexed onto a single P2P EVPN service tunnel. Since the multiplexing involves several physical interfaces, there can be overlapping VLAN IDs (VIDs) across these interfaces. In such cases, the VIDs must be translated into unique VIDs to prevent collisions. Furthermore, if the number of VLANs being multiplexed onto a single VPWS service tunnel exceeds 4095, then a single tag to double tag translation must be performed. This translation of VIDs into unique VIDs (either single or double) results in a "normalized VID".
このセクションでは、各PEの複数のESS（物理インターフェイス）にまたがる多数のACS（VLANなど）が単一のP2P EVPNサービストンネルに多数のACS（VLANなど）が2つのPEデバイス間で新しいVPWSサービスを提供する方法を指定します。多重化にはいくつかの物理インターフェイスが含まれるため、これらのインターフェイス全体にVLAN ID（VID）が重複する可能性があります。そのような場合、VIDは衝突を防ぐために一意のビデオに翻訳する必要があります。さらに、単一のVPWSサービストンネルに多重化されているVLANの数が4095を超える場合、1つのタグからダブルタグ変換を実行する必要があります。このVIDを一意のVID（単一または二重）に翻訳すると、「正規化されたVID」が生じます。
When a single normalized VID is used, the lower 12 bits of the Ethernet Tag ID field in EVPN routes MUST be set to that VID. When a double normalized VID is used, the lower 12 bits of the Ethernet Tag ID field MUST be set to the inner VID, while the higher 12 bits are set to the outer VID. 24-bit VPWS service instance identifiers [RFC8214] as well as 12-bit VPWS service instance identifiers representing normalized VIDs MUST be right-aligned.
単一の正規化されたVIDを使用する場合、EVPNルートのイーサネットタグIDフィールドの下部12ビットをそのVIDに設定する必要があります。二重正規化されたVIDを使用すると、イーサネットタグIDフィールドの下部12ビットを内側のVIDに設定する必要があり、より高い12ビットが外VIDに設定されます。24ビットVPWSサービスインスタンス識別子[RFC8214]および正規化されたVIDを表す12ビットVPWSサービスインスタンス識別子は右に整列する必要があります。
Since there is only a single EVPN-VPWS service tunnel associated with many normalized VIDs (either single or double) across multiple physical interfaces, an MPLS lookup at the disposition PE is no longer sufficient to forward the packet to the correct egress endpoint or interface. Therefore, in addition to an EVPN label lookup corresponding to the VPWS service tunnel, a VID lookup (either single or double) is also required. At the disposition PE, the EVPN label lookup identifies a VID-VRF, and the lookup of the normalized VIDs within that table identifies the appropriate egress endpoint or interface. The tag manipulation (translation from normalized VIDs to the local VID) SHOULD be performed either as part of the VID table lookup or at the egress interface itself.
複数の物理インターフェイスにわたって多くの正規化されたVID（シングルまたはダブル）に関連付けられた単一のEVPN-VPWSサービストンネルしかないため、気質PEのMPLS検索は、パケットを正しい出力エンドポイントまたはインターフェイスに転送するのに十分ではなくなりました。したがって、VPWSサービストンネルに対応するEVPNラベルルックアップに加えて、VIDルックアップ（シングルまたはダブル）も必要です。気質PEでは、EVPNラベルルックアップがVID-VRFを識別し、そのテーブル内の正規化されたVIDのルックアップは、適切な出口エンドポイントまたはインターフェイスを識別します。タグの操作（正規化されたVIDからローカルVIDへの翻訳）は、VIDテーブルの検索の一部として、またはEgressインターフェイス自体のいずれかとして実行する必要があります。
Since the VID lookup (single or double) needs to be performed at the disposition PE, VID normalization MUST be completed prior to MPLS encapsulation on the ingress PE. This requires that both the imposition and disposition PE devices be capable of VLAN tag manipulation, such as rewriting (single or double), adding, or deleting (single or double) at their endpoints (e.g., their ESs, MAC-VRFs, IP-VRFs, etc.). Operators should be informed of potential trade-offs from a performance standpoint, compared to typical pseudowire processing.
VIDルックアップ（シングルまたはダブル）を処分PEで実行する必要があるため、MPLSがイングレスPEでカプセル化される前に、VID正規化を完了する必要があります。これには、賦課と処分PEデバイスの両方が、書き換え（シングルまたはダブル）、エンドポイント（ESS、MAC-VRFS、IP-VRFなど）で追加または削除（シングルまたはダブル）などのVLANタグ操作が可能であることが必要です。オペレーターは、典型的な擬似ワイヤの処理と比較して、パフォーマンスの観点から潜在的なトレードオフを知らせる必要があります。
In [RFC8214], a unique value identifying the service is signaled in the context of each PE's EVI. The 32-bit Ethernet Tag ID field MUST be set to this VPWS service instance identifier value. Translation at an Autonomous System Border Router (ASBR) is needed if re-advertising to another AS affects uniqueness.
[RFC8214]では、サービスを識別する一意の値が、各PEのEVIのコンテキストで通知されます。32ビットイーサネットタグIDフィールドは、このVPWSサービスインスタンス識別子値に設定する必要があります。自律システムのボーダールーター（ASBR）での翻訳は、一意性に影響を与えるように別のものに再版を付ける場合に必要です。
For FXC, this same Ethernet Tag ID field value is an identifier that may represent:
FXCの場合、この同じイーサネットタグIDフィールド値は、次のことを表す可能性のある識別子です。
* VLAN Bundle Service Interface: a unique value for a group of VLANs
* VLANバンドルサービスインターフェイス：VLANのグループにとってユニークな価値
* VLAN-Aware Bundle Service Interface: a unique value for individual VLANs and is considered the same as the normalized VID
* VLAN-AWAREバンドルサービスインターフェイス：個々のVLANの一意の値であり、正規化されたVIDと同じと見なされます
Both the VPWS service instance identifier and normalized VID are carried in the Ethernet Tag ID field of the Ethernet A-D per EVI route. For FXC, in the case of a 12-bit ID, the VPWS service instance identifier is the same as the single-tag normalized VID and will be the same on both VPWS service endpoints. Similarly in the case of a 24-bit ID, the VPWS service instance identifier is the same as the double-tag normalized VID.
VPWSサービスインスタンス識別子と正規化されたVIDの両方が、EVIルートあたりのイーサネットA-DのイーサネットタグIDフィールドに運ばれます。FXCの場合、12ビットIDの場合、VPWSサービスインスタンス識別子はシングルタグ正規化VIDと同じであり、両方のVPWSサービスエンドポイントで同じになります。同様に、24ビットIDの場合、VPWSサービスインスタンス識別子は、ダブルタグ正規化されたVIDと同じです。
In this mode of operation, many ACs across several ESs are multiplexed into a single EVPN-VPWS service tunnel represented by a single VPWS service ID. This is the default mode of operation for FXC, and the participating PEs do not need to signal the VLANs (normalized VIDs) in EVPN BGP.
この動作モードでは、いくつかのESSにわたる多くのACSが、単一のVPWSサービスIDで表される単一のEVPN-VPWSサービストンネルに多重化されています。これはFXCのデフォルトの動作モードであり、参加しているPESはEVPN BGPのVLAN（正規化されたVID）を信号する必要はありません。
Regarding the data plane aspects of this solution, the imposition PE performs VID normalization, and the disposition PE carries out VID lookup and translation. Both imposition and disposition PE devices MUST be aware of the VLANs through configuration. There should ideally be a single point-to-point (P2P) EVPN-VPWS service tunnel between a pair of PEs for a specific set of ACs.
このソリューションのデータプレーンの側面に関して、賦課PEはVID正規化を実行し、PES PEはVIDの検索と翻訳を実行します。賦課と処分の両方のPEデバイスは、構成を介してVLANを認識する必要があります。理想的には、特定のACSセットについて、PEのペア間に単一のポイントツーポイント（P2P）EVPN-VPWSサービストンネルが必要です。
As previously mentioned, because the EVPN-VPWS service tunnel is employed to multiplex ACs across various ESs or physical interfaces, the EVPN label alone is not sufficient for accurate forwarding of the received packets over the MPLS/IP network to egress interfaces. Therefore, normalized VID lookup is REQUIRED in the disposition direction to forward packets to their proper egress endpoints; the EVPN label lookup identifies a VID-VRF, and a subsequent normalized VID lookup in that table identifies the egress interface.
前述のように、EVPN-VPWSサービストンネルはさまざまなESSまたは物理インターフェイスにわたってマルチプレックスACSに採用されているため、EVPNラベルだけでは、MPLS/IPネットワークを介して受信したパケットを正確に転送してインターフェースを出力するのに十分ではありません。したがって、適切な出力エンドポイントにパケットを転送するには、気質方向に正規化されたVID検索が必要です。EVPNラベルルックアップはVID-VRFを識別し、その後のテーブルのその後の正規化されたVIDルックアップは、出口インターフェイスを識別します。
In this solution, for each PE, the single-homing ACs represented by their normalized VIDs are associated with a single VPWS service instance within a specific EVI. The generated EVPN route is an Ethernet A-D per-EVI route with an ESI of 0, the Ethernet Tag field is set to a VPWS service instance ID, and the MPLS label field is set to a dynamically generated EVPN service label representing the EVPN-VPWS service tunnel. This route is sent with a Route Target (RT) that represents the EVI, which can be auto-generated from the EVI according to Section 5.1.2.1 of [RFC8365]. Additionally, this route is sent with the EVPN Layer 2 Attributes Extended Community defined in Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) that indicate: 1) the VPW service tunnel (set to default Flexible Cross-Connect) and 2) the normalized VID type (set to normalized single VID or double VID). The receiving PE uses these new flags for a consistency check and MAY generate an alarm if it detects inconsistencies, but it will not disrupt the VPWS service.
このソリューションでは、各PEについて、それらの正規化されたVIDで表される単一ホーミングACは、特定のEVI内の単一のVPWSサービスインスタンスに関連付けられています。生成されたEVPNルートは、ESIが0のイーサネットA-D PER-EVIルートであり、イーサネットタグフィールドはVPWSサービスインスタンスIDに設定され、MPLSラベルフィールドは、EVPN-VPWSサービストンネルを表す動的に生成されたEVPNサービスラベルに設定されます。このルートは、[RFC8365]のセクション5.1.2.1に従ってEVIから自動生成できるEVIを表すルートターゲット（RT）で送信されます。さらに、このルートは、[RFC8214]のセクション3.1で定義されている拡張されたコミュニティ2属性で送信されます。これは、次の2つの新しいフラグ（セクション4で概説）を示します。受信PEは、一貫性チェックのためにこれらの新しいフラグを使用し、矛盾を検出した場合にアラームを生成する可能性がありますが、VPWSサービスを妨害しません。
It should be noted that in this mode of operation, a single Ethernet A-D per-EVI route is transmitted upon the configuration of the first AC with the normalized VID. As additional ACs are configured and associated with this EVPN-VPWS service tunnel, the PE does not advertise any additional EVPN BGP routes and only locally associates these ACs with the pre-established VPWS service tunnel.
この操作モードでは、単一のイーサネットA-D EVIごとのルートが、正規化されたVIDを使用した最初のACの構成時に送信されることに注意してください。追加のACSが構成され、このEVPN-VPWSサービストンネルに関連付けられているため、PEは追加のEVPN BGPルートを宣伝せず、これらのACを事前に確立されたVPWSサービストンネルと地元でのみ関連付けます。
The default FXC mode can also be used for multi-homing. In this mode, a group of normalized VIDs representing ACs on a single ES, all destined to a single endpoint, are multiplexed into a single EVPN-VPWS service tunnel, which is identified by a unique VPWS service ID. When employing the default FXC mode for multi-homing, rather than using a single EVPN-VPWS service tunnel, there may be multiple service tunnels per pair of PEs. Specifically, there is one tunnel for each group of VIDs per pair of PEs, and there can be many such groups between a pair of PEs, resulting in numerous EVPN service tunnels.
デフォルトのFXCモードは、マルチホミングにも使用できます。このモードでは、単一のES上のACSを表す正規化されたVIDのグループは、すべて単一のエンドポイントに運命づけられており、単一のVPWSサービスIDによって識別される単一のEVPN-VPWSサービストンネルに多重化されます。単一のEVPN-VPWSサービストンネルを使用するのではなく、マルチホーミングにデフォルトのFXCモードを使用する場合、PESペアごとに複数のサービストンネルがある場合があります。具体的には、PEのペアごとにVIDのグループごとに1つのトンネルがあり、PEのペア間に多くのグループがあるため、多数のEVPNサービストンネルが生成されます。
In this mode of operation, similar to the default FXC mode described in Section 3.2, many normalized VIDs representing ACs across several ESs and interfaces are multiplexed into a single EVPN-VPWS service tunnel. However, this single tunnel is represented by multiple VPWS service IDs (one per normalized VID), and these normalized VIDs are signaled using EVPN BGP.
この動作モードでは、セクション3.2で説明されているデフォルトのFXCモードと同様に、いくつかのESSおよびインターフェイスにわたってACSを表す多くの正規化されたVIDが単一のEVPN-VPWSサービストンネルに多重化されます。ただし、この単一のトンネルは、複数のVPWSサービスID（正規化されたVIDごとに1つ）で表され、これらの正規化されたVIDはEVPN BGPを使用して通知されます。
In this solution, on each PE, the multi-homing ACs represented by their normalized VIDs are configured with a single EVI. There is no need to configure a separate VPWS service instance ID in here, as it corresponds to the normalized VID. For each normalized VID on each ES, the PE generates an Ethernet A-D per-EVI route where the ESI field represents the ES ID, the Ethernet Tag field is set to the normalized VID, and the MPLS label field is set to a dynamically generated EVPN label representing the P2P EVPN service tunnel. This label is the same for all ACs multiplexed into a single EVPN-VPWS service tunnel. This route is sent with an RT representing the EVI. As before, this RT can be auto-generated from the EVI per Section 5.1.2.1 of [RFC8365]. Additionally, this route includes the EVPN Layer 2 Attributes Extended Community defined in Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) that indicate: 1) this VPWS service tunnel for VLAN-signaled FXC and 2) the normalized VID type (single versus double). The receiving PE uses these new flags for a consistency check and may generate an alarm if it detects inconsistency, but it will not disrupt the VPWS service.
このソリューションでは、各PEで、正規化されたVIDで表されるマルチホームACSは、単一のEVIで構成されています。正規化されたVIDに対応するため、ここで個別のVPWSサービスインスタンスIDを構成する必要はありません。各ESの各正規化されたVIDについて、PEはESIフィールドがES IDを表すイーサネットA-D PER-EVIルートを生成し、イーサネットタグフィールドは正規化されたVIDに設定され、MPLSラベルフィールドはP2P EVPNサービストンネルを表す動的に生成されたEVPNラベルに設定されます。このラベルは、単一のEVPN-VPWSサービストンネルに多重化されたすべてのACSで同じです。このルートは、EVIを表すRTで送信されます。前と同様に、このRTは、[RFC8365]のセクション5.1.2.1ごとにEVIから自動生成できます。さらに、このルートには、[RFC8214]のセクション3.1で定義されているEVPNレイヤー2属性が、次の2つの新しいフラグ（1）を示す2つの新しいフラグ（セクション4で概説）を含みます。受信PEは、一貫性チェックのためにこれらの新しいフラグを使用し、矛盾を検出した場合にアラームを生成する可能性がありますが、VPWSサービスを妨害しません。
It should be noted that in this mode of operation, the PE sends a single Ethernet A-D per-EVI route for each AC that is configured. Each normalized VID that is configured per ES results in generation of an Ethernet A-D per EVI.
この動作モードでは、PEは構成されている各ACに対して単一のイーサネットA-D PER-EVIパールートを送信することに注意する必要があります。ESごとに構成された各正規化されたVIDは、EVIごとにイーサネットA-Dの生成をもたらします。
This mode of operation enabled automatic cross-checking of normalized VIDs used for Ethernet Virtual Private Line (EVPL) services because these VIDs are signaled in EVPN BGP. For instance, if the same normalized VID is configured on three PE devices (instead of two) for the same EVI, then when a PE receives the second remote Ethernet A-D per EVI route, it generates an error message unless the two Ethernet A-D per EVI routes include the same ESI. Such cross-checking is not feasible in the default FXC mode because the normalized VIDs are not signaled.
この操作モードは、これらのVIDがEVPN BGPでシグナル化されるため、イーサネット仮想プライベートライン（EVPL）サービスに使用される正規化されたVIDの自動クロスチェックを可能にしました。たとえば、同じEVIに対して同じ正規化されたVIDが3つのPEデバイス（2つではなく）で構成されている場合、PEがEVIルートごとに2番目のリモートイーサネットA-Dを受信する場合、EVIルートごとに2つのイーサネットA-Dに同じESIが含まれない限り、エラーメッセージを生成します。正規化されたVIDSが信号されていないため、このようなクロスチェックはデフォルトのFXCモードでは実行不可能です。
When cross-connection occurs between two ACs belonging to two multi-homed ESs on the same set of multi-homing PEs, the forwarding between the two ACs must be performed locally during normal operation (e.g., in absence of a local link failure). This means that traffic between the two ACs MUST be locally switched within the PE.
同じマルチホーミングPESのセット上の2つのマルチホームESSに属する2つのACS間で相互接続が発生する場合、通常の動作中に2つのACS間の転送をローカルに実行する必要があります（たとえば、ローカルリンク障害がない場合）。これは、2つのAC間のトラフィックをPE内でローカルに切り替える必要があることを意味します。
In terms of control plane processing, this means that when the receiving PE processes an Ethernet A-D per-EVI route whose ESI is a local ESI, the PE does not modify its forwarding state based on the received route. This approach ensures that local switching takes precedence over forwarding via the MPLS/IP network. This method of prioritizing locally switched traffic aligns with the baseline EVPN principles described in [RFC7432], where locally switched preference is specified for MAC/IP routes.
これは、コントロールプレーン処理の観点から、受信PEがESIがローカルESIであるイーサネットA-D PER-EVIパスルートを処理する場合、PEは受信ルートに基づいて転送状態を変更しないことを意味します。このアプローチにより、ローカルスイッチングがMPLS/IPネットワークを介した転送よりも優先されることが保証されます。ローカルに切り替えられたトラフィックの優先順位付けのこの方法は、[RFC7432]で説明されているベースラインEVPN原則と一致します。
In such scenarios, the Ethernet A-D per-EVI route should be advertised with the MPLS label either associated with the destination AC or with the destination ES in order to avoid any ambiguity in forwarding. In other words, the MPLS label cannot represent the same VID-VRF outlined in Section 3.3, as the same normalized VID can be reachable via two ESs. In the case of using an MPLS label per destination AC, this approach can also be applied to VLAN-based VPWS or VLAN bundle VPWS services as per [RFC8214].
このようなシナリオでは、Ethernet A-D PER-EVIルートは、転送のあいまいさを避けるために、宛先ACまたは宛先ESに関連付けられているMPLSラベルで宣伝する必要があります。言い換えれば、MPLSラベルは、セクション3.3で概説されている同じVID-VRFを表すことはできません。宛先ACごとにMPLSラベルを使用する場合、このアプローチは、[RFC8214]に従って、VLANベースのVPWSまたはVLANバンドルVPWSサービスにも適用できます。
The V field defined in Section 4 is OPTIONAL. However, if transmitted, its value may indicate an error condition that could lead to operational issues. In such cases, merely notifying the operator of an error is insufficient; the VPWS service tunnel must not be established.
セクション4で定義されているVフィールドはオプションです。ただし、送信された場合、その値は、運用上の問題につながる可能性のあるエラー条件を示している可能性があります。そのような場合、エラーをオペレーターに通知するだけでは不十分です。VPWSサービストンネルを確立してはなりません。
If both endpoints of a VPWS tunnel are signaling a matching normalized VID in the control plane, but one is operating in single-tag mode and the other in double-tag mode, then the signaling of the V-bit facilitates the detection and prevention of this tunnel's instantiation.
VPWSトンネルの両方のエンドポイントがコントロールプレーンで一致する正規化されたVIDを信号しているが、1つはシングルタグモードで動作し、もう1つはダブルタグモードで動作している場合、Vビットの信号はこのトンネルのインスタンスの検出と予防を促進します。
If single VID normalization is signaled in the Ethernet Tag ID field (12 bits), yet the data plane is operating based on double tags, the VID normalization applies only to the outer tag. Conversely, if double VID normalization is signaled in the Ethernet Tag ID field (24 bits), VID normalization applies to both the inner and outer tags.
イーサネットタグIDフィールド（12ビット）で単一のVID正規化がシグナル化されているが、データプレーンがダブルタグに基づいて動作している場合、VID正規化は外側のタグにのみ適用されます。逆に、イーサネットタグIDフィールド（24ビット）で二重VID正規化がシグナル化されている場合、VID正規化は内側と外側のタグの両方に適用されます。
This document uses the EVPN Layer 2 Attributes Extended Community as defined in [RFC8214] with two additional flags incorporated into this Extended Community (EC) as detailed below. This EC is sent with Ethernet A-D per-EVI route per Section 3 and SHOULD be sent for both Single-Active and All-Active redundancy modes.
このドキュメントでは、[RFC8214]で定義されているEVPNレイヤー2属性拡張コミュニティを使用して、この拡張コミュニティ（EC）に組み込まれた2つの追加フラグを以下に説明します。このECは、セクション3ごとにイーサネットA-D EVIごとのルートを使用して送信され、単一活性およびオールアクティブな冗長性モードの両方に対して送信する必要があります。
+-------------------------------------------+
| Type (0x06) / Sub-type (0x04) (2 octets) |
+-------------------------------------------+
| Control Flags (2 octets) |
+-------------------------------------------+
| L2 MTU (2 octets) |
+-------------------------------------------+
| Reserved (2 octets) |
+-------------------------------------------+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | V | M | |C|P|B| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bits in the Control Flags are defined; the remaining bits MUST be set to zero when sending and MUST be ignored when receiving this community.
コントロールフラグの次のビットが定義されています。残りのビットは、送信中はゼロに設定する必要があり、このコミュニティを受け取るときは無視する必要があります。
+=======+==============================================+
| Name | Meaning |
+=======+==============================================+
| B,P,C | per definition in [RFC8214] |
+-------+----------------------------------------------+
| M | 00 mode of operation as defined in [RFC8214] |
| +----------------------------------------------+
| | 01 VLAN-Signaled FXC |
| +----------------------------------------------+
| | 10 Default FXC |
+-------+----------------------------------------------+
| V | 00 operating per [RFC8214] |
| +----------------------------------------------+
| | 01 single-VID normalization |
| +----------------------------------------------+
| | 10 double-VID normalization |
+-------+----------------------------------------------+
Table 1
The M and V fields are OPTIONAL. The M field is ignored at reception for forwarding purposes and is used for error notifications.
MおよびVフィールドはオプションです。Mフィールドは、転送目的で受信時に無視され、エラー通知に使用されます。
The two following examples analyze the failure scenarios.
次の2つの例では、障害シナリオを分析します。
The first scenario is a default Flexible Cross-Connect with a multi-homing solution, and it is depicted in Figure 1. In this case, VID normalization is performed, and a single Ethernet A-D per-EVI route is sent for the bundle of ACs on an ES. That is, PE1 will advertise two Ethernet A-D per-EVI routes: The first one will identify the ACs on port p1's ES, and the second one will identify the AC2 in port p2's ES. Similarly, PE2 will advertise two Ethernet A-D per-EVI routes.
最初のシナリオは、マルチホミングソリューションを備えたデフォルトの柔軟なクロスコネクトであり、図1に描かれています。この場合、VID正規化が実行され、ESのACSのバンドルに対して単一のイーサネットA-D EVIパールートが送信されます。つまり、PE1は2つのイーサネットA-D EVI PER-EVIルートを宣伝します。1つ目はポートP1のESのACSを識別し、2番目のESでAC2をポートP2のESのAC2を識別します。同様に、PE2はEVIごとに2つのイーサネットA-Dを宣伝します。
N.VID 1,2,3 +---------------------+
PE1 | |
+---------+ IP/MPLS |
+-----+ VID1 p1 | +-----+ | sv.T1 +
| CE1 |-------------| FXC |======+ PE3 +-----+
| | /\ | | | | \ +----------+ +--| CE3 |
+-----+\ +||---| | sv.T2 \ | | 1/ | |
VID3\ / ||---| |=====+ \ | +-----+ | / +-----+
\ // \/ | +-----+ | \ +====| FXC |----+
\ / p2 +---------+ +======| | | 2 +-----+
/\ | | |----------| CE4 |
/ /\ +---------+ +=====| | | | |
/ / \p3 | +-----+ sv.T3 / +====| | | +-----+
VIDs1,2 / +----| FXC |=======+ / | | |---+
+-----+ / /\ | | | | / | +-----+ |\3 +-----+
| CE2 |-----||---| | | sv.T4 / | | \ | CE5 |
| |-----||---| | |======+ +----------+ +---| |
+--VIDs3,4 \/ | +-----+ | | +-----+
p4 +---------+ |
PE2 | |
N.VID 1,2,3 +-------------------+
Figure 1: Default Flexible Cross-Connect
図1：デフォルトのフレキシブルクロスコネクト
The second scenario, depicted in Figure 2, illustrates the VLAN-signaled FXC mode with multi-homing. In this example:
図2に示す2番目のシナリオは、マルチホミングを備えたVLANシグナルFXCモードを示しています。この例では：
* CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3), respectively. CE1's VIDs are normalized to value 1 on both PEs, and CE1 is cross-connected to CE3's VID 1 at the remote end.
* Ce1は、それぞれ（ポート、VID）=（P1,1）および（P3,3）を介してPE1およびPE2に接続されています。CE1のVIDは両方のPESで値1に正規化され、CE1はリモートエンドのCE3のVID 1に相互接続されています。
* CE2 is connected to PE1 and PE2 via ports p2 and p4, respectively:
* CE2は、それぞれポートP2とP4を介してPE1とPE2に接続されています。
- The combinations (p2,1) and (p4,3) identify the ACs used to cross-connect CE2 to CE4's VID 2 and are normalized to value 2.
- 組み合わせ（p2,1）と（p4,3）は、CE2とCE4のVID 2に相互接続するために使用されるACSを識別し、値2に正規化されます。
- The combinations (p2,2) and (p4,4) identify the ACs used to cross-connect CE2 to CE5's VID 3 and are normalized to value 3.
- 組み合わせ（p2,2）と（p4,4）は、CE2とCE5のVID 3との相互接続に使用されるACSを識別し、値3に正規化されます。
In this scenario, PE1 and PE2 advertise an Ethernet A-D per EVI route for each normalized VID (values 1, 2, and 3). However, only two VPWS Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1) between PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2) between PE2's FXC and PE3's FXC.
このシナリオでは、PE1とPE2は、正規化された各VID（値1、2、および3のEVIルートごとにイーサネットA-Dを宣伝しています。ただし、必要なのは2つのVPWSサービストンネルのみが必要です。1）PE1のFXCとPE3のFXCの間のVPWSサービストンネル1（SV.T1）、およびPE2のFXCとPE3のFXCの間のVPWSサービストンネル2（SV.T2）。
N.VID 1,2,3 +---------------------+
PE1 | |
+---------+ IP/MPLS |
+-----+ VID1 p1 | +-----+ | +
| CE1 |------------| FXC | | sv.T1 PE3 +-----+
| | /\ | | |=======+ +----------+ +--| CE3 |
+-----+\ +||---| | | \ | | 1/ | |
VID3\ / ||---| | | \ | +-----+ | / +-----+
\ / /\/ | +-----+ | +=====| FXC |----+
\ / p2 +---------+ | | | | 2 +-----+
/\ | | |----------| CE4 |
/ /\ +---------+ +======| | | | |
/ / \p3 | +-----+ | / | | | | +-----+
VIDs1,2 / +----| FXC | / | | |---+
+-----+ / /\ | | |======+ | +-----+ |\3 +-----+
| CE2 |-----||-----| | | sv.T2 | | \ | CE5 |
| |-----||-----| | | +----------+ +---| |
+-----+ \/ | +-----+ | | +-----+
VIDs3,4 p4 +---------+ |
PE2 | |
N.VID 1,2,3 +------------------+
Figure 2: VLAN-Signaled FXC
図2：VLANシグナルFXC
The failure detection of an EVPN-VPWS service can be performed via OAM mechanisms such as Bidirectional Forwarding Detection (BFD) for the pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5885], and upon such failure detection, the switch over procedure to the backup PE is the same as the one described above.
EVPN-VPWSサービスの故障検出は、擬似方向転送検出（BFD）などのOAMメカニズムを介して実行できます。仮想回路接続検証（VCCV）[RFC5885] [RFC5885]、およびそのような障害検出により、上記のバックアップPEへの手順と同じです。
In the event of an AC failure, the VLAN-Signaled and default FXC modes exhibit distinct behaviors:
AC障害が発生した場合、VLANシグナル付きFXCモードとデフォルトのFXCモードは、異なる動作を示します。
* Default FXC (Figure 1): In the default mode, a VLAN or AC failure is not signaled. Consequently, in case of an AC failure, such as VID1 on CE2, there is nothing to prevent PE3 from directing traffic from CE4 to PE1, leading to a potential packet loss at the egress PE with a failed AC. Application layer OAM may be utilized if per-VLAN fault propagation is necessary in this scenario.
* デフォルトのFXC（図1）：デフォルトモードでは、VLANまたはAC障害はシグナルではありません。その結果、CE2のVID1などのAC障害が発生した場合、PE3がCE4からPE1にトラフィックを向けることを防ぐことは何もありません。このシナリオでVLANごとの障害伝播が必要な場合、アプリケーションレイヤーOAMを利用できます。
* VLAN-Signaled FXC (Figure 2): In the case of a VLAN or AC failure, such as VID1 on CE2, this triggers the withdrawal of the Ethernet A-D per-EVI route for the corresponding Normalized VID, specifically Ethernet-Tag 2. Upon receiving the route withdrawal, PE3 will remove PE1 from its outgoing adjacency list for traffic originating from CE4.
* VLANシグナルFXC（図2）：CE2のVID1などのVLANまたはAC障害の場合、これにより、対応する正規化されたVID、特にイーサネットタグ2のイーサネットA-D PER-EVIルートの引き出しがトリガーされます。
In the event of a PE port failure, the failure will be signaled, and the other PE will assume forwarding in both scenarios:
PEポートの障害が発生した場合、障害は合図され、他のPEは両方のシナリオで転送を想定します。
* Default FXC (Figure 1): In the case of a port failure, such as p2, the route for Service Tunnel 2 (sv.T2) will be withdrawn. Upon receiving the fault notification, PE3 will remove PE1 from its adjacency list for traffic originating from CE4 and CE5.
* デフォルトのFXC（図1）：P2などのポート障害の場合、サービストンネル2（SV.T2）のルートが撤回されます。障害通知を受信すると、PE3はCE4とCE5に由来するトラフィックの隣接リストからPE1を削除します。
* VLAN-Signaled FXC (Figure 2): A port failure, such as p2, triggers the withdrawal of the Ethernet A-D per EVI routes for normalized VIDs 2 and 3, along with the withdrawal of the Ethernet A-D per-ES route for p2's ES. Upon receiving the fault notification, PE3 will remove PE1 from its adjacency list for the traffic originating from CE4 and CE5.
* VLANシグナルFXC（図2）：P2などのポート障害により、正規化されたVIDS 2および3のEVIルートあたりのイーサネットA-Dの引き出しが、P2のESのイーサネットA-D PER-ESルートの引き出しとともにトリガーされます。障害通知を受信すると、PE3はCE4とCE5に由来するトラフィックの隣接リストからPE1を削除します。
In the case of PE node failure, the operation is similar to the steps described above, albeit that EVPN route withdrawals are performed by the route reflector instead of the PE.
PEノードの障害の場合、EVPNルートの引き出しはPEの代わりにルートリフレクターによって実行されるとはいえ、操作は上記の手順に似ています。
Since this document describes a muxing capability that leverages EVPN-VPWS signaling, no additional functionality beyond the muxing service is added, and thus no additional security considerations are needed beyond what is already specified in [RFC8214].
このドキュメントでは、EVPN-VPWSシグナル伝達を活用するマクシング機能について説明しているため、[RFC8214]で既に指定されているものを超えて追加のセキュリティ上の考慮事項は追加されていないため、マクシングサービスを超えた追加の機能は追加されていません。
This document has allocated bits 8-11 in the "EVPN Layer 2 Attributes Control Flags" registry with names M and V:
このドキュメントには、「EVPNレイヤー2属性制御フラグ」レジストリにMとVのレジストリに8〜11が割り当てられています。
M
m
Signaling mode of operation (bits 10-11)
シグナリング動作モード（ビット10-11）
V
v
VLAN-ID normalization (bits 8-9)
VLAN-ID正規化（ビット8-9）
[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>.
[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>.
[BGP-PIC] Bashandy, A., Ed., Filsfils, C., and P. Mohapatra, "BGP
Prefix Independent Convergence", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-bgp-pic-21, 7 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
bgp-pic-21>.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
DOI 10.17487/RFC5659, October 2009,
<https://www.rfc-editor.org/info/rfc5659>.
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", RFC 5885,
DOI 10.17487/RFC5885, June 2010,
<https://www.rfc-editor.org/info/rfc5885>.
[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>.
In addition to the authors listed on the front page, the following coauthors have also contributed substantially to this document:
フロントページにリストされている著者に加えて、次の共著者もこのドキュメントに大きく貢献しています。
Wen Lin
Juniper Networks
Email: wlin@juniper.net
Luc Andre Burdet
Cisco
Email: lburdet@cisco.com
Ali Sajassi (editor)
Cisco Systems
Email: sajassi@cisco.com
Patrice Brissette
Cisco Systems
Email: pbrisset@cisco.com
James Uttaro
Individual
Email: juttaro@ieee.org
John Drake
Independent
Email: je_drake@yahoo.com
Sami Boutros
Ciena
Email: sboutros@ciena.com
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com