要約

  • OpenConfigはフィールドを共通化する一方、terminal-deviceモデルではoperational-modeをベンダー固有の識別子とし、対応モード一覧への掲載を求める。
  • NANOG 98の例で5003は発表者の環境におけるOIF 400ZR AppSel 1を指す。共通コードではない。

5003は自動化向きに見える。短く、比べやすく、テンプレートにも写しやすい。だがPhilip BedardのNANOG 98発表には条件が付く。例示環境で5003はOIF 400ZR Application Selection 1を指す。同じスライドはOpenConfigの数値operational-modeが標準化されておらず、実際のAppSelを表す案として6xxxを挙げる。

ここが制御の境界だ。OpenConfigはモードの共通欄を用意するが、数字を共通の光伝送語彙にはしない。terminal-deviceモデルは値をベンダー固有IDとし、装置が提示する対応モード一覧に存在することを求める。その一覧が接続先の認識を示す。

台帳からコントローラーを経てルーターへ設定を渡す際、定義なしに5003だけを複製すれば、文字列は残っても意図は抜ける。標準または組織定義のモード、ローカルID、ホスト側とメディア側の組み合わせ、対象装置の能力一覧を一緒に保持し、適用先でローカル表現を解決する。

光路にも別の検証が要る。設定値、モジュールの動作状態、光学測定値、サービス提供は別の事実だ。書き込み成功だけでは目的のモードや全経路の成立は分からない。

OIFが2026年9月に発表したC-CMIS 1.5はコヒーレントモジュールの管理機能を追加した。10月30日更新のIETF DWDM YANG草案は標準、組織定義、明示モードを区別するが、相互接続は保証しないと記す。語彙が整っても装置能力との対応付けは運用に残る。

資料に複数ベンダー移行の試験表やID不一致による障害はない。示すのは、番号だけではシステム間の契約として弱いことだ。数字は意味より遠くまで移動してしまう。

出典