摘要

  • RFC 9985 对 BFD 的重大状态变化使用 MCI，对大量不改变内容的 Up 报文允许使用 LCI。
  • 认证成功是某一 BFD 会话的有限证据，不能自动升级为流量、服务或商业动作的决定权。

它划分的是计算成本，不是绝对等级

MCI 和 LCI 的名称很容易被误读为“强”和“弱”。RFC 9985 特意不这样定义：二者的相对标准是对实现的影响。BFD 的价值取决于它能在足够多会话上以足够频率工作，因此把高成本计算放在真正改变状态的时刻，是一种资源治理，而不是降低其他责任的理由。

AdminDown、Down 与 Init 必须用 MCI。状态变化、Demand 位变化、Poll 或 Final 的变化，以及某些参数变化也属于重大变化。会话已经处于 Up 时，采用 LCI 的报文不能改变认证段之外的内容。高频报文因此只能维持已获得的会话意义，不能悄悄写入新的状态。

Up 仍只是被封装边界内的观察

RFC 5880 将 BFD 设计为发现到转发平面下一跳的通信故障，并把每个会话绑定到其封装。Up 表示该会话所描述的连通性在工作；它不是端到端应用事务、所有等价多路径、可用容量或客户体验的总判断。把一个清晰的协议状态扩张为模糊的服务结论，是自动化最常见的越界。

RFC 9314 也没有混淆层次：它同时描述 BFD 配置、会话运行状态和使用 BFD 的客户端。路由协议可以按自身收敛规则处理信号；流量控制器还要核对策略、容量和回退；服务负责人还要看应用观测。每一层都可以使用 BFD，却不能从 BFD 继承未被授予的权限。

定期 MCI 检验只关闭会话窗口

LCI 并非让会话无限期地免于更高成本的检验。RFC 9985 建议周期性地以 MCI 发起 Poll 序列；在规定边界内收不到经 MCI 认证的 Final，必须将会话置为 Down。该重认证间隔可配置，正是本地运营者必须明确承担的风险选择。

现有 LCI 配对涉及 RFC 9986 的 Meticulous Keyed ISAAC。该 RFC 对密钥分发不作规定，并说明对 ISAAC 的分析有限且仅应限于所述用途。它们不是把单次 LCI 成功判为无效，而是提醒任何人：该成功不能填补密钥保管、部署证据或服务影响之间的空白。

通知客户端也有独立门槛

RFC 9985 建议在向 BFD 客户端报告会话 Up 之前，先确认向 LCI 的转换成功。原因很朴素：MCI 下看似有效的内部转换，若无法进入实际维持会话的模式，就不应被下游当成完成的事实。

资料来源