Summary

  • A configured PIM Light Interface can accept Join/Prune from a router whose Hello it has never seen. It does not acquire ordinary neighbour discovery, DR election or Assert by doing so.
  • Redundant borders need two distinct arrangements: authority to forward receiver-side signalling, and selection that prevents multiple upstream streams reaching one downstream router.
  • Attribute support, failure-to-OIF removal and TCP PORT active/passive roles must be established elsewhere. RFC 9739 supplies requirements and examples, not evidence of a deployed service’s behaviour.

Analysis

Consider a proposed multicast service joining two PIM domains through a transit core. The receiver-side border sends a Join. The far border has no Hello-established relationship with that sender, but its logical interface is enabled for PIM Light, so it accepts the message and creates multicast state.

Before adding the spare border router, the designer must answer an awkward question: which mechanism will stop the two borders from creating two effective forwarding paths? “PIM handles redundancy” is not a sufficient answer here. Some of the machinery associated with that familiar name has deliberately been removed from this interface.

This is a hypothetical commissioning case, not a reported deployment. Its significance follows from RFC 9739, published on the Standards Track in March 2025. PIM Light offers an interface for environments where full PIM neighborship cannot be supported or is not wanted. It is a sparse-mode design, including Source-Specific Multicast; it is not a lighter version of every PIM variant.

The exception has an interface boundary

Ordinary PIM-SM generally processes Join/Prune from known neighbours. RFC 7761, Section 4.5 says a message from an address whose Hello has not been seen should be discarded. The baseline has a qualified compatibility exception for older point-to-point implementations; that exception is not intended to be enabled by default.

PIM Light makes the departure explicit. On a PLI, an unknown router can introduce multicast state without Hello. The receiver retains multicast routing state rather than a general-purpose neighbour relationship. It cannot discover the other routers or their capabilities through the absent exchange.

The exception is not global. RFC 9739 requires unknown-neighbour Join/Prune to be dropped unless the receiving interface has PLI enabled. An underlying mechanism may enable a logical PLI automatically, as the BIER example illustrates. Automatic creation still needs a defined boundary: which logical interface, which encapsulation and which peers can reach it? In a proposed acceptance test, the same Join bytes should be admitted at the intended PLI and rejected at a non-PLI interface. That is a test proposal, not a result established by the RFC.

Nor does PIM Light mean “only Join/Prune”. Its supported PIM message list includes Register (1), Register Stop (2), Join/Prune (3), Candidate RP Advertisement (8), Packed Null-Register (13.0) and Packed Register-Stop (13.1), plus future types whose destination is a unicast IP address. Other message types must not be processed on a PLI. The IANA registry identifies the codes; a code assignment does not establish support in equipment. A particular BIER use can employ the PLI solely for Join/Prune without narrowing the protocol’s full list.

The state is also not limited to an SSM channel. PIM-SM has shared-tree and source-tree Join/Prune procedures for (*,G), (S,G) and (S,G,rpt). An SSM-focused procurement cannot silently stand in for acceptance of all sparse-mode behaviour.

Choosing the Join forwarder is not choosing the incoming stream

The first redundancy decision arises at the receiver-facing PIM domain. When two border routers are attached there, which one carries the receiver’s Join across the transit boundary?

RFC 9739’s BIER example keeps ordinary PIM adjacency between redundant edge routers so DR election can happen within the PIM domain. Only the DR forwards the incoming Join/Prune through the BIER tunnel. The PLI does not perform that election. Removing Hello across the core is compatible with retaining it where the edge’s signalling authority is decided.

A second decision arises when a downstream border can reach more than one upstream router capable of supplying the stream. In ordinary PIM on a shared medium, Assert responds to duplicate forwarding by electing one transmitter. That role is distinct from being the DR. PIM Light does not process Assert, so it cannot be expected to repair duplication by the ordinary LAN procedure.

RFC 9739 therefore places a mandatory no-duplication obligation on the applications or networks using PLIs. Its BIER illustration selects one upstream candidate after topology-based identification, with lowest or highest IP address offered as possible unique selection rules. Choosing an alternative when that border fails is outside the document’s algorithmic scope.

A deterministic choice can be valuable, but it answers only the selection question. The design still needs to show that the unselected path is ineffective, that restoration does not briefly enable both paths, and that the selected border remains the same for the relevant state. These are proposed operating checks, not claims about measured failover. A working receiver-side DR election does not, by itself, complete this upstream selection arrangement.

Attribute knowledge must have another source

An attributed Join carries more than tree membership. It can alter how the tree is constructed. RFC 5384 distinguishes the ability to parse its type-1 source encoding from knowledge of each individual attribute. Even ordinary Hello advertisement of the envelope does not announce understanding of every possible attribute.

On a PLI that advertisement is absent as well. RFC 9739 says PIM Light should not send attributed Joins unless configuration establishes the neighbours’ capability, or another draft or RFC explicitly permits the attribute in the particular scenario.

This is a narrow exception, not permission to assume that anything accepted by a parser has its intended meaning. If a deployment relies on configured capability, the configuration needs to identify the actual attribute, peers and software scope. A peer replacement can invalidate that premise while the interface continues admitting plain Joins. For an attribute allowed by another specification, acceptance needs the exact specification and scenario rather than a generic “supports PIM extensions” statement.

Failure detection needs a state action

The missing Hello also removes a familiar source of neighbour liveness information. RFC 9739 describes failures that may go undiscovered in the Light domain, leaving upstream traffic running until the outgoing interface expires.

The document does not prescribe universal BFD protection. It gives implementation-dependent alternatives. In its BFD example, a far-end PLI failure at an upstream router that has this PLI in an (S,G) OIF list requires removing that PLI. In the automatically established BIER-interface example, loss of downstream-border reachability can cause the upstream border to prune (S,G) toward the source.

Those examples expose the integration point. A detector must cover the object whose loss invalidates the state, and its result must reach the PIM action. “BFD is up” is not a description of that mapping. A commissioning exercise should distinguish failure of the selected border, failure of the monitored path, and loss of the notification or callback that removes the OIF. The observation of interest is which PLI was removed, for which state and when—not merely whether an alarm appeared.

No fixed withdrawal interval can be inferred for every implementation from this text. Any timing promise needs a named detection method, configuration, expiry behaviour and observed state transition.

Reliable signalling adds a different dependency

PIM Over Reliable Transport, defined in the Experimental RFC 6559, carries Join/Prune with TCP or SCTP on destination port 8471. In ordinary PORT, Hello options announce capabilities and Connection IDs. The TCP opening rules use those addresses, with qualifications for on-demand connections. SCTP can handle call collision.

PIM Light has no Hello from which to obtain this information. RFC 9739 allows the Connection ID—the IPv4 or IPv6 address used to establish the transport connection—to be configured. For TCP PORT, the two ends must be explicitly and correctly assigned active and passive opening roles. This address is not an opaque session token, proof of peer identity or a DR election.

Reliability must not obscure maintenance. RFC 6559 explains why an idle TCP connection may fail to reveal that a peer has disappeared. It provides keep-alive and connection-expiry procedures without mandating one default Holdtime. Establishing or re-establishing PORT requires a full set of relevant Join/Prune state; loss of the connection starts OIF-state expiry timers unless fresh state arrives. Connection loss does not automatically authorize fallback to native datagram Join/Prune.

Thus TCP establishment, PORT state resynchronisation and PLI failure removal are related but distinct behaviours. A design claiming both should test both. Neither a transport acknowledgement nor a restarted connection specifies how another redundant border will be selected.

A bounded standard, not an observed service

The security boundary is similarly specific. RFC 9739 recommends route policy for desired (S,G) pairs and requires discarding other pairs. PLI enablement and this policy limit state admission; they do not authenticate the sender. The RFC points to RFC 5796 IPsec authentication mechanisms. RFC 4607 also warns that source selection in SSM is not strong sender authentication. Those protections need their own deployment evidence, but they are not a substitute for the missing DR, Assert or failure integration.

RFC 8279 explains the BIER motivation: intermediate core nodes need not retain per-flow multicast state or build conventional distribution trees. That does not remove PIM state at the borders. PIM Light makes it possible to signal across this architectural seam without recreating a full neighbour relationship in the core.

The separate BIER-PIM signalling document is listed in the official status captured on 13 September 2026 as expired revision 13, dated 3 March 2025. RFC 9739’s illustrative reference must not be represented as a separately completed standard or proof of current deployment.

The source set contains no production incident, adoption survey or measured cost reduction. Its substantive result is a division of work: removing one exchange permits a useful boundary, while the edge, architecture and implementation must still supply the decisions it no longer mediates.

Sources

The featured image is an AI-created editorial metaphor, not a verified topology or deployment record.