要約

  • RFC 1245はOSPF Version 2の資源消費、トラフィック、拡張性、堅牢性を解析し、RFC 1246は実装、シミュレーション、運用網、3回の相互接続試験を記録した。
  • 試験は仕様の欠落と実装上の不具合を別々に発見した。一方で、現場の3網は同じ実装を使っていたこと、初回試験の記録が不完全だったこと、異なるベンダー間で複数の経路制御プロトコルを同時に動かす試験が未実施だったことも明記された。
  • RFC 1247は別の標準化過程にある仕様書だった。解析、試験、導入を同じ「検証済み」という言葉に縮めないことが、OSPFの信頼性を支えた。

帯域の計算が正しくても、二つのプログラムが未定義のフィールドを同じように扱うとは限らない。逆に、試験室で隣接関係が成立しても、大きなデータベースや日常の障害、外部経路の継続的な流入に耐えることまでは示さない。

OSPFワーキンググループは、この違いを文書構成に残した。RFC 1245 OSPF Protocol Analysis と RFC 1246 Experience with the OSPF Protocol は、1991年7月に情報提供RFCとして公開された。同じ月の RFC 1247 は、OSPF Version 2を定める標準化過程の仕様書である。

RFC 1247はプロトコルの動作を定義した。RFC 1245は、その設計がどの条件で性能と規模を保てるかを問うた。RFC 1246は、独立したコード、試験構成、実際の網で観測されたことを保存した。それぞれの結論には、別の出所と限界があった。

解析が示した条件付きの範囲

RFC 1245は、リンク状態データベース、最短経路計算、詳細なトポロジーの拡散と計算を限定するエリア、マルチアクセス網の隣接数を減らすDesignated Routerを取り上げた。続いて、経路制御トラフィック、SPF計算の頻度、メモリ、データベース規模、一つのLANに置けるルーター数、分断や再起動への対応を評価した。

根拠は一種類ではない。プロトコル構造と式、BARRNet、NASA Sciences Internet、OARnetの運用統計、シミュレーション、特定構成の測定が組み合わされた。Proteon P4200を使ったメモリ推定には、他の実装では異なり得るという限定が付いていた。

一つのLANに50台を超えるルーターを置いた結果はシミュレーションだった。13台を同じEthernetに接続して問題が見られなかったという結果は相互接続試験だった。前者はモデル内の構成、後者は実際に動かした構成である。どちらも任意のタイマー、障害、負荷、実装を保証しない。

解析値は、トポロジー、LSAの構成と更新頻度、パケット長、タイマー、メモリ構造と一体だった。後の網が条件を変えるなら、古い数値は保証ではなく再検討の出発点になる。

実運用ではコードが一つに固定されていた

RFC 1246は、少なくとも一回の相互接続試験に参加した実装として、3Com、ACC、Proteon、Wellfleet、University of Marylandの五つを挙げた。また、NSI、BARRNet、OARnetの運用を、当時それぞれ15台、14台、13台のルーターを持つシステムとして記録した。

三つの運用網は、データベース同期、信頼できるフラッディング、外部経路の取り込み、等コスト経路、stub areaについて現場の材料を与えた。しかし、すべてProteon実装を使っていた。そのため報告書は、複数ベンダーによる運用導入を未試験事項に数え、別章の相互接続試験と明確に分けた。

運用網は現実の負荷、故障、作業時間を含むが、ここでは実装が一定だった。試験室は実装を変える一方、計画したトポロジーと短い日程を使った。試験中の頻繁な再起動により、MaxAgeによるLSA消去は通常運用より多く発生した。二つの環境は補完的であって、互いの代用ではない。

不一致が仕様そのものを直した

初回試験では、同時にフラッディングされたMaxAge LSAがDatabase Description処理中の特定の時間窓に入ると、同期が完了しない可能性が見つかった。仕様のMaxAge処理を変更する必要があった。さらに、デフォルト宛先を通知する外部LSAのNetwork Maskをどう設定するかが定められていなかった。独立実装は、その空白に異なる前提を置いていた。

ただし初回試験の記録は不完全で、RFC 1246は構成図を再現できないと認めた。発見は残ったが、すべてのリンク、参加者、設定値を後から復元することはできなかった。

後の試験は、仮想リンク、複数のネットワーク種別、認証、経路階層、フラッディング、LSA消去、外部経路を対象にした。400本の外部経路を取り込んだ構成では、実装のバッファ割り当てとIPフラグメンテーション回避に問題が見つかった。仕様の曖昧さ、コードの不具合、通過した試験項目は別々の記録だった。

さらに、異なるベンダーのルーター間でOSPFとRIP、EGPなど複数の経路制御プロトコルを同時に動かす試験は行われていなかった。OSPF内の相互接続成功から、プロトコル間の経路交換まで推定することはできなかった。

推奨は採用命令ではなかった

1992年の RFC 1371 は、IESGがOSPFをIPインターネットのcommon IGPとして推奨した理由を説明した。判断には運用経験が必要だとしながら、その指定はOSPF利用を義務づけないとも明記した。

これは当時の資料から生まれた統治上の判断である。RFC 1245の推定を普遍的な測定に変えたり、RFC 1246の試験を世界中の複数ベンダー導入に変えたりはしなかった。

残された価値は、仕様、仮定、シミュレーション、実装一覧、試験、運用、欠陥、未検証領域、後の判断をつなげられる点にある。証拠は同じ種類だったから強くなったのではなく、違いを保持したまま結合できたから強くなった。

出典

証拠の限界

これらのRFCが示すのは、1991～1992年に記録された解析、実装、試験・運用環境、欠陥、推奨である。任意規模の性能、すべてのベンダー組み合わせ、普遍的導入、後年の無欠陥、現在の網状態、OSPF採用義務は示さない。