摘要

  • 10 月 28 日的一份 IETF 个人草案，为 PCEP 增加两种 SRv6 FlowSpec 匹配：一种读取普通 SID 的 locator、function、argument，另一种读取压缩 SID 容器的内部字段；双方须先宣布 S 能力位。
  • PCC 收到未协商或格式错误的规则时必须发送 Type 30 错误。草案把错误值写成 TBD_EV，IANA 章节却没有申请这个值；现行登记表已有分别表示“不支持”和“格式错误”的编号。

控制器能数清地址，数不清拒绝

PCEP 原本就能让路径计算单元 PCE 向路由器上的 PCC 传递 FlowSpec 规则。新草案往前推了一步：控制器不只看完整的 IPv6 目的地址，还要按 SRv6 SID 的结构挑选字段。普通 SID 的定位符、功能和参数可被单独或组合匹配；压缩 SID 容器则有定位符块、节点和功能字段。PCE 写规则，PCC 在数据面执行。这等于把“哪些比特有意义”的判断搬进了控制协议。

草案也给路由器留了两道门。会话建立时，PCE 和 PCC 都须通告新的 S 能力位，双方同意后才可传送这些 TLV。收到规则后，PCC 要检查字段长度之和是否超过 128 位。超过就算格式错误。控制器再强，也不能把一份装不进地址的结构图硬塞给路由器。

麻烦发生在拒绝时。第 5.2 节要求 PCC 对未协商或畸形规则发送 PCErr，Error-Type 30，Error-Value TBD_EV，并给这个未定值取名“Unsupported or Malformed SRv6 FlowSpec Component”。第 7 节向 IANA 申请了 S 位和两种 TLV 类型，却没有申请错误值。IANA 现行 PCEP 登记表在 Type 30 下列出 1 至 5，6 至 255 尚未分配。路由器必须发的那个数，草案尚未交代。

更有趣的是，底座已经有两个可用的答案。RFC 9168把 Type 30 的值 1 给了“不支持 FlowSpec”，值 2 给了“FlowSpec 格式错误”。新草案却把两种情形合写在一个 TBD_EV 下。作者可以沿用 1 和 2，让控制器看出问题发生在哪一关；也可以为 SRv6 申请一个新值。两条路都通，现稿哪条都没选。

这不是排版上的小洞。两个厂商可以对合法规则达成一致，却在一台路由器拒绝规则时给出不同的错误字节。操作员看到的便是失败，听到的却是方言。命令描述得越精细，拒绝理由越不能靠厂商猜测。

Datatracker 记录把这份 00 版列为个人 Internet-Draft。下一版只需在既有编号与新编号之间作出明确选择，并把选择写进协议和 IANA 申请。到那时，控制器的命令和路由器的“不”才会使用同一套语法。

来源