SlideShare a Scribd company logo
1 of 19
Download to read offline
R I F T
A NEW ROUTING PROTOCOL FOR IP FABRICS
Masayuki Kobayashi@LINE Corporation
May 2, 2018
Disclaimer
• 本資料の内容は2018年4月28日時点の情報に基づいています
• draft-ietf-rift-rift-01
• 将来にわたり情報・仕様が更新される可能性があります
CLOS Architecture
• Web Scale Data Center時代のスタンダード
• 水平方向への高いスケーラビリティ
• BGP ECMP(RFC7938)
• ポリシーに基づくTE
• リンク検出とトポロジー自動構築の未実装
• ルーティング情報の増大と非効率化
• プロトコルレベルでのZTPの未サポート
• 障害発生時のprefix自動分離の未実装
Web Scaleの展開速度に適合するDC Routingとは?
引⽤:https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/
CLOS Architecture
• Web Scale Data Center時代のスタンダード
• 水平方向への高いスケーラビリティ
• BGP ECMP(RFC7938)
• ポリシーに基づくTE
• リンク、隣接関係の自動検証機能の不足
• ルーティングテーブルの肥大化
• コンバージェンス速度の低下
• 障害リンクの自動切り離し
Path/Distance VectorとLink Stateそれぞれの利点を持つ
CLOSアンダーレイ⽤の新しいダイナミックルーティングプロトコルの開発
Link State(SPF)による分散処理の利点
Distributed Computation
Vector型ルーティングプロトコルの利点
Diffused Computation
RIFT overview
https://datatracker.ietf.org/doc/draft-ietf-rift-rift/
Routing in Fat Trees
RIFT
• ネットワークトポロジーをNorthbound(北方向)とSouthbound(南方向)で表現
• Node, Prefix, Policy, Key-Valueの情報をTopology Information Element(TIE)として交換
• Northbound(Leaf → Spine方向)はLink State情報を広報
• Southbound(Spine → Leaf方向)はDistance/Path Vector型のように伝搬
• North/Southで異なるフラッディングメカニズムを採⽤
• 最上位レベルのSpineのみがネットワーク全体の完全なトポロジーを把握
• 通常は上位レベルのノードがSouthboundへデフォルトルートのみ広報
• 各階層(Level)毎のルーティングテーブルの最小化とブラックホールの防止
• ノード・リンク障害時にmore specific経路を広報することでprefixをAuto Disaggregation
情報を広報する方向によって、各ノードが異なるデータベースを保持する
Distance Vector と Link State それぞれの利点を持つルーティングプロトコル
General concept
Leaf111 Leaf112 Leaf121
Node111 Node112 Node121 Node122
Leaf122
Spine21 Spine22
Prefix111 Prefix112 Prefix121 Prefix122
Northbound
Southbound
• Link State情報を
フラッディング
• トポロジーを把握
するのに必要な情
報が含まれる
• 上位のノードは配
下のトポロジーを
把握する
• 情報がDistance Vector
型のように伝搬
• 隣接関係の効率化のた
めにフラッディングも
使⽤
• 通常はデフォルトルー
トとPGPを広報
• 障害発生時に特定経路
を広報
Leaf -> Spine Spine -> Leaf
PGP = Policy-Guided Prefixes
2-Level spine-and-leaf topology
General concept
• 階層をLevelで表現≒Stage
• PoD,Level,NodeをLIEで識別
• LIE交換でNeighborを検出
• LIE交換後にTIEを交換
• LIE/TIEは全RIFTノードで交換
• TIEには方向とタイプが存在
Leaf111 Leaf112 Leaf121
Node111 Node112 Node121 Node122
Leaf122
Spine21 Spine22
Prefix111 Prefix112 Prefix121 Prefix122
P O D # 1 P O D # 2
L E V E L 0
L E V E L 1
L E V E L 2
Neighbor Discovery
• Link Information Element(LIE)
• すべてのRIFTノードが交換するIGP Helloメッセージ相当
• IPv4 multicast or IPv6 link-local multicast scope w/ UDP
• PoD Number:
• 0はSpine
• 一致しないノードとは隣接関係にならない
• Level Number:
• 0はLeaf(ToR)
• Node-ID:
• 64bitのRIFTドメインでユニークな値
• TTLは1(例外は破棄)
Topology Information Element(TIE)
• ノードや隣接関係、PrefixなどのRIFTネットワークを定義するための要素
• LIE交換で学習したI/Fを通じてすべてのRIFTノードで交換される
• NorthboundとSouthboundの2つの方向がある
• TIEを広報する方向に応じて異なるデータベースを持つ
Northbound-TIE (N-TIE)
• 上位レベルのノードに広報されるTIE
• Node, Prefix, PGP, Key-Valueのタイプがある
• ノードの隣接関係とすべてのprefixを広報
• 上位レベルにトポロジー情報を提供
Southbound-TIE (S-TIE)
• 下位レベルのノードに広報されるTIE
• Node, Prefix, PGP, Key-Valueのタイプがある
• ノードの隣接関係とデフォルトルートを広報
• Disaggregated prefixで障害時の到達性を確保
South & Northbound TIEs
Leaf111 Leaf112 Leaf121
Node111 Node112 Node121 Node122
Leaf122
Spine21 Spine22
Prefix111 Prefix112 Prefix121 Prefix122
Leaf 111 N-TIEs:
Node N-TIE:
Neighbor: N111, N112
Prefix N-TIE:
L111.loopback, Pfx112
Spine 22 S-TIEs:
Node S-TIE:
Neighbor: N111, N112,
N121, N122
Prefix S-TIE:
0/0, ::/0 (self-originated)
Node 111 N-TIEs:
Node N-TIE:
Neighbor: S21, S22,
L111, L112
Prefix N-TIE:
N111.loopback
Node 122 S-TIEs:
Node S-TIE:
Neighbor: S21, S22,
L121, L122
Prefix S-TIE:
0/0, ::/0 (self-originated)
※ PGP, Key-Value TIE については本資料では詳細は割愛します
Routing Information
• Spine 2[12]
• Prefix 111 → Node 111 or Node 112
• Prefix 112 → Node 111 or Node 112
• Prefix 121 → Node 121 or Node 122
• Prefix 122 → Node 121 or Node 122
• Node 11[12]
• 0.0.0.0/0 → Spine 21 or Spine 22
• Prefix 111 → Leaf 111
• Prefix 112 → Leaf 112
• Node 12[12]
• 0.0.0.0/0 → Spine 21 or Spine 22
• Prefix 121 → Leaf 121
• Prefix 122 → Leaf 122
• Leaves
• 0.0.0.0/0 → Connected Level1 Node
Leaf111 Leaf112 Leaf121
Node111 Node112 Node121 Node122
Leaf122
Spine21 Spine22
Prefix111 Prefix112 Prefix121 Prefix122
TIE-Type vs Peer Direction
Direction TIE-Type Content & Flooding Scope
North
(N-TIE)
Node
• ノード、リンク、隣接関係などのトポロジー情報
• 常にNorthboundに対してフラッディングする
• Southboundには決してフラッディングしない
Prefix
• 自身と配下のノードの経路情報とメトリック
• 常にNorthboundに対してフラッディングする
• Southboundには決してフラッディングしない
South
(S-TIE)
Node
• ノード、リンク、隣接関係などのトポロジー情報
• 自身が生成したTIEのみSouthboundに対してフラッディングする
• 全てのNorthboundにリフレクトする
Prefix
• デフォルトルートと特定経路およびメトリック
• 自身が生成したTIEのみSouthboundに対してフラッディングする
Automatic disaggregation of prefixes
1. リンク障害で赤色のリンクがlost
• Spine 21経由でNode 12[12]と通信するルートが失われる
• Prefix 12[12]宛の通信にloss/black holeが発生する可能性
2. Spine 21はS-TIEをアップデート
• Node 12[12]のNeighbor情報を削除
3. Spine 21のS-TIEがNode11[12]でReflect
4. Spine 22はSpine 21とNode 12[12]間のリンクが
lostしたことを検知
5. Spine 22はPrefix 12[12]のmore specific routeを
新たなS-TIEで広報
6. Node 11[12]は0/0に加えてmore specific routeを
学習する
7. Prefix 12[12]宛の通信はSpine 22経由に変更
8. Spine-Node間のルーティングアップデートのみで
障害を分離することができ、Node-Leaf間は変わ
らずに0/0のみでルーティングされている
Leaf111 Leaf112 Leaf121
Node111 Node112 Node121 Node122
Leaf122
Spine21 Spine22
Prefix111 Prefix112 Prefix121 Prefix122
S-TIE Reflection
0.0.0.0/0 → Spine 21 or Spine 22
Prefix 111 → Leaf 111
Prefix 112 → Leaf 112
Prefix 121 → Spine 22
Prefix 122 → Spine 22
RIFT Advantages
Neighbor・Topologyの自動検出
ルーティング情報の最小化
より高速なコンバージェンス
フラッディング情報の削減
Key-Value Store
Automatic disaggregation
Reduced
flooding
Automatic
detection
Automatic
disaggregation
Minimal
routes
Fast
convergence
Key-Value
Store
RIFT Only AdvantagesExisting Advantages
https://www.juniper.net/us/en/dm/free-rift-trial/
Implementations
Expected to Implementation
• TIE Transport on QUIC
• Fabric Bandwidth Balancing
• Segment Routing Support
• etc.
R I F T
THANK YOU

More Related Content

Similar to RIFT A new routing protocol for IP fabrics

RouterBOARD with OpenFlow
RouterBOARD with OpenFlowRouterBOARD with OpenFlow
RouterBOARD with OpenFlowToshiki Tsuboi
 
20131211 Neutron Havana
20131211 Neutron Havana20131211 Neutron Havana
20131211 Neutron HavanaAkihiro Motoki
 
HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26
HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26
HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26Takashi Yamanoue
 
Lagopus Switch Usecases
Lagopus Switch UsecasesLagopus Switch Usecases
Lagopus Switch UsecasesSakiko Kawai
 
Packet と向き合う夏 VRRP Advertisement編
Packet と向き合う夏 VRRP Advertisement編Packet と向き合う夏 VRRP Advertisement編
Packet と向き合う夏 VRRP Advertisement編@ otsuka752
 
MAP 実装してみた
MAP 実装してみたMAP 実装してみた
MAP 実装してみたMasakazu Asama
 
IETF102 Report Authorization
IETF102 Report AuthorizationIETF102 Report Authorization
IETF102 Report AuthorizationKaoru Maeda
 
CEDEC-Net 2015 テクニカルレビュー
CEDEC-Net 2015 テクニカルレビューCEDEC-Net 2015 テクニカルレビュー
CEDEC-Net 2015 テクニカルレビューYuya Rin
 
SAS Visual Analytics 6.3 を使った DELL VRTX の評価
SAS Visual Analytics 6.3 を使った DELL VRTX の評価SAS Visual Analytics 6.3 を使った DELL VRTX の評価
SAS Visual Analytics 6.3 を使った DELL VRTX の評価Dell TechCenter Japan
 
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)NTT DATA Technology & Innovation
 
VPP事始め
VPP事始めVPP事始め
VPP事始めnpsg
 
Lagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそばLagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそばYoshihiro Nakajima
 
『どうする?どうやる? データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29
『どうする?どうやる?  データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29『どうする?どうやる?  データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29
『どうする?どうやる? データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29Yukihiro Kikuchi
 
Tremaで構築!中小企業の社内LAN #Tremaday 120419
Tremaで構築!中小企業の社内LAN #Tremaday 120419Tremaで構築!中小企業の社内LAN #Tremaday 120419
Tremaで構築!中小企業の社内LAN #Tremaday 120419エイシュン コンドウ
 
SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...
SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...
SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...Miya Kohno
 
OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月
OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月
OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月VirtualTech Japan Inc.
 
20150715 xflow kikuta_final
20150715 xflow kikuta_final20150715 xflow kikuta_final
20150715 xflow kikuta_finalKazumasa Ikuta
 
SAP Applicationのソース・エンドポイントとしての利用
SAP Applicationのソース・エンドポイントとしての利用SAP Applicationのソース・エンドポイントとしての利用
SAP Applicationのソース・エンドポイントとしての利用QlikPresalesJapan
 

Similar to RIFT A new routing protocol for IP fabrics (20)

HTTP/2.0と標準化
HTTP/2.0と標準化HTTP/2.0と標準化
HTTP/2.0と標準化
 
RouterBOARD with OpenFlow
RouterBOARD with OpenFlowRouterBOARD with OpenFlow
RouterBOARD with OpenFlow
 
20131211 Neutron Havana
20131211 Neutron Havana20131211 Neutron Havana
20131211 Neutron Havana
 
HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26
HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26
HTML5 技術を利用した授業や会議向けデスクトップ画面実時間配信システムとその管理システムの試作, 情報処理学会IOT研究会26
 
Lagopus Switch Usecases
Lagopus Switch UsecasesLagopus Switch Usecases
Lagopus Switch Usecases
 
Packet と向き合う夏 VRRP Advertisement編
Packet と向き合う夏 VRRP Advertisement編Packet と向き合う夏 VRRP Advertisement編
Packet と向き合う夏 VRRP Advertisement編
 
MAP 実装してみた
MAP 実装してみたMAP 実装してみた
MAP 実装してみた
 
IETF102 Report Authorization
IETF102 Report AuthorizationIETF102 Report Authorization
IETF102 Report Authorization
 
CEDEC-Net 2015 テクニカルレビュー
CEDEC-Net 2015 テクニカルレビューCEDEC-Net 2015 テクニカルレビュー
CEDEC-Net 2015 テクニカルレビュー
 
SAS Visual Analytics 6.3 を使った DELL VRTX の評価
SAS Visual Analytics 6.3 を使った DELL VRTX の評価SAS Visual Analytics 6.3 を使った DELL VRTX の評価
SAS Visual Analytics 6.3 を使った DELL VRTX の評価
 
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
 
VPP事始め
VPP事始めVPP事始め
VPP事始め
 
Lagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそばLagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそば
 
『どうする?どうやる? データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29
『どうする?どうやる?  データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29『どうする?どうやる?  データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29
『どうする?どうやる? データセンター間ネット ワーク』 - 802.1aq(SPB)/TRILL@JANOG29
 
Tremaで構築!中小企業の社内LAN #Tremaday 120419
Tremaで構築!中小企業の社内LAN #Tremaday 120419Tremaで構築!中小企業の社内LAN #Tremaday 120419
Tremaで構築!中小企業の社内LAN #Tremaday 120419
 
SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...
SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...
SRv6 Network Programmability - Dis-aggregation and Re-aggregation of Network ...
 
OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月
OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月
OpenStackネットワーキング管理者入門 - OpenStack最新情報セミナー 2014年8月
 
Protocol2018
Protocol2018Protocol2018
Protocol2018
 
20150715 xflow kikuta_final
20150715 xflow kikuta_final20150715 xflow kikuta_final
20150715 xflow kikuta_final
 
SAP Applicationのソース・エンドポイントとしての利用
SAP Applicationのソース・エンドポイントとしての利用SAP Applicationのソース・エンドポイントとしての利用
SAP Applicationのソース・エンドポイントとしての利用
 

Recently uploaded

20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 

Recently uploaded (12)

20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 

RIFT A new routing protocol for IP fabrics

  • 1. R I F T A NEW ROUTING PROTOCOL FOR IP FABRICS Masayuki Kobayashi@LINE Corporation May 2, 2018
  • 3. CLOS Architecture • Web Scale Data Center時代のスタンダード • 水平方向への高いスケーラビリティ • BGP ECMP(RFC7938) • ポリシーに基づくTE • リンク検出とトポロジー自動構築の未実装 • ルーティング情報の増大と非効率化 • プロトコルレベルでのZTPの未サポート • 障害発生時のprefix自動分離の未実装 Web Scaleの展開速度に適合するDC Routingとは? 引⽤:https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/
  • 4. CLOS Architecture • Web Scale Data Center時代のスタンダード • 水平方向への高いスケーラビリティ • BGP ECMP(RFC7938) • ポリシーに基づくTE • リンク、隣接関係の自動検証機能の不足 • ルーティングテーブルの肥大化 • コンバージェンス速度の低下 • 障害リンクの自動切り離し Path/Distance VectorとLink Stateそれぞれの利点を持つ CLOSアンダーレイ⽤の新しいダイナミックルーティングプロトコルの開発 Link State(SPF)による分散処理の利点 Distributed Computation Vector型ルーティングプロトコルの利点 Diffused Computation
  • 7. RIFT • ネットワークトポロジーをNorthbound(北方向)とSouthbound(南方向)で表現 • Node, Prefix, Policy, Key-Valueの情報をTopology Information Element(TIE)として交換 • Northbound(Leaf → Spine方向)はLink State情報を広報 • Southbound(Spine → Leaf方向)はDistance/Path Vector型のように伝搬 • North/Southで異なるフラッディングメカニズムを採⽤ • 最上位レベルのSpineのみがネットワーク全体の完全なトポロジーを把握 • 通常は上位レベルのノードがSouthboundへデフォルトルートのみ広報 • 各階層(Level)毎のルーティングテーブルの最小化とブラックホールの防止 • ノード・リンク障害時にmore specific経路を広報することでprefixをAuto Disaggregation 情報を広報する方向によって、各ノードが異なるデータベースを保持する Distance Vector と Link State それぞれの利点を持つルーティングプロトコル
  • 8. General concept Leaf111 Leaf112 Leaf121 Node111 Node112 Node121 Node122 Leaf122 Spine21 Spine22 Prefix111 Prefix112 Prefix121 Prefix122 Northbound Southbound • Link State情報を フラッディング • トポロジーを把握 するのに必要な情 報が含まれる • 上位のノードは配 下のトポロジーを 把握する • 情報がDistance Vector 型のように伝搬 • 隣接関係の効率化のた めにフラッディングも 使⽤ • 通常はデフォルトルー トとPGPを広報 • 障害発生時に特定経路 を広報 Leaf -> Spine Spine -> Leaf PGP = Policy-Guided Prefixes 2-Level spine-and-leaf topology
  • 9. General concept • 階層をLevelで表現≒Stage • PoD,Level,NodeをLIEで識別 • LIE交換でNeighborを検出 • LIE交換後にTIEを交換 • LIE/TIEは全RIFTノードで交換 • TIEには方向とタイプが存在 Leaf111 Leaf112 Leaf121 Node111 Node112 Node121 Node122 Leaf122 Spine21 Spine22 Prefix111 Prefix112 Prefix121 Prefix122 P O D # 1 P O D # 2 L E V E L 0 L E V E L 1 L E V E L 2
  • 10. Neighbor Discovery • Link Information Element(LIE) • すべてのRIFTノードが交換するIGP Helloメッセージ相当 • IPv4 multicast or IPv6 link-local multicast scope w/ UDP • PoD Number: • 0はSpine • 一致しないノードとは隣接関係にならない • Level Number: • 0はLeaf(ToR) • Node-ID: • 64bitのRIFTドメインでユニークな値 • TTLは1(例外は破棄)
  • 11. Topology Information Element(TIE) • ノードや隣接関係、PrefixなどのRIFTネットワークを定義するための要素 • LIE交換で学習したI/Fを通じてすべてのRIFTノードで交換される • NorthboundとSouthboundの2つの方向がある • TIEを広報する方向に応じて異なるデータベースを持つ Northbound-TIE (N-TIE) • 上位レベルのノードに広報されるTIE • Node, Prefix, PGP, Key-Valueのタイプがある • ノードの隣接関係とすべてのprefixを広報 • 上位レベルにトポロジー情報を提供 Southbound-TIE (S-TIE) • 下位レベルのノードに広報されるTIE • Node, Prefix, PGP, Key-Valueのタイプがある • ノードの隣接関係とデフォルトルートを広報 • Disaggregated prefixで障害時の到達性を確保
  • 12. South & Northbound TIEs Leaf111 Leaf112 Leaf121 Node111 Node112 Node121 Node122 Leaf122 Spine21 Spine22 Prefix111 Prefix112 Prefix121 Prefix122 Leaf 111 N-TIEs: Node N-TIE: Neighbor: N111, N112 Prefix N-TIE: L111.loopback, Pfx112 Spine 22 S-TIEs: Node S-TIE: Neighbor: N111, N112, N121, N122 Prefix S-TIE: 0/0, ::/0 (self-originated) Node 111 N-TIEs: Node N-TIE: Neighbor: S21, S22, L111, L112 Prefix N-TIE: N111.loopback Node 122 S-TIEs: Node S-TIE: Neighbor: S21, S22, L121, L122 Prefix S-TIE: 0/0, ::/0 (self-originated) ※ PGP, Key-Value TIE については本資料では詳細は割愛します
  • 13. Routing Information • Spine 2[12] • Prefix 111 → Node 111 or Node 112 • Prefix 112 → Node 111 or Node 112 • Prefix 121 → Node 121 or Node 122 • Prefix 122 → Node 121 or Node 122 • Node 11[12] • 0.0.0.0/0 → Spine 21 or Spine 22 • Prefix 111 → Leaf 111 • Prefix 112 → Leaf 112 • Node 12[12] • 0.0.0.0/0 → Spine 21 or Spine 22 • Prefix 121 → Leaf 121 • Prefix 122 → Leaf 122 • Leaves • 0.0.0.0/0 → Connected Level1 Node Leaf111 Leaf112 Leaf121 Node111 Node112 Node121 Node122 Leaf122 Spine21 Spine22 Prefix111 Prefix112 Prefix121 Prefix122
  • 14. TIE-Type vs Peer Direction Direction TIE-Type Content & Flooding Scope North (N-TIE) Node • ノード、リンク、隣接関係などのトポロジー情報 • 常にNorthboundに対してフラッディングする • Southboundには決してフラッディングしない Prefix • 自身と配下のノードの経路情報とメトリック • 常にNorthboundに対してフラッディングする • Southboundには決してフラッディングしない South (S-TIE) Node • ノード、リンク、隣接関係などのトポロジー情報 • 自身が生成したTIEのみSouthboundに対してフラッディングする • 全てのNorthboundにリフレクトする Prefix • デフォルトルートと特定経路およびメトリック • 自身が生成したTIEのみSouthboundに対してフラッディングする
  • 15. Automatic disaggregation of prefixes 1. リンク障害で赤色のリンクがlost • Spine 21経由でNode 12[12]と通信するルートが失われる • Prefix 12[12]宛の通信にloss/black holeが発生する可能性 2. Spine 21はS-TIEをアップデート • Node 12[12]のNeighbor情報を削除 3. Spine 21のS-TIEがNode11[12]でReflect 4. Spine 22はSpine 21とNode 12[12]間のリンクが lostしたことを検知 5. Spine 22はPrefix 12[12]のmore specific routeを 新たなS-TIEで広報 6. Node 11[12]は0/0に加えてmore specific routeを 学習する 7. Prefix 12[12]宛の通信はSpine 22経由に変更 8. Spine-Node間のルーティングアップデートのみで 障害を分離することができ、Node-Leaf間は変わ らずに0/0のみでルーティングされている Leaf111 Leaf112 Leaf121 Node111 Node112 Node121 Node122 Leaf122 Spine21 Spine22 Prefix111 Prefix112 Prefix121 Prefix122 S-TIE Reflection 0.0.0.0/0 → Spine 21 or Spine 22 Prefix 111 → Leaf 111 Prefix 112 → Leaf 112 Prefix 121 → Spine 22 Prefix 122 → Spine 22
  • 16. RIFT Advantages Neighbor・Topologyの自動検出 ルーティング情報の最小化 より高速なコンバージェンス フラッディング情報の削減 Key-Value Store Automatic disaggregation Reduced flooding Automatic detection Automatic disaggregation Minimal routes Fast convergence Key-Value Store RIFT Only AdvantagesExisting Advantages
  • 18. Expected to Implementation • TIE Transport on QUIC • Fabric Bandwidth Balancing • Segment Routing Support • etc.
  • 19. R I F T THANK YOU