要約

  • 第07版は、単体 OAM テストと利用者が順序を決めるテスト列を表す2つの YANG モジュールを提案し、期間、反復、状態、スキーママウントを組み合わせる。
  • 列が success になっても、意図した版が意図した時間帯に走ったこと、全手順がそろったこと、プローブと業務通信が同じ条件だったこと、原因が一つに絞れたこと、変更が承認されたこと、復旧したことまでは証明されない。

手順を記述できても、結論まで自動化されたわけではない

ネットワーク診断は、一つの測定で終わらない。到達性を確認し、経路を追い、遅延や損失を測り、対象区間を狭め、障害が現れる時間帯でもう一度確かめる。draft-ietf-opsawg-scheduling-oam-tests-07 は、この組み立てを共通のデータモデルにする試みだ。ietf-oam-unitary-test はテストと対象ノードを表し、ietf-oam-test-sequence は複数のテストを利用者指定の順序に並べ、期間や反復回数を与える。

これは運用の足場になる。一方で、オーケストレーターの画面に計画、カウンター、成功表示がそろうと、それだけで原因まで分かったように見える。そこで必要なのは、表示項目を疑うことではない。各項目が証明できる範囲を限定することだ。

Datatracker によれば、第07版は OPSAWG の active な Working Group Internet-Draft で、Standards Track を目指している。RFC 番号はなく、IESG の処理も始まっていない。履歴 には、OPSDIR と PERFMETRDIR の早期レビューがいずれも Has Issues と記録され、YANG Doctors のレビューは未完了である。したがって、本文を実装済み・配備済みの標準として扱ってはならない。

記録1：承認された計画そのもの

草案は RFC 9922 から、スケジュール状態、版、ローカル時刻、直前と次回の実行時刻、成功・失敗カウンターを再利用する。単体テストには複数の ne-config を置き、各ノードの下に機器固有の OAM モデルをマウントできる。

計画名だけでは監査できない。必要なのは、設定全体のダイジェスト、テスト順序、対象ノード、入力値、時刻規則、タイムゾーン、マウントされたモジュールと YANG library の識別子、承認者を固定した記録である。RFC 9922 の version は再利用側が管理し、使わない場合も認められる。単なる数字では内容同一性を保証できない。各実行は、実際に発火した設定版へ戻れなければならない。

記録2：受付ではなく、適用された状態

第07版は planned、configured、ready、on-going、stop、error、success を定義し、テスト列には failure もある。これらは有益な状態だが、報告した実装の内部状態である。

NETCONF や RESTCONF が設定を受理しても、すべての装置で有効になったとは限らない。RFC 8342 は running、intended、applied、operational を分ける。意図された設定が operational に現れないこともある。適用記録には、各ノードの intended と operational の照合、能力情報、スキーマ版、部分失敗を含めるべきだ。

OPSDIR の早期レビュー は、草案がオンデマンド診断を掲げながら、即時実行の規範的 RPC/action を定義していない点も指摘する。下位モデルに存在し得る操作を、この草案の機能として扱うことはできない。

記録3：どの実行回が実際に走ったか

反復規則は予定であり、実行インスタンスではない。キュー遅延、再試行、制御系の切替、再起動、時計補正、反復の重なりがあれば、last-occurrence とカウンターだけでは一意に追えない。

実行ごとに独立 ID を付け、予定時刻、実開始・終了、計画版、オーケストレーター、時計源と誤差、再試行の親子関係、到達したノード集合を結び付ける必要がある。障害時間帯を外れて走ったテストは、成功していても障害時の状態を測っていない。

記録4：全ステップと依存関係

テスト列は ordered-by user である。同時に、ある単体テストが失敗しても後続を実行できる。この性質は残りの証拠を集めるうえで役立つが、「最後まで処理した」と「診断に必要な手順が完了した」を分ける。

PERFMETRDIR の早期レビュー は、単体図の stop が success へ、テスト列の stop が failure へ進む不整合を挙げる。OPSDIR も failure と error、通知、相関、複数ノードの一貫性、ロールバックを問題にしている。完全性記録は、必須ステップ、前提、ノード、実行時刻、結果参照、スキップ、継続判断を一覧化し、欠落により残った仮説を明示しなければならない。

記録5：測定値の意味

スケジュール草案は、個々の OAM 入出力を再定義しない。RFC 8913 の TWAMP YANG モデルのような機器側モデルに委ねる。RFC 8528 のスキーママウントはモデル木を接続するが、インスタンスデータの出所までは仮定せず、マウントポイントの生成や制御が範囲外になる場合もある。

したがって、測定記録はマウント境界を越えて、テスト種別と版、入力、送受信点、方向、パケット集団、転送クラス、サイズ、レート、時間窓、単位、時計、装置、原データまたはダイジェスト、保管先を示す必要がある。結果への参照と、結果の意味は同じではない。

RFC 7799 が区別する active、passive、hybrid も必須の文脈だ。テスト用に生成した通信と、実際の業務通信を観測した記録は、対象集団が異なる。

記録6：影響を受けた通信との同一性

RFC 10014 は、同じトポロジーを通ることと、同じ転送処理を受けることを別にする。同じ装置とリンクを通っても、プローブが別のキュー、QoS、ECMP 経路、policer、シェーピング条件を使えば、利用者通信の障害を再現しない。

比較可能性の記録は、トポロジー、カプセル化、転送クラス、ハッシュ入力、保守ドメイン、時刻、負荷、故障モードのどこまでを共有したかを示す。共有したのが経路だけなら、言えるのも経路についてだけである。スケジュール設定は、実通信との fate sharing を作り出さない。

記録7：原因候補と変更権限

草案の troubleshooting 節は candidate root cause という慎重な表現を使う。RFC 9940 は event、fault、problem、symptom、cause、alert、alarm、incident を分け、原因判定には複数入力があり得るとする。RFC 8632 も、root-cause-resource をクライアント向けのヒントと位置付ける。

診断記録には、観測、競合する説明、除外できた仮説、信頼度、適用範囲、反証条件を残すべきだ。そのうえで、変更権限を別に確認する。テストを作成できる利用者が、経路や QoS、顧客サービスを変更できるとは限らない。RFC 8341 が示すアクセス制御に加え、変更対象、承認者、根拠、影響範囲、作業時間、ロールバック条件が必要になる。

記録8：変更後のサービス

変更が適用され、同じプローブが正常に戻っても、顧客の問題が解消したとは限らない。別経路へ問題を移した可能性、症状だけを隠した可能性、新しい劣化を生んだ可能性がある。

結果記録は、約束を担う面で観測する。対象サービス、利用者集団、SLA 条件、事後時間窓、独立信号、残存アラーム、ロールバック状態、安定継続時間を含める。同じプローブの再実行は有用だが、そのプローブと業務通信の同一性が争点なら、独立した証明にはならない。

この草案は、診断の入口を整える。信頼を作るのは、入口を結論として扱わず、各移行を確認できる場所から記録を返す運用である。