要約

  • RFC 9960はRootとTree-IDでSR P2MP Policyを識別し、Leaf集合、候補パス、P2MP Tree Instanceを区別する。これらは転送状態の識別子であり、顧客や組織の受信権限ではない。
  • RFC 9961は候補パス内の特定PTIを対象にできる。仕様自身が、候補パス全体の試験ではないこと、SRv6ではなくMPLSだけを対象とすることを明記している。
  • 「マルチポイント配信対象レシート」は、会員判断とPolicy、候補パス、PTI、Leaf、コントローラー世代、OAM範囲、切替完了を結ぶ。これはDaniel Kadeの編集上の提案で、IETF要件ではない。

ツリーが知るのは複製先である

ポイント・ツー・マルチポイントの利点は、共通区間で同じデータを何度も運ばないことにある。Rootから一つの流れを送り、経路が分かれる場所で複製し、それぞれのLeafへ届ける。入口で受信者ごとの完全なコピーを作るより、共通リンクを効率よく使える。

RFC 9960は、この仕組みをSR-MPLSとSRv6の双方で扱うための構造を定めた。Policyは<Root, Tree-ID>で一意に識別され、Leaf集合と複数の候補パスを持つ。候補パスにはトポロジーや資源の制約、最適化目標を置ける。コントローラーはそれに沿ってPTIを計算し、各ノードにReplication segmentを設定する。

識別が細かいのは、複製状態の取り違えが大きな影響を持つからだ。ただしLeafという語は、ツリーの終端、または受信しながらさらに複製するBudを示す。そこに現在の契約、テナント権限、緊急連絡網、イベント参加資格といった意味は含まれていない。

配信対象は別の機関が決める。契約台帳、IDロール、テナント管理面、当番表などが起点になり、それを自動化がネットワークアドレスとサービスコンテキストへ変換する。その変換が古ければ、転送は誤った名簿を正確に実行する。

これは標準の欠点ではない。相互運用のための最小仕様が、各組織の商取引や権限体系まで決めないのは自然である。だからこそ、ローカルな判断を標準の識別子へ結ぶ記録が必要になる。

同じTree-IDの下で実体は入れ替わる

一つのPolicyには複数の候補パスがあり、RootはRFC 9256の規則でアクティブ候補を選ぶ。制約を満たす木が計算できなければPTIはゼロであり、make-before-breakでは一時的に複数のPTIを持てる。

ただし、候補パスでアクティブにできるPTIは一つだけである。RFC 9960は、アクティブ候補のPTIが複数同時に動けば、Leafへ重複したトラフィックが届き得ると警告する。

切替では、新しいPTIを構築して有効化し、その後に古いPTIを削除できる。二つは同じTree-IDを共有してもInstance-IDが異なり、中間の複製状態も異なる。運用画面がPolicy単位の緑色だけを残せば、どちらを試験したのか、共存が何秒続いたのか、重複が起きなかったのかが消える。

さらに、PTIは通常一つのマルチポイントサービスに結び付くが、サービスコンテキストで区別できれば複数サービスを運ぶこともできる。ツリーの健全性と、あるサービスの配信対象の正しさは、最初から同じ命題ではない。

コントローラーの実行権限と会員決定権

RFC 9960では、運用者、ネットワークノード、または機械がRoot、Leaf集合、候補パスを供給できる。コントローラーはツリーを計算し、Replication-SIDを割り当て、PCEP、BGP、NETCONF/YANGなどで状態を実体化する。静的ツリーを明示的に渡す構成もある。

したがってコントローラーは強い実行権限を持つ。新しい受信先へパケットを到達させ、失敗を再試行し、インスタンスを切り替えられる。しかし、そのAPIを操作できることと、サービスの会員を決める権限は同じではない。

Heng LuのPolicy Mirrorが示すのは、この差である。稼働中の制御面は、実際に誰がネットワークを動かせるかを映す。だから監査すべき重要な証拠になる。一方で、コードが受け入れた操作だけを根拠に、その操作の制度的正当性まで推定してはならない。

部分的な失敗も世代ごとに残す必要がある。SID競合などでReplication segmentの設定に失敗した場合、RFCは理由の報告、再試行回数の上限、レート制限した警告を勧める。成功した再試行が失敗世代を上書きすると、不完全な木が存在した時間と除去の有無が見えなくなる。

RFC 9961が試験するもの

RFC 9961は、MPLSを使うSR P2MP Policy向けにpingとtracerouteを拡張する。Target FEC Stackは候補パスとPTIを明示し、Root、Tree-ID、Instance-IDを持つ。対象を「マルチキャスト一般」ではなく、一つの実体へ絞る設計である。

その結論も絞られている。新しいsub-TLVは候補パス内の特定PTIを試験するのであって、候補パスという抽象全体を試験しない。対象はMPLSのReplication-SIDであり、SRv6は範囲外である。応答者を限定する機構も、不必要な処理を避けるためのものだ。

成功応答が証明するのは、ある時刻に、指定したMPLS転送インスタンスについて得た観測である。アプリケーションが利用可能な形で受け取ったこと、受信組織の資格が続いていること、切替中に重複しなかったこと、SRv6でも同じこと、コントローラーへの入力が承認済みだったことは証明しない。

限界を明示することでOAMの価値は上がる。狭く正確な観測は、会員台帳、設定ハッシュ、変更承認へ結合できる。意味を広げた緑色ランプは、後から検証できない。

配信対象レシートの構成

最初に保存するのはネットワーク外の判断である。サービスとコンテキストの識別子、権威ある会員ソース、その版と有効期間、承認者、除外対象を記す。次に、安定した主体IDからLeafまたはBudのアドレスへの対応を記録する。アドレスは再割当され得るので、単独では会員証明にならない。

技術側には<Root, Tree-ID>、候補パスの<Protocol-Origin, Originator, Discriminator>、制約、最適化目標、選択理由を置く。PTI側には新旧Instance-ID、正確なLeaf/Bud集合、コントローラーと設定の世代、SID割当、ノード別の設定結果を置く。

観測欄は、OAM方式、RFC 9961を使う場合のMPLS限定、対象PTI、応答範囲、時刻、Leaf別結果を保持する。切替欄は、有効化順序、共存期間、重複観測、ロールバック条件、旧PTIの撤去証拠を持つ。最後に、現存するアクティブ・バックアップ双方を最新会員一覧と照合し、レシートの期限と未証明事項を明記する。

ハッシュは後からの差し替えを検出できるが、会員ソースの正当性や測定器の真実性までは保証しない。受信者情報は機微になり得るため、公開記録では件数、時刻、変更理由、例外だけを示す方法もある。

この「レシート」はローカルな運用提案である。RFC 9960/9961の新フィールドでも、IETF適合証明でもない。

削除を完了させる

追加には成功イベントが多い。申請、設定、インストール、応答が連続する。削除はしばしば「見えなくなった」という不在だけで済まされる。しかし配信対象の撤回は、アクティブPTIだけでなく、バックアップや途中まで設定された失敗世代にも届かなければならない。

完了記録は、旧PTIへRootからトラフィックが導入されないこと、複製状態が撤去されたこと、削除対象がバックアップにも残っていないことを分けて証明する。「非アクティブ」と「削除済み」は同義ではない。

RFC 9960のセキュリティ考慮事項は、SRドメイン境界の保護不足による外部注入や、コントローラーが作る複製ループによるストームも挙げる。Leafの応答成功は、それらの統制を自動的に検査しない。

限界と出典

資料は、特定事業者の導入、不正なLeaf追加、現実の重複配信、攻撃、性能向上を証明しない。ここで扱うのは、公表された仕組みとリスク、そしてそれを採用する組織に残るローカルな説明責任である。

結論は小さいままでよい。Tree-IDは転送Policyを、Instance-IDはその一つの実体を、RFC 9961のpingはMPLSデータ面の一観測を示す。配信対象を決めた根拠は別の権威から取得し、その木と一緒に保存しなければならない。