IETF 批准动态泛洪实验，但“可接受”仍需量化

摘要

• 2026 年 8 月 31 日，IESG 批准 Dynamic Flooding on Dense Graphs 第 05 版按实验性 RFC 发布。核查时，最终 RFC 编号尚未确定。
• 方案由 Area Leader 为链路状态更新计算一张稀疏泛洪拓扑；承载数据转发的基础拓扑并未被替换。
• 草案列出未来推进前必须满足的七项标准，其中包括至少三个能够互操作的独立实现和有文档的运营经验。审批材料目前只确认了一个 IS-IS 实现。
• “可接受”的收敛、“可接受”的泛洪削减以及对拓扑变化的“稳健”没有统一数值。保留这种本地判断空间是合理的，但阈值必须在实验结果出现前固定。
• 运营者应建立版本化实验台账，记录所测版本、实现、两张拓扑图、算法选项、统计口径、故障注入、临时泛洪、回退以及最终决策人。

这是一张实验许可，不是生产通行证

IESG 的选择相当克制。Link State Routing 工作组对开展这项实验形成了强共识，但文档仍被放在 Experimental 轨道。原因不难理解：密集图能为业务转发提供丰富路径，却也会让传统链路状态泛洪产生大量重复报文。动态泛洪希望把“业务可以走哪里”和“状态更新需要走哪里”分开。

Area Leader 根据完整基础图计算稀疏子图，再通过 RFC 9667 定义的机制通告给参与节点。子图必须覆盖所有可达节点，在可能时保持双连通，避免直径过大，也要防止度数过度集中到少数路由器。基础图依旧存在，数据包仍可使用其中的链路；被缩减的是控制信息传播边。

草案用一个十节点完全图说明直觉：基础图有 45 条边，示例子图只保留 12 条，直径则从一增至四。这个数字只是结构示意。它没有测量某个运营网络，也不能证明另一种图同样减少报文或保持相同收敛速度。

实验性地位还反映了实现基础。文档 shepherd 只记录到一个 IS-IS 实现，而这种机制会明显改变控制面的运行方式，并依赖本身仍为实验性的 RFC 9667 框架。作者没有声称算法最优，也没有把它直接提议为唯一标准算法。批准的含义是让不同实现有共同的实验对象，而不是让某一个实现继承 IETF 的权威。

七项条件里有四个判断词

第 05 版明确写出推进工作的七项条件：至少三个独立实现互操作；形成有记录的部署和运营经验；不存在根本性反对意见；安全考虑经过验证或更新；运营质量可接受；收敛与泛洪削减可接受；拓扑变化下表现稳健。

这份清单很重要，因为它阻止一次演示代替完整验证。三个采用同一代码库的产品不当然构成三个独立实现。实验室仿真也不会因为规模很大就自动成为运营经验。互操作不仅是设备能解析报文，还包括领导节点按 RFC 9667 正确编码图、参与节点对自身泛洪角色作出一致解释。

问题集中在“可接受”和“稳健”。骨干网、数据中心网络和教学试验床不必共享同一收敛预算；统一规定一个百分比，可能只是伪精确。因此，把最终阈值留给部署方并非规范漏洞。

真正的漏洞出现在先看结果、再决定什么算成功。试验方可以更换时间窗口、排除最差尾部、只统计升级节点，或者把原本不够的下降幅度重新描述为“有意义”。本地决定只有在规则、口径和责任人预先公开时才具有可信度。

同名算法可能算出不同的图

中央计算过程保留了不少实现选择：深度优先搜索如何推进，邻居按什么顺序处理，平局如何打破，额外端点如何选择。它们会改变最终子图。因此，台账不能只写“启用动态泛洪”，还要写出足以重现图的参数和实现版本。

Area Leader 也不是抽象角色。只有它运行算法并通告拓扑。运营者需要知道当时哪台路由器担任领导者、选举处于什么状态、计算使用哪一版链路状态数据库、图何时生效、领导者变化时又发生了什么。草案认为管理面应当展示领导者和当前泛洪邻接，但具体接口由实现决定。

局部部署会改变分母。旧节点继续在全部接口上泛洪，这能维持兼容，却也会稀释削减效果。只报告支持新机制的节点集合，等于把现实区域裁成了对结果更有利的实验区域。

稳定拓扑则是最容易的一关。链路断开、节点失效、Area Leader 消失、分区与恢复、连续快速变化都会触发重算和临时泛洪。如果回退过迟，或不同节点接收了不一致的图，一部分路由器可能缺少最新状态并产生不一致路由。平静一小时里的平均报文数无法覆盖这种风险。

在生成第一张稀疏图之前登记证据

实验台账首先应锁定身份：草案版本、RFC 9667 支持范围、实现名称和构建版本、成熟度、许可模式、测试责任人和时间。与该工作相关的 IPR 披露已经存在；运营者可以记录是否完成了相应审查，但本文不替代法律判断。

拓扑部分记录基础图指纹、节点与边数量、参与节点和旧节点范围、领导者及选举方式、计算图指纹，以及排序、平局和端点选取参数。敏感设备名和地址可用稳定化名替代；可复核不等于公开攻击地图。

指标部分必须先写分母与阈值。收敛从哪个事件起算，以哪一种观测结束；泛洪量在哪些接口、什么时间窗统计；单节点控制面负担、图直径和度数分布如何记录；允许多少丢失、重复和尾部延迟；何种结果自动触发暂停或回退。平均值之外，分布和最差样本同样属于证据。

韧性部分事先列出故障：链路、节点和领导者失效，分区及重连，连续拓扑变化，与旧节点混合，以及退回经典泛洪。每一次都要关联检测时间、临时泛洪启动、图替换、状态一致性、恢复时长和人工干预。

最后是决策部分：继续、缩小范围、暂停还是撤回；谁有权决定；哪条预设阈值被触发；保留哪些例外；何时复审。更正必须追加，不能用一张后来成功的仪表盘覆盖第一次失败的图。

RFC 7942 对运行代码信息给出了有用范式：实现主体、名称、成熟度、覆盖、版本兼容、许可、经验和互操作报告。此类事实随时间变化，通常不会固化在最终 RFC 中。动态泛洪实验因此需要一份独立于不可变标准文本的活台账，并最终为工作组要求的结果报告提供材料。

获批没有证明什么

已核查资料没有证明存在三个独立实现，也没有确认任何具名生产部署、性能收益、路由事故或厂商缺陷。十节点示例不能被改写成产品承诺。IPR 披露的法律与商业后果也不应由编辑报道代判。

运营审查过程值得准确描述。OPSDIR 对第 04 版提出“重大问题”，认为渐进部署、多算法并存、部署实践和节点失效等运营内容不足；第 05 版随后加入 Operational Considerations。这说明审查推动了文本完善，并不意味着所有未来实现问题已被永久解决。

《恒路笔记》中“最小初始规范”的原则在这里仅作为有限的编辑尺度：共同机制应尽量最小、确定且可本地核验，未来运营选择则要保留本地决策人与证据。这一原则不提供关于本次 IETF 审批或任何具体网络的事实。

因此，这次批准最有价值的部分不是给出答案，而是把问题固定下来。能否从实验走向更高标准，取决于多方运行代码、可比较指标和没有被删去的失败记录。

来源

1. IESG：动态泛洪算法审批公告
2. IETF Datatracker：Dynamic Flooding on Dense Graphs 第 05 版
3. IETF：文档 shepherd 报告
4. OPS Directorate：第 04 版 Last Call 审查
5. RFC 9667：密集图动态泛洪框架
6. RFC 7942：运行代码状态记录
7. IETF：IPR 披露 4044
8. Heng Lu：Minimum Initial Specification