摘要

  • RFC 9756 为 PCEP 留出实验错误类型；参与者自行协调的编号组合，不会因为试验成功就自动成为正式分配。
  • 真正难退出的往往是编号周围的依赖：旧日志的解释方式、尚未升级的对端、值班手册，以及应急回滚包。
  • 管理者应把“停止携带哪些临时依赖”列为试验验收内容，而不是只验收新版本能否运行。

应急回滚通常有一个很有说服力的画面：旧版本恢复了，连接重新建立，告警数量下降。可是在一个使用实验错误码的网络试验里，这幅画面还少了一项检查——旧版本发出的错误，值班系统是否仍按旧版本的意思理解？

设想这样一个场景。试验双方原先约定了一组临时编号，后来新版本改用正式分配的编号。设备升级之外，监控规则也更新了。一次故障迫使其中一端恢复旧软件，但监控字典没有一同恢复。连接存在，字段格式正确，屏幕上甚至出现了熟悉的中文解释；真正不确定的是，这句解释是否属于当前报文。这个场景是用于验收设计的假设，不是本文发现的生产事故。

它揭示了一种容易被低估的迁移成本：软件可以恢复，解释软件行为的环境却未必随之恢复。把“能退回旧程序”写成回滚承诺，比证明整个运行环境仍理解旧程序容易得多。

先看这个编号到底表示什么

PCEP 的基础规范 RFC 5440规定，错误对象中既有 Error-Type，也有 Error-value。前者表示错误类别，后者给出进一步说明。运行人员需要理解的是二者的组合，而不是孤立地检索一个数字。PCEP 本身用于路径计算客户端和路径计算元素之间的信息交换，这套错误词汇是双方协作的一部分。

2025 年 3 月发布的 RFC 9756把 Error-Type 的 252—255 留给实验使用，其下 0—255 的 Error-value 同样属于实验范围。IANA 当前的 PCEP 注册表已经体现这一安排；其余 0—251 类型及其取值适用 IETF Review。

这里分开的不是“有用”与“没用”，而是两种不同的协调范围。正式注册表提供共同编号；实验参与者则在一个受控环境里约定编号及含义。后者能支持有效试验，却不能保证另一个团队没有给相同组合赋予另一种解释。

所以 RFC 9756 要求参与者协调错误类型、错误值及其意义，提醒共享实现的并行实验保持组合不冲突。它还明确排除了一个貌似省事的办法：不能在普通、非实验错误类型下面，自行塞入所谓实验错误值。未分配不等于可以把它当作私有扩展槽位。

临时约定为何容易留下来

RFC 3692早已讨论过临时编号难以收回的问题。联系人会失效，试验是否结束不容易确认，而一旦产品带着临时编号进入使用环境，就很难判断重新使用该编号会不会影响既有设备。

预留实验范围，正是为了让测试无需先占据一个普通分配。但这种便利有边界：它不面向一般性部署，产品不应默认启用实验编号识别；用户需要明确启用并配置实验功能，适当情况下通过显式重新编程完成配置。即使多家厂商共同认可一个实验值，也不会因此获得全球唯一的命名空间。

对运营组织而言，这意味着试验的“参加者名单”并非项目附件。谁加入了环境，谁升级了实现，谁引入了第二个试验，都可能改变原来的不冲突假设。最初两个团队之间的口头默契，不能自动覆盖后来接手的供应商和夜班人员。

依赖还会从设备向外扩散。一个临时错误值可能进入测试断言、客服检索、监控面板和历史工单。只修改发报文的代码，能够改变后续字节，却不能保证所有读这些字节的人和系统同步更换理解方式。本文没有发现某个厂商存在这些缺陷；这些是根据机制推导出的检查对象。

标准减少了绕路，却没有替组织完成迁移

PCEP 并非到 RFC 9756 才允许实验。RFC 8356已为报文、对象和 TLV 划出实验范围。当时的思路是，其他子注册表里需要新功能时，可以通过实验对象或 TLV 承载。

RFC 9756 对错误处理重新作了取舍。另造一个实验对象来装实验错误，会造成不必要的实现分岔；直接使用既有错误机制，更有利于成功试验向标准轨道迁移。这个改进有实际价值：实验不必为了报告失败，先建立一套日后还要拆掉的特别封装。

然而，复用错误机制不代表保留原来的实验编号。试验如果进入以标准轨道发布为目标的 IETF 工作，每一组错误类型和值都需要取得 IANA 分配。可以新分配错误类型及其下的取值，也可以在既有类型下分配新值。具体走哪条路，不应在试验阶段凭习惯预设。

规范把程序里的调整描述为数值替换。对于该处实现，这可能确实简单；对于整个运行环境，这句话不能被延伸成“无需额外迁移”。RFC 没有替某家运营商规定设备升级顺序，没有定义通用的双字典协商，也没有承诺新旧版本自然互通。若产品不具备受控共存能力，就应隔离试验或安排明确切换，而不是让接收端猜测一个值来自哪个时代。

同一份记录，不能被新字典悄悄改写

RFC 9756 有一条很值得技术管理者注意的建议：不要在公开文档中记录实验所选的具体数字组合，可以使用文字或符号名称说明错误。稳定的名字有助于解释功能；具体临时数字则不该被公开文档固化成长期承诺。

这不等于不留诊断证据。公开说明和受控运行记录承担不同任务。前者解释一种失败意味着什么；后者需要保存当时收到的原始组合，以及足以辨别其语境的信息。观察时间、对端、实验版本和解码规则版本，都是值得评估的记录维度，不是 RFC 强制规定的一套日志格式。

尤其要防止历史被“统一显示”覆盖。假设面板升级后，用当前字典重新渲染所有旧事件，文字可能更整齐，却把过去的意义换成了现在的意义。以后复盘的人无法知道，是设备真的报告过另一类问题，还是展示层后来换了词典。

因此，迁移验收应包含一次旧记录重读：新版本上线后，团队能否正确解释保留的实验故障样本？一端回滚后，新的观察工具能否辨别它所使用的旧约定？这两项建议不要求永久启用旧协议，只要求不要把历史可解释性与在线兼容功能混为一谈。

评审通道放宽，不等于试验私有化

RFC 9756 还把列明的若干 PCEP 注册表从 Standards Action 改为 IETF Review。RFC 8126给出了区别：后者允许不同类型的 IETF 流 RFC 提出分配，而不仅限于标准轨道或最佳当前实践文件；IETF 共识评审仍然存在。

这不是先到先得，也不是任何流的 RFC 都可以直接取得编号。工作组考虑过为位数紧张的标志字段保留更窄的政策，最终判断 Last Call 等评审足以处理轻率占用。应把它如实理解为制度设计判断，而不是已经发生编号滥用的证据。

同样，接收一个未知实验错误也不能直接证明编号冲突。RFC 9756 列举了实现错误、双方取值不同步和并行实验等可能原因，并讨论记录错误及可能关闭会话。它没有规定所有 PCEP 错误一律强制断开。基础规范对不同错误分别规定了请求取消、会话建立处理等行为，有的情形还要求保留既有会话。只看断连计数，不能替代对实际对端行为的核查。

Lu Heng 在关于 BTW 为何以现实而非倡议为产品的文章中强调，要描述承受压力时的结构，而不是虚构善恶角色。用于本题，就是把标准已经解决的事和组织仍要承担的事分开。现有材料支持编号规则和评审机制，不支持厂商采用率、真实事故或迁移费用估算。管理上的问题却已足够明确：一个临时约定正在变成长期依赖时，谁有预算和权力让它结束？