Summary

  • RFC 9960 defines an SR P2MP Policy by a Root and Tree-ID, with a leaf set, candidate paths and P2MP Tree Instances. Those identifiers describe forwarding state; they do not establish a subscriber, customer or institutional right to receive the service.
  • RFC 9961 can target one specific MPLS PTI inside one candidate path and observe data-plane behavior. It explicitly does not test the candidate path as a whole and does not cover SRv6.
  • A multipoint audience receipt should bind the authoritative membership decision to the exact policy, candidate path, PTI, leaf set, controller generation, OAM scope and make-before-break closure. This is Daniel Kade’s editorial proposal, not an IETF requirement.

The clean test can answer the wrong question

A point-to-multipoint service has an appealing operational shape. One Root injects traffic. Replication occurs only where paths diverge. Leaves receive the result. Compared with sending an independent copy from the ingress to every destination, the tree can avoid repeating the same traffic across common links.

RFC 9960 gives Segment Routing a common architecture for that shape. An SR P2MP Policy identifies the Root and the Leaf nodes. Candidate paths express constraints and optimization objectives. A controller computes one or more P2MP Tree Instances, then instantiates the Replication segments that make packets branch through the domain.

The vocabulary is precise because ambiguity in a replication system is expensive. The policy is identified by <Root, Tree-ID>. A candidate path has an origin tuple. A PTI has an Instance-ID. Replication state at a particular node can therefore be identified by Root, Tree-ID, Instance-ID and Node-ID.

That precision creates a tempting inference. If an operator can name the tree, see its intended leaves and verify packet paths, the distribution decision can appear complete.

It is not complete. A Leaf node is a transport endpoint in this architecture. The RFC does not assert that the node represents a paying subscriber, a current licence, a valid emergency-response group, a permitted tenant or any other local relationship. Those meanings belong to the multipoint service and the institutions that operate it. Forwarding state can faithfully execute an obsolete or unauthorised audience list.

The distinction is not a criticism of the standard. It is the point of a reusable standard. IETF consensus can define how implementations identify and build a tree without appointing the person who may add a receiver to a broadcaster’s service.

One policy can contain several operational truths

The hierarchy inside RFC 9960 matters. An SR P2MP Policy can have more than one candidate path. The Root selects the active candidate path using the tiebreaking rules inherited from the SR Policy architecture in RFC 9256. A candidate path may be unable to produce any PTI if its constraints cannot be satisfied. It may also contain multiple PTIs while the network moves from one topology to another.

Yet only one PTI of a candidate path may be active. RFC 9960 warns that if more than one PTI of the active candidate path is active at the same time, duplicate traffic may be delivered to leaves.

This is not a minor inventory detail. During make-before-break, the controller can create a new tree, activate it after instantiation and remove the old one. The old and new trees may have different intermediate replication state because the topology changed. A dashboard that displays only <Root, Tree-ID> hides the Instance-ID that tells an operator which realization was actually carrying packets.

The same policy can also front more than one multipoint service when a service context distinguishes them at Root and Leaf nodes. The transport tree and service membership are therefore related but non-identical populations. A correct PTI may carry the wrong service context; a correct service membership list may be mapped to an old PTI; two services may share transport while having different audience authority.

The evidence record has to preserve those joins. “Tree 71 was healthy” is too coarse. Healthy for which candidate path, which PTI, which service context, which leaf population and which observation interval?

The controller has power without possessing the mandate

RFC 9960 allows an operator, a network node or a machine to provision the Root, leaf set and candidate paths. A controller may compute the topology, assign Replication-SIDs and instantiate state through PCEP, BGP, NETCONF/YANG or other mechanisms. Static paths may also be installed without adaptive computation.

This makes the controller a consequential policy surface. It decides which constraints become a tree, which PTI is prepared, how SID resources are used and when a transition is attempted. It may retry a failed Replication-segment installation, raise an alert, tear down a partial tree or proceed once the Root is ready.

None of that necessarily gives it authority over service membership. A CRM, entitlement service, broadcast scheduler, tenant directory, emergency roster or human change board may own the receiver decision. The controller often receives a projection of that decision: a set of network addresses that should become leaves.

The projection can drift. A subscriber is removed upstream but not from the provisioning queue. A tenant identifier is reused. A site is renumbered. A machine retries an old request after a timeout. A partial rollout updates the Root while one leaf retains old service context. Every component may report success in its own terms while the overall distribution is wrong.

Heng Lu’s Policy Mirror helps here. The controller reveals who can cause packets to be replicated in practice. It does not prove that the actor had the institutional right to make the audience decision. Running code is evidence of exercised power; it is not a self-authenticating source of legitimacy.

A P2MP ping proves less—and more—than a green lamp

RFC 9961 adds ping and traceroute support for MPLS SR P2MP Policies. The echo request identifies the exact candidate path and PTI being tested. Its Target FEC Stack carries the Root, Tree-ID and Instance-ID, allowing the observation to address a particular realized tree rather than a vague service name.

That is stronger evidence than a generic “multicast up” indicator. It can help locate forwarding failures and validate path integrity for active and backup candidate paths and their PTIs. Response identifiers can limit the scope so the test does not produce needless processing across every possible responder.

The document is equally valuable for what it refuses to claim. It says that the new sub-TLV tests a specific PTI within a candidate path; it is not testing the candidate path itself. Its mechanism applies to MPLS Replication-SIDs and does not cover SRv6. The inherited OAM security considerations still apply.

A successful response is therefore a time-stamped observation about a nominated MPLS forwarding instance. It does not prove that application payload reached a usable service, that the receiving organisation remained entitled, that an SRv6 sibling behaved the same way, that the controller’s input was current or that no duplicate copy escaped during make-before-break.

Those limits do not weaken OAM. They make its evidence usable. The operator can join a narrow technical observation to other records without laundering it into a universal certificate.

Membership must be resolved before it becomes a leaf set

The decisive governance artifact begins upstream of Segment Routing. A service owner needs an authoritative membership source. That source may be a contract system, an internal role registry, a public-safety roster, a tenant control plane or another bounded institution. Its form varies; its decision must have a version, effective time and accountable owner.

That population then has to be resolved into technical receivers. The mapping may be one organisation to several nodes, several services to one node, or a short-lived endpoint for one event. An address alone is dangerous evidence because addresses can be reassigned. The mapping record should retain both the stable local subject and the network identifier used for this deployment.

Only then should a controller-facing leaf set be generated. The generation needs a digest so that the controller state can be compared with the membership decision it was supposed to express. Additions and removals deserve equal visibility. A system that records every successful add but cannot prove deletion from all active and backup PTIs accumulates an audience it no longer understands.

This is especially important where a Leaf is also a Bud. A node can terminate the service and replicate it further. The operator must know which function is intended. Proving that the node responded does not show whether onward branches were authorized or removed.

The multipoint audience receipt

A compact receipt can preserve the whole decision without pretending to be a new protocol object. It should contain:

  1. Service authority: the multipoint service/context identifier, authoritative membership source, source version, effective interval, approver and any exclusions.
  2. Receiver resolution: stable local receiver identifiers, their network Leaf or Bud addresses, mapping version, additions, removals and expiry.
  3. Policy identity: Root, Tree-ID, candidate-path <Protocol-Origin, Originator, Discriminator>, constraints, optimization objective and selected path reason.
  4. Instance identity: old and new Instance-IDs, exact Leaf/Bud set, controller/configuration generation, Replication-SID allocation record and installation results by node.
  5. Observation: OAM protocol, MPLS-only scope where RFC 9961 is used, targeted PTI, responder scope, per-leaf result, time, counters and unresolved branches.
  6. Transition: make-before-break activation order, period of coexistence, duplicate-delivery observation, rollback trigger and proof that the old PTI was removed.
  7. Closure: comparison between authorised population and every surviving active/backup instance, operator sign-off, receipt expiry and a clear statement of what was not proved.

Hashes can bind membership, configuration and observations so later substitution is visible. They cannot prove that the source system had lawful authority or that the measurement was honest. Access controls must also protect potentially sensitive receiver populations. A public transparency record can disclose counts, timestamps, change reasons and exceptions without exposing every address or customer name.

“Audience receipt” is an editorial term used here. RFC 9960 and RFC 9961 do not mandate this record. The IETF should not have to encode every operator’s commercial or institutional membership model before a transport mechanism can interoperate.

Failure states should retain their own identity

RFC 9960 recognizes that a Replication segment may fail to instantiate, for example because a SID conflicts. It recommends reporting the failure, bounding retries and rate-limiting alerts. It also describes building leaf and intermediate state before the Root, so traffic is not injected into a tree whose downstream state is not ready.

An operations platform should preserve those failures against the attempted generation. Reusing the same “desired tree” identifier after retry can make a failed partial installation disappear from the audit trail. The later success then appears to have existed from the beginning.

The same applies to SID assignment. A controller may not know every allocation when reserved blocks and deconfliction are absent. A collision is not evidence of malicious conduct, but it is evidence that the controller’s view was incomplete. The receipt should show the generation that failed, the reason reported, the state removed and the generation that replaced it.

Security boundaries belong in the record as conditions, not ceremonial checkboxes. RFC 9960 warns about packets injected from outside an inadequately protected SR domain and about controller-created replication loops that can cause storms until TTL or Hop Limit reaches zero. A successful leaf test does not prove ingress filtering, controller authorization or absence of loops under every packet path.

Limits

The source set establishes standards architecture and stated risks. It does not establish that a named operator has deployed these RFCs, that any receiver has been included improperly, that any transition produced duplicates or that one controller design is universally appropriate.

An operator may choose static trees, computed trees, MPLS, SRv6 or no P2MP deployment at all. RFC 9961 supplies a specific MPLS OAM mechanism; another environment needs evidence suited to its actual data plane. The receipt proposal remains local and adaptable.

Reality, not advocacy, requires a narrow conclusion. RFC 9960 can make the distribution tree precise. RFC 9961 can make one forwarding observation precise. The remaining job is to prove that the precise tree still expresses a current audience decision—and that every replaced instance has truly stopped expressing the old one.

Sources