要約

  • RFC 9833〜9836 は、下位の bearer、顧客向け AC サービス、事業者内部のネットワーク AC、そして L2/L3 VPN と結ぶ参照を別々の YANG モデルとして定義する。
  • 承認・検証済みの要求でも awaiting-processing にとどまり得る。サービス層とネットワーク層の名前も一致するとは限らず、受理や同名だけでは実現を証明できない。
  • PE/SAP の選択、正しい VPN 参照、意図した設定、適用済み設定、運用状態、OAM、実トラフィックまでを別の受領証として追う必要がある。

注文画面には回線があった。しかし、事業者のネットワークには、その注文が指すはずの回線がまだなかった。

この差だけで障害や不正を意味するわけではない。RFC 9833、RFC 9834、RFC 9835、RFC 9836 が意図的に設けた境界である。2025年9月に Standards Track として公開された4文書は、アクセス回線の要求と実現を、参照でつながる複数のモデルに分けた。一つの層の緑色表示が、別の層の事実を無断で代弁しないためだ。

RFC 9833、RFC 9834、RFC 9835、RFC 9836 の情報ページは、IETF の合意と IESG の承認を示す。特定事業者の実装、相互接続試験、注文の受理、機器設定、疎通は示さない。標準化の受領証と運用の受領証は別物である。

bearer が上がっても AC は完成しない

bearer は有線または無線の下位リンクであり、AC はその上に構成され、顧客終端と事業者網の間でデータ交換を可能にする仕組みである。一つの bearer が複数 AC を運び、一つの AC が複数の CE や peer SAP に関係する場合がある。一つの CE も複数 AC を終端できる。

したがって、bearer の正常性を顧客 AC の正常性に読み替えることはできない。共有 bearer 上の一サービスを解約する権限は、他サービスや bearer 全体を消す権限でもない。単一ステータスは、この多重性を最初に失う。

RFC 9834 では、事業者が bearer reference を発行し、顧客が取得して後の AC 要求で使える。顧客が提示した識別子を事業者が拒否する場合もある。AC 識別子の一意性は事業者ドメイン内に限られる。発行者、適用範囲、現在の解決先を伴わない文字列は、普遍的な ID ではない。

顧客モデルは内部配置を知らない

RFC 8309 は、顧客サービスモデルを、顧客が要求または体験するサービスの記述と位置づける。事業者がどう実現するかを記述するモデルではない。RFC 9834 も PE、SAP、装置インターフェース、内部トポロジーを顧客ビューから隠す。

この抽象化により、共通の注文を異なる内部網で扱える。同時に、顧客オブジェクトは、設計上見えない PE/インターフェース配置の証拠にはなれない。注文側で証明できるのは、認証主体、権限、bearer または peer-SAP 参照、サービス AC ID、要求値、検証結果、管理状態までである。

RFC 9833 は awaiting-validation、awaiting-processing、admin-prohibited、rejected などを持つ。awaiting-processing は、承認と検証が終わっていても活性化作業が残る状態を表せる。これを「稼働中」と表示すれば、標準が保持した差を画面が消すことになる。

ネットワーク AC には別の識別子が要る

RFC 9835 の ietf-ac-ntw は、サービス参照を実際のネットワーク AC に対応させ、PE/SAP の配置を保持する。サービスの意図が、事業者の具体的資源へ移る地点だ。

サービス層とネットワーク層が同じ命名規則を使うかは、RFC 自身が配備依存としている。同じ名前になり得るが、同じだと仮定してはいけない。証拠は参照エッジである。文字列一致で結合するシステムは、移行、改名、再利用の後に別注文のテレメトリを表示し得る。

RFC 8969 は、サービス、ネットワーク、デバイスの各モデルを段階として分け、運用状態と統計を上位に返すことを求める。ネットワークモデルの行は、オーケストレーターの意図を表せても、下位装置が適用したことまでは証明しない。

glue は関連付けであって疎通ではない

RFC 9836 の ietf-ac-glue は、AC のサービス ID とネットワーク ID を VPN モデルに結び付ける。RFC 8299 の L3VPN サービスモデル、RFC 8466 の L2VPN サービスモデル、RFC 9181 の L3VPN ネットワークモデルが対象となる。RFC 8345 と RFC 9543 は、トポロジーとサービス保証の周辺構造を示す。

glue が証明するのは、どの VPN オブジェクトがどの AC を参照するかである。資源確保、装置反映、到達性、転送、SLA は証明しない。サービス AC がネットワーク AC A を指す一方、VPN が B を指していても、全オブジェクトは存在できる。存在確認だけの監視は、誤ったグラフを正常と判断する。

意図と運用を比較する

RFC 8342 は、設定値、意図した設定、運用状態を区別する。伝播遅延、ハードウェア、プロトコル、他システムとの相互作用で <intended> と <operational> はずれ得る。注文時刻ではなく両者の比較が、意図のどこまで使われているかを示す。

よって証拠鎖は、主体の認証・認可、bearer の解決、サービス AC の受理、ネットワーク AC への写像、PE/SAP/インターフェース選択、正しい VPN の結合、意図設定、適用・運用状態、そして OAM・到達性・トラフィックの測定まで続く。

RFC 7950 は YANG を定義するが、内部実装を一つに固定しない。RFC 9408 は YANG モジュールのセキュリティ評価を広く扱う。ここから特定の侵害は主張できない。言えるのは、書き込み権限を正しい層と対象に限定すべきだということだけだ。

Heng Lu の最小初期仕様と将来判断の局所化は、共通参照だけを決定的にし、資源選択を運用者に残す考え方である。動くコードの優位性は、その参照が実システムで生きているかを問う。現実を製品とする姿勢に従えば、結論は限定される。4つの RFC は優れた管理図だが、稼働回線の検収票ではない。

情報源