摘要

  • draft-ietf-bier-source-protection-11 明确指出：备用 BFIR 到已选 BFIR 的监测路径可能中断，而已选 BFIR 到全部或部分 BFER 的转发路径仍然正常。此时接管既多余，也会在网络和接收端制造重复包。
  • 反向 Ping 也不能自动代表正向组播路径。若两者不共路，Ping 可能失败而业务正常，也可能成功而业务路径已经损坏。
  • 观测对象、探测结论、冷/暖/热备状态、切换授权、丢包或重复、接收连续性与应用结果必须各有回执。第 11 版是信息类工作组 Internet-Draft，不是部署证明。

凌晨三点十七分，备用入口的计时器到期。它已经连续几个周期没有收到主入口的信号。控制器把状态改成 Down，备用入口随即开始为同一批接收者转发。

主入口并没有停。它到三个 BFER 的路径也没有断。断掉的只是两个入口之间那条用于相互观察的窄路径。于是同一条流从两个入口同时进入网络：技术系统准确报告了“我看不见它”，运营叙事却把这句话扩写成“它已经不能服务任何人”。

BIER 冗余入口故障切换第 11 版最重要的价值，就在于把这类错误写进机制本身。问题不只是误报率，而是一个控制权边界：探测器观察的是哪条路径，它又被允许改变哪条路径？

同一拓扑里存在多条有方向的事实

RFC 8279中的 BIER 由 BFIR 把组播包送入域内，BFER 接收，核心路由器依据包内 BitString 转发而不保存每流组播状态。每个 BFER 仍要为具体流选择上游组播跳点。MVPN、MLD 或 PIM 等 overlay 传播选择所需的流信息，BIER transport 承担数据包传输。

草案把已选入口称为 S-BFIR，把备用入口称为 B-BFIR。这个角色不必全网一致：不同 BFER 可以为同一条流选不同入口，两台入口也可能分别服务不同接收者子集。因此，“主入口宕机”本身就过于粗糙。

至少要保留三条有方向的路径身份：

  1. B-BFIR 到 S-BFIR，备用入口用它观察主入口；
  2. S-BFIR 到各个 BFER，业务包沿它正向分发；
  3. BFER 到 S-BFIR，接收者可能沿它发送反向 Ping。

它们有时共享链路，但不能假定相同。第一条断裂，只能证明备用入口在那条路径上失去了预期信号；它不能独自证明 S-BFIR 节点死亡，更不能证明第二条路径失效。

草案给出的暖备场景很具体。BFIR2 监测 BFIR1，二者之间路径中断。BFIR2 将其解释为 BFIR1 故障并接任 S-BFIR。然而 BFIR1 到所有或部分 BFER 的路径仍在工作。草案直接称这种切换为不必要，并指出它会在域内与 BFER 处产生重复包。

反过来也成立：两入口之间的监测链路保持健康，并不保证 BFIR1 到某个 BFER 的业务路径仍然健康。绿色探测灯和真实业务中断可以同时存在。

Down 不是一句完整的话

RFC 5880的 BFD 对特定转发路径进行故障探测。RFC 8562把它扩展到多点场景。BIER BFD 第 12 版提供 BIER 环境的会话引导与 active-tail 通知。它们可以很快，但快速不会扩大证据范围。

已记录状态 可以成立的结论 不应擅自扩大的结论
B-BFIR/S-BFIR 会话 Down 该会话越过了故障阈值 S-BFIR 到所有 BFER 的路径都断了
反向 Ping 无响应 该反向探测未完成 正向组播已经停止
某 tail 越过 Detection Time 该接收点没有收到预期控制包 所有接收者都失去业务
BFER 选择新 UMH 该流、该接收者的 overlay 选择已变 应用已经恢复
备用入口开始发送 网络里出现第二个发送源 每个重复包都已被正确丢弃

一条可审计的探测回执必须保存方向、两端、子域、流量处理方式、熵或选路输入、会话 discriminator、探测间隔、阈值与业务类别。只剩 Down 的日志，既无法解释，也无法在事故后复原因果。

反向 Ping 会向两个方向说谎

BFER 可以向 BFIR1 发出 Ping，若多个预期周期没有回应，就把 BFIR1 当作失败的 UMH 并选择 BFIR2。但被保护的组播包从 BFIR1 前往 BFER，Ping request 却从 BFER 反向前往 BFIR1。

复杂网络的双向路径不必对称。草案明确写出两种错误：Ping 失败但组播路径与流都正常；组播路径有缺陷但 Ping 仍能成功。因此，它要求 echo request 与被监测的正向路径共路，以提高探测一致性。

这里的“提高”不能被改写成“证明”。共路只是让探测更接近它所代表的转发面。它仍不能证明接收端得到完整、有序、无重复的流，更不能证明上层应用连续工作。

冷备、暖备、热备是在搬运风险

组播冗余入口第 10 版把模式分成冷备、暖备与热备。三者不只是切换速度不同。

冷备由接收端在故障判断后才向备用入口请求流量。平时没有重复流，却会承受 signaling 与收敛造成的丢包。

暖备让主、备入口预先知道接收需求，但正常时只有主入口发送。备用启动更快，也因此获得一项危险权限：它可能在看不见接收路径的情况下自行判断主入口失效。

热备让两个入口同时发送，BFER 丢弃未选入口的那一份。切换损失可能更小，代价是域内长期重复流量、带宽预算，以及接收端持续承担正确筛选的责任。

所以，“最快故障切换”不是完整采购目标。决策者必须说明丢包由谁承担、重复带宽由谁承担、状态由谁同步、哪个主体有权宣布故障、哪个主体能推翻误判。

不同接收者可以持有不同的主入口事实

草案允许不同 BFER 选择不同 S-BFIR，也允许不同 timeout。一个 BFER 可能已经切到 BFIR2，另一个仍接收 BFIR1，第三个还在等待 Detection Time。用一个全局 primary_failed 覆盖它们，会把合法局部差异与失控双主状态混在一起。

更小的决策键应接近：流身份、接收者或接收者集合、已选 BFIR、观测路径、探测器、阈值和状态版本。

切换后还需要两组回执。控制组说明谁、何时、依据什么规则改变 UMH。效果组说明 BFIR2 何时真正开始、BFIR1 何时真正停止、出现多少丢失/重复/乱序、每个 BFER 接受哪个来源，以及应用实际看到什么。

“收到 BFIR2 的包”只能证明一个包从备用入口抵达，不能证明所有 BFER 已收敛，更不能证明旧源已退出。

工作草案的边界必须留在文章里

第 11 版是 2026 年 10 月 1 日更新的 BIER 工作组 Internet-Draft，预期状态为 Informational。它不是 RFC，不请求 IANA 分配；安全章节引用底层 BIER、multipoint BFD、MVPN failover、BIER Ping 与 BIER BFD 文档。

这足以证明设计文本认识到观测路径错位、正反误判和不必要接管。它不能证明某个厂商已经实现，某个运营商已经部署，或任何真实组播业务成功恢复。

《现实层》要求把探测器的符号状态锁回它实际采样的物理表面。《政策之镜》则要求在探测结果能够改变拓扑时，记录行动者、规则、范围与后果。

故障切换回执

每次自动切换至少保留：流身份；S-BFIR 与 B-BFIR；涉及的 BFER 集合；冷/暖/热备模式；overlay 与既有选择状态；探测器和会话；有方向的观测路径；探测流量与业务流量处理等价证据；计时器、阈值与缺失包数量；授权切换的主体；每个 BFER 的旧/新 UMH；两入口的实际开始与停止时间；丢包、重复、乱序计数；接收端接受状态；应用连续性证据。

没有共路证明时，记录“路径等价未验证”；备用入口不知道接收路径时，记录“接收路径未知”。未知不是日志缺陷，而是限制切换权限的事实。

Sources