摘要

  • RFC 9862 用 PCEP Association 表示一条 SR Policy，用 LSP 表示其中每条候选路径。信令的基本单位是候选路径，但有些由它承载的选择会改变整个策略的行为。
  • INVALIDATION TLV 中的配置 D 标志写在候选路径上；只要任意候选路径启用它，整条 SR Policy 就具备 Drop-Upon-Invalid。真正触发丢弃，还要等到全部候选路径都无效。
  • 应为这种范围扩张建立整条策略级的丢弃凭据，把能力协商、完整成员集合、配置与运行标志、全体无效时点、承载丢弃的路径和实际报文结果连起来。这是 Daniel Kade 的编辑建议，不是 RFC 字段或 IETF 命令。

一条路径旁边亮起红灯，看上去只是一条路径的事情。它由一个 LSP 对象送来，挂在一个候选路径标识符下面，也完全可以作为这一行数据的一个布尔字段存进数据库。若只看编码位置，这种设计没有错；若由此推断影响范围，就错了。

RFC 9862 规定，Drop-Upon-Invalid 的配置通过候选路径上的 INVALIDATION TLV 传递，但它只在整条 SR Policy 上启用或关闭。任何一条候选路径的配置 D 为真，都意味着整个策略启用了这一特性。此时尚未发生丢弃。只有当该策略的所有候选路径都变成无效，策略才进入 drop state，从启用了该特性的路径中选出偏好值最高的一条作为承载者，并让本来会被这条策略吸引的流量继续抵达头端后被丢弃，而不是自然回退到其他 LSP 或 IGP 路径。

因此，这里至少有四个不同事实：某条路径携带配置；一个路径集合跨过“全部无效”的阈值；整条策略改变状态；报文在数据面被丢弃。把它们压成一个“D=true”，会得到格式整齐却无法追责的记录。

信令说的是一条路径，判定依赖的是一组路径

SR Policy 本来就不是单一路径。它可以包含一条或多条候选路径，并在有效路径中选择最合适的一条。RFC 9862 为 PCEP 增加 SR Policy Association，也就是 SRPA：Association 对应整条策略，其中的每个 LSP 对应一条候选路径。这一映射服从 PCEP 的既有语法，因为 PCEP 实际能够发送、更新和报告的单位是 LSP。

但这种合理的语法安排带来证据问题。与 SR Policy 有关的信息会在候选路径层面携带，即便某项信息只有放回完整集合中才有意义。SRPA 提供了联结键，却不会自动替运营者保存每个时点的完整成员快照。路径变化、会话重建、采样丢失或告警系统只截取最后一个对象，都可能让“集合”在事后消失。

这也是颜色、端点、发起者和判别值不应只被当作调试细节的原因。颜色与端点参与标识策略；发起者与判别值帮助标识候选路径。一条候选路径最多属于一个 SRPA，其标识在同一 PCEP 会话中保持稳定，同一策略里也不能出现重复标识。这些约束让关联成为可能，却不等于已经完成关联。

能力协商同样只回答一个窄问题。双方要在使用 SRPA 前声明相应能力；支持该能力的发送方为 SR Policy LSP 发报时必须带上关联信息。SRPOLICY-CAPABILITY TLV 还分别表明计算优先级、显式空标签、失效处理和无状态操作等能力。若没有完成相应协商却收到 SRPA，协议会报错并关闭会话。由此能证明双方是否共享这套词汇，不能证明当时有哪些路径有效，更不能证明后来有多少报文被丢弃。

两个 D 不是同一件事

INVALIDATION TLV 内有配置字段和运行字段，两者都使用 D。配置 D 表示这条候选路径启用了 Drop-Upon-Invalid；运行 D 表示这条 LSP 正因为该行为已经激活而实际处于丢弃状态。字母相同，不代表证据层级相同。

配置是意图：如果未来整条策略满足条件，应当怎样处理。运行标志是结果报告：条件跨过后，系统选择了什么状态。数据面是否真的持续吸引并丢弃报文、丢了多少、持续多久，还要看转发与计数证据。控制面上的一个位不能替数据面作证。

方向也不可省略。PCE 发给 PCC 时，配置字段在下达启用或禁用的要求；PCC 报给 PCE 时，消息既返回当前配置，也返回是否正在丢弃。如果日志只保留“最新 D 值”，却不保存发送者、接收者、方向、时间和会话，指令会被误读成确认，期望会被误读成观测结果。

正常失效时，一条无效 LSP 停止吸引流量，流量可转向别的 LSP 或 IGP。Drop-Upon-Invalid 故意改变这一结果：继续吸引，然后在头端丢弃。对于不能允许流量绕到非预期路径的业务，这可能是审慎的 fail-closed；对于过时或误配的策略，它也可能把一次可回退故障升级为主动中断。标准给出了可互操作的机制，却没有替每个运营者决定哪种风险更值得承担。

真正的触发器是最后一条有效路径失效

RFC 9256 把“全部候选路径都无效”定义为整条 SR Policy 无效。一条路径只能报告自己的状态，不能单独证明这个集合命题。第一条路径失效可能只削弱冗余；第二条失效可能改变当前最佳路径；最后一条有效路径失效，才让策略越过阈值。

越过阈值后，策略检查是否有任一候选路径启用了 Drop-Upon-Invalid。若有，就进入丢弃状态，并从这些启用路径中选择偏好值最高的一条。RFC 9862 还明确，只需向 PCE 报告一条带运行 D 的候选路径。这样的信令很节省，却不是完整因果史。

设想一条策略有三条候选路径。偏好最低的一条在很早以前被某位运营者设置了配置 D；另外两条没有。后来两条高偏好路径先后无效，此时仍有一条路径有效，策略不会丢弃。最后这条路径也失效时，那个很久以前留在低偏好成员上的标志使整条策略具备了丢弃条件。最终显示运行 D 的路径可以告诉我们“现在由谁承载丢弃”，却不能告诉我们“谁在何时授权了这个政策”“为什么它仍有效”以及“最后是哪一次失效让全体条件成立”。

还必须把两种容易混名的数值分开。候选路径 preference 用来挑选最佳路径，数字越大优先，缺省值是 100。RFC 9862 的 computation priority 用来安排拓扑变化后的重算次序，数字越小越先，在能力启用且 TLV 缺失时缺省为 128。两者方向相反，语义也不同。一个笼统的“priority”字段足以制造完全反向却看似合理的事故解释。

缺失值和本地覆盖都是真实决定

RFC 9862 里的缺失不总是空白。计算优先级 TLV 在相应能力成立时缺失，会落到 128。显式空标签策略缺失时，由本地配置决定；它只适用于 SR-MPLS，SRv6 必须忽略；不能识别的值也被忽略；运营者还可以用本地配置覆盖收到的行为。

这组规则揭示了运维数据库常见的错误：把 null 当作“没有政策”。实际上，缺失可能调用默认值，可能把权力交给本地配置，可能因为数据面类型而不适用，也可能被更高优先级的本地选择替代。四种状态不能共用一个空单元格。

审查丢弃事件时，应当查的是最终有效决定及其来源。D 是 PCE 下达的，还是本地保留的？它是否在建立关联后发生过变化？是否已经删除但采样尚未反映？当时使用哪个软件版本和哪次 PCEP 会话解释它？用于“全体无效”计算的成员集合，是否与运营团队以为存在的集合一致？

RFC 9862 要求实现让运营者看到 SRPA 中通告的策略与候选路径标识，并建议让运营者看到每个对等体的能力以及某个策略标识关联的 LSP。这是必要的可见性。要解释一次跨范围的状态迁移，还需要把这些画面按时间联在一起。

为范围扩张建立一张凭据

本文提出的策略级丢弃凭据先固定策略身份：颜色、端点、SRPA 标识，以及双方看到的 PCEP 会话与能力状态。然后冻结这次决策使用的完整候选路径集合，逐项记录发起者、判别值、偏好值、配置 D 和有效性。

接着记录迁移过程。每条路径何时由哪个观察源判定无效？最后一条有效路径在哪个时点跨过全体阈值？那一刻哪些候选路径带有配置 D？哪条最高偏好启用路径被选作丢弃承载者？运行 D 由谁向谁报告？意图、解释和报告之间是否不一致？

最后必须落到报文。流量是否继续被引入该策略？头端丢弃计数如何变化？首次与末次丢弃发生在何时？服务恢复是因为某条候选路径重新有效、配置被改变、成员集合变化，还是策略整体被撤销？配置的批准人、适用业务、例外理由、复核日期和回滚动作也应保留。

这并不要求把拓扑交给中央机构。SRPA 与 TLV 会暴露额外的策略信息，RFC 9862 因而沿用在同一管理权限下、经过认证与加密的 PCE/PCC 会话中使用 TLS 的建议。证据应留在必要范围内，受到访问控制，并以解释本地决定所需的最小信息为限。

这张凭据也不是新的协议扩展。它只是阻止管理系统把“某个位编码在哪里”错当成“权力在哪里发生”的编辑方法。

Sources