Summary

  • RFC 5384 lets a PIM Join attach TLV attributes to a particular multicast tree, but its Hello option advertises only willingness to receive the type-1 encoding. It does not prove that a neighbour understands every attribute type.
  • When different downstream adjacencies supply conflicting values of the same type, the generic rule selects the attribute from the numerically smallest adjacency address, unless that attribute's own specification overrides the rule. The result is deterministic control state, not validated policy authority or packet-delivery evidence.

The election nobody should call approval

Imagine two edge routers serving the same multicast tree. One attaches an attribute that asks the upstream network to construct the tree one way; the other attaches the same attribute type with a different value. Both Join messages are syntactically valid. Both arrive from known adjacencies. Neither request can simply coexist as the single value carried farther upstream.

RFC 5384 has to make the state machine deterministic. Its generic procedure orders the suppliers, not the meanings. The attribute from the PIM adjacency with the numerically smallest IP address wins. For IPv6, the link-local address is used. If two neighbours present the same address, interface index breaks the tie. A later attribute specification may define a type-specific procedure, but absent that override the address order settles the conflict.

That is a valuable protocol property. Every conforming router can reach the same answer from the same inputs. Yet it is a dangerous management metaphor. The smallest address has not demonstrated a better business case, a newer change ticket, stronger ownership, a more reliable path or permission to overrule the other edge. It won because an arbitrary but stable ordering was necessary.

Operations often turn determinism into legitimacy after the fact. A dashboard shows one active value. The tree appears stable. The absence of oscillation is read as agreement. RFC 5384 exposes why that inference fails: consensus on the algorithm can conceal disagreement in the requests.

The envelope and the meaning are different capabilities

A PIM Join identifies a distribution tree by a source address, possibly a wildcard, in the context of a group address. RFC 5384 assigns Encoded-Source Address type 1 so that one or more Type-Length-Value Join Attributes can travel with that tree. Type 1 must contain at least one attribute; a Join with none uses ordinary type 0.

Before sending type 1 on an interface, a router looks for the Join Attribute option in PIM Hellos. Every neighbour on that interface must have advertised willingness to receive the encoding. Even a neighbour that is not the upstream next hop needs to parse the packet for Join suppression or overriding.

The option has a deliberately narrow meaning. RFC 5384 says that a router advertising it does not necessarily understand every possible attribute type. There is no Hello option for each type. The receipt therefore proves envelope capability: the neighbour says it can encounter the type-1 address encoding. It does not prove semantic capability for the TLV inside.

Later specifications make the distinction visible. RFC 6420 defines the MT-ID attribute and adds its own MT-ID Hello option, validation rules and conflict procedures. RFC 6807 defines a Population Count attribute with a separate capability option. RFC 7887 adds a hierarchical way to encode shared values across a message, group or source without changing their meanings. The generic container was intentionally not the complete policy contract.

For an acceptance record, “Join Attributes supported” is therefore too coarse. Record support for the type-1 envelope, support for each actual attribute type, relevant software version and interface scope separately. A parser capability should never be allowed to stand in for a shared interpretation.

Unknown does not always mean stopped

RFC 5384 gives every attribute an F-bit. When a router does not understand the type, F=1 makes the attribute transitive: the router must forward it. F=0 makes it non-transitive: the router must discard it. The rest of the attribute sequence continues. If discarding unknown non-transitive values leaves none, the router forwards a type-0 Join.

That behaviour is not semantic validation. A transitive attribute can cross a hop that cannot explain it. Its continued presence says that the forwarding rule was obeyed, not that every custodian endorsed the value. Unlike BGP's separate Partial-bit story, the specific point here is what that opacity means inside the PIM tree-building request and how RFC 5384 then resolves competing adjacency-scoped sets.

An unaware router may still face two conflicting transitive sets of the same type. If the sets are not byte-for-byte identical with the same number of instances, the generic conflict procedure applies. The router can choose one supplier without understanding what it chose. This is algorithmically coherent and evidentially limited.

The right audit vocabulary is precise: received, parsed envelope, understood type, forwarded unknown value, discarded unknown value, selected competing set. Words such as approved, validated or honoured require additional evidence.

State belongs to an adjacency, not to an eternal truth

Attribute processing can affect tree construction, other instances of the same type and what is sent farther upstream. When it does, RFC 5384 requires state tying the received attribute to the adjacency or adjacencies that supplied it.

That association matters during failure. The router may remember non-selected alternatives. If the adjacency that supplied the winning attribute is pruned or expires, the next one in the numerical order can become effective immediately rather than waiting for another periodic update. Fast convergence is the benefit.

The control meaning has still changed. Yesterday's winning value may disappear because its adjacency expired; today's value may have been present all along but suppressed by the generic order. If monitoring records only the final active value, an incident reviewer cannot tell whether policy changed, a neighbour failed or an old conflict simply exposed its runner-up.

Preserve the full candidate set, supplier address, incoming interface, selection rule, winning value, retained alternatives and transition reason. A failover that keeps packets moving can still change which request governs the tree.

A new Join replaces the whole set

RFC 5384 does not advertise incremental edits to an adjacency's attribute set. When a new Join for the tree carries a set that differs from the prior Join, the new set becomes the entire set. Missing attributes are withdrawn. An empty set is represented by type 0. A Prune also withdraws the attributes previously supplied by that downstream neighbour.

This is clean protocol state, but it punishes diff-only observability. Suppose a router previously supplied attributes A and B, then sends only B. The wire does not say “delete A” as a separate operation. Absence in the complete replacement performs the withdrawal. A log that stores only newly observed TLVs may retain a ghost A that the protocol no longer recognizes.

Hierarchical encoding from RFC 7887 makes scope even more important. An attribute may apply message-wide, to a group set or to one source. Compactness does not relax provenance. A wrong broad value can affect many sources just as repeating the wrong value on each source would.

Change control should therefore retain before and after complete sets at every applicable scope. The review question is not merely which bytes appeared. It is which prior meanings ceased to exist because they did not appear.

Security protects the message, not the mandate

RFC 5384 says an attribute is only as secure as the PIM packet that carries it, and that particular attributes may need additional security analysis. RFC 5796 can authenticate link-local PIM messages and support origin and integrity claims. Those are essential controls, but they answer a different question.

An authenticated neighbour can send a request that conflicts with another authenticated neighbour. Cryptography can show which adjacency supplied the bytes and whether they changed in transit. It cannot infer which department owns the multicast service, which maintenance window is current or whether the smaller address should have authority over the larger one.

This is the core governance boundary. Identity supports accountability; it does not manufacture authorization. Authorization needs an external policy that maps principals, group/source scopes, attribute types and permitted values to explicit decision rights. Where a type-specific specification says local configuration takes precedence, as RFC 6420 does for MT-ID, the configuration and its approval become part of the proof chain.

The tree is still not the outcome

Even a correctly selected, understood and authenticated attribute remains control-plane evidence. It may influence an upstream neighbour, an RPF topology or another construction choice. It does not by itself prove that the required multicast state was installed, that packets used the intended links, that replication avoided duplicates, that receivers were authorized or that applications received useful data.

The operational chain should remain explicit: configured intent; advertised capability; exact received Join; attribute interpretation; conflict selection; new upstream Join; installed multicast state; data-plane counters and path observation; receiver and application result. Each stage can fail after the previous one succeeds.

Existing BTW coverage of RFC 9798 owns Receiver RLOC mapping, ETR joining, ITR replication and receiver-delivery evidence. Existing RFC 9739 coverage owns the absence of Hello, DR election, Assert and failure withdrawal on PIM Light Interfaces. This Article does not reopen either subject. Its narrower contribution is the authority limit inside RFC 5384's generic attribute machinery.

An acceptance test that preserves the losing request

Build a lab tree with two downstream adjacencies and one upstream router. Verify type-1 parsing capability on every neighbour of the interface. Then exercise an attribute type that has a known specification and a controlled conflict. Capture the exact Join bytes, tree key, adjacency address, interface and time.

Send different same-type values from the two downstream routers. Confirm which procedure applies: the attribute-specific one or RFC 5384's generic smallest-address rule. Swap address order without changing the values and show that the winner follows the rule. Where safe, test equal addresses on distinct interfaces to expose the interface-index tie-break.

Next, expire or prune the winning adjacency. Verify whether the remembered alternative becomes active and whether the upstream Join changes. Replace a two-attribute set with a one-attribute set and confirm that the omitted value is withdrawn. Insert an unknown transitive attribute and an unknown non-transitive one; prove forwarding and discard separately without calling either interpretation.

Finally compare control-plane state with packet traces and receiver canaries. The report should be able to say “router selected value X under rule Y” without implying “value X was authorized” or “the service succeeded.” That linguistic discipline is part of the conformance test.

Sources