いろいろ備忘録

雑記です。

EVPNメモ(RFC 7209)

1章 モチベーション

L2仮想化の一つであるVPLSは広く使われているものの、冗長性、マルチキャストの扱い、プロビジョニングの複雑さがイケてない。

それに、E-Tree(疑似的なハブ&スポーク構成)や、VPWS(疑似的な専用線)という新しいニーズも増えた。

 

マルチホーミングについては、VPLSはAct-Sby構成しかサポートしていない。

マルチキャスト最適化については、マルチキャストLSPをVPLSと組み合わせて使う方法はあるが、VPLSが一対他しかサポートしていない。(多対多をサポートしていない)

 プロビジョニングについては、BGPをベースにしたauto-discoveryを使って、single-side provisioning(よくわからん、後でググる)ことができる。ただ、この場合も、コアネットワークの設定はちょっと必要。

データセンター間の接続については、VLANを上手く扱えるインターフェース(VLAN-aware bundling)が欲しくなってきた。

仮想サーバの隆盛で、扱うMACアドレスの量も増えてきた。PEで学習するMACアドレスがいくら多くても、障害発生後の切り替わりに影響を及ぼさないようにしたい。

VPLSやH-VPLSじゃ出来ないような複雑なトポロジーも作りたい。

 

2章、3章は割愛

 

4章 冗長性の要件

 

4.1 フローベースのロードバランシング

CE-PE間のマルチホーミングで一般的なMC-LAGだけど、ICCPもそんな感じの技術。

LAGのアルゴリズムは柔軟で、唯一の要件はトラフィックフローにおけるフレームの順番を保証すること。

LAGの普通の実装では、ヘッダの情報をもとにフローを識別するけど、RFCじゃ標準が決まってないから、実装次第で動作が変わっちゃう。まあ実際非対称になってても動作には問題ないんだけど。

ここが良くないから、L2~L4のヘッダを基にフローを識別するアルゴリズムRFCで決めなきゃならんね。

 

要件 1a:CEが行う柔軟なフローベースのロードバランシングに対応すること。

 

要件 1b:CEが複数のPEに接続されていても、CE宛のトラフィックフローベースでロードバランシングすること。CEが何本PEに接続されていようと、そのすべてのリンクを使うこと。

 

マルチホーミングの場合、マルチホーミングしている2つ以上のPE~どっかのPE間にECMPパスがあることもある。そのマルチホーミングがAct-Actなら、どっちのPEに送っても良いようにしたい。その時は、それもフローベースでロードバランシングしよう。

 

要件 1c:複数のASにまたがる冗長のPEに対し、フローベースでロードバランシングできること。

 

4.2 フローベースのマルチパス

 4.1で説明した機能について、PEの間でも複数の通信経路を使えること。

例えば、あるPEとAct-ActのPEの間に通信経路が2つ以上あるなら、Act-Actが宛先のトラフィックは、ロードバランシングできること。

 また、そのパスのコストが同じ(ECMPパスである)なら、そのすべてを使えること。

後者なら、 RFC6790で規定されているエントロピーラベル(後でググる)を使ってもいい。

 

 要件 2a:あるPE~Act-Actのマルチホーミングが有効な冗長グループに属する全PE間の、全てのLSPを、全てActiveとしてロードバランシングに使用できること。

 

 要件 2b:あるPE~Act-Actのマルチホーミングが有効な冗長グループに属する任意のPE間にあるECMPをすべて使用すること

 

たとえば、CE1=PE1,2(Act-Sby), CE2=PE3,4(Act-Act)の構成で、PE1,2~PE3,4に3つのECMPパスがあるとき。

FROM:CE1 TO:CE2のトラフィックはMPLS/IPコア上で以下の12通りにロードバランシングできる。

①CE1→PE1,2の2通り(Act-Sbyでも、要件1aにより受信は可能)

②PE1,2→PE3,4の3通り(上記ECMPパスの数)

③PE3,4→CE2の2通り

=>2x3x2=12通り。

 

4.3. 地理的に冗長なPE

マルチホーミングするPEを地理的に冗長しようとすると、マルチホーミングのグループ内のPE間のリンクを用意するのはコストがかかるので、そのリンクが無くても良いようにしたい。

また、IGPのコストの計算に遅延などが含まれる場合は、あるPEから上記の地理的に冗長なPEまでのコストが冗長グループ内で異なる可能性がある。

要件3a:マルチホーミンググループ内の制御用リンクが無くても、All-Activeなマルチホーミングができること。

 

要件3b:任意のPEからマルチホーミンググループの各PEへのIGPコストが異なるケースをサポートすること。

 

要件3c:同一ASで異なるIGPドメイン間のマルチホーミングをサポートすること。

 

要件3d:複数のASにまたがるマルチホーミングをサポートすること。

 

4.4 トラフィック転送の最適化

マルチホーミングのPEの先には、もちろんCEが1つじゃなくて2つのパターンもある。(CE1,2=PE1,2)
All-Actの場合、下記のすべてのケースで最適な転送をサポートすること。
( ”最適な転送”とは、宛先CEがマルチホーミンググループのPEに接続されていない限り
マルチホーミンググループのPE間でトラフィックが転送されないこと )

具体的なケース
A: シングルホームのCEから、マルチホーミングのCE
B: マルチホームのCEから、シングルホームのCE
C: マルチホームのCEから、マルチホームのCE(上述の通り、受信側は除く)

特に、マルチホームグループで地理的な冗長をとっているとき、距離分の遅延が発生するので、良くない。

 

4.5 柔軟な冗長のサポート

マルチホーミングカニズムはPEを複数の冗長グループに任意にグループ化できるようにすべき。
各冗長グループは、PEの同じグループを共有するすべてのマルチホーミングされたデバイスやネットワークを代表する。

 

例えば、PE1,2,3があるとき、①PE1,2 ②PE2,3 ③PE1,3の3つの冗長グループを作れる。

この冗長グループのいずれかに、CEをマルチホーミングできる。

 

4.6マルチホームネットワーク

マルチホーミングしているネットワークにおいて、MSTPやリングプロトコル(G.8032)が有効な時。PEはそれらに参加する必要はないが、VLANごとに、マルチホーミングしているリンクのうち1つのみアクティブ経路である必要がある。

 

要件6a:すべてのVLANが一つの