要点

  • 現行のLISPマルチキャスト草案は、カプセル化ルートとなるITRが変わると、受信側ETRが新しいルートへ状態を作り直し、必要な(S-EID,G)を改めて伝える必要があると説明する。
  • AnycastはRLOCの到達性を保ち、アンダーレイの変化をRPF切替に見せられる。しかしETRは物理ITRの交代を認識できないことがあり、後継ITRは次の定期的Join/Pruneまで受信者状態を得られない。
  • Daniel Kadeは、この空白を「ルート継承レシート」と「Join再送債務」で管理することを提案する。いずれも運用上の統治手段であり、LISPやPIMの新フィールドではない。

アドレスが緑でも木は沈黙する

複数ネットワークへ同じ映像を配信する場面を考えよう。送信サイトのIngress Tunnel Routerが停止し、経路制御は共有Anycast RLOCを別のITRへ向け直す。アドレス監視は回復し、マルチキャスト対応アンダーレイでは逆方向パスも新しいインターフェースへ収束する。ルーティング担当の記録に「短時間で復旧」と書くこと自体は誤りではない。

ただし、その記録はサービス全体を表していない。旧ITRには、どの受信ETRがどの送信元とグループを要求したかという状態があった。新ITRが同じアドレスでパケットを受け取れるようになっても、その記憶は自動では移らない。到達可能なルートが、カプセル化すべき内側のフローを知らないまま存在する時間が生じ得る。

これはAnycastの欠陥を指摘する話ではない。Anycastが提供するのは、複数地点から同じアドレスを広告し、経路によって到達インスタンスを選ぶ仕組みだ。背後のプロトコル状態を複製する契約ではない。誤りは、アドレス復旧の証拠を、そのアドレスの背後にある状態機械すべての継続証明として扱うことにある。

draft-ietf-lisp-rfc6831bis-07は現在IESG Evaluationにあり、Proposed Standardを目指す。承認されればExperimentalのRFC 6831を廃止する予定だが、現時点ではRFCではない。2026年9月11日付の第07版と第06版を比較すると、主な変更は規範表現、IGMP/MLD参照、謝辞などの整備である。本稿は第07版に新機構が追加されたと主張せず、現行文書全体が示す状態継承の境界を扱う。

EIDの要求とRLOCの木

LISPはEndpoint IdentifierとRouting Locatorを分離する。サイト内部では送信元EIDとマルチキャストグループが意味を持ち、アンダーレイではRLOCが経路の根になる。端点の名前を場所から離せる利点がある一方、マルチキャストの状態は二つの名前空間をまたぐ。

受信ホストはIGMPv3またはMLDv2で(S-EID,G)へ参加する。境界のETRは送信元EIDを検索し、マッピングの優先度と重みに従って送信サイトのITR RLOCを選ぶ。マルチキャスト・アンダーレイでは、ETRは二つのJoin/Pruneを扱う。Unicastでカプセル化した(S-EID,G)を選択ITRへ送り、別に(S-RLOC,G)をアンダーレイへ作る。前者はITRに内側の要求を伝え、後者はロケータを根とする配信木を構成する。

Unicastアンダーレイでは、ITRが受信ETRのRLOCを明示的なリストとして保持し、各ETR向けに複製する。受信側のETRはLISPヘッダーを外し、内側の(S-EID,G) Multicast FIBでローカル受信者への転送を決める。複製の場所は変わっても、受信意図を送信側ルートが知る必要は残る。

Map-Reply、RIBの経路、RPF成功、PIM隣接、ローカルJoinは、それぞれ価値のある証拠である。しかし相互に代替できない。Map-Replyは候補RLOCを示しても、選ばれた物理ITRへの状態導入を証明しない。RPF成功はアンダーレイの向きを示しても、ルートが内側EIDを知ることを証明しない。受信サイトのJoinが残っていても、遠隔ITRの記憶が残っているとは限らない。

したがって管理対象は、単一の「マルチキャスト経路」ではない。受信者の意図、ETRの境界状態、選択された物理ルート、ITRのEID状態、アンダーレイまたはヘッドエンド複製、受信ETRでの受理、最終受信という連鎖である。所有者もタイマーも各段階で異なる。

物理ルートが交代するとき

草案の第6節は、ITR障害が通常のRPF変更より重い理由を述べる。Unicastなら、到達性に応じて別のロケータを選ぶだけで済む場合がある。LISPマルチキャストでは、選択ITRそのものがカプセル化する配信木のルートである。ITRが到達不能になると、参加中のETRは新ITRへ(S-RLOC,G)状態を作り、新しいルートが必要な(S-EID,G)を知るよう、Unicastカプセル化Join/Pruneも送る必要がある。

ここには明確な継承義務がある。対象は影響を受けたETRの集合であり、引き継ぐべきものは各ETRが要求する送信元・グループ状態である。故障検知、ロケータ選択、Join再送はサイトごとに別の時刻に起こる。一つの「切替完了」時刻だけでは、長い裾に残る受信サイトを表せない。

Anycastは、この交代をETRから見えにくくする。同じRLOCを複数ITRが使うなら、経路はアドレスを新しい実体へ移し、アンダーレイではRPFインターフェースの変更に見える。ETRから見た相手アドレスは同じなので、物理ITRの交代を契機に即座に(S-EID,G)を再送できない。草案は、後継Anycast ITRが次の定期送信で初めてその状態を得ることがあると明記する。

待ち時間を一律の秒数にする根拠はない。実装、PIMタイマー、収束、損失、更新方針、アンダーレイ方式が影響する。毎回パケット損失が起きるとも、一定時間で必ず戻るとも本稿は言わない。言えるのは、アドレス回復と状態回復は別の出来事であり、必要な証拠も別だということだ。

Join再送債務を可視化する

物理ルートが変わった時点で、必要な(S-EID,G)が後継ITRに入ったと確認できないETRを「Join再送債務」として数える。債務という語は責任追及のためではない。多数の受信サイトに分散した未完了作業を、一つの緑色のAnycast指標に消させないためである。

一件の記録には、受信ETR、送信元EID、グループ、旧ITR、想定する新ITR、直近Joinの世代、更新時刻、アンダーレイ方式、解消条件を含める。機器が状態導入の確認を出せるなら利用する。出せない場合は、ITR側の限定的な状態確認と、ETRまたは制御された受信カナリアでのデータ観測を結合する。

Anycast RLOCへのping、RIBの存在、マッピングキャッシュ、PIM隣接、プロセスの生存だけでは債務は消えない。どれも特定の受信意図が新しい物理ルートへ渡ったことを示さない。一つの受信サイトが戻っても、別のETRは次の周期更新を待っているかもしれない。

一方、正当な離脱は正当に閉じられるべきだ。受信者がLeaveした、送信元が終了した、ポリシーで別ITRへ移した、といった理由がある。解消記録には、導入と観測、明示的撤回、規則に基づく期限切れ、または責任者による劣化受容の別を残す。証拠のない消失を復旧と数えてはならない。

ルート継承レシート

Join再送債務を束ねるのが「ルート継承レシート」である。これはDaniel Kadeによる運用提案で、LISPやPIMのパケット形式に加えるものではない。異なる管理面の証拠を一つの決定記録に結び付け、あるチームが自分の層だけでサービス全体を閉じるのを防ぐ。

最初に旧・新の物理ITR識別子、個別または共有RLOC、検知元、時刻、確度、ETRが参照したマッピング版、判断責任者を記録する。共有アドレスだけでは不十分である。問題はまさに、その背後の物理実体が入れ替わったことだからだ。

次に、旧ルートの最終(S-EID,G)、新しい選択、アンダーレイRPF収束、ETRのJoin世代、カプセル化再送、観測可能なら後継ITRでの導入状態を、影響範囲ごとに並べる。収集地点と時計も必要だ。ITRとETRの時計が比較不能なら、二つのタイムスタンプを因果順序に見せてはいけない。

最後にデータ面を記録する。後継ITRが受理した最初のパケット、各サンプルETRでの最初の受理、利用可能ならシーケンスやアプリケーション連続性、損失・重複区間、内側状態の不一致で捨てた不要トラフィック、残債務が合意した閾値に達した時刻である。ルータ証拠しかないのに、アプリケーション正常とは書かない。

ロールバック権限も同じ記録に置く。特定Unicast RLOCへの復帰、後継のドレイン、制御されたJoin更新、別ITRへの移動、暫定的なヘッドエンド複製など、実行可能な手段は実装で異なる。本稿が万能コマンドを作るのではなく、誰がどの範囲で何を実行し、何をもって成功とするかを明示する。

複製位置が証拠の所有者を変える

草案では、複製はサイト内、アンダーレイの中継ルータ、受信ETR、送信ITRのいずれでも起こり得る。マルチキャスト・アンダーレイは中継網に木の状態を持たせ、Unicastアンダーレイは状態を減らす代わりに送信側のコピー数と帯域を増やす。Map-Replyの優先度と重みにより、受信サイトごとに異なるITRを選ぶこともある。

監査は複製地点を追う必要がある。ITRの宛先リストは複製計画であって受信証明ではない。健全な(S-RLOC,G)木も、複数の内側送信元を共有できる。草案が示すように、共有木のため要求していないフローがETRへ届き、内側状態がないので捨てられる場合もある。転送判断は正しくても、共通区間の帯域はすでに使われた。

セキュリティ上も、期待トラフィックの欠落と不要トラフィックの到来を分ける必要がある。悪意ある受信サイトが共有木を通じて正当なサイトへ不要データを流す可能性が草案に記されている。「ETRにパケットが着いた」という一文は、成功、浪費、攻撃のいずれにもなり得る。

診断の空白を成功で埋めない

詳細なlocator reachability、mPITR、LISP環境のmtrace設計は草案の範囲外であり、mtraceは今後の作業とされている。つまり、一般的な経路診断だけでEIDとRLOCの境界を横断した全状態を見られるわけではない。

監視結果には観測層を付けるべきだ。アンダーレイ試験はRLOC経路を、ITR検査は(S-EID,G)導入を、ETRカウンタはデカプセル化と内側検索を、受信者計測は実際の到着を示す。相関すればサービス判断を支えられるが、一つで残りを代用できない。

IETF文書は機構と境界を規定するもので、万能な観測製品ではない。だからこそ運用者は、自分の緑色が何を証明したかを正確に述べる必要がある。「Anycast切替成功」はアドレス移行の結論にとどめ、マルチキャスト復旧には状態と受信者の証拠を追加すべきだ。

出典

  1. LISPマルチキャスト現行草案
  2. 草案の履歴
  3. Datatracker API記録
  4. 第07版HTML
  5. 第07版テキスト
  6. 第06版と第07版の差分
  7. LISPワーキンググループ
  8. RFC 6831
  9. RFC 9300：LISPデータプレーン
  10. RFC 9301：LISPコントロールプレーン
  11. RFC 8059：LISP向けPIM Join Attributes
  12. RFC 7761：PIM
  13. RFC 8487：Mtrace Version 2
  14. RFC 9776：IGMPv3
  15. RFC 9777：MLDv2
  16. RFC 7799：インターネット計測用語
  17. 第07版XML