要約

  • RFC 3084 では、一つの DEC メッセージに入った削除とインストールはまとめて成功するか、まとめて失敗する。PEP は結果を RPT で返し、失敗時には直前の正常なトランザクションへ戻る。
  • その成功通知は永続的な一致を保証しない。切断中も装置はキャッシュした Request-State を使い続け、再接続後には差分を同期するか、双方が一致しているという仮定を引き受ける必要があった。

配布された規則は別の機械で現実になる

古い分類器を削除し、新しいキュー設定を入れる DEC を考える。TCP はメッセージを届け、PEP は Success を返す。この時点で、PDP には単なる送信記録より強い証拠がある。装置は一つの取引として受け入れたと報告した。

しかし利用者が得るサービスまで証明されたわけではない。PEP は PIB のインスタンスをローカルなフィルター、キュー、スケジューラーへ写像する。RPT はその境界で止まる。パケットがどの処理を受けたか、アプリケーションが期待した品質を得たかは、別の観測を要する。

2001 年3月の RFC 3084 は、COPS をポリシー供給に用いる COPS-PR を定めた。Policy Decision Point が Policy Enforcement Point にデータを押し出し、Policy Information Base がクラスとインスタンスを記述する。PRID は個々の PRI を識別する。RFC が共通化したのは万能なポリシー意味論ではなく、供給、削除、報告、同期の手順だった。

この論点は RFC 3060 の既存記事とは重ならない。PCIM の記事は、共通スキーマが同じ評価アルゴリズムを保証しないことを扱った。本稿が追うのは、意味が定まった規則でも、PDP と PEP が現在状態をどう共有し、失った一致をどう回復するかである。

原子性は即時失敗を囲い込んだ

DEC は複数の decision を持てる。削除を先、インストールを後に置く順序は、時間差ではなく優先関係を解くためだった。メッセージ全体は一つのトランザクションであり、一部だけを残してはならない。失敗すれば PEP は Failure を返し、直前の成功状態へ巻き戻す。新規設定が入らないのに旧設定だけが消える事態を避ける仕組みである。

各 DEC には solicited RPT が必要で、NULL decision にも Success が返る。ところが、以前は正常だった設定が後から壊れた場合は事情が変わる。PEP は unsolicited Failure を送れるが、RFC は、その時点では正しい旧状態が曖昧なため巻き戻せないことがあると認めた。直後の拒否と、稼働後の故障は同じ Failure ではない。

PIB の版違いにも方向性があった。新しい PDP が、古い PEP の知らない PRC を送れば、PEP はエラーを返して正常状態へ戻る。逆に新しい PEP と古い PDP の組合せでは、新クラスのインスタンスが届かないだけである。互換規則は破損を抑えるが、能力が等しいことまでは証明しない。

切断中はキャッシュが権限を持つ

COPS-PR は一つの Client-Type で一つのサーバーが設定を更新する構成を採った。接続中はローカルコンソールからも事実上ロックされる。競合する書き手を減らす設計だが、その分、接続相手と保存状態が統制面の要になる。

通信が失われると PEP は最後の PDP、次に設定済みの二次 PDP を試す。その間も active Request-State は判断に使われる。再接続時には LastPDPAddr で、どの PDP の決定をキャッシュしているかを示せる。PDP が SSQ を送れば、PEP は全 Request-State の REQ を再発行し、PDP は不要な PRID または prefix を削除して既知の整合状態へ導く。

PDP が同期を要求しなければ、PEP はサーバーが自分を認識し、現在状態を正しいとみなせる。ただしこれは手順上の仮定であり、独立した検証ではない。切断中の変更は後から報告する必要がある。所定時間を超えて再接続できなければ、PEP と PDP はそれぞれ Request-State を期限切れとして削除する。

SPPI と後続 PIB はこの構想を広げたが、2016 年に IETF は RFC 3084 と関連文書を Historic へ移した。理由には限定的な導入と、運用管理の重心が NETCONF/YANG へ移ったことが挙げられた。Historic は方向転換の記録であって、すべての実装が同日に消えた証拠ではない。

RFC 3084 の教訓は、PDP の意図、DEC の原子受理、RPT、キャッシュ、再同期、ローカル実装、実トラフィックを別々に保存することにある。届いた規則と、装置が今なお実行している規則は、同じ問いではない。

情報源

  1. https://www.rfc-editor.org/info/rfc3084
  2. https://www.rfc-editor.org/rfc/rfc3084.html
  3. https://datatracker.ietf.org/doc/rfc3084/
  4. https://www.rfc-editor.org/errata/rfc3084
  5. https://www.rfc-editor.org/rfc/rfc2748.html
  6. https://www.rfc-editor.org/rfc/rfc2753.html
  7. https://www.rfc-editor.org/rfc/rfc3159.html
  8. https://www.rfc-editor.org/rfc/rfc3198.html
  9. https://www.rfc-editor.org/rfc/rfc3317.html
  10. https://www.rfc-editor.org/rfc/rfc3318.html
  11. https://www.rfc-editor.org/rfc/rfc3483.html
  12. https://datatracker.ietf.org/doc/status-change-copspr-sppi-to-historic/
  13. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  14. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/