要約

  • RFC 9968 は、ネットワーク管理の次の時代を議論したNEMOPSワークショップの記録である。IABの情報提供文書であり、標準トラックの命令でも、コントローラへ与えられた業務上の委任でもない。
  • 意図された構成、装置に適用された構成、観測された状態、通知された差分は別の記録である。どれか一つが整って見えても、顧客影響、完全性、因果関係、変更を承認する主体までは証明しない。
  • 自動化を説明可能にするには、サービス約束、限界付きの観測、対象を絞った提案、撤回可能なローカル承認を分けて残す必要がある。速い実行と、根拠のない支配を混同してはならない。

「通知がない」は一つの事実ではない

監視画面に変化がないとき、運用者はまず安心したくなる。サービスが安定している可能性はある。しかし別の説明も残る。送信側が止まった、購読が切れた、収集器が遅れている、フィルタが信号を落とした、モデルが必要な状態を表現していない――静けさはそれらを区別しない。

この単純な事実は、管理自動化の権限境界を考える起点になる。RFC 9968 は、2024年のNEMOPSワークショップを記録し、RFC 3535 の2002年ワークショップから何が進み、何が残ったかを検討している。報告書は、使いやすいツール、検証、可観測性、サービス水準のモデル、ベンダー間の統合を求める。SNMPとCLIがなお広く使われ、NETCONFやYANGが多くの装置で完全な機能範囲を持たず、複数モデルの共存が現実であることも述べる。

これは抽象化を否定する議論ではない。むしろ、抽象化がどこで役に立ち、どこで判断を代替できないかを正確にする議論である。サービス・モデルは、個々の機器の断片より契約上の結果に近い表現を与え得る。オフボックスのアダプタは、異なる機器モデルを共通の意図につなげ得る。検証は、送信前に装置が受け入れるかを確かめる助けになる。だが、いずれも「その変更による損失を誰が引き受けるか」を決めない。

文書自身もその射程を限定している。RFC 9968はInformationalであり、Internet Standards Trackではない。参加者の発表と議論メモを解釈・検証せずに記録したもので、明示されない限り合意を表すものではなく、参加者の見解はIABの見解とは限らない。これは価値を下げる但し書きではない。ワークショップを、問題・要件・未解決点の証拠として読ませるための必要な境界である。それを装置や他者のサービスを変更する授権に変えてはならない。

一つの「真実」にしない四つの記録

第一はサービスの意図である。到達性、遅延の範囲、顧客接続、保護されたトラフィック、保守の制約、復旧目標など、組織が守ると約束した結果を記す。そして、その約束の所有者を明らかにする。機器設定は通常、その実現方法の一つに過ぎない。

第二は観測証拠である。テレメトリ、ログ、プローブ、カウンタ、経路観測、アラーム、現場確認を含む。各証拠には取得時刻、出所、対象、欠落、モデルの外側を付けるべきである。正しく届いた流れでも、世界の一部しか表さないことがある。

第三は変更提案である。どのサービス、装置、顧客、時間帯、依存関係を対象とし、どの差分を送り、何を期待し、どう戻すかを明示する。サービス・モデルをベンダー固有の設定へ変換するなら、入力、出力、アダプタの版を残す。残さなければ、後から意図の誤りと変換の誤りを分けられない。

第四は承認記録である。誰がどの範囲を、どの証拠で、いつまで許し、誰が停止・ロールバックできるかを示す。各コマンドに儀式的な人間クリックを求めるものではない。自動ルールそのものに、ローカルな所有者、適用範囲、失効、撤回手段が必要だという意味である。

RFC 8342 のNMDAは、意図した構成、適用された構成、運用状態を分ける。この分類は技術アーキテクチャであり、責任の憲法ではない。適用状態が顧客への約束を満たすか、コントローラが変えてよいかを決めるものではない。それでも「表示された記録は何を表すのか」を先に問わせるため、重要である。

RFC 6241 のNETCONFは候補・稼働構成やconfirmed commitを含む構成管理の仕組みを定め、RFC 8040 はRESTCONFを定める。これらは構造化され、認証され、範囲内で戻せる操作を可能にする。しかし、医療機関のテナント、トランジット顧客、地域の運用チームの誰が中断を受け入れるかまでは知らない。書き込める能力は、結果を決める権利ではない。

観測の改善は判断の代行ではない

RFC 8639 はYANG通知の購読枠組みを、RFC 8641 はデータストア更新通知を、RFC 9196 は能力と更新通知のモジュールを扱う。これらは受信者に、合意されたスキーマに沿った信号を渡す。全ての関連状態がモデル化されていること、翻訳が無損失であること、信号が欠けないこと、信号と原因が同一であることは保証しない。

危険な飛躍は三段階で起きる。モデルが変更可能と示す。だからモデルが決定者だと扱う。だから変更は承認済みだと扱う。最初の段階は試験やカナリアで確かめられる。二番目は別の証拠を要する。運用者の委任、契約、適用される法、そして実際に顧客影響と損失を引き受ける主体である。データ・ツリーのパスからその委任は生まれない。

Heng Luの動くコードの優位、最小初期仕様と局所的な将来決定、現実の層は、ここで編集上の試験になる。共通の表現は相互運用を助けても、後の選択を吸収してはならない。宣言ではなく、実際に稼働するサービスの結果を見る。象徴的な記録を、運用上の事実と取り違えない。

境界を故障で確かめる

成功したトランザクションだけを試しても不十分である。サービス意図、モデル版、装置能力、証拠の鮮度、通知の欠落、提案差分、承認、独立プローブの結果を結ぶ。次に意図的に壊す。テレメトリを一つ失ってもサービスは正常な場合、通知の遅延、モデル葉の拒否、未対応機能、帯域外CLI変更、配布と有効化の間のコントローラ再起動、承認後の対象拡大を試す。どの場面でも、「見えた」ことが「安全に実行できる」ことと同じでない理由が現れる。

Sources