摘要

  • 10 月 2 日的 draft-ietf-grow-routing-ops-sec-inform-03 新增“配置范式的影响”一节，对比先暂存再原子提交的事务式接口与逐条立即执行命令的接口。它仍是 GROW 工作组的互联网草案，Datatracker 状态为 I-D Exists，并非已批准的 RFC。
  • 草案举例：先输入 action permit，再输入 set large-community add 65536:0:0。如果新允许规则排在拒绝上游学得路由的规则之前，中间状态可能把上游路由发给对等方。这是推演的故障路径，不是已核实的真实泄漏事件。

一份变更单可以准确写出最后的 BGP 出口策略，却不一定准确描述设备到达那个结果的过程。事务式配置把一组修改暂存，在提交点整体生效；另一类接口在每条命令敲下之后就改变运行行为。GROW 新修订讨论的正是这两类执行语义。它的标题是《Current Options for Securing Global Routing》，定位为非穷尽的安全选项梳理，既不逐项裁定有效性，也不规定某种统一实现。

新加的第三节给出一个可以检验的顺序问题。操作者建立 route-map，先写 action permit，随后才写添加 Large Community 65536:0:0 的语句。如果该规则位于拒绝上游来源路由的规则之前，允许动作在即时执行平台上可能率先开放出口。等到最终配置被审阅时，后续语句或许已经齐备，但短暂被宣告的路由不会因此从对等方的历史里消失。示例中的社区数值不是身份凭据，也不能单独证明出口被约束。

“新”需要说清。上一版 -02 在前缀过滤器一致性的章节，已经指出非原子修改可能暂时放过不该放过的前缀，或在变更中断后留下不一致策略。-03 并非首次发现非原子更新风险，而是把问题提升为配置范式的独立章节，并补上 route-map 中先允许、后补条件的图景。草案要求操作者理解这些方式的差异；它没有为所有厂家规定同一套发布命令。

RFC 8212 的默认拒绝要求也不能被误读为过渡期保险。该 RFC 要求 EBGP 导入、导出有明确策略，缺失策略时拒绝路由，同时明确说错误的显式配置仍可能发生。一个过早启用的 permit 恰恰是显式配置。最终文件里有 reject，不等于变更每一步都执行了 reject；会话保持 Established，也不等于邻居没有收到错误公告。

因此验收应区分三个收据：命令已被设备接受、完整目标策略已附着到正确会话、邻居只收到获准路由。最终 diff 通常只能较好说明第二件事。若平台支持，先构建完整替换策略再切换引用，是值得评估的办法；但引用切换本身是否原子、是否作用于预期地址族，仍要按具体实现验证。“只有一条切换命令”不等于“过程只有一个可见状态”。这些检查是从草案故障模型得出的操作建议，不是草案新增的强制遥测规范。

没有一手资料证明某运营商因此发生泄漏，或者哪款产品存在缺陷；草案也没有给出部署暴露率。它真正提供的是更准确的治理对象：审批不能只盖在正确的终态上，还应覆盖每一个可能发出路由的中间态。

来源