摘要

  • IETF BIER 工作组的 BFD 草案第 12 版仍处于工作组最后征询阶段，并非 RFC。它把 BIER 中主动末端的非请求式通知明确接到 RFC 9780 的机制上，区别于 RFC 8563 的请求式做法；上一版已有非请求式通知章节，不能称此次首次发明告警。
  • 末端检测到 P2MP BFD 失效后，须用与组播树分离的单播路径通知入口，并以会话鉴别符关联故障。入口的 Final 回答确认通知交换，不代表原有组播转发已经修复。

同一条组播树上，入口发出控制报文，多个接收端各自判断自己能否持续收到。若其中一端失去连续性，观察首先发生在末端。入口并不会因为对方“已经发现”就自动得到故障记录。运营判断往往恰好在这一步跳得太快：把本地监测仪表的红灯，当作中心控制面已经掌握的事件。

9 月 29 日形成的 draft-ietf-bier-bfd-12 试图把这两个观察点接起来。IETF Datatracker 显示，它是 BIER 工作组的有效 Internet-Draft，工作组状态为 Last Call，IESG 状态仍是 I-D Exists。这些状态说明文本正在审议，不说明相关设备已普遍实现，也没有证明现实网络出现了某次事故。

草案使用点到多点 BFD 监测 BIER 路径。发送端 BFIR 向末端 BFER 发送控制报文；后者按 RFC 8562 的方式判断从入口到自己的连续性。RFC 8562 本身没有让入口获知每一个末端所见故障的完整机制。第 12 版第 6 节特别说明，在 BIER 上采用 RFC 9780 的非请求式主动末端通知机制，而非它所对照的 RFC 8563 请求式方法。这里的新闻不是从无到有：第 11 版已有“非请求式入口通知”小节；RFC 8563 也并非完全不提非请求式报文。变化在于所依循机制、字段与交互时序被写得更明确。

故障出现时，BFER 发送的 BFD 控制报文须设置 Poll，状态为 Down，诊断值为 Control Detection Time Expired；Your Discriminator 填入失效 P2MP 会话的 My Discriminator。目的地是 BFIR 的 IP 地址、UDP 端口 4784。它不是沿着可能已坏的 BIER 组播树“倒流”的报文；草案要求单播回程与组播分发树分离。接收端须每秒发送一个通知，直至收到对此会话有效的 Final 报文，或故障状态消失；为提高送达机会，文本还建议在一秒内按伪随机间隔发送三个报文。

入口收到后，使用 Your Discriminator 找到对应 BFD 会话，匹配后以设置 Final 的单播报文答复。这里有两种不同的会话识别视角：在末端，来自入口的报文要结合 BFIR-id 与入口的 My Discriminator；在入口，回传通知靠 Your Discriminator 分派。若记录只写“收到了 BFD 告警”，却没有保存匹配到哪一会话、是否收到 Final，就难以证明到底是哪条分支完成了报告。

草案同时提醒，许多末端同时受影响时，通知会涌向控制面，因此要考虑速率限制。由此可以作一个有限推论：入口没有告警，不足以证明所有末端健康；回程路径或接收能力也可能是盲区。反过来，Final 是通知交换的回执，不是原组播方向恢复的测试。这与先前关于 BIER Ping 获批及诊断参数的报道不同：此处讨论的是持续监测中，故障证据如何从末端抵达入口。

来源