摘要

  • RFC 9384（2023年3月）为BGP定义Cease子码10“BFD Down”，使BFD触发的拆除对接收方可观察；Juniper 22.3R1与Arista 4.29.0两个实现被报告为符合规范，但这是厂商自报，而非独立测试。
  • RFC 5880勘误5205（Dave Katz报告）记录了一个规范级缺陷：AdminDown信号后链路单向失效时，对端不出超时指示；勘误7240由Jeffrey Haas本人报告，记录实现偏离而规范文本“正确”。
  • IESG核验的RFC 5882勘误8921只修正了一条内部章节引用；RFC 9978（BFD Stability）明确承认发布时“没有已知实现”。
  • 结论：BFD/BGP故障信令修复目前处于“已规范、部分实现”状态，而非“已持久验证”。

当链路在BGP还看不到问题之前已经失效，运营商依赖的正是BFD与BGP之间的信令通道。这条通道的规范性文件是RFC 5882第10.2节：对EBGP，BFD会话应建立在BGP邻居上，且强烈建议开启BFD认证；若Graceful Restart生效，则按其流程处理而非立即拆除。

这条文本本身也带着已记录的缺陷。RFC 5882的内部交叉引用“Section 3.2”被勘误8921纠正为“Section 4.2”，该勘误由Xiao Min于2026年5月19日报告，并由IESG的Ketan Talaulikar核验。这是IETF勘误流程中最接近“已验证”的状态——但它验证的是一条引用修正，不是任何运行时行为。

RFC 5880的勘误更直接地触及故障检测本身。勘误5205（技术性，Dave Katz报告，留待文档更新）指出，第6.8.4节中“Init或Up”条件使得会话在Down状态下的超时成为无操作并抑制诊断码：当系统A发出AdminDown、随后链路单向失效时，B发出的Control包中不再有任何超时指示。勘误7240（技术性，Jeffrey Haas报告，留待文档更新）记录bfd.LocalDiag被多个实现重置为零——勘误备注同时声明规范文本“正确、完整并反映作者意图”。这是规范与实现之间的分歧，而非规范错误，两者在证据等级上是不同的事实。

修复方向的证据呈现明显的层级。RFC 9384把BFD触发的拆除变成可观察事件：接收方“将理解连接因BFD检测到的问题而终止，而非BGP对端自身的问题”，并在总连接丢失时应将原因记录到运营状态。IETF社区Wiki的实现报告列出Juniper 22.3R1（联系人Jeffrey Haas）与Arista 4.29.0（联系人Bill Fenner），在发送子码、运营状态上报与RFC 8538 Hard Reset封装三方面自报“符合”。未提供独立测试方法。

IETF 118的IDR会议幻灯片报告Junos与SRoS之间BGP strict-mode互操作成功（Strict-Mode Capability，选项74/0x4a），同时记录了一家专有实现不支持动态strict-mode信令、需两侧静态配置——幻灯片称之为部署复杂化因素。Junos出货文档描述了完整行为：BFD在允许等待区间内未上报Up，BGP会话即被重置并向对端发送子码“BFD Down”的通知；FRR文档则实现了neighbor bfd strict [hold-time]。这是两种独立实现的存在证据，仍是厂商自撰文档。

BFD工作组正在以bis修订推进RFC 5880–5883，2026年12月的里程碑是将RFC 5880/5882推进到Internet Standard。strict-mode草案（-19，2026年8月26日，作者含HPE的J. Haas）增加了协商能力、hold-down与dampening作为稳定性考虑。RFC 9978定义的BFD Stability机制——用递增序列号检测会话内丢包——明确站在另一端：Experimental，“没有已知实现或概念验证”。

资料来源