Segment Routingを用いたEPEの活用事例と GoBGPへの実装

Segment Routingを用いたEPEの活用事例と GoBGPへの実装
- 三島航 (NTTコミュニケーションズ株式会社)
- 豊田安信 (慶應義塾大学/株式会社ブロードバンドタワー)
- 金谷光一郎 (東京大学)

ENOG77 イベントページ: https://enog.jp/archives/2657

Transcript

1. Segment Routingを用いたEPEの活用事例と
   GoBGPへの実装
   Wataru Mishima NTT Communications Corporation
   Yasunobu Toyota Keio University / BroadBand Tower, Inc.
   Koichiro Kanaya The University of Tokyo
   1
   

   View Slide

2. 1. Key Ideas of Egress Peer Engineering
   ○ About Egress Peer Engineering
   ○ D-Plane: SRv6
   ○ C-Plane: BGP-LS EPE
   2. Our Activities about SRv6-EPE
   ○ Performance Aware Egress Path Discovery for Content Provider with SRv6 Egress Peer Engineering
   ○ QoE-Aware Content Oriented Path Optimization Framework with Egress Peer Engineering
   3. GoBGP Implementation of BGP-LS EPE
   ○ Development Background
   ○ Steps in the Development of BGP-LS EPE
   4. Conclusion & Future Works
   5. Discussion
   Agenda
   2
   

   View Slide

3. About us
   3
   Yasunobu TOYOTA
   Dr. student at Keio Univ.
   Researcher at BBTower, Inc.
   WIDE Project vSIX WG chair
   Koichiro KANAYA
   Master student
   at The University of Tokyo
   WIDE Project vSIX WG member
   Wataru MISHIMA
   Researcher & Developer
   at NTT Communications Corporation
   WIDE Project vSIX WG member
   watal_i27e
   https://github.com/watal
   yasnyannet
   https://github.com/yas-nyan
   kanaya516
   https://github.com/kanaya516
   

   View Slide

4. vSIX (IPv6 Single-stack Infrastracture Experimental network)
   活動：
   ● IPv6 single-stack ASの運用（AS4690）
   ● 次世代のインターネット運用技術の開発・検証
   ● ワカモノの育成
   ● インターネットコミュニティへの貢献
   メンバー: 産学の若手エンジニアが中心に50人以上
   vSIX WGについて
   4
   WIDE Project:
   https://www.wide.ad.jp
   vSIX WG:
   https://www.vsix.wide.ad.jp
   

   View Slide

5. 本セッションの目的
   ● EPEの運用と研究を通じて得られた知見を共有＆議論
   ○ EPEの可能性や活用に興味を持っていただくとともに、今後の研究につながる議論をしたい！
   ● 下記の2点を通じ、EPEについて紹介！
   1. EPEの技術説明とvSIX WGで運用・研究した活用事例紹介
   ■ SRv6 BGP-EPEを用いたBGP best path計測
   ■ コンテンツ毎にQoEを向上させるためのSRv6 BGP-EPEフレームワーク
   2. EPEを広く使っていただくためのOSS Contribution - GoBGPへの実装事例の紹介
   ■ 開発背景・開発の流れやステップ
   ■ 開発合宿の成果
   5
   本セッションに参加することで、EPEの魅力や活用手法などを体感いただけます！
   

   View Slide

6. 1. Key Ideas of Egress Peer Engineering
   6
   

   View Slide

7. ● EPEとは
   ○ Egress Trafficに対し，利用するASBRと転送先のEgress Peerを指定し制御する技術
   ■ 従来はBGPパラメータを用いてNW全体で制御されてきたが、より細かい単位でも制御したい！
   ● EPEのモチベーション
   ○ ユーザへのE2E通信品質が良い経路を利用したコンテンツ提供
   ○ 外部接続リンクの利用効率化
   AS65003
   AS65002
   AS65001
   What is “Egress Peer Engineering” ?
   7
   パスの
   切り替え
   コンテンツプロバイダ（AS65000）
   ASBR
   Egress Peer
   Egress Peer
   Egress Peer
   Server X
   Server Y
   Server Z
   Data Center
   Network
   BGPベストパス
   代替パス
   ASBR
   通信品質の劣化
   

   View Slide

8. D-Plane: SRv6 EPE
   ● SRv6: IPv6拡張ヘッダ（SRH: SRヘッダ）を用いるソースルーティング技術
   ○ IPv6フォーマットのSegment IDentifier（SID）によって中継ノード上で任意の機能を実行
   ○ PBR等と組み合わせIP Prefixに囚われない柔軟な経路制御も可能（C-Planeの工夫しどころ）
   ○
   ● データプレーンの流れの例
   1. head-end（Content Server）でSRヘッダをencap
   2. DCNは通常のIPv6パケットとして透過
   3. tail-end（ASBR）でSRヘッダをdecap，特定のネクストホップへ転送
   8
   packet
   SRH
   decap and forward
   to Egress Peer 1
   via Egress Peer 1
   packet
   Content
   Server DCN
   ASBR
   Egress Peer 1
   Egress Peer 2
   

   View Slide

9. ● 必要なC-Planeの機能
   1. 特定のEgress Peerに対応するSIDの広告
   ■ BGP-LS（RFC9086）
   ● RFC9086で提案されているが，実装はまだ発展途上
   ■ その他 (SDNで頑張る)
   C-Plane Requirements for EPE（1/2）
   9
   EPE-SID 1::1
   for Peer 1
   EPE-SID 2::2
   for Peer 2
   SIDの広告
   EPE SID
   の発行
   Content
   Server DCN
   ASBR
   Egress Peer 1
   Egress Peer 2
   

   View Slide

10. 2001:db8::/64
    への到達性アリ
    2001:db8:1::/64
    への到達性アリ
    ● 必要なC-Planeの機能
    2. SIDとPrefixの対応付け:
    ✔ RFC9086では，EPEコントローラが以下のどちらかを行い，head-endのencapsulationポリシー
    (EPEポリシー) を決定。（具体的なメッセージングフォーマットは未定義）
    ● 1. EPEコントローラがASBRとiBGPピアを張り，Add-PathをASBRから受信
    ● 2. EPEコントローラがBMPを使用してASBRのAdj-RIB-Inを追跡
    ■ Egress Peerから経路の広告がなければ，その経路を宛先としてそのEgress Peer経由で
    パケットを転送してはならない
    C-Plane Requirements for EPE（2/2）
    10
    SIDとPrefixの広告
    1::1
    2::2
    宛先2001:db8::/64
    へは，1::1というSID
    をencapし送信して良
    いんだな
    宛先2001:db8:1::/64
    へは，2::2というSID
    をencapし送信して良
    いんだな
    EPEコントローラ
    Content
    Server DCN
    ASBR
    Egress Peer 1
    Egress Peer 2
    

    View Slide

11. C-Plane Requirements for EPE（2/2）
    ● 必要なC-Planeの機能
    2. SIDとPrefixの対応付け:
    ■ RFC9086では，EPEコントローラが以下のどちらかを行い，head-endのencapsulationポリシー
    (EPEポリシー) を決定。（具体的なメッセージングフォーマットは未定義）
    ● 1. EPEコントローラがASBRとiBGPピアを張り，Add-PathをASBRから受信
    ● 2. EPEコントローラがBMPを使用してASBRのAdj-RIB-Inを追跡
    ✔ Egress Peerから経路の広告がなければ，その経路を宛先としてそのEgress Peer経由で
    パケットを転送してはならない
    2001:db8::/64
    への到達性アリ
    2001:db8:1::/64
    への到達性アリ
    11
    SIDとPrefixの広告
    1::1
    2::2
    宛先2001:db8::/64
    へのエントリから， SID
    1::1 を削除！
    宛先2001:db8:1::/64
    へは，2::2というSID
    をencapし送信して良
    いんだな
    EPEコントローラ
    Content
    Server DCN
    ASBR
    Egress Peer 1
    Egress Peer 2
    

    View Slide

12. 2. Our Activities about SRv6-EPE
    12
    

    View Slide

13. Our Activities
    ● AS 4690の運用を通じたBGP-EPEの研究チーム
    ○ EPEのもつ可能性を検証し、運用成果を研究につなげる
    ○ IPv6 Single-Stackなネットワークを活かし、SRv6 BGP-EPEを運用中
    ● BGP-EPE活用手法を提案・検証！
    ○ EPEは意味があるのか？: BGP best pathの品質測定システムの提案＆計測結果の評価
    ■ Performance Aware Egress Path Discovery for Content Provider with SRv6 Egress Peer Engineering
    IEICE Inf&Sys 2023年5月号（出版予定）
    ○ EPEは運用可能なのか？: コンテンツのQoEを向上させるEPEフレームワークの提案
    ■ QoE-Aware Content Oriented Path Optimization Frameworkwith Egress Peer Engineering
    CANDAR 2022
    13
    実用網やプロダクトでの活用事例を通じ、EPEの持つ利点やポテンシャルを紹介！
    

    View Slide

14. 2.1
    Performance Aware Egress Path Discovery for Content Provider
    with SRv6 Egress Peer Engineering
    14
    IEICE Inf&Sys 2023年5月号（出版予定）
    

    View Slide

15. 15
    コンテンツプロバイダから見たインターネット
    15
    そもそもウチのNW/コンテンツで、
    EPEをすることによるメリットが
    あるのかわからないな...
    どのPeerの経路を優先すればいいのかな？
    お客さんのISPにも依存するし、
    サービスごとに必要な品質は違うしな...
    コンテンツプロバイダ
    の運用者
    

    View Slide

16. 定量的に外向きの経路(Egress Path)を評価する仕組みが必要
    16
    16
    提案
    評価機構の要件：
    ①様々なQoS Metricsを扱えること
    - 遅延以外の要素もコンテンツ配信には重要
    ②実際のNW/アプリケーションで調べること
    - コンテンツアプリケーションの品質を向上させるために測るので、そのコンテンツ自体で測らないと意味がない。
    ③デプロイメントのインパクトが小さいこと
    → SRv6 EPE とPassive End-to-End Measurementで、
    自分のASでEPEが有効かどうか測りましょう！
    

    View Slide

17. ネットワーク：
    vSIX AS(AS4690)で実験を実施
    17
    評価実験：実験環境
    調査対象としたコンテンツ：
    スマホ用のスピードテストアプリのテストトラフィック
    1アクセス毎に6並列で100MBのダミーデータをHTTP GET
    Wi-Fiミレル | ネットワーク関連 | IODATA アイ・オー
    ・データ機器
    ※バックエンドは https://inonius.net
    Special Thanks: iNonius Project, IODATA-san.
    ↓ 某学術系AS
    ↑ 商用系AS
    ←凡そ10万人が利用
    ←殆ど日本からのアクセス
    

    View Slide

18. AS 4690
    所属AS other ASs
    speedtest
    server
    ASBR
    SRv6 domain
    評価実験： EPE トラフィックの流れ
    AS β
    AS α
    Internet
    IF
    つけられたSIDに基づいて
    どちらかのpeerに配送
    DL TrafficをL4 ECMPで
    どちらかのSIDに
    SRv6 encap
    DL Traffic
    アプリ利用者
    UL Trafficは
    BGP Best pathで流入
    一度のスピードテストに6つのTCPセッションを利用。
    各セッションはECMPによってどちらかのpeerへ配送
    18
    

    View Slide

19. 19
    評価実験：メトリクスの解析の仕組み
    トラフィックの品質そのものを
    計測・保存
    どのトラフィックが
    どのEPE-SIDを利用したか記録
    配送に利用された(と推定される)
    BGP Pathの情報
    ログの集約や紐付け
    どっちのPathが
    良かったかを評価
    

    View Slide

20. 20
    20
    実験結果
    当日のみご紹介します！お楽しみに！
    

    View Slide

21. 結論: EPEは意味があった！
    SRv6 EPE と Passive End-to-End Measurement で
    既存のNWに変更を及ぼすことなく
    Egress TEがQoS向上に有効かどうか調べられる！
    我々のAS・サービスでは、
    15％のユーザの品質向上が期待出来ることがわかりました！
    23
    23
    大掛かりな仕組みを入れなくても
    EPEのメリットがわかって嬉しい！
    ※IEICE Inf&Sys 2023年5月号で出版予定
    

    View Slide

22. 24
    CANDAR 2022
    2.2
    QoE-Aware Content Oriented Path Optimization Framework
    with Egress Peer Engineering
    

    View Slide

23. コンテンツプロバイダ (AS65000)
    ● COFFEE: Content-Oriented Flexible Framework of Egress Engineering
    ○ インターネットを介したコンテンツのエンドツーエンドのQoEを向上が目的
    ○ インテント（EPEポリシー）を投入すれば，自動で計測・評価・制御が可能
    ■ 一部のトラフィックは計測用に利用
    ■ インテントの例: RTTが最小となる経路
    AS65003
    AS65002
    AS65001
    COFFEE: EPE framework for content quality
    25
    25
    Egress Peer 2
    Egress Peer 3
    Egress Peer 1
    サーバX
    サーバY
    サーバZ
    EPEポリシーの定義
    DCN
    BGPベストパス
    代替パス
    を計測/評価し，
    評価結果に応じて制御
    25
    コンテンツ
    オペレータ
    ASBR 2
    ASBR 1
    

    View Slide

24. ASBR 2
    ASBR 1
    1. コンテンツサーバ: EPEの計測・評価・制御．パケットにSRHをカプセル化する
    2. ASBR: SRHを取り除き特定のEgress Peerへパケットを転送する
    3. EPEパスアグリゲータ: コンテンツサーバの経路の正当性を保証（like EPEコントローラ）
    構成要素
    コンテンツプロバイダ (AS65000)
    ✔
    ✔
    ✔
    ✔
    ✔
    BGPパスを反映
    COFFEE enabled host
    packet
    SRH
    packet
    SRH
    via C
    decap
    Contents
    Server
    EPEパスアグリゲータ
    AS65003
    AS65002
    AS65001
    Egress Peer 2
    Egress Peer 3
    Egress Peer 1
    DCN
    encap
    26
    

    View Slide

25. ③現在の状態を反映
    ● Kubernetesとは？
    ○ Kubernetesは，オープンソースのコンテナオーケストレーション・フレームワーク
    ○ カスタムリソース・カスタムコントローラとして，独自のリソースやコントローラを定義可能
    ■ カスタムリソース：”あるべき状態”を定義
    ■ カスタムコントローラ：カスタムリソースの変更を検出し，宣言的な動作を行う
    ○ 簡単かつ統一的にデータモデル・コントローラを定義可能であるため採用
    27
    Kubernetes Implementation
    カスタムリソース
    カスタムコントローラ
    ①変更を検出
    Kubernetes
    spec:
    あるべき状態
    status:
    現在の状態
    ②定義された
    動作を実施
    

    View Slide

26. 28
    28
    実装（全体像）
    flow-assessor
    epe-path-con
    stats-mon
    sid-mon
    カスタムコントローラ
    カスタムリソース
    flow-score
    epe-egress-
    peer
    srv6-epe-rule
    epe-rule-con
    bgp-con
    EPEライフサイクル
    EPEライフサイクル
    リソースに反映
    リソースの監視
    以下のリソース，コントローラをスクラッチで定義・実装
    カスタムコントローラ
    ではない
    

    View Slide

27. 29
    29
    実装（全体像）
    flow-assessor
    epe-path-con
    stats-mon
    sid-mon
    カスタムコントローラ
    カスタムリソース
    flow-score
    epe-egress-
    peer
    srv6-epe-rule
    epe-rule-con
    bgp-con
    EPEライフサイクル
    EPEライフサイクル
    リソースに反映
    リソースの監視
    以下のリソース，コントローラをスクラッチで定義・実装
    カスタムコントローラ
    ではない
    こんなのを見せられても
    何がなんだか
    分からないよ！！！
    

    View Slide

28. 30
    30
    実装（全体像）
    flow-assessor
    epe-path-con
    stats-mon
    sid-mon
    カスタムコントローラ
    カスタムリソース
    flow-score
    epe-egress-
    peer
    srv6-epe-rule
    epe-rule-con
    bgp-con
    EPEライフサイクル
    EPEライフサイクル
    リソースに反映
    リソースの監視
    以下のリソース，コントローラをスクラッチで定義・実装
    カスタムコントローラ
    ではない
    ということで，
    一部分だけご紹介いたします
    

    View Slide

29. 31
    31
    実装: 経路切替の実現手法
    カスタムリソース
    カスタムコントローラ
    （実際はサーバ内で動作）
    サーバ
    （server1）
    ②コマンドを実行
    ip -6 route replace …
    srv6-epe-rule
    epe-path-controller
    Kubernetes上で, カスタムリソース＆カスタムコントローラにより経路切替を実現！
    ● srv6-epe-rule: どのようにFIBを制御するか．SIDや5-tupleに対する重み
    ● epe-path-controller: srv6-epe-ruleを監視し，その変更内容を元にサーバのFIBを操作
    Kubernetes
    ③現在の状態を反映
    ①変更を検出
    spec:
    dst 2001:db8::/64
    sport 443
    sid 1::1 weight 1
    sid 2::2 weight 2 3
    server-name server1
    

    View Slide

30. コンテンツプロバイダAS（AS4690）
    重み: 3
    重み: 3
    コンテンツサーバ（live1.vsix.wide.ad.jp）からテストクライアントまでのパス
    ● BGPベストパス: AS β 経由
    ● 代替パス: AS α 経由
    32
    32
    実験: フィジビリティ検証
    AS β
    AS α
    BGP ベストパス
    代替パス
    ASBR 1
    EPEパス
    アグリゲータ
    ASBR 2
    DCN
    Contents
    Server
    Internet Test Client
    Egress Peer 1
    Egress Peer 2
    

    View Slide

31. ● コンテンツサーバはQoSメトリクスを収集
    ● BGPベストパス上に擬似障害が発生した場合に，FIBが変更するまでの時間を計測
    ○ 擬似障害の発生のため，tcコマンドを利用しトラフィックに遅延や帯域制限などを付与
    33
    33
    実験: フィジビリティ検証（詳細）
    コンテンツプロバイダAS（AS4690）
    BGP ベストパス
    代替パス
    tcコマンド
    で擬似障害
    QoSメトリクス監視
    FIB収束時間監視
    重み: 1
    重み: 3
    AS β
    AS α
    ASBR 1
    EPEパス
    アグリゲータ
    ASBR 2
    DCN
    Contents
    Server
    Internet Test Client
    Egress Peer 1
    Egress Peer 2
    

    View Slide

32. → RTT，スループット，ジッタ，パケットロス率，それらの複合でもフィジビリティ確認
    ● フィジビリティ検証として下記2点を検証
    1. 擬似障害が発生し，BGPベストパスの重みが小さくなるか
    2. 擬似障害が復旧し，BGPベストパスの重みが大きくなるか
    ● 以下のグラフは，BGPベストパスと代替パスにおけるRTTの時系列データ
    ○ ①とFIB変化①（②とFIB変化②）は共に1.12秒，1.57秒
    結果: フィジビリティ検証
    BGPベストパス
    代替パス
    擬似障害 →
    ←
    FIB 変化①
    ←
    FIB 変化②
    擬似障害復旧
    →
    ①
    ②
    重みが1
    重みが3
    34
    

    View Slide

33. まとめ - Our Activities
    ● EPEは意味があるのか？
    ○ EPEを利用して、実際のインターネットでの有効性を検証
    ■ (我々の環境では) コンテンツ配信のQoS向上に効果アリ
    ● EPEは運用可能なのか？
    ○ EPE運用に必要な要素・機能を整理
    ○ SDNによるEPEフレームワークを開発・構築・運用し、フィジビリティを検証
    ■ “COFFEE”でコンテンツ配信のQoS向上を目的としたEPEは運用可能！
    → ただ、まだ一般性に欠ける... 汎用C-Planeで実現した方が筋が良いかも？
    ■ フルルートは？ プロダクションルーターは？
    ■ 広く使える実装が欲しい ＆ 将来的には求める機能の実装がしたい！
    35
    EPEはコンテンツ配信のQoS向上に効果アリ！ 運用も可能！
    ただ、C-Planeの実装方法はもうちょっと考えたほうが良さそう.
    更なる活用を見据え、汎用C-Planeと拡張性の両立を目指す！
    

    View Slide

34. 3. GoBGP Implementation of BGP-LS EPE
    36
    

    View Slide

35. ● 必要なC-Planeの機能
    ○ 特定のEgress Peerに対応するSIDの広告
    ■ BGP-LS（RFC9086）
    ● RFC9086で提案されているが，実装はまだ発展途上
    ■ その他 (SDNで頑張る)
    (振り返り) C-Plane Requirements for EPE
    37
    Content
    Server
    ASBR
    Egress Peer 1
    Egress Peer 2
    EPE-SID 1::1
    for Peer 1
    EPE-SID 2::2
    for Peer 2
    SIDの広告
    DCN
    EPE SID
    の発行
    

    View Slide

36. ● 必要なC-Planeの機能
    ○ 特定のEgress Peerに対応するSIDの広告
    ■ BGP-LS（RFC9086）
    ● RFC9086で提案されているが，実装はまだ発展途上
    ■ その他 (SDNで頑張る)
    → OSSのBGP-LS実装は存在しない！ ならば自分たちで作ってみよう！
    (振り返り) C-Plane Requirements for EPE
    38
    EPE-SID 1::1
    for Peer 1
    EPE-SID 2::2
    for Peer 2
    SIDの広告 via BGP-LS
    EPEコントローラ
    EPE SID
    の発行
    Content
    Server
    ASBR
    Egress Peer 1
    Egress Peer 2
    DCN
    

    View Slide

37. What is GoBGP?
    ● Goで開発されたOSSのルーティングデーモン
    ○ 高い拡張性と豊富な機能
    ○ gRPCによるデータ連携
    ○ Zebraを介したカーネル経路との連携
    ● BGP-LS EPEの開発にあたり、下記のポイントを考慮しGoBGPを選定！
    ○ OSS: 自分たちが欲しい機能を拡張可能
    ○ Goへの理解: 先程のCOFFEEフレームワークもGoで開発 → 各自経験あり
    ○ BGP-LSの下地: IGP Link Stateについてはある程度開発済
    39
    https://github.com/osrg/gobgp
    

    View Slide

38. ● タスクを整理＆コミュニティへ共有！
    ○ 実施内容＆目標を明確化
    ○ 他の開発者とのタスク分離＆作業内容衝突の回避
    https://gobgp.slack.com
    BGP-EPEの実装に向けて
    40
    https://github.com/osrg/gobgp/issues/2616
    

    View Slide

39. ● まずは実装に向けた流れを整理。大きく分けて4ステップ
    ○ まずはSR-MPLSでStep2まで対応済
    ■ C-PlaneとgRPC APIを実装！
    ● vSIX EPE分科会の3名で開発合宿（各3日間）
    ○ 第1回: C-Plane implementation（RFC9086）
    ○ 第2回: gRPC API + Confederation
    いざ開発！
    41
    1. BGP-LS EPE extentionのTLV実装
    2. BGP-LSのgRPC対応
    3. BGP peer up/down に伴うEPE SIDの発行/削除
    4. FIB Install (Zebra APIの拡張)
    

    View Slide

40. GoBGPで新しいNLRI/PathAttrを作る流れ
    42
    データ型（構造体・Interface）を定義
    1
    ベンダ機器とのデータ送受信を確認
    2
    gRPC protoの拡張＆コンパイル
    3
    apiutilにUnmarshal/Marshalを実装
    4
    RFCから実装対象のPathAttr＆TLVを確認
    パケットもキャプチャしつつ、データ型＆Methodの正しさを検証
    まずはBGP RIBの確認が主目的。protoのコンパイルはREADME.mdの手順を参照
    gRPCデータと構造体・Interfaceとの送受信が可能に！
    パケットキャプチャを交えつつ動作を確認！
    5
    TLVの有無や、計算が必須なLength等のパラメータもチェック！
    Branch作成
    PR提出！
    

    View Slide

41. ● Cisco/Juniperと相互接続可能なBGP-LS EPEとgRPC APIを実装完了！
    ● GoBGPへのContribution
    ○ BGP-LS EPEはGoBGP v3.10.0以降、gRPC機能はv3.11.0以降でそれぞれ利用可能！
    ○ 迅速な Review＆Merge＆Release ありがとうございました🙏
    開発合宿の成果 🎉🎉
    43
    

    View Slide

42. ● (我々の成果物で) 皆様ができるようになったこと
    ○ 標準的なBGP-LSを利用してEPE-SIDのメッセージングが出来るようになりました！
    ■ 現在SR-MPLSのみ。SRv6はまた形式が異なるが...(現在wg-draft)
    ○ Cisco / JuniperとのInteroperability testにも成功しました！
    ○ (ついでに) BGP-LSの他の機能もgRPC経由で操作できるように。
    ● (開発をしてみて) 我々が成長したこと
    ○ GoBGPに新しい機能を実装するコツがわかりました！
    ■ 迅速なコミュニティ対応は開発の大きなモチベーションになりました！
    ○ EPEに関連する機能で、現在のRFC/I-D・他社ルータの出来ること・出来ないことを認識
    ■ SRv6-EPEにはまだまだ未確定の部分が多く課題が多い。
    44
    44
    まとめ - GoBGP Implementation of BGP-LS EPE
    GoBGPへのContributionを通じて、
    C-Planeの勘所を把握 & EPE用の汎用C-Planeを獲得！
    OSSへのコントリビューションって良いものですね
    

    View Slide

43. 4. Conclusion & Future Works
    45
    

    View Slide

44. ● vSIXでの研究＆開発＆運用の結果、EPEやSRv6の持つ可能性を検証＆提案
    ○ SRv6 EPEとE2E計測を利用し、EPEが有用であることを評価
    ■ 実環境においてASごとのBGP best pathの性能を測定
    ○ コンテンツ提供者ごとの要求に合わせたQoS/QoE向上を実現！
    ■ k8sを活用したSDNフレームワークを実装＆評価
    ● BGP-LS EPEを実装 & GoBGPへContribution！
    ○ 汎用的なプロトコルでの実装。研究成果が広く使われるための下地になることを期待
    ○ WGメンバーの開発能力＆プロトコルへの理解力向上
    46
    46
    EPE活用＆BGP-LS開発を通じて得られたこと
    今後もEPEの利便性を実証するとともに、誰もが使える世界を目指します！
    

    View Slide

45. 今後取り組むべき課題
    ● GoBGPへのさらなる機能追加
    ○ SR-MPLS Step3 & 4
    ○ SRv6実装
    ● C-Planeの整理
    ○ EPEのC-PlaneはEPE情報をどのように伝えるべきか
    ○ 例えば経路と紐づけて送ることで、より効率的な経路制御が可能になるのでは？
    ● どうやって「最適なパス」を探すかの方式検討
    ○ コンテンツサーバーでの運用戦略の検討
    ● 標準化？
    ○ 必要なデータ(Prefix + SID)をC-Planeとして送る仕組み
    ○ D-Planeの新たな用い方：End.DX6
    ● EPEの運用モデルのドキュメント化
    ○ 仲間探し！
    47
    

    View Slide

46. さらなる研究テーマ
    48
    以降は研究中の内容のため、会場のみでの公開とさせてください
    

    View Slide

47. WIDE Project vSIX WG
    www.vsix.wide.ad.jp
    Thank you for listening
    

    View Slide