Summary

  • RFC 9524 makes a Replication-SID invoke local branch state at one SR node. The branch list may be nonempty at a root or transit node, empty at a leaf, or combined with local delivery at a bud.
  • Several locally valid Replication segments can compose into a wrong tree. Incorrect provisioning can create a replication loop and packet storm until MPLS TTL or IPv6 Hop Limit expires.
  • A credible “tree active” claim needs three separate receipts: a versioned and cycle-checked graph, installed-state readback from every participating node, and observed delivery to the intended leaves.

The green state that multiplied traffic

Imagine a controller has installed local state at nodes A, B and C. At A, the Replication-SID sends copies toward B and C. At B, another branch points back toward A. Each local entry exists, each next hop resolves, and each device can honestly report that its own programming succeeded. Yet the composition contains a cycle. One packet can revisit a replication action and generate more packets on every turn.

RFC 9524 names this risk directly. Incorrectly provisioned Replication segments can form a chain loop, particularly when nodes are provisioned without a control plane. Replicated packets can create a storm until the MPLS TTL in SR-MPLS or IPv6 Hop Limit in SRv6 reaches zero. That terminal condition prevents an immortal packet. It does not convert a cyclic graph into a correct tree.

This is the central assurance problem. The protocol gives a precise local forwarding primitive. Operations often promote evidence about that primitive into a global claim—“the multicast tree is installed”—without retaining the joins that would make the claim true.

What the identifier actually names

A Replication segment is a logical construct local to a replication node. It connects that node to a set of downstream nodes. Its identity is the tuple <Replication-ID, Node-ID>, while its Replication-SID is the data-plane handle: an MPLS label or an SRv6 SID. The handle causes the receiving node to consult its local Replication state.

That state is conceptually a list of branches. A branch identifies a downstream node and its Replication-SID, plus the reachability needed to get there. Reachability may be as immediate as an interface and next hop, or it may be a constrained path, a SID list or an SR Policy. The state can be provisioned directly on the node or programmed by a control plane.

Nothing in that definition makes a Replication-SID a portable description of the complete tree. The same numeric value can have meaning only in the context of the owning node. The downstream list can change as reachability and leaf requirements change. An inventory that records only the SID loses the node, state version, role, branch destinations and effective time that give the symbol meaning.

Empty is a role, not automatically an error

The branch list is allowed to be empty. At a leaf, no further replication is required. The leaf's Replication-SID may identify the multipoint service even though its Replication state contains no outgoing branches. RFC 9524 still calls this a Replication segment for consistency.

A bud combines roles: it is both a replication node and a leaf. It can copy traffic downstream and deliver a copy locally. Root and transit nodes normally need branches. The same observation—zero branches—can therefore mean “correct terminal leaf” or “broken root,” depending on intended role.

This defeats a tempting monitoring shortcut. A state-presence check cannot prove useful replication, while a branch-count check cannot judge correctness without the intended topology. Assurance needs a role-aware comparison: expected role, expected branch set, installed branch set and observed action.

How the two data planes execute local state

In SR-MPLS, a node receiving an active Replication-SID pops that label. For each branch in the local state, it makes a packet copy and pushes the downstream Replication-SID plus any labels needed for the path. Leaf and bud delivery depends on local configuration. Each copy is therefore the result of one node executing one local list.

SRv6 expresses the same boundary with End.Replicate. The function part of the local SID selects Replication state. If no state exists, the packet is discarded. The node checks and decrements IPv6 Hop Limit, processes permitted SRH material, and makes a copy for every branch. Each copy receives the downstream Replication-SID as destination and may receive an additional segment list. Service decapsulation or local delivery is a further context, not an automatic consequence of successful replication.

These actions prove something narrow and useful: a particular node found state and executed it. They do not prove that the next node held the matching state, that every intended leaf was reachable, that no branch returned to an ancestor, or that a VPN service associated the packet with the correct customer context.

Stitching changes the unit of truth

A point-to-multipoint tree can be formed by stitching Replication segments at a root, intermediate replication nodes and leaves. RFC 9524 deliberately leaves the stitching procedure to other documents. It requires a control-plane specification to prevent loops or detect and mitigate them in steady state; locally provisioned chains should not form loops.

RFC 9960, published later, defines SR P2MP Policy. A policy has a root, a leaf set and candidate paths. A candidate path can instantiate a P2MP tree instance, and a controller can program its Replication segments. RFC 10018 later describes how MVPN and EVPN procedures use SR P2MP trees or ingress replication. The progression is instructive: local segment, stitched instance, service binding.

Those abstractions should remain separate in evidence. A Replication-SID says where a node will look. Replication state says what that node plans to copy. A tree instance says how several local plans compose. Service intent says which root, leaves and VPN context should be served. Delivery evidence says what copies actually arrived. A green light at an earlier layer cannot silently certify the later ones.

TTL is an expiry mechanism, not a topology auditor

The replication-loop failure exposes the danger of confusing containment with correctness. TTL and Hop Limit eventually stop circulating packets. Their decrement is essential. Yet an operator who says “the loop is safe because TTL will expire” has accepted a burst multiplier whose size depends on branching, initial lifetime and where the cycle sits.

SRv6 also permits an IPv6 Hop Limit Threshold. A replication node can discard a packet below the configured threshold and log the event in a rate-limited way. RFC 9524 discusses the threshold partly because forwarding nodes can otherwise produce a storm of ICMPv6 errors toward the root. The threshold should still allow traffic to reach the furthest legitimate leaf.

The threshold is a guardrail around packet lifetime and error amplification. It does not test whether the graph is acyclic. It does not show that the leaf set is complete. It cannot reveal an unintended but noncyclic branch. A graph check answers structure; Hop Limit bounds execution. They are different controls.

A ping reply is not a map

Operational testing has another hard boundary. RFC 9524 permits ping to a Replication-SID at a leaf or bud. When a probe passes through a transit replication node, the node may copy the Echo Request toward other leaves; those other nodes can discard it because the checksum is wrong for their address. The document also explains why ordinary traceroute through the replicated tree is not available under this behavior: ICMPv6 Time Exceeded is not generated along that replicated path.

A reply therefore confirms reachability to one answering endpoint under the tested state. It does not enumerate every branch, prove the absence of a loop or certify that all intended leaves received a service packet. OAM evidence should be retained as an observation with its target and limits, not transformed into a topology fact.

Three receipts for one operational claim

Before a controller or operator asserts that a tree is active, the evidence should cross three gates.

First is the graph receipt. Preserve the service and policy version, root, intended leaf set, constraints, computed directed graph and cycle-check result. Every edge should resolve to an owning node, downstream Replication-SID and reachability object. The check must cover the exact graph intended for deployment, not a later reconstruction.

Second is the installation receipt. Record the configuration generation, acknowledgements and readback from every affected node: role, local Replication-SID, branch list, local-delivery indicator and effective time. If nodes update at different times, preserve the transition order, because a safe final graph can pass through a transient loop or black hole.

Third is the outcome receipt. Compare ingress packets, generated copies, branch counters, lifetime drops and per-leaf observations. Delivery evidence must name the expected recipients and measurement interval. A flat counter on one leaf can coexist with rising copy counts elsewhere; a single successful endpoint test cannot stand for the set.

Together these receipts support a bounded statement: this policy version produced this graph; these nodes installed matching local state; during this interval the intended leaves exhibited these results. Removing any clause widens the claim beyond the evidence.

Sources

Sources