Summary

  • The 6 September PIM Working Group draft carries topology, algorithm and dataplane as one TAD tuple so multicast trees can follow a constrained path rather than the ordinary shortest path; revision 01 refreshes dates and references but does not change the mechanism from revision 00.
  • TAD is a tree-wide contract, not a hop-local preference: every router on the tree must participate in the same TAD, the numeric meaning must stay inside its IGP domain, and inconsistent joins can stop the PIM procedure or suppress forwarding.
  • Mixed-capability deployment is the hidden edge. The experimental PFM extension converts its richer source advertisement to a legacy form when a neighbor lacks support and deliberately discards sub-TLVs, including the place where TAD is carried.

The attractive promise is easy to draw. A network has two paths from a multicast source to its receivers. The shortest path is congested. A second path is longer but satisfies a bandwidth or latency constraint. Select the second path for this flow and leave everything else alone.

The current Multi-Topology in PIM draft proposes the control-plane machinery. Revision 01, dated 6 September, is an active PIM Working Group document intended for the Standards Track. It is still an Internet-Draft with IESG state I-D Exists, not an RFC or evidence of deployment. A comparison of the exact revision 01 with revision 00 shows date, expiry and reference updates, not a changed packet format or processing rule.

That limited revision history matters. The fresh date does not announce a freshly proven system. It returns attention to a design whose main operational question remains unresolved by syntax: can every participant maintain one coherent meaning from receiver policy to packets received?

Three coordinates become one forwarding instruction

PIM normally uses an underlying Multicast Routing Information Base to decide where Join/Prune messages travel. RFC 7761 explains the causal direction: joins travel hop by hop toward a source or rendezvous point, installing tree state; multicast data then follows the reverse path of those joins.

The draft adds a Topology-Algorithm-Dataplane tuple, or TAD. The topology selects an IGP topology. The algorithm selects a path computation, including the constraint-based Flex-Algorithms defined by RFC 9350. The dataplane identifies the forwarding context, including Segment Routing, the IP Flex-Algorithm context in RFC 9502, or a proposed soft dataplane.

Those are not decorative labels. Together they select the routing table used to find the upstream neighbor. The draft therefore says all routers on a given multicast tree must participate in the same TAD.

One tuple appears in two places. A first-hop router can advertise the source and group with a TAD sub-TLV through the PIM Flooding Mechanism. A last-hop router uses that information, or a local policy, to put a TAD Join Attribute into the Join/Prune message. Each intermediate router then looks up the matching TAD-aware unicast route and continues the join upstream.

An operator who sees the three fields decode correctly has proved only the first step. The fields must resolve to installed topology, algorithm and dataplane state on every relevant router. That state must select a reachable upstream. The resulting Tree Information Base must become an implementation-specific Multicast Forwarding Information Base. Only traffic counters and receiver observations show whether packets arrived without loss, duplication or an unintended path.

The same number can mean a different topology next door

The draft places a hard boundary around the tuple: a PIM message carrying a local TAD must not leave its IGP domain. Multi-Topology identifiers are protocol-specific. RFC 4915 and RFC 5120 define separate OSPF and IS-IS machinery; a value meaningful in one deployed domain need not name the same topology in another.

This is a governance boundary expressed as a packet rule. The tuple has authority only inside a domain that shares its registry, configuration and operational meaning. Transitivity in a message format cannot manufacture shared semantics across a border.

The draft exposes several other points where local discretion can fracture the tree. If two first-hop routers advertise the same source and group with different TADs, the last-hop router is told to choose using originator-address ordering, with the highest address preferred by default. If an LHR's configured tuple conflicts with the tuple it advertises, it must not send a TAD-bearing join. If TAD and an RPF Vector arrive together, local policy decides which one to ignore. If multiple TAD attributes arrive, the first is recommended.

Each rule is deterministic in isolation. Together they show why an inventory of configured values is insufficient. Two routers can both be “correctly configured” according to different local choices and still disagree about the one tree they are jointly constructing.

Failure is deliberately visible—but only if someone records it

When a router receives joins for the same state from different neighbors, it must check whether all carry the same TAD. If they do not, or if the TAD-aware routing table has no reachable upstream, the draft says to stop the PIM procedure and notify the administrator. A first-hop router should not forward until all received joins carry the same TAD.

This fail-closed tendency is safer than silently building an incoherent tree. It is not free. One inconsistent branch can suppress a flow whose other branches agree. An alert that says only “PIM stopped” loses the reason, the conflicting tuples, the neighbors, the selected policy and the last known forwarding result.

The security section is unusually direct: different topology and algorithm choices driven by different local policies may create a loop or prevent multicast forwarding. A forged router may also advertise source/group information with the wrong TAD sub-TLV. The document tells the administrator to take care over consistency, but does not provide a complete origin-authentication design for the new instruction.

That makes the TAD advertisement a privilege-bearing input. It should be logged with its originator, incoming interface, capability state, raw tuple, resolved local objects and policy decision. Otherwise a forged or stale advertisement and an authorized change look identical after they have both become three integers in a table.

The compatibility fallback removes the very selector being relied upon

The TAD source advertisement depends on a newer Group Source Info structure defined by the PFM forwarding-enhancements draft. That document is Experimental and currently in the RFC Editor queue. Routers announce GSI support in PIM Hello messages and track it per interface.

Where every neighbor supports GSI, a router forwards the richer TLV unchanged. Where any neighbor does not, it converts GSI to the older Group Source Holdtime form from RFC 8364. During that conversion it preserves group, source and holdtime—and must ignore the sub-TLVs.

TAD lives in one of those sub-TLVs. The fallback is therefore not a transparent tunnel for the path-selection intent. It is an explicit semantic downgrade. The legacy neighbor may still learn that a source exists while losing the instruction that says which constrained topology should be used.

That is the deployment boundary leaders need to see. A green capability flag on the first and last router is not enough. Every outgoing interface along the relevant flooding and join paths needs evidence. A topology can be connected for ordinary PIM and still be unable to preserve the TAD contract end to end.

A control-plane success is not a multicast result

The PIM Join Attribute specification supplies a way to carry additional join semantics. RFC 8364 supplies source discovery. Flex-Algorithm supplies constrained route computation. Their composition is useful precisely because each piece has a bounded job.

Composition also multiplies proof obligations. The source advertisement may be accepted while the sub-TLV is dropped on one interface. The join may carry TAD while a router lacks a corresponding route. The control plane may converge while MFIB programming fails. Packets may enter the intended plane while a receiver sees loss during switchover.

Heng Lu's Reality Layers names the error: document state, configuration, control-plane state, running forwarding code and observed outcome are related but not interchangeable. Running-Code Primacy puts the packet result above the elegance of the tuple.

The draft's best contribution is therefore not merely four new octets. It makes disagreement fail visibly. The operational task is to preserve that evidence until the person approving the multicast service can tell whether the whole tree agreed.