摘要

  • RFC 9753 通过 RELAX 协商，把原有 P、I 对象头标志带入有状态 PCEP；当未知对象的 P 位为零时，接收方可以忽略对象并继续处理消息。
  • 继续处理、I 位指示或成功的 PCRpt 都只是协议范围内的收据，不能证明约束语义被保留、实际路径等价、设备状态与控制器一致，或数据包走过安全路径。

最难审计的变更，往往没有报错。PCC 报告一条 LSP，消息里包含若干预期属性。其中一个对象承载新版本才理解的约束，而发送方策略已经把该对象的 P 位清零。接收方跳过对象、处理其余内容并维持会话。没有缺失强制对象，也没有格式错误；协议完全走在 RFC 9753 许可的分支上。

消失的不是消息，而是消息的一部分含义。

RFC 9753 于 2025 年 4 月作为 IETF 标准轨道文件发布，并更新 RFC 8231。RFC Editor 记录与 IETF Datatracker确认了文件身份和状态。它把“对象可选处理”扩展到 PCRpt、PCUpd 和 PCInitiate，使混合能力环境不必因每个未知非强制对象而放弃整次交换。

RELAX 协商的是语法，不是共同策略

基础 RFC 5440 将 P 定义为 Processing-Rule，将 I 定义为可选对象被忽略的指示。RFC 8231 原本要求有状态对象发送时把 P、I 置零，接收时忽略。RFC 9753 在 STATEFUL-PCE-CAPABILITY TLV 中加入 R，即 RELAX；当前 IANA PCEP 注册表把第 17 位分配给它。

PCE 与 PCC 必须同时设置 R，P/I 才在该有状态会话中生效。如果一方没有设置 R，却收到 P 或 I，它必须沿用旧规则忽略这些标志。因此，双向 R 只能证明双方愿意在这次会话中理解同一套对象处理语法。它没有列出双方共同认可的可放宽对象，也没有证明双方对时延、带宽、亲和性、保护或未来对象的风险判断一致。

RFC 9753 建议在双方都支持 R 时默认设置 P。只有本地配置或策略认定某项约束可以放宽，或者对象只携带可以安全忽略的信息时，才应清除 P。协议不会自动发现某个对象“没有影响”；这个判断由可追责的本地决策产生。

风险单位是整个对象

P 与 I 作用于完整 PCEP 对象，不能只针对对象内部某个可选 TLV。审计时应保存对象类、对象类型、消息类型、方向、SRP 或请求标识、LSP、策略版本和原始字节散列。否则，人们可能以为接收方仅丢掉了陌生装饰，实际上却把承载约束的整个对象排除在决策之外。

强制对象仍然强制。在 PCRpt 中，RFC 9753 点名 LSP 和表示预期路径的 ERO；在 PCUpd 与 RFC 8281 的 PCInitiate 中，则包括 SRP、LSP 与 ERO。若这类对象错误地清除了 P，接收方必须发送 Error-Type 10、Error-value 1 的 PCErr。

非强制对象的分支不同。P=1 时，如果接收方不认识对象，或虽认识却决定不处理，就必须拒绝整条有状态 PCEP 消息，并发送 Unknown Object 或 Not supported object 错误。P=0 时，接收方可以忽略对象并继续。于是，“没有错误”有两种合法解释：所有对象都被理解；或者未知对象被正确标成可选并被丢弃。只统计成功消息无法区分二者。

P 在三种消息与两种权力之间移动

在 PCRpt 中，P 告诉 PCE：某对象是否必须参与状态维护、路径计算或再优化。在 PCUpd 与 PCInitiate 中，P 告诉 PCC：该对象是否必须参与路径建立。同一位沿两个操作方向流动，一边是设备向控制器报告意图，另一边是控制器向设备提出处理要求。

RFC 8051给出有状态 PCE 的适用背景；RFC 8231 则保留 PCC 对 LSP 状态的所有权，并让 PCE 提供的属性受 PCC 本地策略约束。不过在委派期间，RFC 9753 允许 PCE 改变对象待遇：即使 PCC 原先设置了 P，PCE 也可把某对象标为忽略；即使 PCC 原先清除了 P，PCE 也可把它改为必须处理。PCC 必须在 PCRpt 中确认 PCE 的预期，否则进入不可接受更新流程。

最终的一个 P 位无法重建这段历史。可靠收据还要包含委派所有者、会话代次、请求或 SRP、对象身份、变更前后的 P 值、授权策略版本、有效期限和 PCC 回应。

I 证明“声称处理”，不证明“满足约束”

PCE 可以在 PCUpd 中附回被忽略的可选对象并设置 I；PCC 也可以在回应 PCUpd 或 PCInitiate 的 PCRpt 中这样做。I 清零表示对等体声称已处理对象。但 I 有严格上下文：没有用于关联回应的 SRP 时，PCRpt 里的 I 没有意义；PCInitiate 中的 I 必须为零并被忽略。

即使 I 合法，“已处理”也不等于“已满足”。解析器可以识别对象，策略模块可以读取它，但另一条约束可能赢得选择；路径计算可以考虑对象，却产生与预期属性不同的实际属性；PCC 可以报告控制平面状态，却没有独立读取转发硬件。

RFC 9753 自己的例子把差异说得很清楚。PCRpt 可以同时编码预期属性表和实际属性表。预期表中的 METRIC 对象，可以按 RFC 8233为 Path Delay Variation 设置上限。若没有路径满足上限，把对象标为可选可能是合理取舍。但随后交换成功，并不意味着原上限继续存在。证据应保存数值与单位、忽略决定、替代计算、实际路径，并用流量测量验证真实时延变化。

状态同步终止在转发证明之前

RFC 8231 把初始同步描述为 PCC LSP 状态在某一时点的副本。PCRpt 可以携带路径、带宽以及操作或管理状态。这些是有价值的控制器证据，却不是独立见证。在报告和数据包之间，还存在本地策略、信令、资源准入、RIB 或标签表选择、下一跳解析和硬件编程。

对 RSVP-TE LSP，可能要核对信令、预留与标签编程；其他路径建立类型需要不同的安装证据。RFC 9753 没有规定通用数据平面测试，本文也不把操作建议冒充新规范要求。要点只是：主张必须停在观察边界。对象处理报告不能认证它未测量的后续层。

这个边界也使本篇与已相邻的 RFC 9757 分开：后者处理 Native IP 的 BPI、EPR、PPA 中央指令，本篇处理有状态对象在更早阶段的语义分岔。RFC 9826可把 PCEP 状态投影到 YANG 管理模型，但完整的数据树仍是投影，不是独立转发证据。

RFC 9753 建议仅在同一管理权威之下、经过认证与加密的 PCE/PCC 会话上启用扩展，采用 RFC 8253 的 PCEPS，并遵循 RFC 9325 的 TLS 当前实践。它能保护通道身份与机密性，却不能证明清除 P 的策略正确、及时或双方同义。

文档还建议实现允许配置 RELAX 与相关可选约束，并让操作者查看能力；它没有新增活性或正确操作验证要求。“没有新增”界定的是规范范围，不等于外部验证不再需要。

Heng Lu 的《现实层级》在这里作为公开说明的编辑视角：协商符号、接受操作、控制器状态、设备实现和观测结果是不同事实。套用到 RFC 9753，可靠台账要连接十一张收据：对等身份与会话、双向 R、消息与对象、发送策略、解析结果、忽略或报错决定、丢失或保留的约束、重新计算、PCE/PCC 对账、设备转发状态、流量与回滚。

来源登记

技术材料包括 RFC 9753 正文、RFC Editor 元数据、Datatracker 记录、IANA PCEP 注册表、RFC 5440、RFC 8231、RFC 8281、RFC 8051、RFC 8233、RFC 8253、RFC 9325，以及用于划清边界的 RFC 9757 与 RFC 9826。本文不主张任何厂商实现、运营部署、互操作测试、事故或采用率。