要約

  • RFC 9961 は Root、Tree-ID、Instance-ID で特定 PTI を指す。sub-TLV が試験するのは CP 全体ではない。
  • active 状態、他の PTI、非隣接 unicast 区間、流入 steering、サービス文脈、利用者への配送は別々に記録する必要がある。

切替前の予備木に Ping を打ち、指定した Leaf からすべて応答が返ったとする。試験は成功だ。しかし、その時点で利用者トラフィックを運んでいたのが旧 PTI なら、「Policy 正常」という表示は別の事実を語っている。プロトコルではなく、集約した報告が対象を取り違えた。

RFC 9961 は 2026 年4月公開の IETF Standards Track 文書で、MPLS カプセル化の SR P2MP Policy に MPLS ping/traceroute を拡張する。SRv6 は対象外だ。公開記録とErrataは文書の状態を示すが、実装や配備を示さない。

階層は RFC 9960 が定める。Policy は <Root, Tree-ID> で識別され、複数の Candidate Path（CP）を持ち得る。CP は制約と最適化目標を持ち、計算不能なら PTI はゼロ、平常時には一つ、make-before-break では複数になり得る。同じ CP で active なのは一つだけで、PTI ごとにトポロジーと複製状態が異なり得る。

RFC 9961 の Target FEC Stack sub-TLV は Address Family、Root、Tree-ID、Instance-ID を運ぶ。仕様は、それが特定 CP 内の特定 PTI を試すもので、CP 自体を試すものではないと明記する。subtype は IANA の MPLS LSP Ping registryに登録された。識別子の正確さは、結論の広さを同時に制限する。

inactive な CP/PTI にも応答させられる。各 CP と PTI を個別に試せるべきで、Replication-SID を理解する下流ノードは、その組が現在 active でなくても処理し応答する。予備経路の事前確認には有用だが、利用者パケットの選択を証明しない。

応答範囲にも落とし穴がある。RFC 6425 の P2MP 手順と RFC 8029 の MPLS LSP Ping 基盤を再利用するが、Leaf 集合を知るのは通常 Root だけだ。Transit は特定 Leaf への経路上に自分がいるか判断できず、egress address 指定には応答しない場合がある。node address で範囲を絞れば、他の沈黙は意図されたものになる。欠落は、要求した responder 集合とセットで読むべきだ。

非隣接 Replication segment の間には別の観測面がある。P2MP OAM は複製木を、unicast OAM は二つの複製区間をつなぐ経路を試す。後者の障害検出は RFC 9961 の範囲外だ。traceroute では unicast 区間の入口を Pipe Mode にし、P2MP 側の TTL を消費させない。RFC 3270 がその TTL モデルを与える。

RFC 9524 の Replication segment と RFC 9256 の SR Policy 選択モデルを重ねると、必要な台帳が見える。controller 計算、配備状態、active CP/PTI、Root の steering、probe identity、response scope、unicast test、Leaf traffic、service receipt は別の時刻と所有者を持つ。

Heng Lu の動作するコードの優位は仕様から観測結果への戻り道を求める。最小初期仕様は共通 identity と局所責任を両立させ、現実の層は Policy という名前が instance と outcome を覆い隠す危険を示す。

したがって、緑の表示には主語が要る。この Root、この Tree-ID、この Instance-ID、この responder scope、この TTL mode、この時刻。そこから先は別の証拠である。