要約

  • RFC 1863では担当クライアントの少ないサーバーほど短いDelayTimerを得たが、それは最も勝ちやすいというだけで、一意の送信者を保証しなかった。
  • informed client一覧はサーバー側の送信責任の申告であり、クライアントの受信確認、経路選択、導入、到達性の証明ではなかった。
  • 重複はクライアントが吸収し、障害引継ぎはセッション状態とHold Timeに依存した。RFC 4223は後に、この特定方式の実装が存在しなかったと記録した。

待機順位が作ったのは確率だった

RFC 1863は1995年、BGP/IDRPのフルメッシュ接続数を減らすルートサーバーを提案した。冗長化のためクライアントはクラスター内の全サーバーへ接続する一方、通常は一台だけが更新を送る想定だった。

各サーバーは、自分と同僚それぞれのinformed client一覧を持った。一覧は担当数、同数なら識別アドレスで並ぶ。新規クライアントがどの一覧にもなければ、順位Nのサーバーは(N-1) × DelayGranularityだけ待つ。最少負荷のサーバーが先に満了しやすい。

満了時には一覧を再走査する。新しいLISTで他者の担当が見えれば送らず、なお空白なら自分の一覧へ追加してLIST送信を予定し、更新を始める。二度目の確認は遅れた状態の窓を縮めるが、複製状態を原子的台帳にはしない。仕様自身が、調停は競合を完全には排除せず、複数サーバーから更新が届き得ると認めた。

接続削減と経路削減は別だった

サーバーは受け取った外部経路と属性を中継し、配布用の最良経路を選ばない。クライアントが直接ピアの場合と同じようにローカル方針を適用する。このvirtual peeringは接続管理を軽くしたが、各クライアントが保持する経路情報量は減らさないとRFCは明記した。

従って、中継成功は選択成功ではない。受信、比較、選択、転送表への導入、次ホップ解決、実トラフィックの到達は別の観測である。中央にサーバーを置いても、この証拠列は短縮されない。

informedは受信者の返事ではない

LISTを発行したのは送信担当のサーバーだった。クライアント名が載っていても、特定UPDATEの受信、保存、採用は確認されない。

Initiation状態のサーバーは接続を受け入れ、入力更新を処理できたが、更新を送信しなかった。推奨五分の初期タイマー、または設定済みサーバー間接続とLISTが揃うまで待った。セッションの存在と、送信責任を引き受けられる状態は別だった。

競合で二台が送った場合、クライアントが最後の防波堤となる。同じクラスターの別サーバーから、全属性が完全に同じ経路を受けると、古いコピーを置換し、新たな広告を起こさないことが望まれた。同一プレフィックスでも属性が違えばこの規則の外である。置換は真偽も優劣も決めず、同一候補の重複だけを閉じ込めた。

障害後も、担当はもう一度競った

サーバー間セッションを失うと、生存者は故障相手の一覧を見る。自分がクライアントとの接続を維持し、他の稼働中一覧にもそのクライアントがない場合だけ、引継ぎを検討する。その後も新規クライアントと同じ遅延と再走査を行う。

これは故障機から所有権を受け取る処理ではない。残った観測から担当を再構成する処理である。旧一覧も調停後まで捨てない。

RFCは最大DelayTimerとサーバー間Hold Timeの合計を、最小クライアントHold Timeの三分の二未満にするよう勧めた。三台構成の例は90秒、30秒、DelayGranularity 15秒だった。この計算は引継ぎ時間を確保するが、最新経路やデータ面継続を証明しない。

名札は認証ではなかった

ADVERTISER属性は最初に経路を提出した境界ルーターのアドレスを保持した。クライアント方針に必要な文脈だが、署名ではない。RFCはセキュリティを論じないと明記した。RCID_PATHもクラスター間のループ検知用で、通常クライアントへは渡らない。どちらも普遍的な来歴証明ではない。

実装されなかった設計をどう読むか

RFC Editorの記録は現在Historicである。RFC 4223は2005年、RFC 1863方式の実装は存在せず、フルメッシュ代替として使われていないとした。

ただし他のroute server用途まで否定していない。route reflection、BGP confederation、private AS番号を別の代替として挙げた。RFC 2796と後継のRFC 4456は最良経路を選ぶreflectorと別のループ属性を扱い、RFC 3065はconfederationを扱う。RFC 1863が別名で実装された証拠ではない。

未実装は技術的反証ではない。しかしこの方式について、時計差、損失、分断、運用者の設定を通過した観測がないことは確定する。仕様は望ましい遷移を示し、running codeだけが現実の遷移を示す。

結論

セッション、LIST、短い待機、再走査、同一経路置換、Hold Timeは六つの異なる証拠だった。どれも単独では到達性にならない。RFC 1863が残した価値は、冗長性の中心に競合を隠さず、クライアントがなお負担する失敗境界まで書いたことにある。

出典