摘要

  • RFC 9974 是 BIER 层 OAM 的功能要求清单，并明说可用于识别工具缺口；它不是任何网络的实时能力证明。
  • 文本对下行同路径同待遇、回程可不同以及主动探针的控制面限制作出的规定，说明每一次诊断都必须保留自己的证据范围。

RFC 9974 所做的工作很具体：它列举 Bit Index Explicit Replication（BIER）层的 OAM 方案应支持什么。会话应能由 BFR 或控制器发起；应支持主动和按需监测、主动和被动测量、出口可用性、下行连续性、性能、故障通知和生存性。文件也清楚说明用途：用这份清单做缺口分析，判断既有工具是否需要增强、是否应有新工具来完成路径监测和服务验证。

这定义的是工程目标，不是运行事实。它没有说某个域部署了某方案、某个控制器获准启动会话，或一条测试报文代表某项承载服务。在 RFC 8279 的 BIER 架构中，入口通过报文头中的位选择出口路由器，中间节点不必保存每流状态。“方案必须支持连续性”与“这次测量证明了这条服务的连续性”之间，仍隔着配置、范围、授权和观察的证据链。

RFC 自己划出了测量边界

RFC 9974 要求在下行方向，OAM 报文经过与被监测 BIER 流相同的节点和链路，并获得相同的转发待遇，包括 QoS。这个要求不是可省略的背景；它正是单次测试必须能证明的条件。若一个组合流包含不同服务等级的子流，运营者可以只在最高 CoS 上检查连续性，而不必逐一检查。

双向方法还保留了一个不能抹平的差别：下行必须符合上述条件，但从出口回到入口的方向可以走不同节点或链路，也可以有不同的转发待遇。因此，往返测量的回程结果不能自动成为下行路径的同等证据。RFC 提到 P2MP BFD with active tail、BFD、STAMP 和 Alternate-Marking，只是可对应某些要求的例子，不是对任何 BIER 域部署状况的声明。丢包、时延或时延变化的数值，同样只有在测量对象、区间、待遇和基准留存后才有解释空间；它们不是根因。

主动 OAM 还会制造自己的风险。在组播网络中，特制测试包可能被复制，一个 echo 请求可能带来多份回复。RFC 因而要求控制 echo 请求速率，也控制发送到控制平面的 BIER OAM 消息数量。这里的“必须支持”并不能证明实际阈值、实际配置或高负载下的效果。

Heng Lu 对协调工件的界定在这里很有用：共同的技术参考只有在参与者采纳并运行后才会成为运行现实。要求文档能让缺失的能力可见，但不能把承担服务后果的本地判断，悄悄转交给写下要求的文档。