要約
- IESGは9月9日、ACTNをパケット・光統合に適用する第20版ドラフトについて、23日までの最終意見募集を開始した。想定ステータスはInformationalで、締切時点では承認もRFC化もされていない。
- 部分要約方式では、MDSCはパケットTEトポロジーを詳細に把握する一方、光ドメインからは抽象ビューだけを受け取る。光PNCはローカル経路計算と内部情報の管理を続ける。
- 抽象ビューが示すのは、特定の政策下における潜在的接続性である。物理在庫、予約、設定完了、エンドツーエンドの実測結果には、それぞれ別の証拠が要る。
今回の決定は、まだ「決めるために聞く」段階にある
9月9日付のIESG告知は、Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) への最終コメントを求めている。期限は9月23日、目標はInformational RFCである。
取材締切時のIETF Datatrackerは「In Last Call」と表示していた。したがって現時点で言えるのは、IESGが最終審査に向けた意見募集を始めたことまでだ。承認済み、RFC番号確定、導入必須、相互運用確認済みという意味にはならない。
Document Shepherdのwrite-upには技術概要と担当者はあるが、論争点、既存実装、ベンダーの導入予定を尋ねるテンプレート欄には具体的回答がない。記載がないから実装が存在しないとは言えない。しかし、この記録を採用実績の証拠に使うこともできない。
ACTNが分けるのはネットワークだけではなく、知識の所有者だ
パケットと光をまたぐサービスでは、IP/MPLSの経路、光トランスポンダ、波長、物理ポート、複数の管理ドメインが関係する。すべてを中央に集めれば一括計算はしやすくなるが、機密性、規模、ベンダー依存、障害時の責任まで中央に集中する。
ACTNでは、Multi-Domain Service Coordinator（MDSC）がサービス意図をまとめ、Provisioning Network Controller（PNC）が各ドメインを制御する。第20版ドラフトの「部分要約」では、MDSCはパケットドメインのTEトポロジーを完全に見られるが、光側については抽象ビューを受け取る。光PNCが域内経路を計算する。
より完全な情報をMDSCに渡す構成も示されている。ただしドラフトは、規模拡大の問題と、最適な光経路がドメインごとに異なるベンダー固有属性に依存し得ることを挙げる。情報量が多いほど無条件に正しいのではない。完全知識と部分要約は、計算、秘密、運用責任をどこに置くかという異なる選択である。
抽象化は情報不足ではなく政策の結果である
RFC 8453は、ACTNの抽象化をネットワーク政策と結びつけている。PNCは技術固有の属性や内部トポロジーを隠し、上位には潜在的接続性を提示できる。どのMDSCにどの詳しさで渡すかは、認証され、アクセス制限され、設定可能で、政策に基づくべきだとする。
RFC 7926では、抽象トポロジーが境界点間の潜在接続を帯域や遅延とともに示す例がある。基盤ネットワークや資源利用が変われば、定期または差分更新が必要になる。ビューの値だけを切り出し、生成時刻と更新条件を落とせば、正しかった情報を誤って使うことになる。
RFC 8795は、プロバイダーのNative TE topologyと、個別クライアント向けのCustomized TE topologyを区別する。顧客の要件や権限に応じて違う地図が提示されてもよい。また、レイヤー間のtransitional TE linkは、サーバー層トレイルがまだ確立していない段階の潜在接続性を表す補助構造とされる。
つまり抽象ビューは、「物理台帳から行を削ったもの」ではない。「政策Pの下で、クライアントCが時点Tに検討してよい選択肢」を表す独立した制御対象だ。評価するなら、完全さではなく、発行主体、対象、政策版、元データ、鮮度を問うべきである。
Loose pathでは、中央が選ばなかった経路が実際に使われる
ドラフトでは、MDSCがPNCへstrict pathまたはloose pathを渡せる。loose pathなら、PNCが自ドメイン内の完全な経路を決め、その選択をMDSCに報告する。光PNC内部の発見や設定方法は一般にベンダー固有で、文書の対象外だ。
この仕組みはドメイン自治を守る。一方、MDSCの計算ログだけでは実行過程を説明できない。そこに残るのは、受け取ったビューと境界条件から中央が考えた候補である。光PNCがどの経路を選んだか、資源を確保したか、機器設定が通ったか、後で保護切替が起きたかは、別の記録にある。
特にmuxponderでは、一本の幹線ポートを複数のクライアントポートで共有し、装置設計によって接続可能な組合せが限定されることがある。抽象的な総容量が足りても、具体的なポート対は成立しないかもしれない。LAGも、論理的にはupでも、失われたメンバー数によって期待した冗長性を満たさない場合がある。
したがって、証拠は次の順序を飛び越えてはいけない。
ビュー提示 ≠ 経路計算 ≠ ドメイン確約 ≠ 設定反映 ≠ サービス観測。
自動化によって一連の処理が高速化しても、状態の意味は統合されない。成功通知には、計算成功、予約成功、設定成功、疎通成功のどれなのかを残す必要がある。
未解決点は公開された作業境界であって、障害報告ではない
第20版は、経路計算モデルの拡張、SR-TE設定、LAGの最小アクティブメンバー数、通常の負荷分散とは異なるトラフィック分割、muxponderの接続制約などをギャップとして列挙する。運用者にはベンダーが必要機能を支えるか確認するよう求める。
これは完成を装わないための重要な情報だ。ただし、特定ネットワークの停止や製品の欠陥を報告したものではない。文書には、そのような事故、導入結果、費用削減、SLA達成、相互運用試験の証拠はない。
運用上は、パケットと光を横断する監視が必要になる。片方の障害がもう一方へ波及し、切り分けや復旧が難しくなる可能性がある。統合された操作面が一枚でも、観測面まで一枚に省略してよいわけではない。
認可は行為の入口を守るが、結果を保証しない
ドラフトはRESTCONF、NETCONF、PCEPの安全な通信と、接続・資源要求への細かなアクセス制御を扱う。RFC 8341はNACMを定義し、RFC 8040はRESTCONF、RFC 6241はNETCONFの基盤を示す。
認証は操作者を確かめ、認可は試せる操作を限定する。しかし、認可済みの要求でも資源不足やローカル制約で拒否される。保護された応答でも、計算結果は設定完了ではない。アクセスログは権限の証拠であって、帯域、遅延、復旧の実績ではない。
この区別がなければ、技術的失敗が権限違反として誤読されたり、正しい権限設定がサービス保証の代用品になったりする。
詳細を漏らさずに、決定の受領証を残す
物理トポロジーを公開しなくても説明責任は作れる。私は、状態の受け渡しを結ぶクロスレイヤー決定受領証を提案する。
最初に記録するのは抽象ビューの身元だ。トポロジーID、版、対象クライアント、発行PNC、抽象化政策の責任者、生成時刻、有効期限、鮮度を残す。Native topologyはドメイン内に置き、監査用のハッシュまたは保護された参照で結べばよい。
次に、サービス意図、制約、要求主体、アクセス判断、MDSCのソフトウェア版と政策版を書く。中央計算と委任計算を分離し、loose pathなら境界点と制約を記録する。MDSCが選んでいない域内経路を、中央の決定として後から描いてはいけない。
資源確約と設定反映も別欄にする。各ドメインが予約・確約した範囲と期限、その後のパケット・光設定時刻、ローカル経路参照、阻害条件、保護状態を残す。最後に測定窓、到達性、性能、アラーム、復旧、ロールバック、訂正を接続する。
この受領証はDaniel Kadeの編集提案であり、IETFの必須要件ではない。Heng LuのThe Policy Mirrorが求める主体・政策・証拠の分離を、多層制御へ移したものだ。Minimum Initial Specificationはローカル実装を奪わない小さな共通面を支え、Why BTW Media Existsは設計上の可能性を現実の成果として報じない基準を与える。
抽象化の役割は、すべてを中央へ集めることではない。見せないものを残したまま協調し、「できるかもしれない」が「実際にできた」へ変わる各地点だけを検証可能にすることにある。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加