📝

draft-ietf-bess-evpn-mh-pa-05翻訳

2022/03/30に公開

memo

tech

注意

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

EVPN multi-homing port-active load-balancing draft-ietf-bess-evpn-mh-pa-05

Abstract

MC-LAG（Multi Chassis Link Aggregation Group）技術は、独立した冗長ノード群による論理的なリンクアグリゲーション接続を実現する技術です。マルチシャーシLAGの目的は、トラフィックの共有や分散の異なるモードを提供しながら、より高いネットワークの可用性を達成するためのソリューションを提供することです。RFC7432ではSingle-ActiveおよびAll-ActiveのロードバランスモードのEVPNベースのMC-LAGを定義しています。
このdraftでは、EVPNでサポートされている既存の冗長メカニズムを拡張し、Port-Activeロードバランシングモードのサポートを導入します。

Status of This Memo

略

Copyright Notice

略

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Multi-Chassis Link Aggregation  . . . . . . . . . . . . . . .   4
   3.  Port-active Load-balancing Procedure  . . . . . . . . . . . .   4
   4.  Designated Forwarder Algorithm to Elect per Port-active PE  .   5
     4.1.  Capability Flag . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Modulo-based Algorithm  . . . . . . . . . . . . . . . . .   6
     4.3.  HRW Algorithm . . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Preference-based DF Election  . . . . . . . . . . . . . .   7
     4.5.  AC-Influenced DF Election . . . . . . . . . . . . . . . .   7
   5.  Convergence considerations  . . . . . . . . . . . . . . . . .   8
     5.1.  Primary / Backup per Ethernet-Segment . . . . . . . . . .   8
     5.2.  Backward Compatibility  . . . . . . . . . . . . . . . . .   9
   6.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Overall Advantages  . . . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction

EVPNは[RFC7432]に従いマルチホーミングのためにフローごとのall-activeな負荷分散を提供します。また冗長関係にあるPEの1つがサービスごとにアクティブになるservice carvingモードのSingle-Activeも定義しています。これら2つのマルチホーミングはデータセンターやサービスプロバイダのアクセスネットワークで最も広く利用されていますが、インターフェースごとのアクティブスタンバイによるマルチホーミングの負荷分散が有効であり、必要とされるシナリオもあります。このモードの負荷分散の主な考慮点はマルチホーミングを提供する複数のPEにまたがる統計的なフローごとの負荷分散ではなく、特定のインターフェースを介して転送されるトラフィックを決定することです。インターフェイスごとのアクティブスタンバイによって提供される決定性は、特定のQoS機能を動作させるためにも必要です。このモードを使用する場合、顧客は障害時の収束を最小限に抑えることも期待できます。新しいタイプのロードバランシングモードであるPort-Activeロードバランシングが定義されています。このドラフトではEVPNを介して新しいロードバランシングモードをサポートする方法を説明します。この新しいモードはインターフェースごとのアクティブ／スタンバイと呼ばれることもあります。

Figure 1: MC-LAG Topology

図1は、PE1とPE2が同じ冗長グループの一員として、インターフェースI1とI2を通じてCE1にマルチホーミングを提供するMC-LAGマルチホーミングトポロジーを示しています。インターフェースI1とI2は、LACPプロトコルを実行するLAGのメンバーです。コアはIPまたはMPLSに対応し、幅広いL2およびL3サービスを提供します。 MC-LAGのマルチホーミング機能は、コアのこれらのサービスから切り離され、CEへのマルチホーミングの提供に特化しています。ポートごとのアクティブ／スタンバイのロードバランシングにより、2つのインタフェースI1またはI2のうち1つだけがフォワーディングになり、もう1つのインタフェースはスタンバイになります。これは、アクティブインタフェースのすべてのサービスがアクティブモードで、スタンバイインタフェースのすべてのサービスがスタンバイモードで動作することも意味します。

1.1. Requirements Language

略

2. Multi-Chassis Link Aggregation

[IEEE.802.1AX_2014] リンクアグリゲーション制御プロトコル（LACP）を使用してCEがPEノードにマルチホームされる場合、PEはイーサネットリンクをリンクアグリゲーショングループ（LAG）として形成し動作するために単一のLACPスピーカーであるかのように動作しなければなりません。これを実現するには、同じマルチホームCEに接続されているPE間で、LACPの設定と運用データを同期させる必要があります。そのためにICCP(Interchassis Communication Protocol) [RFC7275]が使用されています。 EVPN LAGはその解決策を大幅に簡略化します。簡略化に伴い、いくつかの前提条件があります。

マルチホーミングPEに接続されたCEデバイスは、そのすべてのアクティブリンクで単一のLAGを持つことができます。
ピアリングPEにはシステム ID、ポート優先度、ポートキーなど、同じ LACP パラメータが設定されなければなりません。
このリストからのいかなる相違も、ピアリング PE 間の誤設定や誤配線検出と同様に、本ドキュメントの範囲外です。

3. Port-active Load-balancing Procedure

以下の手順でEVPN LAGでPort-Activeロードバランシングモードをサポートする提案手順を説明します。

a. Ethernet-Segment Identifier (ESI)は[RFC7432]に記述されているように、アクセスインターフェースごとに割り当てられなければならず、自動生成でも手動割り当てでも構いません。
アクセスインタフェースは、レイヤ 2 またはレイヤ 3 インタフェースでよいです。
レイヤ3インタフェースにおけるESIの使用法は、本ドキュメントで新たに規定します。

b. Ethernet-Segment (ES)は特定のアクセスインタフェースにおいてport-active load-balancing modeで設定されなければなりません。

c. ピアリングPEはレイヤ3インタフェースにESIが設定されている場合、Ethernet Segment(ES) Route(RT-4)のみを交換することができます。

d. 冗長化グループの PE は、[RFC8584]で定義されたDF Electionを利用して、どの PE がポートをアクティブモードにし、どの PE がスタンバイモードにするかを決定します。[RFC8584]で定義されているDF Electionは[ES, Ethernet Tag]の粒度ごとですが、Port-Activeマルチホーミングでは、DF Electionを<ES>ごとに行います。本アルゴリズムの詳細についてはセクション4で説明します。

e. DFルーターは対応するアクセスインタフェースアップ状態のまま保持しそのEthernet Segmentにおいて転送がアクティブである状態を保持し続けねばなりません。

f. Non-DFルーターはデフォルトで全てのVLANsへ[RFC7432]Single-Active blocking schemeにより全てのトラフィックに対して双方向ブロッキングングする方式を実装します。

Non-DFルーターは接続されているピアリングアクセスインターフェースを運用停止状態にすることができます。

インターフェースが LACP プロトコルを実行している場合、Non-DF PEはインターフェース状態ダウンではなくLACP 状態をOOS (Out of Sync) に設定することができます。これによりスタンバイからアクティブへの移行時により良いコンバージェンスが可能となります。

g. EVPN-VPWSサービスでは、EVPNレイヤー2属性拡張コミュニティ[RFC8214]のプライマリ/バックアップビットの使用を強く推奨し、より良いコンバージェンスを達成します。

4. Designated Forwarder Algorithm to Elect per Port-active PE

Port-Active load-balancing modeで動作するES Routeは[RFC8584]で定義されたDF Election Extended Communityの新しいPort Mode Load-Balancing Capabilityで広報されます。
さらにポートに関連するESは既存のSingle-Activeの手順を活用し、Ethernet-AD per-ES routeと共に Single-Active(RED=01) Multihomed site redundancy mode をシグナリングします（[I-D.ietf-bess-rfc7432bis]の 7.5 節）。最終的に[RFC7432]のESI-label based split-horizon手順は、レイヤ2サーキットが関与している場合に、過渡的なエコーパケットを避けるために使用されるべきです。このソリューションにおけるアルゴリズムの選択は他のload-balancingモードにおける複雑性やパフォーマンスに影響を及ぼしませんが、セクション4.2から4.5にてDF Election関する様々なアルゴリズムについて徹底的に議論されています。

4.1. Capability Flag

[RFC8584]ではDF algorithmフィールドのDF Electionアルゴリズムで使用するcapabilityをエンコードするためにDF Election extended community、Bitmapフィールドについてについて定義しています。Bitmap(2octet)は以下のように拡張されます：

Figure 2: Amended Bitmap field in the DF Election Extended Community
Bit 0: D bitあるいは'Don't Preempt' bit,[I-D.ietf-bess-evpn-pref-df]で説明

Bit 1: AC-DF Capability (AC-Influenced DF election), [RFC8584]で説明

Bit 5: (DF Election Extended CommunityのBit29に相当し、このドキュメントで定義されます) 。Port Mode Load-Balancing Capability（以下、Pビットと呼ぶ）は、DF-AlgorithmがEthernet TagsではなくPort ESのみを考慮するように修正されるべきであると判断します。

4.2. Modulo-based Algorithm

ここではデフォルトのDF Electionアルゴリズム、または[RFC7432]にあり[RFC8584]で更新されたモジュラスベースのアルゴリズムがESの粒度でのみ使用されています。ES-Import Route TargetExtended CommunityはESI バイト1-6から直接自動派生させることができるため、多くのオペレータはESIを主にこれらのバイトで区別しています。その結果、バイト3-6はModulo-based DF assignment を用いてDesignated Forwarderを決定するため、ESI 間で Modulo 計算を行う際に良好なエントロピーを実現することができます。N個のPEノードからなる冗長グループを仮定すると、(Es mod N) = iのとき、序数iのPEが<EE>のDFになります。

4.3. HRW Algorithm

[RFC8584]で定義されたHighest Random Weight (HRW)アルゴリズムを使用してシグナリングすることができ、<ES, VLAN>単位ではなく<ES>単位で動作するように修正されています。

[RFC8584]のセクション3.2では、Ethernet TagとESIを連結して32ビットCRCを計算することが説明されています。 Port-Active load-balancingモードではEthernet Tagは単にCRC計算から除外されます。
DF(Es)はESI esのDF、BDF(Es)はBDFを表し、Si はPE iのIPアドレス、WeightはSi、Esの関数です。

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

Where:

DF(Es)はWeight(Es, Si)が最も大きいIPアドレスSi (index i)と定義される; 0 <= i < N-1です

BDF(Es)は計算されたWeightがDFのWeightの次に大きいアドレスSkを持つPEと定義されます。jは0からN-1までの実行インデックスで、iとkは選択された値です。

4.4. Preference-based DF Election

新しいcapabilityである'Port-Mode'がシグナリングされた時、アルゴリズムはポートのみを考慮し、関連付けられたEthernet Tagsを考慮しないように修正されます。さらに”port-based” capabilityは”Don’t Preempt”ビットと互換性がなければなりません。インタフェースが復旧した際、ピアリングPEはDビットがポートレベルで非復帰的な動作を可能とするようシグナリングします。

4.5. AC-Influenced DF Election

Port Mode Load-Balancing capability(P=1)を広報する際はAC-DF bitを0にセットしなければなりません。単一のAC（Sub-Interface）がダウンした場合、DF Electionに影響を与えません。全てのPort Mode DF Electionアルゴリズムにおいてはピア側のEthernet A-D per EVIが無視されます。リモートPEからAC-DF bitがセットされた（A=1）の経路を受信した場合、Port-Mode DF Electionを実行するばあいに無視しなければなりません。

5. Convergence considerations

Port-Active Load-Blancingモードを使用する場合、障害発生時及び復旧時のコンバージェンスを向上させるため、ピアリングPE間の高速な同期が必要となるでしょう。Port-Activeではstandbyポートがダウン状態であるため難易度が高いです。そしてstandbyポートをアップ状態にしてネットワークを安定化させるには少し時間がかかります。IRBとL3サービスではARP/NDキャッシュを同期させることが出来ます。また関連するVRFテーブルも同期されることがあります。L2サービスではMACテーブルの同期が考慮されているでしょう。最後に、LACPを使っているLAGメンバーはstandbyポート側でOOS(out-of-sync)状態、別名”warm-standby”機能を使用することが出来ます。

5.1. Primary / Backup per Ethernet-Segment

高速なコンバージェンスのためにEthernet A-D per ES routeの中にEVPN Layer 2 Attributes Control Flags Extended Communityを付加して広報を行うべきです（SHOULD）。PビットとBビットのみがこのドキュメントに関連し、Ethernet A-D per ES routesのコンテキストのみに関連します：

広報される場合、EVPN Layer 2 Attributes Control Flags extended communityはPビットまたはBビットのみを設定し、他の全てのビットとフィールドはゼロとしなければなりません。
リモートPEはEthernet A-D per ES routesでOptionalな EVPN Layer 2 Attributes Control Flags extended community を受信した場合、PビットとBビットのみを考慮しなければなりません。

EVPN Layer 2 Attributes Control Flags extended communityが Ethernet A-D per EVI routesで送受信されることは[RFC8214], [I-D.ietf-bess-rfc7432bis] と [I-D.ietf-bess-evpn-vpws-fxc]を参照して下さい:

受信したP、Bビットは上記Ethernet A-D per ES routeの"parent“ビットで上書きされます。
Extended Communityの他のフィールドやビットはこれらの文章の手順に従って使用されます

5.2. Backward Compatibility

[RFC7432]または[RFC8214]にのみ準拠する実装（すなわち、このドキュメントより前の実装）は、Ethernet A-D per ES routesのEVPN Layer 2 Attributes Control Flags Extended Communityを広報しないでしょう。つまりES内の全てのリモートPEはESごとにPとBビットを受信せず、Ethernet A-D per EVI route(s)で受信したPとBビットを受信し、尊重し続けることになるでしょう。同様に、[RFC7432]または[RFC8214]にのみ準拠し、EVPN Layer 2 Attributes Control Flags extended communityを受信した実装は、それを無視し、デフォルトパス解決アルゴリズムを使用し続けることになります。

6.Applicability

PEsでL2もしくはL3サービスを供給する一般的なデプロイメントではマルチホーミングを提供します。サービスは、EVPN VPWSやEVPN[RFC7432]などのL2 EVPNである可能性があります。L3サービスはVPNコンテキスト[RFC4364]またはグローバルルーチングコンテキストである可能性があります。PEがファーストホップルーティングを提供する場合、PEにEVPN IRBを展開することも可能です。このドキュメントで定義されたメカニズムは、インターフェースごとのSingle-Activeなロードバランシングが望まれるとき、L2および/またはL3サービスを提供するPE間で使用されます。
代替ソリューションとしては、ICCP[RFC7275]のactive-standby冗長性を持つMC-LAGが考えられます。しかし、ICCP は LDP を ICCP メッセージのトランスポートとして有効にする必要があります。しかし、VXLAN や SRv6 など、LDP が不要なケースも多くあります。このドラフトで定義されたEVPNによるソリューションは、LDPやICCPの使用を強制するものではなく、アンダーレイカプセル化にも依存しないものです。

7. Overall Advantages

Port-Activeマルチホーミングを使用することによってEVPNネットワークに次のメリットをもたらします：

a. オープンな標準仕様に基づき、インターフェース単位でのSingle-ActiveロードバランスメカニズムによってICCPとLDPを排除できるでしょう（ネットワーク内でVxLANもしくはSRv6を実行するかもしれません）

b. アンダーレイ技術（MPLS、VxLAN、SRv6）や関連サービス（L2、L3、Bridging、E-LINE、etc）に依存しません

c. MC-LAGのAttachment Circuites(AC)上でQoSを有効化出来るようになります

d. [RFC7432]へ完全に準拠し、既存のEVPN RFCへのいかなる機能拡張も必要としません

e. モジュロ、HRWなど様々なDF Electionアルゴリズムを利用することが出来ます

f. ICCPベースのレガシーなMC-LAGを代替し、次のような追加メリットをもたらします

ICCPは冗長PE間でフルメッシュLDP接続が必要ですが、1+N冗長モード（BGP RRを利用したEVPN）を効率的にサポートします。
EVPNではMass-WithdrawnによるFast Convergenceが可能ですが、ICCPには同等機能がありません

8. IANA Considerations

このドキュメントは下記値の割り当てを要求します

Bit 5 in the [RFC8584] DF Election Capabilities registry, with
name "P" for Port Mode Load-Balancing.