🌊

RFC8584翻訳

2022/03/30に公開

memo

tech

注意

RFCを読みやすく理解しやすくするようにDeeplベースで翻訳しました。
元ドキュメント　 https://datatracker.ietf.org/doc/html/rfc8584

RFC8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility

Abstract

Ethernet VPN（EVPN）におけるデフォルトのDesignated Forwarder（DF）選択アルゴリズムに代わるものが定義されます。DFはProvider Edge（PE）ルーターで、BUMトラフィックを特定のEthernet Segment（ES）上のVLANでマルチホーム構成に帰属するCustomer Edge（CE）デバイスに送る責任があります。さらに、関連付けられたAC（Attachment Circuit）の状態によってVLAN BasedのDF Election結果に影響を与える機能が定義されました。このドキュメントではEVPNサービスにおけるDF Electionのステートマシンを明確にします。よって、このドキュメントはEVPN仕様であるRFC7432をアップデートします。

Table of Contentes

   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

1.Introduction

Ethernet VPNs(EVPNs)におけるDesignated Forwarder(DF)は特定のEthernet Segment(ES)上のVLANにおいてマルチホーム構成に帰属するCustomer Edge(CE)へBUMトラフィックを転送する責任があります。DFはESに接続されたマルチホーム構成のPEから選出され、それぞれESI（Ethernet Segment Identifier）で識別されるES routeを広報します。デフォルトでEVPNは”service carving”と呼ばれるDF Electionアルゴリズムを使用します。このDF ElectionアルゴリズムはES(N)におけるPEの数とVLAN値(V)を入力とするモジュロ演算(V mod N)に基づきます。このドキュメントでは新しいDF Electionアルゴリズムと関連するAttachment Circuit(AC)の状態に応じてVLANのDF Election結果に影響を与える機能を定義することによってデフォルトのDF Electionアルゴリズムの非効率性に対処します。DF Eelctionアルゴリズムで使用される識別子との曖昧さを避けるため、本書では「VLAN」の代わりに「Ethernet Tag」という用語を使用します。またこのドキュメントは将来のDF ElectionアルゴリズムとCapability(セクション7参照)のためにIANA登録を行います。これはDF Electionのステートマシン(FSM)を正式に定義し明確化します。ゆえに、このドキュメントは[RFC7432]をアップデートし、EVPNの実装はこの規定されたFSMに準拠しなければなりません。FSMの正式な記述を除き本文書は[RFC7432]に記述されている他の手順をupdateする意図はなく、この文書で記述された手順に従うようアップグレードされたPEにおけるDF Electionの動作を改善することのみを目的としています。

1.1. Conventions and Terminology

   o  AC: Attachment Circuit.  An AC has an Ethernet Tag associated
      with it.

   o  ACS: Attachment Circuit Status.

   o  BUM: Broadcast, unknown unicast, and multicast.

   o  DF: Designated Forwarder.

   o  NDF: Non-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  Ethernet A-D per EVI route: Refers to Route Type 1 as defined in
      [RFC7432] or to Auto-discovery per EVPN Instance route.

   o  ES: Ethernet Segment.

   o  ESI: Ethernet Segment Identifier.

   o  EVI: EVPN Instance.

   o  MAC-VRF: A Virtual Routing and Forwarding table for Media Access
      Control (MAC) addresses on a PE.

   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  Bridge table: An instantiation of a BD on a MAC-VRF.

   o  HRW: Highest Random Weight.

   o  VID: VLAN Identifier.

   o  CE-VID: Customer Edge VLAN Identifier.

   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  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  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 algorithm: A component of the DF election procedure.  Strictly
      refers to the selection of a PE for a given <ES, Ethernet Tag>.

   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  TTL: Time To Live.

   This document also assumes that the reader is familiar with the
   terminology provided in [RFC7432].

1.2. Default Designated Forwarder (DF) Election in EVPN Services

[RFC7432]では、これらをDFをEVPN PEの責任として定義しています。

o　特定のES上の特定のEthernet TagのCEヘBUMトラフィックをフラッディングします
o　特定のES上の特定のEthernet TagのCEヘユニキャストトラフィックを転送します。この動作はSingle-Active Multihomingにおいて有効です。

Figure 1 illustrates an example that we will use to explain the DF function.

図1はES1とES2の2つのESがあるケースを示します。ES1とES2の2つのESがある場合を図1に示します。
PE1はES1経由でCE1に接続され、PE2、PE3、PE4はES2経由でCE2に接続され、つまりPE2、PE3、PE4が冗長グループを形成しています。CE2は同じES上の異なるPEにマルチホームされているため、PE2、PE3、PE4は上記要件を満たすためDFに合意する必要があります。

L2ネットワークにおける転送ループの影響は特に深刻です、なぜならBroadcastはEthernetトラフィックの性質でありTTLも無いためです。ゆえにマルチホームCE構成では1つのPEのみがBUMトラフィックを転送すべきです。これをサポートするための1つの前提条件として、参加するPEは誰がDFとしてふるまうかを合意しておく必要があります。これは参加する各PEらが独立的かつ曖昧さなく参加PEのどれか1つをDFとして選択する分散アルゴリズムによって達成される必要があり、その結果は一貫して全会一致であるべきです。

これは、各参加PEが独立かつ曖昧さなく参加PEの1つをDFとして選択する分散アルゴリズムによって達成される必要があり、その結果は一貫して全会一致であるべきです。[RFC7432]で定義された(ESI, EVI)の粒度のデフォルトのDF Electionアルゴリズムは”Service Carving”と呼ばれます。このドキュメントでは、service carvingとデフォルトのDF Electionアルゴリズムは同じ意味として使われます。service carvingでは、そのES方向のトラフィックをロードラバンスするため、ES(EVIごとに1つ)毎に複数のDFを選出することが出来ます。負荷分散の目的は、冗長PEノード間でBD空間を均等に分割し、すべてのPEが異なるEVIのセットのDFとなるようにすることです。DF Electionアルゴリズム([RFC7432]のセクション8.5で記述されているもの)はモジュラス演算に基づいています。ES(EVI毎にDF Electionが行われる)がマルチホームされるPEはPEのIPアドレス値の昇順で並べられた序列リストを形成します。例えばN個のPEs（PE0、PE1・・・PE(N-1））が序数リストのIPアドレス増加によってランク付けが行われ、そのときEthernet Tag Vを使用する各VLANがES1上で設定され、PExはx=(V mod N)の場合、ES1上のVLAN VのDFとなります。VLAN Bundleの場合は最も小さいVLANのみが使用されます。計画密度が高い（VLANの数が多く、Ethernet Tagが均一に分布していることを意味する）場合、DF ElectionはそのESをホストするPEに分散し、良好な負荷分散を達成できると考えられます。

しかしながらこのデフォルトのDF Electionアルゴリズムには望ましくない特性があり、場合によっては破壊的で不公平になる可能性があります。このドキュメントではそれらの問題をいくつか述べ、対処するメカニズムを定義します。これらのメカニズムはデフォルトのDF Electionアルゴリズムに変更を加えますが、これらはEVPNの経路交換においていかなる変更を要求することなく、そしてEVPN経路の変更を最小限にします。また新しいアルゴリズムとcapabilityのためにDF Election手順を拡張する必要があります。

単一のアルゴリズム（つまりデフォルトのDF Electionアルゴリズム）が全てのユースケースの要求を満たすとは限りません。

[RFC7432]では<ES, EVI>ごとにDFを選出するのに対して、このドキュメントでは<ES, BD>ごとにDFを選出することに留意してください。つまり、VLAN-aware Bundle Service EVIのDFが1つしかない[RFC7432]と異なることを意味し、このドキュメントではそのEVIに設定されたBDごとに複数のDFが存在することを規定します。

1.3. Problem Statement

このセクションではデフォルトのDF Electionアルゴリズムに関するいくつかの潜在的な問題について説明します。

1.3.1. Unfair Load Balancing and Service Disruption

現在のデフォルトDF Electionアルゴリズムには3つの根本的な問題があります。

このアルゴリズムは、Ethernet Tagが一様でない分布に従う場合、例えばEthernet Tagがすべて偶数またはすべて奇数の場合、うまく実行されません。このような場合、ESが2つのPEにマルチホームされていると仮定すると、PEの1つが全てのVLANのDFとして選択されることになります。これは、非常に最適とは言えません。DFがESをホストするPEに均等に分散されていないため、service carvingの目的を破っています。
実際、このケースではPEの1つはDFとして選出されないため、DFの責任には全く関与しません。
図1を参照して、(1) PE2、PE3、PE4がIPアドレスの昇順でリストアップされ、(2) ES2に設定された各VLANには、xが整数である（3x+1）形式のEthernet Tagが付いていると仮定する別の例を考えてみましょう。
これにより、PE3が常にDFとして選択されることになります。
BDを識別するEthernet Tagは 2^24 個まで可能ですが、ES 上のテナントBD が一様分布になることは保証されません。実際、ES上のBDをどのように構成するかは顧客次第です。
引用[Knuth] : 一般に、r^k+a または r^k-a (k と a は小数、r はアルファベット文字セットの基数（通常 r=64, 256 または 100）)を割るような M 値は避けたいものです。このようなことから、Mは小さなkとaに対してr^k!=a(modulo)Mまたはr^k!=?a(modulo)Mを満たす素数であることが推奨されます。
我々の場合、NはPEの数です([RFC7432]のセクション8.5)。そして、Nは上記のMに相当します。
N、N-1、またはN+1はMのプライマリティを満たす必要がないため、モジュロベースのDF割り当て[RFC7432]と同様に、PEがダウンしたり新しいPE（同じESに接続）が起動すると、モジュロスキームは必ずしもBDをPEに均一にマッピングするとは限りません。
混乱もまた問題です。同じESが一組のPEにマルチホームされている場合を考えてみましょう。あるPE、例えばPE1でESがダウンした場合、PE1自体が再起動した場合、BGPプロセスがダウンした場合、PE1とRR間の接続がダウンした場合、システム内の有効PE数はN-1となり、そのESに設定されているすべてのVLANに対してDFが計算されます。一般に、あるVLAN VのDFがPE1ではなく、他のPE、例えばPE2であった場合、PE1とPE2とは異なる他のPEが新しいDFになる可能性があります。これは望ましくありません。同じように新しいPEが同じESをホストするときモジュラス計算によってマッピングが再び変更されます。結果として不要に撹乱されることになります。再び図1を参照して、V1、V2、V3はES2に設定されたVLANで、それぞれ999、1000、1001という値のEthernet Tagが関連付けられているとします。PE1、PE2、PE3は、それぞれV1、V2、V3のDFです。PE3がダウンすると、PE2がV1のDFになり、PE1がV2のDFになります。

注意点としてデフォルトのDF Electionアルゴリズムでは、同じESにマルチホームされる（そしてEVPN経路を交換することでDF選択に関心を持つ）すべてのPEが、同じアドレスファミリのオリジンルーターのIPアドレス（RFC7432）を使用していると仮定しています。

EVPNアドレスファミリはIPv4またはIPv6ピアリングで伝送され、同じESに接続されたPEはどちらのファミリのアドレスを使用してもよいため、このようなことは必要ありません

数学的には、従来のハッシュ関数は、関数h(k)を介して鍵kをm個のハッシュバケットの一つを表す数値iに対応付ける、つまりi = h(k)となります。EVPNの場合、hは単純にモジュロmハッシュ関数です。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ポートをブロッキングまたはノンブロッキングに再プログラムすることになるため、これはチャーン（churn）となります。
このドキュメントでは、この問題を取り上げ、この望ましくない動作に対する解決策を提供します。

1.3.2. Traffic Black-Holing on Individual AC Failures

[RFC7432]で定義されたデフォルトのDF Electionアルゴリズムは特定ESのモジュラス関数において、候補リスト内のPEのIPアドレスとローカルのEthernet Tagの2つの変数のみを考慮します。ある<ESI, EVI>のDFが（物理的なリンクやノードの障害により）失敗した場合、ES route withdrawnによりNDF PEはその<ESI, EVI>のDFを再選出し、サービスは回復します。しかし、デフォルトのDF Election手順では、DFのサービスレベルで発生する可能性のある"論理"障害や人的エラーに対する保護は提供されず、あるESのアクティブPEリストは変更されません。これらの障害は問題が発生したローカルPEだけでなく、ESの残りのPEにも影響を与える可能性があります。以下にこのような論理障害の例をいくつか挙げます。

(a)ESに定義された個々のACが誤ってシャットダウンされたり、まだプロビジョニングされていない（従って、ACSはDOWN）、しかしESは動作上アクティブである（ES routeはアクティブである）

(b)ESが定義されているMAC-VRFはシャットダウンされているかまだプロビジョニングされていない状態ですが、ESは動作上アクティブです（ES routeがアクティブなので）。この場合、すべてのACのACSが停止します。そのMAC-VRFで定義されているものはDOWNしていると見なします。

ACSはDF Election手順において考慮されないため、(a)と(b)のどちらも、あるESのリモートマルチホームPEにおけるDF再選出をトリガすることはありません。。仮想プライベートLANサービス（VPLS）のマルチホーミング手順[VPLS-MH]では、ACSがDF Electionのタイブレーカーおよびトリガーとして使用されますが、EVPN仕様[RFC7432]では、DF上のACS変更に基づくDF再選択をトリガーする手順は定義されていません。

BD-1はPE1、PE2、PE3、PE4で定義されています。CE12はPE1とPE2のES12に接続されたマルチホームのCEです。同様に、CE23はES23を使用してPE2とPE3にマルチホームされています。CE12とCE23はともにVLAN Based Service InterfaceでBD-1に接続されています。CE12-VID1 (CE12のVID1)は以下のようになります。CE23-VID1はBD-1のAC1とAC2に対応し、CE23-VID1はBD-1のAC3とAC4に対応します。また表にはありませんが、これらのESには異なるBDにマッピングされた他のACが定義されていると仮定します。[RFC7432]に記載されているデフォルトのDF Electionアルゴリズムを実行した後、PE2がBD-1のES12とES23のDFであることが判明します。

以下のような問題が発生する可能性があります。

(a)AC2が誤ってシャットダウンされたり、未設定の場合、CE12のトラフィックに影響があります。All-Activeマルチホーミングの場合、CE12へのBUMトラフィックはブラックホール化され、Single-Activeマルチホーミングの場合、CE12との間のトラフィックはすべて廃棄されます。これはPE2のAC2で論理障害が発生しても、ES12のES Route withdrawalのトリガーにはならないためです（ES12にはまだ他のACがアクティブであるため）したがってPE1は、DFの選出手続きを再実行しません。
(b)BD-1のブリッジテーブルが管理上シャットダウンされているか、PE2にまだ設定されていない場合、CE12とCE23の両方が影響を受けます：All-Activeマルチホーミングの場合は両方のCEへのBUMトラフィックは廃棄され、そしてSingle-Activeマルチホーミングの場合、CEとの全てのトラフィックが廃棄されます。これは、PE1とPE3がDF Electionの手続きを再実行せず、PE2がDFであると仮定し続けるからです。

[RFC7432] から引用、「Ethernet TagがEthernet Segmentで廃止されるとき、PEは<ESI, Ethernet Tag>が廃止の影響を受けたこと知らせるためにEthernet A-D per EVI route(s)をWithdrawしなければならない。」とあります。しかしながらこのA-D per EVI route withdrawalはaliasingやbackup手順を行うリモートPEsで使用されますが、影響を受けるEVIのDF Electionに影響を与えるために使用されるわけではありません。このドキュメントではACSをDF Electionの変数として考慮できるようDF Electionの手順をオプションとして修正します。従って、EVPNでは論理障害に対する保護を提供出来ます。

1.4. The Need for Extending the Default DF Election in EVPN Services

セクション1.3では、デフォルトのDF Election手順に存在するいくつかの問題について説明しました。それらの問題に対処するため、このドキュメントは新しいDF Electionフレームワークを導入します。
このフレームワークによりPEsがDF Electionの間に有効化するcapabilityだけではなく新しいDF Electionアルゴリズムについて合意することが出来ます。
一般に、「DF Electionアルゴリズム」とは、DF PEを決定するために多くの入力パラメータを使用するアルゴリズムを指し、「DF Election Capability」とは、入力（または候補PEリスト）の変更など、DF Electionアルゴリズムの呼び出しの前に使用できる追加機能を指します。一般的に「DF Electionアルゴリズム」とは、DF PEを決定するために多くの入力パラメータを使用するアルゴリズムを指し、「DF Election Capability」とは、DF Electionアルゴリズムを呼び出す前に使用できる追加機能、例えば修正することを指します。入力（または候補PEのリスト）。このフレームワークの中で、このドキュメントは新しいDF Electionアルゴリズムと、DF Electionに影響を与えることができる新しいCapabilityを定義します。

結果的に:
o 新しいDF Electionアルゴリズムは"Highest Random Weight" (HRW)と呼ばれます。HRWの手順はセクション3で説明します。
o 新しいDF Election Capabilityは"AC-Influenced DF election" (AC-DF)と呼ばれます。AC-DF手順はセクション4で説明します。
o HRWとAC-DFメカニズムはそれぞれ独立しています。よって、PEはHRWとAC-DFのどちらかを単独でサポートしてもよいし、両方共にサポートすることができます。PEは[RFC7432]によるデフォルトのDF Electionアルゴリズムと共にAC-DF capabilityをサポートすることが出来ます。またこのドキュメントではあるESのEVPN ES route広報でHRWとAC-DF両方またはいずれか片方をサポートするための方法を定義します。より詳細はセクション2.2を参照してください。

2. Designated Forwarder Election Protocol and BGP Extensions

このセクションでは新しいDF Election手順をサポートするために必要なBGP拡張機能について記述します。また[RF 7432]のEVPN仕様ではDF Electionの正確なFSMについていくつかの疑問点が残っているため、セクション2.1では意図する動作を正確に記述します。

2.1. The DF Election Finite State Machine (FSM)

RFC7432ではこの図3のFSMをVLAN-basedの場合<ES, VLAN>毎に、VLAN Bundleの場合は<ES,VLANs in Bundle>毎に各PEで実行されます。FSMは概念的であり、どんな設計や実装もこのFSMで概要説明された動作と同じ動作に同じような挙動となるべきです。

各EVIが特定のESに接続された各マルチホームPEでローカルに設定されていること、およびFSMがこれらのPE間の不整合な設定に対する保護を提供していないことを確認してください。
つまり、特定のEVIについて1つ以上のPEがVLAN-aware Bundle Serviceの場合はVLANの異なるセットで、VLAN-Based serviceの場合はVLANで誤って設定されています。

図3に示されている状態とイベントは、次のように定義されています。

States:
１　INIT: Initial state.
２　DF_WAIT: 参加者がEVI/ESI/VLANの組み合わせによりDF Electionを行うための十分な情報を待つ状態
３　DF_CALC: 新DFが再計算される状態
４　DF_DONE: EVI/ESI/VLANの組み合わせに対応するDFがElectionされた状態
５　ANY_STATE: 上記状態のいずれかのこと

Events:
１　ES_UP　ESがローカルでUpとして設定された状態
２　ES_DOWN ESがローカルでDownとして設定された状態
３　VLAN_CHANGE Bundle（ESを使用）で設定されたVLANらが変更された状態
４　DF TIMER　DF Timerが満了した状態　*RFC7432のWait timerを見てね
５　RCVD_ES　変更された、もしくは新しいES RouteをMP_REACH_NLRIとして受信した状態。このイベントをトリガーにしてはならない。
６　LOST_ES　既に受信していたES RouteをMP_UNREACH_NLRIとして受信した状態。もしこれまでに広報を受信していない経路の場合、このイベントをトリガーにしてはならない
７　CALCULATED DF計算が成功した状態

状態遷移した場合もしくはは他の状態に移る/状態が終わる際に対応する動作

１ANY_STATE_ on ES_DOWN
　(i)　DF wait timerを止める
　(ii)　ローカルPEをNon-DFとする
２　INIT on ES_UP　DF_WAITへ状態へ遷移する
３　INIT on VLAN_CHANGEしてRCVD_ESかLOST_ES　何もしない
４　状態に入るときのDF_WAIT
　(i)　既に開始されてるかTimer満了した場合、DF Wait timerを開始する
　(ii)　ローカルPEをNon-DFとする
５　DF_WAIT on VLAN_CHANGE, RCVD_ES, or LOST_ES　何もしない
６　DF_WAIT on DF_TIMER: DF_CALCへ遷移する
７　DF_CALC　状態遷移した、もしくは再度戻った場合のDF_CALC
　(i)　候補リストを再構築し、8種してElectionする
　(ii)　その後FSMは反して計算イベントを生成する
８　DF_CALC on VLAN_CHANGE, RCVD_ES, or LOST_ES: Do as prescribed in
７の通り実行する
９　DF_CALC on CALCULATED: VLANかBundleのためElection結果をマークし、状態をDF_DONEヘ遷移させる
１０　DF_DONE on exiting the state: もし新しいDF Electionがトリガーされ、現在のDFが失われた際、ローカルPEをVLANかVLAN bundleのNDFにする
１１　DF_DONE on VLAN_CHANGE, RCVD_ES, or LOST_ES: DC_CALCへ遷移する

上記イベントと状態遷移はデフォルトのDF Electionアルゴリズムとして定義されています。セクション4で記述しているように、AC-DF capabilityの使い方で追加イベントや遷移を紹介します。

2.2. The DF Election Extended Community

DF Election手順に一貫性があり合意されるためにはDF Electionに参加する全てのPEでDF Election Algorithmとcapabilityに同意する必要があります。例えば、あるPEらがHRWを使ってるなか、あるPEらがデフォルトのDF Election Algorithmを使用することは不可能です。
ブラウンフィールド・デプロイメント（以前開発されたもの）に配置され、レガシーなPEらと相互接続する場合、そのPEらはデフォルトのDF Electionへフォールバック出来ることが重要です。
PEらはES Route(RT-4)に含まれるDF Election Ext-CommのシグナリングによってHRWと（または）AC-DFをサポートする意思を示すことができます。
　DF Election Ext-Commは新しいBGPのトランジティブなExt-Commアトリビュートで、ESのDF Election手順で使われます。　Figure4でDF Election Ext-Commのencodingを示します。

Figure 4: DF Election Extended Community

o Type: 0x06, EVPN Extended CommunitiesのためにIANA（セクション7）として登録されています
o Sub-Type: 0x06. “"DF Election Extended Community"としてIANAに登録されています
o RSV/Reserved: DF Alg固有の情報のための予約ビットです
o DF Alg (5 bits): 広報するPEがESに使用することを望むDF Election アルゴリズム値（0〜31）をエンコードします。このドキュメントは”DF Alg”（セクション7）と呼ばれるIANAレジストリーを作成します、次の値を含みます：
Type 0: デフォルトのDF Electionアルゴリズム、もしくは[RFC7432]で定義されているモジュラスベースのアルゴリズム
Type 1: HRWアルゴリズム (セクション3).
Types 2-30: 未アサイン
Type 31: 試験用予約
o ビットマップ (2 octets): DF AlgフィールドのDF Electionアルゴリズムで使用する「Capability」をエンコードします。このドキュメントではビットマップフィールド（0～15の値）のIANAレジストリ（セクション7）を作成します。このレジストリは「DF Election Capabilities」と呼ばれ、以下に示すビット値が含まれます。

Figure 5: Bitmap Field in the DF Election Extended Community

Bit 0（DF Election Extended Community の Bit 24 に相当）：未アサイン
Bit 1: AC-DF Capability（AC-Influenced DF election：セクション4参照）。 1に設定すると、AC-DFを使用したいことを示す。ES内の残りのPEとAC-DFを行う。
Bits 2-15: 未アサイン

DF Election Extended Communityは次のように使用されます：
o PEは広報されたES RouteにDF Election Extended Communityを付加すべきです、ES がデフォルトのDF Electionアルゴリズム以外のDF Electionアルゴリズムでローカルに設定されている場合、または使用するCapabilityが必要な場合、Extended Communityが送信されなければなりません。Extended Communityでは、PEはESで使用される希望の「DF Alg」アルゴリズムと「bitmap」Capabilityを示します。

ES Routeと一緒に送信可能なDF Election Extended Communityは1つだけです。広報するPEは、サポートされているすべてのDF ElectionアルゴリズムとCapabilityを示すのではなく、好ましいものを示すことを意図していることに注意してください。
DF Alg値0と1はビット1(AC-DF)の設定を0または1に設定することで両方使用することが出来ます。
一般に、特定のDF Algは、Extended Communityの予約ビットの使用を決定すべきです。
特に、DF Alg値0と1では予約ビットは設定されません。広告PEは、受信 PE からは無視されるべきです。

o PEは他のPEから当該ES Routeを受信すると、すべての広報が同じDF Algとビットマップを持つExtended Communityを持つかどうかを確認します：

もしそうであれば、この特定のPEは広告されたDF AlgとCapabilityに関する手順に従わなければなりません。例えば、あるESのすべてのES routeがDF Alg HRWとAC-DFを1に設定している場合、ESに接続しているPEはHRWアルゴリズムに従いAC-DF手順に従ってDF選択を実行することになります。
そうでなければ、ローカルに設定されたDF AlgとCapabilityを持たないRT-4の広告を1つでも受信した場合、[RFC7432]で規定されているようにデフォルトのDF Electionアルゴリズムが使用されなければなりません。この手順はESに参加しているPEが、適用すべきDFアルゴリズムとCapabilityについて意見が一致しない場合に対処するものです。
DF Election Extended Communityが存在しない、または複数のDF Election Extended Communityが存在する場合、受信側PEは送信側PEのデフォルトDF Electionアルゴリズム（DF Alg 0およびDF Election機能なし）を示すと解釈しなければなりません。

o ES内のすべてのPEがDFタイプ31を広報するとき、PEはローカルポリシーに依存してDF Electionをどのように進めるかを決定します。

o 将来的に定義される新しいCapabilityについては、既存のDF Alg値との適用性／互換性をケースバイケースで評価する必要があります。

o 同様に、将来的に定義される新しいDFアルゴリズムについても、既存のCapabilityとの適用性／互換性はケースバイケースで評価されなければなりません。

2.2.1. Backward Compatibility

[RFC7432]にのみ準拠する実装(すなわち、この仕様より前の実装)はDF Election Extended Communityを広報しません。つまりESの他のすべての参加PEはDF Preferenceを受け取らず、AC-DFなしのデフォルトDF Electionアルゴリズムに戻ります。同様に、[RFC7432]にのみ準拠する実装がDF Election Extended Communityを受信した場合、これを無視しデフォルトのDF Electionアルゴリズムを使用し続けることになります。

3.The Highest Random Weight DF Election Algorithm

このセクションの議論する手順はRFC7432のEVPN ServicesとRFC8214のEVPN VPWS Serviceです。
HRWはHRW1999として定義されており、もともとインターネットキャッシングやプロキシーサーバーロードバランスなどを目的として提案されました。
オブジェクト名とサーバーセットらが与えられるとHRWはサーバーの状態ではなくオブジェクト名（オブジェクトID）とサーバー名（サーバーID）を用いてリクエストをサーバーへマッピングします。
HRWはサーバーIDとオブジェクトIDからハッシュを生成し、特定のオブジェクトIDに対応するサーバーの順序付きリストを形成します。
　ハッシュ値が最も大きいサーバーがそのオブジェクトを担当するプライマリーサーバーとなり、ハッシュ値が次に大きいサーバーがバックアップサーバーとして機能します。
HRW は与えられたオブジェクト名を常に同じサーバーにマッピングします。その結果、クライアントサイトで使用することができます。オブジェクトとサーバーのマッピングについてグローバルなコンセンサスを得ることができます。
そのサーバーがダウンした場合、バックアップサーバーが責任者となります。
鍵の分布に統計的に影響を受けず、ハッシュ出力に良好な一様分布を与える適切なハッシュ関数を選択することは、このアルゴリズムの重要な側面です。
幸運にも、たくさんハッシュファンクションが存在します。[HRW1999] は、Unix のユーティリティであるrandとsrandに基づく擬似ランダム関数と、望みのハッシュ特性を満たす簡単に構築できるXOR関数を提供します。HRWはすでにマルチキャストやECMP[RFC2991] [RFC2992]で使用されています。

3.1. HRW and Consistent Hashing

HRWは単なるアルゴリズムとしてのみではなく、公平な負荷分散、冗長性、そして高速アクセスを目標としてオブジェクトとサーバーのマッピング問題に取り組みます。
この問題に対処する別のアルゴリズム群もあり、これらは以下のように分類されます。Consistent Hashing Algorithms [CHASH]（一貫したハッシングアルゴリズム）。が、これらはここでは考慮しません。

3.2. HRW Algorithm for EVPN DF Election

このセクションではDF Electionに対するHWの適用について記述します。

DF(V)はEthernet Tag VのDF、BDF(V)はBDFを示すとします。
SiはPE iのIPアドレス、EsはESI、そしてWeightはV、Si、Esの関数です。

[RFC7432]のDF ElectionアルゴリズムはPEのアドレスとVLANを入力として使用することに気をつけて下さい、このドキュメントではEthernet Tag、PEのアドレス、そしてESIらをインプットとして使用します。
これはもし同じPEらがあり、同じESらをMultihome構成で共有する場合、[RFC7432]で使われるDF Electionアルゴリズムの結果として各ES上の同BDセットに対して同じPEがDFとして選出されてしまいます。これは負荷分散と冗長性両方の面で影響を及ぼす可能性があります。
DF ElectionアルゴリズムにESIを含めると追加エントロピーが発生し、各ES上の同BDセットに対して同じPEがDFとして選出される確率が大幅に減ります。
　ゆえに、DF ElectionでHRWアルゴリズムが使用されるとき、以下のWeight関数内ESI値は対応するESの値に設定されるべきです。

VLAN Bundle serviceの場合、[RFC7432]の”Bundleの中で最も小さいVLAN”のロジックと同じようにVは最も低いVLAN値を示します。

DF(V) = Si| Weight(V, Es, Si) >= Weight(V, Es, Sj), for all j.
同数の場合は、IPアドレスの数字が最も小さいPEを選択します。
0 <=i , j < Redundancy Group内のPE数、であることに注意してください。
BDF(V) = Sk| Weight(V, Es, Si) >= Weight(V, Es, Sk), と
```
Weight(V, Es, Sk) >= Weight(V, Es, Sj).
```

同数の場合はIPアドレスが数字的に最も小さいPEを選択します。

どこで？

DF(V)は以下のアドレスSi(インデックス値i)と定義されます。
Weight(V, Es, Si)が最も高く、0 <= i < N-1　です。
BDF(V)は、アドレスSkを持つPEの中では、DFのWeightに次いで高いWeightを計算します。
jは0からN-1までの流動的なインデックス値であり、iとkは選択された値です。

Weightは3タプル(V, Es, S)をドメインとする擬似ランダム関数であるため、Ethernet Tag Vのサンプル空間分布に依存しない効率的かつ決定論的なアルゴリズムです。
このアルゴリズムがデフォルトのアルゴリズムよりも優れたパフォーマンスを発揮するためには、疑似ランダム関数に適したハッシュ関数を選択することが重要な考慮事項となります。
前述したように、このような関数は [HRW1999] に記述されています。
そして[HRW1999]で好ましいとされている2つのハッシュ関数のうち、最初の関数を候補とします。

Wrand(V, Es, Si) = (1103515245((1103515245.Si+12345) XOR D(V, Es))+12345)(mod 2^31)

ここで、D(V, Es)は14-octetのストリーム(4-octetのEthernet Tag Vと10-octetのESI)の31-bit dijest(HRW1999で言及されているようにCRC-32と最上位ビット(MSB)を破棄する)です。
Ethernet TagとESIをネットワークバイト順に連結した14オクテットのストリームを形成することが義務付けられています。CRCはストリームがネットワークバイト順（ビッグエンディアン）のように処理すべきです。Siはi番目のサーバーのアドレスです。そのサーバーのIPアドレス長は関係なく、下位31ビットのみがモジュロで重要です。注意点として、Weight関数はEthernet Tag、そのES、またそのPEのIPアドレスの組み合わせを考慮し、サーバーIPアドレスの実際の長さ（IPv4かIPv6か）はあまり関係ありません。

[RFC7432]で定義されたデフォルトのアルゴリズムはIPv4とIPv6両方のPEアドレスを使うことが出来きません、なぜなら[RFC7432]ではIPv4アドレスとIPv6アドレスの両方が設定されている場合にどのようにPE IPアドレス順序（序列）を決めるのかを示していないためです。

HRWは当ドキュメントのセクション1.3.1で指摘したデメリットを解決し、

・非常に高い確率でPEが2つの場合でも、ESに設定されたVLANのDF ElectionのタスクはPEが2つの場合でもPE間で多かれ少かれ均等に分散されます（セクション1.3.1で列挙された最初の基本的な問題点を参照）
・そのVLANのDFやBDFでないPEがダウンしたり、ESとの接続が切れたりしても、DFやBDFの再割り当てには至らない。これにより、特に接続がフラップした場合の計算を節約することができます。

・そのVLANのDFやBDFでないPEがダウンしたり、ESとの接続が切れたりしても、DFやBDFの再割り当てには至りません。これにより、特に接続がフラップする場合の計算を節約することができます。

・さらに重要なことは、1.3.1節で挙げた既存のデフォルトのDF Electionに内在する3番目の基本的な問題（不必要な混乱）を回避することです。

・このアルゴリズムでは、DFに加えて、現在のDFが失敗した場合のDFとなるBDFも提供されます。

4.The AC-Influenced DF Election Capability

このセクションで説明する手順はEVPN Serviceの[RFC7432]とEVPN VPWS[RFC8214]におけるDF Electionに適用されます。

AC-DF Capabilityは今後将来的に出てくる全てのDF algorithmへ広く適用出来ることが期待されます。BDに属するACでトラフィックを転送できないES内の候補PEを考慮から外すことで、DF Electionの手順を変更します。BDに属するACでトラフィックを転送できないES内の候補PEを考慮から除外することにより、DF選出手順を変更します。このセクションではVLAN-basedとVLAN Bundle Service interfaceに適用されます。セクション4.1ではVLAN-aware Bundle serviceについて記述します。

特にデフォルトのDFアルゴリズムと併用する場合、AC-DF機能は[RFC7432]のセクション8.5で説明されているDF選択手順のステップ3を次のように変更します。

3. タイマーが満了したとき、それぞれのPEはそのESに接続されているすべてのPEノード（自身を含む）のIPアドレスの順序付き候補リストを数値の昇順で作成します。候補リストはES RouteのOriginating Router’s IP addressに基づいていますが、ES経路ごとのEthernet A-Dを受信していないPE、または経路がwithdrawnされたPEは除外されます。その後、DF Electionアルゴリズムは<ES, Ethernet Tag>単位で適用されますが、あるPEのIPアドレスは、そのPEから対応するEVIごとのEthernet A-D Routeを受信するまで、ある<ES, Ethernet Tag>の候補とは見なされません。言い換えると、ES上 の ACS は、PE が BD の候補とみなされるように UP する必要があります。

デフォルトのDFアルゴリズムが使用される場合、候補リストの各PEには、IPアドレスが最も小さいPEを示す0から始まる順序が与えられます。
序数は、ES上の与えられたEthernet Tagに対して、どのPEノードがDFになるかを以下のルールで決定するために使用されます。

N個のPEノードからなる冗長グループを想定し、VLAN-based serviceでは(V mod N) = iのとき、序数iのPEが<ES, Ethernet Tag V>のDFとなります。VLAN(-aware) Bundle Serviceの場合、ES上のバンドル内で数値的に最も低いVLAN値がEthrenet Tagとしてモジュロ機能で使用されなければなりません（MUST）。

順序付きリストに必要なPE IPアドレスを取得するために、ESルート内のOriginating RouterのIPアドレスフィールド[RFC7432]を使用すると、そのような必要が生じた場合、CEが異なるBGP AS（AS）にまたがってマルチホームされることができることに注意する必要があります。

上記の修正されたステップ3は[RFC7432]のセクション8.5のStep3とはこれら2つの点で異なります。

o 記述されているモジュラスベースのDFアルゴリズム（このドキュメントではデフォルトDF ElectionもしくはDF Alg0と呼ぶ）のみならず、どんなDFアルゴリズムでも使用することが出来ます

o Ethernet A-D route未受信によってこの候補リストは削除されます：もしEthernet A-D per ES routeのwithdrawnを受信した場合、PEのIPアドレスはES候補リストから削除されるべきです。もし<ES,Eternet Tag>に紐づくEthernet A-D per EVI経路がwithdrawnされた場合、PEのIPアドレスは<ES, Ethernet Tag>の候補DFとして考慮すべきではありません。

次の例は、図2のネットワークを想定して、デフォルトのDF Electionアルゴリズムに適用されるAC-DFの動作を説明するものです。

(a) PE1とPE2はES12を検出するとES12のES RouteをES-import Ext-CommとAC-DFが1にセットされたDF Election Ext-Commを広報し、それぞれ独立してDF Wait Timerを開始します。

(b) PE1とPE2はES12のEthernet A-D per ES routeを広報します。
PE2とPE3はES23のEthernet A-D per ES routeを広報します。

(c) そしてPE1/PE2/PE3らはそれぞれのACらが有効化されたらすぐにAC1/AC2/AC3とAC4のEthernet A-D per EVI routeを広報します。
ACは単一のカスタマーVID（VLAN-based service interface）もしくはカスタマーVIDsのバンドル（VLAN Bundle Service interface）と関連づけることが出来ることに注意してください。

(d) タイマー満了した時、上記の修正されたStep3手順で説明されているように、各PEらはESに接続されている全てのPEノード（自分含む）のIPアドレスの順序付き候補リストを生成します。そしてEthernet A-D per ES routeを受信していない全てのPEはそのリストから削除されます。

(e) あるBDのDFを選出した時、PEはEthernet A-D per EVI routeをそのPEから受信するまで候補とみなされません。言い換えると、PEがそのBDの候補としてみなされるには、あるPEのES上ACSがUpしている必要があります。例えば、PE1はPE2から<ES12, VLAN-1>のEtherenet A-D per EVI routeを受信するまでPE2をDF候補としてみなしません。

(f) ACS=DOWNのPEが候補リストから削除されると、残りのN個の候補に対してDF Electionを適用することができます。この手順はDF Election Ext-Commの追加と処理、およびDF Electionに参加するPEの候補リスト削除によって、既存のEVPN Control-Planeを変更するだけであることに注意してください。

当ドキュメントのセクション2.1のFSMの箇所で定義されたイベントに加え、下記のイベントが候補PEリストを修正し、与えられた<ES, Ethernet ag>のPEでDFの再選出をトリガーしなければならない（SHALL）。
図3で図示されているFSMにて、下記のイベントらは DF_DONEからDF_CALC:への遷移のトリガーとならねければなりません。

ローカルのACがDown/Upする
その<ES, Ethernet Tag>のEthernet A-D per EVI routeのUpdate/Withdrawalを受信する
そのESのEthernet A-D per ES routeのUpdate/Withdrawalを受信する

4.1. AC-Influenced DF Election Capability for VLAN-Aware Bundle Services

セクション4で述べた手順はVLAN-basedとVLAN Bundle interfaceで動作します、なぜならこれらのサービス種別ではPEは<ES, VLAN>毎もしくは<ES,VLAN Bundle>毎に1つのEthernet A-D per EVI経路のみを広報するからです。セクション4ではEthernet TagはDF ElectionのためにVLANもしくはVLAN Bundleを示します。
このような経路のWithdrawalはPEがその特定の<ES, VLAN>または<ES, VLAN Bundle>上のトラフィックを転送できないことを意味し、従って

ごめんなさい、このへんaware-bundleだからって後回しにしてます

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.

   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>.

   This document modifies the DF election for VLAN-aware Bundle services

   in the following ways:

   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  The PEs will now follow the procedures in Section 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.

5. Solution Benefits

このドキュメントで説明するソリューションには以下のメリットがあります：

(a) [RFC7432]で定義されているDF Electionを拡張し、デフォルトのDF Electionアルゴリズムにある不公平な負荷分散とブラックホール化の可能性の問題に対処するものです。このソリューションは、EVPNサービス[RFC7432]とEVPN VPWS[RFC8214]のDF選挙に適用可能です。

(b) 広告するPEが意図するDF ElectionアルゴリズムとCapabilityをシグナリングする方法を定義しています。これはDF Election Extended Communityを定義することによって行われ、広告するPEは、このドキュメントで定義されたCapabilityと、その後に定義されるDF ElectionアルゴリズムやCapabilityのサポートを示すことができます。