要約

  • RFC 9692 は詳細なリンク状態を北へ、集約されたデフォルト経路を南へ送る。fallen leaf は、その集約が一部のプレーンで真ではなくなる例外である。
  • 正の非推移的な disaggregation は到達可能な親へトラフィックを引き寄せる。負の推移的な disaggregation は到達不能な親を候補から外し、プレーンを選ぶ入口リーフまで伝わり得る。
  • 負の Prefix TIE の受信、データベースの安定、RIB の計算結果は、ハードウェア FIB の反映やサービス到達の証明ではない。

正常時の圧縮は障害時の説明責任を増やす。RFC 9692 は 2025 年 4 月に公開された IETF Standards Track の文書で、Clos や fat-tree 向けの RIFT を定義する。North TIE は隣接関係とプレフィックスをスパイン側へ運ぶ。South TIE は通常、隣接情報と IPv4/IPv6 のデフォルト、必要な例外だけをリーフ側へ運ぶ。RFC の記録が示す通り、北向きはリンクステート、南向きは距離ベクトルに近い。

この設計で多数のエッジ機器が全プレフィックスを持たずに済む。しかし、接続欠損により一部の Top-of-Fabric ノードからしか到達できないリーフ、すなわち fallen leaf が生じると、デフォルトは均一な事実ではなくなる。複数プレーンでは入口リーフが早い段階でプレーンを選ぶため、例外はその選択点まで届かなければならない。

到達可能を足す方法と、到達不能を差し引く方法

正の disaggregation は、まだ対象プレフィックスへ到達できるルータが、より具体的な正の South Prefix TIE を広告する仕組みだ。longest-prefix match により、その親へトラフィックが集まる。これは非推移的で、受信した下位ノードが自動的にさらに南へ再広告するわけではない。到達可能な ToF 群が故障プレーンを覆う天井を形成できる場合には十分である。

負の disaggregation は逆に、その親からは対象へ行けないことを表す。負のプレフィックスは単独では動作せず、より短い正の集約プレフィックスの内側でだけ意味を持つ。集約から next hop を継承し、負を広告した親を削除する。RFC 9692 の抽象 RIB は負の経路と比較情報を保持する一方、FIB には削除後の正の転送命令が入る。

中間ノードが負を南へ伝える条件は厳しい。どの child も対象プレフィックスを広告せず、すべての parent が負を広告したときに限り、自らも負を生成する。どれか一つの parent が負を撤回すれば、推移的な広告も撤回しなければならない。

負が生じる契機は二つある。ToF は水平 ToF リンクを含む全 North Node TIE から得た完全な到達集合と、通常の southbound SPF を比較し、その差から fallen leaf を見つける。下位ノードではプレフィックスを付与する際、短い正の集約から継承したすべての候補が負の広告で除外されたことが契機になる。どちらも制御プレーンの判断であり、パケットの到着記録ではない。

一つの緑色ではなく、層ごとの記録

最初はリンクまたは隣接の検出である。RIFT は BFD を組み込める。RFC 5880 と RFC 5881 は高速な双方向障害検出を定めるが、影響を受けるリーフの全プレフィックスまでは確定しない。

次に Node/Prefix TIE の変化、プレーン間共有、fallen-leaf 計算、正負 disaggregate の発行と受信がある。その後に SPF/RIB の結果、各装置への実 FIB 反映が続く。RFC 9719 の RIFT YANG モデルは、インターフェース、隣接、TIE データベース、SPF 統計を観測できる。これは有用な運用状態だが、ハードウェア転送の完全な証明ではない。

さらにデータプレーンを通す必要がある。RFC 5357 の双方向アクティブ測定のような方法は、一つのプローブが一定時間に経験した経路を示す。入口リーフ、宛先プレフィックス、アドレスファミリ、ECMP ハッシュを変えて試すべきだ。それでも、すべての経路、負荷時の容量、アプリケーションの正常性までは保証しない。

RFC 9696 は、負の disaggregation に ToF の完全なプレフィックス知識が必要で、FIB の処理が再帰的かつ通常の経路より複雑になり得ると説明する。また ECMP だけでは配信や遅延上限を保証しない。これは適用・運用上の指針であり、特定製品の実績ではない。

現在の RFC 9692 errata には、7.2 節で欠けた Thrift 内容に関する更新保留の技術訂正がある。fallen-leaf の手順を変更するものではない。

Heng Lu の動くコードの優先、最小初期仕様、現実の層は、仕様、実装、観測結果を分けるための編集上の視点である。IETF 要件でも、RIFT 配備の証拠でもない。

したがって、妥当な結論は限定的だ。RFC 9692 は広すぎる default を修復する手段を定める。運用上の完了は、障害検出、TIE 伝搬、計算、FIB 反映、プローブ、サービス到達を別々に確認し、回復時の撤回でも同じ連鎖を確認した後である。