Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9785 S. Sathappan
Updates: 8584 Nokia
Category: Standards Track W. Lin
ISSN: 2070-1721 Juniper Networks
J. Drake
Independent
A. Sajassi
Cisco Systems
June 2025
The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPNs) is defined as the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device/network in the case of an All-Active multihoming Ethernet Segment (ES) or BUM and unicast in the case of Single-Active multihoming. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the default DF election algorithm. While the default algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more "deterministic" and user-controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE.
イーサネット仮想プライベートネットワーク（EVPNS）の指定された転送者（DF）は、放送、不明なユニキャスト、およびマルチホーム（BUM）トラフィックをマルチホーム/ネットワークに送信するプロバイダーエッジ（PE）ルーターとして定義されます。指定されたフォワーダーは、デフォルトのDF選挙アルゴリズムに従って、同じイーサネットセグメント識別子（ESI）をEVPNネットワークに宣伝するPESの候補リストから選択されます。デフォルトのアルゴリズムは、イーサネットセグメントの異なるイーサネットタグにわたって指定されたフォワーダーを選択する効率的かつ自動化された方法を提供しますが、より「決定論的」およびユーザー制御された方法が必要なユースケースがいくつかあります。同時に、ネットワークオペレーターは、既存の指定されたフォワーダーでいくつかのメンテナンスタスクを実行するか、新しいアクティブPEが既存の指定されたフォワーダーPEを先取りできるかどうかを制御するために、オンデマンド指定されたフォワーダースイッチオーバーを強制する簡単な方法を必要とします。
This document proposes use of a DF election algorithm that meets the requirements of determinism and operation control. This document updates RFC 8584 by modifying the definition of the DF Election Extended Community.
この文書は、決定論と運用管理の要件を満たすDF選挙アルゴリズムの使用を提案しています。このドキュメントは、DF選挙拡張コミュニティの定義を変更することにより、RFC 8584を更新します。
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/rfc9785.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9785で取得できます。
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. Problem Statement
1.2. Solution Requirements
1.3. Solution Overview
2. Requirements Language and Terminology
3. EVPN BGP Attribute Extensions
4. Solution Description
4.1. Use of the Highest-Preference and Lowest-Preference
Algorithm
4.2. Use of the Highest-Preference or Lowest-Preference
Algorithm in Ethernet Segments
4.3. The Non-Revertive Capability
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
[RFC7432] defines the Designated Forwarder (DF) in EVPN networks as the PE responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device/network in the case of an All-Active multihoming Ethernet Segment or BUM and unicast traffic to a multihomed device or network in the case of Single-Active multihoming. The Designated Forwarder is selected out of a candidate list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network and according to the DF election algorithm or to DF Alg as per [RFC8584].
[RFC7432]は、EVPNネットワークの指定されたフォワーダー（DF）を、放送、不明なユニキャスト、およびマルチリキャスト（バム）トラフィックをマルチホームデバイス/ネットワークに送信する責任があるPEとして定義します。指定されたフォワーダーは、EVPNネットワークにイーサネットセグメント識別子（ESI）を宣伝するPESの候補リストから選択され、[RFC8584]に従ってDF選挙アルゴリズムまたはDF ALGに従って選択されます。
While the default DF algorithm or the Highest Random Weight (HRW) algorithm [RFC8584] provide an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more user-controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE.
デフォルトのDFアルゴリズムまたは最高のランダム重量（HRW）アルゴリズム[RFC8584]は、イーサネットセグメントの異なるイーサネットタグにわたって指定された転送業者を選択する効率的かつ自動化された方法を提供しますが、よりユーザー制御メソッドが必要なユースケースが必要です。同時に、ネットワークオペレーターは、既存の指定されたフォワーダーでいくつかのメンテナンスタスクを実行するか、新しいアクティブPEが既存の指定されたフォワーダーPEを先取りできるかどうかを制御するために、オンデマンド指定されたフォワーダースイッチオーバーを強制する簡単な方法を必要とします。
The procedures described in this document meet the following requirements:
このドキュメントで説明されている手順は、次の要件を満たしています。
a. The solution provides an administrative preference option so that the user can control in what order the candidate PEs may become the Designated Forwarder, assuming they are all operationally ready to take over as the Designated Forwarder. The operator can determine whether the Highest-Preference or Lowest-Preference PE among the PEs in the Ethernet Segment will be elected as the Designated Forwarder, based on the DF algorithms described in this document.
a. このソリューションは、管理者が指定されたフォワーダーになる可能性のある候補PESがすべて操作的に準備ができていると仮定して、ユーザーが指定されたフォワーダーになる可能性のある順序でユーザーが制御できるように、管理優先オプションを提供します。オペレーターは、このドキュメントで説明されているDFアルゴリズムに基づいて、イーサネットセグメントのPES間のPES間のPEの中で最も高いプレファレンスまたは最も低いPEが指定されたフォワーダーとして選出されるかどうかを判断できます。
b. The extensions described in this document work for Ethernet Segments [RFC7432] and virtual Ethernet Segments as defined in [RFC9784].
b. このドキュメントで説明されている拡張機能は、[RFC9784]で定義されているイーサネットセグメント[RFC7432]および仮想イーサネットセグメントについて機能します。
c. The user may force a PE to preempt the existing Designated Forwarder for a given Ethernet Tag without reconfiguring all the PEs in the Ethernet Segment, by simply modifying the existing administrative preference in that PE.
c. ユーザーは、そのPEの既存の管理選好を単に変更することにより、イーサネットセグメント内のすべてのPEを再構成することなく、特定のイーサネットタグの既存の指定されたフォワーダーを特定のイーサネットタグの既存の指定転送業者に強制することができます。
d. The solution allows an option to NOT preempt the current Designated Forwarder (the "Don't Preempt" Capability), even if the former Designated Forwarder PE comes back up after a failure. This is also known as "non-revertive" behavior, as opposed to the DF election procedures [RFC7432] that are always revertive (because the winner PE of the default DF election algorithm always takes over as the operational Designated Forwarder).
d. このソリューションにより、前者の指定されたフォワーダーPEが障害後に戻ってきた場合でも、現在の指定されたフォワーダー（「プリエンプトしない」機能）を先取りしないオプションが許可されます。これは、常に戻るDF選挙手続き[RFC7432]とは対照的に、「非反論」行動としても知られています（デフォルトのDF選挙アルゴリズムの受賞者が常に運用上のフォワーダーとして引き継ぐため）。
e. The procedures described in this document support Single-Active and All-Active multihoming Ethernet Segments.
e. このドキュメントで説明されている手順は、単一活性およびオールアクティブなマルチホームイーサネットセグメントをサポートしています。
To provide a solution that satisfies the above requirements, we introduce two new DF algorithms that can be advertised in the DF Election Extended Community (Section 3). Carried with the new DF Election Extended Community variants is a DF election preference advertised for each PE that influences which PE will become the DF (Section 4.1). The advertised DF election preference can dynamically vary from the administratively configured preference to provide non-revertive behavior (Section 4.3). In Section 4.2, an optional solution is discussed for use in Ethernet Segments that supports large numbers of Ethernet Tags and therefore needs to balance load among multiple DFs.
上記の要件を満たすソリューションを提供するために、DF選挙拡張コミュニティ（セクション3）で宣伝できる2つの新しいDFアルゴリズムを紹介します。新しいDF選挙で運ばれる拡張コミュニティバリアントは、PEがDFになることに影響する各PEに対して宣伝されているDF選挙の好みです（セクション4.1）。宣伝されているDF選挙の選好は、再ververtive的な行動を提供するために、管理上構成された選好と動的に異なる場合があります（セクション4.3）。セクション4.2では、多数のイーサネットタグをサポートするイーサネットセグメントで使用するためのオプションのソリューションについて説明します。
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] で説明されているように解釈されます。
AC:
AC:
Attachment Circuit. An AC has an Ethernet Tag associated to it.
アタッチメント回路。ACには、それに関連付けられたイーサネットタグがあります。
CE:
CE:
Customer Equipment router
顧客機器ルーター
DF:
DF:
Designated Forwarder
指定されたフォワーダー
DF Alg:
DFアルグ：
Refers to the DF election algorithm, which is sometimes shortened to "Alg" in this document.
DF選挙アルゴリズムを指します。これは、このドキュメントの「アルグ」に短縮されることがあります。
DP:
DP:
Refers to the "Don't Preempt" Capability in the DF Election Extended Community.
DF選挙拡張コミュニティの「先制しない」能力を指します。
ENNI:
エニ：
External Network-Network Interface
外部ネットワークネットワークインターフェイス
ES and vES:
esとves：
Ethernet Segment and virtual Ethernet Segment.
イーサネットセグメントと仮想イーサネットセグメント。
Ethernet A-D per EVI route:
EVIルートごとのイーサネットA-D：
Refers to Route Type 1 or Auto-Discovery per EVPN Instance route [RFC7432].
EVPNインスタンスルートあたりのタイプ1または自動発見を指します[RFC7432]。
EVC:
EVC:
Ethernet Virtual Circuit
イーサネット仮想回路
EVI:
EVI:
EVPN Instance
EVPNインスタンス
Ethernet Tag:
イーサネットタグ：
Used to represent a broadcast domain that is configured on a given Ethernet Segment for the purpose of DF election. Note that any of the following may be used to represent a broadcast domain: VLAN IDs (VIDs) (including Q-in-Q tags), configured IDs, VXLAN Network Identifiers (VNIs), normalized VIDs, Service Instance Identifiers (I-SIDs), etc., as long as the representation of the broadcast domains is configured consistently across the multihomed PEs attached to that Ethernet Segment. The Ethernet Tag value MUST NOT be zero.
DF選挙の目的で特定のイーサネットセグメントで構成されているブロードキャストドメインを表すために使用されます。以下のいずれかを、ブロードキャストドメインを表すために使用できることに注意してください：VLAN IDS（VIDS）（Q-in-Qタグを含む）、構成されたIDS、VXLANネットワーク識別子（VNI）、正規化されたVIDS、サービスインスタンス識別子（I-SID）などは、ブロードキャストドメインの表現がマルチオンペスを介して一貫して構成されています。イーサネットのタグ値はゼロではありません。
HRW:
HRW:
Highest Random Weight, as per [RFC8584].
[RFC8584]に従って、最高のランダム重量。
OAM:
OAM:
Operations, Administration, and Maintenance.
運用、管理、およびメンテナンス。
This solution reuses and extends the DF Election Extended Community defined in [RFC8584] that is advertised along with the Ethernet Segment route. It does so by replacing the last two reserved octets of the DF Election Extended Community when the DF algorithm is set to Highest-Preference or Lowest-Preference. This document also defines a new capability referred to as the "Don't Preempt" Capability, which MAY be used with Highest-Preference or Lowest-Preference Algorithms. The format of the DF Election Extended Community used in this document is as follows:
このソリューションは、イーサネットセグメントルートとともに宣伝されている[RFC8584]で定義されたDF選挙拡張コミュニティを再利用および拡張します。これは、DFアルゴリズムが最高予防または最も低いプレファーに設定されたときに、DF選挙の拡張コミュニティの最後の2つの予約されたオクテットを置き換えることで行います。このドキュメントでは、「先制しない」機能と呼ばれる新しい機能を定義します。これは、最高のプレファレンスまたは最も低いプレファレンスアルゴリズムで使用される場合があります。このドキュメントで使用されているDF選挙拡張コミュニティの形式は次のとおりです。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap | Reserved | DF Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DF Election Extended Community
図1：DF選挙拡張コミュニティ
Where the above fields are defined as follows:
上記のフィールドは次のように定義されています。
* The DF algorithm can have the following values:
* DFアルゴリズムには、次の値を持つことができます。
- Alg 0 - Default DF election algorithm, i.e., the modulus-based algorithm as per [RFC7432].
- アルグ0-デフォルトのDF選挙アルゴリズム、つまり[RFC7432]に従ってモジュラスベースのアルゴリズム。
- Alg 1 - HRW algorithm as per [RFC8584].
- alg 1 -HRWアルゴリズム[RFC8584]に従って。
- Alg 2 - Highest-Preference Algorithm (Section 4.1).
- ALG 2-最高予防アルゴリズム（セクション4.1）。
- Alg 3 - Lowest-Preference Algorithm (Section 4.1).
- アルグ3-最低プレファレンスアルゴリズム（セクション4.1）。
* Bitmap (2 octets) encodes "capabilities" [RFC8584], whereas this document defines the "Don't Preempt" Capability, which is used to indicate if a PE supports a non-revertive behavior:
* BitMap（2オクテット）は「機能」[RFC8584]をエンコードしますが、このドキュメントは「先制しない」機能を定義します。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Bitmap Field in the DF Election Extended Community
図2：DF選挙の拡張コミュニティのビットマップフィールド
- Bit 0 (corresponds to Bit 24 of the DF Election Extended Community, and it is defined by this document): The D bit, or "Don't Preempt" Capability, determines if the PE advertising the Ethernet Segment route requests the remote PEs in the Ethernet Segment to not preempt it as the Designated Forwarder. The default value is DP=0, which is compatible with the 'preempt' or 'revertive' behavior in the default DF algorithm [RFC7432]. The "Don't Preempt" Capability is supported by the Highest-Preference or Lowest-Preference Algorithms. The procedures of the "Don't Preempt" Capability for other DF algorithms are out of the scope of this document. The procedures of the "Don't Preempt" Capability for the Highest-Preference and Lowest-Preference Algorithms are described in Section 4.1.
- ビット0（DF選挙拡張コミュニティのビット24に対応し、このドキュメントで定義されています）：Dビット、または「先制」機能は、イーサネットセグメントルートを広告するPEがイーサネットセグメントのリモートPEを要求して、指定されたフォワーダーとして先制しないかどうかを判断します。デフォルト値はdp = 0であり、これはデフォルトのDFアルゴリズム[RFC7432]の「先制」または「リバート」動作と互換性があります。「先制」機能は、最高予防または最も低いプレファレンスアルゴリズムによってサポートされています。他のDFアルゴリズムの「先制」機能の手順は、このドキュメントの範囲外です。最も高いプレファレンスおよび最も低いプレファレンスアルゴリズムの「先制」機能の手順については、セクション4.1で説明します。
- Bit 1: AC-Influenced DF (AC-DF) election is described in [RFC8584]. When set to 1, it indicates the desire to use AC-DF with the rest of the PEs in the Ethernet Segment. The AC-DF capability bit MAY be set along with the "Don't Preempt" Capability and Highest-Preference or Lowest-Preference Algorithms.
- ビット1：AC影響を受けたDF（AC-DF）選挙は[RFC8584]に記載されています。1に設定すると、イーサネットセグメントのPESの残りの部分を使用してAC-DFを使用したいという要望を示します。AC-DF機能ビットは、「先制しない」機能と最高のプレファレンスまたは最も低いプレファレンスアルゴリズムとともに設定できます。
* Designated Forwarder (DF) Preference: Defines a 2-octet value that indicates the PE preference to become the Designated Forwarder in the Ethernet Segment, as described in Section 4.1. The allowed values are within the range 0-65535, and the default value MUST be 32767. This value is the midpoint in the allowed Preference range of values, which gives the operator the flexibility of choosing a significant number of values, above or below the default Preference. A numerically higher or lower value of this field is more preferred for DF election depending on the DF algorithm being used, as explained in Section 4.1. The Designated Forwarder Preference field is specific to Highest-Preference and Lowest-Preference Algorithms, and this document does not define any meaning for other algorithms. If the DF algorithm is different from Highest-Preference or Lowest-Preference, these 2 octets can be encoded differently.
* 指定されたフォワーダー（DF）優先：セクション4.1で説明されているように、イーサネットセグメントの指定されたフォワーダーになるPEの優先度を示す2オクターテット値を定義します。許可された値は0-65535の範囲内で、デフォルト値は32767でなければなりません。この値は、許可された値の嗜好範囲の中間点であり、オペレーターがデフォルトの好みを上または下回るかなりの数の値を選択する柔軟性を提供します。セクション4.1で説明されているように、このフィールドの数値的に高い値または低い値は、使用されているDFアルゴリズムに応じて、DF選挙でより好まれます。指定されたフォワーダー選好フィールドは、最高予防と最低プレファレンスアルゴリズムに固有のものであり、このドキュメントは他のアルゴリズムの意味を定義しません。DFアルゴリズムが最も高いプレファレンスまたは最も低いプレファレンスとは異なる場合、これらの2つのオクテットは異なる方法でエンコードできます。
* RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to 47): When the DF algorithm is set to Highest-Preference or Lowest-Preference, the values are set to zero when advertising the Ethernet Segment route, and they are ignored when receiving the Ethernet Segment route.
* RSVおよび予約済みフィールド（ビット16からビット18、ビット40から47まで）：DFアルゴリズムが最高予防または最も低いプレファレンスに設定されている場合、イーサネットセグメントルートを宣伝するときに値がゼロに設定され、イーサネットセグメントルートを受信するときに無視されます。
Figure 3 illustrates an example that will be used in the description of the solution.
図3は、ソリューションの説明で使用される例を示しています。
EVPN Network
+-------------------+
| +-------+ ENNI Aggregation
| <---ESI1,500 | PE1 | /\ +----Network---+
| <-----ESI2,100 | |===||=== |
| | |===||== \ vES1 | +----+
+-----+ | | \/ |\----------------+CE1 |
CE3--+ PE4 | +-------+ | \ ------------+ |
+-----+ | | \ / | +----+
| | | X |
| <---ESI1,255 +-----+============ \ |
| <-----ESI2,200 | PE2 |========== \ vES2 | +----+
| +-----+ | \ ----------+CE2 |
| | | --------------+ |
| +-----+ ----------------------+ |
| <-----ESI2,300 | PE3 +--/ | | +----+
| +-----+ +--------------+
--------------------+
Figure 3: Preference-Based DF Election
図3：優先ベースのDF選挙
Figure 3 shows three PEs that are connecting EVCs coming from the Aggregation Network to their EVIs in the EVPN network. CE1 is connected to vES1, which spans PE1 and PE2, and CE2 is connected to vES2, which is attached to PE1, PE2, and PE3.
図3は、集約ネットワークからEVPNネットワークのEVIに届くEVCを接続している3つのPESを示しています。Ce1はPE1とPE2に及ぶVES1に接続され、Ce2はPE1、PE2、およびPE3に接続されているVes2に接続されています。
If the algorithm chosen for vES1 and vES2 is the Highest-Preference or Lowest-Preference Algorithm, the PEs may become the Designated Forwarder irrespective of their IP address and based on the administrative preference value. The following sections provide some examples of the procedures and how they are applied in the use case of Figure 3.
VES1およびVES2に選択されたアルゴリズムが最も高いプレープレーションまたは最も低いプレファレンスアルゴリズムである場合、PESはIPアドレスに関係なく指定された転送業者になり、管理選好値に基づいています。次のセクションでは、手順のいくつかの例と、それらが図3のユースケースでどのように適用されるかを示します。
Assuming the operator wants to control -- in a flexible way -- what PE becomes the Designated Forwarder for a given virtual Ethernet Segment and the order in which the PEs become a Designated Forwarder in case of multiple failures, the Highest-Preference or Lowest-Preference Algorithms can be used. Per the example in Figure 3, these algorithms are used as follows:
オペレーターが、柔軟な方法で、PEが特定の仮想イーサネットセグメントの指定された転送業者になるものと、PESが複数の障害の場合に指定されたフォワーダーになる順序を制御したいと仮定すると、最も高いプレファレンスまたは最低プレファレンスアルゴリズムを使用できます。図3の例によると、これらのアルゴリズムは次のように使用されます。
a. vES1 and vES2 are now configurable with three optional parameters that are signaled in the DF Election Extended Community. These parameters are the Preference, Preemption (or "Don't Preempt" Capability) option, and DF algorithm. We will represent these parameters as (Pref, DP, Alg). For instance, vES1 (Pref, DP, Alg) is configured as:
a. VES1とVES2は、DF選挙拡張コミュニティで通知される3つのオプションパラメーターで構成可能になりました。これらのパラメーターは、好み、プリエンプション（または「プリエンプション機能」機能」オプション、およびDFアルゴリズムです。これらのパラメーターを（Pref、DP、ALG）として表します。たとえば、ves1（pref、dp、alg）は次のように構成されています。
(500, 0, Highest-Preference) in PE1,
（500、0、最高予防）PE1の、
(255, 0, Highest-Preference) in PE2.
（255、0、最高予防）PE2の。
vES2 is configured as:
ves2は次のように構成されています：
(100, 0, Highest-Preference) in PE1,
（100、0、最高予防）PE1、
(200, 0, Highest-Preference) in PE2, and
（200、0、最高予防）PE2、および
(300, 0, Highest-Preference) in PE3.
（300、0、最高予防）PE3の。
b. The PEs advertise an Ethernet Segment route for each virtual Ethernet Segment, including the three parameters indicated in (a) above, in the DF Election Extended Community (encoded as described in Section 3).
b. PESは、DF選挙拡張コミュニティ（セクション3に記載されているようにエンコード）で上記（a）に示されている3つのパラメーターを含む、各仮想イーサネットセグメントのイーサネットセグメントルートを宣伝しています。
c. According to [RFC8584], each PE will run the DF election algorithm upon expiration of the DF Wait timer. Each PE runs the Highest-Preference or Lowest-Preference Algorithm for each Ethernet Segment as follows:
c. [RFC8584]によると、各PEはDF待機タイマーの有効期限が切れるとDF選挙アルゴリズムを実行します。各PEは、次のように、各イーサネットセグメントの最高予防アルゴリズムまたは最低プレファレンスアルゴリズムを実行します。
* The PE will check the DF algorithm value in each Ethernet Segment route, and assuming all the Ethernet Segment routes (including the local route) are consistent in this DF algorithm (that is, all are configured for Highest-Preference or Lowest-Preference, but not a mix), the PE runs the procedure in this section. Otherwise, the procedure falls back to the default DF algorithm [RFC7432]. The Highest-Preference and Lowest-Preference Algorithms are different algorithms; therefore, if two PEs configured for Highest-Preference and Lowest-Preference, respectively, are attached to the same Ethernet Segment, the operational DF election algorithm will fall back to the default DF algorithm.
* PEは、各イーサネットセグメントルートのDFアルゴリズム値を確認し、すべてのイーサネットセグメントルート（ローカルルートを含む）がこのDFアルゴリズム（つまり、すべてが最高のプレープレーションまたは最低プレファレンス）で一貫していると仮定します。PEは、このセクションで手順を実行します。それ以外の場合、手順はデフォルトのDFアルゴリズム[RFC7432]に戻ります。最も高いプレーと最も低いプレイファレンスアルゴリズムは、異なるアルゴリズムです。したがって、それぞれ最高のプレファレンスと最も低いプレファレンスのために構成された2つのPESが同じイーサネットセグメントに接続されている場合、運用上のDF選挙アルゴリズムはデフォルトのDFアルゴリズムに戻ります。
* If all the PEs attached to the Ethernet Segment advertise the Highest-Preference Algorithm, each PE builds a list of candidate PEs, ordered by preference value from the numerically highest value to lowest value. For example, PE1 builds a list of candidate PEs for vES1 ordered by the Preference, from high to low: <PE1, PE2> (since PE1's preference is more preferred than PE2's). Hence, PE1 becomes the Designated Forwarder for vES1. In the same way, PE3 becomes the Designated Forwarder for vES2.
* イーサネットセグメントに添付されているすべてのPEが最高予防アルゴリズムを宣伝している場合、各PEは候補PESのリストを作成します。たとえば、PE1は、優先順位によって順序付けられたVES1の候補PEのリストを高く構築します。したがって、PE1はVES1の指定されたフォワーダーになります。同様に、PE3はVES2の指定されたフォワーダーになります。
* If all the PEs attached to the Ethernet Segment advertise the Lowest-Preference Algorithm, then the candidate list is ordered from the numerically lowest preference value to the highest preference value. For example, PE1's ordered list for vES1 is <PE2, PE1>. Hence, PE2 becomes the Designated Forwarder for vES1. In the same way, PE1 becomes the Designated Forwarder for vES2.
* イーサネットセグメントに添付されているすべてのPEが最低プレファレンスアルゴリズムを宣伝する場合、候補リストは数値的に最低優先値から最高の優先値に注文されます。たとえば、VES1のPE1の順序リストは<PE2、PE1>です。したがって、PE2はVES1の指定されたフォワーダーになります。同様に、PE1はVES2の指定されたフォワーダーになります。
d. Assuming some maintenance tasks had to be executed on a PE, the operator may want to make sure the PE is not the Designated Forwarder for the Ethernet Segment so that the impact on the service is minimized. For example, if PE3 is going on maintenance and the DF algorithm is Highest-Preference, the operator could change vES2's Preference on PE3 from 300 to, e.g., 50 (hence, the Ethernet Segment route from PE3 is updated with the new preference value), so that PE2 is forced to take over as Designated Forwarder for vES2 (irrespective of the "Don't Preempt" Capability). Once the maintenance task on PE3 is over, the operator could decide to leave the latest configured preference value or configure the initial preference value back. A similar procedure can be used for the Lowest-Preference Algorithm too. For example, suppose the algorithm for vES2 is Lowest-Preference, and PE1 (the DF) goes on maintenance mode. The operator could change vES2's Preference on PE1 from 100 to, e.g., 250, so that PE2 is forced to take over as the Designated Forwarder for vES2.
d. いくつかのメンテナンスタスクをPEで実行する必要があると仮定すると、オペレーターは、サービスへの影響が最小化されるように、PEがイーサネットセグメントの指定されたフォワーダーではないことを確認することをお勧めします。たとえば、PE3がメンテナンスを行っており、DFアルゴリズムが最も高い場合、オペレーターはVES2のPE3の好みを300から50に変更することができます（したがって、PE3からのイーサネットセグメントルートは新しい選好値で更新されます）。PE3のメンテナンスタスクが終了したら、オペレーターは最新の設定された設定値を残すか、初期設定値を構成することを決定できます。同様の手順も、最も低いプレファレンスアルゴリズムにも使用できます。たとえば、VES2のアルゴリズムが最も低い場合、PE1（DF）がメンテナンスモードで行われるとします。オペレーターは、PE1に対するVES2の好みを100から250に変更する可能性があるため、PE2はVES2の指定されたフォワーダーとして引き継ぐことを余儀なくされます。
e. In case of equal Preference in two or more PEs in the Ethernet Segment, the "Don't Preempt" Capability and the numerically lowest IP address of the candidate PE(s) are used as tiebreakers. The procedures for the use of the "Don't Preempt" Capability are specified in Section 4.3. If more than one PE is advertising itself as the preferred Designated Forwarder, an implementation MUST first select the PE advertising the "Don't Preempt" Capability set, and then select the PE with the lowest IP address (if the "Don't Preempt" Capability selection does not yield a unique candidate). The PE's IP address is the address used in the candidate list, and it is derived from the Originating Router's IP address of the Ethernet Segment route. In case PEs use the Originating Router's IP address of different families, an IPv4 address is always considered numerically lower than an IPv6 address. Some examples of using the "Don't Preempt" Capability and IP address tiebreakers follow:
e. イーサネットセグメントの2つ以上のPEで等しい選好がある場合、候補PEの「先制」機能と数値的に最低のIPアドレスがタイブレーカーとして使用されます。「先制しない」機能を使用する手順は、セクション4.3で指定されています。複数のPEが優先指定されたフォワーダーとして広告を宣伝している場合、実装は最初に「先制しない」機能を宣伝するPEを選択する必要があります。次に、最低のIPアドレスでPEを選択します（「先制」機能の選択が一意の候補を生成しない場合）。PEのIPアドレスは、候補リストで使用されるアドレスであり、イーサネットセグメントルートの発信ルーターのIPアドレスから派生しています。PESがさまざまなファミリの発信元ルーターのIPアドレスを使用した場合、IPv4アドレスは常にIPv6アドレスよりも数値的に低いと見なされます。「先制しない」機能とIPアドレスのタイブレーカーを使用する例が次のとおりです。
* If vES1 parameters were (500, 0, Highest-Preference) in PE1 and (500, 1, Highest-Preference) in PE2, PE2 would be elected due to the "Don't Preempt" Capability. The same example applies if PE1 and PE2 advertise the Lowest-Preference Algorithm instead.
* VES1パラメーターがPE1で（500、0、最高予測）、PE2で（500、1、最高予測）であれば、「先制しない」機能によりPE2が選出されます。PE1とPE2が代わりに最も低いプレファレンスアルゴリズムを宣伝する場合、同じ例が適用されます。
* If vES1 parameters were (500, 0, Highest-Preference) in PE1 and (500, 0, Highest-Preference) in PE2, PE1 would be elected, if PE1's IP address is lower than PE2's. Or PE2 would be elected if PE2's IP address is lower than PE1's. The same example applies if PE1 and PE2 advertise the Lowest-Preference Algorithm instead.
* VES1パラメーターがPE1で（500、0、最高予防）、PE2で（500、0、最高予測）の場合、PE1のIPアドレスがPE2よりも低い場合、PE1が選出されます。または、PE2のIPアドレスがPE1のIPアドレスよりも低い場合、PE2が選出されます。PE1とPE2が代わりに最も低いプレファレンスアルゴリズムを宣伝する場合、同じ例が適用されます。
f. The Preference is an administrative option that MUST be configured on a per-Ethernet-Segment basis, and it is normally configured from the management plane. The preference value MAY also be dynamically changed based on the use of local policies that react to events on the PE. The following examples illustrate the use of local policy to change the preference value in a dynamic way.
f. 優先順位は、セグメントごとのベースで構成する必要がある管理オプションであり、通常は管理プレーンから構成されます。また、PEのイベントに反応するローカルポリシーの使用に基づいて、優先値は動的に変更される場合があります。次の例は、地域のポリシーを使用して、動的な方法で優先値を変更することを示しています。
* On PE1, if the DF algorithm is Highest-Preference, ES1's preference value can be lowered from 500 to 100 in case the bandwidth on the ENNI port is decreased by 50% (that could happen if, e.g., the 2-port Link Aggregation Group between PE1 and the Aggregation Network loses one port).
* PE1では、DFアルゴリズムが最も高いプレイヤーである場合、ENNIポートの帯域幅が50％減少した場合に、ES1の優先値を500から100に下げることができます（たとえば、PE1と集約ネットワークの間の2ポートリンク分解グループが1つのポートを失う場合に発生する可能性があります）。
* Local policy MAY also trigger dynamic Preference changes based on the PE's bandwidth availability in the core, specific ports going operationally down, etc.
* また、ローカルポリシーは、コアでのPEの帯域幅の可用性、操作的に操作する特定のポートなどに基づいて動的な好みの変更を引き起こす場合があります。
* The definition of the actual local policies is out of scope of this document.
* 実際のローカルポリシーの定義は、このドキュメントの範囲外です。
Highest-Preference and Lowest-Preference Algorithms MAY be used along with the AC-DF capability. Assuming all the PEs in the Ethernet Segment are configured consistently with the Highest-Preference or Lowest-Preference Algorithm and AC-DF capability, a given PE in the Ethernet Segment is not considered as a candidate for DF election until its corresponding Ethernet A-D per ES and Ethernet A-D per EVI routes are received, as described in [RFC8584].
AC-DF機能とともに、最も高いプレファレンスおよび最も低いプレイファレンスアルゴリズムを使用できます。イーサネットセグメント内のすべてのPEが最高のプレーまたは最も低いプレイファレンスアルゴリズムおよびAC-DF機能と一貫して構成されていると仮定すると、イーサネットセグメントの特定のPEは、対応するイーサネットA-DおよびEVIあたりのETHERNET A-Dが受信されるまで[RFC8584]に記載されているように、DF選挙の候補とは見なされません。
Highest-Preference and Lowest-Preference Algorithms can be used in different virtual Ethernet Segments on the same PE. For instance, PE1 and PE2 can use Highest-Preference for vES1 and PE1, and PE2 and PE3 can use Lowest-Preference for vES2. The use of one DF algorithm over the other is the operator's choice. The existence of both provides flexibility and full control to the operator.
同じPEのさまざまな仮想イーサネットセグメントで、最高のプレープレーションおよび最も低いプレファレンスアルゴリズムを使用できます。たとえば、PE1とPE2はVES1およびPE1に対して最も高いプレーファレンスを使用でき、PE2とPE3はVES2に対して最も低いプレファレンスを使用できます。1つのDFアルゴリズムを他のDFアルゴリズムの使用は、オペレーターの選択です。両方の存在は、オペレーターに柔軟性と完全な制御を提供します。
The procedures in this document can be used in an Ethernet Segment as defined in [RFC7432] or a virtual Ethernet Segment per [RFC9784] and also in EVPN networks as described in [RFC8214], [RFC7623], or [RFC8365].
このドキュメントの手順は、[RFC7432]で定義されているイーサネットセグメントまたは[RFC9784]あたりの仮想イーサネットセグメント、および[RFC8214]、[RFC7623]、または[RFC8365]で説明されているEVPNネットワークで使用できます。
While the Highest-Preference or Lowest-Preference Algorithm described in Section 4.1 is typically used in virtual Ethernet Segment scenarios where there is normally an individual Ethernet Tag per virtual Ethernet Segment, the existing definition of an Ethernet Segment [RFC7432] allows potentially up to thousands of Ethernet Tags on the same Ethernet Segment. If this is the case, and if the Highest-Preference or Lowest-Preference Algorithm is configured in all the PEs of the Ethernet Segment, the same PE will be the elected Designated Forwarder for all the Ethernet Tags of the Ethernet Segment. A potential way to achieve a more granular load balancing is described below.
セクション4.1で説明されている最高のプレファレンスまたは最も低いプレイファレンスアルゴリズムは、通常、仮想イーサネットセグメントごとに個々のイーサネットタグがある仮想イーサネットセグメントシナリオで使用されますが、イーサネットセグメント[RFC7432]の既存の定義は、同じイーサネットセグメントのイーサネットタグの潜在的なものを可能にします。この場合、イーサネットセグメントのすべてのPESで最高のプレーファレンスまたは最も低いプレイファレンスアルゴリズムが構成されている場合、同じPEがイーサネットセグメントのすべてのイーサネットタグに対して選出された指定された転送業者になります。より細かい負荷分散を達成する潜在的な方法を以下に説明します。
The Ethernet Segment is configured with an administrative preference value and an administrative DF algorithm, i.e., Highest-Preference or Lowest-Preference Algorithm. However, the administrative DF algorithm (which is used to signal the DF algorithm for the Ethernet Segment) MAY be overridden to a different operational DF algorithm for a range of Ethernet Tags. With this option, the PE builds a list of candidate PEs ordered by Preference; however, the Designated Forwarder for a given Ethernet Tag will be determined by the locally overridden DF algorithm.
イーサネットセグメントは、管理選好値と管理DFアルゴリズム、つまり最高段階または最も低いプレイファレンスアルゴリズムで構成されています。ただし、管理DFアルゴリズム（イーサネットセグメントのDFアルゴリズムを信号にするために使用される）は、さまざまなイーサネットタグの異なる操作DFアルゴリズムにオーバーライドされる場合があります。このオプションを使用すると、PEは好みによって注文された候補PEのリストを作成します。ただし、特定のイーサネットタグの指定されたフォワーダーは、ローカルにオーバーライドされたDFアルゴリズムによって決定されます。
For instance:
例えば：
* Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as (500, 0, Highest-Preference) and PE2 as (100, 0, Highest-Preference) for ES3. Both PEs will advertise the Ethernet Segment routes for ES3 with the indicated parameters in the DF Election Extended Community.
* ES3がPE1およびPE2で定義されていると仮定すると、PE1はES3の（500、0、最高予測）、PE2として（100、0、最高予測）として構成できます。両方のPESは、DF選挙拡張コミュニティで示されたパラメーターを使用して、ES3のイーサネットセグメントルートを宣伝します。
* In addition, assuming there are VLAN-based service interfaces and that the PEs are attached to all Ethernet Tags in the range 1-4000, both PE1 and PE2 may be configured with (Ethernet Tag-range, Lowest-Preference), e.g., (2001-4000, Lowest-Preference).
* さらに、VLANベースのサービスインターフェイスがあると仮定し、PESが1〜4000のすべてのイーサネットタグに接続されていると仮定すると、PE1とPE2の両方が（イーサネットタグ範囲、最低プレファレンス）、たとえば（2001-4000、最も低いプレファレンス）で構成できます。
* This will result in PE1 being the Designated Forwarder for Ethernet Tags 1-2000 (since they use the default Highest-Preference Algorithm) and PE2 being the Designated Forwarder for Ethernet Tags 2001-4000, due to the local policy overriding the Highest-Preference Algorithm.
* これにより、PE1はイーサネットタグ1-2000の指定された転送業者になります（デフォルトの最高プレームアルゴリズムを使用するため）、PE2は、最高予測アルゴリズムを最優先するローカルポリシーのため、イーサネットタグ2001-4000の指定された転送者です。
While the above logic provides a perfect load-balancing distribution of Ethernet Tags per Designated Forwarder when there are only two PEs, for Ethernet Segments attached to three or more PEs, there would be only two Designated Forwarder PEs for all the Ethernet Tags. Any other logic that provides a fair distribution of the Designated Forwarder function among the three or more PEs is valid, as long as that logic is consistent in all the PEs in the Ethernet Segment. It is important to note that, when a local policy overrides the Highest-Preference or Lowest-Preference signaled by all the PEs in the Ethernet Segment, this local policy MUST be consistent in all the PEs of the Ethernet Segment. If the local policy is inconsistent for a given Ethernet Tag in the Ethernet Segment, packet drops or packet duplication may occur on that Ethernet Tag. For all these reasons, the use of virtual Ethernet Segments is RECOMMENDED for cases where more than two PEs per Ethernet Segment exist and a good load-balancing distribution per Ethernet Tag of the Designated Forwarder function is desired.
上記のロジックは、指定されたフォワーダーごとにイーサネットタグの完全な負荷分布を提供しますが、3つ以上のPEに接続されているイーサネットセグメントについては、すべてのイーサネットタグに2つの指定されたフォワーダーPEのみがあります。そのロジックがイーサネットセグメントのすべてのPEで一貫している限り、3つ以上のPES間の指定された転送機能の公正な分布を提供する他のロジックは有効です。ローカルポリシーがイーサネットセグメント内のすべてのPESによってシグナルが示す最高のプレファレンスまたは最も低いプレファレンスをオーバーライドする場合、このローカルポリシーはイーサネットセグメントのすべてのPESで一貫している必要があることに注意することが重要です。ローカルポリシーがイーサネットセグメントの特定のイーサネットタグに対して一貫していない場合、そのイーサネットタグでパケットドロップまたはパケットの複製が発生する可能性があります。これらすべての理由により、イーサネットセグメントごとに2つ以上のPEが存在する場合、指定された転送先機能のイーサネットタグごとの適切な負荷分布が必要な場合には、仮想イーサネットセグメントの使用が推奨されます。
As discussed in item d of Section 1.2, a capability to NOT preempt the existing Designated Forwarder (for all the Ethernet Tags in the Ethernet Segment) is required and therefore added to the DF Election Extended Community. This option allows a non-revertive behavior in the DF election.
セクション1.2の項目Dで説明したように、既存の指定されたフォワーダー（イーサネットセグメントのすべてのイーサネットタグに対して）を先制しない機能が必要であるため、DF選挙拡張コミュニティに追加されます。このオプションにより、DF選挙で非反論的な行動が可能になります。
Note that when a given PE in an Ethernet Segment is taken down for maintenance operations, before bringing it back, the Preference may be changed in order to provide a non-revertive behavior. The "Don't Preempt" Capability and the mechanism explained in this section will be used for those cases when a former Designated Forwarder comes back up without any controlled maintenance operation, and the non-revertive option is desired in order to avoid service impact.
イーサネットセグメントの特定のPEがメンテナンス操作のために削除された場合、それを取り戻す前に、非リバーシックな動作を提供するために好みが変更される可能性があることに注意してください。「先制」機能とこのセクションで説明されているメカニズムは、制御されたメンテナンス操作なしで以前の指定されたフォワーダーが戻ってきた場合に使用され、サービスの影響を避けるために非反論オプションが望まれます。
In Figure 3, we assume that based on the Highest-Preference Algorithm, PE3 is the Designated Forwarder for ESI2.
図3では、最高予防アルゴリズムに基づいて、PE3がESI2の指定されたフォワーダーであると想定しています。
If PE3 has a link, EVC, or node failure, PE2 would take over as the Designated Forwarder. If/when PE3 comes back up again, PE3 will take over, causing some unnecessary packet loss in the Ethernet Segment.
PE3にリンク、EVC、またはノード障害がある場合、PE2は指定された転送業者として引き継ぎます。PE3が再び戻ってきた場合、PE3が引き継ぎ、イーサネットセグメントで不必要なパケット損失を引き起こします。
The following procedure avoids preemption upon failure recovery (see Figure 3). The procedure supports a non-revertive mode that can be used along with:
次の手順では、障害回復時の先制を回避します（図3を参照）。この手順は、以下と一緒に使用できる非反転モードをサポートします。
* Highest-Preference Algorithm
* 最高プレームアルゴリズム
* Lowest-Preference Algorithm
* 最も低いプレーファレンスアルゴリズム
* Highest-Preference or Lowest-Preference Algorithm, where a local policy overrides the Highest-/Lowest-Preference tiebreaker for a range of Ethernet Tags (Section 4.2)
* 最も高いプレファレンスまたは最も低いプレファレンスアルゴリズム。ローカルポリシーは、範囲のイーサネットタグの最高/最低プレーファレンスタイブレーカーをオーバーライドします（セクション4.2）
The procedure is described, assuming the Highest-Preference Algorithm in the Ethernet Segment, where local policy overrides the tiebreaker for a given Ethernet Tag. The other cases above are a subset of this one, and the differences are explained.
この手順については、現地のポリシーが特定のイーサネットタグのタイブレーカーをオーバーライドするイーサネットセグメントの最高プレームアルゴリズムを仮定して説明します。上記の他のケースはこれのサブセットであり、違いについて説明します。
1. A "Don't Preempt" Capability is defined on a per-PE / per-Ethernet-Segment basis, as described in Section 3. If "Don't Preempt" is disabled (default behavior), the PE sets DP to zero and advertises it in an Ethernet Segment route. If "Don't Preempt" is enabled, the Ethernet Segment route from the PE indicates the desire of not being preempted by the other PEs in the Ethernet Segment. All the PEs in an Ethernet Segment should be consistent in their configuration of the "Don't Preempt" Capability; however, this document does not enforce the consistency across all the PEs. In case of inconsistency in the support of the "Don't Preempt" Capability in the PEs of the same Ethernet Segment, non-revertive behavior is not guaranteed. However, PEs supporting this capability still attempt this procedure.
1. セクション3で説明されているように、「先制」機能はPE / PER / PER-ETHERNETセグメントベースで定義されます。「先制」が無効になっている場合（デフォルトの動作）、PEはDPをゼロに設定し、イーサネットセグメントルートで宣伝します。「プリエンプト」が有効になっている場合、PEからのイーサネットセグメントルートは、イーサネットセグメントの他のPESによって先取りされないという欲求を示します。イーサネットセグメント内のすべてのPEは、「先制しない」機能の構成に一貫性があるはずです。ただし、このドキュメントでは、すべてのPESにわたって一貫性を強制しません。同じイーサネットセグメントのPESにおける「先制」能力をサポートする矛盾がある場合、非反対の動作は保証されません。ただし、この機能をサポートするPESは、この手順を試みます。
2. Assuming we want to avoid 'preemption' in all the PEs in the Ethernet Segment, the three PEs are configured with the "Don't Preempt" Capability. In this example, we assume ESI2 is configured as 'DP=enabled' in the three PEs.
2. イーサネットセグメント内のすべてのPEで「先制」を回避したいと仮定すると、3つのPESは「先制」機能で構成されています。この例では、ESI2が3つのPESで「DP =有効」として構成されていると仮定します。
3. We also assume vES2 is attached to Ethernet Tag-1 and Ethernet Tag-2. vES2 uses Highest-Preference as the DF algorithm, and a local policy is configured in the three PEs to use Lowest-Preference for Ethernet Tag-2. When vES2 is enabled in the three PEs, the PEs will exchange the Ethernet Segment routes and select PE3 as the Designated Forwarder for Ethernet Tag-1 (due to the Highest-Preference) and PE1 as the Designated Forwarder for Ethernet Tag-2 (due to the Lowest-Preference).
3. また、VES2がイーサネットTAG-1およびイーサネットTAG-2に接続されていると仮定します。VES2はDFアルゴリズムとして最高のプレファレンスを使用し、ローカルポリシーは3つのPESで構成され、イーサネットTAG-2の最低プレファレンスを使用します。VES2が3つのPESで有効になっている場合、PESはイーサネットセグメントルートを交換し、PE3をイーサネットTAG-1の指定されたフォワーダー（最高のプレーファレンスのため）の指定された転送者として選択し、PE1はイーサネットTAG-2の指定されたフォワーダーとして（最も低いプレファレンスのため）を選択します。
4. If PE3's vES2 goes down (due to an EVC failure (as detected by OAM protocols), a port failure, or a node failure), PE2 will become the Designated Forwarder for Ethernet Tag-1. No changes will occur for Ethernet Tag-2.
4. PE3のVES2が（EVC障害（OAMプロトコルで検出された）、ポート障害、またはノード障害のために）ダウンした場合、PE2はイーサネットTAG-1の指定されたフォワーダーになります。イーサネットタグ-2に変更は発生しません。
5. When PE3's vES2 comes back up, PE3 will start a boot-timer (if booting up) or hold-timer (if the port or EVC recovers). That timer will allow some time for PE3 to receive the Ethernet Segment routes from PE1 and PE2. This timer is applied between the INIT and the DF_WAIT states in the DF election Finite State Machine described in [RFC8584]. PE3 will then:
5. PE3のVES2が戻ってくると、PE3はブートタイマー（ブートアップの場合）またはホールドタイマー（ポートまたはEVCが回復する場合）を開始します。そのタイマーは、PE3がPE1とPE2からイーサネットセグメントルートを受信するための時間を許可します。このタイマーは、[RFC8584]に記載されているDF選挙の有限状態マシンで、initとdf_wait状態の間に適用されます。PE3は次のとおりです。
* Select a "reference-PE" among the Ethernet Segment routes in the virtual Ethernet Segment. If the Ethernet Segment uses the Highest-Preference Algorithm, select a "Highest-PE". If it uses the Lowest-Preference Algorithm, select a "Lowest-PE". If a local policy is in use, to override the Highest-/Lowest-Preference for a range of Ethernet Tags (as discussed in Section 4.2), it is necessary to select both a Highest-PE and a Lowest-PE. They are selected as follows:
* 仮想イーサネットセグメントのイーサネットセグメントルートから「参照PE」を選択します。イーサネットセグメントが最も高いプレーファレンスアルゴリズムを使用する場合、「最高PE」を選択します。最も低いプレファレンスアルゴリズムを使用する場合は、「最低PE」を選択します。ローカルポリシーが使用されている場合、一連のイーサネットタグの最高/最低のプレファレンスを上書きします（セクション4.2で説明しているように）、最高PEと最低PEの両方を選択する必要があります。それらは次のように選択されます：
- The Highest-PE is the PE with higher Preference, using the "Don't Preempt" Capability first (with DP=1 being better) and, after that, the lower PE-IP address as tiebreakers.
- 最も高いPEは、最初に「先制しない」機能を使用して（DP = 1が優れている）、その後、タイブレーカーとして下のPE-IPアドレスを使用して、優先度が高いPEです。
- The Lowest-PE is the PE with lower Preference, using the "Don't Preempt" Capability first (with DP=1 being better) and, after that, the lower PE-IP address as tiebreakers.
- 最低PEは、最初に「先制しない」機能を使用して（DP = 1が優れている）、その後、タイブレーカーとして下のPE-IPアドレスを使用して、優先度が低いPEです。
- In our example, the Highest-Preference Algorithm is used, with a local policy to override it to use Lowest-Preference for a range of Ethernet Tags. Therefore, PE3 selects a Highest-PE and a Lowest-PE. PE3 will select PE2 as the Highest-PE over PE1, because when comparing (Pref, DP, PE-IP), (200, 1, PE2-IP) wins over (100, 1, PE1-IP). PE3 will select PE1 as the Lowest-PE over PE2, because (100, 1, PE1-IP) wins over (200, 1, PE2-IP). Note that if there were only one remote PE in the Ethernet Segment, the Lowest and Highest PE would be the same PE.
- この例では、最高のプレーファレンスアルゴリズムが使用されており、ローカルポリシーを使用して、一連のイーサネットタグに対して最も低いプレファレンスを使用するようにオーバーライドします。したがって、PE3は最高PEと最低PEを選択します。PE3は、PE2をPE1よりも最高PEとして選択します。これは（Pref、DP、PE-IP）（200、1、PE2-IP）を比較すると（100、1、PE1-IP）勝ちます。PE3は、（100、1、PE1-IP）が（200、1、PE2-IP）以上で勝つため、PE2よりも最低PEとしてPE1を選択します。イーサネットセグメントにリモートPEが1つしかなかった場合、最も低くて最高のPEは同じPEになることに注意してください。
* Check its own administrative Pref and compare it with the one of the Highest-PE and Lowest-PE that have the "Don't Preempt" Capability set in their Ethernet Segment routes. Depending on this comparison, PE3 sends the Ethernet Segment route with a (Pref, DP) that may be different from its administrative (Pref, DP):
* 独自の管理PREFを確認し、イーサネットセグメントルートに「先制しない」機能が設定されている最も高いPEおよび最低PEの1つと比較します。この比較に応じて、PE3は、その管理（PREF、DP）とは異なる可能性のある（Pref、DP）でイーサネットセグメントルートを送信します。
- If PE3's Pref value is higher than or equal to the Highest-PE's, PE3 will send the Ethernet Segment route with an 'in-use' operational Pref equal to the Highest-PE's and DP=0.
- PE3のPREF値が最高-PEよりも高い場合、PE3は、最高PEおよびDP = 0に等しい「使用中」の動作対象とともにイーサネットセグメントルートを送信します。
- If PE3's Pref value is lower than or equal to the Lowest-PE's, PE3 will send the Ethernet Segment route with an 'in-use' operational Preference equal to the Lowest-PE's and DP=0.
- PE3のPREF値が最低PE以下の値が低い場合、PE3は、最低PEおよびDP = 0に等しい「使用中の」運用設定でイーサネットセグメントルートを送信します。
- If PE3's Pref value is not higher than or equal to the Highest-PE's and is not lower than or equal to the Lowest-PE's, PE3 will send the Ethernet Segment route with its administrative (Pref, DP)=(300, 1).
- PE3のPREF値が最高-PEの値以下が高く、最低PE以外の値以下が低い場合、PE3はその管理（PREF、DP）=（300、1）でイーサネットセグメントルートを送信します。
- In this example, PE3's administrative Pref=300 is higher than the Highest-PE with DP=1, that is, PE2 (Pref=200). Hence, PE3 will inherit PE2's preference and send the Ethernet Segment route with an operational 'in-use' (Pref, DP)=(200, 0).
- この例では、PE3の管理PREF = 300は、DP = 1、つまりPE2（Pref = 200）の最高PEよりも高くなっています。したがって、PE3はPE2の好みを継承し、イーサネットセグメントルートを運用上の「使用」（PREF、DP）=（200、0）で送信します。
* Send its "Don't Preempt" Capability set to zero, as long as the advertised Pref is the 'in-use' operational Pref (as opposed to the 'administrative' Pref).
* 宣伝されているPREFが「使用中」の運用PREFである限り（「管理者」とは対照的に）、「プリエンプト」機能をゼロに送信します。
* Not trigger any Designated Forwarder changes for Ethernet Tag-1. This Ethernet Segment route update sent by PE3, with (200, 0, PE3-IP), will not cause any Designated Forwarder switchover for any Ethernet Tag. This is because the "Don't Preempt" Capability will be used as a tiebreaker in the DF election. That is, if a PE has two candidate PEs with the same Pref, it will pick the one with DP=1. There are no Designated Forwarder changes for Ethernet Tag-2 either.
* イーサネットTAG-1の指定された転送者の変更をトリガーしない。（200、0、PE3-IP）を備えたPE3が送信したこのイーサネットセグメントルート更新は、イーサネットタグに指定されたフォワーダースイッチオーバーを引き起こしません。これは、DF選挙で「先制しない」機能がタイブレーカーとして使用されるためです。つまり、PEに同じPREを持つ2つの候補PESがある場合、DP = 1で1つを選択します。イーサネットTAG-2の指定された転送者の変更はありません。
6. For any subsequent received update/withdraw in the Ethernet Segment, the PEs will go through the process described in (5) to select the Highest-PEs and Lowest-PEs, now considering themselves as candidates. For instance, if PE2 fails upon receiving PE2's Ethernet Segment route withdrawal, PE3 and PE1 will go through the selection of the new Highest-PEs and Lowest-PEs (considering their own active Ethernet Segment route), and then they will run the DF election.
6. イーサネットセグメントでのその後の更新/撤回の場合、PESは（5）で説明されているプロセスを経て、最高PEと最低PEを選択し、現在は候補者と考えています。たとえば、PE2がPE2のイーサネットセグメントルートの引き出しを受信して失敗した場合、PE3とPE1は新しい最高PEと最低PEの選択（独自のアクティブなイーサネットセグメントルートを考慮）を実行し、DF選挙を実行します。
* If a PE selects itself as the new Highest-PE or Lowest-PE and it was not before, the PE will then compare its operational 'in-use' Pref with its administrative Pref. If different, the PE will send an Ethernet Segment route update with its administrative Pref and DP values. In the example, PE3 will be the new Highest-PE; therefore, it will send an Ethernet Segment route update with (Pref, DP)=(300, 1).
* PEが新しい最高PEまたは最低PEとしてそれ自体を選択し、それが以前ではなかった場合、PEはその運用上の「使用」と比較します。異なる場合、PEは、その管理PREFおよびDP値を使用してイーサネットセグメントルートの更新を送信します。この例では、PE3は新しい最高PEになります。したがって、（Pref、dp）=（300、1）でイーサネットセグメントルートの更新を送信します。
* After running the DF election, PE3 will become the new Designated Forwarder for Ethernet Tag-1. No changes will occur for Ethernet Tag-2.
* DF選挙を実施した後、PE3はイーサネットTAG-1の新しい指定されたフォワーダーになります。イーサネットタグ-2に変更は発生しません。
Note that, irrespective of the "Don't Preempt" Capability, when a PE or Ethernet Segment comes back and the PE advertises a DF election algorithm different from the one configured in the rest of the PEs in the Ethernet Segment, all the PEs in the Ethernet Segment MUST fall back to the default DF algorithm [RFC7432].
PEまたはイーサネットセグメントが戻ってきて、PEがイーサネットセグメントの残りのPESで構成されたものとは異なるDF選挙アルゴリズムを宣伝する場合、「先取りしないでください」機能に関係なく、イーサネットセグメントのすべてのPESがデフォルトのDFアルゴリズム[RFC7432]に戻る必要があることに注意してください。
This document does not modify the use of the P and B bits in the Ethernet A-D per EVI routes [RFC8214] advertised by the PEs in the Ethernet Segment after running the DF election, irrespective of the revertive or non-revertive behavior in the PE.
このドキュメントでは、PEでの復帰または非リベーターの動作に関係なく、DF選挙を実行した後、イーサネットセグメントのPESによって宣伝されているEVIルートあたりのイーサネットA-D [RFC8214]のPおよびBビットの使用を変更しません。
This document describes a DF election algorithm that provides absolute control (by configuration) over what PE is the Designated Forwarder for a given Ethernet Tag. While this control is desired in many situations, a malicious user that gets access to the configuration of a PE in the Ethernet Segment may change the behavior of the network. In other DF algorithms such as HRW, the DF election is more automated and cannot be determined by configuration. If the DF algorithm is Highest-Preference or Lowest-Preference, an attacker may change the configuration of the preference value on a PE and Ethernet Segment to impact the traffic going through that PE and Ethernet Segment.
このドキュメントでは、特定のイーサネットタグの指定されたフォワーダーであるPEを（構成ごとに）絶対制御するDF選挙アルゴリズムについて説明します。この制御は多くの状況で望まれますが、イーサネットセグメントのPEの構成にアクセスできる悪意のあるユーザーは、ネットワークの動作を変更する場合があります。HRWなどの他のDFアルゴリズムでは、DF選挙はより自動化されており、構成によって決定することはできません。DFアルゴリズムが最も高いプレファレンスまたは最も低い場合の場合、攻撃者は、PEおよびイーサネットセグメントの優先値の構成を変更して、そのPEおよびイーサネットセグメントを介してトラフィックに影響を与える場合があります。
The non-revertive capability described in this document may be seen as a security improvement over the regular EVPN revertive DF election: an intentional link (or node) "flapping" on a PE will only cause service disruption once, when the PE goes to Non-Designated Forwarder state. However, an attacker who gets access to the configuration of a PE in the Ethernet Segment will be able to disable the non-revertive behavior, by advertising a conflicting DF election algorithm and thereby forcing fallback to the default DF algorithm.
このドキュメントで説明されている非反転能力は、通常のEVPNリバリバティブDF選挙のセキュリティ改善と見なされる場合があります。PEの意図的なリンク（またはノード）「羽ばたき」は、PEが非指定されたフォワーダー状態になる場合にのみサービスの破壊を引き起こします。ただし、イーサネットセグメントでPEの構成にアクセスできる攻撃者は、矛盾するDF選挙アルゴリズムを宣伝し、デフォルトのDFアルゴリズムへのフォールバックを強制することにより、非反転動作を無効にすることができます。
The document also describes how a local policy can override the Highest-Preference or Lowest-Preference Algorithms for a range of Ethernet Tags in the Ethernet Segment. If the local policy is not consistent across all PEs in the Ethernet Segment and there is an Ethernet Tag that ends up with an inconsistent use of Highest-Preference or Lowest-Preference in different PEs, packet drop or packet duplication may occur for that Ethernet Tag.
このドキュメントでは、ローカルポリシーが、イーサネットセグメントの一連のイーサネットタグの最高予防または最も低いプレファレンスアルゴリズムをどのようにオーバーライドできるかについても説明しています。ローカルポリシーがイーサネットセグメントのすべてのPEで一貫していない場合、異なるPESで最も高いプレファレンスまたは最も低いプレファレンスの一貫性のない使用が終了するイーサネットタグがある場合、そのイーサネットタグではパケットドロップまたはパケットの重複が発生する可能性があります。
Finally, the two DF election algorithms specified in this document (Highest-Preference and Lowest-Preference) do not change the way the PEs share their Ethernet Segment information, compared to the algorithms in [RFC7432] and [RFC8584]. Therefore, the security considerations in [RFC7432] and [RFC8584] apply to this document as well.
最後に、このドキュメントで指定された2つのDF選挙アルゴリズム（最高予防と最も低いプレファレンス）は、[RFC7432]および[RFC8584]のアルゴリズムと比較して、PESがイーサネットセグメント情報を共有する方法を変更しません。したがって、[RFC7432]および[RFC8584]のセキュリティ上の考慮事項は、このドキュメントにも適用されます。
Per this document, IANA has:
このドキュメントによると、IANAには次のようなものがあります。
* Allocated two new values in the "DF Alg" registry created by [RFC8584], as follows:
* [RFC8584]によって作成された「DFアルグ」レジストリに2つの新しい値を割り当てました。
+=====+==============================+===========+
| Alg | Name | Reference |
+=====+==============================+===========+
| 2 | Highest-Preference Algorithm | RFC 9785 |
+-----+------------------------------+-----------+
| 3 | Lowest-Preference Algorithm | RFC 9785 |
+-----+------------------------------+-----------+
Table 1
* Allocated a new value in the "DF Election Capabilities" registry created by [RFC8584] for the 2-octet Bitmap field in the DF Election Extended Community (under the "Border Gateway Protocol (BGP) Extended Communities" registry group), as follows:
* [RFC8584]によって作成された「DF選挙能力」レジストリに新しい価値を割り当て、DF選挙拡張コミュニティ（「Border Gateway Protocol（BGP）拡張コミュニティ」の下で、次のように、「Border Gateway Protocol（BGP）拡張コミュニティ」の下で、[RFC8584]フィールドに次のように割り当てられました。
+=====+==============================+===========+
| Bit | Name | Reference |
+=====+==============================+===========+
| 0 | D (Don't Preempt) Capability | RFC 9785 |
+-----+------------------------------+-----------+
Table 2
* Listed this document as an additional reference for the DF Election Extended Community field in the "EVPN Extended Community Sub-Types" registry, as follows:
* このドキュメントは、次のように、「EVPN拡張コミュニティサブタイプ」レジストリのDF選挙のコミュニティフィールドを拡張する追加の参照としてリストしました。
+================+================================+==============+
| Sub-Type Value | Name | Reference |
+================+================================+==============+
| 0x06 | DF Election | [RFC8584] |
| | Extended Community | and RFC 9785 |
+----------------+--------------------------------+--------------+
Table 3
[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>.
[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>.
[RFC9784] Sajassi, A., Brissette, P., Schell, R., Drake, J., and J.
Rabadan, "Virtual Ethernet Segments for EVPN and Provider
Backbone Bridge EVPN", RFC 9784, DOI 10.17487/9784, June
2025, <https://www.rfc-editor.org/info/rfc9784>.
[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>.
[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>.
The authors would like to thank Kishore Tiruveedhula and Sasha Vainshtein for their reviews and comments. Also, thank you to Luc André Burdet and Stephane Litkowski for their thorough reviews and suggestions for a new Lowest-Preference Algorithm.
著者は、Kishore TiruveedhulaとSasha Vainshteinのレビューとコメントに感謝したいと思います。また、LucAndréBurdetとStephane Litkowskiに、新しい最低プレファレンスアルゴリズムの徹底的なレビューと提案に感謝します。
In addition to the authors listed, the following individuals also contributed to this document:
リストされている著者に加えて、次の個人もこの文書に貢献しました。
Tony Przygienda
Juniper
Satya Mohanty
Cisco
Kiran Nagaraj
Nokia
Vinod Prabhu
Nokia
Selvakumar Sivaraj
Juniper
Sami Boutros
VMWare
Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Senthil Sathappan
Nokia
Email: senthil.sathappan@nokia.com
Wen Lin
Juniper Networks
Email: wlin@juniper.net
John Drake
Independent
Email: je_drake@yahoo.com
Ali Sajassi
Cisco Systems
Email: sajassi@cisco.com