摘要

  • PIM 确定性 ECMP 草案第 01 版让下游节点对组播源、组和候选上游的 Router ID 或 Color 值做哈希，挑出最高结果，目标是让同一条流少占几条等价路径。
  • 草案的 Arista 兼容附录记录现有私有 Hello 选项及小端序 Color 哈希；正文拟议的公开 Color 哈希用网络字节序。Cisco 附录又记录了另一套 Router ID 哈希与平局处理。
  • Color 的公开选项编号仍是 TBD。判断一座机房是否真的形成同一棵树，要看各叶节点收到的 Hello、参与比较的上游以及实际 Join 去向。

重复流量的源头并不在播放器。叶脊网络里，几台叶节点到组播源可能都有等代价路径。每台叶节点都要选一个逆向路径转发邻居，把 PIM Join 发过去。若它们选了不同的脊节点，同一条流就可能在多条上行链路上出现。RFC 7761规定 PIM-SM 怎样维持逆向路径和 Join 状态，却没有替每个等代价场景指定同一个胜者。设备实现与网络配置填上了空白。

新草案先给两层网络一条共同算法：拿源 S、组 G 与每个合格上游的 Router ID 计算哈希，选择结果最高者；撞上平局，再用本地信息决胜。纸上看是“确定性”，条件却很硬：各叶节点必须看到相同候选，喂给算法相同输入，还得执行同一种算法。某台叶节点少看见一个候选，即使程序一行不错，也会选出另一条路。

三层网络更难。中间层节点可以在 PIM Hello 里携带四字节 Color，表示它所连接的上层脊节点等分组。叶节点改按 S、G、Color 计算哈希。草案只让发布了 Color 的上游进入这轮比较。于是上线顺序就成了选路变量：先给一部分接口打开 Color，候选集合随之收缩；另一部分接口还按旧规则走。迁移计划若只写“启用新选项”，却不写每条邻接何时启用，就没有说明组播树会怎样移动。

附录把既有实现摆到了桌面上。Arista EOS 已使用两个私有 Hello 选项：65001 带标识私有格式的固定值，65002 携带 Color。拟议中的公开选项编号还未分配。草案建议标准实现默认不要收发那对私有选项，但允许按接口打开兼容。这个按接口的开关很实在：同一台设备一侧开、一侧关，邻居看到的候选和标记就可能不同。运维者得知道每个接口到底讲哪一种话。

字节序把差异再推进一层。草案正文的 Color 哈希按网络字节序排列四字节值，Arista 兼容哈希按小端序排列。草案要求候选集合里只要有一个节点用私有 Color，就用 Arista 兼容算法比较。提案写出了过桥规则，现网是否都按规则过桥仍须逐台验证。抓包看见同一个 Color 数值，并不能证明两端把相同字节序列喂进哈希。画在图上的“同色”，可能算出两个胜者。

Cisco 的附录也没提供一键统一的答案。它记录 Cisco 独立采用 RFC 7761里的 RP 哈希处理基于 Router ID 的选择，平局时用 RFC 6395 Hello 通告的接口 ID。正文采用 Jenkins 哈希，并可用本地信息破平局。验证差异无需猜测厂商意图：选一个具体 (S,G)，列出每台叶节点的候选邻居、收到的 Hello、哈希输入与选中的上游；再切断一条脊节点链路，重复记录。两个胜者是否同时出现，会在这张表里露面。

这也解释了草案为何专门比较 RFC 6754 的 ECMP Redirect。Redirect 允许上游在 Join 发出后要求下游换路；正在运行的流可能在纠正时移动。共同哈希则希望一开始就选对，省去事后转向。代价是大家必须共同理解候选、Color 和哈希。一个方案把协调放在事后消息，另一个把协调压进部署前的兼容性测试。

草案尚无实测节省带宽的数据，也没有记录混合设备导致的事故。它提供了更有价值的检查位置：公开规则和现网规则交接的那一个接口。标准编辑能定义字段，厂商能实现算法，真正付链路账单的网络运营者仍得证明 Join 发往哪里。只要这个证明缺席，“确定性”就是配置里的形容词，流量才是裁判。

PIM 草案第 01 版 · RFC 7761 · RFC 6395 · RFC 6754