draft-ietf-bess-evpn-fast-df-recovery-05翻訳

11276 ワード

テキストリンク

注意

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

Abstract

Ethernet Virtual Private Network (EVPN)ソリューションはマルチホームEthernet Segmentsに対してDesignated Forwarder electionを提供します。これらの手順は障害時に不要なDFの状態変化を避けるため、Designated Forwarded electionにHighest Random Weight (HRW)アルゴリズムを適用することでさらに強化されました。このDraftはマルチホームEthernet Segmentsに関連するリンクもしくはノードの障害復旧時に高速なDesignated Forwarder (DF) electionを提供することでこれらの手順を向上させます。このソリューションは、そのEthernet Segmentに関連するEVIの数に依存せず復旧したPEとマルチホーミンググループ内の他の各PEとの間のシンプルなシグナリングによって実行されます。

Requirements Language

略

Status of This Memo

略

Copyright Notice

略

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Challenges with Existing Solution . . . . . . . . . . . . . .   3
   3.  DF Election Synchronization Solution  . . . . . . . . . . . .   4
     3.1.  Advantages  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  BGP Encoding  . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Synchronization Scenarios . . . . . . . . . . . . . . . .   7
     3.4.  Backwards Compatibility . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

Ethernet Virtual Private Network (EVPN)ソリューションの[RFC7432]は、Network Virtualization Overlay (NVO)やDC Interconnect(DCI)サービスなどのデータセンター(DC)アプリケーションや次世代virtual private LAN services.などのサービスプロバイダ (SP) アプリケーションで広く普及してきています。

1.1. Terminology

Provider Edge (PE): A device that sits in the boundary of Provider and Customer networks and performs encap/decap of data from L2 to L3 and vice-versa.

Designated Forwarder (DF): A PE that is currently forwarding (encapsulating/decapsulating) traffic for a given VLAN in and out of a site.

2. Challenges with Existing Solution

EVPN技術では、複数のPEデバイスが同じVLANに属するデータをencap/decapする機能を持ちます。特定の状況では、2つ以上のPEデバイス間で転送の役割が一瞬重なった場合にL2の重複やループが発生することがあり、ブロードキャストストームが発生します。

EVPN [RFC7432]は現在、冗長グループ内のPE間でタイマーベースの同期を使用していますが、複数DFsのタイマーが短すぎる場合は重複（さらにはループ）し、タイマーが長すぎる場合はブラックホール化する可能性があります。

[RFC7432]セクション8.3のSplit-horizon filteringを使えばループを防ぐことが出来（重複は防げない）ますが、同じVLANで同時に2つのサイトのDFが重複した場合、パケットの再エントリー時にサイト識別子が異なることからsplit-horizon checkに失敗しL2ループが発生します。

[RFC8584]でアップデートされたDF手順として知られるHRW (Highest Random Weight)アルゴリズムを使用すると障害時/復旧時に冗長グループ内のPEデバイス間でVLANによるDFの再シャッフルを防げます。これにより障害/復旧ポートに割り当てられていないVLANへの影響を削減し、障害/復旧時のループや重複を排除します。

しかし、DFへのPE挿入時やポートがアップした時（もしくは復旧した際）は古いDFがアクティブなまま新しく挿入されたデバイスやポートにDFの役割を移さなければならないため、HRWも役に立ちません。

                                     +---------+
                  +-------------+    |         |
                  |             |    |         |
                / |    PE1      |----|         |   +-------------+
               /  |             |    |  MPLS/  |   |             |---CE3
              /   +-------------+    |  VxLAN/ |   |     PE3     |
         CE1 -                       |  Cloud  |   |             |
              \   +-------------+    |         |---|             |
               \  |             |    |         |   +-------------+
                \ |     PE2     |----|         |
                  |             |    |         |
                  +-------------+    |         |
                                     +---------+

Figure 1: CE1 multihomed to PE1 and PE2.

図1ではPE2が挿入されるかブートアップした時にPE1はいくつかのVLANのDFロールをPE2へ移すことによってロードバランスを実現します。しかしPE1とPE2の間にはハンドシェイク・メカニズムが無いため、あるVLANにおけるDFロールの重複が可能となります。DFロールの重複は最終的にトラフィックのL2ループのようなトラフィックの重複を引き起こす可能性があります。

現在のEVPN仕様である[RFC7432]と[RFC8584]では新しく挿入されたデバイスへDFロールを転送するためにタイマーベースのアプローチをとっています。これには次のような問題を引き起こします。

タイマーが短すぎる場合、ループ/重複する
タイマーが長すぎる場合、トラフィックがブラックホールする時間が長くなる

3. DF Election Synchronization Solution

このソリューションは共通のEthernet Segmentへ参加するパートナーPEs間の共通クロックの協調性に依存します。主なアイデアは、そのEthernet SegmentのすべてのピアリングPEがDF Electionを実行し、周知された時刻にcarving stateを同時適用することです。

[RFC7432]で記述され、[RFC8584]でオプションとしてシグナリングされるDF Election手順が適用されます。あるEthernet Segmentに接続された全てのPEsらは時刻同期を行うためのネットワーキング・プロトコル（e.g. NTP, PTP, etc）を使用して時刻同期されます。新しく挿入されたPEもしくは障害復旧したPEはピアリングパートナーに現在時刻にピアリングタイマーの残り時間を加えて伝達します。これはローカルPEの”終了時刻”もしくは”絶対時刻”を制定します。この絶対時刻のことを”Service Carving Time”（SCT）と呼びます。

他のパートナーらとService Carving Timeを交換するために新しいBGP Extended CommunityがEthernet Segment route(RT-4)と共に広報されます。

新しいBGP Extended Communityを受信するとパートナーPEsはそのcarving timeを正確に知ることが出来ます。Skewという概念を導入することで潜在的なトラフィック重複やループを排除します。そのためService Carving TimeにSkew(デフォルト=-10ms)を追加します。先に挿入されたPE(s)は初めにcarveすべきであり、その後間も無く新しく挿入されたPEがSkewします。

まとめると、全てのピアリングPEsは新しく追加/回復したPEが広報した時刻にほぼ同時にCarveします。新しく挿入されたPEはSCTを初期化し、ピアリングタイマーが終了すると直ちにカーブします。前に挿入されたPE(s)らはSCT BGP Extended Communityと共にEthernet Segment route(RT-4)を受信し、Service Carving Timeよりも少し前にカーブします。

3.1. Advantages

このアプローチを使うことには複数のアドバンテージがあり、これらは非網羅的なリストです。

必要なのはシンプルな片方向のシグナリングだけ
下位互換性があること：古い[RFC7432]のみをサポートするPEらに認識されない”Service Carving Timestamp” BGP Extended Communityは単に破棄されます
複数のDF Electionアルゴリズムがサポートされます：
- [RFC7432] default ordered list ordinal algorithm (Modulo),
- [RFC8584] highest-random weight, etc.
Ethernet Segment route(RT-4)のBGP転送遅延に依存しません
使用する時刻同期メカニズムに依存しません(e.g. NTP, PTP, etc.)

3.2. BGP Encoding

各Ethernet SegmentのService Carving Timestampを交換するために新しいBGP Extended communityを定義する必要があります。

Typeフィールドが0x06でSub-Typeが0x0Fの新しいトランジティブなExtended communityであり、Ethernet Segment routeと共に広報されます。期待されるService Carving Timeは次のように8オクテット値としてエンコードされます。

                        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(0x0F)|      Timestamp Seconds        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~  Timestamp Seconds            | Timestamp Fractional Seconds  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

交換されるタイムスタンプは1900年1月1日のNTPエポック[RFC5905]を使用します。NTPプロトコルの64ビットタイムスタンプは32ビットの秒部(Timestamp Seconds)と32ビットの分数秒部(Timestamp Fractional Seconds)で構成されます。

Timestamp Seconds: 32ビットのNTP秒数がこのフィールドにエンコードされます
Timestamp Fractional Seconds: 16 ビットの NTP 分数秒がこのフィールドにエンコードされます。 16ビットの端数秒を使用することで15マイクロ秒（2^-16秒）の十分な精度を得ることができます。

このドキュメントでは[RFC8584]で定義されたDF Election Extended Communityのビットマップフィールドに「T」（Time Synchronization）という新しいフラグを導入します。

                        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 | |A| |T|       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~     Bitmap    |            Reserved = 0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bit 3: Time Synchronization (DF Election Extended Communityの27bitに該当)。1に設定された場合、Ethernet Segment内の他PEとTime Synchronization capabilityを使用することを示します。

このcapabilityは合意されたDF Type(DF Election Type)と共に使用されます。例えばEthernet Segment内の全PEがTime Synchronization capabilityを持ちDF typeをHRWにしたいと示すなら、HRWがこのcapabilityと共に使用されます。

3.3. Synchronization Scenarios

Figure 1を例にとると、当初PE2が故障しPE1が引き継いだ場合です。この例は[RFC7432]の DF-Election メカニズムの問題点を示しています。

[RFC7432]のセクション8.5に基づき、デフォルトである3秒のピアリングタイマーを使用すると：

初期状態：PE1が通常状態、PE2が回復中
PE2が(絶対)時間 t=99で回復する
PE2がパートナーPE1へRT-4(t=100で送信)を広報する
PE2は3秒のピアリングタイマーを開始する
PE1はRT-4を受信するとただちにcarveする　i.e. t=100+BGP伝播遅延の最小値
PE2は時刻t=103にcarveする
[RFC7432]ではトラフィック重複よりもトラフィックブラックホールを優先して目的としています。上記の手順では、PE1が受信時にいくつかのVLANをNon-Designated-Forwarder (NDF)へ遷移させているため、各PEの回復シーケンスの一部としてトラフィックブラックホールが発生します。ピアリングタイマー値（デフォルト=3秒）はブラックホールの継続時間に直接影響します。ただしピアリングタイマーを短くすると（特にゼロ）、トラフィックの重複やトラフィックループが発生する場合があります。

Service Carving Time (SCT) のアプローチでは：

初期状態：PE1が通常状態、PE2が回復中
PE２が(絶対)時間 t=99で回復する
PE2がパートナーPE1へRT-4(t=100で送信)をtarget SCT値 t=103と共に広報する
PE2は3秒のピアリングタイマーを開始する
PE1とPE2は(絶対)時刻t=103でcarveする

実際には、PE1がPE2よりわずかに先にcarveするべきです（skew）。先に挿入され回復中のPE2は、ピアリングタイマー満了時にVLANごとにDF→NDF、NDF→DFの両方の遷移を実行します。目的は重複を防ぐことであり、SCTを受信した元のPE1に適用されるでしょう：

t=SCT - skewの時にDFからNDFへ遷移し、両PEが「skew」の時間だけNDFとなる
t=SCTの時にNDFからDFへ遷移する

このsplit-behaviourがDF roleをロスすることなく遷移させます。

SCTアプローチによりピアリングタイマーの悪影響が緩和されます。もっと言うとBGP Ethernet Segment route (RT-4)の伝送遅延(PE2からPE1への)も問題にならなくなります。SCTアプローチはピアリングタイマーに関連する問題を救済し、3秒タイマーのウィンドウがミリ秒単位に短縮されます。

3.4. Backwards Compatibility

冗長グループごとにDF Election手順がグローバルに収束し全会一致するためには、全ての参加PEが使用するDF Electionアルゴリズムに同意する必要があります。しかし、一部のPEが既存のモジュロベースのDF Electionを使用し続け、新しいSCT BGP Extended Communityに依存しない可能性があります。基本のDF Electionメカニズムを実行しているPEsは単に新しいSCT BGP Extended Communityを未認識として破棄します。

PEはEthernet Segment Route(RT-4)と共に新しいService Carving Time BGP Extended Communityを含めることによって新しい'T' DF Election Capabilityをシグナリングし、clock-synchedなcarvingをサポートする意思を示すことが出来ます。Ethernet Segmentに接続された1つ以上のPEがT=1をシグナリングしないとき、Ethernet Segment内の全てのPEsらは[RFC7432]のタイマーアプローチへ戻らなければなりません。これは2台以上のPEがある場合のVLANがシャッフルされるコンテキストにおいて特に重要です。

4. Security Considerations

このドキュメントのメカニズムは[RFC7432]として定義されるEVPNコントロールプレーンを使用しています。[RFC7432]で記述されたセキュリティ考察は同じく適用されます。このドキュメントはデータプレーントランスポートのためMPLSとIPベースのトンネル技術を使用します。[RFC7432]と[RFC8365]で記述されたセキュリティ考察も同じように適用されます。

5. IANA Considerations

このドキュメントは[RFC7153]で登録された”EVPN Extended Community Sub-Types”レジストリに対して次のSub-typeの割り当てを求めます。

         0x0F     Service Carving Timestamp    This document

このドキュメントでは[RFC8584]で登録された”DF Election Capability”レジストリに対して次の値の割り当てを求めます。

         Bit         Name                             Reference
         ----        ----------------                 -------------
         3           Time Synchronization             This document

Author And Source

この問題について(draft-ietf-bess-evpn-fast-df-recovery-05翻訳), 我々は、より多くの情報をここで見つけました https://zenn.dev/yuheiotsuka/articles/6ae5a1f55dfcac

著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。

Collection and Share based on the CC protocol

AWS Lambdaコンテナでpuppeteerを動かす

Supabase で Join Array