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
510
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
8
790
クラウドデータセンターネットワークの “いま”と “これから”
markunet
8
2.4k
HPCネットワーク基礎(RDMA/Infiniband/RoCE編)
markunet
38
5.1k
Clos Network Topology 再入門
markunet
23
7.6k
大規模DCのネットワークデザイン
markunet
4
1.3k
閉域網接続の技術入門
markunet
1
330
Other Decks in Technology
See All in Technology
【CEDEC+KYUSHU2025】学生・若手必見!テクニカルアーティスト 大全 ~仕事・スキル・キャリアパス、TAの「わからない」を徹底解剖~
cygames
PRO
0
150
AI 駆動開発勉強会 フロントエンド支部 #1 w/あずもば
1ftseabass
PRO
0
210
「Managed Instances」と「durable functions」で広がるAWS Lambdaのユースケース
lamaglama39
0
280
Oracle Technology Night #95 GoldenGate 26ai の実装に迫る1
oracle4engineer
PRO
0
150
チーリンについて
hirotomotaguchi
3
830
生成AI時代の自動E2Eテスト運用とPlaywright実践知_引持力哉
legalontechnologies
PRO
0
210
Debugging Edge AI on Zephyr and Lessons Learned
iotengineer22
0
120
Kiro Autonomous AgentとKiro Powers の紹介 / kiro-autonomous-agent-and-powers
tomoki10
0
320
エンジニアリングマネージャー はじめての目標設定と評価
halkt
0
250
Security Diaries of an Open Source IAM
ahus1
0
130
MapKitとオープンデータで実現する地図情報の拡張と可視化
zozotech
PRO
1
120
Sansanが実践する Platform EngineeringとSREの協創
sansantech
PRO
2
660
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.3k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.7k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
390
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
970
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.8k
Music & Morning Musume
bryan
46
7k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
GraphQLとの向き合い方2022年版
quramy
50
14k
Testing 201, or: Great Expectations
jmmastey
46
7.8k
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