要約

  • 資源対応 SID は既存の SR 命令に帯域、バッファ、キューの選択を加えるが、各ノードでその資源が実在することまでは証明しない。
  • 第20版は、NRP の完全なプロビジョニング前の利用を禁じ、全ノードの変更が終わるまで更新を未完了とし、不整合なバインディングを原則停止させる。
  • 侵害されたノードは容量を過大申告し、割当を省略し、特定 NRP だけを劣化できる。設定の真正性と転送結果の真正性は別物である。

宛先と資源を一枚の札に載せる

RFC 8402 の SR アーキテクチャ、RFC 8660 の SR-MPLS、RFC 8986 の SRv6 は、SID を転送命令として扱う。草案第20版 は新しい SID 種別を設けず、既存命令に資源集合の意味を重ねる。

ローカルな SID は一つのリンクやノードの帯域・キューを選び、グローバルな SID は複数ノードから成る NRP を選べる。だがパケット上の値が示すのは希望するレーンだ。割当が受理されたか、ハードウェアで有効か、全ノードが同じ版か、そして顧客が期待した遅延を得たかは、別の問いである。

RFC 9543 はネットワークスライスを実現する下位資源集合を定義し、RFC 9732 は NRP の構造と識別を扱う。名前の一致は供給の完了ではない。

「完了」は最後の一台まで待つ

第20版では、NRP に参加する全ノードで SID や locator の対応を揃えなければならない。中央システムは完了を確認し、部分失敗時にはロールバックできるべきだ。SID と資源の関連付け失敗は報告必須であり、NRP は完全に構成されるまでサービスに使ってはならない。更新も、関係する全ノードの変更が成功するまで終わらない。

これは分散コミットである。コントローラが要求を送信し終えた時刻でも、九台が成功した時刻でもない。必要なのは参加集合、ノードごとの受理、実際に有効化されたキューやスケジューラ、バインディング版、ロールバックの証跡である。

不整合を検出したノードは、該当 SID を原則転送に使わず、エラーを記録・報告する。正直な故障には有効だが、虚偽には十分でない。草案自身が、侵害ノードによる未割当、容量の水増し、選択的劣化を想定している。

到達性を守る回避路が保証を失わせる

ローカル資源が見つからない場合は破棄が既定だが、運用ノブで best effort へ送れる。割当を超過したトラフィックも、破棄または優先度低下が可能である。best-effort への退避はログと報告の対象になる。

障害中に通信を残す判断は合理的でも、サービスは変わった。到着したパケットは到達性の証拠であり、予約資源の証拠ではない。退避イベントを NRP、フロー、時間帯、契約に結び付けなければ、可用性の緑色表示が SLA の喪失を隠す。

Flexible Algorithm が乗っ取られれば経路と資源隔離の両方が崩れる。さらに入場制御の閾値は、資源パーティションが基礎 SR 転送面を枯渇させるのを防ぐ必要がある。安全な制御チャネルだけでは、この二つを保証できない。

実装報告を認証書にしない

草案は Huawei の複数ルータ系列について本番実装の報告を収録する。しかし RFC 7942 に沿う注意書きは、IETF が投稿内容を検証しておらず、掲載は推奨でも製品一覧でもないと明記する。これは running code の手掛かりであって、相互接続試験や SLA 監査ではない。

Datatracker、履歴、API が示す現在地は、IESG Evaluation の AD Followup と未解決 DISCUSS である。Secdir レビュー と Opsdir レビュー は規範が強化された経緯を示す。第19版、第20版の HTML と XML は文書差分であり、RFC化や普及の証拠ではない。

編集上の明示的な視座として、running code の優先、最小共通仕様とローカル判断、現実の層 を当てはめると結論は単純だ。SID はレーンを名指す。レーンの実在と成果は観測で確かめる。