摘要

  • draft-ietf-idr-fsv2-ip-basic-08 为规则加入用户顺序、必选与可选组件以及依赖过滤链，但这些机制在每台设备本地判断，并不构成全网安装确认。
  • 运营方必须为每个目标节点保存独立回执：收到什么、理解什么、验证什么、排序如何、安装什么、省略什么、何时撤销，以及报文最终经历了什么；路由传播本身无法补齐这条链。

控制面全绿，数据面却有三个答案

紧急过滤规则离开控制器，经由路由反射器到达所有预期邻居。会话稳定，UPDATE 已接收，监控面板于是把任务标成完成。

第一台边缘设备支持完整匹配条件和动作，把规则写入转发表。第二台不支持其中一个必选组件，因此把该规则和同一依赖链的规则全部判为本地无效。第三台不支持一个可选组件，于是删掉它，再把剩余规则作为有效规则安装。还有一台旧设备不认识新动作，却能按扩展社区的传递属性继续传播它。

控制对象相同，有效报文政策却不同。这正是 2026 年 9 月 28 日发布的第 08 版草案所暴露的运营边界，而不是对标准的外部猜测。

草案后段有一句决定性的话：BGP 仍然没有 action-reply 功能。它擅长快速、规模化地分发，却不会等待每台设备完成解析、能力判断、策略排序和硬件编程后再向源头回复。

所以，“邻居已经收到”只能证明传递，不能证明执行。

这是正在工作的草案，不是部署事实

Datatracker 把第 08 版列为 IDR 工作组的活跃 Internet-Draft，状态仍是 I-D Exists。正文写着 Standards Track，元数据里的目标 RFC 状态却未填写；AFI、SAFI 和部分类型值仍是 TBD，文本也保留编辑注记，并把完整的多动作方案留给后续文件。

这些并非形式上的免责声明。它们规定了本文可以说到哪里：草案证明工作组正在解决 FSv1 暴露出的顺序、依赖与增量部署问题，却不能证明任何具名运营商已经部署第 08 版，也不能证明某台设备符合尚未完成的设计。

RFC 8955、RFC 8956 与 RFC 9117 构成 FSv1 的基本分发和验证脉络。FSv2 使用不同的地址族与后续地址族，使两个版本能够“各自航行”。迁移网络里可能同时存在只支持 FSv1、只支持 FSv2、两者都支持或两者都不支持的节点。

协议对象可以分开航行，报文却只能穿过设备上的一套实际过滤顺序。

User Order 是指令，不是落地证明

每条 FSv2 NLRI 都携带 32 位 User Order，数值越小，优先级越高。默认的组件排序不能表达意图时，运营者可用它指定规则的相对位置。

这一能力很重要。一个窄范围的放行动作若排在广范围丢弃之后，最终结果会完全不同。草案建议在共同数据库里把 FSv2 放在 FSv1 之前，并给 FSv1 分配更大的用户顺序。

但携带顺序只是表达意图。接收设备仍须把它与本地所有 FSv1、FSv2 规则合并，解决相同顺序，验证匹配与动作，再翻译成软件分类器或硬件表项。BGP UPDATE 不会把最终有效顺序返回给源头。

因此审计记录必须同时保存广告顺序与安装顺序。两者不同时，差异本身就是事件。

DFC 只在本地共同失败

Dependent Filters Chain 解决的是部分安装带来的危险。草案举例：一条更具体的规则允许 SMTP 并设置 DSCP，另一条更宽的规则执行丢弃。若设备因不支持 DSCP 而没有安装第一条，却安装了第二条，本应放行的通信就会被丢弃。

非零 DFC 把应当共同成败的规则联系起来。一条规则被本地判为无效时，同一 DFC 的规则也在该设备上失效并停止安装。这是一种有价值的本地 fail-closed 行为。

它不是分布式事务。一台设备可以接受整组规则，另一台可以拒绝；路由反射器可以只检查语法并继续传播；升级中的旧节点可能根本不知道新的组件语义。DFC 不向源头发送成功回执，也不比较各节点结果，更不会回滚其他节点上已安装的规则。

把 DFC 称为“全网原子提交”会夸大规范。它协调本地资格，全网一致性仍需逐节点证明。

可选组件意味着安装后的规则可能不同

匹配组件带有 Optional 标志。不支持的必选组件会使规则本地无效；不支持的可选组件则可以被省略，剩余部分仍以有效规则安装。

这有利于渐进部署，却可能改变匹配集合。假设一个目标前缀再加一个新限定条件，用来缩小被过滤的报文。在新设备上，两者共同生效；在旧设备上，限定条件被省略，前缀和动作仍保留，过滤范围便扩大了。

可选不是错误，未被观测的省略才是风险。运营者需要知道哪一项被删掉、剩余规则会命中什么、动作是否仍适当，以及这种差异是否得到授权。

动作也有同样问题。草案允许实现根据本地默认值或配置判断无法安装的动作是否使整条规则失效，并承认有序动作和有效性机制还可能在未来完善。混合设备群不能据此推定一致执行。

字节可以继续传播，含义却停在旧设备上

FSv2 使用扩展社区把动作与过滤器关联。RFC 4360 规定通用的携带和传递机制。一台不认识新动作的设备仍可能忠实地继续传播相关字节。

第 08 版明确指出，旧实现甚至可能不知道有人请求了某项动作，只能对自己认识的动作做 best effort。于是，控制面能够完整保存对象，设备本地却没有相同含义。

对于缓解任务，这一点尤为危险。意图可能是采样、标记并重定向，某台设备却只执行其中一部分。草案讨论多动作交互，但把完整解决方案留给后续 Action Community Container 工作。UPDATE 成功绝不是有序动作集进入数据面的证书。

验证通过仍不是执行完成

草案把验证分成 NLRI 语法语义、路由属性和动作。默认可行性与目标前缀及相关单播路由证据有关，部分规则可以由显式配置放宽。

这些检查减少危险分发，却没有把验证变成安装。

当边界无法恢复时，畸形 NLRI 可能要求重置 BGP 会话；其他可定位错误按照 RFC 7606 执行 treat-as-withdraw。草案还警告：已经有效的 NLRI 若以畸形的隐式或显式撤销退出，网络中可能留下 stuck route，并要求通知运营者。

撤销因此也需要证据链。源头发出撤销、邻居解析、RIB 删除，都不证明下游策略库、软件分类器或硬件表项已经清除。“不再广告”与“不再影响报文”不是同一句话。

快速分发与慢速证明应当并存

FSv2 沿用 BGP 的强项。RFC 4760 提供多协议携带，路由反射器扩展分发，扩展社区附带动作。发送方无需等待所有设备写完硬件表项，分发因此很快。

草案也承认，过滤器分发的运营验证历来发生在 BGP 之外。NETCONF 和 RESTCONF 具有请求/响应模式，文档建议以 BGP 快速分发，再以管理协议长期查询安装情况。

这只是架构建议。RFC 6241 与 RFC 8040 能提供结构化交互，却不会自动产生跨厂商一致的 FSv2 安装回执。管理响应可能只代表请求被接受、目标配置被修改、operational datastore 更新、软件表写入或硬件提交。报文是否命中仍需另行观测。

合理做法是两速控制：BGP 快速开启干预，较慢的证据环逐节点确认规则、动作、计数器与报文结果，并决定规则是否可以继续存在。

一次 FSv2 操作应携带的回执

至少保存以下记录：规范版本和 AFI/SAFI；发起权限与目标节点清单；完整 NLRI、User Order、DFC 和组件标志；所有动作社区及其传递性；验证输入和显式放宽；逐邻居收发时间；节点能力版本；未知、缺失与省略项；每个 DFC 的本地结论；合并后的 FSv1/FSv2 顺序；软件与硬件安装身份；匹配计数或报文样本；到期、撤销和实际清除；继续、缩小、回滚或关闭的决定。

路由到达证明控制对象抵达。验证通过证明它符合一套规则。硬件表项证明某个对象被编程。报文计数证明流量遇到分类器。恢复还需要新的运行态证据。

若只能取得其中一部分，就应明确写出证据断点、适用节点与有效时段，而不是把缺失状态补成“全网完成”。

这正是“运行代码优先”的操作含义：规范描述符合要求的实现应做什么，责任判断则必须依赖某台设备在某个时间对某条规则实际做了什么。

来源