Summary

  • RFC 10018 connects MVPN and EVPN auto-discovery to SR point-to-multipoint policy: imported routes change the intended Leaf set, while a controller separately computes and instantiates a P2MP tree instance.
  • A Leaf record proves neither installed replication state nor customer delivery. Shared-tree service context, split-horizon handling, branch programming, receiver observations and withdrawal cleanup remain distinct receipts.
  • Hooman Bidgoli is one of five named RFC authors. His documented contribution provides a useful standards boundary; it does not establish sole invention, deployment control or a production service result.

Five customer edges appear in an ingress router's current Leaf set. The count is stable. The relevant auto-discovery routes are present, and the controller accepted a policy update. A dashboard can therefore show a neat fan of five branches.

At one edge, however, the replication segment still belongs to the preceding policy generation. At another, the shared tree arrives with the wrong service context. A multihomed site receives two copies because split-horizon state was not aligned. The fifth edge advertised membership but its receiver process is no longer consuming the stream.

The Leaf set was not false. It answered a narrower question: which egress nodes the service control plane currently intended to include. Trouble came from treating that answer as proof of downstream execution once the intention left BGP.

RFC 10018, published on the IETF Standards Track in August 2026, specifies extensions for Multicast VPN and Ethernet VPN over Segment Routing point-to-multipoint trees and ingress replication. Rishabh Parekh and Daniel Voyer are the editors; Clarence Filsfils, Hooman Bidgoli and Zhaohui Zhang are the other named authors. The document connects several mature mechanisms without pretending they collapse into a single state.

Auto-discovery produces membership input

An SR P2MP Policy has a Root, a set of Leaf nodes and one or more candidate paths. A candidate path can carry constraints or an optimization objective and can have zero or more P2MP tree instances. Those nouns already describe separate things: the desired membership, the policy option and an instantiated tree are not synonyms.

For MVPN or EVPN, the ingress Provider Edge participates in BGP auto-discovery. When it imports the relevant route from an egress PE, it discovers that PE as a Leaf for the P-tunnel. It adds the egress PE to the corresponding SR P2MP Policy Leaf set. A withdrawal removes it. An egress PE, for its part, associates the route with the relevant service context and informs its policy module that it is joining as a Leaf or Bud.

This is valuable control-plane work. It means an operator need not maintain a completely separate hand-written receiver list. It creates inspectable route events, origins and withdrawals. It also defines a useful failure boundary. A missing auto-discovery route can explain why a node never entered the intended tree.

But the route does not carry a packet-delivery receipt. It does not say that the candidate path has a viable tree instance, that every intermediate node has matching replication state, or that the receiving application accepted the stream. Membership is an instruction to the next system.

The controller has a different job

RFC 10018 describes the handoff clearly. Given a Leaf set and a candidate path with its constraints and objective, a controller computes and instantiates a P2MP tree instance. It does so by stitching replication segments at the Root, intermediate replication nodes and Leaves. BGP, PCEP, NETCONF or another mechanism may install those segments; the choice is outside the document's scope.

That scope boundary is operationally decisive. An ingress router can truthfully report that it signalled an updated Leaf set while a controller is delayed, rejects an infeasible constraint or computes a new generation that only some nodes install. A successful API response from the controller can still precede southbound programming. A completed programming transaction can still leave one device on an older version.

The receipt therefore needs generation identity. Record the candidate-path identifier, Leaf-set hash, constraint set, optimization objective, controller request, computed PTI identity and per-node acknowledgement. A bare word such as “success” is insufficient if it cannot join those records to one generation.

RFC 9960 supplies the policy structure. RFC 9524 supplies the replication roles: Root, Bud, Leaf and intermediate replication node. RFC 9961 supplies MPLS SR P2MP ping and traceroute. Their separation reinforces the point. Policy, installed replication and observation are related surfaces, not interchangeable labels.

A Tree-SID identifies a tree, not every service fact

Once instantiated, the P2MP tree instance has a Tree-SID. The Root places the payload into that tree. Provider nodes replicate it along the installed branches; Leaves remove the Tree-SID and deliver the payload into an MVPN or EVPN context.

If one tree is dedicated to one service, the tree identifier may be enough to recover the service context. Shared trees are different. Several MVPNs or Ethernet VPN instances can use one P-tunnel, so an additional label, SRv6 service SID or argument distinguishes the customer's context. A packet can traverse the intended tree and still enter the wrong service table if that context is incorrect.

EVPN multihoming adds another receipt. Split-horizon filtering exists to prevent a broadcast, unknown-unicast or multicast packet from returning through the same Ethernet segment and appearing as a duplicate. Correct Leaf membership does not prove correct Ethernet Segment Identifier handling. A receiver that gets two copies is not made whole by a perfect topology diagram.

This is why the operational join must preserve both tree identity and service identity. Record the Tree-SID, service label or SID, Ethernet segment context, split-horizon value, ingress PE and egress lookup. Do not infer those fields from the Leaf count.

Ingress replication is not the same execution path

RFC 10018 also covers ingress replication. In that mode, the ingress PE makes separate copies and sends them toward egress PEs over SR-MPLS or SRv6 paths. The SR P2MP Policy module and controller do not participate in the same way.

An estate can therefore present two services with similar customer outcomes but different control and failure surfaces. A P2MP tree depends on the common tree generation and replication nodes. Ingress replication depends more heavily on source copy count and per-egress unicast reachability. Treating both as one “multicast enabled” flag removes the distinction that incident response needs.

The implementation record should name the delivery mode for each service and generation. During migration, it should also say whether some receivers use the tree and others ingress replication, who owns the cutover, and what observation closes the old state. Otherwise, a traffic counter can be counted twice or a stale branch can survive because each team assumes the other mechanism owns it.

The receiver closes the evidence chain

At the Root, count accepted customer packets and packets inserted into the exact Tree-SID or ingress-replication set. At each replication node, preserve input, replicated-output and drop counters tied to the same policy generation. At the Leaf, record decapsulation and service-context lookup. At the receiver boundary, measure expected sequence, loss, duplication, ordering, latency and useful consumption.

These measurements should not be forced into one green state. A Root counter proves admission at the source. Branch counters can localize loss. A Leaf decapsulation count shows arrival at an egress router. Only the final receiver observation answers whether the intended endpoint obtained the stream under the service's stated conditions.

The negative cases matter as much as the happy path. Test a Leaf withdrawal while traffic is active. Measure how long the ingress membership, controller generation, node programming and packet replication take to converge. Confirm that stale state is removed and that a later rejoin receives a new, traceable generation. Exercise a multihomed failure and look for duplicates. Force one intermediate programming failure and verify that the service does not continue to advertise completeness.

Hooman Bidgoli's name marks a contribution, not ownership

The IETF Datatracker record captured on 1 September 2026 lists seven RFCs for Hooman Bidgoli, including RFC 9524 on SR replication, RFC 9960 on SR P2MP Policy, RFC 9961 on P2MP Policy Ping and RFC 10018. RFC 10018 records his Nokia affiliation in Ottawa. Nokia's official SReXperts profile describes source-dated work across IP/MPLS, multicast and router security.

That record makes his relevance specific. The standards sequence spans replication structure, policy, OAM and service binding. It does not make him the sole inventor of any of them, the owner of IETF consensus or the operator of a named network. RFC 10018 has five named authors and inherits substantial work from earlier MVPN, EVPN and Segment Routing specifications.

Person-centred analysis is useful when it makes collective work easier to inspect, not when it manufactures a hero. Bidgoli's documented role points to the boundary: a membership update can drive a tree, while separate systems still decide whether the tree exists and whether a service arrived.

Build the multicast receipt as a join

For each service change, preserve the service and tenant identity, delivery mode, Root, imported auto-discovery routes, Leaf/Bud membership, candidate path, constraints and objective. Add the controller request, computed PTI generation and each node's replication-segment acknowledgement. Then join the Tree-SID to its service label or SID, Ethernet-segment state and split-horizon rule.

Close the record with packets admitted, copies produced, branch drops, Leaf decapsulation, receiver results, OAM probes and alarm timing. On withdrawal, preserve who initiated it, when each layer removed state, whether packets continued and which receipt proved cleanup.

This chain does not make multicast simple. It makes disagreement localizable. The Leaf set can remain what it is: a precise record of intended membership. Delivery becomes a separate claim, supported only after the rest of the chain agrees.

Sources