draft-ietf-bess-evpn-pref-df-08翻訳
注意
- RFCを読みやすく理解しやすくするようにDeeplベースで翻訳しました。
- 元ドキュメントhttps://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-08
draft-ietf-bess-evpn-pref-df-08 Preference-based EVPN DF Election
Abstract
Ethernet Virtual Private Networks(EVPN)のDesignated Forwarder(DF)はall-active multi-homingのEthernet Segment(ES)の場合、マルチホームのデバイス/ネットワークへBroadcast、Unkown Unicast、Broadcastトラヒック(BUM)を、シングルアクティブのマルチホームの場合はBUMとUnicastを送る責任を負うPEと定義されています。DFはデフォルトDF選択アルゴリズムに従ってEVPNネットワークに同じイーサネットセグメント識別子(ESI)を広報するPEの候補リストから選択されます。 デフォルトアルゴリズムはESの異なるイーサネットタグ間でDFを選択する効率的で自動化された方法を提供しますが、より'決定的'かつユーザー制御の方法が必要とされる使用事例もあります。 同時に、サービスプロバイダは既存のDFのメンテナンス作業を行うため、または新しいアクティブPEが既存のDF PEをpreemptできるかどうかを制御するために、オンデマンドDFスイッチオーバーを強制する簡単な方法を必要としています。
本書では、決定性と動作制御の要件を満たすDF Electionアルゴリズムを提案します。
Status of This Memo
略
Copyright Notice
略
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Solution requirements . . . . . . . . . . . . . . . . . . 3
2. Requirements Language and Terminology . . . . . . . . . . . . 4
3. EVPN BGP Attributes Extensions . . . . . . . . . . . . . . . 5
4. Solution description . . . . . . . . . . . . . . . . . . . . 6
4.1. Use of the Highest-Preference Algorithm . . . . . . . . . 7
4.2. Use of the Lowest-Preference Algorithm . . . . . . . . . 9
4.3. Use of the Highest-Preference algorithm in [RFC7432]
Ethernet Segments . . . . . . . . . . . . . . . . . . . . 9
4.4. The Non-Revertive Capability . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1.Introduction
1.1. Problem Statement
[RFC7432]では、EVPNネットワークにおけるDesignated Forwarder(DF)を、All-Active Multihoming ESの場合はマルチホームのデバイス/ネットワークにBroadcast、Unkown Unicast、Broadcastトラフィック(BUM)を、Single-Active Multihomingの場合はマルチホームのデバイスやネットワークにBUMとUnicastトラフィックを送る責任を負うPEと定義しています。DFはEVPNネットワークにイーサネットセグメント識別子(ESI)を広報するPEの候補リストから、[RFC8584]によるDF Election Algorithm(DF Alg)に従って選択されます。デフォルトDF Alg [RFC7432]またはHRW [RFC8584]はES内の異なるイーサネットタグ間でDFを選択する効率的で自動化された方法を提供しますが、より'決定的'でユーザ制御の方法が必要な使用ケースもあります。 同時に、サービスプロバイダは既存のDFのメンテナンス作業を行うため、または新しいアクティブPEが既存のDF PEをpreemptできるかどうかを制御するために、オンデマンドDFスイッチオーバーを強制する簡単な方法を必要としています。この文書では上記のニーズに対応する新しいDF Algとcapabilityを提案します。
1.2. Solution requirements
本書で説明する手順は、以下の内容を満たしています。
要件:
a. このソリューションはadministrative preferenceオプションを提供し、候補となるPEがすべてDFとして引き継ぐ運用準備が整っていると仮定して、どのような順番でDFになるかをユーザーが制御できるようにします。
b. この拡張は [I-D.ietf-bess-evpn-virtual-eth-segment] で定義されている [RFC7432] Ethernet Segmentとvirtual ESに対して機能します。
c. ユーザーはES 内のすべての PE を再設定することなく、与えられた Ethernet Tag に対して既存の DF をpreemptするようPEに強制することができます。
d. このソリューションでは、たとえ以前の DF PE が障害後に復旧しても、現在の DF をpreempティー内sいオプションを許可します。 これは、常に復帰的である[RFC7432]のDF選択手順とは対照的に、「非復帰的」な動作としても知られています。
e. このソリューションはSingle-ActiveおよびAll-ActiveのMultihoming Ethernet Segmentで機能します。
2. Requirements Language and Terminology
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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
o AC - Attachment Circuit. An AC has an Ethernet Tag associated to it.
o BUM - refers to the Broadcast, Unknown unicast and Multicast traffic.
o DF, NDF and BDF - Designated Forwarder, Non-Designated Forwarder and Backup Designated Forwarder.
o DF Alg or simply Alg - refers to Designated Forwarder Election Algorithm.
o HRW - Highest Random Weight, as per [RFC8584].
o ES, vES and ESI - Ethernet Segment, virtual Ethernet Segment and Ethernet Segment Identifier.
o EVI - EVPN Instance.
o ISID - refers to Service Instance Identifiers in Provider Backbone Bridging (PBB) networks.
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 (VLAN-Based or VLAN Bundle services) or multiple (VLAN-Aware Bundle services) Broadcast Domains.
o EVC - Ethernet Virtual Circuit.
o DP - refers to the "Don't Preempt me" capability in the DF Election extended community.
o OAM - refers to Operations And Maintenance protocols.
o Ethernet A-D per ES route - refers to [RFC7432] route type 1 or Auto-Discovery per Ethernet Segment route.
o Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or Auto-Discovery per EVPN Instance route.
o Ethernet Tag - used to represent a Broadcast Domain 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 Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network Identifiers), normalized VID, I-SIDs (Service Instance Identifiers), etc., as long as the representation of the broadcast domains is configured consistently across the multi-homed PEs attached to that ES. The Ethernet Tag value MUST be different from zero.
3. EVPN BGP Attributes Extensions
このソリューションはES routeとともに広報される[RFC8584]で定義されたDF Election Extended Communityを再利用し、拡張するものです。
Figure 1: DF Election Extended Community
ここで、以下のフィールドは以下のように定義されます。
o DF Alg は以下の値を持つことができます。
Alg 0 - デフォルトのDF Electionアルゴリズム、またはモジュラスベースの[RFC7432]に従ったアルゴリズム。
Alg 1 - [RFC8584]に従ったHRW algorithm
Alg 2 - Highest-Preference algorithm (このドキュメント)。
Alg TBD - Lowest-Preference algorithm(このドキュメント)。TBDは、発行時にその時点で割り当てられている値に置き換えられます。
o ビットマップ(2オクテット)は以下の値を持つことができます。
Figure 2: Bitmap field in the DF Election Extended Community
Bit 0(DF Election Extended CommunityのBit 24に相当し、本書で定義されます)。Dビットまたは'Don't Preempt'ビット(以下 DP)は、ES routeを広報するPEがES内のリモートPEにDF としてpreemptしないように要求するかどうかを決定します。 デフォルト値はDP=0であり、デフォルトDF Alg [RFC7432] の「preempt」または「revertive」動作と互換性があります。DP Capabilityは Alg 2とAlg TBDでサポートされており、DF Alg 0または1と一緒に使用することもできます。 DF Alg 0または1のDP Capabilityの手順は、このドキュメントの範囲外です。
Bit 1:AC-DFまたはAC-Influenced DF Election。[RFC8584]で説明されている通り。 1に設定された場合、ES内の残りのPEでAC-Influenced DF Electionを使用することを希望することを示します。AC-DF Capabilityビットは、DP CapabilityおよびDF Alg 2またはAlg TBDと共に設定することもできます。
o DF Preference (このドキュメントで定義): ESのDFになるためのPEのpreferenceを示す2オクテット値を定義します。 許容される値は0-65535の範囲であり、デフォルト値は32767でなければなりません。 この値は許容されるpreferenceの範囲の中間点であり、オペレータはデフォルトのpreferenceの上または下の相当数の値を選択する柔軟性を与えます。DF Preference フィールドは、DF Alg 2とDF Alg TBDに固有であり、他のAlgに対するPreference値は表しません。DF AlgがAlg 2またはAlg TBDと異なる場合、これら2つのオクテットは異なる方法でエンコードすることができます。
4. Solution description
Figure 3 illustrates an example that will be used in the description of the solution.
Figure 3: Preference-based DF Election
図3はアグリゲーションネットワークから来るEVCをEVPNネットワーク内のEVIに接続している3つのPEを示しています。 CE1はPE1とPE2にまたがるvES1に接続され、CE2はPE1、PE2、PE3で定義されるvES2に接続されています。
vES1とvES2のアルゴリズムがAlg 2またはAlg TBD、すなわちHighest-PreferenceまたはLowest-Preferenceである場合、PEはIPアドレスに関係なく管理上のPreference値に基づいてDFになる可能性があります。 以下のセクションはいくつかの例を示しています。図 3 のユースケースで手順とその適用方法を説明します。
4.1. Use of the Highest-Preference Algorithm
オペレータがあるvESのためにどのPEがDFになるか、また複数の障害が発生した場合にPEがDFになる順序を柔軟に制御したいと仮定すると、以下の手順で行うことができます。
a. vES1とvES2はDF Election Extended Communityでシグナリングされる3つのオプションパラメータで設定できるようになりました。
これらのパラメータはPreference 、Preemption option (または "Don't Preempt Me" option) 、そしてDF Algです。これらのパラメータを(Pref,DP,Alg)と表現します。 vES1はPE1で(500,0,Highest-Pref)、PE2で(255,0,Highest-Pref)として構成されているとします。vES2はPE1、PE2、PE3でそれぞれ(100,0,Highest-Pref)、(200,0,Highest-Pref)、 (300,0,Highest-Pref)として構成されると仮定しましょう。
b. PEはDF Election Extended Communityの3つのパラメータを含む各vESのES routeを広報します。
c. [RFC8584]によると、各PEはDF待機タイマーが切れた時点でDFエレクションアルゴリズムを実行します。 この場合、次のように各PEは各ESに対して以下のように最重要DF Algを実行します:
PE は各ES RouteのDF Alg値をチェックし、すべてのES RouteがこのDF Alg値に一致し、値が2 (Highest-Preference) である場合、PEはこのセクションの手順を実行します。そうでない場合は[RFC7432] Default Algにフォールバックします。
この最高優先度アルゴリズムでは、各PEは優先度順に並べた候補PEリストを作成します。 例えばPE1はPE1>PE2 のようにvES1の候補となるPEをPreferenceの高い順に並べたリストを作成します。 したがって、PE1 がvES1のDFとなります。同様にPE3はvES2のDFとなります。
d. PE3のメンテナンスが必要な場合、vES2のPreferenceを50に設定し、PE2をvES2のDFとして使用することができます(DP Capabilityに関係なく)。PE3のメンテナンスタスクが終了したら、PE3のPreferenceを50に設定します。オペレータは既存のPreferenceを残すか古いPreferenceを設定し直します。
e. ES内の2つ以上のPEでPreferenceが等しい場合、DPビットとIPの最小値がタイブレーカーとして使用されます。最も高いPreference値を持つPEを選択した後、実装はまずDPビットを設定した広報PEを選択し、次に最も低いIPアドレスを持つPEを選択しなければなりません(DPビット選択で一意の候補が得られない場合)。PEのIPアドレスは、候補リストで使用されるアドレスであり、ES routeのオリジンルータのIPアドレスから導き出されます。DPビットとIPアドレスのタイブレーカーを使用するいくつかの例を以下に示します。:
仮にvES1のパラメータがPE1で(500,0,Highest-Pref)、PE2で(500,1,Highest-Pref)の場合、DPビットによりPE2が選択されます。
vES1のパラメータがPE1で(500,0,Highest-Pref)、PE2で(500,0,Highest-Pref)の場合、PE1のIP アドレスがPE2のIPアドレスより低いと仮定するとPE1が選出されるでしょう。
f. Preferenceはadministrativeオプションであり、管理プレーンからES単位で設定されなければなりませんが、ローカルポリシーの使用に基づいて動的に変更することも可能です。
例えば、PE1とアグリゲーションネットワーク間の2ポートLAGが1ポートを失った場合など、ENNIポートの帯域が50%減少した場合、PE1ではES1のPreferenceを500から100に下げることができます。 ポリシーはコアのPEの帯域幅の有効性、特定のポートの動作停止などに基づいて、動的なPreferenceの変更をトリガーすることが出来ます。 実際のローカルポリシーの定義はこのドキュメントのスコープ外です。 デフォルトのPreferenceの値は32767です。
Highhest-Preference Alg は、AC-DF capabilityと共に使用しすることができます。 ES内の全てのPEがHighest-Preference AlgとAC-DF capabilityで一貫して設定されていると仮定すると、[RFC8584]で説明されているように、Ethernet A-D per ESとEthernet A-D per EVI routesを受信しない限り、そのPEはDF Electionの候補者とは見なされません。 この文書の手順は[I-D.ietf-bess-evpn-virtual-eth-segment]のように[RFC7432]に基づくESまたはvESで使用でき、[RFC8214], [RFC7623] または [RFC8365] のようなEVPNネットワークを含むことが可能です。
4.2. Use of the Lowest-Preference Algorithm
セクション4.1で述べたHighest-Preference Alg に加えて、本書ではLowest-Preference Algを定義します。 この場合、図3のvES1の例では、ES内の全てのPEにLowest-Preference Algが設定された場合、PE2がその低いPreferenceによりDFとなります。
セクション4.1で述べた手順はすべてLowest-Preference Algに適用され、Highest-PreferenceタイブレークをLowest-Preferenceタイブレークに置き換えるだけです。
Highest-PreferenceとLowest-Preference Algsは異なる Alg であるため、Highest-PreferenceとLowest-Preferenceに設定された 2 つの PE が同じ ES に接続されている場合、運用上のDF Election Alg はデフォルトAlg にフォールバックされます。
4.3. Use of the Highest-Preference algorithm in [RFC7432] Ethernet Segments
セクション4.1で説明したHighest-Preference (またはLowest-Preference) DF Algは、通常vESごとに個々のEthernet Tagが存在する仮想ESで使用されますが、既存の[RFC7432]の定義では同一のES上で最大数千のEthernet Tagを許容しています。 この場合、もしESの全てのPEにHighest-Preference(またはLowest-Preference)Algが設定されていれば、同じPEがESの全てのEthernet TagのDFとして選出されることになります。 よりきめ細かいロードバランシングを実現する方法として、以下のようなものがあります。
ESはadministrative Preference値、例えばHighest-Preference Algで設定されますが、その後イーサネットタグの範囲を定義して、希望の動作に応じてLowest-Preferenceを使用することができます。 このオプションでは、PEはPreferenceによって並べられたPE候補のリストを構築するが、与えられたEthernet Tagに対するDFは、ローカルな設定によって決定されます。
For instance:
o ES3 が PE1 と PE2 で定義されていると仮定すると、PE1 は ES3 に対して (500,0,Highest-Preference) に、PE2 は (100,0,Highest-Preference) に設定されるかもしれません。
o さらに、VLAN-based service interfacesで、PEが1-4000の範囲のすべてのEthernet Tagsに接続されていると仮定すると、PE1とPE2の両方は、(Ethernet Tagsの範囲、低)、例えば、(2001-4000、低)で構成されることになります。
o この結果、PE1がイーサネットタグ1-2000に対してDFとなり(デフォルトのHighest-Preference Algを使用するため)、PE2がイーサネットタグ2001-4000に対してDFとなります(ローカルポリシーにより上書きされるため)。Highest-Preference Alg.
3つ以上のPEに接続されたイーサネットセグメントでは、PE間でDF機能を公平に分配する他のロジックは、ES内のすべてのPEでそのロジックが一貫している限り有効です。ローカルポリシーが、ESの全PEから通知されたHighest-PreferenceまたはLowest-Preferenceを上書きする場合、このローカルポリシーはESの全PEで一貫していなければならないことに注意することが重要です。 ESのあるEthernet Tagに対してローカルポリシーの一貫性がない場合、そのEthernet Tagでブラックホールやパケットの重複が発生する可能性があります。
4.4. The Non-Revertive Capability
セクション1.2 (d)で述べたように、与えられた Ethernet Tag に対して既存の DF をPreemptしないCapabilityが必要であり、そのため DF Election Extended Communityに追加されました。 このオプションは、DF Electionにおける非復帰的な動作を可能にします。
ESのPEがメンテナンスのために停止した場合、それを復帰させる前に、プリファレンスが変更され、非復帰的な動作を提供することに注意してください。 DPビットとこのセクションで説明するメカニズムは以前のDFが保守作業なしで復旧し、非復帰的なオプションが望まれる場合に使用されます。
サービスに影響を与える。図3では、PE3がESI2のDFであると仮定しています。PE3にリンク、EVC、またはノード障害が発生した場合、PE2がDFとして引き継ぎます。PE3が復旧した場合、PE3が引き継ぎ、ESに不要なパケットロスを発生させます。以下の手順では、障害回復時のPreemptを回避することができます(図3を参照)。 この手順は非復帰モードをサポートし、これと一緒に使用することができます。
o Highest-Preference Alg
o Highest-Preference Alg , Ethernetタグの範囲でローカルポリシーがHighest-Preferenceタイブレーカーをオーバーライドする場合
o Lowest-Preference Alg
この手順は、ESのHighest-Preference Alg 、ローカルポリシーが与えられたEthernet Tagのタイブレーカーをオーバーライドする、これが最も複雑なケースであるため、仮定して説明されています。 上記の他の2つのケースは、このケースのサブセットであり、その違いは後で説明されます。
-
A"Don't Preempt Me" capabilityは、セクション3に記載されているように、PE/ES単位で定義されます。 "Don't Preempt Me"が無効(デフォルト動作)の場合、広報されるDPビットは0になります。 "Don't Preempt Me"が有効の場合、ESルートは広報されます。
DP=1 ("Don't Preempt Me")とする。 ES 内の全ての PE は DP capabilityの設定に一貫性を持たせるべきですが、本ドキュメントは全ての PE に一貫性を強制するものではありません。 同じ ES の PE で DP capabilityのサポートに矛盾がある場合、非復帰的な動作は保証されません。しかし、このcapabilityをサポートするPEはこの手順を試行します。 -
ES内の全てのPEで'preemption'を回避したいと仮定し、3つのPEは「Don't Preempt Me」capabilityで構成されます。 この例ではESI2が以下のように構成されていると仮定します。'DP=enabled'を3つのPEで使用します。
-
vES2はDF AlgとしてHighest-Preferenceを使用し、Ethernet Tag-2にはLowest-Preferenceを使用するよう3つのPEでローカルポリシーが設定されていると仮定します。 3つのPEでvES2が有効になると、PEはESルートを交換し、Ethernet Tag-1のDFとしてPE3(Highest-Preferenceのため)、Ethernet Tag-2のDFとしてPE1(Lowest-Preferenceのため)が選択されます。
-
PE3のvES2がダウンした場合(OAMで検出されるEVCの障害、または ポート障害またはノード障害)、PE2がDFになります。Ethernet Tag-1 Ethernet Tag-2については変更ありません。
-
PE3のvES2が復旧すると、PE3はブートタイマー(起動している場合)またはホールドタイマー(ポートまたはEVCが復旧した場合)を開始します。 このタイマーは、PE3がPE1やPE2からESルートを受信するための時間を確保します。 このタイマーは、[RFC8584]で説明されているDF Election Finite State MachineのINITとDF_WAIT状態の間で適用される。 その後、PE3は
vESのES経路の中から、”Highest-PE”と”Lowest-PE”の2つの”reference-PE”を選択する。
Highhest-PEはDPビットを最初に使用し(DP=1が良い)、その後にPE-IPアドレスの小さい方をタイブレーカーとして、Preferenceの高いPEを指します。 PE3はPE1よりもPE2をHighest-PEとして選択します。なぜなら、(Pref,DP,PE-IP)を比較すると、(200,1,PE2-IP)が(100,1,PE1-IP)よりも勝っているからです。
最下位PEは、DPビット(DP=1が良い)を最初に使用し、その後、PE-IPアドレスの小さい方をタイブレイクとして、Preferenceが低いPEとします。 PE3は、(100,1,PE1-IP) が (200,1,PE2-IP) よりも勝っているので、PE1 を PE2 よりも Lowest-PE として選択することになります。
ESにリモートPEが1つしかない場合は、注意が必要です。最下位と最上位のPEは同じPEになります。
自分のadministrative Prefを確認し、ES ルートに DP=1 が設定されている上位 PE、下位 PE と比較します。 この比較により、PE3は管理上の(Pref,DP)と異なる可能性のある(Pref,DP)を持つESルートを送信することになります。
PE3のPref値がHighest-PEより高い場合、PE3は、Highest-PEと比較して は、「使用中」の運用 Pref で ES 経路を送信します。はHighest-PEと等しく、DP=0です。
PE3のPrefがHighest-PEより大きい場合、PE3はHighest-PEと同じPrefでDP=0のESルートを送信します。
PE3のPref値がHighest-PEまたはLowest-PEより高くも低くもない場合、PE3は管理上(Pref,DP)=(300,1)でESルートを送信します。
Iこの例では、PE3の管理上のPref=300は、DP=1のHighest-PE、つまりPE2(Pref=200)より高くなっています。 したがって、PE3はPE2のpreferenceを継承し、運用上の「使用中」(Pref,DP)=(200,0)でESルートを送信します。
PEはアドバタイズされたPrefが(「管理」Prefではなく)「使用中」のoperational Prefである限り、常にDP=0を送信することに注意してください。
PE3 が (200,0,PE3-IP) で送信するこのES routeアップデートは、どのイーサネットタグに対しても DF のswitchoverを起こしません。PE2 は Ethernet Tag-1 に対して DF を継続します。 これは、DP ビットが DF Electionのタイブレーカーとして使用されるからです。 つまり、ある PE が同じ Pref を持つ 2 つの候補があった場合、DP=1 のものを選択する。 Ethernet Tag-2 についてもDFの変更はありません。
- その後、ESのupdate/withdrawがあった場合、PEは(5)のプロセスを経て、Highest-PEとLowest-PEを選択します。 例えばPE2が故障した場合、PE2のESルート撤退を受けてPE3とPE1は、(自分たちのアクティブなES routeを考慮して)新しいHighest-PEとLowest-PEを選択し、DF Electionを実行することになります。
もし PE が自らをHighestまたはLowest-PE として選択し、それ以前は選択しなかった場合、PE はoperational Pref とadministrative Pref を比較します。 異なる場合、PE はadministrative Pref と DP 値を含む ES routeアップデートを送信します。 この例ではPE3が新しいHighest-PEとなり、(Pref,DP)=(300,1)のES routeアップデートを送信します。
DF Electionを実行すると、PE3 がEthernet Tag-1の新しい DF になります。Ethernet Tag-2については変更ありません。
ESがHighest-Preference Algを使用する場合(全てのイーサネットタグに対して、ローカルポリシーなし)、PEは「参照-PE」として「Highest-PE」のみを選択すればよい(つまり、「Lowest-PE」を選択する必要はない)。 ESがすべてのイーサネットタグに対して最下位優先Algを使用する場合、PEは「reference-PE」として「Lowest-PE」を選択する必要があるのみです。 残りの手順は同じである。
DPビットに関係なく、PEまたはESが戻ってきたとき、PEがES内の他のPEで設定されたものと異なるDF ElectionAlgを広報した場合、ES内の全てのPEはデフォルト[RFC7432]Algにフォールバックしなければならないことに注意してください。本書は、PEにおける復帰または非復帰の動作に関係なく、DF Election実行後にES内のPEによって広報されるEthernet A-D per EVI route [RFC8214]のPおよびBビットの使用を変更しません。
5. Security Considerations
このドキュメントでは、与えられたEthernet Tagに対してどのPEをDFとするかを(設定により)絶対的に制御するDF Election Algorithmについて説明します。このような制御は多くの状況で望まれているが、悪意のあるユーザがES内のPEの設定にアクセスすることで、ネットワークの動作が変化する可能性があります。HRWのような他のDFアルゴリズムではDFの選出はより自動化されており、設定によって決定されることはありません。
この文書で説明されている非可逆的なcapability、通常の EVPN 可逆的 DF Electionよりもセキュリティが向上していると見なすことができます。PE のリンク(またはノード)の故意の「ばたつき」は、PE が NDF 状態になったときに一度だけサービス中断の原因となります。このドキュメントでは、ローカルポリシーがESのイーサネットタグの範囲に対する最高優先度Algをオーバーライドする方法についても説明しています。 もしローカルポリシーがES内の全てのPEで一貫しておらず、異なるPEでHighest-PreferenceやLowest-Preferenceが使用されているEthernet Tagがある場合、ブラックホールやパケット重複が発生する可能性があるため、ローカルポリシーはES内の全てのPEで一貫している必要があります。
6. IANA Considerations
このドキュメントでは以下値の割り当てを要求します:
o DF Alg = 2 in the [RFC8584] "DF Alg" registry, with name "Highest-Preference Algorithm".
o DF Alg = TBD in the same "DF Alg" registry, with name "Lowest-Preference Algorithm".
o Bit 0 in the [RFC8584] DF Election Capabilities registry, with name "D (Don't Preempt) Capability" for Non-revertive ES.
Author And Source
この問題について(draft-ietf-bess-evpn-pref-df-08翻訳), 我々は、より多くの情報をここで見つけました https://zenn.dev/yuheiotsuka/articles/fe4623b9ed49e8著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Collection and Share based on the CC protocol