© NTT Communications Corporation All Rights Reserved. マルチAS/マルチドメインなSegment Routingの実現 2021/12/3 イノベーションセンター 三島 航

© NTT Communications Corporation All Rights Reserved. 2 ● マルチAS/マルチドメインなSegment Routing ○ 背景: NTT ComのSR活⽤事例と課題 ○ 新たな要求とユースケース ○ Multi-AS SRについて ■ E2E TEとスケーラビリティのバランス（集中と分散） ● SR-MPLS/SRv6相互接続 ○ Service Function Chainingの活⽤ ● Future Work ○ PCEの活⽤ ○ VPN/TEのセルフマネージ化 ○ より⾼度なTEの実現 ○ SRv6のさらなる活⽤ CE CE Interwork ASBR P PE/ASBR PE/ASBR P PE/ASBR SFC Proxy Network Function PE PE/ASBR PE P PE CE CE PE PE P PE/ASBR CE SR-MPLS SR-MPLS SR-MPLS SRv6 ⽬次

© NTT Communications Corporation All Rights Reserved. 3 マルチAS/マルチドメインなSegment Routing NTT ComのSR活⽤事例と課題

© NTT Communications Corporation All Rights Reserved. 4 Customer CE CE Customer Customer AS AS SR-MPLS domain Inter-AS MPLS 作りたいネットワーク Interwork ASBR P SRv6 domain PE/ASBR PE/ASBR P PE/ASBR SFC Proxy Network Function SR-MPLS domain PE PE/ASBR PE P PE CE CE SR-MPLS domain Customer Inter-AS MPLS PE PE P PE/ASBR AS AS Inter-AS MPLS CE Customer ● マルチAS/マルチドメインなSegment Routing ○ なぜ必要か、どう作るかを説明して⾏きます

© NTT Communications Corporation All Rights Reserved. 5 Customer CE CE Customer Customer AS AS ● まずはMulti-AS SR-MPLSから︕ SR-MPLS domain Inter-AS MPLS Multi-AS SR-MPLSについて Interwork ASBR P SRv6 domain PE/ASBR PE/ASBR P PE/ASBR SFC Proxy Network Function SR-MPLS domain PE PE/ASBR PE P PE CE CE SR-MPLS domain Customer PE PE P PE/ASBR AS AS Inter-AS MPLS CE Customer Inter-AS MPLS

© NTT Communications Corporation All Rights Reserved. 6 NTT ComとSegment Routing（2018〜） ● SR-MPLSを活⽤した全社的な商⽤インフラを構築・運⽤中 ○ Customerごとにスライスを提供 ○ SR網のみでのL2VPN / L3VPN提供 ■ 要件と当時の実装状況を考慮し、SR-MPLS + MP-BGP（VPNv4/v6、EVPN）を選定 ○ 過去の対外発表 ■ SR-MPLSの導⼊事例と今後の展望について（MPLS JAPAN 2019） ● https://mpls.jp/2019/presentations/MPLS-Japan2019_NTTcom.pdf ■ ユーザによるセルフマネージ可能なネットワークサービス運⽤システムの事例（ONIC 2019） ● https://onic.jp/_cms/wp-content/uploads/2019/11/onic2019_tajima.pdf ■ マルチベンダASかつマルチベンダにおけるSR-MPLS TEの実現（MPLS JAPAN 2021） ● https://mpls.jp/2021/presentations/20211101_MPLSJAPAN_NTTCOM_tajima_pub.pdf

© NTT Communications Corporation All Rights Reserved. 7 ● SR-MPLSをより⼤規模に構成したい︕ ○ 例として下記のようなユースケースを検討中 ○ 複数拠点に跨がるSR-MPLS網の⼤規模展開 ○ 複数の運⽤者の持つネットワークの相互接続 ■ （参考）Docomo・NTT Com・NTTコムウェアの組織統合 ● https://www.nttdocomo.co.jp/info/news_release/2021/10/25_00.html ○ 複数の機能を持つネットワーク同⼠の接続 ■ コア網・アクセス網・データセンタなど 実現したいこと（2021〜）

© NTT Communications Corporation All Rights Reserved. 8 Single-AS構成で⽣じる課題 1. Global Unique空間の共有 ○ ⽤途や管理者ごとにレベル/エリアの分割は可能だが、IP空間は共有する必要あり ○ SIDのindexも単⼀のSR domainでUniqueに管理、NW同⼠が密結合になる 2. ある設定や障害の影響範囲が全体に及ぶ ○ フラットな単⼀ネットワーク設計はスケーラビリティの⾜枷となる PE/ASBR1 16004 P1 16002 PE/ASBR3 16006 ⽤途 β のNW ⽤途 α のNW PE1 16001 PE/ASBR2 16005 P2 16003 PE/ASBR4 16007 SR domain P3 16008 P/SFF1 16009 PE2 16010 Single-AS 障害情報の伝搬 IP addr / SIDはSR domainでGlobal Uniqueに設計しなければならない

© NTT Communications Corporation All Rights Reserved. 9 ● マルチASにネットワークを設計、各ASでSRを利⽤し相互接続 ○ ASごとのリソース分離によるスケーラビリティ向上・新規ユースケースの創出︕ ■ 既存網同⼠の相互接続によるサービス連携、リソースの有効活⽤ ■ SR domainの範囲、LSDBの共有⽅法、TEの実現⽅法などで形態が実現可能 ■ SR-MPLS-SRv6 Interworkなど、新たな価値の提供 提案: Multi-AS Segment Routing SR domain PE/ASBR1 16004 P1 16002 PE/ASBR3 16001 AS β AS α PE1 16001 PE/ASBR2 16005 P2 16003 PE/ASBR4 16002 SR domain P3 16003 P/SFF1 16004 PE2 16005 UnderlayをASごとに隠蔽、IP addr / SIDはSR domainを⾃由に設計︕ 障害影響もAS内に閉じる Inter-AS MPLS

© NTT Communications Corporation All Rights Reserved. 10 Multi-AS SRのユースケースの例 ● 企業間/AS間連携、Inter-DCなL2/L3VPN ○ 複数の網を接続し、CustomerにL2/L3VPNを提供 ● 5G Core/Access/MECの接続 ○ 機能ごとのNW分離。SRのスライシングやFunctionはモバイルと好相性 ● Service Function Chainingの提供 ○ Public Cloud等の他ASと連携し、⼀連のサービスを提供 画像: https://pc.nanog.org/static/published/meetings/NANOG73/1659/20180626_Moyer_Segment_Routing_For_v1.pdf

© NTT Communications Corporation All Rights Reserved. 11 Inter-AS Option ● Multi-AS MPLS-VPNでは複数の接続オプションが提案済（RFC4364） ○ 実現⽅式により、Option A, B, Cの3種に分類 ■ Option AとBを組み合わせたOption D(AB)も提案 ○ それぞれのOptionにPros/Consが存在 PE/ASBR1 P1 PE/ASBR2 AS β AS α PE1 P2 PE2 以降のページで、下記のトポロジをそれぞれのInter-AS Optionで繋ぐ例を紹介 Customers Customers

© NTT Communications Corporation All Rights Reserved. 12 Inter-AS Option A ● AS間をCustomerごとのサブインターフェースで分割する⼿法 ○ 最もシンプルな⼿法 ■ リモートASとはCEと同様の構成で接続 ■ AS間は単純なIPパケットで転送 ○ スケーラビリティは低い ■ AS間にCustomerの数だけサブインターフェースと経路共有（eBGP/IGP/Static Route等）が必要 SR domain PE/ASBR1 16003 P1 16002 PE/ASBR2 16001 AS β AS α PE1 16001 SR domain P2 16002 PE2 16003 eBGP per-VRF iBGP POP iBGP 24001 Payload 16003 VPN label TE label PUSH POP Payload 24002 Payload VPN label 24001 Payload VPN label PUSH 24002 Payload 16003 VPN label TE label Subinterface per-VRF POP POP

© NTT Communications Corporation All Rights Reserved. 13 Inter-AS Option B ● ASBR間でVPN経路を広告、VPNラベルのSWAPでAS間を接続する⽅式 ○ ASBRはVRFに紐づくインターフェースを持たないため、経路のRIB Installが不要 ○ AS間は単⼀のインターフェースで接続可能 ○ ASBR間もMPLS-VPNで接続。AS内のVPNとSWAPし、⼀連のVPNを構築 ○ → ASを分離し、疎結合に接続することでスケーラビリティの確保が可能 SR domain PE/ASBR1 16003 P1 16002 PE/ASBR2 16001 AS β AS α PE1 16001 SR domain P2 16002 PE2 16003 eBGP iBGP POP Inter-AS MPLS domain iBGP Next-hop self 24001 Payload 16003 VPN label TE label PUSH SWAP 24002 Payload VPN label 24002 Payload VPN label 24001 Payload VPN label SWAP & PUSH 24002 Payload 16003 VPN label TE label POP POP

© NTT Communications Corporation All Rights Reserved. 14 Inter-AS Option C ● フラットなdomainを構築しE2Eの到達性を担保 ○ ASBR間でIGPとBGP-LS or BGP-LUでAS間の到達性を確保 ○ RR間でVPN情報を交換。Option A, Option Bと異なり、ASBRにはVRFが不要 ○ → ASを超えた柔軟な経路制御が可能だが、複数のASを密結合に設計する必要あり ■ Global Unique空間の共有（Node SIDなど） PE/ASBR1 16003 P1/RR 16002 PE/ASBR2 16004 AS β AS α PE1 16001 SR domain P2/RR 16005 PE2 16006 iBGP SWAP iBGP 24002 Payload 16006 VPN label TE label PUSH SWAP 24002 Payload VPN label 24002 Payload VPN label 24002 Payload VPN label SWAP 24002 Payload 16006 VPN label TE label POP POP 16006 16006 TE label TE label eBGP（LinkState） eBGP (VPN) IGP IGP IGP IGP IP addr / SIDはASを超えたSR domainでGlobal Uniqueに設計

© NTT Communications Corporation All Rights Reserved. 15 Inter-AS Option D（AB） ● Option Aの抱えるスケーラビリティの課題を⼀部改善する⼿法 ○ データ転送とeBGPセッション⽤のリンクを分割 ■ Option Aと同様に、AS間はCustomerごとのサブインターフェースで分割しデータを転送 ■ Option Bと同様に、Global VRFの単⼀BGPセッションで接続 ○ → BGPセッション数は削減。サブインターフェースによるスケーラビリティの制限は残る SR domain PE/ASBR1 16003 P1 16002 PE/ASBR2 16001 AS β AS α PE1 16001 SR domain P2 16002 PE2 16003 eBGP iBGP POP iBGP 24001 Payload 16003 VPN label TE label PUSH POP Payload 24002 Payload VPN label 24001 Payload VPN label PUSH 24002 Payload 16003 VPN label TE label POP POP Global VRF for eBGP / Subinterface per-VRF

© NTT Communications Corporation All Rights Reserved. 16 Inter-AS Optionの特徴と技術選定 ● スケーラビリティの向上、Underlayの隠蔽が⽬的 = Option Bを選定 ○ Option A: AS間に⼤量のサブインターフェースとBGPセッションが必要 ○ Option B: ASごとに分離しつつ、AS間は単⼀のBGPセッションで実現可能 ○ Option C: 柔軟な経路制御は可能だが、ASごとの情報分離が不可能 ○ Option D(AB): BGPセッションの課題は改善されているが、サブインターフェースは⼤量に必要 ● Option Cと異なり、Option BではE2Eでの真に最適なTEは難しい ○ LSDBがASごとに分離しているため、あるASのPEだけで最適経路を計算できない ○ → Intent-basedなTEポリシーの接続により解決︕（次章で解説）

© NTT Communications Corporation All Rights Reserved. 17 Inter-AS Option BによるL3VPN（VPNv4/VPNv6） ● ASBRはAS内とAS間のVPNラベルを相互にSWAPしてVPNを接続 ○ TEラベルはASごとにPUSH ○ 3AS以上でも正しく接続可能なことを検証済︕ ○ Route-Targetは慣例的にAS番号を埋め込むため⼯夫が必要 ■ AS間で書き換え or 相互接続⽤のRTを利⽤ SR domain PE/ASBR1 16003 P1 16002 PE/ASBR2 16001 AS β AS α PE1 16001 SR domain P2 16002 PE2 16003 eBGP iBGP POP Inter-AS MPLS domain iBGP Next-hop self 24001 Payload 16003 VPN label TE label PUSH SWAP 24002 Payload VPN label 24002 Payload VPN label 24001 Payload VPN label SWAP & PUSH 24002 Payload 16003 VPN label TE label POP POP Node SIDはAS内でUniqueであれば良い。横のASを気にせず設計可能

© NTT Communications Corporation All Rights Reserved. 18 Inter-AS Option BによるL2VPN（EVPN） ● 基本的な動作はL3VPNと同様 ● 各ベンダ機能実装中の段階 ○ Type-2経路（MAC Advertisement）に限られるなど制約あり SR domain PE/ASBR1 16003 P1 16002 PE/ASBR2 16001 AS β AS α PE1 16001 SR domain P2 16002 PE2 16003 eBGP iBGP POP Inter-AS MPLS domain iBGP Next-hop self 24001 Payload 16003 VPN label TE label PUSH SWAP 24002 Payload VPN label 24002 Payload VPN label 24001 Payload VPN label SWAP & PUSH 24002 Payload 16003 VPN label TE label POP POP

© NTT Communications Corporation All Rights Reserved. 19 SR domain AS β Inter-AS MPLS ● ASごとにSRドメインを分離し、Option BでVPN実装 ○ Global Uniqueな情報（SID/IGP情報）を分離、スケーラビリティを確保︕ ● AS間の接続の⾃由度も確保 ○ AS間の繋がりはSRに依存しない、MPLS-VPNでVPN経路を交換するだけの疎結合 ○ トランジットASを挟み、3AS以上での検証にも成功︕ SR domain PE/ASBR1 16003 P1 16002 PE/ASBR2 16001 AS γ AS α PE1 16001 SR domain P2 16002 PE2 16003 Inter-AS MPLS Node SIDはAS内でUniqueであれば良い。横のASを気にせず設計可能 IGP空間はASごとに閉じる。横のASに内部的な設定変更/障害影響を与えない PE/ASBR2 16001 P2 16002 PE2 16003 Multi-AS SR（VPN）のまとめ

© NTT Communications Corporation All Rights Reserved. 20 Multi-AS SR - Traffic Engineering

© NTT Communications Corporation All Rights Reserved. 21 Inter-AS Option BのLSDBによるTEの限界 ● Option BではPEがASを超えた最適経路を計算できない ○ SR domain/IGP情報をASごとに分離するため ○ Option-CであればIGP情報が混ざるため、PEが最適経路を計算可能 ○ TE情報の集中と分散設計 SR domain PE/ASBR1 16004 P1 16002 PE/ASBR3 16001 AS β AS α PE1 16001 SR domain P3 16003 Inter-AS MPLS domain POP P2 16003 P4 16004 PE/ASBR2 16005 PE/ASBR4 16002 PE2 16005 PE1はAS α内のLinkStateしか持たないため、AS α内部のTEパスしか計算できない AS β内部のTEはASBR3やASBR4のポリシーに依存する

© NTT Communications Corporation All Rights Reserved. 22 Multi-AS構成におけるTE ● Multi-ASでのユースケースを満たすようなTEとは︖ ○ この通信を帯域 X bps以上 / 遅延 X ms未満 で送りたい / 冗⻑系のうち1系をメインに送りたい ○ → ある意図（Intent）に基づいたTEが構築できればOK ■ 送信元PEでE2Eの最適経路計算を⾏う代わり、ASごとにIntentを満たす部分最適経路を構築し接続 ■ ASごとのIntentは他ASへTEメニューとして提供 SR domain PE/ASBR1 16004 P1 16002 PE/ASBR3 16001 AS β AS α PE1 16001 SR domain P3 16003 Inter-AS MPLS domain POP P2 16003 P4 16004 PE/ASBR2 16005 PE/ASBR4 16002 PE2 16005 Intentに基づく部分最適なTE α Intentに基づく部分最適なTE β Intent情報を事前に共有、⼀連のTEを実現

© NTT Communications Corporation All Rights Reserved. 23 （参考）Intent-based Networking ● 意図に基づいてネットワーキングを実現する概念 ○ 運⽤者が事前に定義した状態になるようネットワークを構築する ○ 例: 障害が起きても、常に帯域X bpsを満たすようリルートされる経路 ○ 例: IGPコストではなく、常に遅延最⼩になるような経路 画像: https://blogs.cisco.com/networking/improving-networks-with-ai

© NTT Communications Corporation All Rights Reserved. 24 TEメニューの実現 ● BGP Color Extended Communityを利⽤ ○ TEメニュー（Intent）に対応するColorを定義、伝搬 ○ Colorの値はTE区間 = SR domainに隠蔽 ■ AS間では相互流通⽤のColorに変換、ASごとに値を変換しながら伝達 ● 下記は極端な例だが、全区間でColorを変換している SR domain PE/ASBR1 16004 P1 16002 PE/ASBR3 16001 AS β AS α PE1 16001 SR domain P3 16003 Inter-AS MPLS domain POP P2 16003 P4 16004 PE/ASBR2 16005 PE/ASBR4 16002 PE2 16005 eBGP iBGP iBGP Color: 1000 Color: 300 Color: 200 相互流通ルールの Color = 1000に変換 AS αのルールで Color = 300に変換 Color = 300に紐づく 最短遅延パスを割当 最短遅延のIntentを指定したい 経路にColor = 200を付与

© NTT Communications Corporation All Rights Reserved. 25 SR domain内でのTE実現⼿法の例 ● TEには複数の⼿法が存在。管理のしやすさを考慮し⼿法を検討 SR domain PE/ASBR1 16004 P1 16002 AS α PE1 16001 P2 16003 PE/ASBR2 16005 SR domain PE/ASBR1 16004 P1 16002 AS α PE1 16001 P2 16003 PE/ASBR2 16005 ● Headend（PE/ASBR）がIntentを満たすように TailendまでのSIDを積む⽅式（Explicit-Path/CSPF） ○ IntentはSegment ListとしてInstance化される ● Intentを満たすFlex-Algoを定義し転送を⾏う⽅式 ○ IntentはAlgorithmとしてInstance化される 10, 100 10, 100 100, 10 10, 10 10, 100 10, 100 100, 10 Algorithm 128: exclude-all RED, IGP Metric Algorithm 129: exclude-all RED, TE Metric Algorithm 130: exclude-all GREEN, IGP Metric Explicit-Path 1: 16002/16005 Explicit-Path 2: 16002/16003/16005 Explicit-Path 3: 16003/16005

© NTT Communications Corporation All Rights Reserved. 26 HeadendでSIDを積むパターン Explicit-Path 1: 16002/16005 Explicit-Path 2: 16002/16003/16005 Explicit-Path 3: 16003/16005 SR domain PE/ASBR1 16004 P1 16002 AS α PE1 16001 P2 16003 PE/ASBR2 16005 ● VPNのIngress PE = HeadendでIntentを満たすSegment Listを定義 ○ Explicit-PathやCSPF計算など、PEの機能のみで実現 ○ シンプルな⼿法だが、TE経路の増減に合わせてHeadendに詳細な設定が必要

© NTT Communications Corporation All Rights Reserved. 27 Flex-Algoで転送するパターン（1/2） ● IGPの経路計算を柔軟に実現するため、経路計算⾯を仮想化・多重化する技術 ○ 分けたAlgorithmごとにトポロジを持ち、AlgoごとのMetric/制約で経路計算を実施 ■ Affinity制約: bitmapなColor。Include(any/all), Excludeなどが選択可能 ■ Metric: IGP Metric・TE Metric・DelayなどAlgorithmごとに設定可能 ■ Disjoint Path: SRLG（Shared Risk Link Group）を考慮した冗⻑パスの有効利⽤ ○ QoS保証をしつつルーズソースルーティングをする、などということが可能 A D B C SR domain A D B C A D B C Algorithm 129: Exclude GREEN TE Metric Algorithm 128: Exclude RED IGP Metric A D C Algorithm 130: include-all Blue IGP Metric 100, 10 10, 100 10, 10 100, 10 10, 100 Metric: IGP, TE Color Legend 10 10 10 100 100 10 10 10 10 10

© NTT Communications Corporation All Rights Reserved. 28 Flex-Algoで転送するパターン（2/2） ● Intentを満たす詳細な経路をStrictに指定せず、Algoに基づくLooseな指定が可能 ○ Intent/SliceをAlgoの形で管理可能 ○ Algo/Affinityは全ルータで正しく設定・認識される必要あり SR domain PE/ASBR1 16004 P1 16002 AS α PE1 16001 P2 16003 PE/ASBR2 16005 10, 100 10, 100 100, 10 10, 10 10, 100 10, 100 100, 10 Algorithm 128: exclude-all RED, IGP Metric Algorithm 129: exclude-all RED, TE Metric Algorithm 130: exclude-all GREEN, IGP Metric

© NTT Communications Corporation All Rights Reserved. 29 SR domain内でのTE実現⼿法⽐較 SR domain PE/ASBR1 16004 P1 16002 AS α PE1 16001 P2 16003 PE/ASBR2 16005 ● HeadendがIntentを満たすSIDを積む⽅式 ○ IntentはSegment ListとしてInstance化 ● pros: 中間に追加Stateは不要。PEのみで管理 ● cons: 網がIntentを持たないため、障害等で経路変更が ⽣じた場合、Intentが満たされなくなる可能性あり ● Intentを満たすFlex-Algoを利⽤し転送を⾏う⽅式 ○ IntentはAlgorithmとしてInstance化 ● pros: Intent数分のステートを網に設定する必要あり ● cons: 障害時の経路変更後も、必ずIntentが満たされる 10, 100 10, 100 100, 10 10, 10 10, 100 10, 100 100, 10 SR domain PE/ASBR1 16004 P1 16002 AS α PE1 16001 P2 16003 PE/ASBR2 16005 Algorithm 128: exclude-all RED, IGP Metric Algorithm 129: exclude-all RED, TE Metric Algorithm 130: exclude-all GREEN, IGP Metric Explicit-Path 1: 16002/16005 Explicit-Path 2: 16002/16003/16005 Explicit-Path 3: 16003/16005

© NTT Communications Corporation All Rights Reserved. 30 ユースケースを満たすTE実装のまとめ ● ASごとにSR domainを分離しつつ、Intentに基づくTEの接続を実現 ○ ASごとにLinkstateが隠蔽されるためE2Eの最適経路は計算できないが、Intentの形でTEを実現 ○ AS間ではColorによる疎結合なTEの接続 ○ AS内ではIntentに基づいたSegment Listの積み込みや、Flex-AlgoによるLooseな指定が可能 SR domain PE/ASBR1 16004 P1 16002 PE/ASBR3 16001 AS β AS α PE1 16001 SR domain P3 16003 Inter-AS MPLS domain POP P2 16003 P4 16004 PE/ASBR2 16005 PE/ASBR4 16002 PE2 16005

© NTT Communications Corporation All Rights Reserved. 31 その他SR-MPLSの検証について 網の持つ機能の向上・充実

© NTT Communications Corporation All Rights Reserved. 32 その他のSR-MPLS関連技術検証 ● より柔軟・⾼度なTEを⽬指し、下記4点をマルチベンダ環境で検証︕ ○ Performance Measurement ■ 遅延ベースのTEを実現 ○ EPE（Egress Peer Enginieering） ■ AS間もSR Policyによるを実現 ○ SR PolicyによるIGPメトリックの上書き ■ ASBRをSR Policyにより選択 ○ FRR / TI-LFA ■ 障害発⽣時も⾼速に復旧

© NTT Communications Corporation All Rights Reserved. 33 Performance Measurement ● SR Policyの接続性や遅延などを計測 ○ https://datatracker.ietf.org/doc/html/draft-gandhi-spring-stamp-srpm ○ 遅延が最⼩になるようなTEメニューを提供したい︕ ● TWAMP（Two-Way Active Measurement Protocol） ○ https://datatracker.ietf.org/doc/html/rfc5357 ○ タイムスタンプ付きのUDPパケットを利⽤し、遅延を計測するためのプロトコル ■ 通常のTWAMPの他に、Client-Serverを省略したTWAMP Lightも存在 ○ 計測結果はIGP / BGP-LSに載せて広告可能 ■ Flex-Algoとの組み合わせ、Delay MetricのIGP計算スライスを作成するなど ● P2P遅延とE2E遅延 ○ P2P遅延: ある区間の遅延を計測する⼿法。IGPで集め、Metricとして利⽤ ○ E2E遅延: ある経路の遅延を計測する⼿法。定義済みのSR Policyの評価などに利⽤

© NTT Communications Corporation All Rights Reserved. 34 Performance Measurementの活⽤例（P2P） ● P2P区間の遅延を集めてLinkstateとして広告、Metricとして利⽤ ○ Delay MetricベースでのSegment List構築やFlex-Algoの定義など ● Performance Measurementの課題 ○ 遅延の測定結果がベンダによりオーダーが違うほどの差 ■ E2Eの遅延計算がリンク遅延の合計となると、正しく実情を反映できない SR domain PE/ASBR1 P1 AS α PE1 P2 PE/ASBR2 TWAMP

© NTT Communications Corporation All Rights Reserved. 35 Performance Measurementの活⽤例（E2E） ● 発⾏済みSegment Listを⽐較し、最適な経路を選択 ○ 実測値に基づいてSegment Listを選択可能 ○ 計測⼿法にはOne-way / Two-way / Loopbackの3種が存在 ■ 時刻同期の必要性や計測可能区間（⽚道/往復）、計測精度に違い SR domain PE/ASBR1 16004 P1 16002 AS α PE1 16001 P2 16003 PE/ASBR2 16005 TWAMP Explicit-Path 1: 16002/16005 Explicit-Path 2: 16002/16003/16005 Explicit-Path 3: 16003/16005

© NTT Communications Corporation All Rights Reserved. 36 eBGP Peerごとに発⾏された EPE Peer Adj SIDで処理 ● EPE (Egress Peer Engineering) ○ 対向ASへの経路が複数ある場合にそのどちらかを選択するための技術 ● SRでのEPE ○ Peer Adj SID / Peer Node SIDで対向を識別 ○ https://datatracker.ietf.org/doc/html/rfc9086 EPE SR domain PE/ASBR1 P1 ASBR β AS β AS α PE1 PE/ASBR2 P2 ASBR γ AS γ 24001 Payload Segment List Label Action Next 24000 POP ASBR β 24001 POP ASBR γ ... ... ... PE/ASBR 1のSID Table（⼀部）

© NTT Communications Corporation All Rights Reserved. 37 ● Multi-ASにTEをする場合、下記の3種類が重要となる a. AS内のTE（SR-TE） ■ Multi-ASなTEメニューのため、より効率的かつ柔軟なTEをしたくなる ■ TE Metric/遅延ベースなFlex-Algo等との組み合わせ、IGP MetricのOverride... b. ASBR（Egress）の選択 c. Egress Peerの選択 ■ 同⼀Prefixに対して複数の経路を持ちたい → RR環境ではBGP add-pathなども必要 Egress/Egress Peer周りのTEについて SR domain PE/ASBR1 P1 ASBR β1 AS β AS α PE1 PE/ASBR2 P2 / RR ASBR β2

© NTT Communications Corporation All Rights Reserved. 38 1. Head-endから⾒た時のASBRの選択⽅法が難しい ○ PE1はASBR1/2どちらに送るか、先のLinkstateが⾒えないのでマクロな判断が不可 ■ BGP attribute（LP等）での制御は可能 ■ SR-TEのメトリクスによるASBR選択も⼀部ベンダでは可能 2. EPE/VPNの同時利⽤問題 ○ Egressでのラベルの2枚消費が不可能。EPEとVPNラベルを兼ねる機能も検討されていそうだが... Inter-AS部分のTE設計の難しさ SR domain PE/ASBR1 P1 ASBR β1 AS β AS α PE1 PE/ASBR2 P2 / RR ASBR β2 24001 Payload 16003 VPN label EPE label 課題② EgressでEPEラベルとVPNラベルの同時処理が不可能 課題① IngressはEgressから先のLinkstateを持たないため、 冗⻑なEgressの選択材料がない

© NTT Communications Corporation All Rights Reserved. 39 FRR / TI-LFA ● FRR（Fast Reroute） ○ Backup-Pathを⽤意し、障害時に50ms未満のLocal Repairを実現 ● TI-LFA（Topology-Independent Loop-Free Alternate） ○ FRRの実現⼿法の⼀つ。トポロジを問わずループフリーなBackup-Pathを⽣成 ■ Qノード、Pノードを選出し、P→Qノードを通るよう迂回路を⽣成 ■ IGPでSID込みのトポロジ共有をするSRとの親和性 画像: https://www.netone.co.jp/knowledge-center/blog-column/knowledge_takumi_121/

© NTT Communications Corporation All Rights Reserved. 40 Inter-AS Option BとFRR/TI-LFAの課題 ● Inter-AS部分の保護ができず、真のE2E FRRは不可能 ○ TI-LFAはIGP前提の技術であるため、Option-BではASを超えて使⽤できない SR domain PE/ASBR1 16004 P1 16002 PE/ASBR3 16001 AS β AS α PE1 16001 SR domain P3 16003 Inter-AS MPLS domain POP P2 16003 P4 16004 PE/ASBR2 16005 PE/ASBR4 16002 PE2 16005 Inter-AS区間にはIGPが存在しないため、 FRRでの保護は不可能

© NTT Communications Corporation All Rights Reserved. 41 その他のSR-MPLS関連技術検証のまとめ ● ⾼度なTEを実現するため、様々な技術を検証 ○ Performance Measurement: 遅延ベースIntentの実現 ○ EPE（Egress Peer Enginieering）: AS間部分のTEを実現 ○ SR PolicyによるIGPメトリックの上書き: ASBR選択を実現 ○ FRR / TI-LFA: 障害発⽣時の⾼速迂回（Local Repair） ● → これらの技術について、マルチベンダでの検証を実施済

© NTT Communications Corporation All Rights Reserved. 42 SR-MPLS / SRv6相互接続 Service Function Chainingの活⽤

© NTT Communications Corporation All Rights Reserved. 43 ● マルチAS/マルチドメインなSegment Routing ○ SRv6も⼀つのASとしてOption Bで接続︕ Customer CE CE Customer Customer AS AS SR-MPLS domain Inter-AS MPLS （再掲）作りたいネットワーク Interwork ASBR P SRv6 domain PE/ASBR PE/ASBR P PE/ASBR SFC Proxy Network Function SR-MPLS domain PE PE/ASBR PE P PE CE CE SR-MPLS domain Customer Inter-AS MPLS PE PE P PE/ASBR AS AS Inter-AS MPLS CE Customer

© NTT Communications Corporation All Rights Reserved. 44 SRv6を利⽤・検証するモチベーション ● Service Function Chainingの導⼊ ○ 網への付加価値提供 ○ Option BのASとして参加し、SFCを提供する網として設計︕ ● SRv6の実装状況調査・機能検証 ○ SRv6の技術検証のため、SRv6内でのTE/VPNのフィールド検証も兼ねてASを設計 ■ SRv6 FunctionによるVPN・SFCの検討 ■ C-Plane検証 ○ SRv6のユースケース検討 ■ SFCのユースケース ■ 既存のIPv6網を活⽤︓将来的な商⽤網のマイグレーション難易度を下げる︖

© NTT Communications Corporation All Rights Reserved. 45 Service Function Chaining ● Service Function Chaining ○ TEの応⽤技術の⼀つ ■ https://datatracker.ietf.org/doc/html/rfc7665 ○ NW上の機能を特定の順番でつなぎ、サービスとして提供する技術 ■ ある通信に付加価値を提供することが可能 ○ ⽇本語ではサービスチェイニングと呼ぶことが多い CGN Firewall Optimizer DPI Dst. Service Chain B Service Chain A Customer A Customer B

© NTT Communications Corporation All Rights Reserved. 46 SRv6 SFC Proxy ● SRv6⾮対応なNetwork Functionを利⽤するための技術 ○ SFF（Service Function Forwarder）: Fucntionにパケットを転送、戻りパケットを受信するノード ○ SR Proxy: SRv6⾮対応なノードに対しパケットを転送、戻りパケットをSRv6に再送信するノード ■ SRv6ではSFFと機能を兼ねる設計が可能 ● SRv6ではEnd.A系のFunctionによりProxyを実現 ○ https://datatracker.ietf.org/doc/draft-ietf-spring-sr-service-programming/ ■ SR-Unaware対応のため、Static / Dynamic / Masquerading の3⽅式が提案 PE 1 SR domain SFF / SR Proxy PE 2 Function End.AM 1. Segment Leftを1つ進め（End） Destination AddressをSegment List [0]（末尾）で上書き 3. Destination AddressをSegment List [Segment Left] （本来の先頭要素）で上書き、SRv6による転送を再開 2. Network Functionは正しく最終的なDestinationが 指定されたIPv6パケットを受け取る（拡張ヘッダは無視）

© NTT Communications Corporation All Rights Reserved. 47 SFCの良い使い⽅とは︖ ● 単なるSecurity Functionの提供ではメリットがない ○ Functionを利⽤者の⼿元（エッジ）に置く⽅が効率的な場合が存在 ■ 経路をねじ曲げて無駄に遅延をかける理由がない ○ SRの⽴場としては、将来的にはSR対応のFunctionが欲しい ■ Node SIDで指定するとInlineにFunctionを適⽤するようにして欲しい ○ → これらがEnd.A系のFunction実装が盛り上がらない理由 ■ ただし業界的にはSR対応のFunctionが開発されているわけではない ● SFCの良い使い⽅︖ ○ ① Streaming処理でFunctionを適⽤ ■ ①はSFC Proxyとの相性が悪い。Streamingと経路のねじ曲げの相性問題 ● その上Multi-AS構成でAS的にねじ曲げて引き込むと考えると...? ○ ② 同⼀の機材を複数のCustomerで利⽤し、規模の経済を実現 ■ ユースケース次第。SFC Proxy等を設定し、通信の途中に⼊れてまで利⽤したいFunctionがあるか

© NTT Communications Corporation All Rights Reserved. 48 2021/12時点で検討しているSFCのユースケース ● 全社に先⾏した新機能や最新機材の検証 ○ SRv6網で最新機能を検証 ○ 他ASは気軽に接続しサービスを検証、良さそうなら⾃らのAS内部に取り込み ■ Security appliance、Load balancer、CGN、NFV基盤... ○ 全社に先駆けて検証を⾏うR&D部⾨ならではの強み ● 構築、運⽤の⼿間を削減した隣接ASへのサービス提供 ○ C-Planeを活⽤した拡張性の⾼い相互接続 ○ チェインを含めたTEポリシーとして隣接ASに公開するなど、利⽤しやすいSFCメニューの提供

© NTT Communications Corporation All Rights Reserved. 49 SRv6/SR-MPLS相互接続の課題 Interwork ASBR SRv6 P ASBR PE2 P PE1 CE2 CE1 SFC Proxy Network Function SRv6 PE ● SR-MPLSのCustomer同⼠の通信にSFCを提供することを考える ○ シンプルなIP Forwardingだけでは折り返しは実現できない ■ SR-MPLSのSFCもdraftで議論されているが、折り返し可能な実装はない 同じ192.168.1.0/24宛のVPN経路を、 ⾏きはSRv6⽅向に転送し、 戻りはSR-MPLS⽅向に転送する︖ SRv6 domain Inter-AS MPLS SR-MPLS domain Customer Customer 192.168.0.0/24 192.168.1.0/24

© NTT Communications Corporation All Rights Reserved. 50 解決策: ルーティング⾯の分割（1/2） Interwork ASBR SRv6 P ASBR PE2 P PE1 CE2 CE1 SFC Proxy Network Function SRv6 PE ● ⾏きと戻りでルーティングを分割すれば実現可能 ○ ⾏きのTrafficを処理するノードと帰りのTrafficを処理するノードを⽤意 Interwork ASBR ASBR SRv6 domain Inter-AS MPLS SR-MPLS domain Customer Customer 192.168.0.0/24 192.168.1.0/24

© NTT Communications Corporation All Rights Reserved. 51 解決策: ルーティング⾯の分割（2/2） SRv6 P PE2 P PE1 CE2 CE1 SFC Proxy Network Function SRv6 PE ● ルーティング⾯の分割をVRFで実現 ○ 送信⽤、受信⽤のVRFを⽤意し、経路を分離 Interwork ASBR ASBR rt export 65001:1 rt import 65001:101 VRF cust-a-rcv VRF cust-a-snd End.DT6（cust-a-snd） VPN label（cust-a-snd） SRv6 domain Inter-AS MPLS SR-MPLS domain Customer Customer 192.168.0.0/24 192.168.1.0/24

© NTT Communications Corporation All Rights Reserved. 52 SR-MPLS、SRv6相互接続⼿法の課題 ● SR-MPLS側 ASBRへの影響（後述） ○ SR-MPLS側にも接続⽤VRFを設定する必要 ■ 例えばiBGP由来のSend⽤ラベルとeBGP由来のRecv⽤ラベルをGlobal VRFだけで併⽤できれば解決 ● iBGP/eBGP由来のVPNラベルを同時にLFIB installする⽅法︖ ● VRF/Route-Target 数の増加 ○ Customer x2の数だけVRFを⽤意しなければならない... ○ Send/Recv⽤にGlobalなVRFを作成し、それぞれBGP sessionを貼る改善案も検討中 ■ CustomerごとのSend/RecvのVRFは不要になる ■ Recv⽤に専⽤のVRF/RTを⽤意する必要がなくなり、スケーラビリティが向上するはず

© NTT Communications Corporation All Rights Reserved. 53 （補⾜）SR-MPLS側のInterwork ASBRについて SRv6 P SRv6 domain PE2 P PE1 CE2 CE1 SFC Proxy Network Function Inter-AS MPLS SR-MPLS domain SRv6 PE Customer ● MPLSはラベルによる転送⼿法であるため、折り返しの実現可能性あり ○ ⾏きを⽰すラベルと帰りを⽰すラベルを別に⽤意、それぞれを指定する ■ 現時点では、単⼀のVRFでeBGP/iBGPで学習した経路を同時にLFIB Installする実装がないため断念 Customer 192.168.0.0/24 192.168.1.0/24 Interwork ASBR ASBR 24000 Payload VPN label 24001 Payload Label Action Next 24000 SWAP 24000 SRv6へ 24001 SWAP 24000 SR-MPLSへ ... ... ... ASBRのMPLS Table（⼀部）

© NTT Communications Corporation All Rights Reserved. 54 SRv6 - SR-MPLS相互接続検証まとめ ● SRv6の⼀つのユースケースであるService Funtion Chainingを導⼊ ○ 網への付加価値提供が可能 ○ Option BのASとして参⼊し、SR-MPLSにもSFCを提供 ■ 作成したASはマルチベンダにSRv6を検証する網としても活⽤ ● SR-MPLS - SRv6 - SR-MPLS折り返しのための⼿法を提案 ○ 折り返しの結果、SR-MPLS網にSFCの提供に成功

© NTT Communications Corporation All Rights Reserved. 55 SRv6 AS内部について ● SRv6の機能検証を⾏うASとしても設計、検証を実施 ○ SRv6 FunctionによるVPN/TE（Flex-Algo）/ SFCの検証 ○ SRv6⾮対応ノードのTransit活⽤ ○ マルチベンダSRv6 ● 複数の拠点にまたがる網を1つのASとして設計 ○ 将来的にはIPv6の性質を⽣かし、AS/拠点/Algo単位で階層化されたMulti-AS通信なども可能︖ Customer A P Customer B SR domain Site B Network Function PE PE / SFC Proxy Customer A Customer B Site C Site A PE P P P Customer A Customer B

© NTT Communications Corporation All Rights Reserved. 56 SRv6のSID設計案 ● 基本的に可変⻑かつ⾃由（ただし⼀部の実装はLocator⻑が固定） ○ （例）Cisco: Locatorは64bit、うち上位40bitをSID block、下位24bitをNode IDとして利⽤ ● 階層的に設計することに利点あり︖（拠点間通信やSRv6⾮対応網の利⽤など） ○ 例えば AS Prefix : 拠点ID : Algo ID : index のように設計するべきと考える ○ Function部分も管理がしやすいようID設計を⾏う ○ ただしSIDはLocatorを元に⾃動⽣成する実装も多く、Functionを任意の値にできない場合も ■ （例）VPNv6によるEnd.DT6の⾃動払い出し SID設計の例。2001:db8::/32 を利⽤し設計を実施 例では255拠点で、拠点ごとに65535ノードが収容可能になる LocatorはASの持つPrefixや⾮SR網のアドレスブロック、 Function/ArgumentはSRv6の⽤途と相談して設計する 2001:db8:180:1:1:4:1:a 拠点ID（拠点1） Flex-Algo ID (128) Algo内のindex Function Sub-ID Function ID パラメータ1 パラメータ2

© NTT Communications Corporation All Rights Reserved. 57 （参考）SR-MPLSとSRv6の⽐較 ● SR-MPLS側の利点 ○ SR-MPLSの⽅が先に実装が始まっているため、SRv6に⽐べ実装状況が良い ■ MPLS-VPNなど、MPLSの既存アーキテクチャもそのまま活⽤できる ○ SRv6に⽐べSIDサイズが⼩さい（SRv6 128bitに対しSR-MPLSは32bit） ● SRv6側の利点 ○ 128bitのSIDを活かして様々な動作を⾏うSRv6 Functionの存在、⾼い拡張性 ○ SRv6に対応していない網も、IPv6さえ対応していれば⼟管として使⽤可能 ■ 仮に間にインターネットが挟まっていても、IPv6さえあれば転送可能

© NTT Communications Corporation All Rights Reserved. 58 SRv6活⽤のまとめ ● Service Function Chainingによる付加価値提供 ○ R&D部⾨としてのNetwork Function検証、PoCの場として検討中 ● Option Bで⼀つのASとして実現 ○ 疎結合なMulti-AS構成の利点 ○ SR-MPLS網にSFCを提供 ■ SR-MPLSには現状SFC実装がないので、折り返しに⼯夫が必要 ● SRv6機能検証の場としてもASを活⽤中

© NTT Communications Corporation All Rights Reserved. 59 Future Work

© NTT Communications Corporation All Rights Reserved. 60 Future work ● PCEの活⽤ ● セルフマネージポータルの開発 ● より⾼度なTEの実現 ● SRv6のさらなる活⽤

© NTT Communications Corporation All Rights Reserved. 61 PCE（Path Computation Element） ● 中央集権的に経路計算を実⾏するノード ○ 複雑なポリシーの適⽤や経路計算、発⾏済みのLSP管理などを実現 ○ 遅延、トラフィック分散、Affinity制約などの複雑なTEの実現、SDN的なアプローチ ○ Stateful PCEによる発⾏済みのパスの管理や、可視化との相性、マルチドメインの集中管理 ● → 集中的な網の管理や複雑な経路計算などに威⼒を発揮 Router (PCC) Router Router (PCC) PCE Path情報（MPLSではLSP）の計算 経路(PCE)⽣成時の処理 トポロジ変更時の処理 (BGP Triggered Update) LinkStateの共有 Path情報の伝達

© NTT Communications Corporation All Rights Reserved. 62 ● Stateless PCE: 発⾏済みのLSP/Segment Listを管理するPCE ○ PCReqに対応した経路を発⾏し、PCRepを返すだけ ● Stateful PCE: 発⾏済みのLSP/Segment Listを管理しないPCE ○ 経路変更などが⽣じた際、PCE側からPCCに能動的に経路変更が可能 ○ 新規LSPの確⽴（PCInitiate）、既存LSPの経路変更（PCUpd）など ○ ポータル等と組み合わせ、発⾏済みLSPの可視化等が可能 Stateful PCEとStateless PCE 画像: https://www.slideshare.net/TakuyaMiyasaka/pce-mplssdn PCE

© NTT Communications Corporation All Rights Reserved. 63 （参考）SRの帯域保証について ● SRのIGP機能だけではRSVP-TEのような帯域保証はできない ○ 帯域を確保するシグナリングプロトコルを利⽤しないため ● Stateful PCE機能を備えたコントローラを⽤いることで可能となる ○ 既存Segment Listの情報を管理することで帯域を管理 ○ Telemetry等と組み合わせた機器情報管理と相性 ● PCEを使わない場合の帯域保証も提案 ○ SRでもRSVP-TEのような仕組みを使う ■ https://datatracker.ietf.org/doc/html/rfc8403

© NTT Communications Corporation All Rights Reserved. 64 ● マルチASなPCEの効率的な設計、運⽤は難しい ○ 集中と分散を考慮した設計 ○ Linkstateを⼀元管理することで真のE2E最適は満たせるが、Option C的な情報管理となる ○ Option B的に情報を分離しつつ、E2E最適を満たすための仕組みを導⼊する︖ ASごとにPCEを配置する場合はOption B的な運⽤、 ASを超えてPCEに管理させる場合はOption C的な運⽤となる︖ マルチAS対応のものも出ているので、ベンダ実装を検証中 マルチASなPCEの連携 SR domain PE/ASBR1 16004 P1 16002 PE/ASBR3 16001 AS β AS α PE1 16001 SR domain P3 16003 Inter-AS MPLS domain POP P2 16003 P4 16004 PE/ASBR2 16005 PE/ASBR4 16002 PE2 16005 PCE PCE LinkStateや発⾏済みSegment Listの共有︖

© NTT Communications Corporation All Rights Reserved. 65 セルフマネージポータルとの組み合わせ ● マルチAS環境のセルフマネージ化 ○ ユーザが⼿元のASから対向のASを操作、PCEとも好相性 ○ ASを超えた制御に課題 ■ 横のASをオンデマンドに操作して良い︖ ● 双⽅向なTEを考えると、対向ASのPEにもSR Policyを与える必要...? ■ TEメニューの提供⽅法や課⾦⼿法などが課題になるか https://onic.jp/_cms/wp-content/uploads/2019/11/onic2019_tajima.pdf

© NTT Communications Corporation All Rights Reserved. 66 リアルタイムな監視技術の活⽤ ● リアルタイムな情報と組み合わせ、より⾼度なTEを実現 ○ リアルタイムな流量や帯域をベースにした最適化 ○ 故障予測と回避など ○ TelemetryやxFlowなど、様々な監視情報と組み合わせる ■ Telemetry技術検証について: https://engineers.ntt.com/entry/2021/09/02/162022 ■ Service Function Chainingもパケットの監視⼿法として活躍できるかも SR domain PE/ASBR1 P1 AS α PE1 P2 PE/ASBR2 PCE Telemetry Collector Telemetry情報から得たリンクの統計情報や、 コントローラで実施した機器の故障予測などを元にSegment Listを更新 Segment Listの更新 Telemetry

© NTT Communications Corporation All Rights Reserved. 67 SRv6のさらなる活⽤ ● 既存IPv6網の活⽤ ○ ⾮対応網を取り込んでおいて、少しずつSRv6化する︖ ■ 対応したところからTEができるようになるのは⾯⽩い ■ エッジ間でVPNを貼っておき、将来的にTEもできるようになるというのもgood ■ 間に別のIPv6網が⼊るとアドレス設計をうまくできなくなるのが課題 ○ 運⽤中の網におけるマイグレーション︖ ■ 1. 既存網にSRv6網を接続 ● SFCや固有Functionなどで付加価値提供 ■ 2. 既存網の⼀部をSRv6化する ● 例えばエッジ部分をSRv6化し、⾮対応ノードをVPNの⼟管として利⽤ ■ 3. 既存網全体をSRv6化し、SRの適⽤範囲を拡⼤していく ● 少しずつ参加するASを増やせるのもMulti-AS構成の強み

© NTT Communications Corporation All Rights Reserved. 68 まとめ ● Multi-AS Segment Routingの提案 ○ スケーラビリティの向上 ■ ASごとのリソース分離・Intentに基づいたTEメニューの設計・集中と分散のバランス ■ 疎結合なMulti-AS構成により新たな網の追加も容易に。SRv6も1つのASとして検証中 ○ 新たなユースケースの獲得 ■ 拠点ごとのAS設計 ■ 管理者の異なるASのつなぎ合わせ ■ SFCの活⽤ ■ → 将来的なネットワーク設計の⼀つの姿 ● ⼀緒に取り組む仲間を募集中 ○ 是⾮継続して議論しましょう CE CE Interwork ASBR P PE/ASBR PE/ASBR P PE/ASBR SFC Proxy Network Function PE PE/ASBR PE P PE CE CE PE PE P PE/ASBR CE SR-MPLS SR-MPLS SR-MPLS SRv6

© NTT Communications Corporation All Rights Reserved.