摘要

  • IDR 工作组 9 月 28 日的第 08 版仍是有效 Internet-Draft，不是 RFC，也不意味着新编号已获正式分配。
  • 第 07 版把基本 IP 过滤规则放在拟议家族 256，并以组件 60 表示 IP 目的前缀。第 08 版改列 IPv4 Basic 家族 1000、IPv6 Basic 家族 1100；IPv4 目的前缀则是 IPv4 家族内的组件 1000。
  • 判断规则含义必须同时看家族、组件和草案版本。只看一个数字，或只看路由是否到达，都不足以证明过滤行为。

数字背后还有一层命名空间

RFC 8955规范的是第一版 IPv4 FlowSpec；这份 v2 文本仍在工作组修改中。七月版本采用一张基本 IP 组件表，九月版本把 IPv4、IPv6 分开，并为 Queue Pair、CAT 和 Routing Augment 分列组件。组件编号是在其家族内部解释的，不是一张可以脱离上下文通用的标签。即使“目的前缀”这个人类可读名称没变，旧版测试样本的家族 256／组件 60，也不能在新版直接当作家族 1000／组件 1000 的测试结论。

草案还要求 NLRI 内相关 TLV 严格递增排列，不能重复。接收者先要识别完整编码，随后才谈得上把匹配条件与动作交给设备处理。第 08 版第九节请求 IANA 分配一个 AFI、两个 SAFI 并创建新注册表；AFI／SAFI 值在文中仍写作 TBD。因此报道应把表中的家族值称为草案拟议值，而不是已经登记、可以长期依赖的协议常数。

能转发，不等于能执行

第 08 版专门讨论部分部署：有的节点检查语法，却不理解新过滤器家族；升级过程中也可能只有部分节点识别新组件。验证章节允许对形式正确、但本机不认识其编码的 NLRI 作受配置约束的继续传播，并指出语义错误可能直到理解该编码的节点才被发现。这是草案描述的协议边界，不是已发生故障的证据。

同一条策略至少留下几种不同痕迹：收到 BGP 路由、把路由传给下一跳、理解匹配条件、在本地安装过滤规则，以及数据包确实受到预期处理。草案另行讨论规则依赖链、必需／可选组件和本地无效规则，恰好说明这些痕迹不能合并成一个“成功”。变化中的家族表，使每次验收都更需要带上确切版本。

来源