Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RIFT A new routing protocol for IP fabrics
Search
Masayuki Kobayashi
May 03, 2018
Technology
0
520
RIFT A new routing protocol for IP fabrics
Routing In Fat Trees(RIFT) Overview
Masayuki Kobayashi
May 03, 2018
Tweet
Share
More Decks by Masayuki Kobayashi
See All by Masayuki Kobayashi
AIインフラを考える
markunet
7
3.3k
GPUネットワーク設計・運用 基礎勉強会 Lossless Ethernet – PFC/ECN編
markunet
9
820
クラウドデータセンターネットワークの “いま”と “これから”
markunet
8
2.4k
HPCネットワーク基礎(RDMA/Infiniband/RoCE編)
markunet
38
5.1k
Clos Network Topology 再入門
markunet
23
7.6k
大規模DCのネットワークデザイン
markunet
4
1.4k
閉域網接続の技術入門
markunet
1
340
Other Decks in Technology
See All in Technology
ペアーズにおけるAIエージェント 基盤とText to SQLツールの紹介
hisamouna
2
1.3k
AgentCoreとStrandsで社内d払いナレッジボットを作った話
motojimayu
1
570
NIKKEI Tech Talk #41: セキュア・バイ・デザインからクラウド管理を考える
sekido
PRO
0
190
ExpoのインダストリーブースでみたAWSが見せる製造業の未来
hamadakoji
0
180
Agent Skillsがハーネスの垣根を超える日
gotalab555
5
2.8k
意外と知らない状態遷移テストの世界
nihonbuson
PRO
1
130
Power of Kiro : あなたの㌔はパワステ搭載ですか?
r3_yamauchi
PRO
0
200
Databricks向けJupyter Kernelでデータサイエンティストの開発環境をAI-Readyにする / Data+AI World Tour Tokyo After Party
genda
1
630
IAMユーザーゼロの運用は果たして可能なのか
yama3133
2
520
SREには開発組織全体で向き合う
koh_naga
0
400
AIBuildersDay_track_A_iidaxs
iidaxs
3
910
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9.8k
Featured
See All Featured
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
57
37k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.6k
エンジニアに許された特別な時間の終わり
watany
105
220k
[SF Ruby Conf 2025] Rails X
palkan
0
550
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Writing Fast Ruby
sferik
630
62k
Optimizing for Happiness
mojombo
379
70k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
1.9k
How to Think Like a Performance Engineer
csswizardry
28
2.4k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.1k
The untapped power of vector embeddings
frankvandijk
1
1.5k
Transcript
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 Advantages Existing 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