摘要

  • draft-ietf-pim-multicast-over-srv6-01 明确把多播分发与 Segment Routing 视为正交问题，采用的是原生 IPv6 (S,G) 或 (*,G) 转发表项，而不是多播 SID 序列。
  • Flex-Algo 可以改变 PIM 用来做 RPF 的单播路径；RFC 9502 仍要求 IP 数据面的参与信息与 SR-MPLS、SRv6 分别通告，同一个算法号不是同一份执行证明。
  • 真正的验收链应分别核验源通告、算法定义和参与节点、RPF 选择、PIM 或控制器所有权、硬件转发表、overlay 映射、分支复制以及接收端结果。

验收清单里最危险的是一个合并单元格

设想迁移项目的最后一张表：网络类型写 SRv6，策略写 FA128，多播一栏写“通过”。这个合并单元格让三件事看起来像一个机制。第一件是 underlay 的单播架构；第二件是到源地址的受约束 IP 计算；第三件是每台路由器如何接收并复制某个源组流量。它们可以同时成功，也可以在其中一层悄悄分叉。

RFC 8402 对 Segment Routing 的架构定义以单播 source routing 为核心，并把该概念应用于多播留在范围之外。RFC 8986 定义 SRv6 网络编程行为。最新的 PIM 草案文本 则直接说明多播分发与 SR 正交；其 HTML 和 XML 版本没有隐藏另一套 SRv6 多播过程。

草案选择复用 IPv6-only 网络已有的原生多播能力。实时状态的关键字段是源、组、RPF 入接口和下游出接口集合。它没有一条按顺序规定每个分叉点的 SID 列表。因此“在 SRv6 网络上传输多播”可以是准确描述，“多播树已由 SRv6 指令定义”却是多加出来的结论。

同一个 128，在两个数据面上可能是两张名单

PIM-SM 的上游判断来自单播表：路由器会沿着自己前往源的方向建立 RPF 侧，再依据接收者兴趣维护下游接口。草案允许源前缀进入例如 Flex-Algo 128，使 PIM 使用该算法算出的受约束 IP 路径。这样可以避开链路、选择特定度量，但复制模型依然是原生多播。

RFC 9350 表明，算法定义不只是数字，还包含计算类型、度量和约束。作用域内定义不一致，或者节点不支持某个定义，都可能让节点退出参与并撤掉状态。RFC 9502 又划出更清楚的边界：常规 IPv4/IPv6 转发的 IP Flex-Algo 是独立数据面，参与信息必须与 SR-MPLS 或 SRv6 分开通告。

所以供应商写“支持 FA128”不够。必须追问：支持哪个定义，在哪个数据面参与，源前缀以什么算法通告，当前 RPF 实际选了哪条接口。SR 参与正常不能替 IP 参与作证。拓扑变化时，单播表可能先切换而 PIM 状态还没收敛，旧接口上的包立刻可能过不了新的 RPF 检查。

控制器成功返回，不代表每个分支已接管

草案也允许中心控制器计算并下发原生 IPv6 多播表项。这适合需要特定树形或不希望依赖 PIM 消息的环境，但没有改变转发语义：每个分支节点仍须装入正确入接口和出接口列表。API 接受了一次写入，只能说明意图进入某个系统，不能说明所有设备硬件都成功编程，更不能说明接收者已经看到连续业务。

PIM 树与控制器树可以共存，前提是使用不同的源和组。这句话实际规定了控制权边界。如果双方碰到同一个 (S,G)，PIM 定时器可能回收控制器认为永久的状态，控制器的重调和也可能覆盖分布式选择。草案把 northbound 路由实例化细节留给补充文档；授权、跨节点事务和回滚都不能从“中心化”三个字中推导出来。

运营系统因此要显示所有者、意图版本、逐节点应用结果和实时硬件状态。两套控制平面各自健康，并不保证它们合在一起时没有争抢同一棵树。

Overlay 并没有把证据链折叠起来

IPv4 或 VPN 多播跨越 IPv6-only underlay 时，还会多一层客户流到提供商树的映射。RFC 6513 给出 MVPN 架构，RFC 6514 给出 BGP MVPN 过程，RFC 6515 允许提供商基础设施使用 IPv4 或 IPv6 地址。RFC 7716 扩展到 Global Table Multicast，RFC 8950 允许 IPv4 NLRI 携带 IPv6 next hop。

草案示例中，PIM-SSM 建立原生 IPv6 提供商树，MP-BGP 通告 PMSI 和客户多播路由，客户报文再以 IP-in-IPv6 承载。外层 Next Header 的 4 只表示内层 IPv4，41 只表示内层 IPv6；它不证明 VPN 归属、接收者名单、出口解封装或分支复制。草案还明确表示这些 overlay 不需要 SRv6 特有过程。验收必须逐项核验客户流、PMSI、提供商 (S,G)、分支计数、出口 PE 和授权接收者。

版本号更新的只是时间边界

冻结的 Datatracker API、文档页面 与历史记录 显示它是 PIM 工作组的活动 Internet-Draft。页眉目标为 Informational；页面没有负责 AD、shepherd 或 telechat。它不是 RFC、部署普查、互操作报告或性能测量。

冻结比较表明，00 版 到 01 版只改变日期、到期日、修订号和页眉，没有实质机制变化。安全部分称没有超出引用规范的新问题，应理解为范围声明；它不会认证控制器写入，不会证明全网 FAD 一致，也不会发现错误的 PMSI 映射。

来源与结论边界

来源集包括 01 文本、HTML、XML、00 文本、API、状态页 和历史。协议背景来自 RFC 7761、RFC 6513、RFC 6514、RFC 6515、RFC 7716、RFC 8402、RFC 8950、RFC 9350、RFC 9502 和 RFC 8986。这些材料没有给出具名部署、厂商矩阵、收敛时长、丢包率或应用 SLA。