[要約] RFC 8584は、Ethernet VPNのデザインされたフォワーダー選出の拡張性のためのフレームワークを提供しています。このRFCの目的は、異なるネットワーク環境において、フォワーダーの選出方法を柔軟に拡張することです。
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 8584 Nokia
Updates: 7432 S. Mohanty, Ed.
Category: Standards Track A. Sajassi
ISSN: 2070-1721 Cisco
J. Drake
Juniper
K. Nagaraj
S. Sathappan
Nokia
April 2019
Framework for Ethernet VPN Designated Forwarder Election Extensibility
Ethernet VPN Designated Forwarder Election Extensibilityのフレームワーク
Abstract
概要
An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).
イーサネットVPN（EVPN）のデフォルトの指定フォワーダー（DF）選択アルゴリズムの代替が定義されています。 DFは、特定のイーサネットセグメント（ES）上の特定のVLANにあるマルチホームのカスタマーエッジ（CE）デバイスにブロードキャスト、不明なユニキャスト、およびマルチキャスト（BUM）トラフィックを送信するプロバイダーエッジ（PE）ルーターです。さらに、関連付けられた接続回線（AC）の状態に基づいて、VLANのDF選定結果に影響を与える機能も指定されています。このドキュメントでは、EVPNサービスにおけるDF選定有限状態マシンを明確にします。したがって、EVPN仕様（RFC 7432）を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8584.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8584で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions and Terminology ................................3
1.2. Default Designated Forwarder (DF) Election in EVPN
Services ...................................................5
1.3. Problem Statement ..........................................8
1.3.1. Unfair Load Balancing and Service Disruption ........8
1.3.2. Traffic Black-Holing on Individual AC Failures .....10
1.4. The Need for Extending the Default DF Election in
EVPN Services .............................................12
2. Designated Forwarder Election Protocol and BGP Extensions ......13
2.1. The DF Election Finite State Machine (FSM) ................13
2.2. The DF Election Extended Community ........................16
2.2.1. Backward Compatibility .............................19
3. The Highest Random Weight DF Election Algorithm ................19
3.1. HRW and Consistent Hashing ................................20
3.2. HRW Algorithm for EVPN DF Election ........................20
4. The AC-Influenced DF Election Capability .......................22
4.1. AC-Influenced DF Election Capability for
VLAN-Aware Bundle Services ................................24
5. Solution Benefits ..............................................25
6. Security Considerations ........................................26
7. IANA Considerations ............................................27
8. References .....................................................28
8.1. Normative References ......................................28
8.2. Informative References ....................................29
Acknowledgments ...................................................30
Contributors ......................................................30
Authors' Addresses ................................................31
The Designated Forwarder (DF) in Ethernet VPNs (EVPNs) is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). The DF is elected from the set of multihomed PEs attached to a given ES, each of which advertises an ES route for the ES as identified by its Ethernet Segment Identifier (ESI). By default, the EVPN uses a DF election algorithm referred to as "service carving". The DF election algorithm is based on a modulus function (V mod N) that takes the number of PEs in the ES (N) and the VLAN value (V) as input. This document addresses inefficiencies in the default DF election algorithm by defining a new DF election algorithm and an ability to influence the DF election result for a VLAN, depending on the state of the associated Attachment Circuit (AC). In order to avoid any ambiguity with the identifier used in the DF election algorithm, this document uses the term "Ethernet Tag" instead of "VLAN". This document also creates a registry with IANA for future DF election algorithms and capabilities (see Section 7). It also presents a formal definition and clarification of the DF election Finite State Machine (FSM). Therefore, this document updates [RFC7432], and EVPN implementations MUST conform to the prescribed FSM.
イーサネットVPN（EVPN）の指定フォワーダー（DF）は、特定のVLAN上の特定のVLAN上のマルチホームカスタマーエッジ（CE）デバイスにブロードキャスト、不明なユニキャスト、マルチキャスト（BUM）トラフィックを送信するプロバイダーエッジ（PE）ルーターです。イーサネットセグメント（ES）。 DFは、所定のESに接続されたマルチホームPEのセットから選出されます。各PEは、ESのイーサネットセグメント識別子（ESI）で識別されるESルートをアドバタイズします。デフォルトでは、EVPNは「サービスカービング」と呼ばれるDF選定アルゴリズムを使用します。 DF選出アルゴリズムは、ES内のPEの数（N）とVLAN値（V）を入力として取る係数関数（V mod N）に基づいています。このドキュメントでは、関連付けられている接続回路（AC）の状態に応じて、新しいDF選定アルゴリズムとVLANのDF選定結果に影響を与える機能を定義することにより、デフォルトのDF選定アルゴリズムの非効率性について説明します。 DF選出アルゴリズムで使用される識別子とのあいまいさを回避するために、このドキュメントでは「VLAN」の代わりに「イーサネットタグ」という用語を使用します。このドキュメントは、将来のDF選出アルゴリズムと機能のためにIANAのレジストリも作成します（セクション7を参照）。また、DF選挙の有限状態機械（FSM）の正式な定義と説明も示します。したがって、このドキュメントは[RFC7432]を更新し、EVPN実装は規定のFSMに準拠する必要があります。
The procedures described in this document apply to DF election in all EVPN solutions, including those described in [RFC7432] and [RFC8214]. Apart from the formal description of the FSM, this document does not intend to update other procedures described in [RFC7432]; it only aims to improve the behavior of the DF election on PEs that are upgraded to follow the procedures described in this document.
このドキュメントで説明されている手順は、[RFC7432]と[RFC8214]で説明されているものを含め、すべてのEVPNソリューションでのDF選出に適用されます。 FSMの正式な説明は別として、このドキュメントは[RFC7432]で説明されている他の手順を更新することを意図していません。このドキュメントで説明されている手順に従うようにアップグレードされたPEでのDF選挙の動作を改善することのみを目的としています。
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]で説明されているように解釈されます。
o AC: Attachment Circuit. An AC has an Ethernet Tag associated with it.
o AC：取り付け回路。 ACにはイーサネットタグが関連付けられています。
o ACS: Attachment Circuit Status.
o ACS：接続回路ステータス。
o BUM: Broadcast, unknown unicast, and multicast.
o BUM：ブロードキャスト、不明なユニキャスト、およびマルチキャスト。
o DF: Designated Forwarder.
o DF：指定フォワーダー。
o NDF: Non-Designated Forwarder.
o NDF：Non-Designated Forwarder。
o BDF: Backup Designated Forwarder.
o BDF：Backup Designated Forwarder。
o Ethernet A-D per ES route: Refers to Route Type 1 as defined in [RFC7432] or to Auto-discovery per Ethernet Segment route.
o ESルートごとのイーサネットA-D：[RFC7432]で定義されているルートタイプ1、またはイーサネットセグメントルートごとの自動検出を指します。
o Ethernet A-D per EVI route: Refers to Route Type 1 as defined in [RFC7432] or to Auto-discovery per EVPN Instance route.
o EVIルートごとのイーサネットA-D：[RFC7432]で定義されているルートタイプ1、またはEVPNインスタンスルートごとの自動検出を指します。
o ES: Ethernet Segment.
o ES：イーサネットセグメント。
o ESI: Ethernet Segment Identifier.
o ESI：イーサネットセグメント識別子。
o EVI: EVPN Instance.
o EVI：EVPNインスタンス。
o MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE.
o MAC-VRF：PE上のメディアアクセスコントロール（MAC）アドレス用の仮想ルーティングおよび転送テーブル。
o BD: Broadcast Domain. An EVI may be comprised of one BD (VLAN-based or VLAN Bundle services) or multiple BDs (VLAN-aware Bundle services).
o BD：ブロードキャストドメイン。 EVIは、1つのBD（VLANベースまたはVLANバンドルサービス）または複数のBD（VLAN対応バンドルサービス）で構成できます。
o Bridge table: An instantiation of a BD on a MAC-VRF.
o ブリッジテーブル：MAC-VRF上のBDのインスタンス化。
o HRW: Highest Random Weight.
o HRW：最高のランダムウェイト。
o VID: VLAN Identifier.
o VID：VLAN識別子。
o CE-VID: Customer Edge VLAN Identifier.
o CE-VID：カスタマーエッジVLAN ID。
o Ethernet Tag: Used to represent a BD that is configured on a given ES for the purpose of DF election. Note that any of the following may be used to represent a BD: VIDs (including Q-in-Q tags), configured IDs, VNIs (Virtual Extensible Local Area Network (VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service Instance Identifiers), etc., as long as the representation of the BDs is configured consistently across the multihomed PEs attached to that ES. The Ethernet Tag value MUST be different from zero.
o イーサネットタグ：DF選出のために特定のESに構成されているBDを表すために使用されます。 BDを表すために次のいずれかを使用できることに注意してください：VID（Q-in-Qタグを含む）、構成済みID、VNI（仮想拡張ローカルエリアネットワーク（VXLAN）ネットワーク識別子）、正規化されたVID、I-SID（サービスインスタンス識別子）など、BDの表現がそのESに接続されているマルチホームPE全体で一貫して構成されている限り。イーサネットタグの値はゼロとは異なる必要があります。
o Ethernet Tag ID: Refers to the identifier used in the EVPN routes defined in [RFC7432]. Its value may be the same as the Ethernet Tag value (see the definition for Ethernet Tag) when advertising routes for VLAN-aware Bundle services. Note that in the case of VLAN-based or VLAN Bundle services, the Ethernet Tag ID is zero.
o イーサネットタグID：[RFC7432]で定義されたEVPNルートで使用される識別子を参照します。 VLAN対応のバンドルサービスのルートをアドバタイズする場合、その値はイーサネットタグの値（イーサネットタグの定義を参照）と同じになる場合があります。 VLANベースまたはVLANバンドルサービスの場合、イーサネットタグIDはゼロであることに注意してください。
o DF election procedure: Also called "DF election". Refers to the process in its entirety, including the discovery of the PEs in the ES, the creation and maintenance of the PE candidate list, and the selection of a PE.
o DF選挙手続き：「DF選挙」とも呼ばれます。 ES内のPEの検出、PE候補リストの作成と保守、およびPEの選択を含む、プロセス全体を指します。
o DF algorithm: A component of the DF election procedure. Strictly refers to the selection of a PE for a given <ES, Ethernet Tag>.
o DFアルゴリズム：DF選出手順のコンポーネント。特定の<ES、イーサネットタグ>のPEの選択を厳密に指します。
o RR: Route Reflector. A network routing component for BGP [RFC4456]. It offers an alternative to the logical full-mesh requirement of the Internal Border Gateway Protocol (IBGP). The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR -- acting as a route reflector server -- rather than peer with every other router in a full mesh. This results in an O(N) peering as opposed to O(N^2).
o RR：ルートリフレクター。 BGP [RFC4456]のネットワークルーティングコンポーネント。これは、Internal Border Gateway Protocol（IBGP）の論理的なフルメッシュ要件の代替手段を提供します。 RRの目的は集中です。複数のBGPルーターは、フルメッシュで他のすべてのルーターとピアリングするのではなく、RR（ルートリフレクターサーバーとして機能）とピアリングできます。これにより、O（N ^ 2）ではなくO（N）ピアリングになります。
o TTL: Time To Live.
o TTL：存続可能時間。
This document also assumes that the reader is familiar with the terminology provided in [RFC7432].
このドキュメントは、読者が[RFC7432]で提供される用語に精通していることも前提としています。
[RFC7432] defines the DF as the EVPN PE responsible for:
[RFC7432]は、DFを以下に責任を持つEVPN PEとして定義します。
o Flooding BUM traffic on a given Ethernet Tag on a particular ES to the CE. This is valid for Single-Active and All-Active EVPN multihoming.
o 特定のES上の特定のイーサネットタグ上のCEへのBUMトラフィックのフラッディング。これは、シングルアクティブおよびオールアクティブEVPNマルチホーミングに有効です。
o Sending unicast traffic on a given Ethernet Tag on a particular ES to the CE. This is valid for Single-Active multihoming.
o 特定のES上の特定のイーサネットタグ上のユニキャストトラフィックをCEに送信します。これは、シングルアクティブマルチホーミングに有効です。
Figure 1 illustrates an example that we will use to explain the DF function.
図1は、DF関数の説明に使用する例を示しています。
+---------------+
| IP/MPLS |
| Core |
+----+ ES1 +----+ +----+
| CE1|-----| | | |____ES2
+----+ | PE1| | PE2| \
| | +----+ \+----+
+----+ | | CE2|
| +----+ /+----+
| | |____/ |
| | PE3| ES2 /
| +----+ /
| | /
+-------------+----+ /
| PE4|____/ES2
| |
+----+
Figure 1: EVPN Multihoming
図1：EVPNマルチホーミング
Figure 1 illustrates a case where there are two ESes: ES1 and ES2. PE1 is attached to CE1 via ES1, whereas PE2, PE3, and PE4 are attached to CE2 via ES2, i.e., PE2, PE3, and PE4 form a redundancy group. Since CE2 is multihomed to different PEs on the same ES, it is necessary for PE2, PE3, and PE4 to agree on a DF to satisfy the above-mentioned requirements.
図1は、ES1とES2の2つのESがある場合を示しています。 PE1はES1を介してCE1に接続され、PE2、PE3、およびPE4はES2を介してCE2に接続されます。つまり、PE2、PE3、およびPE4は冗長グループを形成します。 CE2は同じES上の異なるPEにマルチホーム化されているため、PE2、PE3、およびPE4は、DFについて上記の要件を満たすことに同意する必要があります。
The effect of forwarding loops in a Layer 2 network is particularly severe because of the broadcast nature of Ethernet traffic and the lack of a TTL. Therefore, it is very important that, in the case of a multihomed CE, only one of the PEs be used to send BUM traffic to it.
イーサネットトラフィックのブロードキャストの性質とTTLがないため、レイヤ2ネットワークの転送ループの影響は特に深刻です。したがって、マルチホームCEの場合、BUMトラフィックを送信するために使用されるPEは1つだけであることが非常に重要です。
One of the prerequisites for this support is that participating PEs must agree amongst themselves as to who would act as the DF. This needs to be achieved through a distributed algorithm in which each participating PE independently and unambiguously selects one of the participating PEs as the DF, and the result should be consistent and unanimous.
このサポートの前提条件の1つは、参加しているPEが、DFとして行動することになるメンバーについて合意する必要があることです。これは、参加している各PEが独立して明確に参加しているPEの1つをDFとして選択する分散アルゴリズムによって実現する必要があり、結果は一貫して全会一致でなければなりません。
The default algorithm for DF election defined by [RFC7432] at the granularity of (ESI, EVI) is referred to as "service carving". In this document, service carving and the default DF election algorithm are used interchangeably. With service carving, it is possible to elect multiple DFs per ES (one per EVI) in order to perform load balancing of traffic destined to a given ES. The objective is that the load-balancing procedures should carve up the BD space among the redundant PE nodes evenly, in such a way that every PE is the DF for a distinct set of EVIs.
[ESI、EVI）の粒度で[RFC7432]によって定義されたDF選出のデフォルトアルゴリズムは、「サービスカービング」と呼ばれます。このドキュメントでは、サービスカービングとデフォルトのDF選出アルゴリズムを同じ意味で使用しています。サービスカービングを使用すると、特定のESを宛先とするトラフィックのロードバランシングを実行するために、ESごとに複数のDF（EVIごとに1つ）を選択できます。目的は、負荷分散手順により、冗長PEノード間のBDスペースを均等に分割し、すべてのPEが個別のEVIセットのDFになるようにすることです。
The DF election algorithm (as described in [RFC7432], Section 8.5) is based on a modulus operation. The PEs to which the ES (for which DF election is to be carried out per EVI) is multihomed form an ordered (ordinal) list in ascending order by PE IP address value. For example, there are N PEs: PE0, PE1,... PE(N-1) ranked as per increasing IP addresses in the ordinal list; then, for each VLAN with Ethernet Tag V, configured on ES1, PEx is the DF for VLAN V on ES1 when x equals (V mod N). In the case of a VLAN Bundle, only the lowest VLAN is used. In the case when the planned density is high (meaning there are a significant number of VLANs and the Ethernet Tags are uniformly distributed), the thinking is that the DF election will be spread across the PEs hosting that ES and good load balancing can be achieved.
DF選出アルゴリズム（[RFC7432]、セクション8.5で説明）は、モジュラス演算に基づいています。 ES（DF選出はEVIごとに実行される）がマルチホーム化されているPEは、PE IPアドレス値の昇順で順序付き（順序）リストを形成します。たとえば、N個のPEがあります。PE0、PE1、... PE（N-1）は、序数リストのIPアドレスの増加に従ってランク付けされます。次に、ES1で構成されたイーサネットタグVの各VLANについて、xが（V mod N）に等しい場合、PExはES1のVLAN VのDFです。 VLANバンドルの場合、最も低いVLANのみが使用されます。計画密度が高い場合（つまり、多数のVLANがあり、イーサネットタグが均一に分散されている場合）、DFの選定は、ESをホストしているPE全体に分散され、適切なロードバランシングを実現できると考えられています。 。
However, the described default DF election algorithm has some undesirable properties and, in some cases, can be somewhat disruptive and unfair. This document describes some of those issues and defines a mechanism for dealing with them. These mechanisms do involve changes to the default DF election algorithm, but they do not require any changes to the EVPN route exchange, and changes in the EVPN routes will be minimal.
ただし、説明されているデフォルトのDF選出アルゴリズムにはいくつかの望ましくない特性があり、場合によっては、やや破壊的で不公平になることがあります。このドキュメントでは、これらの問題のいくつかを説明し、それらに対処するためのメカニズムを定義します。これらのメカニズムには、デフォルトのDF選択アルゴリズムの変更が含まれますが、EVPNルート交換に変更を加える必要はなく、EVPNルートの変更は最小限になります。
In addition, there is a need to extend the DF election procedures so that new algorithms and capabilities are possible. A single algorithm (the default DF election algorithm) may not meet the requirements in all the use cases.
さらに、DF選出手順を拡張して、新しいアルゴリズムと機能を可能にする必要があります。単一のアルゴリズム（デフォルトのDF選出アルゴリズム）は、すべてのユースケースで要件を満たしていない場合があります。
Note that while [RFC7432] elects a DF per <ES, EVI>, this document elects a DF per <ES, BD>. This means that unlike [RFC7432], where for a VLAN-aware Bundle service EVI there is only one DF for the EVI, this document specifies that there will be multiple DFs, one for each BD configured in that EVI.
[RFC7432]は<ES、EVI>ごとにDFを選出していますが、このドキュメントは<ES、BD>ごとにDFを選出しています。つまり、[RFC7432]とは異なり、VLAN対応のバンドルサービスEVIの場合、EVIのDFは1つだけですが、このドキュメントでは、そのEVIで構成されている各BDに1つずつ、複数のDFがあることを指定しています。
This section describes some potential issues with the default DF election algorithm.
このセクションでは、デフォルトのDF選出アルゴリズムに関するいくつかの潜在的な問題について説明します。
There are three fundamental problems with the current default DF election algorithm.
現在のデフォルトのDF選出アルゴリズムには、3つの根本的な問題があります。
1. The algorithm will not perform well when the Ethernet Tag follows a non-uniform distribution -- for instance, when the Ethernet Tags are all even or all odd. In such a case, let us assume that the ES is multihomed to two PEs; one of the PEs will be elected as the DF for all of the VLANs. This is very suboptimal. It defeats the purpose of service carving, as the DFs are not really evenly spread across the PEs hosting the ES. In fact, in this particular case, one of the PEs does not get elected as the DF at all, so it does not participate in DF responsibilities at all. Consider another example where, referring to Figure 1, let's assume that (1) PE2, PE3, and PE4 are listed in ascending order by IP address and (2) each VLAN configured on ES2 is associated with an Ethernet Tag of the form (3x+1), where x is an integer. This will result in PE3 always being selected as the DF.
1. アルゴリズムは、イーサネットタグが不均一な分布に従う場合、たとえば、イーサネットタグがすべて偶数またはすべて奇数である場合、うまく機能しません。そのような場合、ESが2つのPEにマルチホーム化されていると仮定します。 PEの1つがすべてのVLANのDFとして選出されます。これは非常に最適ではありません。 DFは実際にはESをホストするPE全体に均等に分散されていないため、サービスカービングの目的に反します。実際、この特定のケースでは、PEの1つがDFとして選出されることがまったくないため、DFの責任にはまったく関与しません。図1を参照して、（1）PE2、PE3、およびPE4がIPアドレスの昇順でリストされ、（2）ES2で構成された各VLANが（3x +1）、ここでxは整数です。これにより、常にPE3がDFとして選択されます。
2. The Ethernet Tag that identifies the BD can be as large as 2^24; however, it is not guaranteed that the tenant BD on the ES will conform to a uniform distribution. In fact, it is up to the customer what BDs they will configure on the ES. Quoting [Knuth]:
2. BDを識別するイーサネットタグは、最大2 ^ 24です。ただし、ES上のテナントBDが均一な分布に準拠することは保証されていません。実際、ESでどのBDを構成するかはお客様次第です。引用[Knuth]：
In general, we want to avoid values of M that divide r^k+a or r^k-a, where k and a are small numbers and r is the radix of the alphabetic character set (usually r=64, 256 or 100), since a remainder modulo such a value of M tends to be largely a simple superposition of key digits. Such considerations suggest that we choose M to be a prime number such that r^k!=a(modulo)M or r^k!=?a(modulo)M for small k & a.
一般的に、r ^ k + aまたはr ^ kaを分割するMの値は避けたいとします。ここで、kとaは小さな数で、rはアルファベット文字セットの基数です（通常はr = 64、256または100）。このようなMの値を法とする剰余は、主にキーディジットの単純な重ね合わせになる傾向があるためです。そのような考慮事項は、小さなk＆aに対してr ^ k！= a（modulo）Mまたはr ^ k！=？a（modulo）Mのような素数になるようにMを選択することを示唆しています。
In our case, N is the number of PEs (Section 8.5 of [RFC7432]). N corresponds to M above. Since N, N-1, or N+1 need not satisfy the primality properties of M, as per the modulo-based DF assignment [RFC7432], whenever a PE goes down or a new PE boots up (attached to the same ES), the modulo scheme will not necessarily map BDs to PEs uniformly.
私たちの場合、NはPEの数です（[RFC7432]のセクション8.5）。 Nは上記のMに対応します。モジュロベースのDF割り当て[RFC7432]のように、N、N-1、またはN + 1は、PEがダウンするか、新しいPEが起動する（同じESに接続される）たびに、Mの素数特性を満たす必要はありません。 、モジュロスキームは、BDをPEに均一にマッピングする必要はありません。
3. Disruption is another problem. Consider a case when the same ES is multihomed to a set of PEs. When the ES is DOWN in one of the PEs, say PE1, or PE1 itself reboots, or the BGP process goes down or the connectivity between PE1 and an RR goes down, the effective number of PEs in the system now becomes N-1, and DFs are computed for all the VLANs that are configured on that ES. In general, if the DF for a VLAN V happens not to be PE1, but some other PE, say PE2, it is likely that some other PE (different from PE1 and PE2) will become the new DF. This is not desirable. Similarly, when a new PE hosts the same ES, the mapping again changes because of the modulus operation. This results in needless churn. Again referring to Figure 1, say V1, V2, and V3 are VLANs configured on ES2 with associated Ethernet Tags of values 999, 1000, and 1001, respectively. So, PE1, PE2, and PE3 are the DFs for V1, V2, and V3, respectively. Now when PE3 goes down, PE2 will become the DF for V1 and PE1 will become the DF for V2.
3. 混乱は別の問題です。同じESがPEのセットにマルチホーム化されている場合を考えます。 PEの1つでESがダウンしている場合、たとえばPE1、またはPE1自体が再起動した場合、またはBGPプロセスがダウンした場合、またはPE1とRR間の接続がダウンした場合、システム内のPEの有効数はN-1になります。 DFは、そのESで構成されているすべてのVLANに対して計算されます。一般に、VLAN VのDFがPE1ではなく、PE2などの他のPEである場合、他のPE（PE1およびPE2とは異なる）が新しいDFになる可能性があります。これは望ましくありません。同様に、新しいPEが同じESをホストしている場合、モジュラス演算のため、マッピングは再び変更されます。これにより、不必要なチャーンが発生します。再び図1を参照すると、V1、V2、およびV3は、それぞれ値999、1000、および1001のイーサネットタグが関連付けられたES2で構成されたVLANであるとします。したがって、PE1、PE2、およびPE3は、それぞれV1、V2、およびV3のDFです。 PE3がダウンすると、PE2がV1のDFになり、PE1がV2のDFになります。
One point to note is that the default DF election algorithm assumes that all the PEs who are multihomed to the same ES (and interested in the DF election by exchanging EVPN routes) use an Originating Router's IP address [RFC7432] of the same family. This does not need to be the case, as the EVPN address family can be carried over an IPv4 or IPv6 peering, and the PEs attached to the same ES may use an address of either family.
注意すべき点の1つは、デフォルトのDF選定アルゴリズムは、同じESにマルチホーム化されている（そしてEVPNルートを交換することによってDF選定に関心がある）すべてのPEが同じファミリーの発信ルーターのIPアドレス[RFC7432]を使用することを前提としていることです。 EVPNアドレスファミリーはIPv4またはIPv6ピアリングで伝送でき、同じESに接続されたPEはどちらかのファミリーのアドレスを使用する可能性があるため、これは当てはまる必要はありません。
Mathematically, a conventional hash function maps a key k to a number i representing one of m hash buckets through a function h(k), i.e., i = h(k). In the EVPN case, h is simply a modulo-m hash function viz. h(V) = V mod N, where N is the number of PEs that are multihomed to the ES in question. It is well known that for good hash distribution using the modulus operation, the modulus N should be a prime number not too close to a power of 2 [CLRS2009]. When the effective number of PEs changes from N to N-1 (or vice versa), all the objects (VLAN V) will be remapped except those for which V mod N and V mod (N-1) refer to the same PE in the previous and subsequent ordinal rankings, respectively. From a forwarding perspective, this is a churn, as it results in reprogramming the PE ports as either blocking or non-blocking at the PEs where the DF state changes.
数学的には、従来のハッシュ関数は、関数h（k）を介して、キーkをm個のハッシュバケットの1つを表す番号iにマッピングします。つまり、i = h（k）です。 EVPNの場合、hは単にmodulo-mハッシュ関数vizです。 h（V）= V mod N、ここでNは問題のESにマルチホーム化されているPEの数です。モジュラス演算を使用した良好なハッシュ分布の場合、モジュラスNは2の累乗に近すぎない素数でなければならないことはよく知られています[CLRS2009]。 PEの実効数がNからN-1（またはその逆）に変更されると、V mod NおよびV mod（N-1）が同じPEを参照するオブジェクトを除くすべてのオブジェクト（VLAN V）が再マッピングされます以前とその後の序数ランキング。フォワーディングの観点からは、これはチャーンです。これは、DF状態が変化するPEで、PEポートをブロッキングまたは非ブロッキングとして再プログラミングするためです。
This document addresses this problem and furnishes a solution to this undesirable behavior.
このドキュメントでは、この問題に対処し、この望ましくない動作の解決策を提供します。
The default DF election algorithm defined by [RFC7432] takes into account only two variables in the modulus function for a given ES: the existence of the PE's IP address in the candidate list and the locally provisioned Ethernet Tags.
[RFC7432]で定義されているデフォルトのDF選択アルゴリズムは、所定のESの係数関数の2つの変数のみを考慮します。候補リスト内のPEのIPアドレスの存在とローカルにプロビジョニングされたイーサネットタグです。
If the DF for an <ESI, EVI> fails (due to physical link/node failures), an ES route withdrawal will make the NDF PEs re-elect the DF for that <ESI, EVI> and the service will be recovered.
<ESI、EVI>のDFに障害が発生した場合（物理リンク/ノードの障害により）、ESルートの撤回により、NDF PEはその<ESI、EVI>のDFを再選し、サービスが回復します。
However, the default DF election procedure does not provide protection against "logical" failures or human errors that may occur at the service level on the DF, while the list of active PEs for a given ES does not change. These failures may have an impact not only on the local PE where the issue happens but also on the rest of the PEs of the ES. Some examples of such logical failures are listed below:
ただし、デフォルトのDF選出手順では、DFのサービスレベルで発生する可能性のある「論理的な」障害や人的エラーに対する保護は提供されませんが、特定のESのアクティブなPEのリストは変更されません。これらの障害は、問題が発生したローカルPEだけでなく、ESの残りのPEにも影響を与える可能性があります。このような論理的な障害のいくつかの例を以下に示します。
(a) A given individual AC defined in an ES is accidentally shut down or is not provisioned yet (hence, the ACS is DOWN), while the ES is operationally active (since the ES route is active).
（a）ESが運用上アクティブな間（ESルートがアクティブであるため）、ESで定義された特定のACが誤ってシャットダウンされたか、まだプロビジョニングされていない（そのため、ACSがダウンしている）。
(b) A given MAC-VRF with a defined ES is either shut down or not provisioned yet, while the ES is operationally active (since the ES route is active). In this case, the ACS of all the ACs defined in that MAC-VRF is considered to be DOWN.
（b）ESが運用上アクティブな間（ESルートがアクティブであるため）、ESが定義された特定のMAC-VRFはシャットダウンされているか、まだプロビジョニングされていません。この場合、そのMAC-VRFで定義されているすべてのACのACSはダウンしていると見なされます。
Neither (a) nor (b) will trigger the DF re-election on the remote multihomed PEs for a given ES, since the ACS is not taken into account in the DF election procedures. While the ACS is used as a DF election tiebreaker and trigger in Virtual Private LAN Service (VPLS) multihoming procedures [VPLS-MH], there is no procedure defined in the EVPN specification [RFC7432] to trigger the DF re-election based on the ACS change on the DF.
ACSはDF選出手順で考慮されないため、（a）も（b）も、特定のESのリモートマルチホームPEでDF再選をトリガーすることはありません。 ACSはDF選挙タイブレーカーとして使用され、仮想プライベートLANサービス（VPLS）マルチホーミング手順[VPLS-MH]でトリガーしますが、EVPN仕様[RFC7432]で定義されている手順に基づいて、DF再選をトリガーします。 DFのACS変更。
Figure 2 shows an example of logical AC failure.
図2は、論理AC障害の例を示しています。
+---+
|CE4|
+---+
|
PE4 |
+-----+-----+
+---------------| +-----+ |---------------+
| | | BD-1| | |
| +-----------+ |
| |
| EVPN |
| |
| PE1 PE2 PE3 |
| (NDF) (DF) (NDF)|
+-----------+ +-----------+ +-----------+
| | BD-1| | | | BD-1| | | | BD-1| |
| +-----+ |-------| +-----+ |-------| +-----+ |
+-----------+ +-----------+ +-----------+
AC1\ ES12 /AC2 AC3\ ES23 /AC4
\ / \ /
\ / \ /
+----+ +----+
|CE12| |CE23|
+----+ +----+
Figure 2: Default DF Election and Traffic Black-Holing
図2：デフォルトのDF選出とトラフィックのブラックホール化
BD-1 is defined in PE1, PE2, PE3, and PE4. CE12 is a multihomed CE connected to ES12 in PE1 and PE2. Similarly, CE23 is multihomed to PE2 and PE3 using ES23. Both CE12 and CE23 are connected to BD-1 through VLAN-based service interfaces: CE12-VID 1 (VID 1 on CE12) is associated with AC1 and AC2 in BD-1, whereas CE23-VID 1 is associated with AC3 and AC4 in BD-1. Assume that, although not represented, there are other ACs defined on these ESes mapped to different BDs.
BD-1は、PE1、PE2、PE3、およびPE4で定義されています。 CE12は、PE1およびPE2のES12に接続されたマルチホームCEです。同様に、CE23はES23を使用してPE2およびPE3にマルチホーム化されています。 CE12とCE23の両方がVLANベースのサービスインターフェイスを介してBD-1に接続されています。CE12-VID1（CE12のVID 1）はBD-1のAC1とAC2に関連付けられていますが、CE23-VID 1はAC3とAC4に関連付けられています。 BD-1。表示されていませんが、異なるBDにマップされたこれらのESで定義された他のACがあると仮定します。
After executing the default DF election algorithm as described in [RFC7432], PE2 turns out to be the DF for ES12 and ES23 in BD-1. The following issues may arise:
[RFC7432]で説明されているデフォルトのDF選択アルゴリズムを実行した後、PE2はBD-1のES12およびES23のDFであることがわかります。次の問題が発生する可能性があります。
(a) If AC2 is accidentally shut down or is not configured yet, CE12 traffic will be impacted. In the case of All-Active multihoming, the BUM traffic to CE12 will be "black-holed", whereas for Single-Active multihoming, all the traffic to/from CE12 will be discarded. This is because a logical failure in PE2's AC2 may not trigger an ES route withdrawal for ES12 (since there are still other ACs active on ES12); therefore, PE1 will not rerun the DF election procedures.
（a）AC2が誤ってシャットダウンされたか、まだ構成されていない場合、CE12トラフィックが影響を受けます。オールアクティブマルチホーミングの場合、CE12へのBUMトラフィックは「ブラックホール化」されますが、シングルアクティブマルチホーミングの場合、CE12へ/からのトラフィックはすべて破棄されます。これは、PE2のAC2で論理的な障害が発生しても、ES12のESルートの撤回がトリガーされない場合があるためです（ES12で他のACがまだアクティブであるため）。したがって、PE1はDF選挙手続きを再実行しません。
(b) If the bridge table for BD-1 is administratively shut down or is not configured yet on PE2, CE12 and CE23 will both be impacted: BUM traffic to both CEs will be discarded in the case of All-Active multihoming, and all traffic will be discarded to/from the CEs in the case of Single-Active multihoming. This is because PE1 and PE3 will not rerun the DF election procedures and will keep assuming that PE2 is the DF.
（b）BD-1のブリッジテーブルが管理上シャットダウンされているか、PE2でまだ構成されていない場合、CE12とCE23の両方が影響を受けます。オールアクティブマルチホーミングの場合、両方のCEへのBUMトラフィックが破棄され、すべてシングルアクティブマルチホーミングの場合、トラフィックはCEとの間で破棄されます。これは、PE1とPE3がDF選出手順を再実行せず、PE2がDFであると想定し続けるためです。
Quoting [RFC7432], "When an Ethernet tag is decommissioned on an Ethernet segment, then the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for the <ESI, Ethernet tags> that are impacted by the decommissioning." However, while this A-D per EVI route withdrawal is used at the remote PEs performing aliasing or backup procedures, it is not used to influence the DF election for the affected EVIs.
[RFC7432]を引用すると、「イーサネットセグメントでイーサネットタグが廃止された場合、PEは廃止の影響を受ける<ESI、イーサネットタグ>に対してアナウンスされたEVIルートごとにイーサネットA-Dを撤回する必要があります。」ただし、このA-D / EVIルートの撤回は、エイリアスまたはバックアップ手順を実行するリモートPEで使用されますが、影響を受けるEVIのDF選定に影響を与えるためには使用されません。
This document adds an optional modification of the DF election procedure so that the ACS may be taken into account as a variable in the DF election; therefore, EVPN can provide protection against logical failures.
このドキュメントでは、DF選挙手順のオプションの変更を追加して、ACSがDF選挙の変数として考慮されるようにしています。したがって、EVPNは論理的な障害に対する保護を提供できます。
Section 1.3 describes some of the issues that exist in the default DF election procedures. In order to address those issues, this document introduces a new DF election framework. This framework allows the PEs to agree on a common DF election algorithm, as well as the capabilities to enable during the DF election procedure. Generally, "DF election algorithm" refers to the algorithm by which a number of input parameters are used to determine the DF PE, while "DF election capability" refers to an additional feature that can be used prior to the invocation of the DF election algorithm, such as modifying the inputs (or list of candidate PEs).
セクション1.3では、デフォルトのDF選出手順に存在するいくつかの問題について説明します。これらの問題に対処するために、このドキュメントでは新しいDF選挙フレームワークを紹介します。このフレームワークにより、PEは共通のDF選出アルゴリズム、およびDF選出手順中に有効にする機能について合意することができます。一般に、「DF選定アルゴリズム」とは、DF PEを決定するためにいくつかの入力パラメーターを使用するアルゴリズムを指し、「DF選定機能」とは、DF選定アルゴリズムの呼び出し前に使用できる追加機能を指します。入力（または候補PEのリスト）の変更など。
Within this framework, this document defines a new DF election algorithm and a new capability that can influence the DF election result:
このフレームワーク内で、このドキュメントは、DF選挙結果に影響を与える可能性のある新しいDF選挙アルゴリズムと新しい機能を定義します。
o The new DF election algorithm is referred to as "Highest Random Weight" (HRW). The HRW procedures are described in Section 3.
o 新しいDF選出アルゴリズムは「最高ランダムウェイト」（HRW）と呼ばれます。 HRWの手順については、セクション3で説明します。
o The new DF election capability is referred to as "AC-Influenced DF election" (AC-DF). The AC-DF procedures are described in Section 4.
o 新しいDF選挙機能は、「ACに影響されるDF選挙」（AC-DF）と呼ばれます。 AC-DFの手順については、セクション4で説明します。
o HRW and AC-DF mechanisms are independent of each other. Therefore, a PE may support either HRW or AC-DF independently or may support both of them together. A PE may also support the AC-DF capability along with the default DF election algorithm per [RFC7432].
o HRWとAC-DFのメカニズムは互いに独立しています。したがって、PEはHRWまたはAC-DFのいずれかを個別にサポートすることも、両方を同時にサポートすることもできます。 PEは、[RFC7432]のデフォルトのDF選出アルゴリズムとともにAC-DF機能もサポートする場合があります。
In addition, this document defines a way to indicate the support of HRW and/or AC-DF along with the EVPN ES routes advertised for a given ES. Refer to Section 2.2 for more details.
さらに、このドキュメントでは、特定のESにアドバタイズされるEVPN ESルートとともに、HRWおよび/またはAC-DFのサポートを示す方法を定義します。詳細については、セクション2.2を参照してください。
This section describes the BGP extensions required to support the new DF election procedures. In addition, since the EVPN specification [RFC7432] leaves several questions open as to the precise FSM behavior of the DF election, Section 2.1 precisely describes the intended behavior.
このセクションでは、新しいDF選出手順をサポートするために必要なBGP拡張について説明します。さらに、EVPN仕様[RFC7432]では、DF選挙の正確なFSM動作についていくつかの疑問が残されているため、セクション2.1は意図された動作を正確に説明しています。
Per [RFC7432], the FSM shown in Figure 3 is executed per <ES, VLAN> in the case of VLAN-based service or <ES, [VLANs in VLAN Bundle]> in the case of a VLAN Bundle on each participating PE. Note that the FSM is conceptual. Any design or implementation MUST comply with behavior that is equivalent to the behavior outlined in this FSM.
[RFC7432]に従って、図3に示すFSMは、VLANベースのサービスの場合は<ES、VLAN>ごとに実行され、参加している各PEのVLANバンドルの場合は<ES、[VLANs in VLAN Bundle]>ごとに実行されます。 FSMは概念的なものであることに注意してください。設計または実装は、このFSMで概説されている動作と同等の動作に準拠する必要があります。
VLAN_CHANGE VLAN_CHANGE
RCVD_ES RCVD_ES
LOST_ES LOST_ES
+----+ +-------+
| | | v
| +-+----+ ES_UP ++-------++
+->+ INIT +-------------->+ DF_WAIT |
++-----+ +-------+-+
^ |
+-----------+ | |DF_TIMER
| ANY_STATE +-------+ VLAN_CHANGE |
+-----------+ ES_DOWN +-----------------+ |
| RCVD_ES v v
+--------++ LOST_ES ++------+-+
| DF_DONE +<--------------+ DF_CALC +<-+
+---------+ CALCULATED +-------+-+ |
| |
+----+
VLAN_CHANGE
RCVD_ES
LOST_ES
Figure 3: DF Election Finite State Machine
図3：DF選挙の有限状態マシン
Observe that each EVI is locally configured on each of the multihomed PEs attached to a given ES and that the FSM does not provide any protection against inconsistent configuration between these PEs. That is, for a given EVI, one or more of the PEs are inadvertently configured with a different set of VLANs for a VLAN-aware Bundle service or with different VLANs for a VLAN-based service.
各EVIが特定のESに接続された各マルチホームPEでローカルに構成され、FSMがこれらのPE間の矛盾した構成に対する保護を提供しないことを確認します。つまり、特定のEVIの場合、1つ以上のPEが、VLAN対応のバンドルサービスでは異なるVLANセットで、またはVLANベースのサービスでは異なるVLANで誤って設定されます。
The states and events shown in Figure 3 are defined as follows.
図3に示す状態とイベントは、次のように定義されます。
States:
状態：
1. INIT: Initial state.
1. INIT：初期状態。
2. DF_WAIT: State in which the participant waits for enough information to perform the DF election for the EVI/ESI/VLAN combination.
2. DF_WAIT：参加者がEVI / ESI / VLANの組み合わせのDF選出を実行するのに十分な情報を待つ状態。
3. DF_CALC: State in which the new DF is recomputed.
3. DF_CALC：新しいDFが再計算される状態。
4. DF_DONE: State in which the corresponding DF for the EVI/ESI/VLAN combination has been elected.
4. DF_DONE：EVI / ESI / VLANの組み合わせに対応するDFが選択された状態。
5. ANY_STATE: Refers to any of the above states.
5. ANY_STATE：上記のいずれかの状態を指します。
Events:
イベント：
1. ES_UP: The ES has been locally configured as "UP".
1. ES_UP：ESはローカルで「UP」として構成されています。
2. ES_DOWN: The ES has been locally configured as "DOWN".
2. ES_DOWN：ESはローカルで「DOWN」として構成されています。
3. VLAN_CHANGE: The VLANs configured in a bundle (that uses the ES) changed. This event is necessary for VLAN Bundles only.
3. VLAN_CHANGE：バンドルで構成された（ESを使用する）VLANが変更されました。このイベントは、VLANバンドルにのみ必要です。
4. DF_TIMER: DF timer [RFC7432] (referred to as "Wait timer" in this document) has expired.
4. DF_TIMER：DFタイマー[RFC7432]（このドキュメントでは「待機タイマー」と呼ばれます）が期限切れです。
5. RCVD_ES: A new or changed ES route is received in an Update message with an MP_REACH_NLRI. Receiving an unchanged Update MUST NOT trigger this event.
5. RCVD_ES：新規または変更されたESルートは、MP_REACH_NLRIを含む更新メッセージで受信されます。変更されていないUpdateを受信しても、このイベントをトリガーしてはなりません。
6. LOST_ES: An Update message with an MP_UNREACH_NLRI for a previously received ES route has been received. If such a message is seen for a route that has not been advertised previously, the event MUST NOT be triggered.
6. LOST_ES：以前に受信したESルートのMP_UNREACH_NLRIを含む更新メッセージを受信しました。以前にアドバタイズされていないルートでこのようなメッセージが表示された場合、イベントをトリガーしてはなりません（MUST NOT）。
7. CALCULATED: DF has been successfully calculated.
7. 計算済み：DFは正常に計算されました。
Corresponding actions when transitions are performed or states are entered/exited:
遷移が実行されたとき、または状態が開始/終了したときの対応するアクション：
1. ANY_STATE on ES_DOWN: (i) Stop the DF Wait timer. (ii) Assume an NDF for the local PE.
1. ES_DOWNのANY_STATE：（i）DF待機タイマーを停止します。 （ii）ローカルPEのNDFを想定します。
2. INIT on ES_UP: Transition to DF_WAIT.
2. ES_UPのINIT：DF_WAITへの移行。
3. INIT on VLAN_CHANGE, RCVD_ES, or LOST_ES: Do nothing.
3. VLAN_CHANGE、RCVD_ES、またはLOST_ESのINIT：何もしません。
4. DF_WAIT on entering the state: (i) Start the DF Wait timer if not started already or expired. (ii) Assume an NDF for the local PE.
4. 状態に入ったときのDF_WAIT：（i）DF開始タイマーがまだ開始されていないか期限切れでない場合は開始します。 （ii）ローカルPEのNDFを想定します。
5. DF_WAIT on VLAN_CHANGE, RCVD_ES, or LOST_ES: Do nothing.
5. VLAN_CHANGE、RCVD_ES、またはLOST_ESのDF_WAIT：何もしません。
6. DF_WAIT on DF_TIMER: Transition to DF_CALC.
6. DF_TIMERのDF_WAIT：DF_CALCへの移行。
7. DF_CALC on entering or re-entering the state: (i) Rebuild the candidate list, perform a hash, and perform the election. (ii) Afterwards, the FSM generates a CALCULATED event against itself.
7. 状態の開始または再入力時のDF_CALC：（i）候補リストを再構築し、ハッシュを実行して、選挙を実行します。 （ii）その後、FSMは自身に対してCALCULATEDイベントを生成します。
8. DF_CALC on VLAN_CHANGE, RCVD_ES, or LOST_ES: Do as prescribed in Transition 7.
8. VLAN_CHANGE、RCVD_ES、またはLOST_ESのDF_CALC：移行7の規定どおりに実行します。
9. DF_CALC on CALCULATED: Mark the election result for the VLAN or bundle, and transition to DF_DONE.
9. 計算済みのDF_CALC：VLANまたはバンドルの選出結果をマークし、DF_DONEに移行します。
10. DF_DONE on exiting the state: If a new DF election is triggered and the current DF is lost, then assume an NDF for the local PE for the VLAN or VLAN Bundle.
10. 状態の終了時のDF_DONE：新しいDF選出がトリガーされ、現在のDFが失われた場合、VLANまたはVLANバンドルのローカルPEのNDFを想定します。
11. DF_DONE on VLAN_CHANGE, RCVD_ES, or LOST_ES: Transition to DF_CALC.
11. VLAN_CHANGE、RCVD_ES、またはLOST_ESのDF_DONE：DF_CALCへの移行。
The above events and transitions are defined for the default DF election algorithm. As described in Section 4, the use of the AC-DF capability introduces additional events and transitions.
上記のイベントと遷移は、デフォルトのDF選出アルゴリズムに対して定義されています。セクション4で説明したように、AC-DF機能を使用すると、追加のイベントと遷移が発生します。
For the DF election procedures to be consistent and unanimous, it is necessary that all the participating PEs agree on the DF election algorithm and capabilities to be used. For instance, it is not possible for some PEs to continue to use the default DF election algorithm while some PEs use HRW. For brownfield deployments and for interoperability with legacy PEs, it is important that all PEs have the ability to fall back on the default DF election. A PE can indicate its willingness to support HRW and/or AC-DF by signaling a DF Election Extended Community along with the ES route (Route Type 4).
DF選出手順が一貫して満場一致であるためには、参加するすべてのPEが、使用されるDF選出アルゴリズムと機能に同意する必要があります。たとえば、一部のPEがHRWを使用している間、一部のPEはデフォルトのDF選出アルゴリズムを引き続き使用できません。ブラウンフィールド展開の場合、およびレガシーPEとの相互運用性の場合、すべてのPEがデフォルトのDF選出にフォールバックできることが重要です。 PEは、ESルート（ルートタイプ4）と共にDF選挙拡張コミュニティに信号を送ることにより、HRWやAC-DFをサポートする意思を示すことができます。
The DF Election Extended Community is a new BGP transitive Extended Community attribute [RFC4360] that is defined to identify the DF election procedure to be used for the ES. Figure 4 shows the encoding of the DF Election Extended Community.
DF選挙拡張コミュニティは、ESに使用するDF選挙手順を識別するために定義された新しいBGP推移拡張コミュニティ属性[RFC4360]です。図4は、DF Election Extended Communityのエンコードを示しています。
0 1 2 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DF Election Extended Community
図4：DF選挙拡張コミュニティ
Where:
ただし：
o Type: 0x06, as registered with IANA (Section 7) for EVPN Extended Communities.
o タイプ：0x06、EVPN拡張コミュニティのIANA（セクション7）に登録済み。
o Sub-Type: 0x06. "DF Election Extended Community", as registered with IANA.
o サブタイプ：0x06。 「DF Election Extended Community」、IANAに登録済み。
o RSV/Reserved: Reserved bits for information that is specific to DF Alg.
o RSV /予約済み：DF Algに固有の情報のための予約済みビット。
o DF Alg (5 bits): Encodes the DF election algorithm values (between 0 and 31) that the advertising PE desires to use for the ES. This document creates an IANA registry called "DF Alg" (Section 7), which contains the following values:
o DF Alg（5ビット）：アドバタイジングPEがESに使用したいDF選定アルゴリズム値（0〜31）をエンコードします。このドキュメントは、次の値を含む「DF Alg」（セクション7）と呼ばれるIANAレジストリを作成します。
- Type 0: Default DF election algorithm, or modulus-based algorithm as defined in [RFC7432].
- タイプ0：デフォルトのDF選出アルゴリズム、または[RFC7432]で定義されている係数ベースのアルゴリズム。
- Type 1: HRW Algorithm (Section 3).
- タイプ1：HRWアルゴリズム（セクション3）。
- Types 2-30: Unassigned.
- タイプ2〜30：未割り当て。
- Type 31: Reserved for Experimental Use.
- タイプ31：実験用に予約済み。
o Bitmap (2 octets): Encodes "capabilities" to use with the DF election algorithm in the DF Alg field. This document creates an IANA registry (Section 7) for the Bitmap field, with values 0-15. This registry is called "DF Election Capabilities" and includes the bit values listed below.
o ビットマップ（2オクテット）：DF AlgフィールドのDF選出アルゴリズムで使用する「機能」をエンコードします。このドキュメントでは、ビットマップフィールドのIANAレジストリ（セクション7）を作成し、値を0〜15にします。このレジストリは「DF選挙機能」と呼ばれ、以下のビット値が含まれています。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Bitmap Field in the DF Election Extended Community
図5：DF選挙拡張コミュニティのビットマップフィールド
- Bit 0 (corresponds to Bit 24 of the DF Election Extended Community): Unassigned.
- ビット0（DF選挙拡張コミュニティのビット24に対応）：未割り当て。
- Bit 1: AC-DF Capability (AC-Influenced DF election; see Section 4). When set to 1, it indicates the desire to use AC-DF with the rest of the PEs in the ES.
- ビット1：AC-DF機能（ACの影響を受けるDFの選択。セクション4を参照）。 1に設定されている場合、ES内の残りのPEでAC-DFを使用したいことを示します。
- Bits 2-15: Unassigned.
- ビット2〜15：未割り当て。
The DF Election Extended Community is used as follows:
DF選挙拡張コミュニティは次のように使用されます。
o A PE SHOULD attach the DF Election Extended Community to any advertised ES route, and the Extended Community MUST be sent if the ES is locally configured with a DF election algorithm other than the default DF election algorithm or if a capability is required to be used. In the Extended Community, the PE indicates the desired "DF Alg" algorithm and "Bitmap" capabilities to be used for the ES.
o PEは、DF Election拡張コミュニティをアドバタイズされたESルートに接続する必要があります。ESがデフォルトのDF選択アルゴリズム以外のDF選択アルゴリズムでローカルに構成されている場合、または機能を使用する必要がある場合は、拡張コミュニティを送信する必要があります。拡張コミュニティでは、PEはESに使用する必要のある「DF Alg」アルゴリズムと「ビットマップ」機能を示します。
- Only one DF Election Extended Community can be sent along with an ES route. Note that the intent is not for the advertising PE to indicate all the supported DF election algorithms and capabilities but to signal the preferred one.
- ESルートと一緒に送信できるDF Election Extended Communityは1つだけです。広告PEがサポートされているすべてのDF選出アルゴリズムと機能を示すのではなく、優先するものを通知することを意図していることに注意してください。
- DF Alg values 0 and 1 can both be used with Bit 1 (AC-DF) set to 0 or 1.
- DF Alg値0と1はどちらも、ビット1（AC-DF）を0または1に設定して使用できます。
- In general, a specific DF Alg SHOULD determine the use of the reserved bits in the Extended Community, which may be used in a different way for a different DF Alg. In particular, for DF Alg values 0 and 1, the reserved bits are not set by the advertising PE and SHOULD be ignored by the receiving PE.
- 一般に、特定のDF Algは拡張コミュニティで予約済みビットの使用を決定する必要があります（SHOULD）。これは、異なるDF Algに対して異なる方法で使用できます。特に、DF Alg値0および1の場合、予約済みビットはアドバタイジングPEによって設定されず、受信PEによって無視されるべきです（SHOULD）。
o When a PE receives the ES routes from all the other PEs for the ES in question, it checks to see if all the advertisements have the Extended Community with the same DF Alg and Bitmap:
o PEは問題のESの他のすべてのPEからESルートを受信すると、すべてのアドバタイズメントに同じDF Algとビットマップを持つ拡張コミュニティがあるかどうかを確認します。
- If they do, this particular PE MUST follow the procedures for the advertised DF Alg and capabilities. For instance, if all ES routes for a given ES indicate DF Alg HRW and AC-DF set to 1, then the PEs attached to the ES will perform the DF election as per the HRW algorithm and following the AC-DF procedures.
- その場合、この特定のPEは、アドバタイズされたDF Algと機能の手順に従う必要があります。たとえば、特定のESのすべてのESルートがDF Alg HRWおよびAC-DFが1に設定されていることを示している場合、ESに接続されているPEは、HRWアルゴリズムに従って、AC-DF手順に従ってDF選定を実行します。
- Otherwise, if even a single advertisement for Route Type 4 is received without the locally configured DF Alg and capability, the default DF election algorithm MUST be used as prescribed in [RFC7432]. This procedure handles the case where participating PEs in the ES disagree about the DF algorithm and capability to be applied.
- それ以外の場合、ローカルに構成されたDF Algと機能なしでルートタイプ4の単一のアドバタイズメントを受信した場合でも、[RFC7432]で規定されているデフォルトのDF選出アルゴリズムを使用する必要があります。この手順は、ESに参加しているPEがDFアルゴリズムと適用される機能について同意しない場合を扱います。
- The absence of the DF Election Extended Community or the presence of multiple DF Election Extended Communities (in the same route) MUST be interpreted by a receiving PE as an indication of the default DF election algorithm on the sending PE -- that is, DF Alg 0 and no DF election capabilities.
- DF Election Extended Communityが存在しないか、（同じルートに）複数のDF Election Extended Communitiesが存在することは、受信側PEが送信側PEのデフォルトのDF選択アルゴリズムを示すものとして解釈する必要があります-つまり、DF Alg 0およびDF選出機能なし。
o When all the PEs in an ES advertise DF Type 31, they will rely on the local policy to decide how to proceed with the DF election.
o ESのすべてのPEがDFタイプ31をアドバタイズするとき、それらはローカルポリシーに依存して、DF選挙の進め方を決定します。
o For any new capability defined in the future, the applicability/ compatibility of this new capability to/with the existing DF Alg values must be assessed on a case-by-case basis.
o 今後定義される新しい機能については、この新しい機能の既存のDF Alg値への適用性/既存のDF Alg値との互換性は、ケースバイケースで評価する必要があります。
o Likewise, for any new DF Alg defined in the future, its applicability/compatibility to/with the existing capabilities must be assessed on a case-by-case basis.
o 同様に、将来定義される新しいDF Algについても、既存の機能への適用性/既存の機能との互換性は、ケースバイケースで評価する必要があります。
Implementations that comply with [RFC7432] only (i.e., implementations that predate this specification) will not advertise the DF Election Extended Community. That means that all other participating PEs in the ES will not receive DF preferences and will revert to the default DF election algorithm without AC-DF.
[RFC7432]のみに準拠する実装（つまり、この仕様に先行する実装）は、DF選挙拡張コミュニティをアドバタイズしません。つまり、ESに参加している他のすべてのPEはDF設定を受信せず、AC-DFなしのデフォルトのDF選択アルゴリズムに戻ります。
Similarly, an implementation that complies with [RFC7432] only and that receives a DF Election Extended Community will ignore it and will continue to use the default DF election algorithm.
同様に、[RFC7432]のみに準拠し、DF選挙拡張コミュニティを受信する実装は、それを無視し、デフォルトのDF選挙アルゴリズムを引き続き使用します。
The procedure discussed in this section is applicable to the DF election in EVPN services [RFC7432] and the EVPN Virtual Private Wire Service (VPWS) [RFC8214].
このセクションで説明する手順は、EVPNサービス[RFC7432]およびEVPN仮想プライベートワイヤーサービス（VPWS）[RFC8214]でのDF選出に適用されます。
HRW as defined in [HRW1999] is originally proposed in the context of Internet caching and proxy server load balancing. Given an object name and a set of servers, HRW maps a request to a server using the object-name (object-id) and server-name (server-id) rather than the server states. HRW forms a hash out of the server-id and the object-id and forms an ordered list of the servers for the particular object-id. The server for which the hash value is highest serves as the primary server responsible for that particular object, and the server with the next-highest value in that hash serves as the backup server. HRW always maps a given object name to the same server within a given cluster; consequently, it can be used at client sites to achieve global consensus on object-to-server mappings. When that server goes down, the backup server becomes the responsible designate.
[HRW1999]で定義されているHRWは、もともとインターネットキャッシングとプロキシサーバーの負荷分散のコンテキストで提案されています。オブジェクト名とサーバーのセットが与えられると、HRWはサーバーの状態ではなく、オブジェクト名（オブジェクトID）とサーバー名（サーバーID）を使用してリクエストをサーバーにマッピングします。 HRWはサーバーIDとオブジェクトIDからハッシュを形成し、特定のオブジェクトIDのサーバーの順序付きリストを形成します。ハッシュ値が最も高いサーバーが、その特定のオブジェクトを担当するプライマリサーバーとして機能し、そのハッシュで次に値が高いサーバーがバックアップサーバーとして機能します。 HRWは常に、特定のオブジェクト名を特定のクラスター内の同じサーバーにマップします。その結果、クライアントサイトで使用して、オブジェクトからサーバーへのマッピングに関するグローバルな合意を得ることができます。そのサーバーがダウンすると、バックアップサーバーが担当サーバーになります。
Choosing an appropriate hash function that is statistically oblivious to the key distribution and imparts a good uniform distribution of the hash output is an important aspect of the algorithm. Fortunately, many such hash functions exist. [HRW1999] provides
統計的にキー分布に気づかず、ハッシュ出力の良好な均一分布を与える適切なハッシュ関数を選択することは、アルゴリズムの重要な側面です。幸いにも、そのようなハッシュ関数はたくさんあります。 [HRW1999]が提供する
pseudorandom functions based on the Unix utilities rand and srand and easily constructed XOR functions that satisfy the desired hashing properties. HRW already finds use in multicast and ECMP [RFC2991] [RFC2992].
Unixユーティリティrandおよびsrandに基づく疑似ランダム関数、および目的のハッシュプロパティを満たす簡単に構築されたXOR関数。 HRWはすでにマルチキャストとECMPでの使用を見つけています[RFC2991] [RFC2992]。
HRW is not the only algorithm that addresses the object-to-server mapping problem with goals of fair load distribution, redundancy, and fast access. There is another family of algorithms that also addresses this problem; these fall under the umbrella of the Consistent Hashing Algorithms [CHASH]. These will not be considered here.
HRWは、公平な負荷分散、冗長性、高速アクセスを目的としたオブジェクトからサーバーへのマッピングの問題に対処する唯一のアルゴリズムではありません。この問題にも対処するアルゴリズムの別のファミリがあります。これらは、一貫性のあるハッシュアルゴリズム[CHASH]の傘下に入ります。これらはここでは考慮されません。
This section describes the application of HRW to DF election. Let DF(V) denote the DF and BDF(V) denote the BDF for the Ethernet Tag V; Si is the IP address of PE i; Es is the ESI; and Weight is a function of V, Si, and Es.
このセクションでは、DF選挙へのHRWの適用について説明します。イーサネットタグVのDF（V）がDFを示し、BDF（V）がBDFを示します。 SiはPE iのIPアドレスです。 EsはESIです。重量はV、Si、Esの関数です。
Note that while the DF election algorithm provided in [RFC7432] uses a PE address and VLAN as inputs, this document uses an Ethernet Tag, PE address, and ESI as inputs. This is because if the same set of PEs are multihomed to the same set of ESes, then the DF election algorithm used in [RFC7432] would result in the same PE being elected DF for the same set of BDs on each ES; this could have adverse side effects on both load balancing and redundancy. Including an ESI in the DF election algorithm introduces additional entropy, which significantly reduces the probability of the same PE being elected DF for the same set of BDs on each ES. Therefore, when using the HRW algorithm for EVPN DF election, the ESI value in the Weight function below SHOULD be set to that of the corresponding ES.
[RFC7432]で提供されているDF選出アルゴリズムはPEアドレスとVLANを入力として使用しますが、このドキュメントではイーサネットタグ、PEアドレス、およびESIを入力として使用しています。これは、同じPEのセットが同じESのセットにマルチホーム化されている場合、[RFC7432]で使用されるDF選択アルゴリズムにより、各ESの同じBDのセットに対して同じPEがDFとして選択されるためです。これは、負荷分散と冗長性の両方に悪影響を与える可能性があります。 DF選出アルゴリズムにESIを含めると、追加のエントロピーが導入され、各ESの同じBDセットに対して同じPEがDFに選出される確率が大幅に減少します。したがって、HRNアルゴリズムをEVPN DF選択に使用する場合、以下の重み関数のESI値は、対応するESの値に設定する必要があります（SHOULD）。
In the case of a VLAN Bundle service, V denotes the lowest VLAN, similar to the "lowest VLAN in bundle" logic of [RFC7432].
VLANバンドルサービスの場合、Vは最低のVLANを示し、[RFC7432]の「バンドル内の最低のVLAN」ロジックと同様です。
1. DF(V) = Si| Weight(V, Es, Si) >= Weight(V, 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（V）= Si |すべてのjに対して、Weight（V、Es、Si）> = Weight（V、Es、Sj）。同数の場合は、IPアドレスが数値的に最も小さいPEを選択します。 0 <= i、j <冗長グループ内のPEの数であることに注意してください。
2. BDF(V) = Sk| Weight(V, Es, Si) >= Weight(V, Es, Sk), and Weight(V, Es, Sk) >= Weight(V, Es, Sj). In the case of a tie, choose the PE whose IP address is numerically the least.
2. BDF（V）= Sk | Weight（V、Es、Si）> = Weight（V、Es、Sk）、およびWeight（V、Es、Sk）> = Weight（V、Es、Sj）。同数の場合は、IPアドレスが数値的に最も小さいPEを選択します。
Where:
ただし：
o DF(V) is defined to be the address Si (index i) for which Weight(V, Es, Si) is the highest; 0 <= i < N-1.
o DF（V）は、Weight（V、Es、Si）が最も高いアドレスSi（インデックスi）として定義されます。 0 <= i <N-1。
o BDF(V) 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.
o BDF（V）は、DFの重みの次に計算された重みが次に高いアドレスSkを持つPEとして定義されます。 jは0からN-1までの実行インデックスです。 iとkは選択された値です。
Since the Weight is a pseudorandom function with the domain as the three-tuple (V, Es, S), it is an efficient and deterministic algorithm that is independent of the Ethernet Tag V sample space distribution. Choosing a good hash function for the pseudorandom function is an important consideration for this algorithm to perform better than the default algorithm. As mentioned previously, such functions are described in [HRW1999]. We take as a candidate hash function the first one out of the two that are listed as preferred in [HRW1999]:
重みは、ドメインを3タプル（V、Es、S）とする疑似ランダム関数であるため、イーサネットタグVのサンプル空間の分布とは関係なく、効率的で確定的なアルゴリズムです。疑似ランダム関数に適切なハッシュ関数を選択することは、このアルゴリズムがデフォルトのアルゴリズムよりも優れたパフォーマンスを発揮するための重要な考慮事項です。前述のように、このような機能は[HRW1999]に記載されています。 [HRW1999]で推奨されている2つのうち、最初のハッシュ関数を候補として使用します。
Wrand(V, Es, Si) = (1103515245((1103515245.Si+12345) XOR
D(V, Es))+12345)(mod 2^31)
Here, D(V, Es) is the 31-bit digest (CRC-32 and discarding the most significant bit (MSB), as noted in [HRW1999]) of the 14-octet stream (the 4-octet Ethernet Tag V followed by the 10-octet ESI). It is mandated that the 14-octet stream be formed by the concatenation of the Ethernet Tag and the ESI in network byte order. The CRC should proceed as if the stream is in network byte order (big-endian). Si is the address of the ith server. The server's IP address length does not matter, as only the low-order 31 bits are modulo significant.
ここで、D（V、Es）は、14オクテットストリーム（続く4オクテットイーサネットタグV）の31ビットダイジェスト（CRC-32および[HRW1999]に記載されている最上位ビット（MSB）を破棄）です。 10オクテットESIによる）。イーサネットタグとESIをネットワークバイトオーダーで連結することにより、14オクテットストリームを形成することが義務付けられています。 CRCは、ストリームがネットワークバイトオーダー（ビッグエンディアン）であるかのように処理する必要があります。 Siはi番目のサーバーのアドレスです。下位の31ビットのみがモジュロ有意であるため、サーバーのIPアドレスの長さは重要ではありません。
A point to note is that the Weight function takes into consideration the combination of the Ethernet Tag, the ES, and the PE IP address, and the actual length of the server IP address (whether IPv4 or IPv6) is not really relevant. The default algorithm defined in [RFC7432] cannot employ both IPv4 and IPv6 PE addresses, since [RFC7432] does not specify how to decide on the ordering (the ordinal list) when both IPv4 and IPv6 PEs are present.
注意すべき点は、Weight関数はイーサネットタグ、ES、およびPE IPアドレスの組み合わせを考慮し、サーバーIPアドレスの実際の長さ（IPv4またはIPv6）は実際には関係がないということです。 [RFC7432]は、IPv4とIPv6の両方のPEが存在する場合に順序（順序リスト）を決定する方法を指定していないため、[RFC7432]で定義されたデフォルトアルゴリズムはIPv4とIPv6の両方のPEアドレスを使用できません。
HRW solves the disadvantages pointed out in Section 1.3.1 of this document and ensures that:
HRWは、このドキュメントのセクション1.3.1で指摘された欠点を解決し、次のことを保証します。
o With very high probability, the task of DF election for the VLANs configured on an ES is more or less equally distributed among the PEs, even in the case of two PEs (see the first fundamental problem listed in Section 1.3.1).
o 非常に高い確率で、ES上に構成されたVLANのDF選出のタスクは、2つのPEの場合でも、PE間でほぼ均等に分散されます（セクション1.3.1にリストされている最初の基本的な問題を参照）。
o If a PE that is not the DF or the BDF for that VLAN goes down or its connection to the ES goes down, it does not result in a DF or BDF reassignment. This saves computation, especially in the case when the connection flaps.
o そのVLANのDFまたはBDFでないPEがダウンしたり、ESへの接続がダウンしたりしても、DFまたはBDFの再割り当ては行われません。これにより、特に接続がフラップした場合の計算が節約されます。
o More importantly, it avoids the third fundamental problem listed in Section 1.3.1 (needless disruption) that is inherent in the existing default DF election.
o さらに重要なことに、これはセクション1.3.1にリストされている3番目の基本的な問題（不要な混乱）を回避します。
o In addition to the DF, the algorithm also furnishes the BDF, which would be the DF if the current DF fails.
o DFに加えて、アルゴリズムはBDFも提供します。BDFは、現在のDFが失敗した場合にDFになります。
The procedure discussed in this section is applicable to the DF election in EVPN services [RFC7432] and EVPN VPWS [RFC8214].
このセクションで説明する手順は、EVPNサービス[RFC7432]およびEVPN VPWS [RFC8214]でのDF選出に適用されます。
The AC-DF capability is expected to be generally applicable to any future DF algorithm. It modifies the DF election procedures by removing from consideration any candidate PE in the ES that cannot forward traffic on the AC that belongs to the BD. This section is applicable to VLAN-based and VLAN Bundle service interfaces. Section 4.1 describes the procedures for VLAN-aware Bundle service interfaces.
AC-DF機能は、将来のDFアルゴリズムに一般的に適用できると期待されています。 BDに属するAC上のトラフィックを転送できないES内の候補PEを考慮から外すことにより、DF選出手順を変更します。このセクションは、VLANベースおよびVLANバンドルサービスインターフェイスに適用されます。セクション4.1では、VLAN対応バンドルサービスインターフェイスの手順について説明します。
In particular, when used with the default DF algorithm, the AC-DF capability modifies Step 3 in the DF election procedure described in [RFC7432], Section 8.5, as follows:
特に、デフォルトのDFアルゴリズムで使用する場合、AC-DF機能は、[RFC7432]のセクション8.5で説明されているDF選出手順のステップ3を次のように変更します。
3. When the timer expires, each PE builds an ordered candidate list of the IP addresses of all the PE nodes attached to the ES (including itself), in increasing numeric value. The candidate list is based on the Originating Router's IP addresses of the ES routes but excludes any PE from whom no Ethernet A-D per ES route has been received or from whom the route has been withdrawn. Afterwards, the DF election algorithm is applied on a per <ES, Ethernet Tag>; however, the IP address for a PE will not be considered to be a candidate for a given <ES, Ethernet Tag> until the corresponding Ethernet A-D per EVI route has been received from that PE. In other words, the ACS on the ES for a given PE must be UP so that the PE is considered to be a candidate for a given BD.
3. タイマーが期限切れになると、各PEは、ESに接続されているすべてのPEノード（自身を含む）のIPアドレスの順序付けされた候補リストを、増加する数値で作成します。候補リストは、ESルートの発信元ルーターのIPアドレスに基づいていますが、ESルートごとにイーサネットA-Dが受信されなかった、またはルートが撤回されたPEは除外されます。その後、DF選出アルゴリズムが<ES、イーサネットタグ>ごとに適用されます。ただし、PEのIPアドレスは、対応するEVIルートごとのイーサネットA-DがそのPEから受信されるまで、特定の<ES、イーサネットタグ>の候補とは見なされません。つまり、PEが特定のBDの候補と見なされるように、特定のPEのES上のACSはUPである必要があります。
If the default DF algorithm is used, every PE in the resulting candidate list is then given an ordinal indicating its position in the ordered list, starting with 0 as the ordinal for the PE with the numerically lowest IP address. The ordinals are used to determine which PE node will be the DF for a given Ethernet Tag on the ES, using the following rule:
デフォルトのDFアルゴリズムが使用される場合、結果の候補リスト内のすべてのPEには、番号が最も小さいIPアドレスを持つPEの序数として0から始まる、順序付きリストでのその位置を示す序数が与えられます。序数は、次のルールを使用して、ES上の特定のイーサネットタグのDFとなるPEノードを決定するために使用されます。
Assuming a redundancy group of N PE nodes, for VLAN-based service, the PE with ordinal i is the DF for an <ES, Ethernet Tag V> when (V mod N) = i. In the case of a VLAN (-aware) Bundle service, then the numerically lowest VLAN value in that bundle on that ES MUST be used in the modulo function as the Ethernet Tag.
N PEノードの冗長グループを想定すると、VLANベースのサービスでは、（V mod N）= iの場合、序数iのPEが<ES、イーサネットタグV>のDFになります。 VLAN（-aware）バンドルサービスの場合、そのESのバンドル内の数値的に最小のVLAN値は、イーサネットタグとしてモジュロ機能で使用する必要があります。
It should be noted that using the Originating Router's IP Address field [RFC7432] in the ES route to get the PE IP address needed for the ordered list allows for a CE to be multihomed across different Autonomous Systems (ASes) if such a need ever arises.
ESルートで発信元ルーターのIPアドレスフィールド[RFC7432]を使用して順序付きリストに必要なPE IPアドレスを取得すると、必要に応じてCEをさまざまな自律システム（AS）にマルチホーム化できることに注意してください。 。
The modified Step 3, above, differs from [RFC7432], Section 8.5, Step 3 in two ways:
上記の変更されたステップ3は、[RFC7432]、セクション8.5、ステップ3と2つの点で異なります。
o Any DF Alg can be used -- not only the described modulus-based DF Alg (referred to as the default DF election or "DF Alg 0" in this document).
o 説明されている係数ベースのDF Alg（このドキュメントではデフォルトのDF選出または「DF Alg 0」と呼ばれる）だけでなく、任意のDF Algを使用できます。
o The candidate list is pruned based upon non-receipt of Ethernet A-D routes: a PE's IP address MUST be removed from the ES candidate list if its Ethernet A-D per ES route is withdrawn. A PE's IP address MUST NOT be considered to be a candidate DF for an <ES, Ethernet Tag> if its Ethernet A-D per EVI route for the <ES, Ethernet Tag> is withdrawn.
o 候補リストは、イーサネットA-Dルートの非受信に基づいてプルーニングされます。ESルートごとのイーサネットA-Dが撤回される場合、PEのIPアドレスをES候補リストから削除する必要があります。 PEのIPアドレスは、<ES、イーサネットタグ>のEVIルートごとのイーサネットA-Dが取り消されている場合、<ES、イーサネットタグ>の候補DFと見なしてはなりません。
The following example illustrates the AC-DF behavior applied to the default DF election algorithm, assuming the network in Figure 2:
次の例は、図2のネットワークを想定して、デフォルトのDF選出アルゴリズムに適用されるAC-DFの動作を示しています。
(a) When PE1 and PE2 discover ES12, they advertise an ES route for ES12 with the associated ES-Import Extended Community and the DF Election Extended Community indicating AC-DF = 1; they start a DF Wait timer (independently). Likewise, PE2 and PE3 advertise an ES route for ES23 with AC-DF = 1 and start a DF Wait timer.
（a）PE1とPE2がES12を検出すると、関連するESインポート拡張コミュニティとDF選挙拡張コミュニティがAC-DF = 1を示すES12のESルートをアドバタイズします。 DF待機タイマーを（独立して）開始します。同様に、PE2とPE3はAC-DF = 1でES23のESルートをアドバタイズし、DF待機タイマーを開始します。
(b) PE1 and PE2 advertise an Ethernet A-D per ES route for ES12. PE2 and PE3 advertise an Ethernet A-D per ES route for ES23.
（b）PE1およびPE2は、ES12のESルートごとにイーサネットA-Dをアドバタイズします。 PE2およびPE3は、ES23のESルートごとにイーサネットA-Dをアドバタイズします。
(c) In addition, PE1, PE2, and PE3 advertise an Ethernet A-D per EVI route for AC1, AC2, AC3, and AC4 as soon as the ACs are enabled. Note that the AC can be associated with a single customer VID (e.g., VLAN-based service interfaces) or a bundle of customer VIDs (e.g., VLAN Bundle service interfaces).
（c）さらに、ACが有効になるとすぐに、PE1、PE2、およびPE3はAC1、AC2、AC3、およびAC4のEVIルートごとにイーサネットA-Dをアドバタイズします。 ACは、単一のカスタマーVID（たとえば、VLANベースのサービスインターフェイス）またはカスタマーVIDのバンドル（たとえば、VLANバンドルサービスインターフェイス）に関連付けることができます。
(d) When the timer expires, each PE builds an ordered candidate list of the IP addresses of all the PE nodes attached to the ES (including itself) as explained in the modified Step 3 above. Any PE from which an Ethernet A-D per ES route has not been received is pruned from the list.
（d）タイマーが期限切れになると、各PEは、上記の変更されたステップ3で説明したように、ES（自身を含む）に接続されたすべてのPEノードのIPアドレスの順序付き候補リストを作成します。 ESルートごとにイーサネットA-Dを受信していないPEは、リストからプルーニングされます。
(e) When electing the DF for a given BD, a PE will not be considered to be a candidate until an Ethernet A-D per EVI route has been received from that PE. In other words, the ACS on the ES for a given PE must be UP so that the PE is considered to be a candidate for a given BD. For example, PE1 will not consider PE2 as a candidate for DF election for <ES12, VLAN-1> until an Ethernet A-D per EVI route is received from PE2 for <ES12, VLAN-1>.
（e）特定のBDのDFを選択する場合、EVIルートごとのイーサネットA-DがそのPEから受信されるまで、PEは候補と見なされません。つまり、PEが特定のBDの候補と見なされるように、特定のPEのES上のACSはUPである必要があります。たとえば、PE1は、<ES12、VLAN-1>のPE2からEVIルートごとのイーサネットA-Dを受信するまで、PE2を<ES12、VLAN-1>のDF選出の候補と見なしません。
(f) Once the PEs with ACS = DOWN for a given BD have been removed from the candidate list, the DF election can be applied for the remaining N candidates.
（f）特定のBDのACS = DOWNのPEが候補リストから削除されると、残りのN個の候補にDF選出を適用できます。
Note that this procedure only modifies the existing EVPN control plane by adding and processing the DF Election Extended Community and by pruning the candidate list of PEs that take part in the DF election.
この手順は、DF Election Extended Communityを追加して処理し、DF選出に参加するPEの候補リストをプルーニングすることによってのみ、既存のEVPNコントロールプレーンを変更することに注意してください。
In addition to the events defined in the FSM in Section 2.1, the following events SHALL modify the candidate PE list and trigger the DF re-election in a PE for a given <ES, Ethernet Tag>. In the FSM shown in Figure 3, the events below MUST trigger a transition from DF_DONE to DF_CALC:
セクション2.1のFSMで定義されたイベントに加えて、以下のイベントは候補PEリストを変更し、特定の<ES、イーサネットタグ>のPEでDF再選をトリガーするものとします（SHALL）。図3に示すFSMでは、以下のイベントがDF_DONEからDF_CALCへの遷移をトリガーする必要があります。
1. Local AC going DOWN/UP.
1. ローカルACがダウン/アップしています。
2. Reception of a new Ethernet A-D per EVI route update/withdrawal for the <ES, Ethernet Tag>.
2. <ES、イーサネットタグ>のEVIルート更新/撤回ごとの新しいイーサネットA-Dの受信。
3. Reception of a new Ethernet A-D per ES route update/withdrawal for the ES.
3. ESのESルートごとの新しいイーサネットA-Dルート更新/取り消しの受信。
4.1. AC-Influenced DF Election Capability for VLAN-Aware Bundle Services
4.1. VLAN対応のバンドルサービスに対するACの影響を受けるDF選出機能
The procedure described in Section 4 works for VLAN-based and VLAN Bundle service interfaces because, for those service types, a PE advertises only one Ethernet A-D per EVI route per <ES, VLAN> or <ES, VLAN Bundle>. In Section 4, an Ethernet Tag represents a given VLAN or VLAN Bundle for the purpose of DF election. The withdrawal of such a route means that the PE cannot forward traffic on that particular <ES, VLAN> or <ES, VLAN Bundle>; therefore, the PE can be removed from consideration for DF election.
セクション4で説明されている手順は、VLANベースおよびVLANバンドルサービスインターフェイスで機能します。これは、これらのサービスタイプの場合、PEは<ES、VLAN>または<ES、VLAN Bundle>ごとにEVIルートごとに1つのイーサネットA-Dのみをアドバタイズするためです。セクション4では、イーサネットタグは、DF選出のための特定のVLANまたはVLANバンドルを表します。そのようなルートの撤回は、PEがその特定の<ES、VLAN>または<ES、VLANバンドル>でトラフィックを転送できないことを意味します。したがって、DF選出の対象からPEを削除できます。
According to [RFC7432], in VLAN-aware Bundle services, the PE advertises multiple Ethernet A-D per EVI routes per <ES, VLAN Bundle> (one route per Ethernet Tag), while the DF election is still performed per <ES, VLAN Bundle>. The withdrawal of an individual route only indicates the unavailability of a specific AC and not necessarily all the ACs in the <ES, VLAN Bundle>.
[RFC7432]によると、VLAN対応バンドルサービスでは、PEは<ES、VLANバンドル>ごとにEVIルートごとに複数のイーサネットAD（イーサネットタグごとに1つのルート）をアドバタイズしますが、DF選択は<ES、VLANバンドルごとに実行されます>。個々のルートの撤回は、特定のACが利用できないことを示すだけであり、必ずしも<ES、VLANバンドル>のすべてのACを示すわけではありません。
This document modifies the DF election for VLAN-aware Bundle services in the following ways:
このドキュメントでは、VLAN対応バンドルサービスのDF選定を次のように変更します。
o After confirming that all the PEs in the ES advertise the AC-DF capability, a PE will perform a DF election per <ES, VLAN>, as opposed to per <ES, VLAN Bundle> as described in [RFC7432]. Now, the withdrawal of an Ethernet A-D per EVI route for a VLAN will indicate that the advertising PE's ACS is DOWN and the rest of the PEs in the ES can remove the PE from consideration for DF election in the <ES, VLAN>.
o [RFC7432]で説明されているように、ES内のすべてのPEがAC-DF機能をアドバタイズすることを確認した後、PEは<ES、VLANバンドル>ごとではなく、<ES、VLAN>ごとにDF選定を実行します。現在、VLANのEVIルートごとのイーサネットA-Dの撤回は、アドバタイジングPEのACSがダウンしており、ES内の残りのPEが、<ES、VLAN>でのDF選出の対象からPEを削除できることを示します。
o The PEs will now follow the procedures in Section 4.
o PEは、セクション4の手順に従います。
For example, assuming three bridge tables in PE1 for the same MAC-VRF (each one associated with a different Ethernet Tag, e.g., VLAN-1, VLAN-2, and VLAN-3), PE1 will advertise three Ethernet A-D per EVI routes for ES12. Each of the three routes will indicate the status of each of the three ACs in ES12. PE1 will be considered to be a valid candidate PE for DF election in <ES12, VLAN-1>, <ES12, VLAN-2>, and <ES12, VLAN-3> as long as its three routes are active. For instance, if PE1 withdraws the Ethernet A-D per EVI routes for <ES12, VLAN-1>, the PEs in ES12 will not consider PE1 as a suitable DF candidate for <ES12, VLAN-1>. PE1 will still be considered for <ES12, VLAN-2> and <ES12, VLAN-3>, since its routes are active.
たとえば、同じMAC-VRFのPE1の3つのブリッジテーブル（それぞれが異なるイーサネットタグに関連付けられている、VLAN-1、VLAN-2、VLAN-3など）を想定すると、PE1はEVIルートごとに3つのイーサネットADをアドバタイズしますES12の場合。 3つのルートはそれぞれ、ES12の3つのACのそれぞれのステータスを示します。 PE1は、3つのルートがアクティブである限り、<ES12、VLAN-1>、<ES12、VLAN-2>、および<ES12、VLAN-3>でのDF選出の有効な候補PEと見なされます。たとえば、PE1が<ES12、VLAN-1>のEVIルートごとにイーサネットA-Dを撤回した場合、ES12のPEはPE1を<ES12、VLAN-1>の適切なDF候補と見なしません。ルートがアクティブであるため、PE1は<ES12、VLAN-2>および<ES12、VLAN-3>で引き続き考慮されます。
The solution described in this document provides the following benefits:
このドキュメントで説明するソリューションには、次の利点があります。
(a) It extends the DF election as defined in [RFC7432] to address the unfair load balancing and potential black-holing issues with the default DF election algorithm. The solution is applicable to the DF election in EVPN services [RFC7432] and EVPN VPWS [RFC8214].
（a）[RFC7432]で定義されているようにDF選出を拡張し、デフォルトのDF選出アルゴリズムでの不当なロードバランシングと潜在的なブラックホール問題に対処します。このソリューションは、EVPNサービス[RFC7432]およびEVPN VPWS [RFC8214]でのDF選出に適用できます。
(b) It defines a way to signal the DF election algorithm and capabilities intended by the advertising PE. This is done by defining the DF Election Extended Community, which allows the advertising PE to indicate its support for the capabilities defined in this document as well as any subsequently defined DF election algorithms or capabilities.
（b）アドバタイジングPEが意図するDF選出アルゴリズムと機能を通知する方法を定義します。これは、DF Election Extended Communityを定義することによって行われます。これにより、アドバタイジングPEは、このドキュメントで定義されている機能、およびその後に定義されるDF選挙アルゴリズムまたは機能のサポートを示すことができます。
(c) It is backwards compatible with the procedures defined in [RFC7432]. If one or more PEs in the ES do not support the new procedures, they will all follow DF election as defined in [RFC7432].
（c）[RFC7432]で定義されている手順と下位互換性があります。 ESの1つ以上のPEが新しい手順をサポートしない場合、それらはすべて[RFC7432]で定義されているDF選出に従います。
This document addresses some identified issues in the DF election procedures described in [RFC7432] by defining a new DF election framework. In general, this framework allows the PEs that are part of the same ES to exchange additional information and agree on the DF election type and capabilities to be used.
この文書は、新しいDF選挙フレームワークを定義することにより、[RFC7432]で説明されているDF選挙手続きで確認されたいくつかの問題に対処します。一般に、このフレームワークにより、同じESの一部であるPEが追加情報を交換し、DFの選択タイプと使用する機能について合意することができます。
By following the procedures in this document, the operator will minimize such undesirable situations as unfair load balancing, service disruption, and traffic black-holing. Because such situations could be purposely created by a malicious user with access to the configuration of one PE, this document also enhances the security of the network. Note that the network will not benefit from the new procedures if the DF election algorithm is not consistently configured on all the PEs in the ES (if there is no unanimity among all the PEs, the DF election algorithm falls back to the default DF election as provided in [RFC7432]). This behavior could be exploited by an attacker that manages to modify the configuration of one PE in the ES so that the DF election algorithm and capabilities in all the PEs in the ES fall back to the default DF election. If that is the case, the PEs will be exposed to the unfair load balancing, service disruption, and black-holing mentioned earlier.
このドキュメントの手順に従うことで、オペレーターは不当な負荷分散、サービスの中断、トラフィックのブラックホールなどの望ましくない状況を最小限に抑えることができます。このような状況は、1つのPEの設定にアクセスできる悪意のあるユーザーによって意図的に作成される可能性があるため、このドキュメントはネットワークのセキュリティも強化します。 DF選出アルゴリズムがESのすべてのPEで一貫して構成されていない場合、ネットワークは新しい手順の恩恵を受けないことに注意してください（すべてのPE間で全会一致がない場合、DF選出アルゴリズムはデフォルトのDF選出にフォールバックします。 [RFC7432]で提供されます）。 ES内のすべてのPEのDF選出アルゴリズムと機能がデフォルトのDF選出にフォールバックするように、ES内の1つのPEの構成を変更する管理者がこの動作を悪用する可能性があります。その場合、PEは前述の不当なロードバランシング、サービスの中断、ブラックホールにさらされます。
In addition, the new framework is extensible and allows for new security enhancements in the future. Note that such enhancements are out of scope for this document. Finally, since this document extends the procedures in [RFC7432], the same security considerations as those described in [RFC7432] are valid for this document.
さらに、新しいフレームワークは拡張可能であり、将来の新しいセキュリティ強化を可能にします。このような拡張機能は、このドキュメントの範囲外であることに注意してください。最後に、このドキュメントは[RFC7432]の手順を拡張しているため、[RFC7432]で説明されているものと同じセキュリティの考慮事項がこのドキュメントに有効です。
IANA has:
IANAには次の機能があります。
o Allocated Sub-Type value 0x06 in the "EVPN Extended Community Sub-Types" registry defined in [RFC7153] as follows:
o [RFC7153]で次のように定義されている「EVPN拡張コミュニティサブタイプ」レジストリに割り当てられたサブタイプ値0x06：
Sub-Type Value Name Reference
-------------- ------------------------------ -------------
0x06 DF Election Extended Community This document
o Set up a registry called "DF Alg" for the DF Alg field in the Extended Community. New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. Value 31 is for experimental use and does not require any other RFC than this document. The following initial values in that registry exist:
o 拡張コミュニティのDF Algフィールドに「DF Alg」というレジストリを設定します。新規登録は、[RFC8126]で定義されている「RFCが必要」の手順で行われます。値31は実験用であり、このドキュメント以外のRFCは必要ありません。そのレジストリには次の初期値が存在します。
Alg Name Reference
---- ----------------------------- -------------
0 Default DF Election This document
1 HRW Algorithm This document
2-30 Unassigned
31 Reserved for Experimental Use This document
o Set up a registry called "DF Election Capabilities" for the 2-octet Bitmap field in the Extended Community. New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. The following initial value in that registry exists:
o 拡張コミュニティの2オクテットビットマップフィールドに「DF Election Capabilities」というレジストリを設定します。新規登録は、[RFC8126]で定義されている「RFCが必要」の手順で行われます。そのレジストリには次の初期値が存在します。
Bit Name Reference
---- ---------------- -------------
0 Unassigned
1 AC-DF Capability This document
2-15 Unassigned
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、and W. Henderickx、 "BGP MPLS-Based Ethernet VPN"、 RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https://www.rfc-editor.org/info/rfc7432>。
[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>.
[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>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、DOI 10.17487 / RFC4360、2006年2月、<https://www.rfc-editor.org/info / rfc4360>。
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC7153]ローゼン、E。およびY.レクター、「BGP拡張コミュニティのIANAレジストリ」、RFC 7153、DOI 10.17487 / RFC7153、2014年3月、<https://www.rfc-editor.org/info/rfc7153>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[VPLS-MH] Kothari, B., Kompella, K., Henderickx, W., Balus, F., and J. Uttaro, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, draft-ietf-bess-vpls-multihoming-03, March 2019.
[VPLS-MH] Kothari、B.、Kompella、K.、Henderickx、W.、Balus、F.、J。Uttaro、「仮想プライベートLANサービスにおけるBGPベースのマルチホーミング」、作業中、draft-ietf -bess-vpls-multihoming-03、2019年3月。
[CHASH] Karger, D., Lehman, E., Leighton, T., Panigrahy, R., Levine, M., and D. Lewin, "Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web", ACM Symposium on Theory of Computing, ACM Press, New York, DOI 10.1145/258533.258660, May 1997.
[CHASH] Karger、D.、Lehman、E.、Leighton、T.、Panigrahy、R.、Levine、M。、およびD. Lewin、「一貫したハッシュおよびランダムツリー：世界のホットスポットを解消するための分散キャッシュプロトコルWide Web」、コンピューティング理論に関するACMシンポジウム、ACM Press、ニューヨーク、DOI 10.1145 / 258533.258660、1997年5月。
[CLRS2009] Cormen, T., Leiserson, C., Rivest, R., and C. Stein, "Introduction to Algorithms (3rd Edition)", MIT Press, ISBN 0-262-03384-8, 2009.
[CLRS2009] Cormen、T.、Leiserson、C.、Rivest、R。、およびC. Stein、「Introduction to Algorithms（3rd Edition）」、MIT Press、ISBN 0-262-03384-8、2009。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <https://www.rfc-editor.org/info/rfc2991>.
[RFC2991] Thaler、D。およびC. Hopps、「ユニキャストおよびマルチキャストネクストホップ選択におけるマルチパスの問題」、RFC 2991、DOI 10.17487 / RFC2991、2000年11月、<https://www.rfc-editor.org/info / rfc2991>。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.
[RFC2992] Hopps、C。、「Analysis of an Equal-Cost Multi-Path Algorithm」、RFC 2992、DOI 10.17487 / RFC2992、2000年11月、<https://www.rfc-editor.org/info/rfc2992>。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/info/rfc4456>.
[RFC4456]ベイツ、T。、チェン、E。、およびR.チャンドラ、「BGP Route Reflection：An Alternative to Full Mesh Internal BGP（IBGP）」、RFC 4456、DOI 10.17487 / RFC4456、2006年4月、<https：/ /www.rfc-editor.org/info/rfc4456>。
[HRW1999] Thaler, D. and C. Ravishankar, "Using Name-Based Mappings to Increase Hit Rates", IEEE/ACM Transactions on Networking, Volume 6, No. 1, February 1998, <https://www.microsoft.com/en-us/research/wp-content/ uploads/2017/02/HRW98.pdf>.
[HRW1999] Thaler、D。およびC. Ravishankar、「名前ベースのマッピングを使用してヒット率を上げる」、IEEE / ACM Transactions on Networking、Volume 6、No。1、1998年2月、<https://www.microsoft。 com / en-us / research / wp-content / uploads / 2017/02 / HRW98.pdf>。
[Knuth] Knuth, D., "The Art of Computer Programming: Volume 3: Sorting and Searching", 2nd Edition, Addison-Wesley, Page 516, 1998.
[Knuth] Knuth、D。、「The Art of Computer Programming：Volume 3：Sorting and Searching」、第2版、Addison-Wesley、ページ516、1998年。
Acknowledgments
謝辞
The authors want to thank Ranganathan Boovaraghavan, Sami Boutros, Luc Andre Burdet, Anoop Ghanwani, Mrinmoy Ghosh, Jakob Heitz, Leo Mermelstein, Mankamana Mishra, Tamas Mondal, Laxmi Padakanti, Samir Thoria, and Sriram Venkateswaran for their review and contributions. Special thanks to Stephane Litkowski for his thorough review and detailed contributions.
著者は、Ranganathan Boovaraghavan、Sami Boutros、Luc Andre Burdet、Anoop Ghanwani、Mrinmoy Ghosh、Jakob Heitz、Leo Mermelstein、Mankamana Mishra、Tamas Mondal、Laxmi Padakanti、Samir Thoria、およびSriram Venkateswaranにレビューと貢献を感謝します。 Stephane Litkowski氏の徹底したレビューと詳細な貢献に感謝します。
They would also like to thank their working group chairs, Matthew Bocci and Stephane Litkowski, and their AD, Martin Vigoureux, for their guidance and support.
彼らはまた、指導と支援をしてくれたワーキンググループの議長であるマシュー・ボッチとステファン・リトコウスキー、そして彼らのADであるマーティン・ヴィグールーにも感謝したいと思います。
Finally, they would like to thank the Directorate reviewers and the ADs for their thorough reviews and probing questions, the answers to which have substantially improved the quality of the document.
最後に、彼らは徹底的なレビューと詳細な質問についての総局の査読者とADに感謝したいと思います。その回答により、ドキュメントの品質は大幅に改善されました。
Contributors
貢献者
The following people have contributed substantially to this document and should be considered coauthors:
次の人々はこのドキュメントに実質的に貢献しており、共著者と見なされるべきです：
Antoni Przygienda Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
Antoni Przygienda Juniper Networks、Inc. 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: prz@juniper.net
Vinod Prabhu Nokia
ヴィノッドプラブノキア
Email: vinod.prabhu@nokia.com
Wim Henderickx Nokia
Wim Henderickxノキア
Email: wim.henderickx@nokia.com
Wen Lin Juniper Networks, Inc.
Wen Lin Juniper Networks、Inc.
Email: wlin@juniper.net Patrice Brissette Cisco Systems
メール：wlin@juniper.net Patrice Brissette Cisco Systems
Email: pbrisset@cisco.com
Keyur Patel Arrcus, Inc.
Keur Patel Recurs、Inc.
Email: keyur@arrcus.com
Autumn Liu Ciena
秋劉シエナ
Email: hliu@ciena.com
Authors' Addresses
著者のアドレス
Jorge Rabadan (editor) Nokia 777 E. Middlefield Road Mountain View, CA 94043 United States of America
ホルヘラバダン（編集者）ノキア777 E. Middlefield Road Mountain View、CA 94043アメリカ合衆国
Email: jorge.rabadan@nokia.com
Satya Mohanty (editor) Cisco Systems, Inc. 225 West Tasman Drive San Jose, CA 95134 United States of America
Satya Mohanty（編集者）Cisco Systems、Inc. 225 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: satyamoh@cisco.com
Ali Sajassi Cisco Systems, Inc. 225 West Tasman Drive San Jose, CA 95134 United States of America
Ali Sajassi Cisco Systems、Inc. 225 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: sajassi@cisco.com John Drake Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
メール：sajassi@cisco.com John Drake Juniper Networks、Inc. 1194 N. Mathilda Ave. Sunnyvale、CA 94089 United States of America
Email: jdrake@juniper.net
Kiran Nagaraj Nokia 701 E. Middlefield Road Mountain View, CA 94043 United States of America
キランナガラジノキア701 E. Middlefield Road Mountain View、CA 94043アメリカ合衆国
Email: kiran.nagaraj@nokia.com
Senthil Sathappan Nokia 701 E. Middlefield Road Mountain View, CA 94043 United States of America
Senthil Sathappan Nokia 701 E. Middlefield Road Mountain View、CA 94043アメリカ合衆国
Email: senthil.sathappan@nokia.com