要約

  • draft-ietf-pim-multicast-over-srv6-01 は、マルチキャスト配信を Segment Routing と直交するものとして扱い、SID 列ではなくネイティブ IPv6 の (S,G)／(*,G) 状態を用いる。
  • Flex-Algo は PIM の RPF 判定に使うユニキャスト経路を変えられるが、RFC 9502 は IP データプレーンへの参加と SR への参加を独立に通知するよう求める。
  • 受入試験では、送信元広告、FAD、IP 参加ノード、RPF、状態の所有者、実転送表、PMSI、各分岐、受信者の結果を別々に確認する必要がある。

数字が一致しても、参加者名簿は一致しない

運用画面に「SRv6: FA128」「IP: FA128」と並ぶと、ひとつの仕組みが端から端まで働いているように見える。しかし RFC 9502 が意図的に分けたのは、まさにこの二つの参加者名簿である。通常の IPv4/IPv6 転送に使う IP Flex-Algo は独立したデータプレーンであり、SR-MPLS や SRv6 の参加とは別に広告される。

この区別はマルチキャストで直接効く。PIM-SM は、ルータが送信元へユニキャストで戻るならどのインターフェースを使うか、という逆向きの問いから RPF 側を選ぶ。送信元プレフィックスがアルゴリズム 128 で広告されれば、草案はその制約付き IP 経路を使ってツリーを構成できるとしている。SR の参加広告が正常でも、IP の参加が欠ければ、この計算の証明にはならない。

RFC 9350 では Flexible Algorithm Definition に計算方式、メトリック、制約が含まれる。同じ番号だけを見ても定義の一致は分からない。未対応の定義を受けたノードは参加をやめ、転送状態を削除し得る。したがって必要なのは「128 対応」という製品フラグではなく、どの定義を、どのデータプレーンで、どのノードが現在実行しているかという記録である。

SRv6 という上位概念は複製命令ではない

Segment Routing のアーキテクチャ は SR をユニキャストの source routing として定義し、マルチキャストへの応用を範囲外としている。SRv6 Network Programming は SR 命令を持つパケットに対する動作を定義する。一方、PIM WG 草案の 01 テキスト は、マルチキャスト配信を SR と直交させ、IPv6-only の SRv6 ネットワークでネイティブ IPv6 マルチキャストを再利用する。HTML と XML も同じ境界を示す。

実際のエントリは送信元、グループ、RPF 入力インターフェース、下流インターフェース集合から成る。各分岐を並べた SID リストではない。ネットワーク全体を SRv6 と呼ぶことと、その中のマルチキャスト木を segment-routed と呼ぶことは別の主張だ。前者から後者は導けない。

制御方式が二つなら、所有権も二つに見えるようにする

草案は PIM だけでなく、中央コントローラによるネイティブ IPv6 マルチキャスト状態の計算と設定も認める。特殊な木を作る場合には有用だが、データプレーンは変わらない。各ノードには正しい入力と下流複製先が必要で、API の成功応答は全ノードのハードウェア適用やパケット受信を保証しない。

PIM とコントローラは異なる送信元・グループを扱う場合に共存できる。この条件は単なる実装注意ではなく、所有権の境界である。同じ (S,G) を両方が担当すれば、PIM の aging が中央設定を消したり、コントローラの再同期が分散状態を上書きしたりする。northbound の経路設定は補完文書に委ねられているため、認可、複数ノードのトランザクション、rollback を本草案から推測してはいけない。

オーバーレイの外側ヘッダーは受信者名簿ではない

MVPN アーキテクチャ と BGP MVPN 手順 は顧客マルチキャスト状態とプロバイダトンネルを分ける。RFC 6515 はプロバイダ基盤の IPv4／IPv6 アドレスを扱い、RFC 7716 は Global Table Multicast へ拡張する。RFC 8950 は IPv4 NLRI に IPv6 next hop を使えるようにする。

草案の例では、PIM-SSM がネイティブ IPv6 のプロバイダ木を作り、MP-BGP が PMSI と顧客マルチキャスト経路を通知し、顧客パケットは IP-in-IPv6 で運ばれる。外側の Next Header が 4 なら内側は IPv4、41 なら IPv6だが、正しい VPN、許可受信者、出口での復号、全分岐の成功までは示さない。しかも草案は、この方式に SRv6 固有の手続きはないと明記する。顧客フローから PMSI、プロバイダ (S,G)、出口 PE、受信者まで、対応関係を追跡する必要がある。

改訂番号を合意や実装実績に読み替えない

凍結した Datatracker API、文書ページ、履歴 は、これを PIM WG の active Internet-Draft として記録している。ヘッダーは Informational を意図するが、担当 AD、shepherd、telechat は表示されていない。RFC、実装調査、相互接続試験、性能報告ではない。

00 版 と 01 版の凍結比較では、日付、期限、改訂番号、ページヘッダーだけが変わり、技術内容は変わっていない。既存 RFC を超える新たなセキュリティ問題はない、という記述も範囲の説明にすぎない。コントローラ書き込みの正当性、FAD の一致、PMSI の正確さを証明するものではない。

出典と限界

凍結資料は 01 text、HTML、XML、00 text、API、status、history である。技術的背景は RFC 7761、RFC 6513、RFC 6514、RFC 6515、RFC 7716、RFC 8402、RFC 8950、RFC 9350、RFC 9502、RFC 8986 に限定した。固有名付き導入、ベンダー対応表、収束時間、損失率、SLA の実測は含まれない。