要約

  • 10月1日に完了したRouting Area Directorateのレビューは、複数の下位コントローラからインベントリを統合する上位コントローラが、公開するne-idの一意性を担うことを明記するよう求めた。
  • 一意なキーを作るだけでは、同じローカルIDを持つ別装置と、別IDで観測された同一装置を区別できない。統合側には判断の根拠と元へ戻れる写像が必要になる。

上位コントローラに二つの「17」が届く。片方はIP網の境界ルータ、もう片方は光伝送装置だ。下位の二つの管理領域では、それぞれ17は一意であり、データにも矛盾はない。それでも一つのYANGリストへ入れようとした瞬間、同じキーが二つの現実を指す。

Linda Dunbarが10月1日に完了したdraft-ietf-ivy-network-inventory-yang-20のtelechatレビューは、この境界を一つのminor issueとして扱った。判定はHas nitsで、文書全体は概ね明確だとされている。ne-idはサーバが割り当て、network-elementリストのキーになる。したがって、下位の複数インベントリをまとめて提供する上位コントローラは、その統合ビューのサーバとして値の一意性を保証する責任を負う、という短い説明が有用だとレビューは述べる。

ここから実装済みの障害を推測してはいけない。リビジョン20はIVYワーキンググループの現行Internet-Draftで、Standards Trackを意図し、IESG評価とArea Directorのフォローアップにある。RFCではない。レビューは攻撃、製品不具合、実運用での衝突を報告したものでもない。標準案が想定する階層構造で、誰が何を引き受けるかを問うている。

このモデルは、コントローラが設置済みだと把握しているネットワーク要素と部品を、汎用かつ読み取り専用で表す。倉庫の予備品や購買情報、商用メタデータは基本モデルの外にある。モデルの範囲では、データを提供するコントローラがsource of truthだ。ただし、それは公開した記録についての責任であり、記録が物理装置そのものになるという意味ではない。

草案がne-idをサーバ割り当てにする理由も明快だ。装置のローカル識別子がネットワーク全体で一意とは限らない。同じネットワーク要素は切断中でも同じIDを保つべきだとも書かれている。一方、製造者名、製品名、管理IP、物理位置などから同一性を判定する方法は実装依存で、標準化の範囲外だ。

この設計は、統合点に二つの異なる責務を置く。一つはデータ構造としての一意性である。もう一つは観測対象の同一性である。下位ドメイン名をIDの先頭につければ、前者は満たせる。しかしA-17とB-42が同じ筐体かどうかは分からない。

分離を誤れば、同じ装置を二重に数え、容量、保守、障害を重複させる。統合を誤れば、二台の装置が一台として扱われ、一方への操作や責任が他方へ流れ込む。管理IPは変わり、物理位置は古くなり、同一製品は多数存在する。矛盾は除去対象ではなく、判断に必要な状態だ。

共通属性のUUIDは強い参照点になるが、判決ではない。リビジョン20はサーバが割り当てるグローバルに一意な値として説明し、UUIDのRFCは形式と生成特性を定める。それでも、一台の物理装置に二つのサーバが別UUIDを与えることはできる。誤った複製で二つの対象が同じUUIDを持つこともある。値の一意性は、対象の同一性を自動的には証明しない。

運用上は少なくとも五層に分ける必要がある。物理資産、下位コントローラの観測、下位のne-id、上位の照合判断、そしてアラームやトポロジー、作業指示が利用する統合ne-idである。YANGリストが妥当でも、発見の正しさや物理的同一性、後続作業の結果までは証明しない。

BTWが提案するのは、可逆なID変換レシートだ。送信元コントローラと元のne-id、統合後のne-id、UUID、利用可能なハードウェア手掛かりを結び、照合規則、確信度、競合状態、最初と最後の観測、置換履歴を保存する。さらに、その対応を使った重要な自動化判断も追跡できるようにする。

これは草案やレビューの要件ではなく、BTWの編集上の提案である。B-17を統合ビューで18へ変更しても、元へ戻る経路を失わないための仕組みだ。後からA-17とB-42を同一筐体と判断した場合も、以前の二つの主張を消さない。証拠が弱ければ、きれいな一行を作るより競合中と表示する方が誠実である。

Heng LuのNote 20は、実行可能な現実と象徴的な表現を区別する。記録が業務を動かしても、記録は装置そのものではない。Note 64は、一意性と相互運用に必要な検証可能な最小不変条件だけを共通層に置き、その後の選択を実装者に残す。Note 19は協調と権威を分ける。ここでは、共通モデルが一意なキーを定め、ローカルの統合者が照合方法と証拠を担い、IDは物理資産への支配権を生まない。これはIETFの見解ではなく、BTWが開示する分析枠組みだ。

既存記事との境界も明確である。トポロジー記事はne-refやport-refの手動上書き、ライセンス記事は権利と実際の有効化、パッシブ資産記事は自ら応答しない設備の証拠を扱う。本稿はそれ以前の問題、つまり参照が統合層へ移るときに何を指し、どの元名前空間へ戻れるかだけを扱う。

草案は、階層型コントローラが下位から情報を集め、統合ビューをさらに上位のコントローラ、Inventory OSS、他のアプリケーションへ出せるとしている。ACTNも一つの利用文脈として挙げる。標準が単一の照合アルゴリズムを命じる必要はない。しかし、どのサーバ境界で一意性が成立し、実装がどのように衝突と同一性を分けて扱うかは、見えるようにすべきだ。

出典