要約

  • RFC 1222 は、加入者 IGP と Backbone IGP の論理主体を一台に置き、両者の間では EGP または BGP を維持する案を示した。
  • NSFNET 側と接続ネットワーク側は、それぞれ自分のルーティング情報の完全性に責任を持ち、Ethernet 接続点も管理境界として残った。
  • 二つの daemon とローカル BGP セッションだけでは、カーネルの分離、正しい経路導入、転送、到達性は証明できなかった。

第一段階では揺れが管理組織を越えた

RFC 1222 は H-W. Braun と Y. Rekhter が 1991 年 5 月に発表した NSFNET 接続の簡素化案である。RFC Editorは Informational とし、IETF Datatrackerは Legacy stream に置く。標準でも、特定導入の実績報告でもない。

56 Kbps の第一段階では Backbone が Hello、地域網が主に RIP を使い、gated が間を翻訳した。全体は一つのルーティング系に見えたが、ある端の metric 変動が複数の管理主体を通って別の端まで伝わった。接続が増えるほど、情報流通を遮る手段の不足が loop と不安定さを招いた。

T1 の第二段階は Backbone IGP と顧客 IGP を強く切り離した。RFC 1093 が接続構造を、RFC 1092 が代表契約、policy database、無権限広告の拒否を記す。外部ルーティングは内部 metric の波及を抑えたが、経路の正当性や packet 到達を自動的に保証したわけではない。

必要なのは二台ではなく二つの主体だった

分離の実装には加入者サイトの追加 router が必要だった。加入者 IGP に参加し、同じ subnet 上の NSFNET node と EGP/BGP を張る。T3 で小規模接続が増えれば、機器と運用知識の負担が入口を狭める。

RFC 1222 は要件を論理化した。一方の主体は加入者 IGP、もう一方は Backbone IGP に属し、両者は inter-domain mechanism で話す。この関係さえ維持すれば、一つの Unix node 上で二つの routing daemon を動かし、loopback または IPC で交換できる。

RFC 1163 の BGP は autonomous system 間の到達性を運ぶ。lo0 を通ることで packet の物理距離は短くなるが、発言者の行政的な立場は変わらない。内部通信に見えても、導入 policy と設定所有者は別のままだった。

共通カーネルは分離を裏切り得た

文書は、二つの daemon が望ましくない形で同時に kernel と相互作用しないよう注意を求めた。プロセスが別でも、routing table、interface、資源、再起動順序は共有され得る。論理図だけでは failure domain を証明できない。

観測は段階ごとに必要だ。process 起動、BGP session 成立、route acceptance、kernel install、data-plane forwarding、遠端到達は別の記録である。前段の成功から後段を埋めてはならない。

IGP 間には強い firewall を残し、越境する情報には exterior-domain の tag を付ける案も示された。tag は由来を運ぶが、広告を認証せず、後段で保持されたことや利用が正しいことも証明しない。

設定権限はそれぞれの領域に残った

RFC 1222 は distributed control を求めた。NSFNET Backbone 組織と接続網 provider は、それぞれ自分の routing information の integrity に責任を負う。regional client は、自分の IGP に参加する daemon の設定を提供し、何を内部へ入れるかを制御できた。

Ethernet attachment は行政・運用上の demarcation point として残る。同じ machine の log だからといって、Backbone 側の観測が client 設定の証明になるわけではない。「責任を負う」という記述も、実際に integrity が守られた証拠ではない。

長期案では境界を C-NSS cloud に近づけ、C-NSS と E-NSS の物理媒体を二つの組織が管理する。そのためには Ethernet の境界に近い管理性と fault isolation が必要だった。PPP や serial-line management は助けになるが、異種装置が fault の所在を曖昧にする。link up は責任の解決ではない。

RFC 1222 の価値は、仮想化を予言したことではない。物理統合が進んでも、route origin、設定、kernel state、物理故障、転送結果を別々に記録しなければならないと示した点にある。

出典