要約

  • draft-ietf-ivy-network-inventory-topology-11 の ne-ref と port-ref は論理オブジェクトを物理要素へ対応付け、読み取り専用の port-breakout はハードウェアが提供し得るチャネルを示す。どちらも、現在の分割構成、チャネルの稼働、空き容量を証明しない。
  • 対応付けは自動発見だけでなく、手動入力や将来資源の計画にも使える。出所、構成意図、機器の読戻し、運用状態、容量、オーケストレーション判断、開通結果を別々の記録として残す必要がある。

「四本ある」と読んだ瞬間

サービス要求が 100G を必要としている。オーケストレータの在庫画面には 400G ポートと四つの breakout channel が見える。候補選択だけを考えれば、最初の一本を割り当てるのが合理的に映る。

しかし port-breakout は config false である。草案は、ポートが trunk として構成されているか breakout として構成されているかに関係なく、リストは固有のハードウェア能力を表すと説明する。四つの候補形は、四つの子インターフェースの存在ではない。

親ポートはまだ 400G 一体で動いているかもしれない。光学条件が分割モードに合わないかもしれない。子インターフェースが生成されていても lane が down かもしれない。運用上 up でも容量が予約済みかもしれない。

能力値はそれでも正しい。誤りは、その正しさを別の問いへ無断で移した側にある。

対応表には由来が要る

第 11 版は RFC 8345 のトポロジーモデルに inventory-topology を定義する。ノードの ne-ref は物理ネットワーク要素へ、終端点の port-ref は物理ポート部品へ一対一で対応する。対応属性の存在は、このモデル上で物理オブジェクトと抽象・論理オブジェクトを区別する。

共通の参照形式は相互運用に効く。だが参照は現場検査そのものではない。どの主体が、どの方法と時点で対応を作ったかが、その主張の強さを決める。

草案が ne-ref、port-ref、link-type などを書込み可能にするのは、発見だけでは届かない現実があるからだ。管理域外の CPE、内部が見えない第三者回線、将来計画上の仮想資源、発見値への手動 override が例示されている。

手動入力は不正ではない。出所を失って自動観測と同じ顔をすることが問題だ。対応記録には、発見・手動・取込み・仮定の区分、作成主体、時刻、対象範囲、上書き権限を残さなければならない。表記が同じでも、信頼の根拠は同じではない。

読取り専用が保証する範囲

port-breakout はこのモデルから手動設定できない。ハードウェアにより決まるため、書込み可能な対応より強い能力主張である。機種選定や変更計画では重要な事実になる。

それでも現在構成の報告ではない。能力応答は機器、部品、ソフトウェアまたはファームウェアの版、取得方法、時刻に結び付ける必要がある。ラインカード交換後も論理名だけは残る。キャッシュは交換前の正しい応答を返し続けることができる。

構成を証明するのは、承認済みの意図と commit 後の読戻しである。運用を証明するのは、実在する子インターフェース、管理・動作状態、光レベル、アラーム、エラーカウンターである。割当可能性を証明するのは、そのチャネルに対する新鮮な容量情報である。

一つの緑色アイコンにまとめれば、どこで事実が途切れたのか分からなくなる。

leased fiber が示す知識の境界

link-type は fiber、copper、coax、microwave、WLAN、leased fiber などの軽量な識別子である。利用者を専門的な在庫モデルへ案内するが、それ自体は完全な物理台帳ではない。

借用光ファイバーでは、利用者が第三者設備への依存を正確に把握しながら、その物理経路、芯線、中継部品、保守状態を見られないことがある。leased-fiber は、その不完全な可視性を隠さずに依存を表現できる。

ここから物理多様性や容量を推論してはいけない。一方で、詳細がないという理由で依存関係を消すべきでもない。成熟した台帳は「種類は分かる」と「内部は観測権限外である」を同時に保持する。

YANG の合格は機器の合格ではない

調査時点で第 11 版は active な Standards Track Internet-Draft で、IESG に提出され AD Go-Ahead 待ちだった。IANA review はまだ OK ではなかった。Datatracker の YANG 検証はエラー 0、警告 0 を示していた。

これはモジュールの品質に関する有用な証拠である。導入済み実装、データ鮮度、ポート状態、サービス結果の証拠ではない。暗号化された通信は古いマッピングを安全に運べる。NACM は権限を制限できるが、権限を持つ主体の判断を正しくはしない。

文書、実装、構成、運用は別々に検証されるべきである。緑色の schema 結果をネットワークの稼働判定へ流用してはならない。

SAP を選んだ後に必要なこと

草案のサービス提供例では、SAP を物理ポートへ対応させた後、別のトポロジーモデルで容量を確認する。資源が不足すれば別 SAP または手動介入を選べる。対応付けだけを容量判定にしない設計である。

実務では、対象装置、親ポート、breakout mode、想定する子識別子、光学条件、変更時間、承認者を意図記録にする。設定後には装置から親モードと子インターフェースを読み戻す。さらに各 lane の状態、アラーム、カウンター、空き容量を確認する。

オーケストレータには、ポリシー版、読んだ snapshot、候補、除外理由、選択した SAP、人手による例外を記録させる。最後に開通結果、実際のトラフィック経路、顧客側の結果を観測する。

設定受理は開通ではない。インターフェース up も、期待したサービスの到達を単独では証明しない。

監査できる十の記録

少なくとも次を分離して保存する。

  1. ツールが理解した draft または RFC、モジュール、registry の版；
  2. controller、device、取得方法と snapshot 時刻；
  3. ne-ref、port-ref、link-type とその由来；
  4. 参照整合性と、作成・override を許された主体；
  5. 部品と firmware に結び付く port-breakout 能力；
  6. 承認済み構成意図と変更記録；
  7. commit 後の機器読戻しと実在する子一覧；
  8. 選択 lane の状態、光学値、counter、capacity；
  9. policy、候補、SAP または path 選択、手動介入；
  10. service activation、観測された traffic path、利用者の結果。

草案は、古い、あるいは誤った対応が mis-provisioning、予期しない経路、activation failure、誤った capacity planning を起こし得ると警告する。原因を区別するには、証拠も区別しなければならない。

アクセス制御が正しさを代行しない理由

在庫トポロジーには、装置集合、内部 port 名、media type、第三者所有、hardware capability といった機微情報が含まれる。安全な transport、相互 authentication、RFC 8341 の NACM は、誰が読み書きできるかを制御するために必要である。

それでも、認証済み応答が新鮮だとは限らない。正当な権限を持つ担当者が、古い cache や失効した manual mapping に基づいて誤ることもある。port-ref の書込みを制限しても、許可された override が実際の配線変更と一致するかは別の検証事項である。

したがって、閲覧権限、変更権限、データ生成者、判断者を同じ欄にまとめてはいけない。秘密性のために provenance を捨てれば監査が弱くなり、監査のために物理詳細を無制限に公開すれば攻撃面が増える。外部には必要最小限を示し、内部判断には完全な由来を保持する設計が必要だ。

反例で運用画面を試す

breakout 導入前には、画面が異なる現実を区別できるか試せる。親 port が 400G のままなら「対応可能・未構成」と表示すべきである。子 interface が生成されても光信号がなければ、configuration success と physical failure を同時に見せるべきである。lane が up でも capacity が予約済みなら、新規割当てを拒否しつつ interface health は維持すべきである。

これらは特殊な例ではなく、state model の正直さを測るテストである。二つ以上の状態が同じ緑色に見えるなら、証拠層がどこかで折り畳まれている。API と console をこうした反例で検証することは、障害後に四チャネル表示の意味を再解釈するより安い。

情報源