Summary

  • PIM deterministic ECMP draft revision 01 proposes that downstream routers hash the multicast source and group with a candidate upstream router ID or a four-byte Color, then choose the highest result. Shared choices can avoid duplicate copies of one stream across equal-cost paths.
  • The draft's Arista compatibility appendix describes a private-use Color Hello option and a little-endian Color hash. Its proposed standard Color hash uses network byte order. A separate Cisco appendix records a different router-ID hash and tie breaker.
  • The Color option code is still TBD, and revision 01 is an IETF working-group draft. An operator's proof of deterministic selection is a mixed-device Join trace and failover result, not the word “deterministic” in a configuration guide.

The duplicate stream is born before a packet reaches the application. In a leaf-and-spine fabric, several downstream routers may have the same-cost path back toward a multicast source. Each sends a PIM Join to an upstream neighbor. If the leaves independently select different spines for the same source and group, the fabric draws multiple copies of traffic across links that could have shared one upstream tree. The PIM-SM specification, RFC 7761, requires a reverse-path forwarding choice but does not settle that equal-cost tie for every leaf. The tie has been left to implementations and deployments.

The new draft's answer starts with a hash. For a two-tier network, each leaf computes a value from source S, group G and each eligible upstream router's ID, then chooses the highest result. If the values tie, locally supplied information breaks the tie. The mechanism works only when the leaves compare the same candidates with the same inputs and algorithm. A leaf that sees a different eligible set can choose a different spine while faithfully implementing its own local rule.

Three-tier networks make the problem sharper. A middle-tier router can advertise a four-byte “Color” in a PIM Hello, representing a grouping such as the upper-tier spine to which it connects. Leaves then hash S, G and that Color. The draft limits this Color election to upstream neighbors that advertise it. That one sentence carries a migration problem: introduce the option on some adjacencies and the eligible set changes. The old paths do not simply become the new paths with a decorative label. Which routers speak Color, and when they begin speaking it, can change where the Join goes.

The draft is unusually candid about running code. Its non-normative Arista appendix describes two private-use Hello options already used by EOS: type 65001 identifies the proprietary option family with a magic value, and type 65002 carries Color. The proposed public option code is still TBD. A standards-compliant router is advised not to emit or parse the proprietary pair by default, while an interface-level switch may enable interoperability. That is a real operational boundary. If an operator turns compatibility on at one link and leaves it off at the next, two leaves may no longer be comparing the same upstream set.

Then comes the byte-order trap. The proposed standard hash represents Color in network byte order. The Arista-compatible hash represents the same 32-bit field little-endian. The draft says that when any candidate in the set advertises the proprietary Color, the comparison must use the Arista-compatible hash. This is a proposed bridge between old and new behavior, not evidence that every device in a rack has crossed it. Byte order is invisible on a topology slide and decisive inside a hash input. A control-plane packet can look syntactically plausible while the leaves produce different winners.

The Cisco appendix introduces another installed rule. It says Cisco independently used the Rendezvous Point hash from RFC 7761 for router-ID-based selection, and uses the interface ID announced through RFC 6395 when values tie. The draft's main router-ID method uses Jenkins' one-at-a-time hash and can use local information for the second pass. Those descriptions do not supply a fleet-wide equality guarantee. The missing evidence is narrow: for a named (S,G), list the neighbors every leaf considered, the Hello options it received, the exact hash inputs and the chosen upstream before and after a topology change. That record would show whether different conventions actually split the tree in that deployment.

RFC 6754 offers a different answer to equal-cost selection: an upstream router may redirect a downstream Join after the initial choice. Revision 01 compares that correction path with a common decision made before traffic moves. The choice is operational, not philosophical. Redirect can move a live Join and disrupt a flow during correction. A shared hash avoids that move only if peers share the rule and candidate view in the first place. Calling either one “automatic” would conceal who tested the transition.

The draft proposes no measured bandwidth saving and reports no outage caused by a mixed vendor fleet. Its value lies in exposing the exact place where a promised saving can evaporate. A standards editor can define a Color option and a byte-order rule. An equipment supplier can implement one. The network operator must inventory both versions, decide where compatibility mode is allowed, and observe which upstream actually receives each Join. That is the moment a protocol design becomes an accountable operating choice.

PIM draft revision 01 · RFC 7761 · RFC 6395 · RFC 6754