要約

  • 第20版はLayer 1/OTNで再利用するidentity、typedef、groupingを定義する。モジュール単体には書き込み可能ノード、読み取り専用状態ノード、RPCがない。
  • 型をimportできることは装置が機能を実装した証明ではない。認証・認可された操作、適用済み状態、両端のラベル、実際の光信号まで別の記録が要る。

import文の先にある空白

コントローラのモデルに ietf-layer1-types のimportが加わる。ビルドは通り、ODU4やtributary slotのidentityを参照できる。差分だけを見れば、光ネットワーク自動化の機能が一つ完成したように映る。

importが証明するのは依存関係である。どの装置がそのrevisionをadvertiseするか、どのfeatureを実装するか、どこにgroupingをinstantiateするかは、まだ分からない。さらに、そのノードへ書く主体が認可されるか、要求がcommitされるか、ハードウェアへ反映されるかも分からない。

Common YANG Data Types for Layer 1 Networks 第20版は2026年9月14日付で、2027年3月18日に失効する。DatatrackerではCCAMP作業部会文書、Proposed Standard予定、RFC Editor Queueとされる。十分な審査を経た文書だが、まだRFCではない。製品のconformance宣言でも、運用結果でもない。

共通型の価値を守るには、importの成功を実行結果へ膨らませないことが必要になる。

共通語彙がなくすもの

光伝送では、トポロジ、トンネル、クライアント信号、サービスが同じ資源を別の視点から扱う。各モデルが独自にODU種別、粒度、TPN、TS、帯域を定義すれば、変換コードと意味のずれが増える。

第20版は1.25G、2.5G、5Gのtributary-slot granularityをidentityとして定義する。odu-type はODUの共通基底、client-signal はEthernet、STM、OC、Fibre Channelなどの共通基底になる。OTN固有のラベルと帯域groupingは、汎用TE型を光レイヤ向けに補う。

これにより、ツールは公開レビューされた形を使える。ベンダ独自拡張も共通baseから派生できる。型エラーを早い段階で止め、異なるモデル間の翻訳量を減らせる。

ただし、派生identityは能力証明書ではない。草案は、関連するコンテナ仕様だけではデータプレーン相互運用性が保証されない場合に、ベンダ固有モジュールで型を定義できると説明する。同じbaseを知っていても、両端が同じ派生型を実行できるとは限らない。

語彙の互換性と実装の互換性は、隣接するが別の問いである。

ライブラリ単体には状態がない

セキュリティ考慮事項は境界を明記する。ietf-layer1-types は再利用されるidentities、types、groupingsを定義する。単体では書き込み可能なデータノード、読み取り専用状態ノード、RPCを公開しない。

groupingのツリーに rw と表示されても、それは別モジュールに展開されたときの形である。実際のデータには、importするモジュール、具体的なschema path、装置実装、datastoreと管理プロトコルが必要になる。

セキュリティ上の情報も、instantiateされたところで発生する。OTN帯域やラベル範囲をトポロジモデルが公開すれば、機微なトポロジを明かす可能性がある。アクセス制御や脅威は利用側モジュールが記述しなければならない。

監査では、装置ごとのYANG library、revision、feature、deviationを記録する。「YANG対応」や「Layer 1 typesを含む」という製品欄だけでは、どのノードが実在し、何が書けるかは分からない。

capabilityはavailabilityではない

装置がODU4を実装していても、今すぐODU4を割り当てられるとは限らない。適切なスロットが使用中かもしれず、もう一方の端点が異なる適応しか持たないかもしれない。

otn-link-bandwidth は、リンクがODU種別ごとにどの程度を支えられるか表現する。草案の100G例では、1個のODU4、10個のODU2、80個のODU0という代替表現が示される。三つを足すことはできない。同じ物理容量の切り方だからである。

OTN labelはTPNとTS集合を含み、同じLSPについてリンク両端で同じlabelを割り当てる必要がある。label rangeはsetupに利用可能な値を表現するが、rangeの読み取りはlockやreservationではない。

選択時のsnapshotが古ければ競合が起きる。片端だけが受け入れる場合もある。candidate datastoreに値が入ってもcommit前かもしれない。commit後にハードウェア制約で適用が遅れることもある。

予約の証拠にはsnapshot時刻、選択したTPN/TS、transaction ID、競合処理、両端の結果、commitとoperational readbackが要る。サービスの証拠にはさらに信号とトラフィックが要る。

ODUflexのgenericは意図的な不足情報

ODUflexには標称ビットレートの計算が異なる六つの形式がある。モデルはgeneric、CBR、GFPのn/k、FlexE、FlexE-aware、packetというchoiceで入力を分ける。

genericは、正確なODUflex形式に依存せずsetupできるtransit domainでforward compatibilityを得るためにある。同時に草案は、必要な場合だけgenericを使い、可能ならtype-specific caseを使うよう勧告する。

genericが悪いのではない。境界が違う。transit nodeに不要な詳細を隠すことで将来の型を通しやすくする一方、edge adaptationに必要な情報までは証明しない。監査記録は、どのchoiceを使ったかを残す必要がある。

さらに、利用可能ODU数だけではODUflex LSPの帯域を推定できない。必要TS数とODTU種別が計算に入る。connectivity matrixやlocal linkのunderlay条件も影響する。

「ODUflex空き1」という表示は、計算根拠を失ったときに最も危険になる。

resizableという文字列とhitlessな現象

第20版は非可変のODUflexとODUflex-resizableを分ける。後者はhitless resizing手順のsupportや、可変LSP数の別上限を記述できる。

schema中のidentityは概念名を確立する。装置がadvertiseすれば宣言されたcapabilityになる。configurationに現れればintentになる。いずれも、特定のLSPが無停止で容量変更したというmeasurementではない。

hitlessを主張するなら、両端対応、追加slot確保、前後のoperational state、変更区間のalarm、error、client trafficを時刻付きで示す必要がある。型は試験項目を明確にするが、試験を完了させない。

認証済みでも適用済みとは限らない

NETCONFとRESTCONFはYANGデータへの操作を運ぶ。secure transportと相互認証は、設定された信頼の下でsession peerを確かめる。NACMはその主体が特定のcontentやoperationへアクセスできるか決める。

payloadがschema-validでも、NACMに拒否され得る。認可済みでも、資源競合で失敗し得る。candidateの検証成功はcommitではない。intended stateのcommitはoperational stateへの反映完了と同じではない。

NMDAがintentとoperationalを分けるのは、非同期適用やsystem-derived valueを正直に表すためである。光レイヤでは、装置状態の後にも物理観測が要る。cross-connect activeと、signal continuityやclient trafficは別のreceiptである。

障害時に残る記録

最初に文書revision、module hash、依存関係、validatorを残す。次に各装置のmodule-set、feature、deviationを残す。操作ではauthenticated principal、NACM decision、operation、datastore、payload hash、transaction、commit、rollbackを残す。

資源ではODU、client signal、granularity、TPN、TS、ODTU、priority、connectivity constraint、同時割当を残す。ODUflexではchoiceと計算入力を残す。最後にalarm、optical metric、error、client trafficを残す。

Heng Luのrunning-code原則は、標準文書を軽視するものではない。文書は共通構造に強く、実装は実行した内容に強く、観測は結果に強い。上流の証拠が下流の結論を借りないことが、全体の信頼性を上げる。

情報源が証明しないこと

凍結した情報源は第20版の型、文書状態、管理プロトコルとdatastoreの境界を示す。特定製品の準拠、ネットワークの採用、光パスの確保、end-to-end serviceは証明しない。

本稿はベンダを評価せず、普及率も推定しない。結論は限定される。型が共有されたことは重要な前進である。光パスが存在するという主張は、running systemの別の証拠を待たなければならない。

Sources