Summary

  • draft-ietf-pim-multicast-over-srv6-01 says multicast distribution is orthogonal to Segment Routing. Its PIM and controller models install native IPv6 (S,G) or (*,G) state; they do not turn multicast into an ordered SID list.
  • Flex-Algo can steer the unicast route from which PIM derives its reverse-path interface. RFC 9502 nevertheless requires IP Flex-Algo participation to be advertised independently from SR participation. The same algorithm number is not one shared execution receipt.
  • An SRv6 migration therefore needs evidence for the source advertisement, algorithm definition and participants, RPF choice, exact multicast state, overlay mapping, branch replication and receiver outcome. A green SRv6 dashboard proves none of those by inheritance.

The brand and the packet tell different stories

Picture a network described accurately as an SRv6 underlay. Its unicast services use SRv6 locators and behaviors. A video source is advertised through Flex-Algo 128, chosen for low delay. The operations console then labels the service “SRv6 multicast.” Nothing in that sentence is necessarily false. It is merely too compressed to explain how one multicast packet reaches three receivers.

The distinction begins in the standards. The Segment Routing architecture defines SR as source routing for unicast and explicitly leaves application of that concept to multicast outside scope. SRv6 network programming supplies behaviors for packets carrying SR instructions. The multicast-over-SRv6 draft takes another route: multicast distribution is orthogonal to Segment Routing, so an IPv6-only SRv6 network can reuse native IPv6 multicast.

That choice is operationally economical. It is also easy to misreport. The network's architecture does not become the packet's proof. The native entry contains a source and group, an incoming reverse-path-forwarding interface and a set of downstream interfaces. It does not contain an ordered SID list that defines every replication branch. The draft's HTML and XML expose the same design without adding a hidden SRv6-specific multicast procedure.

Flex-Algo moves the ruler, not the forwarding model

PIM-SM builds a tree by asking a unicast question in reverse: which interface would this router use to reach the source? That interface becomes the RPF side; PIM state and receiver interest determine the outgoing list. A topology change can therefore move the unicast answer before the old multicast state has fully converged.

The draft applies Flex-Algo at precisely that boundary. With algorithm 0, the source follows the ordinary IGP shortest path. When the source prefix is advertised for algorithm 128, PIM can build the tree along the constrained IP paths calculated for 128. RFC 9350 defines the Flexible Algorithm Definition as more than a number: calculation type, metric type and constraints must agree inside the relevant scope, and unsupported definitions can cause a node to stop participating and remove forwarding state.

The sharper warning is in RFC 9502. IP Flex-Algo is an independent data plane. Participation for regular IPv4 or IPv6 forwarding must be advertised independently from participation for SR-MPLS or SRv6. A router can support FA128 for the IP data plane but not for SR, or the reverse. “All routers support Flex-Algo 128” is therefore an incomplete inventory unless it names the data plane and the selected definition.

This is why the title matters. The tree may be traffic-engineered by an IP algorithm inside an SRv6 network without being segment-routed. Flex-Algo changes the ruler used to compute reachability to the source. PIM still installs native multicast state. The distinction is not semantic fussiness; it determines which capabilities, telemetry and failure modes must be tested.

Two control planes can own different trees—and accidentally the same one

The draft also permits a centralized controller to compute and install native IPv6 multicast entries. That can support distribution trees too specific for PIM and Flex-Algo, or environments that want to avoid PIM's messages and RPF selection. It does not change the data plane: the live router still needs the correct incoming interface and downstream replication list.

PIM-created and controller-created trees may coexist when they use different source and group namespaces. That qualification is the control boundary. A controller success receipt proves that an API or datastore accepted an intended entry. It does not prove every branch programmed the forwarding plane, nor that PIM has not claimed the same (S,G). Ownership must be explicit enough to prevent one mechanism from withdrawing, replacing or aging state that the other believes it controls.

The draft says northbound route instantiation will be covered by a complementary document. That is an honest scope limit. It leaves authorization, transaction semantics, rollback and multi-node completion outside this text. An operator cannot import those missing guarantees from the word “centralized.”

An overlay adds mappings, not shortcuts in the proof chain

Legacy IPv4 multicast and VPN multicast can cross the IPv6-only underlay as overlays. The MVPN architecture and BGP MVPN procedures separate customer multicast state from provider tunnels. RFC 6515 permits IPv4 or IPv6 provider infrastructure addresses, while RFC 7716 extends the model to Global Table Multicast. RFC 8950 lets IPv4 reachability carry an IPv6 next hop.

In the draft's example, PIM-SSM creates a native IPv6 provider tree, MP-BGP signals the PMSI and customer multicast routes, and customer packets travel inside IP-in-IPv6. An outer Next Header value of 4 means the inner packet is IPv4; 41 means IPv6. That field does not identify the intended VPN, enumerate receivers or prove that every egress PE decapsulated and replicated correctly.

The draft is explicit that these overlay mechanisms impose no SRv6-specific requirement. This is the second category error to avoid. “Transported over an SRv6 network” does not mean the overlay used an SRH, a service SID or a multicast SID. Acceptance evidence must show the customer flow, its PMSI mapping, provider (S,G), branch counters, egress decapsulation and authorized receivers.

Revision 01 refreshed the clock, not the mechanism

The frozen Datatracker API, document page and history record an active PIM Working Group Internet-Draft. The header calls it Informational; the Datatracker has no responsible AD, shepherd or telechat. It is not an RFC, implementation report, deployment census or performance result.

The revision-00 text and revision 01 have no substantive textual change in the frozen comparison. Dates, expiry, revision number and page headers changed. A new version number should not be inflated into new consensus, new functionality or new operational evidence.

The security section says the draft introduces no new issue beyond its cited specifications. Read that as a scope statement. It does not authenticate a controller write, guarantee consistent FAD deployment, prevent a wrong PMSI mapping or prove that a receiver obtained the service. Inherited systems keep inherited attack and configuration surfaces.

Sources and limits

The technical basis is the frozen revision text, HTML and XML, compared with revision 00 and bounded by the API, status page and history. Protocol context comes from PIM-SM, MVPN architecture, BGP MVPN, provider-address updates, GTM, Segment Routing, IPv4 NLRI with IPv6 next hop, Flex-Algo, IP Flex-Algo and SRv6 programming.

No source established a named deployment, vendor support matrix, interoperability test, convergence time, loss figure, security incident or application SLA.