要約

  • RFC 5243 では、受信した Database Description パケットが隣接ルータの同一または新しい LSA を示すと、送信側の Database summary list から同一または古い項目を外せる。
  • 外れた項目は一回の重複説明を取り消すだけで、要求リストの空、Full 到達、SPF、RIB/FIB 反映、実トラフィックを証明しない。

「消えた仕事」の理由を残せるか

運用画面に「残り 800」が表示され、次の瞬間に「残り 200」になったとする。良い知らせに見える。だが 600 件は実行されたのか、重複のため取り消されたのか、別のキューへ移ったのか。それを示さない数字は進捗ではなく、単なる在庫差分である。

RFC 5243 は、この違いを小さな OSPF 手順の中で鮮明にする。Database Exchange の開始時、各ルータは隣接相手ごとに、DD パケットで説明する LSA ヘッダの一覧を用意する。相手から同一またはより新しいヘッダを受け取れば、こちらの同一または古いヘッダを送り返す必要はない。項目は一覧から消える。

ところが同じ DD パケットに、ローカル LSDB より新しい別の LSA が含まれることがある。その項目は Link state request list に入る。説明予定は減り、取得義務は増える。

だからリスト長だけでは、同期が前進したかを一意に語れない。

RFC が認めるのは限定された否定

受信ヘッダが与える根拠は限定的だ。「この隣接相手に、この同一または古いヘッダを返す必要はない」と判断できる。それは、予定された一動作を否定する根拠である。

そこから「双方のデータベースは同じだ」という肯定には移れない。一つの LSA 比較は LSDB 全体を代表しない。Database summary list は Link state request list や retransmission list を代表しない。DD 交換は SPF 計算や転送面を代表しない。

運用製品が summary list を「同期残量」と名付けると、この狭い権限が拡張される。最適化が効くほど表示は急速にゼロへ向かう一方、要求すべき LSA が残る可能性がある。表示すべきなのは抽象的な完了率ではなく、どの LSA が、どの比較結果により、どの隣接相手への重複送信から除外されたかである。

次の応答前という境界

RFC 5243 は、ローカル LSDB の照合と summary list の更新について、どちらを先に行ってもよいとする。ただし最適化を実装するなら、受信 DD パケットに列挙された全 LSA の更新を、次の DD 応答を送る前に終えなければならない。

これは次の応答を、受信パケットの一部だけ反映した一覧から作らないための境界である。前半で不要と分かったヘッダを、処理途中の古い一覧から再び送ることを防ぐ。

しかし分散コミットではない。相手は共有トランザクションを承認していない。双方の全 LSDB も認証していない。要求は残り得るし、交換は再開や失敗を迎え得る。

「応答前に処理済み」という記録は、ローカル出力の一貫性を支える。遠隔状態やサービス結果まで確定したという意味を持たせてはならない。

三つのリストは別の質問に答える

RFC 2328 の隣接状態には、用途の異なる記録がある。Database summary list は DD で何を説明するかを示す。Link state request list はローカルにない、または古いため取得すべき LSA を示す。Link state retransmission list は送信後に確認を待つ LSA を示す。

これらを一つの「同期キュー」にまとめると、原因が失われる。減少が重複排除なのか、要求完了なのか、確認受領なのかを後から復元できない。

状態遷移も段階を区別する。DD 交換が終わると ExchangeDone が発生する。request list が空なら Full へ進めるが、残っていれば Loading で完全な LSA を要求し、LoadingDone を待つ。

さらに Full は OSPF 隣接状態でしかない。個別経路の SPF 完了、RIB 選択、FIB 書き込み、物理経路の双方向性、アプリケーション成功は別の証拠を必要とする。

互換性は導入証拠を残さない

この最適化は、新しいパケット種別、能力ビット、IANA 割当を要求しない。片側が重複ヘッダを省いても、相手側は従来手順のまま動ける。これが RFC 5243 の後方互換性である。

一方で、導入を示すネゴシエーション結果も存在しない。DD パケットが少ないという観察だけでは、RFC 5243 の実装、データベース規模、パケットへの詰め方、タイミングを区別できない。線上の観察は何が送られたかを示せるが、送らなかった内部理由はローカル記録なしに確定できない。

RFC は高速検索のため、LSA を辞書順に並べる案も示す。OSPFv2 と OSPFv3 では比較タプルのフィールド順が一部異なる。ただし順序は必須条件ではない。観察できても完全な適合証明ではなく、観察できなくても同期失敗の証拠ではない。

約 50% は例の境界内で読む

RFC 5243 は、隣接形成時にほぼ同期済みである大規模ネットワークなら、Database Description のオーバーヘッドを約 50%減らせると述べる。例では、同一 LSDB のヘッダが二つの完全 DD パケットに収まり、最適化後は各側が一つだけ送る。

これは仕組みを説明するモデルである。特定製品の既定値、実環境の導入率、CPU 削減、収束高速化、障害回避を測定した記録ではない。RFC 5243 自体も Informational である。

RFC 9454 は後に Leader/Follower という用語へ更新したが、最適化の証拠範囲を広げてはいない。RFC 4222 の輻輳対策や RFC 4811 の帯域外 LSDB 再同期も、それぞれ別の操作面を持つ。

効率と完了を同じ権限で承認しない

Lu Heng が示す reality layers の考え方では、記録は実際に観察した層に留まるべきだ。ここで確認できるのは、隣接相手がヘッダを提示し、ローカル比較が重複を認定し、次の応答前に送信予定から外したという一連の事実である。

その記録は有用で、しかも十分に具体的だ。要求、再送、状態遷移、計算、導入、転送を別記録として保てば、効率化は完了の権限を借りずに評価できる。良い制御面は、速いだけでなく、まだ証明していないことを明確に言える。

情報源