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

Segment Routingとその周辺技術の標準化の進行に伴い、マルチベンダでSR-MPLS VPN網を実装できるようになった。
単一のSRドメインを用いると設計や運用においてスケールしにくい場合でも、マルチASに分割し複数のSRドメインを相互接続することで、より柔軟なVPN網を設計できる。
我々はマルチASかつマルチベンダで構成されたSR-MPLS網でVPNトラヒックのTEをいかにして実現するのかを検証している。
本発表ではその検証内容を共有しSR-TEの実装状況を理解するとともに、どのようなユースケースと実装が考えられるかの議論を行いたい。

Transcript

1. Ⓒ NTT Communications Corporation All Rights Reserved.
   マルチ AS かつマルチベンダに
   おける SR-MPLS TE の実現
   NTTコミュニケーションズ / イノベーションセンター
   田島 照久
   2021/11/01 MPLS JAPAN 2021 (オンライン開催)
   teruhisa.tajima@ntt.com
   

   View Slide

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

   View Slide

3. Ⓒ 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
   

   View Slide

4. Ⓒ NTT Communications Corporation All Rights Reserved.
   より広範囲に適用可能なSR-MPLS網へ
   4
   1. Underlayの拡張性担保
   ⚫ 網全体で共有するのではなく、underlayトポロジ情報の隠蔽が必要
   2. ユースケースを満たせるTEの実装
   ⚫ 単にE2Eの到達可能性だけでなく、SLAに応じたoverlayの提供が必要
   1. 2.
   

   View Slide

5. Ⓒ 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による設定が不可に
   

   View Slide

6. Ⓒ 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で交換する
   

   View Slide

7. Ⓒ 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
   

   View Slide

8. Ⓒ 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として
   解釈できるかどうか
   

   View Slide

9. Ⓒ 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で付け
   替えてもよい
   

   View Slide

10. Ⓒ 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
    

    View Slide

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

    View Slide

12. Ⓒ 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
    

    View Slide

13. Ⓒ 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に最短
    遅延パスを割当
    

    View Slide

14. Ⓒ NTT Communications Corporation All Rights Reserved.
    SRドメイン内でのTEの実装パターン
    14
    2-a. Head-end(PE/ASBR)でTail-end(ASBR/PE)までのSIDを積む
    2-b. 各ルータがFlex-Algoによる転送を行う
    

    View Slide

15. Ⓒ 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
    

    View Slide

16. Ⓒ 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
    

    View Slide

17. Ⓒ 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
    

    View Slide

18. Ⓒ 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
    

    View Slide

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

    View Slide

20. Ⓒ 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
    

    View Slide

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

    View Slide