摘要

  • RFC 9960 用根节点与 Tree-ID 标识 SR P2MP Policy，并在其下区分叶节点、候选路径和 P2MP 树实例。这些标识描述转发状态，不证明客户、租户或机构享有接收服务的权利。
  • RFC 9961 可把探测指向某条候选路径中的特定 PTI。规范明确说它不是在测试候选路径整体，而且只覆盖 MPLS，不覆盖 SRv6。
  • “多点受众凭证”应把权威成员决定与政策、候选路径、PTI、叶节点集合、控制器版本、OAM 范围及换树收尾绑定。这是 Daniel Kade 的编辑性建议，不是 IETF 要求。

会复制数据，不等于知道该给谁

点到多点的技术价值来自减少重复。在从入口到多个目的地的公共路段上，数据只传一份；到路径分叉处，复制节点再把它送往不同分支。根、复制节点和叶共同形成一棵分发树。

RFC 9960 为 Segment Routing 中的这类树定义了共同架构，既包括 SR-MPLS，也包括 SRv6。一个 SR P2MP Policy 由 <Root, Tree-ID> 唯一标识，内部包含叶节点集合和一个或多个候选路径。候选路径可带拓扑、资源约束和优化目标，控制器据此计算实际的 P2MP Tree Instance，也就是 PTI。

这种标识精度非常重要。政策、候选路径、实例和具体节点上的复制状态都有各自身份，故障才能被定位，换树也能被追踪。然而，叶节点这个词只说明转发在何处终止，或者 Bud 节点在何处一边接收、一边继续复制。它不说明那个地址背后是有效客户、已撤销租户、临时会场，还是刚被重新分配的设备。

受众资格来自别处。可能是合同系统、角色名录、租户控制面、应急名单或一次有责任人的人工决定。网络自动化取得这份人口清单，再把主体映射为地址、服务上下文和叶节点。映射一旦落后，P2MP 树越准确，执行错误名单就越有效率。

这不是 RFC 遗漏了一个字段。可复用的互联网标准本就不应替每家运营者决定商业或制度成员关系。标准负责让机制互操作；本地机构负责回答谁有权把某个接收者加入服务。

一个 Tree-ID 下可能发生多次现实变化

同一政策可以有多条候选路径。根节点按照 RFC 9256 的决胜规则选择活动候选路径。一条候选路径如果无法满足约束，可能没有 PTI；在 make-before-break 期间，也可能同时保留新旧 PTI。

RFC 9960 要求一条候选路径只能有一个活动 PTI，并警告：如果活动候选路径中有多个 PTI 同时活动，叶节点可能收到重复流量。由此可见，Tree-ID 不足以表示一次具体运行事实。新旧实例可共享政策身份，却有不同 Instance-ID、不同中间复制状态和不同生命周期。

控制器可以先创建新实例，完成节点安装后激活，再撤掉旧实例。这种“先建后拆”能减少中断，却也制造一个短暂的双重状态期。只显示“政策正常”的仪表盘，会把最值得核查的时段抹平：流量究竟由哪个实例承载，两者是否意外重叠，探测又落在哪一个实例上？

运输树与服务也不是严格一一对应。RFC 说一项 PTI 通常关联一个多点服务，但在根和叶能够用服务上下文区分时，一项 PTI 也可以承载多项服务。因此，“这棵树健康”不能替代“这项服务的受众正确”。前者是运输命题，后者包含成员权威和上下文映射。

控制器拥有实权，却未必拥有成员授权

RFC 9960 允许运营者、网络节点或机器把根、叶集合和候选路径交给控制器。控制器可计算拓扑、分配 Replication-SID，并通过 PCEP、BGP、NETCONF/YANG 等机制安装复制状态。也可以跳过计算，安装明确给定的静态树。

这使控制器成为真正的权力面：它能让哪些节点开始复制，决定哪个实例被准备，处理安装失败，并推动切换。但它得到的往往是上游决定的投影，而不是决定权本身。某项 CRM 记录、合同、身份角色或排班表才是受众来源，控制器只看见被解析后的地址。

投影会漂移。上游已删除一名成员，队列里仍滞留旧任务；地址换了主体，映射缓存没有换；自动化在超时后重放旧请求；根节点更新了，新实例的一片叶仍保留旧服务上下文。每个系统都可以在自己的字段范围内报告成功，整个分发关系却已经不对。

Heng Lu 的 Policy Mirror 在这里格外锋利：运行中的基础设施揭示谁事实上能令数据复制。正因为它显示实际权力，才不能把“能调用控制器”误写成“有权定义受众”。代码提供权力行使的证据，不为权力自动签发正当性。

带有姓名和边界的探测

RFC 9961 为采用 MPLS 封装的 SR P2MP Policy 扩展 ping 与 traceroute。探测请求必须指明候选路径和特定 PTI；新的子 TLV 携带 Root、Tree-ID 与 Instance-ID。相比一句含糊的“多播通了”，它把观察对象缩小到一个实际树实例。

规范也主动限定了结论。它明确指出，这个子 TLV 测试的是候选路径中的特定 PTI，不是在测试候选路径这个抽象整体。机制仅适用于 MPLS Replication-SID，不覆盖 SRv6。响应范围还可以被限制，以避免不必要的处理。

因此，一次成功回应能支持一个有时间、有对象的 MPLS 数据面观察。它不证明应用内容已经可用，不证明接收者仍在合同或角色名单中，不证明 SRv6 兄弟实现相同，也不证明换树期间从未产生重复，更不能证明控制器输入拥有合法来源。

严格描述边界，不是削弱 OAM。相反，边界清楚的证据才能与成员记录、配置版本和变更批准可靠连接。一个无对象、无时刻的绿灯反而难以复核。

受众凭证要从网络之外开始

第一组字段应记录服务身份、服务上下文、权威成员来源、来源版本、生效区间、批准者与排除项。第二组字段把稳定主体标识映射到叶或 Bud 地址，记录新增、移除、有效期和映射版本。地址不是稳定身份，不能单独承载受众资格。

第三组字段才进入 RFC 9960：<Root, Tree-ID>、候选路径的 <Protocol-Origin, Originator, Discriminator>、约束、优化目标和选择理由。第四组记录新旧 Instance-ID、确切叶/Bud 集合、控制器与配置世代、SID 分配证据及逐节点安装结果。

第五组保存观察：OAM 方法、使用 RFC 9961 时的 MPLS 限定、目标 PTI、预期响应范围、时间和逐叶结果。第六组保存过渡：激活顺序、共存时长、重复流量观察、回滚触发条件和旧 PTI 撤除证据。最后一组把所有仍存活的活动及备份实例与当前获准人口重新对账，并列明凭证到期时间和未证明事项。

哈希可以让成员、配置或测量被替换时留下痕迹，却不能证明上游制度真的有权，也不能保证传感器诚实。受众名单可能敏感；公开层可披露数量、时间、变更理由和例外，不必公开客户姓名或网络地址。

“多点受众凭证”是本文提出的本地运营记录，不是 RFC 9960 或 RFC 9961 定义的新协议对象，更不是 IETF 合规证书。

删除不是没有记录，而是一项必须完成的动作

系统通常很善于记录新增：申请、配置、安装、探测，每一步都有成功消息。删除却容易退化成“后来没看见”。对多点树来说，撤销一名受众需要同时触达活动实例、备份实例和曾部分安装的失败世代。

关闭凭证必须证明旧 PTI 不再接收根节点导入的流量，复制状态已经撤除，移除的叶也没有留在备用路径里。“不活动”和“已删除”是两个不同事实，不能混写。

RFC 9960 还说明，SID 冲突可能使复制段安装失败，控制器应限制重试并发出告警；域边界保护不当可能允许外部注入；错误拼接复制段可能形成环路，让流量形成风暴直到 TTL 或 Hop Limit 归零。叶节点回应成功，不会自动检验这些条件。它们需要各自的证据。

边界与来源

现有资料没有证明任何具名运营商已经部署相关 RFC，也没有证明真实发生了错误纳入、重复投递、攻击或性能收益。本文只把标准明示的结构与风险，同一项本地受众责任连接起来。运营者可以选择 MPLS、SRv6、静态树、其他 OAM，或根本不用 P2MP。

结论必须保持窄：Tree-ID 标识运输政策，Instance-ID 标识一次现实化，RFC 9961 的 ping 观察其中一个 MPLS 实例。谁应当接收，仍须由网络之外的权威作出决定，并与执行这项决定的树一起留下证据。