要約

  • draft-ietf-nmop-simap-concept-13 は、サービスから支える論理・物理資源への下降と、資源から依存サービスへの上昇を同じ関係グラフで可能にする。
  • 応答は、あるサーバーが特定の権限、抽象度、情報源、時点のもとで示した表現の証拠である。完全性、同期、原因、意思決定権限、網への操作、観測結果は別に立証しなければならない。

障害時に欲しいのは、装置一覧ではなく影響の経路である。顧客サービスを起点に、その構成要素、レイヤー3とレイヤー2の接続、終端点、物理装置まで下る。逆に故障した資源から上り、その資源に依存するサービスを拾う。Service & Infrastructure Map（SIMAP）は、この二方向の探索を標準的なモデルの上で可能にしようとしている。

ここで、きれいな経路が見えたことと、現用網の全体が見えたことを同一視してはいけない。応答はサーバーが構成したトポロジー・インスタンスであり、アクセス方針に従って公開されたビューである。省略も抽象化もあり得る。外部システムから参照した状態が別の時刻に観測されていることもある。

対象文書は2026年9月4日付の draft-ietf-nmop-simap-concept-13 である。IETF Datatracker は、NMOPワーキンググループの有効なInternet-Draftで、想定ステータスはInformationalとしている。履歴 によれば、9月12日にIETF Last Callへ入り、締め切りは9月26日である。完成したRFCではなく、変更され得る作業文書だ。

下から見ても上から見ても同じ関係か

SIMAPの中核となる要素はnetwork、node、link、termination pointである。supporting relationshipは同一レイヤー内だけでなく、異なるレイヤーの要素を結ぶ。サービス起点の問い合わせは、サービスが利用する論理資源を見つけ、最下層の関係を介して物理資源へ至る。資源起点なら、物理、レイヤー2、レイヤー3の要素から、それに依存するサービス、ノード、リンク、終端点へ上る。

RFC 8345 は既に、supporting network、node、link、termination pointを持つYANGトポロジー・モデルを定義している。SIMAPは、その構造をサービス運用、インベントリー、アシュアランス、可観測性などへつなぐ構想である。

ただし、外部モデルへのリンクは事実の同一性を保証しない。インベントリーの資産、アシュアランスの症状、テレメトリーの測定値には、それぞれ識別子と観測時刻がある。同じ名前で結合できても、同じ物を同じ時点に見ていたとは限らない。関係をたどれることと、証拠が時間的に整合していることは別の条件だ。

見えないものは、存在しないものではない

第13版は、クライアントが取得できる情報は認可された範囲に限られると明記する。サーバーはセキュリティ、管理、商業上の理由からレイヤーを隠したり、ネイティブなトポロジーの代わりに抽象ビューを示したりできる。

従って、応答に装置がないことは、その装置が網にないことの証拠ではない。一つの抽象ノードが複数の実ノードを表すかもしれない。単一の論理リンクの下に、障害共有の異なる物理経路が隠れているかもしれない。顧客はサービス運用に必要な関係だけを受け取り、事業者内部の構造を知らないこともある。

レイヤー間の移動と抽象度間の移動も区別が必要だ。レイヤー3リンクを支えるレイヤー2経路を探すのは前者であり、抽象ノードにまとめられたネイティブ・ノードを探すのは後者である。「レイヤー3を取得した」という記録だけでは、ビューの粒度を説明できない。

liveには観測時刻が要る

文書はlive topologyを現実の網の最新スナップショットと定義し、初期・オンデマンドの発見と同期を要求する。これは実装要件であって、個々の応答が実際に完全かつ最新に同期されたことを、応答自身が独立に証明するわけではない。

SIMAPはさらに、時点スナップショット、potential topology、intended topology、passive topologyを扱う。intended topologyは望ましい構成を表し、中間ホップや詳細装置を省くことがある。passive topologyには、ネットワークから自動発見できず、別の台帳や手入力に頼る設備が含まれ得る。状態や履歴はSIMAP内部にある場合も、外部モデルから参照する場合もある。

比較の前に、インスタンス、ビュー種別、情報源、観測時刻、同期状態を特定しなければならない。「live」という分類だけでは、鮮度の証明にならない。

依存は原因ではない

ある資源から五つのサービスへ到達した場合、言えるのは、そのビューの中で五つが当該資源に依存すると表現されていたことだ。その資源が五つの障害を引き起こしたとは限らない。バックアップ経路かもしれず、負荷分散に使われているかもしれず、関係が古い可能性もある。サービス障害には別の原因もあり得る。

原因を論じるには、資源の状態変化、トラフィックやサービスの変化、両者の時間関係、代替原因、復旧後の観測が要る。SIMAPは調査対象を整理するが、グラフ上の近接を因果に変えるものではない。

地図への書き込みは網への操作ではない

第13版は、SIMAPへのwrite操作が現用網を直接変更するためのものではないと説明する。書き込みはwhat-if分析、発見できないintended／passive topologyなどに使われる。実網の変更は、通常のコントローラー操作を通じて行われる。

自動化では少なくとも四つの記録を分離すべきだ。判断に使った地図または提案、意思決定とその権限、コントローラーや装置に送った操作、変更後の網とサービスの観測である。地図の更新が受理されても、装置が動いた証拠にはならない。装置が指示を受理しても、サービスが改善した証拠にはならない。

閉ループも同様である。SIMAPは監視と分析を支えられるが、修正行為、実行権限、フィードバックがそろって初めてループになる。事後観測がなければ、システムは自分の処理が進んだことしか知らない。

ビューの条件を応答と一緒に残す

運用判断に使う問い合わせでは、サーバー、インスタンス、モデル版、クライアントの役割と認可範囲、レイヤーと抽象度、外部情報源、スナップショット時刻、関係の向き、フィルター、同期状態を保存する必要がある。行動に進んだ場合は、承認、実行、観測、ロールバックも別々に記録する。

この限定は自動化を弱めない。結果を説明可能にする。SIMAPが最も確実に答えられるのは「これが網だ」ではない。「このサーバーは、この権限と情報源と時点のもとで、この依存関係を示した」という、条件付きで検証可能な主張である。

情報源

本文と現在の状態はSIMAP第13版およびDatatracker履歴による。関連仕様はRFC 8345、RFC 8341、RFC 8040、RFC 9417、RFC 9408。関連するSIMAP YANG案は個人提出のInternet-Draftで、IETF標準化プロセス上の正式な位置付けを持たない。 固定した原文は第13版アーカイブ、トラフィックエンジニアリングの文脈はRFC 9522を参照した。