要約

  • RFC 9835は、サービス側のAC参照を網内で実際に構成するACに保持させる。これで要求と実装を照合できるが、ベアラーの継続、転送、顧客通信までは証明しない。
  • 網内AC名はノード内の名前である。プロファイル継承、局所上書き、親子関係、管理状態、運用状態を残さなければ、表示上の一致が誤った履歴を作る。
  • 完了を示すには、正しい対象への投入、実効設定、観測状態、範囲を限定したOAM、サービス全体、顧客トラフィックまで別々の受領記録が要る。

同じ受付番号が、二つの異なる成功を隠した

支店向け回線を注文すると、サービス窓口は参照番号を返す。オーケストレータはPEを選び、接続回線を作る。両方の画面に同じ番号が表示されれば、注文の取り違えは減る。しかし、物理・論理ベアラーが切れている、VLANが違う、経路ポリシーが古い、VPNの別拠点が未完成という事態は残る。

参照番号は「どの要求とどの対象を結んだか」を説明する。パケットが届いたとは述べていない。

RFC 9835は2025年9月の標準トラック文書であり、RFC Editorの記録がその文書IDと状態を示す。ietf-ac-ntwは、サービス提供の前または途中で、プロバイダー網のAttachment Circuit（AC）を構成するモデルである。網内ACには顧客へ公開したサービス側参照も保存できる。

要求、参照、網内構成、観測状態、顧客結果は一本の証拠鎖に並ぶ。それぞれが同じ意味を持つわけではない。

ベアラーとACを一つの「回線」に畳まない

RFC 9833では、顧客ノードやサイトをプロバイダー網につなぐ物理または論理リンクがベアラーであり、その上でデータ交換を可能にする設定がACである。一つのベアラーに複数ACを載せられる。一つのACが複数の相手SAPに結ばれる場合も、一つのSAPが複数ACを終端する場合もある。

したがって、ベアラー障害は複数ACへ波及し得る一方、単独ACの設定誤りはベアラー障害を意味しない。ベアラー参照は配置先を特定しても、サービス開通の証明にはならない。

RFC 9834はベアラーとACを顧客向けサービスとして扱い、RFC 9835は網内実装を扱う。RFC 9836はL2VPN/L3VPNのサービス・ネットワークモデルからACを参照する接着層を定義する。境界が残るからこそ、どの層が何を決めたかを監査できる。

記録にはサービス参照、network、node、ノード内AC名、SAP、ベアラー、対応付けの有効期間が必要である。単一の「回線ID」だけでは、実装移行を同一状態と誤認しやすい。

svc-refは結合キーであって結論ではない

RFC 9835は、サービスモデルが公開するAC参照を使い、サービス要求と網内で実際に構成したACの相関を容易にする。だが網内AC名の一意性はノード内に限られる。サービス層とネットワーク層が同じ命名規則を使うかどうかも、導入ごとの判断である。

別ノードに同じac-17が存在しても矛盾しない。安定した顧客参照が、移行後に別ノードの実装へ結ばれることもある。裸の文字列だけで照合すれば、別の対象を同じ履歴へ混ぜてしまう。

受領記録は、サービス参照、ネットワーク、ノード、ローカルAC、SAP、対応付けを決めた主体、エポックを一組で保持すべきだ。RFC 8969が区別する顧客サービスモデル、ネットワークモデル、デバイスモデルの間では、翻訳そのものが責任ある操作となる。

実効設定は継承と上書きから作られる

RFC 9835は共通設定をネットワークレベルのプロファイルに置き、ACへ継承させられる。同じデータをACで細分化すればローカル値が優先する。実効設定は一つのファイルではなく、プロファイル版と上書きを解決した結果である。

監査には、プロファイル名だけでなく版、継承値、上書き、最終値の出所、対象へ送った実効設定のハッシュが要る。後日のプロファイル変更で過去の説明が書き換わってはならない。

RFC 9836でも、参照されたAC情報とVPNアクセス内の重複情報があればAC情報が優先する。これは意図の競合を解く規則であって、原子的適用、装置間の同じ解釈、完全なロールバックの証拠ではない。

RFC 8342のNMDAは意図・設定と運用状態を分け、RFC 8345はRFC 9835が拡張する基礎ネットワークモデルを提供する。「オブジェクトがある」より、「何を意図し、何が実効となり、何が観測されたか」が重要だ。

親ACの削除は子の運命も決める

複数の相手SAPで共通する属性を親ACに持たせ、固有情報を子ACに持たせる構成ができる。子は親から継承する。RFC 9835は、親ACを削除したなら全子ACも削除しなければならないとする。

モデル内の孤児を防ぐ一方、一回の管理操作の影響を拡大する。スキーマは、コントローラが正しい子を列挙したこと、デバイス状態を安全な順序で除去したこと、無関係なサービスを守ったこと、課金や通知が同期したことを証明しない。

削除前には親、子、SAP、サービス、ベアラー、実効プロファイル、運用状態を影響集合として凍結する。実行後は装置状態と顧客試験で照合する。親の行が消えただけでは、残留転送も顧客影響も否定できない。

管理状態と運用状態は食い違ってよい

RFC 9835は管理状態と運用状態を別に保持し、その不一致を異常検知のきっかけにできる。RFC 9833の承認待ち、処理待ち、管理上禁止、拒否といった状態はワークフローを語る。パケットを語らない。

承認済みでも未開通、設定済みでもdown、インターフェースupでも誤VLANという場合がある。ローカルACが正常でもVPN全体が正常とは限らない。

RFC 9408のSAPは、サービスが提供され得るプロバイダー側参照点である。あるSAPで観測したサービス状態は、複数SAPを結ぶ全体状態ではない。RFC 9181、RFC 9182、RFC 9291はVPNの型とネットワークモデルを、RFC 9543はネットワークスライスの枠組みを与える。一つの局所状態はそれら全体の代理人ではない。

証拠鎖は、要求、受付と参照、network/node/SAP/ACへの対応付け、継承解決、対象への投入、運用観測、範囲限定OAM、エンドツーエンド状態、顧客トラフィックを区別する。九つのDBを作る必要はないが、下位の受領が上位の意味を勝手に得てはならない。

資料は特定導入、製品適合、障害、普及率、費用削減、SLA結果を示していない。本稿の証拠設計は運用上の提案であり、RFCへの追加要件ではない。

読み取り権限も無害ではない

RFC 9835は、無権限の読み取りが顧客のpeer-sap-idを漏らし得るとする。書き込み可能な部分は経路、フィルタ、暗号、鍵、サービス結合へ作用する。参照と実装の結合を変えられるアカウントは、メタデータ以上を動かせる。

商用受付、ネットワーク意図、デバイス投入、運用観測には別々の権限を与える。ログには認証主体、範囲、変更前後の値と結果を残す。「API成功」だけでは権限も現実も説明できない。

RFC 9835の長期的な意義は、約束と実行の継ぎ目を追跡可能にしたことにある。その参照が独立観測と顧客結果まで続くなら自動化は説明責任を持つ。参照だけで案件を閉じるなら、標準化されたのは提供ではなく約束である。

参考資料