要約

  • RFC 9731 の vn-compute はインスタンス化前の操作であり、計算された VN と接続行列への参照を返せても、VN を作成せず、資源も予約しない。
  • 設定データと運用状態が同じ NMDA ツリーにあることは、意図、適用、収束、通信結果が同一の証拠になったことを意味しない。
  • 安全な運用では、計算時点の情報、設定決定、各ドメインの資源承認、設置されたオブジェクト、運用観測、顧客側の結果を別々に記録する。

運用画面には、一つの VN の下に設定値と状態値が整然と並んでいた。設計レビューでは、その一画面が「計算済み」「設定済み」「稼働中」の三つを同時に意味する資料として使われた。

だが、同じ枝に表示されることと、同じ現実を表すことは違う。

RFC 9731 は Virtual Network の運用を表す YANG モデルを定義する。さらに vn-compute について、インスタンス化前に VN 全体を確認するための計算であり、その計算は VN を作らず、システム内の資源を予約しないと明記する。

モデルが豊かであるほど、表示上の近さを因果関係と取り違えないことが重要になる。

顧客向けの表現には目的がある

主な例である ACTN では、Customer Network Controller が顧客の要求を表し、Multi-Domain Service Coordinator が情報と計算を調整する。Access Point は顧客エンドポイントの特性を示し、Virtual Network Access Point は AP を VN ごとに分割してプロバイダー側の終端へ結びつける。

Type 1 VN は端から端までの抽象リンクとして見せられる。Type 2 VN は仮想ノードと仮想リンク、さらに意図されたパスを含められる。顧客が各ドメインの全内部構造を知らずに要求を扱えるのが利点だ。

この表現は簡略版の在庫表ではない。顧客と提供者の境界に合わせた、意図的な抽象である。したがって、そこにない下位資源の承認や装置への設定を、抽象表示だけから推定してはならない。

サービスモデルは実際のサービスがどのように設計・提供されるかを前提にしない、という RFC 8309 の考え方も同じ境界を支える。

vn-compute が返すのは事前計算である

vn-compute には VN 全体の制約と最適化条件を与えられ、個別メンバーの条件で上位設定を上書きできる。出力は単一ノードの抽象トポロジーを参照し、各メンバーを path property のある connectivity-matrix-id に結びつけられる。

これは単なる成否ビットより有用だ。要求と結果の対応をたどり、メンバーごとの性質を比較できる。

しかし、詳細な計算結果は実行記録ではない。MDSC が自らの情報や CNC との調整で結果を作っても、その時点ではライブ VN はなく、資源の所有関係も変わらない。抽象パスが描けたことは、各ドメインが容量を差し出したことを意味しない。

同じツリーでも作者と時刻は異なる

RFC 9731 は Network Management Datastore Architecture に従い、設定と運用状態を同じモデルツリーで扱う。クライアントが関連情報を探しやすくなる設計だが、二つの現実層を一つにする設計ではない。

設定された VN メンバーが存在しても、その operational state は down かもしれない。変更直後には、意図は新しくても観測値が旧状態を反映することがある。逆に、削除意図が投入された後もしばらく実体が残る場合がある。

画面が一回の取得で両方を返しても、各 leaf の作者、更新機構、観測時刻は同じとは限らない。証拠には datastore、タイムスタンプ、コントローラー、モデル revision を含める必要がある。

スキーマ上の近さは、因果の同一性ではない。

接続行列はトンネルの台帳ではない

計算結果にある接続行列への参照は、抽象ノード内で可能な切替の組み合わせや TE パスの性質を調べるために使える。内部網をすべて公開せず、顧客が結果を検討できる重要な橋である。

だが、その参照は帯域を割り当てない。各アンダーレイ区間が設定を受理したことも、LSP が確立したことも、パケットが転送されたことも示さない。

行列 ID を変更チケットへコピーし、そのチケットを「提供済み」に変えても、証拠は増えない。実体を主張するには、実際に作られたトンネルや LSP の識別子、設置状態、運用観測が必要だ。

「available」は予約完了ではない

計算は、MDSC が未準備、依存 CNC が利用不能、利用可能資源なし、パスなし、未知の Access Point といった理由で失敗し得る。

ここで「利用可能資源なし」が出なかったから資源は確保済みだ、と読むのは誤りである。計算が見た情報では解があった、という範囲を越えている。

設定を投入するまでに別の要求が容量を使うかもしれない。ローカルポリシーが変わるかもしれない。抽象リンクが別の下位構成へ対応づけられることもある。資源所有者が後段で拒否する可能性も残る。

可用性は計算時点の属性であり、予約は権限を持つ主体の行為である。二つには別の作者がいる。

成功した RPC の受領範囲

成功応答から言えるのは、要求が受理され、定義済みエラーで終わらず、特定時点に特定メンバーとトポロジー参照を含む結果が返った、ということだ。入力制約と計算結果を対応づける資料にもなる。

そこから、作成権限、running datastore への commit、全ドメインの admission、トンネル設置、運用収束、顧客トラフィックまで推論することはできない。遅延、損失、保護切替や顧客受入れも別の観測対象である。

RPC を信用しないのではない。実行した範囲に限定して信用することで、受領記録としての価値が保たれる。

資源権限は各ドメインに残る

マルチドメイン計算を調整できることと、全資源を一方的に消費できることは別である。各ドメインには固有の admission policy、保守状況、quota、保護条件、競合要求がある。

顧客の制約は計算を形作るが、それらの権限を上書きしない。MDSC の端から端までの提案が整合していても、各資源所有者は後段で自ら承認する。

計算サービスは入力と結果の snapshot を記録する。設定権限は意図した VN を記録する。資源所有者は admission の可否を記録し、provisioning は設置したオブジェクトを記録する。運用は収束と health を、サービス観測は顧客境界の通信を記録する。自動化しても、この分担は消えない。

新鮮さは計算後にも必要になる

明らかに壊れた結果より、正しかった古い結果の方が扱いにくい。計算後に topology、resource view、policy、Access Point、依存 controller の状態が変わるからだ。

計算の記録には、入力制約、メンバー、抽象 topology と matrix の version、policy revision、resource snapshot の時刻、参加 controller、期限を束ねるべきである。

再生された結果と再計算された結果を区別できなければ、かつての可能性が現在の権限として流通する。承認の待ち時間が長いほど、期限は運用上の制御になる。

エラー一覧は後工程まで覆わない

RFC 9731 の computation error は、事前計算で何が起きたかを区別する。その後の reservation、provisioning、convergence、traffic validation までの失敗分類ではない。

計算が成功した後に reservation が競合で失敗することもある。複数ドメインの一部だけで設定されることも、operational state が収束しないこともある。抽象パスの性質が維持されても、顧客の観測品質が要件を外れる場合もある。

各工程は成功だけでなく、固有の失敗を記録しなければならない。一つの success 状態へ集約すると、部分成功が完全成功に見える。

計算権限と作成権限を分ける

セキュリティ面では、安全な NETCONF または RESTCONF と NACM による制御が前提になる。設定・運用情報は機微であり、vn-compute 自体が VN 情報を明らかにし得る。

計算するだけでも topology、endpoint、policy、潜在 capacity を知る可能性があるため、無制限に開放すべき操作ではない。それでも、compute を許すことと live VN の create や modify を許すことは同義ではない。

read、compute、configure、reserve、delete を別 capability にすれば、計画システムへ計算だけを許し、本番変更は別の承認済み主体に限定できる。情報開示と状態変更の双方を最小権限で扱える。

計算の破棄と運用ロールバックは違う

事前計算は VN も資源予約も作らないため、不要になった結果は使用をやめ、必要なら再計算すればよい。これは本番状態を戻す作業ではない。

commit 後の撤回は、トンネル削除、容量解放、policy 復元、ドメイン調整、既存トラフィック保護を伴い得る。その時点では実在する状態とコストがあり、復旧結果を証明する必要がある。

両方を「rollback」と呼ぶと、どの工程で現実が変わったのかが見えなくなる。commit 前は提案の破棄、commit 後は運用変更の逆転である。

一つずつ現実を接続する

最初に、受理された計算要求と情報 snapshot を保存する。次に、計算メンバー、matrix 参照、エラーを保持する。その後、承認者を持つ設定判断を作り、必要な全ドメインから資源 admission を集める。実際の tunnel または LSP と設置状態を記録し、operational convergence を観測する。最後に顧客 edge で traffic を確認し、受入れか未解決の差を残す。

証拠を強くするのは、一つの状態を大きく見せることではない。狭い主張を、安定した識別子と時刻で次の主張へ接続することである。

RFC 9731 の最初の線は明快だ。計算されたネットワークは、まだ作られたネットワークではない。

出典