要約

  • RFC 9985はBFDの重要な状態変化をMCIで扱い、変化しないUpパケットの大半にLCIを許す。
  • その認証結果は一つのBFDセッションの根拠であり、より広いネットワーク行為の権限ではない。

これは強弱ではなく処理負荷の分担だ

MCIとLCIを単純に「強い」「弱い」と呼ぶと、RFCの意図を失う。RFC 9985は両者を実装への計算的影響で区別する。BFDは多数のセッションを短い検出時間で扱うため、すべてのパケットに同じ重い処理を課すと、検出能力そのものが損なわれ得る。

そこでAdminDown、Down、InitはMCIを必須とし、状態、Demandビット、Poll/Final、所定のパラメータの変化も重要な変化として扱う。すでにUpのパケットがLCIを使う場合、認証部以外の内容を変えてはならない。安価な継続パケットは、到達済みの状態を維持するだけで、新しい意味を持ち込めない。

観測できる範囲はBFDの封装まで

RFC 5880でBFDが検出するのは、転送面の次ホップとの通信であり、各セッションはその封装に結び付く。Upはアプリケーションの取引完了、すべてのECMP経路、容量、利用者体験を表す総合判定ではない。狭い観測を広い運用結論に置き換えると、速い信号が誤った支配力を持つ。

RFC 9314は設定、運用状態、BFDを利用するクライアントを分けて扱う。ルーティング・クライアントは自分の収束規則を持つ。トラフィック制御にはポリシー、容量、ロールバックの確認がいる。サービス担当者にはアプリケーションの観測がいる。BFDはこれらの入力になり得ても、決定者を兼ねない。

定期的なMCIは長期の偽装余地を狭める

LCIの運用中も、RFC 9985はMCIを使うPollシーケンスで定期的に再認証することを求める。定められた時間内にMCI認証済みFinalを受け取れなければ、そのセッションはDownにしなければならない。再認証間隔は設定可能であり、これは機器能力とリスクを知る運用者の判断として記録されるべきである。

現行のLCI組合せに関係するRFC 9986は、鍵の配布を範囲外とし、ISAACへの分析も限定的だと述べる。これはLCIの成功を無意味にする話ではない。鍵の保管、導入、サービス影響という別の証拠を、一つの制御パケットで埋められないという話だ。

クライアントへの通知にも境界がある

RFC 9985は、LCIへの移行が機能するまでBFDクライアントへのUp通知を遅らせるよう勧告する。MCI下では成立したように見えた移行が、実際に継続を担うLCIで失敗するなら、下流へ成功として渡してはならない。

出典