摘要

  • RFC 9978 以 Experimental 方式为单个 BFD 会话增加遗漏控制报文计数，使普通 Up/Down 状态看不见的早期抖动变得可观察。
  • 该计数可以启动一次有范围的核查；单凭它不能证明业务流量丢失、FIB 错误、LAG 成员故障，或自动切换安全。

数字很容易取得超出其范围的权力。某条 BFD 会话仍为 Up，lost-packet-count 却开始增加。告警屏幕于是从“收到的控制序列有间断”迅速变成“链路正在坏掉”，甚至变成“应立即迁走流量”。计数比二元状态细，因而显得更可信；但可信的观察并不自动扩展为可信的结论。

RFC 9978 于 2026 年 6 月作为 Experimental Protocol 发布，并非 Internet Standards Track。它处理的是BFD 控制报文的遗漏。基础 BFD 在 Detection Time 内至少收到一个报文即可保持会话 Up；RFC 9978 让该窗口内没有抵达的其他控制报文留下记录。RFC 同时明确排除数据流量丢失和链路或隧道时延测量。

这条排除不是缺口，而是读数诚实的前提：它见证一个接收端在某个会话、某套配置、某个时间段内看到的控制序列，不见证服务世界的全部状态。

计数究竟看到了什么

稳定性功能要求使用 meticulous BFD authentication type，使每个新控制报文的序列号递增一。启用 stability 后，ietf-bfd-stability 的 YANG 增补为会话导出 lost-packet-count。接收端比较连续的有效序列号，遇到不连续时可以计入缺口；第一个接受的非零序列号只用于初始化，不会补写此前历史。

因此，计数能支持的最强表述是：“此接收端观察到该会话的控制报文序列出现间断。”它能比 Down 更早地提示系统性问题，值得触发调查。它不能单独命名根因。

RFC 9978 特别指出，LAG 与 ECMP 可能让报文乱序到达而并未丢失。严格递增比较会把乱序误认作丢失；实现可以对预期但乱序到达的报文作处理。若不掌握交付上下文，增加的计数不能证明是哪条物理成员、哪条队列、哪个远端进程或哪条业务路径出了问题。

更重要的是，它不是业务测量。BFD 控制报文可能与客户流量具有不同的封装、QoS 处理、哈希选择、过滤规则或故障域。应用可以在计数升高时保持正常，也可以在控制流干净时失败。两种情况不互相否定，它们回答的是不同层的问题。

NULL 不是认证

RFC 9978 注册 BFD auth type 6 NULL，让原本没有认证的会话也能携带用于稳定性测量的序列号。这个名称不是装饰。RFC 明说它不提供认证所需的任何性质；注入报文可在不重置会话的情况下表现为高丢失，未认证 BFD 原有的会话重置风险也仍然存在。

所以计数必须带着其完整性条件一起流转。在边界清晰且可信的管理面上，NULL 产生的计数可以作为明确标注的诊断触发器。在多跳路由路径、隧道或存在注入风险的场景中，把它直接作为自动改路指令，就是把度量没有给出的结论加了上去。

RFC 9986 所称 meticulous，只是每个发出的报文都递增序列号；它不会让序列连续性变成服务认证、数据面测量或因果归属。

让它开启证据链，而不是关闭事故

应保留会话身份、对端、路径类型、认证模式、重置上下文、配置版本、接收器和时间。先判断乱序能否解释信号，再与 BFD client 状态和控制面事件比对。之后才选择真正覆盖待验证风险的测量。RFC 9978 提到 OAM CFM 与 MPLS 丢失/时延测量；RFC 6374 是另一个数据面测量表面，并不证明这里已经有数据丢失，却说明 BFD 计数不能暗中继承那一结论。

任何保护或路由变更之前，都应把本地 RIB/FIB、实际转发范围、相关 LAG/ECMP 证据与服务级 canary 加入记录。“观察到 BFD 稳定性异常”是准确告警；“客户受影响”与“自动故障切换安全”分别需要更高一层的独立证据。