摘要

  • draft-ietf-pce-flexible-grid-17 于 2026 年 9 月 13 日发布；当时文件仍处于 IESG Evaluation，拟作为 Proposed Standard，并列入 9 月 17 日电话会议议程。
  • 第 16 版把两个新错误放在 PCEP Error-Type 24 下，并称之为 Routing Problem；IANA 的现行 PCEP 登记表却早已把 24 定义为 LSP instantiation error。
  • 路由领域主管在 DISCUSS 中指出 PathErr、Error Code 和这套命名属于 RSVP-TE。第 17 版随后删除两条响应规则及相应登记申请，同时保留一个独立的新错误类型，用来表示无法执行 RSA 计算。
  • 删除避免了编号冲突，也改变了实现可见的诊断表面。跨版本运行时，不能只记录数字，还要保留协议、消息、草案版本和触发条件。

目录号相同，书却不是同一本

设想两座图书馆都用“24”标书架。一座把它解释为“路径实例化错误”，另一份新目录却让它存放“路由问题”。书架没有变，读者却会因为手里的目录不同而取到不同含义。协议编号的风险正是如此：机器不会从上下文猜作者原意，它按照登记和实现执行。

第 16 版草案要扩展 PCEP，让路径计算客户端（PCC）在柔性光栅网络中向路径计算单元（PCE）同时请求路由和频谱分配。请求可以指定双向路径是否使用同一频率槽，也可以选择 First-Fit、Random 等分配方法。

若 PCE 不支持所请求的对称性或方法，第 16 版要求生成 PathErr，使用 Error Code 24、名称 Routing Problem，再附上两个新子码之一。第 9.9 节进一步请求 IANA 在 PCEP 的既有 Error-Type 24 下登记这两项值。

但 IANA PCEP 登记表已经依据 RFC 8281 把 Error-Type 24 分配给 LSP instantiation error。RFC 5440规定的 PCEP 错误消息叫 PCErr，字段是 Error-Type 与 Error-value。PathErr、Error Code 以及 Routing Problem 属于 RSVP-TE 的术语体系。问题不只是名词写错，而是一个协议的故障语义试图占用另一个登记命名空间中的既有号码。

9 月 9 日，路由领域主管 Gunter Van de Velde 把这一点列为正式 DISCUSS。Datatracker 历史记录还显示，他同时质疑 Spectrum Allocation TLV 的格式、容器和放置规则，以及新错误类型是否保留 0 值、以后怎样分配。Mohamed Boucadair 的另一项 DISCUSS 涉及策略例外、固定长度、链路标识解析、能力发现和 IANA 分配政策。DISCUSS 要求问题得到处理，但它不是对文件最终命运的预判。

修复动作是“删”，不是“换号”

第 17 版直接删除了“不支持对称性”和“不支持分配方法”时发送两种 PathErr 的段落，也删除第 9.9 节及其中两项 Error-Type 24 登记请求。官方版本差异没有显示它们被搬到其他编号。就当前文本而言，这两条专用诊断不再是规范定义的输出。

其他失败信号仍在。草案继续申请一个尚未编号的 Flexi-Grid RSA Error 新类型，其中 Error-value 1 表示 RSA computation not supported；第 17 版补上了 Error-value 0 为 Unassigned。NO-PATH-VECTOR 里另有一个比特，表示没有路径满足全部光谱约束。三种事实必须分开：PCE 根本不会做 RSA、PCE 会计算却找不到可行路径，以及 PCE 不支持请求中的某个具体属性。

新版还采纳了多项可核验修改。Frequency Slot Selection TLV 的长度明确为 4；频率索引 n 可以为正、负或零；只有在不存在策略或验证错误时才必须返回 Label Set；Inclusive Range 明确包含两个链路标识记录；容器名称改用 RFC 7570 的 ERO Hop Attributes subobject；安全章节加入 PCEP TLS 更新 RFC 9916。

不过，新版本并不自动证明所有 DISCUSS 已解决。例如，评审还要求说明 TLV 在 ERO 中的有效位置、次序、关联、修改规则和尺寸限制。改正容器名称只回答其中一部分。到研究截止时，可以确认的是 24 号冲突已从文本中撤回，IANA 审查状态由 IANA OK - Actions Needed 变为 Version Changed - Review Needed。

9 月 17 日尚未发生

Datatracker 文件页显示，这仍是 PCE 工作组提交给 IESG、目标为 Proposed Standard 的文件。文件 API把第 17 版时间精确记录为 9 月 13 日 09:57:08 UTC。文件仍处于 IESG Evaluation，电话会议安排在 9 月 17 日。一次上传不会自动清除 DISCUSS，也不等于 IESG 批准、IANA 完成复核或正式分配号码。

IANA 状态回退同样不等于否决。它意味着待执行的登记申请已经变化，需要重新对照。RFC 8126定义了 IETF Review、First Come First Served 等分配政策术语，但新空间采用哪一种，仍要由标准过程确定。

能力发现问题也留下了一条清楚的修订轨迹。第 16 版一方面说不新增 PCEP OPEN 能力通告、改用错误响应，另一方面又援引 RFC 5088 和 RFC 5089 的 OSPF/IS-IS 发现机制。第 17 版删掉“错误式设计”的解释，但保留发现机制可通告 Flexi-Grid RSA 能力的说法。这是文本边界的调整，不是某张运营网已经采用的证据。

IETF Last Call 还链接了 IPR 3053 披露。它是一份程序记录，不构成本文对专利有效性、必要性、侵权、许可需求、价格或实施自由的判断。

给编号与线上行为做同一张回执

每当诊断被新增、移动或删除，最低限度的变更回执应保存旧五元组：协议、消息、Error-Type、Error-value、触发条件；再附上当时的 IANA 登记行、评审意见、新五元组或明确删除状态。实现版本、草案哈希、报文级负向测试、IANA 审查状态、ballot 状态和运营启用时间也应同时记录。

这是我的编辑建议，不是 IETF 或 IANA 的要求。Heng Lu 的 Policy Mirror提醒我们，实际控制面由当前规则、部署副本和执行路径共同组成；脱离版本的标签不是权威。最小初始规范可以只统一这张回执，而不强迫所有运营者采用同一策略。BTW Media 的证据原则则要求把文本修订与部署事故严格分开。

目前没有公开互操作故障、报文抓取或部署统计证明任何实现发出过被删除的两项错误。新闻事实更窄：标准审查在批准前发现了命名空间碰撞，拟议的线上契约因此改变。

来源