要約

  • RFC 5283 は、具体的な FEC を包含する RIB エントリがあり、ラベルを広告した隣接 LSR がその次ホップなら、そのラベルを利用できるとする。上流へ再広告されるのは集約ではなく元の具体的 FEC である。
  • この状態が証明するのは一ノードの制御面判断だけだ。全区間の対応能力、出口 LER の現在性、Withdraw の収束、LFIB 実装、パケット配送、サービス結果には別の観測が要る。

/32 が RIB から消えることが目的だった

従来の LDP は Prefix FEC と RIB の完全一致を前提にしやすい。複数エリアをまたぐ LSP を作るには、各 PE の loopback を全エリアへ漏らす必要があった。これではエリア分割が削減するはずの LSDB、RIB、FIB が再び増える。

RFC 5283 は FEC の名前を丸めず、検索規則だけを変える。/32 FEC は、それを含む /24 を利用できる。さらに、ラベル広告元がその /32 へ向かう RIB 次ホップでなければならない。FEC が RIB エントリより広い場合は一致しない。

LDP が再広告するのは /32 のままである。ラベルの粒度は個別出口、IP の根拠は集合である。この二重性を一つの reachability 状態に潰すと、運用上の誤読が始まる。

集約は方向を示し、構成員を点呼しない

/24 は一つの /32 が失われても有効であり得る。他の出口が同じ境界の先に残るからだ。集約は集合の送り先を示すが、全構成員の生存表ではない。

longest match の判断もローカルである。自分の RIB、次ホップ、LDP 隣接を検査するだけで、遠端 LER を probe せず、下流の LFIB や顧客トラフィックを観測しない。

具体的な FEC 名は強い断定に見える。だが、それを支える経路証拠は意図的に広い。UI と監査記録は FEC とカバーする RIB エントリを並べ、観測者と世代を別々に示すべきである。

互換性は途中の穴を埋めない

この手順は任意で、設定により有効化し、既定では無効にすべきものだ。旧 LSR は安全に共存できても、集約下の FEC を継続して伝播できない。

集約を使うエリアでは、関連経路上の全 LSR が手順を理解しなければならない。未対応ノードに到達すると、出口から始まった LSP はそこで止まる。副作用がないことと、端から端まで完成していることは別である。

入口にラベルがあるという観測は、その入口までチェーンが届いた証拠にはなる。別の等コスト経路や障害時経路まで対応しているとは限らない。能力台帳はノード、エリア、prefix、実際の経路に結合する必要がある。

切替前には二つの根拠を残す

段階導入では、全 LSR の更新を確認するまで ABR が具体的ルートを広告し続ける。確認後に初めて、具体項を取り除き、集約だけにできる。

切替前は旧ノードが完全一致を使い、新ノードは longest match も使える。切替後は、未対応ノードが一台でも残れば FEC の根拠を失う。早すぎる整理は、資産情報の漏れを LSP 断に変える。

切替 receipt は対象エリア、全 LSR、バージョン、feature 状態、prefix ごとの有効化、最後の具体ルート世代、最初の集約のみの世代、FEC マッピング、LFIB と packet test を記録する。変更作業の完了票だけでは足りない。

一つの RIB 変化が多数の FEC を動かす

一つの集約に複数の具体 FEC が依存する。その prefix が現れる、消える、次ホップを変えるたび、包含される全 FEC を再評価しなければならない。

より具体的な route が追加されると、一部の FEC だけが新しい次ホップへ移ることがある。FEC 名は変わらず、NHLFE が変わる。ラベルの作成・削除だけを数える監視はこの rebinding を見落とす。

RIB 世代、カバー prefix、依存 FEC 集合、隣接、受信 label、ローカル label、NHLFE、hardware acknowledgement を一つのグラフで結ぶ必要がある。

FIB の削減は LFIB の削減ではない

RFC 5283 は LSDB と IP FIB を小さくする。一方、個別 LSP の LFIB エントリ数は減らないと明記する。IP の要約は label state 全体の要約ではない。

容量報告はテーブル名を持つべきだ。SPF、RIB、FIB、LIB、LFIB は異なる資源と更新時間を持つ。「経路が減った」という一語では、負荷が消えたのか移動したのか分からない。

収束も同じである。SPF 完了、依存 FEC の再計算、LFIB programming、packet recovery は別々に計時する。

出口 LER 障害だけは集約が残り得る

link、transit router、ABR の障害は通常の挙動を保つ。出口 LER 障害は特別で、出口が消えてもその所属する集約経路は残り得る。

具体的な不可達性は LDP ordered control により Label Withdraw として上流へ戻る。伝播時間は IGP と同程度が期待されるが、実装依存である。MP-BGP や L3VPN がそれをどう利用するかは RFC の範囲外だ。

したがって、集約が green、上流 label がまだ存在、出口は既に down という時間窓が成立する。それぞれが異なる対象と時計を観測している。aggregate 状態で specific alarm を打ち消してはならない。

control-plane 専用の specific reachability、ordered withdraw、edge の BFD は追加証拠になるが、集約 route 自身の保証ではない。

最後はデータ面が閉じる

制御チェーンが揃っても、LFIB 実装、正しい NHLFE、エリア横断 packet、VPN context、egress、return path、application を確認する必要がある。LDP LSP は service receipt ではない。

probe は再現した条件だけを証明する。infrastructure loopback への ping は、別 VRF や service class の顧客フローを代弁しない。

記録は「aggregate 有り、local FEC 有り、remote capability 不明、withdraw 伝播中、hardware 未確認、return 無し」と途中で止まれるべきだ。状態を分けるほど、修復責任も明確になる。

二つの粒度で receipt を組む

  • FEC、address family、egress LER
  • 候補 RIB entry と選ばれた longest match
  • RIB 世代、metric、next hop、広告隣接
  • ノード能力と prefix ごとの activation
  • received/local/advertised label と時刻
  • 集約ごとの dependent FEC set
  • NHLFE、LFIB、hardware acknowledgement
  • 通過 area と ABR
  • specific から aggregate への migration 段階
  • Label Withdraw の起点と進行
  • BFD または control-only reachability
  • 上位 application の反応
  • 双方向 packet 観測
  • 公開主張が要求する service outcome

二つの粒度を協調させることが RFC 5283 の価値である。二つを同じ証拠として扱わないことが運用の責任になる。

Sources