摘要

  • RFC 9961 用 Root、Tree-ID 与 Instance-ID 指定一个 SR-MPLS P2MP 树实例；这个 sub-TLV 明确不是在测试整个候选路径。
  • 其他 PTI、活动选择、非相邻单播段、入口导流、业务上下文和用户交付都需要独立时间戳与证据。

先看一个仅用于说明的切换窗口。控制器为 make-before-break 建好新树，Ping 到达指定叶节点，回包齐全。屏幕上的“Policy health”变绿，但 Root 仍把用户流量送进旧实例。探针没有撒谎；是面板把一个 PTI 的回执写成了整项 Policy 的结论。

RFC 9961 于 2026 年 4 月作为 IETF Standards Track 文档发布，把 MPLS ping/traceroute 扩展到采用 MPLS 封装的 SR P2MP Policy，不覆盖 SRv6。RFC Editor 记录与勘误检索说明文本权威和当前状态，并不证明任何部署。

RFC 9960给出对象层级：<Root, Tree-ID> 标识一项 Policy；Policy 有一个或多个候选路径（CP）；CP 携带约束和优化目标。计算失败时 CP 可以没有 PTI，稳态下可以有一个，make-before-break 时可以暂存多个，但同一 CP 只有一个 PTI 应处于活动态。不同 PTI 的拓扑和复制状态可能不同。

RFC 9961 的 Target FEC Stack sub-TLV 把 Address Family、Root、Tree-ID 与 Instance-ID 放在一起。正文特别指出，它测试的是某个 CP 中的特定 PTI，不是 CP 本身。对应 subtype 已进入 IANA MPLS LSP Ping 参数表。标识越精确，审计边界也越清楚。

非活动实例同样可以被测。实现应能逐个测试每个 CP 及其 PTI；理解 Replication-SID 的下游节点，即便该 CP/PTI 当前没有承载流量，也要处理请求并回答。这让备用树可以在切换前验收，却也说明“Ping 成功”不能回答用户包当时选中了哪条路径。

回包范围还受节点知识限制。RFC 6425提供 P2MP LSP Ping 程序，RFC 8029提供 MPLS 数据面故障检测基础。Root 知道叶节点集合，许多中转节点却不知道。对这一 FEC 不宜用叶节点地址要求响应：中转节点可能无法判断自己是否在去往该叶节点的路径上，于是不回应。按节点地址收窄响应也会有意排除其他节点。沉默必须和请求范围一起解释。

非相邻 Replication segment 又切出另一套工具。P2MP Policy OAM 检查复制树，连接两个非相邻复制段的单播路径要用单播 OAM；RFC 9961 明确不负责该单播路径的故障检测。做 traceroute 时，单播段起点必须采用 Pipe Mode，避免隐藏路径消耗 P2MP 的 TTL，RFC 3270定义了相关 TTL 模式。

RFC 9524提供 Replication segment 基础，RFC 9256提供 SR Policy 候选路径模型。由此可见完整证据链：控制器计算与版本、下发状态、活动 CP/PTI、Root 本地导流、探针所指实例、被请求的响应集、单播连接测试、叶端流量与业务回执。任何一项都不能替下一项签字。

Heng Lu 的运行代码优先要求从规范回到可观察结果；最小初始规范支持共同标识而不夺走本地责任；现实分层则说明为什么“Policy”这个大名词不能吞掉实例、观测和结果。

所以合格的状态行应当更长：哪个 Root、哪个 Tree-ID、哪个 Instance-ID、活动态为何、请求了谁、用了什么 TTL 模式、发生在何时。超出这句话的结论，都要另拿回执。