Internet Engineering Task Force (IETF) P. Brissette
Request for Comments: 9786 LA. Burdet, Ed.
Category: Standards Track Cisco Systems
ISSN: 2070-1721 B. Wen
Comcast
E. Leyton
Verizon Wireless
J. Rabadan
Nokia
June 2025
The Multi-Chassis Link Aggregation (MC-LAG) group technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The objective of MC-LAG is to enhance both network availability and bandwidth utilization through various modes of traffic load balancing. RFC 7432 defines an EVPN-based MC-LAG with Single-Active and All-Active multihoming redundancy modes. This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new active/standby redundancy mode, called 'Port-Active'.
Multi-Chassis Link Aggregation（MC-Lag）グループテクノロジーにより、独立したノードの冗長グループとの論理リンク凝集接続を確立することができます。MC-Lagの目的は、さまざまなトラフィックロードバランシングモードを通じて、ネットワークの可用性と帯域幅の使用の両方を強化することです。RFC 7432は、単一活性およびオールアクティブなマルチホーム冗長モードを備えたEVPNベースのMC-LAGを定義します。このドキュメントは、EVPNによってサポートされる既存の冗長機構に基づいて構築され、「ポートアクティブ」と呼ばれる新しいアクティブ/スタンバイ冗長モードを導入します。
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/rfc9786.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9786で取得できます。
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. Multi-Chassis Link Aggregation (MC-LAG)
2. Port-Active Redundancy Mode
2.1. Overall Advantages
2.2. Port-Active Redundancy Procedures
3. Designated Forwarder Algorithm to Elect per Port-Active PE
3.1. Capability Flag
3.2. Modulo-Based Algorithm
3.3. Highest Random Weight Algorithm
3.4. Preference-Based DF Election
3.5. AC-Influenced DF Election
4. Convergence Considerations
4.1. Primary/Backup Bits per Ethernet Segment
4.2. Backward Compatibility
5. Applicability
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
EVPN [RFC7432] defines the All-Active and Single-Active redundancy modes. All-Active redundancy provides per-flow load balancing for multihoming, while Single-Active redundancy ensures service carving where only one of the Provider Edge (PE) devices in a redundancy relationship is active per service.
EVPN [RFC7432]は、オールアクティブおよび単一活性の冗長性モードを定義します。オールアクティブな冗長性は、マルチホミングのための流量ごとの負荷分散を提供しますが、単一活動冗長性により、冗長関係にあるプロバイダーエッジ（PE）デバイスの1つだけがサービスごとにアクティブであるサービス彫刻が保証されます。
Although these two multihoming scenarios are widely utilized in data center and service provider access networks, there are cases where active/standby multihoming at the interface level is beneficial and necessary. The primary consideration for this new mode of load balancing is the determinism of traffic forwarding through a specific interface rather than statistical per-flow load balancing across multiple PEs providing multihoming. This determinism is essential for certain QoS features to function correctly. Additionally, this mode ensures fast convergence during failure and recovery, which is expected by customers.
これらの2つのマルチホームシナリオは、データセンターとサービスプロバイダーアクセスネットワークで広く利用されていますが、インターフェイスレベルでアクティブ/スタンバイマルチホームが有益で必要である場合があります。この新しい負荷分散モードの主な考慮事項は、マルチホームを提供する複数のPEにわたって統計的なフローごとの負荷バランスではなく、特定のインターフェイスを介したトラフィック転送の決定論です。この決定論は、特定のQoS機能が正しく機能するために不可欠です。さらに、このモードは、顧客が予想する故障と回復中の速い収束を保証します。
This document defines the Port-Active redundancy mode as a new type of multihoming in EVPN and details how this mode operates and is supported via EVPN.
このドキュメントでは、ポートアクティブな冗長モードをEVPNの新しいタイプのマルチホームとして定義し、このモードが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] で説明されているように解釈されます。
When a Customer Equipment (CE) device is multihomed to a set of PE nodes using the Link Aggregation Control Protocol (LACP) [IEEE_802.1AX_2014], the PEs must function as a single LACP entity for the Ethernet links to form and operate as a Link Aggregation Group (LAG). To achieve this, the PEs connected to the same multihomed CE must synchronize LACP configuration and operational data among them. Historically, the Inter-Chassis Communication Protocol (ICCP) [RFC7275] has been used for this synchronization. EVPN, as described in [RFC7432], covers the scenario where a CE is multihomed to multiple PE nodes, using a LAG to simplify the procedure significantly. However, this simplification comes with certain assumptions:
顧客機器（CE）デバイスが、リンク集約制御プロトコル（LACP）[IEEE_802.1AX_2014]を使用してPEノードのセットにマルチホームされている場合、PESはイーサネットリンクの単一LACPエンティティとして機能し、リンクアグリゲーショングループとして動作する必要があります（LAG）。これを達成するには、同じマルチホームCEに接続されたPESは、それらの間でLACP構成と運用データを同期する必要があります。歴史的に、この同期には、チャシス間通信プロトコル（ICCP）[RFC7275]が使用されてきました。[RFC7432]で説明されているEVPNは、CEが複数のPEノードにマルチホームされているシナリオをカバーし、ラグを使用して手順を大幅に簡素化します。ただし、この単純化には特定の仮定が伴います。
* A CE device connected to EVPN multihoming PEs MUST have a single LAG with all its links connected to the EVPN multihoming PEs in a redundancy group.
* EVPNマルチホームPEに接続されたCEデバイスには、冗長グループのEVPNマルチホームPEに接続されたすべてのリンクを備えた単一の遅延が必要です。
* Identical LACP parameters MUST be configured on peering PEs, including the system ID, port priority, and port key.
* 同一のLACPパラメーターは、システムID、ポートの優先度、ポートキーなど、ピアリングPEで構成する必要があります。
This document presumes proper LAG operation as specified in [RFC7432]. Issues resulting from deviations in the aforementioned assumptions, LAG misconfiguration, and miswiring detection across peering PEs are considered outside the scope of this document.
この文書は、[RFC7432]で指定されている適切な遅延操作を推定します。前述の仮定、ラグの誤解、およびピアリングPE全体での配線検出の逸脱に起因する問題は、このドキュメントの範囲外で考慮されます。
+-----+
| PE3 |
+-----+
+-----------+
| MPLS/IP |
| CORE |
+-----------+
+-----+ +-----+
| PE1 | | PE2 |
+-----+ +-----+
I1 I2
\ /
\ /
\ /
+---+
|CE1|
+---+
Figure 1: MC-LAG Topology
図1：MC-LAGトポロジー
Figure 1 shows an MC-LAG multihoming topology where PE1 and PE2 are part of the same redundancy group providing multihoming to CE1 via interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG running LACP. The core, shown as IP or MPLS enabled, provides a wide range of L2 and L3 services. MC-LAG multihoming functionality is decoupled from those services in the core, and it focuses on providing multihoming to the CE. In Port-Active redundancy mode, only one of the two interfaces, I1 or I2, would be in forwarding, and the other interface would be in standby. This also implies that all services on the active interface operate in active mode and all services on the standby interface operate in standby mode.
図1は、PE1とPE2がインターフェイスI1とI2を介してCE1にマルチホームを提供する同じ冗長グループの一部であるMC-LAGマルチホームトポロジを示しています。インターフェイスI1およびI2は、ランキングラックランディングのメンバーです。IPまたはMPLSの有効化として示されているコアは、幅広いL2およびL3サービスを提供します。MC-LAGマルチホーム機能は、コア内のこれらのサービスから切り離されており、CEにマルチホームを提供することに焦点を当てています。ポートアクティブな冗長性モードでは、2つのインターフェイスの1つ、I1またはI2のみが転送中に、もう1つのインターフェイスはスタンバイになります。これはまた、アクティブインターフェイス上のすべてのサービスがアクティブモードで動作し、スタンバイインターフェイスのすべてのサービスがスタンバイモードで動作することを意味します。
The use of Port-Active redundancy in EVPN networks provides the following benefits:
EVPNネットワークでのポートアクティブな冗長性の使用は、次の利点を提供します。
a. It offers open-standards-based active/standby redundancy at the interface level rather than VLAN granularity [RFC7432].
a. VLAN粒度ではなく、インターフェイスレベルでオープンスタンダードベースのアクティブ/スタンバイ冗長性を提供します[RFC7432]。
b. It eliminates the need for ICCP and LDP [RFC5036] (e.g., Virtual eXtensible Local Area Network (VXLAN) [RFC7348] or Segment Routing over IPv6 (SRv6) [RFC8402] may be used in the network).
b. ICCPとLDP [RFC5036]の必要性を排除します（例：仮想拡張可能なローカルエリアネットワーク（VXLAN）[RFC7348]またはIPv6（SRV6）[RFC8402]を介したセグメントルーティングがネットワークで使用される場合があります。
c. This mode is agnostic of the underlying technology (MPLS, VXLAN, and SRv6) and associated services (Layer 2 (L2), Layer 3 (L3), Bridging, E-LINE, etc.)
c. このモードは、基礎となるテクノロジー（MPLS、VXLAN、およびSRV6）および関連サービス（レイヤー2（L2）、レイヤー3（L3）、ブリッジング、電子ラインなど）の不可知論者です。
d. It enables deterministic QoS over MC-LAG attachment circuits.
d. これにより、MC-Lagアタッチメントサーキットを介した決定論的なQOが可能になります。
e. It is fully compliant with [RFC7432] and does not require any new protocol enhancements to existing EVPN RFCs.
e. [RFC7432]に完全に準拠しており、既存のEVPN RFCに対する新しいプロトコルの強化は必要ありません。
f. It can leverage various Designated Forwarder (DF) election algorithms, such as modulo [RFC7432], Highest Random Weight (HRW) [RFC8584], etc.
f. Modulo [RFC7432]、最高のランダム重量（HRW）[RFC8584]など、さまざまな指定されたフォワーダー（DF）選挙アルゴリズムを活用できます。
g. It replaces legacy MC-LAG ICCP-based solutions and offers the following additional benefits:
g. Legacy MC-Lag ICCPベースのソリューションに取って代わり、次の追加の利点を提供します。
* Efficient support for 1+N redundancy mode (with EVPN using BGP Route Reflector), whereas ICCP requires a full mesh of LDP sessions among PEs in the redundancy group.
* ICCPでは、1+N冗長モード（BGPルートリフレクターを使用したEVPNを使用）の効率的なサポートには、冗長グループのPES間のLDPセッションの完全なメッシュが必要です。
* Fast convergence with mass withdraw is possible with EVPN, which has no equivalent in ICCP.
* EVPNでは、大量撤退を伴う高速収束が可能です。これはICCPでは同等のものではありません。
The following steps outline the proposed procedure for supporting Port-Active redundancy mode with EVPN LAG:
次の手順は、EVPNラグでポートアクティブ冗長モードをサポートするための提案された手順の概要を説明します。
a. The Ethernet Segment Identifier (ESI) MUST be assigned per access interface as described in [RFC7432]. The ESI can be auto-derived or manually assigned, and the access interface MAY be an L2 or L3 interface.
a. [RFC7432]で説明されているように、イーサネットセグメント識別子（ESI）は、アクセスインターフェイスごとに割り当てる必要があります。ESIは自動由来または手動で割り当てられ、アクセスインターフェイスはL2またはL3インターフェイスになる場合があります。
b. The Ethernet Segment (ES) MUST be configured in Port-Active redundancy mode on peering PEs for the specified access interface.
b. イーサネットセグメント（ES）は、指定されたアクセスインターフェイスのPESのピアリングでポートアクティブな冗長モードで構成する必要があります。
c. When ESI is configured on an L3 interface, the ES route (Route Type-4) can be the only route exchanged by PEs in the redundancy group.
c. ESIがL3インターフェイスで構成されている場合、ESルート（ルートタイプ4）は、冗長グループのPESによって交換される唯一のルートになります。
d. PEs in the redundancy group leverage the DF election defined in [RFC8584] to determine which PE keeps the port in active mode and which PE(s) keeps it in standby mode. Although the DF election defined in [RFC8584] is per [ES, Ethernet Tag] granularity, the DF election is performed per [ES] in Port-Active redundancy mode. The details of this algorithm are described in Section 3.
d. 冗長グループのPEは、[RFC8584]で定義されているDF選挙を活用して、どのPEがアクティブモードに保持し、どのPEがスタンバイモードに保つかを決定します。[RFC8584]で定義されているDF選挙は[ES、イーサネットタグ]粒度ごとにありますが、DF選挙はポートアクティブな冗長モードで[ES]ごとに実行されます。このアルゴリズムの詳細については、セクション3で説明します。
e. The DF router MUST keep the corresponding access interface in an up and forwarding active state for that ES.
e. DFルーターは、対応するアクセスインターフェイスをそのESのアクティブ状態をアップおよび転送する必要があります。
f. Non-DF routers SHOULD implement a bidirectional blocking scheme for all traffic comparable to the Single-Active redundancy mode described in [RFC7432], albeit across all VLANs.
f. 非DFルーターは、すべてのVLANではあるが、[RFC7432]で説明されている単一活性冗長モードに匹敵するすべてのトラフィックに双方向ブロッキングスキームを実装する必要があります。
* Non-DF routers MAY bring and keep the peering access interface attached to them in an operational down state.
* 非DFルーターは、操作上のダウン状態でピアリングアクセスインターフェイスを持ち込み、それらに取り付けたままにすることができます。
* If the interface is running the LACP protocol, the non-DF PE MAY set the LACP state to Out of Sync (OOS) instead of setting the interface to a down state. This approach allows for better convergence during the transition from standby to active mode.
* インターフェイスがLACPプロトコルを実行している場合、非DF PEは、インターフェイスをダウン状態に設定する代わりに、LACP状態を同期（OOS）に設定する場合があります。このアプローチにより、スタンバイからアクティブモードへの移行中に、より良い収束が可能になります。
g. The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr) Extended Community [RFC8214] SHOULD be used to achieve better convergence, as described in Section 4.1.
g. EVPNレイヤー2属性（L2-ATTR）拡張コミュニティ[RFC8214]のプライマリ/バックアップビットは、セクション4.1で説明されているように、より良い収束を実現するために使用する必要があります。
The ES routes operating in Port-Active redundancy mode are advertised with the new Port Mode Load-Balancing capability bit in the DF Election Extended Community as defined in [RFC8584]. Additionally, the ES associated with the port utilizes the existing Single-Active procedure and signals the Single-Active multihomed site redundancy mode along with the Ethernet A-D per-ES route (refer to Section 7.5 of [RFC7432]). Finally, The ESI label-based split-horizon procedures specified in Section 8.3 of [RFC7432] SHOULD be employed to prevent transient echo packets when L2 circuits are involved.
[RFC8584]で定義されているように、ポートアクティブ冗長モードで動作するESルートは、DF選挙拡張コミュニティの新しいポートモードの負荷分散機能ビットで宣伝されます。さらに、ポートに関連付けられているESは、既存の単一活性手順を利用し、単一活性マルチホームのサイト冗長モードとイーサネットA-D PER-ESルート（[RFC7432]のセクション7.5を参照）を参照）。最後に、[RFC7432]のセクション8.3で指定されているESIラベルベースのスプリットホリゾン手順を使用して、L2回路が関与している場合に一時的なエコーパケットを防ぐために使用する必要があります。
Various algorithms for DF election are detailed in Sections 3.2 to 3.5 for comprehensive understanding, although the choice of algorithm in this solution does not significantly impact complexity or performance compared to other redundancy modes.
DF選挙のさまざまなアルゴリズムについては、包括的な理解のためにセクション3.2から3.5に詳述されていますが、このソリューションのアルゴリズムの選択は、他の冗長モードと比較して複雑さやパフォーマンスに大きな影響を与えません。
[RFC8584] defines a DF Election Extended Community and a bitmap (2 octets) field to encode "DF Election Capabilities" to use with the DF election algorithm in the DF algorithm field:
[RFC8584]は、DFアルゴリズムフィールドのDF選挙アルゴリズムで使用する「DF選挙能力」をエンコードするDF選挙拡張コミュニティとビットマップ（2オクテット）フィールドを定義します。
Bit 0:
ビット0：
D bit or 'Don't Preempt' bit, as described in [RFC9785].
[RFC9785]に記載されているように、dビットまたは「先制」ビット。
Bit 1:
ビット1：
AC-Influenced DF (AC-DF) election, as described in [RFC8584].
[RFC8584]に記載されているように、ACの影響を受けたDF（AC-DF）選挙。
Bit 3:
ビット3：
Time Synchronization, as described in [RFC9722].
[RFC9722]で説明されているように、時間同期。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |T| |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Amended DF Election Capabilities in the DF Election Extended Community
図2：DF選挙拡張コミュニティにおけるDF選挙能力の修正
This document defines the following value and extends the DF Election Capabilities bitmap field:
このドキュメントは、次の値を定義し、DF選挙能力ビットマップフィールドを拡張します。
Bit 5:
ビット5：
Port Mode Designated Forwarder Election. This bit determines that the DF election algorithm SHOULD be modified to consider the port ES only and not the Ethernet Tags.
ポートモード指定フォワーダー選挙。このビットにより、DF選挙アルゴリズムは、イーサネットタグではなくポートESのみを考慮するように変更する必要があると判断されます。
The default DF election algorithm, or modulo-based algorithm, as described in [RFC7432] and updated by [RFC8584], is applied here at the granularity of ES only. Given that the ES-Import Route Target extended community may be auto-derived and directly inherits its auto-derived value from ESI bytes 1-6, many operators differentiate ESIs primarily within these bytes. Consequently, bytes 3-6 are utilized to determine the designated forwarder using the modulo-based DF assignment, achieving good entropy during modulo calculation across ESIs.
[RFC7432]で説明され、[RFC8584]で更新されたデフォルトのDF選挙アルゴリズム、またはモジュロベースのアルゴリズムは、ESの粒度のみに適用されます。ES-Importルートターゲットの拡張コミュニティが自動由来であり、ESIバイト1〜6から自動由来の値を直接継承する可能性があることを考えると、多くの演算子は主にこれらのバイト内でESIを区別します。したがって、バイト3-6は、ModuloベースのDF割り当てを使用して指定されたフォワーダーを決定するために使用され、ESIS全体のモジュロ計算中に良好なエントロピーを達成します。
Assuming a redundancy group of N PE nodes, the PE with ordinal i is designated as the DF for an <ES> when (Es mod N) = i, where Es represents bytes 3-6 of that ESI.
N PEノードの冗長グループを仮定すると、順序Iを持つPEは、（es mod n）= iの場合のdfとしてDFとして指定されます。ここで、ESはそのESIのバイト3-6を表します。
An application of Highest Random Weight (HRW) to EVPN DF election is defined in [RFC8584], and it MAY be used and signaled. For Port-Active, this is modified to operate at the granularity of <ES> rather than per <ES, VLAN>.
EVPN DF選挙への最高のランダム重量（HRW）の適用は[RFC8584]で定義されており、使用および合図される場合があります。ポートアクティブの場合、これは<es、vlan>ではなく<es>の粒度で動作するように変更されています。
Section 3.2 of [RFC8584] describes computing a 32-bit Cyclic Redundancy Check (CRC) over the concatenation of Ethernet Tag (V) and ESI (Es). For Port-Active redundancy mode, the Ethernet Tag is omitted from the CRC computation and all references to (V, Es) are replaced by (Es).
[RFC8584]のセクション3.2は、イーサネットタグ（V）とESI（ES）の連結に関する32ビット環状冗長チェック（CRC）の計算について説明しています。ポートアクティブな冗長モードの場合、イーサネットタグはCRC計算から省略され、（v、es）へのすべての参照はes）に置き換えられます。
The algorithm used to determine the DF and Backup Designated Forwarder (BDF) per Section 3.2 of [RFC8584] is repeated and summarized below using only (Es) in the computation:
[RFC8584]のセクション3.2ごとにDFとバックアップ指定フォワーダー（BDF）を決定するために使用されるアルゴリズムを繰り返し、計算で以下に要約します。
1. DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. In the case of a tie, choose the PE whose IP address is numerically the least. Note that 0 <= i,j < number of PEs in the redundancy group.
1. df（es）= si |重量（es、si）> = weight（es、sj）、すべてのj。ネクタイの場合、IPアドレスが数値的に最も少ないPEを選択します。0 <= i、j <冗長グループのPESの数に注意してください。
2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es, Sk) >= Weight(Es, Sj). In the case of a tie, choose the PE whose IP address is numerically the least.
2. bdf（es）= sk |重量（es、si）> = weight（es、sk）、およびweight（es、sk）> = weight（es、sj）。ネクタイの場合、IPアドレスが数値的に最も少ないPEを選択します。
Where:
ただし：
* DF(Es) is defined to be the address Si (index i) for which Weight(Es, Si) is the highest; 0 <= i < N-1.
* DF（ES）は、重量（ES、SI）が最も高いアドレスSI（インデックスI）であると定義されています。0 <= i <n-1。
* BDF(Es) is defined as that PE with address Sk for which the computed Weight is the next highest after the Weight of the DF. j is the running index from 0 to N-1; i and k are selected values.
* BDF（ES）は、計算された重量がDFの重量後に次に高くなるアドレスSKを使用したPEとして定義されます。jは0からn-1の実行インデックスです。IとKは選択された値です。
When the new capability 'Port Mode' is signaled, the preference-based DF election algorithm [RFC9785] is modified to consider the port only and not any associated Ethernet Tags. The Port Mode capability is compatible with the 'Don't Preempt' bit and both may be signaled. When an interface recovers, a peering PE signaling the D bit enables non-revertive behavior at the port level.
新しい機能「ポートモード」が通知されると、優先ベースのDF選挙アルゴリズム[RFC9785]が変更され、関連するイーサネットタグではなくポートのみを考慮するように変更されます。ポートモード機能は「先制しない」ビットと互換性があり、両方が信号を受けることができます。インターフェイスが回復すると、dビットを信号するピアリングPEは、ポートレベルで非反対の動作を可能にします。
The AC-DF bit defined in [RFC8584] MUST be set to 0 when advertising Port Mode Designated Forwarder Election capability (P=1). When an AC (sub-interface) goes down, any resulting Ethernet A-D per EVI withdrawal does not influence the DF election.
[RFC8584]で定義されているAC-DFビットは、ポートモードが指定されたフォワーダー選挙能力（P = 1）を広告する場合、0に設定する必要があります。AC（サブインターフェイス）がダウンすると、結果として生じるEVI撤退あたりのイーサネットA-Dは、DF選挙に影響を与えません。
Upon receiving the AC-DF bit set (A=1) from a remote PE, it MUST be ignored when performing Port Mode Designated Forwarder Election.
リモートPEからAC-DFビットセット（a = 1）を受信すると、ポートモードが指定されたフォワーダー選挙を実行するときは無視する必要があります。
To enhance convergence during failure and recovery when the Port-Active redundancy mode is employed, prior synchronization between peering PEs may be beneficial.
ポートアクティブな冗長モードが採用されている場合、故障と回復中の収束を強化するために、ピアリングPE間の事前の同期が有益です。
The Port-Active mode poses a challenge to synchronization since the "standby" port may be in a down state. Transitioning a "standby" port to an up state and stabilizing the network requires time. For Integrated Routing and Bridging (IRB) and L3 services, prior synchronization of ARP / Neighbor Discovery (ND) caches is recommended. Additionally, associated Virtual Routing and Forwarding (VRF) tables may need to be synchronized. For L2 services, synchronization of MAC tables may be considered.
「スタンバイ」ポートはダウン状態にある可能性があるため、ポートアクティブモードは同期するのに挑戦します。「スタンバイ」ポートをUP状態に移行し、ネットワークを安定させるには時間がかかります。統合されたルーティングとブリッジング（IRB）およびL3サービスには、ARP / Neighbor Discovery（ND）キャッシュの事前の同期をお勧めします。さらに、関連する仮想ルーティングと転送（VRF）テーブルを同期する必要がある場合があります。L2サービスの場合、MACテーブルの同期を考慮することができます。
Moreover, for members of a LAG running LACP, the ability to set the "standby" port to an "out-of-sync" state, also known as "warm-standby," can be utilized to improve convergence times.
さらに、ランニングLACPのメンバーの場合、「Standby」ポートを「Syncからの」状態（「Warm-Standby」とも呼ばれる」状態に設定する機能を利用して、収束時間を改善することができます。
The EVPN L2-Attr Extended Community defined in [RFC8214] SHOULD be advertised in the Ethernet A-D per ES route to enable fast convergence.
[RFC8214]で定義されているEVPN L2-ATTR拡張コミュニティは、速い収束を有効にするために、ES RORTEごとにイーサネットA-Dで宣伝する必要があります。
Only the P and B bits of the Control Flags field in the L2-Attr Extended Community are relevant to this document, specifically in the context of Ethernet A-D per ES routes:
L2-ATTR拡張コミュニティのコントロールフラグフィールドのPおよびBビットのみが、特にESルートごとのイーサネットA-Dのコンテキストで、このドキュメントに関連しています。
* When advertised, the L2-Attr Extended Community SHALL have only the P or B bits set in the Control Flags field, and all other bits and fields MUST be zero.
* 宣伝すると、L2-ATTR拡張コミュニティは、制御フラグフィールドに設定されたPまたはBビットのみを持つものとし、他のすべてのビットとフィールドはゼロでなければなりません。
* A remote PE receiving the optional L2-Attr Extended Community in Ethernet A-D per ES routes SHALL consider only the P and B bits and ignore other values.
* ESルートごとにイーサネットA-DでオプションのL2-ATTR拡張コミュニティを受信するリモートPEは、PおよびBビットのみを考慮し、他の値を無視するものとします。
For the L2-Attr Extended Community sent and received in Ethernet A-D per EVI routes used in [RFC8214], [RFC7432], and [RFC9744]:
[RFC8214]、[RFC7432]、および[RFC9744]で使用されているEVIルートごとにイーサネットA-Dで送信および受信されたL2-ATTR拡張コミュニティについて：
* P and B bits received SHOULD be considered overridden by "parent" bits when advertised in the Ethernet A-D per ES.
* 受信したPおよびBビットは、ESあたりのイーサネットA-Dで宣伝された場合、「親」ビットによってオーバーライドされると見なす必要があります。
* Other fields and bits of the extended community are used according to the procedures outlined in the referenced documents.
* 参照されたドキュメントに概説されている手順に従って、拡張コミュニティの他のフィールドとビットが使用されます。
By adhering to these procedures, the network ensures proper handling of the L2-Attr Extended Community to maintain robust and efficient convergence across Ethernet Segments.
これらの手順を順守することにより、ネットワークはL2-ATTR拡張コミュニティの適切な取り扱いを保証し、イーサネットセグメント間の堅牢で効率的な収束を維持します。
Implementations that comply with [RFC7432] or [RFC8214] only (i.e., implementations that predate this specification) and that receive an L2-Attr Extended Community in Ethernet A-D per ES routes will ignore it and continue to use the default path resolution algorithms of the two specifications above:
[RFC7432]または[RFC8214]のみに準拠している実装（つまり、この仕様より前の実装）、およびESルートごとのイーサネットA-DでL2-ATTR拡張コミュニティを受け取ることは、それを無視し、上記の2つの仕様のデフォルトパス解像度アルゴリズムを使用し続けます。
* The L2-Attr Extended Community in Ethernet A-D per ES route is ignored.
* ESERNET A-DごとのルートのL2-ATTR拡張コミュニティは無視されます。
* The remote ESI Label Extended Community [RFC7432] signals the Single-Active redundancy mode (Section 3).
* リモートESIラベル拡張コミュニティ[RFC7432]は、単一活性冗長モード（セクション3）をシグナルにします。
* The remote Media Access Control (MAC) and/or Ethernet A-D per EVI routes are unchanged; the P and B bits in the L2-Attr Extended Community in Ethernet A-D per EVI routes are used.
* EVIルートごとのリモートメディアアクセスコントロール（MAC）および/またはイーサネットA-Dは変更されていません。L2-ATTR拡張コミュニティのPおよびBビットは、EVIルートごとにイーサネットA-Dのコミュニティを使用します。
A prevalent deployment scenario involves providing L2 or L3 services on PE devices that offer multihoming capabilities. The services may include any L2 EVPN solutions such as EVPN Virtual Private Wire Service (VPWS) or standard EVPN as defined in [RFC7432]. Additionally, L3 services may be provided within a VPN context, as specified in [RFC4364], or within a global routing context. When a PE provides first-hop routing, EVPN IRB may also be deployed on the PEs. The mechanism outlined in this document applies to PEs providing L2 and/or L3 services where active/standby redundancy at the interface level is required.
一般的な展開シナリオには、多目的機能を提供するPEデバイスでL2またはL3サービスを提供することが含まれます。このサービスには、[RFC7432]で定義されているように、EVPN仮想プライベートワイヤサービス（VPWS）や標準EVPNなどのL2 EVPNソリューションが含まれます。さらに、[RFC4364]で指定されているように、L3サービスはVPNコンテキスト内またはグローバルルーティングコンテキスト内で提供される場合があります。PEが最初のホップルーティングを提供する場合、EVPN IRBもPESに展開される場合があります。このドキュメントで概説されているメカニズムは、インターフェイスレベルでのアクティブ/スタンバイ冗長性が必要なL2および/またはL3サービスを提供するPESに適用されます。
An alternative solution to the one described in this document is MC-LAG with ICCP active/standby redundancy, as detailed in [RFC7275]. However, ICCP requires LDP to be enabled as a transport for ICCP messages. There are numerous scenarios where LDP is not necessary, such as deployments utilizing VXLAN or SRv6. The solution using EVPN, as described in this document, does not mandate the use of LDP or ICCP and remains independent of the underlay encapsulation.
[RFC7275]で詳述されているように、このドキュメントで説明されているものに対する代替ソリューションは、ICCPアクティブ/スタンバイ冗長性を備えたMC-LAGです。ただし、ICCPでは、LDPをICCPメッセージのトランスポートとして有効にする必要があります。VXLANやSRV6を使用して展開など、LDPが必要ない多くのシナリオがあります。このドキュメントに記載されているように、EVPNを使用したソリューションは、LDPまたはICCPの使用を義務付けるものではなく、アンダーレイのカプセル化とは無関係のままです。
Per this document, IANA has added the following entry to the "DF Election Capabilities" registry under the "Border Gateway Protocol (BGP) Extended Communities" registry group:
このドキュメントによると、IANAは「Border Gateway Protocol（BGP）拡張コミュニティ」レジストリグループの下に「DF選挙能力」レジストリに次のエントリを追加しました。
+=====+=========================================+===========+
| Bit | Name | Reference |
+=====+=========================================+===========+
| 5 | Port Mode Designated Forwarder Election | RFC 9786 |
+-----+-----------------------------------------+-----------+
Table 1
The security considerations described in [RFC7432] and [RFC8584] are applicable to this document.
[RFC7432]および[RFC8584]で説明されているセキュリティ上の考慮事項は、このドキュメントに適用されます。
Introducing a new capability necessitates unanimity among PEs. Without consensus on the new DF election procedures and Port Mode, the DF election algorithm defaults to the procedures outlined in [RFC8584] and [RFC7432].This fallback behavior could be exploited by an attacker who modifies the configuration of one PE within the ES. Such manipulation could force all PEs in the ES to revert to the default DF election algorithm and capabilities. In this scenario, the PEs may be subject to unfair load balancing, service disruption, and potential issues such as traffic loss or duplicate traffic, as mentioned in the security sections of those documents.
新しい機能を導入するには、PES間の全会一致が必要です。新しいDF選挙手続きとポートモードに関するコンセンサスがなければ、DF選挙アルゴリズムは[RFC8584]および[RFC7432]で概説されている手順をデフォルトします。このような操作により、ES内のすべてのPEがデフォルトのDF選挙アルゴリズムと機能に戻るように強制する可能性があります。このシナリオでは、PESは、これらのドキュメントのセキュリティセクションに記載されているように、不公平な負荷分散、サービスの混乱、トラフィックの損失やトラフィックの重複などの潜在的な問題の対象となる場合があります。
[IEEE_802.1AX_2014]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Link Aggregation", IEEE 802-1ax-2014,
DOI 10.1109/IEEESTD.2014.7055197, 5 March 2015,
<https://ieeexplore.ieee.org/document/7055197>.
[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>.
[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>.
[RFC9722] Brissette, P., Sajassi, A., Burdet, LA., Ed., Drake, J.,
and J. Rabadan, "Fast Recovery for EVPN Designated
Forwarder Election", RFC 9722, DOI 10.17487/RFC9722, May
2025, <https://www.rfc-editor.org/info/rfc9722>.
[RFC9785] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and
A. Sajassi, "Preference-Based EVPN Designated Forwarder
(DF) Election", RFC RFC9785, DOI 10.17487/RFC9785, June
2025, <https://www.rfc-editor.org/info/rfc9785>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M.,
Matsushima, S., and T. Nadeau, "Inter-Chassis
Communication Protocol for Layer 2 Virtual Private Network
(L2VPN) Provider Edge (PE) Redundancy", RFC 7275,
DOI 10.17487/RFC7275, June 2014,
<https://www.rfc-editor.org/info/rfc7275>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC9744] Sajassi, A., Ed., Brissette, P., Uttaro, J., Drake, J.,
Boutros, S., and J. Rabadan, "EVPN Virtual Private Wire
Service (VPWS) Flexible Cross-Connect (FXC) Service",
RFC 9744, DOI 10.17487/RFC9744, March 2025,
<https://www.rfc-editor.org/info/rfc9744>.
The authors thank Anoop Ghanwani for his comments and suggestions and Stephane Litkowski and Gunter Van de Velde for their careful reviews.
著者は、彼のコメントと提案をしてくれたAnoop Ghanwaniに感謝し、Stephane LitkowskiとGunter Van de Veldeの慎重なレビューをしてくれました。
In addition to the authors listed on the front page, the following people have also contributed to this document:
フロントページにリストされている著者に加えて、次の人々もこの文書に貢献しています。
Ali Sajassi
Cisco Systems
United States of America
Email: sajassi@cisco.com
Samir Thoria
Cisco Systems
United States of America
Email: sthoria@cisco.com
Patrice Brissette
Cisco Systems
Ottawa ON
Canada
Email: pbrisset@cisco.com
Luc André Burdet (editor)
Cisco Systems
Canada
Email: lburdet@cisco.com
Bin Wen
Comcast
United States of America
Email: Bin_Wen@comcast.com
Edward Leyton
Verizon Wireless
United States of America
Email: edward.leyton@verizonwireless.com
Jorge Rabadan
Nokia
United States of America
Email: jorge.rabadan@nokia.com