要約

  • 9月6日付のPIM作業部会ドラフトは、トポロジー、アルゴリズム、データプレーンをTADとして運び、通常の最短路ではない制約付き経路にマルチキャスト木を作る。01版の変更は日付と参照版の更新で、処理規則は00版と同じである。
  • TADは各ホップの希望ではない。木上の全ルーターが同じTADに参加しなければならず、値をIGPドメイン外へ出してはならない。不一致ならPIM処理や送信を止める設計である。
  • 導入時の盲点は能力の混在だ。TADを含むGSIのsub-TLVは、未対応隣接が一つでもあるインターフェースで旧GSHへ変換され、その際に捨てられる。

映像配信の経路を二つに分けたいとする。最短路は帯域が足りず、別の経路なら遅延条件を満たす。Flex-Algorithmで条件付きの道を計算し、その道にだけ一つのフローを載せる。発想は明快だ。

現在のMulti-Topology in PIMは、その選択をPIMに渡す仕組みを提案する。01版はPIM作業部会文書で、Standards Trackを意図するが、状態はまだI-D Existsである。01版と00版の差は、日付、有効期限、参照ドラフトの版だけだった。新しい日付を実装実績や合意の証明にしてはならない。

TADは経路指定ではなく意味の共有である

RFC 7761のPIMでは、Joinが送信元またはRPへホップごとに進み、木の状態を作る。データはその逆向きに流れる。ドラフトはTopology、Algorithm、Dataplaneの三つを一組のTADとしてJoin/Pruneへ加える。

TopologyはIGPのどの位相を見るかを決め、AlgorithmはRFC 9350の制約計算を含む。DataplaneはSegment Routing、RFC 9502のIP Flex、または提案中のsoft dataplaneなどを区別する。三つがそろって初めて、どのMRIBから上流隣接を選ぶかが決まる。

したがって、同じ木の全ルーターが同じTADに参加する必要がある。FHRはPFMのsource discoveryでsource/groupとTAD sub-TLVを広告する。LHRはその広告またはローカル方針に基づき、Join AttributeへTADを入れる。中間ルーターは対応する経路表を引く。

パーサーが三つの値を読めても、転送は証明されない。各装置に同じ定義が入り、上流が到達可能で、TIBがMFIBへ正しく反映され、受信側に重複や損失なく届くまで、別々の証拠が必要だ。

IGP境界では同じ整数が別物になる

ドラフトは、ローカルTADを含むPIMメッセージをIGPドメイン外へ送ることを禁じる。MT-IDはプロトコル固有だからだ。RFC 4915のOSPFとRFC 5120のIS-ISでは、同じ数値に同じ運用意味が保証されない。

ここでは境界そのものが権限管理になる。値が正しい形式でも、共通の定義を持たない領域では命令にならない。

同一ドメインにも決定点がある。同じsource/groupを二つのFHRが異なるTADで広告した場合、LHRはoriginator addressの順序で選び、既定では大きい方を優先する。設定と広告が不一致なら、LHRはTAD付きJoinを送ってはならない。TADとRPF Vectorが同時にあれば、ローカル方針でどちらかを無視する。複数TADなら最初を使うことが推奨される。

個別には決定的でも、装置間で同じ方針を選んだことにはならない。ローカル自律性が共有状態へ入り込む場所を列挙しているのである。

止める設計は、理由を残してこそ安全になる

同じ状態について異なる隣接から来たJoinのTADが一致しない、またはTAD対応経路表に上流がない場合、ルーターはPIM処理を止め、管理者へ通知する。FHRも全Joinが同じTADになるまで転送しないことが求められる。

黙って誤った木を作るより安全だが、一つの不整合で正常な受信者まで止まる可能性がある。ログに「PIM停止」しか残さなければ、安全策は原因不明の障害に変わる。受信値、送信元、隣接能力、選択した方針、経路解決結果を一緒に保存すべきだ。

Security Considerationsは、ローカル方針による異なるトポロジー／アルゴリズム選択がループまたは転送不能を起こし得ること、偽ルーターが誤ったTADを広告し得ることを明記する。新しいsub-TLVだけで完全な暗号学的出自確認が得られるわけではない。

後方互換の境界で選択情報が消える

source側のTADは、PFM forwarding enhancementsが定義するGSI TLVに入る。この文書はExperimentalで、RFC Editor queueにある。GSI対応はPIM Helloでインターフェースごとに確認される。

全隣接が対応していればGSIはそのまま転送される。一つでも未対応なら、ルーターはRFC 8364のGSHへ変換する。source、group、holdtimeは残るが、sub-TLVは無視される。TADもそこに含まれる。

つまり、互換動作は「同じ意味を古い形式で運ぶ」のではない。送信元の存在だけを残し、経路意図を落とす。端点の対応確認だけでは足りず、洪水経路とJoin経路の全インターフェースを確認しなければならない。

Heng LuのReality Layersに従えば、ドラフト、設定、受信広告、TIB、MFIB、パケット結果を一つの「対応済み」に畳み込めない。Running-Code Primacyが最後に問うのは、三つの値ではなく、実際の受信結果である。