摘要

  • 草案第 19 版用 Capability 74 让双方协商 BFD 严格模式，但实现附录列出的运行代码分别声称兼容第 17、12 和 7 版，不能把同一个能力码当成完整版本收据。
  • 状态机在演进：等待本地 BFD Up 时收到对端 KEEPALIVE 的处理、hold-down 与 BfdHoldTimer 的关系，都可能影响会话能否进入 Established。
  • 生产准入必须记录设备版本、真实模式、发送与接收的能力、支持的计时器、待定子状态及异构配对测试结果。

变更单上，两台路由器都写着“支持 BGP BFD strict mode”。抓包里，两边也都发出了 Capability 74。会话仍然反复回到 Idle。工程师直到查看实现附录才发现：一边声明兼容草案第 17 版，另一边的实现基于更早版本，而且没有变更计划依赖的 BfdHoldTimer。

协议编号相同。运行语义不在同一个时间点。

draft-ietf-idr-bgp-bfd-strict-mode-19 是 2026 年 8 月 26 日发布的 IDR 工作组活跃 Internet-Draft，计划走 Standards Track，但尚非 RFC。Datatracker 仍标为 I-D Exists。OPS、SEC 与 BGP Directorate 的早期审查说明文本还在接受澄清与修订。文章讨论的是证据边界，不把草案状态写成批准，也不把附录中的厂商条目写成互通认证。

能力协商只回答一层问题

第 19 版规定：本地启用且支持严格模式时，在 BGP OPEN 中发送长度为零的 Capability 74；只有对端也发送时，BfdStrictNegotiated 才为真。此后，BGP 状态机把本地关联 BFD 会话达到 Up 作为继续握手的前提。

这套设计避免一台设备单方面猜测对端是否接受新规则。它证明双方在协议层宣告了同一能力。它没有携带实现所依据的草案修订号，也没有列出每个可选计时器、厂商兼容分支或本地 override。

规范演进时，能力码通常保持稳定。否则每次修订都更换编号，部署几乎无法延续。但稳定编号把另一项责任交给实现和运营：新旧行为必须在共同兼容范围内，差异必须能被观测和回退。

Cisco 当前文档把普通或专有 strict mode、协商模式和 override 分开。Juniper 要求两端都宣告能力，并建议两端采用一致配置。名称相近不表示触发条件相同。一个控制器若只采集布尔值 strict=true，会抹掉最关键的语义。

状态机修订不是编辑噪声

严格模式把 BFD 事件嵌入 RFC 4271 的 BGP FSM。第 19 版增加或明确了多个待定子状态：Connect、Active、OpenSent 阶段可以已经交换 OPEN，却因为本地 BFD 未 Up 而暂不发送 KEEPALIVE。

最有说明力的是 OpenSentConfirmedBfdUpPending。对端 BFD 可能先 Up，对端 BGP 因而先发 KEEPALIVE。本地已经收到这条消息，但本地 BFD 仍未 Up。状态机需要同时保留“对端握手已推进”和“本地门槛未满足”两条事实。

BGP Directorate 对第 18 版的审查指出了这场竞态：如果普通 OpenSent 逻辑把提前到达的 KEEPALIVE 当作错误，TCP 会被重置。第 19 版加入专门处理。这个变化说明修订号为何具有运行意义。它不是文字排版；它改变设备在同一包序列下采取的动作。

审查还质疑 hold-down 应由哪份规范定义，以及未配置 peer 如何提前建立 BFD 所需的远端地址。OPS 审查要求在继续详细评审前澄清 BGP peer、BFD 与 graceful restart 的组合。不能把“已有 running code”解释为“所有组合已被标准化”。

附录展示存在性，不颁发等价证书

RFC 7942 鼓励草案记录实现状态。第 19 版附录列出 Junos 23.2R1 及以后版本，标注对应第 17 版；IOS XR 24.3.1 及以后版本，标注对应第 12 版；Nokia 23.7R1，标注对应第 7 版，并注明该实现尚未支持 BfdHoldTimer，计划后续加入。

这些信息很有价值，因为它把“可能实现”变成“有人报告运行代码”。但字段 Used 不是互通测试报告。草案作者收集的实现陈述也不是当前所有平台、镜像和配置的保证。尤其不能据此断言三个条目彼此完成了第 19 版的全矩阵测试。

Running-Code Primacy 不是让旧代码自动压倒新规范。它要求把真实代码放进决策：当前到底跑哪一版行为、哪些状态和计时器存在、两台设备在相同事件下如何迁移。没有这些观察，引用“running code”只会成为新的符号权威。

缺失一个计时器，会改变失败的形状

当协商出的 BGP holdtime 为零，第 19 版用 BfdHoldTimer 防止等待 BFD 无限持续，默认 BfdHoldTime 为 30 秒。另一个 hold-down 可以要求 BFD 保持 Up 一段时间。两端本地配置这些值，草案只建议相近，并不协商同一数值。

若某个实现没有 BfdHoldTimer，不能简单说它“不支持严格模式”。它可能实现能力协商和多数 FSM 事件，却在 holdtime 为零的等待边界表现不同。正确描述是具体缺口及其适用场景，而不是给整个产品贴合格或不合格标签。

同样，已进入 Established 后修改严格模式，第 19 版对当前会话忽略该配置事件。运行行为可能要到下一次重启才改变。配置数据库已更新，并不等于会话语义同步更新。变更系统必须分别记录 desired、effective 与 next-restart 状态。

互通证明必须能重放

异构准入清单至少包括：平台与镜像；厂商命令的精确模式；声称兼容的草案或文档版本；Capability 74 发出、收到和协商结果；BFD 会话端点、鉴权与 discriminator；BGP holdtime；BfdHoldTime、hold-down 与 dampening；当前 pending 子状态；收到的 KEEPALIVE；最终进入 Established 或关闭的原因。

测试应重放规范变化涉及的边界：让远端先 Up 并提前发送 KEEPALIVE；把 BGP holdtime 设为零并阻止 BFD Up；采用不对称 hold-down；在 Established 后改变配置；移除对端 capability；只丢弃 BFD 包而保留 TCP/BGP。每种输入都应在两端产生可解释、可预测的状态。

回滚也要基于有效语义。关闭一端协商模式后，另一端是否回到普通 BGP，还是仍有 unilateral override？当前 Established 会话是否需要受控重启才能采用新配置？路由删除与恢复是否只影响目标 peer？答案必须在演练中得到，而不是事故时推测。

Capability 74 的价值在于提供最小共同握手。它不需要承载所有版本历史。运营系统则必须补足剩余证据。编号可以稳定，兼容性不能靠稳定编号想象出来。

真正的风险不是一台设备“太旧”。风险是组织把版本差异压缩成一个绿色勾选，然后让两台状态机在生产流量旁自行发现它们等待的并不是同一件事。

来源