Summary

  • IESG 于 9 月 21 日批准 draft-ietf-bier-ping-29 进入 Proposed Standard 轨道；目前不能把草案称为已出版的 RFC。
  • 草案要求用于监测某条流的 Echo Request 沿用其 BIFT-id、BSL、Entropy 和 DSCP；本文定义的 traceroute 仅适用于 MPLS 承载的 BIER，ping 没有同样限制。
  • 截至本次核查，IANA 工作仍在进行，RFC Editor 队列等待作者输入；公告只说部分机制已有厂商实现，没有给出全面互通结论。

BIER 的一个入口包，可以根据报头位串复制到多个出口。故障定位因此不是问“能否 ping 通一个地址”，而是问：探针带着什么转发条件，指向哪些 BFER，哪一个节点回答，以及没有回答的分支到底发生了什么。

9 月 21 日的 IESG 公告批准了第 29 版 Bit Index Explicit Replication (BIER) Ping and Trace，目标是让运营者在 BIER 数据平面内发现并隔离故障，而不必把 IP 层诊断当成唯一代理。这是规范程序取得的重要进展，却不是某种设备能力的合格证。

草案对探针与被监测流的关系写得很具体：BIFT-id、位串长度 BSL、负载分担熵值 Entropy、DSCP 都要一致。若监控平台只保存“成功／失败”，却丢掉这些值，事后便无法确认绿色结果是否来自同一转发环境。改变其中任何一项，路径或处理方式都可能改变。探针的证明范围必须和其实际设置绑定。

名称里的两个工具并不对称

“Ping and Trace”听起来像一套在所有 BIER 封装上通用的工具包。草案却明确把这里的 traceroute 模式限定在 BIER over MPLS，而 ping 模式不受此限制。采购、部署和事故报告若只写产品支持“BIER Ping and Trace”，遗漏封装、回声模式、出口位和软件版本，就无法让别的运营团队重演结果。

回声本身也不能越权。收到答复能够支持“这个 OAM 包在指定条件下到达并得到回应”的判断；它不能自动证明所有接收端都收到应用流量，更不能给未测量的丢包或时延填数。超时亦不必然等于多播数据路径损坏：回程、限速或设备尚未实现相关功能，都需要排查。

另一道交接在 IANA。草案申请 IP/UDP 封装 Echo Reply 所用的 UDP 端口，并涉及 BIER OAM 的协议值与登记表。IANA 专家意见特别澄清，端口是受控环境中单播回复使用，并非为多播业务载荷申请通用端口。这个区别会影响防火墙和暴露面判断，也解释了为什么不能从草案占位符猜一个正式端口号。

截至 9 月 24 日，Datatracker 把文件列在 RFC Editor 队列，显示 IANA action 仍在进行、RFC Editor 状态为等待作者输入。IESG 公告也要求工作组作者回答 IANA 的审查问题。这不是批准被撤回，而是提醒部署者：程序状态有多个节点，“批准”不能替它们逐一签收。

公告关于实现只用了谨慎的措辞：支持某种 BIER 的厂商已实现其中“部分”内容。它未列出厂商、测试组合或全面互通结果。卢恒的“运行代码优先”在这里不是用来否定标准程序，而是提出检验标准声誉的办法：把报文、分配号、设备行为和可复现的观察放在同一张证据表上。旧稿讨论的是最高 CoS 探针的推断边界；此次新消息的焦点，则是新的诊断规范如何从批准走到可核验的操作工具。

Sources