Summary

  • An MSDP Source-Active message says that an originating rendezvous point learned of a source and group. Peer-RPF checks whether the announcement arrived from the locally selected direction toward that RP; it does not verify the source, authorize it, or observe receiver delivery.
  • Caches, timers, mesh groups, Anycast-RP replication, session authentication and filters make the control plane usable and bounded. Each leaves a different gap between accepted control state and present data-plane truth.

The green counter answered the wrong question

Suppose an operations console shows a Source-Active message accepted from the expected peer. The peer-RPF failure counter has not moved. The TCP session is established, the SA cache contains (S,G), and the entry age is comfortably inside policy. Every displayed fact may be accurate. The tempting conclusion—“the multicast source is alive”—still does not follow.

RFC 3618 was published in October 2003 as an Experimental protocol, not an Internet Standard. It reflects implemented behavior for connecting IPv4 PIM Sparse-Mode domains. When a rendezvous point first learns of a sender, for example from a PIM Register, it creates a Source-Active message containing the source address, group address and RP address. Peers flood that control information. A domain with interested receivers may then initiate an (S,G) join toward the source.

The order matters. The SA is a reason to ask the data plane to build a path; it is not the path, the packets, or the application result. The name Source-Active describes the assertion at the point of origin. It is not an end-to-end health verdict.

That distinction is easy to lose because the protocol provides crisp counters and deterministic acceptance rules. A machine can prove that it followed those rules exactly. It cannot infer facts the rules never observed.

Peer-RPF chooses an admissible messenger

The MSDP peer-RPF check is explicitly about forwarding SA messages. It compares the RP address carried in the SA with the peer from which the message arrived. The multicast routing information base supplies a route toward the originating RP, and deterministic rules select an eligible peer. An SA from that peer is accepted; the same SA from a different peer is discarded.

This is valuable loop control. It prevents a flooded assertion from circulating merely because multiple peers can repeat it. RFC 4611 shows how BGP path information, IGP reachability and peering addresses affect that decision. A mismatch can cause a true source announcement to fail. Alignment can cause the announcement to pass.

Neither result settles the source question. A peer-RPF failure is evidence that this copy arrived through a path the local rules did not accept. It is not proof that the advertised source is false. A pass is evidence that the message came through the selected control direction. It is not authentication of the source address, proof of current traffic, or authorization for the advertised group.

Some deployments make the boundary even clearer. A single peer, a directly connected RP, a mesh group, an IGP-based choice or a configured default peer can change or bypass the BGP-shaped check. RFC 8916's management model describes a default peer that accepts SA messages when ordinary RPF would fail. That may be the correct local design. The exception transfers judgment from an inferred path to explicit configuration; it does not abolish the need for judgment.

An audit receipt therefore needs the rule that selected the peer, the routing snapshot used, any default-peer or static exception, and the identity of the configuration owner. “RPF passed” without that context is a status light without an evidence boundary.

A cache remembers acceptance, not continuous life

RFC 3618 requires an MSDP speaker to cache SAs. The cache reduces join latency, paces forwarding and helps diagnosis. Originating RPs periodically advertise active sources on a 60-second schedule, and an implementation should send cached SAs when a connection is established. An SA-State timer is refreshed by later messages; expiry handling is implementation-specific, typically leading toward deletion.

These are sound control-plane mechanics. They also create three different clocks that a dashboard can collapse into one. There is the time the originating RP last observed enough local evidence to advertise. There is the time an intermediate peer last accepted an SA. There is the time the local cache entry was refreshed or replayed. Reconnection can make an old accepted assertion appear newly received without creating a new first-packet observation at the source.

The operational record should keep origin observation, message creation, peer reception and cache update separate. A cache entry with a recent timestamp proves that the cache was maintained. It does not prove continuous traffic across the whole interval. Conversely, an expired entry does not prove that the source ceased; it may record a session, routing, filtering or policy failure.

The word active should therefore be treated as a scoped protocol state. It can trigger action, but it cannot close the case.

Flood-and-join separates publicity from demand

MSDP's procedure was affectionately called flood-and-join. Source information is flooded across the virtual control topology. A receiving RP checks whether its domain has interest in the group. If it does, the RP initiates a join toward the advertised source. PIM then constructs the distribution state that may carry later packets.

This design deliberately avoids globally advertising receiver membership. It also means that source publicity and receiver demand are different evidence objects. An SA can be correct in a domain with no interested receiver. A receiver can be interested while the SA never arrives. Both control states can exist while the data tree fails to install. The tree can install while no useful payload arrives. Packets can arrive while the application rejects stale, unauthorized or malformed content.

Optional encapsulation sharpens the point. An SA may carry an IPv4 packet so a small burst can reach an interested domain before the source tree is complete. That first packet is evidence of some data associated with the advertised addresses. It is not proof that durable forwarding state followed, that later packets used the same path, or that the application accepted the stream.

A defensible service receipt therefore joins several observations: the originating Register or packet, the exact SA, the peer-RPF decision, receiver interest, the PIM join, installed branch state, packet arrival at the intended leaf, and an application-level freshness or content result. Missing stages must remain missing rather than be filled by the label on the SA.

The full mesh is an assumption, not a picture

Mesh groups reduce redundant SA flooding. A member that receives an SA from another member accepts it and forwards it outside the group, but not to other members. This works because the originator is assumed to have sent the SA directly to every member. RFC 3618 therefore requires the group to be fully meshed.

An incomplete mesh turns an optimization into selective ignorance. One RP can possess an SA while another never receives it, and the suppression rule can prevent an intermediate member from repairing the missing edge. A diagram labelled “mesh group” is not evidence that all required sessions are established, use the intended addresses, share the same membership view or carry the same cache state.

Anycast RP adds another authority boundary. RFC 3446 uses MSDP to share active-source state among RPs that answer the same anycast address. Yet the SA must carry an individual RP address rather than the anycast address or peer-RPF can fail. The service identity is shared; the control provenance must remain attributable to one actual speaker.

Redundancy claims should therefore be tested under failure. Withdraw one peer, change the best path, reconnect a session and compare the SA caches. Observe whether receiver joins and packets continue. A stable anycast address is only the front door; it cannot certify that the state behind every door is synchronized.

Authentication protects a relationship, not the meaning of every claim

RFC 3618 requires implementations to support the TCP MD5 Signature Option for control messages, while also requiring interoperability with peers that do not use it. A mismatch should prevent the connection. Later KARP analysis and the current YANG model expose more of the keying, authentication and operational surface.

Authenticated peering can establish that a message came over a connection possessing the configured secret and was not casually altered in transit. That is important. It still does not prove that the remote RP observed the source correctly, that its policy allowed the advertisement, that a source address was not spoofed before the RP, or that the source is entitled to send to the group.

The same separation applies to filters. RFC 3618 recommends source/group access lists, absolute SA-state limits and creation-rate limits against state explosion. A passed filter means the claim fits local policy. A dropped claim may be real traffic sacrificed to containment. Operators must decide which failure mode they prefer, measure both, and preserve the rule that made the choice.

This is where Heng Lu's emphasis on localized authority becomes concrete. The standard supplies the smallest common mechanism. Each domain owns the decision to accept a peer, create state, permit a source/group range and spend forwarding resources. The party bearing the operational loss needs its own evidence and rollback, not a symbolic appeal to a protocol label.

Build the receipt around the irreversible step

The dangerous step is not receiving an SA. It is allocating state and changing traffic behavior on the strength of that message. Before an announcement can trigger wide joins or expensive cache growth, operators should be able to answer who owns the peer, which source/group ranges it may introduce, which RPF exception applies, how much state it may consume, and how stale state is withdrawn.

The second-order risk is correlated control error. A false or stale assertion can be cached, replayed and flooded, prompting many domains to spend state. The third-order risk is observational: if every system reports only “SA accepted,” investigators can reconstruct the propagation of a claim but not the existence of the source or the fate of its data.

RFC 3618's Experimental status does not make the mechanism unreal; RFC 4611 recorded significant deployment and RFC 4624 and RFC 8916 defined management surfaces. Nor does deployment turn the protocol into ground truth. Running code proves that a mechanism exists. It does not expand what its messages mean.

The most accurate interpretation of peer-RPF is also the most useful: this neighbour was the locally admissible messenger for an assertion about an RP. The source, tree, packets and application must testify separately.

Sources