マルチASかつマルチベンダにおけるSR-MPLS TEの実現

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Ⓒ NTT Communications Corporation All Rights Reserved. 発表要旨 2 ◼ 複数のAS、複数のSRドメインをまたがるVPNの実装について ◼ E2EでSR-TEを行う際の実装について ◼ SR-MPLS/SRv6相互接続SFCの実装について本発表内容は弊社の検証環境で行った検証結果に基づくものです。いかなるサービスの実装に言及するものではなく、さらに各ルータの性能や正確性を保証するものではありません。 AS 65001 AS 65003 AS 65002

Slide 3

Slide 3 text

Ⓒ NTT Communications Corporation All Rights Reserved. SR(-MPLS)の活用状況・発展 3 ◼ SR-MPLSを用いたL2/L3VPN網はすでに実用段階 ⚫ シングルSRドメイン、シングルベンダでは問題なく動作 ⚫ 参考： MPLS JAPAN 2019 “SR-MPLSの導入事例と今後の展望について” ◼ 適用範囲や網の機能を増やす際の実装を検討したい ⚫ 適用範囲＝underlayの広さ、多様さ ⚫ 網の機能＝Traffic Engineering、Fast Re-Route

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Ⓒ NTT Communications Corporation All Rights Reserved. 1. Underlayの拡張性担保 5 ◼ シングルSRドメインの拡大とともに制約が増加 ⚫ レベル/エリアはあるがIP重複などはできない ⚫ 設定の影響範囲を絞れるほうが嬉しい → UnderlayのマルチAS化とマルチSRドメイン化 ◼ ASを区切り、AS内の実装を隠蔽 ⚫ ルータIDやP2P IPの重複が可能 ◼ Route Distinguisherへの影響は要考慮 ⚫ IGP, iBGPの設定影響がAS内に閉じる ◼ AS境界でSRドメインを区切る ⚫ SR関連の設定もAS内に閉じる ⚫ ただし、分断されることによりE2EでのSRによる設定が不可に

Slide 6

Slide 6 text

Ⓒ NTT Communications Corporation All Rights Reserved. Multi-ASの技術選定 6 ◼ Inter-AS MPLS option-Bが要望を満たす ⚫ A > VRFの制限や設定の煩雑さの問題あり ⚫ B > 技術的にデメリットがないが、対応状況が微妙  これを選択 ⚫ C > underlayが見えるので今回の目的には不適 ⚫ D > Aの問題点が半分しか解消されない AS 65001 AS 65002 A: BGPも転送もASBRがVRFごとに行う B: ASBRがまとめてAS間で再配布する C: 双方のASの情報をRRで交換する

Slide 7

Slide 7 text

Ⓒ NTT Communications Corporation All Rights Reserved. Option-BによるL3VPN (VPNv4/6) 7 ◼ ASBRはAS内とAS間のVPNラベルを相互にswapしてVPNを接続 ◼ 3AS以上でも正しく動作 AS 65001 AS 65003 AS 65002 packet VPN (1) packet ASBR SID VPN (2) packet VPN (3) packet PE SID packet

Slide 8

Slide 8 text

Ⓒ NTT Communications Corporation All Rights Reserved. Option-BによるL2VPN (EVPN) 8 ◼ 機能実装中の段階 ⚫ 全メーカがOption-Bが実装できるとは限らない ⚫ Type-2経路に限られるなど制約もある AS 65001 AS 65002 packet VPN (1) packet ASBR SID VPN (2) packet VPN (3) packet PE SID packet EVPN経路情報に含まれる VPNラベルをoption-Bとして解釈できるかどうか

Slide 9

Slide 9 text

Ⓒ NTT Communications Corporation All Rights Reserved. Multi-ASの工夫が必要な点 9 ◼ Route Target ⚫ ingress-PEではASを超えた先のegress-PEの経路情報をインストールしないといけない ⚫ ASの実装を隠蔽するためには、相互流通用ルールを作って対応 AS 65001 AS 65002 RT = (共通ASN):(識別番号) 例) 64999:1000 RT = (共通ASN):(識別番号) をインストール ASBRで付け替えてもよい

Slide 10

Slide 10 text

Ⓒ NTT Communications Corporation All Rights Reserved. 1. Underlayの拡張性担保のまとめ 10 ◼ AS=SRドメインを分割し、Option-BでのVPN実装 ◼ Underlayの設計自由度が確保 ⚫ P2P IPの採番が自由 ⚫ IGPコストの設計が自由 ◼ AS間の接続の自由度も確保 ⚫ AS間のつながりはSRに依存しないため、トランジットASの存在も可能 AS 65003 AS 65001 AS 65002 AS 65004

Slide 11

Slide 11 text

Ⓒ NTT Communications Corporation All Rights Reserved. 2. ユースケースを満たせるTEの実装 11 ◼ ユースケース ⚫ このスライスは {特定の経路} で送りたい ⚫ このスライスは {低遅延|広帯域} で送りたい ⚫ このスライスは冗長系のうち {1系をメインに|2系をメインに} 使いたい ⚫ このフローは {低遅延|広帯域} で送りたい ◼ 実装方針 ⚫ 各SRドメイン内でTEを実装 ⚫ SRドメイン間ではあらかじめTEメニューを設定しておく

Slide 12

Slide 12 text

Ⓒ NTT Communications Corporation All Rights Reserved. あらかじめTEメニューを設定とは 12 ◼ マルチSRドメインで真のend-to-end TEは難しい ⚫ 達成するにはunderlayすべての情報が必要だが、意図的に隠蔽している ◼ なお複数PCE連携等の検証は未着手 ⚫ TEの実装は各SRドメインに閉じて、部分最適をつなぎ合わせることとした AS 65001 AS 65002 TE区間 1 TE区間 2

Slide 13

Slide 13 text

Ⓒ NTT Communications Corporation All Rights Reserved. ColorによるTEメニューの設定 13 ◼ AS間はTEメニューに対応する相互流通用のColor表を作成 ◼ Colorの値の意味はTE区間=SRドメインに隠蔽 AS 65001 AS 65002 例) 最短遅延パスはAS65002では color=200 AS65001では color=300なので付け替え相互流通ルールでは color=1000なので付け替え color=300に最短遅延パスを割当

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Ⓒ NTT Communications Corporation All Rights Reserved. 2-a. Head-endでSIDを積むパターン 15 ◼ VPNのingress PE = Head-endで転送経路を計算しSIDで表現 ⚫ PEの機能のみによって実現される ⚫ Pros: 中継がマルチベンダでも関係ない ⚫ Cons: TE経路の増減に合わせて各Head-endでの詳細な設定が必要 ◼ 指定できる経路の種別 ⚫ Explicit-path > OK ⚫ TE metric > OK ⚫ Latency-based metric > OK AS 65001

Slide 16

Slide 16 text

Ⓒ NTT Communications Corporation All Rights Reserved. 2-b. Flex-Algoで転送するパターン 16 ◼ 詳細な経路をSIDの組で指定するのではなく、Algoに従い転送 ⚫ Pros: Algoの指定だけで設定が統一される ⚫ Cons: Algo面が全ルータで正しく認識されている必要がある ◼ 一部ルータのIS-IS TLV実装の差異で認識されない組み合わせがあった ◼ 指定できる経路の種類 ⚫ 特定のAlgo面を通るpath > OK ⚫ TE metric > OK ⚫ Latency-based metric > OK AS 65001

Slide 17

Slide 17 text

Ⓒ NTT Communications Corporation All Rights Reserved. Inter-AS部分のTE設計の難しさ 17 ◼ Head-endから見た時のASBRの選択方法が難しい ⚫ PE1はASBR1/2どちらに送るか、先が見えないのでマクロな判断は不可 ⚫ ASBR1/2もinter-ASの状況をPE1にSR的には伝えられない ◼ EPEはVPNラベルと同時選択できない ◼ BGP attribute (LP/MED) での制御はできる ◼ SR-TEのメトリクスによるASBR選択も一部はできる AS 65001 AS 65002 PE1 ASBR1 ASBR2 packet

Slide 18

Slide 18 text

Ⓒ NTT Communications Corporation All Rights Reserved. 2. ユースケースを満たせるTEの実装まとめ 18 ◼ AS=SRドメインを分割したことにより必然的にTE同士をつなげる ◼ TEの実装がASで隠蔽されたが、E2Eの真の最適化ができない ◼ 特にInter-AS部分の選択はSRだけでは難しいこともある AS 65001 AS 65002 TE区間 1 TE区間 2

Slide 19

Slide 19 text

Ⓒ NTT Communications Corporation All Rights Reserved. その他細かい点のつまづき 19 ◼ SRLBからのラベル割り当て値の差 ⚫ Localなので動作上問題はなく単なる見た目の問題 ◼ 遅延の測定結果がメーカによりオーダーが違うほどの差 ⚫ E2Eの遅延計算がリンク遅延の合計となると、正しく実情を反映できない ◼ FRRが意外に扱いづらいうえ、inter-AS部分の存在によりE2Eの保護が難しい ⚫ FRRが動かない組み合わせがあった ⚫ inter-AS部分の保護ができない課題

Slide 20

Slide 20 text

Ⓒ NTT Communications Corporation All Rights Reserved. ◼ SRv6はEnd.DT4/DT6での終端、SR-MPLSはVPNv4/6の終端を行う ◼ LinuxにおいてVRFを2つ使い実装 ⚫ 単にSRv6のVPN PEとの通信であれば1つで可能 ⚫ SFCでMPLSに戻すことを考えると2つ必要 SRv6 SR-MPLS/SRv6相互接続SFCの実装 20 SR-MPLS Function head H.Encaps End.AM End.DT4/DT6 Inter-AS MPLS Interwork ASBR

Slide 21

Slide 21 text

Ⓒ NTT Communications Corporation All Rights Reserved. まとめと今後の展望 21 ◼ 複数AS、複数SRドメインでOption-Bを用いてVPNを実装可能 ◼ プリセットメニューのTEは実装可能 ◼ SRv6 interwork SFCの実装は可能今後のさらなる課題 ⚫ PCE等外部ツールでのパスコントロールの可能性 Special Thanks: 本検証はArcadia検証チームメンバ (市原英也、岩田紘成、竹中幹、三島航、宮地瑠香)によって行われました