Summary

  • RFC 9625 introduces a Supplementary Broadcast Domain so multicast interest learned on one ordinary BD can reach ingress PEs that share the Tenant Domain but not that BD.
  • A PE may merge IGMP/MLD state from several BDs into SBD-SMET routes; an unsnooped attachment circuit or an older PE can be treated as interested in every flow, giving one local signal a deliberately broad control-plane effect.
  • Safe operations need separate receipts for report authenticity, local policy, BD-to-SBD mapping, merged intent, route import, gateway election, OIF eligibility, transmission, duplicate suppression, receiver arrival and resource release.

The report entered through one port and left as domain-wide state

A host sent a Join on one attachment circuit. The access PE learned an interested receiver in one ordinary broadcast domain. Moments later, remote PEs that had no attachment to that BD held state for the flow. Nothing in this sequence was necessarily a leak. It is the reach RFC 9625 gives the Supplementary Broadcast Domain.

That design solves a real problem. An ingress PE in another subnet cannot optimize inter-subnet multicast if receiver interest remains trapped inside the receiver's local BD. OISM therefore gives the Tenant Domain a shared control surface. A route can say that some receiver behind some participating PE needs the flow even when source and receiver PEs do not share an ordinary BD.

The operational mistake begins when “received a Join” becomes “the tenant authorized this scope.” The first is a protocol observation. The second is a policy judgment. Between them sit access identity, group policy, rate limits, tenant boundaries, merge rules and an effective epoch. RFC 9625 transports interest; it does not appoint the host as governor of every PE's multicast resources.

The SBD is connective tissue, not an attachment network

Each OISM PE in a Tenant Domain is provisioned with the same SBD. The SBD has an SBD-RT imported across the domain, yet it has no attachment circuits. It is not another customer LAN. It is a control and forwarding context through which PEs can represent traffic whose ordinary source or receiver BD is not locally present.

That absence of ACs matters. A packet or route associated with the SBD is already an abstraction. The receiving PE may use the SBD as the apparent source BD because it does not attach to the actual source BD. The abstraction preserves the ability to route across subnets; it also removes local detail from the receiving device's immediate view.

An audit must therefore retain both identities. Record the ordinary BD in which the host or source actually existed and the SBD under which the remote PE processed the state or frame. A dashboard that keeps only “SBD active” cannot later show which local report created the shared state, which tenant boundary it crossed or whether that mapping was consistent at every PE.

Route Targets classify scope but do not authenticate intent

RFC 9625 gives precise rules for associating IMET, SMET, S-PMSI and Leaf routes with an ordinary BD or the SBD. Route Targets and, in some service models, the NLRI Tag ID determine the association. Conflicting ordinary-BD RTs, multiple SBD-RTs or a cross-tenant mixture are malformed and must be treated as withdrawn under RFC 7606.

This is valuable containment. It prevents several inconsistent encodings from being admitted as normal state. Intermediate BGP systems generally cannot detect those EVPN-specific errors; the receiving PE performs the semantic check. A clean result proves that the route satisfied the receiver's classification rules at that moment.

It does not prove that the RT was assigned by an authorized workflow, that every PE carried the same configuration or that the originating report deserved tenant-wide effect. Syntax, semantic classification and authority are separate receipts. Preserve the raw route, origin, peer, RT set, Tag ID, local mapping table and accept-or-withdraw decision rather than keeping only the resulting BD name.

Merging interest changes the meaning of the evidence

To determine which SBD-SMET routes it needs, a PE merges IGMP/MLD interest across the ordinary BDs of the Tenant Domain. If one BD needs (*,G) and another needs (S,G), a broader SBD-SMET route may attract all necessary traffic. The compression is deliberate. It reduces control state and lets ingress PEs reach all interested receivers.

After the merge, however, the advertised route no longer answers every provenance question. It may not reveal which BD first asked, which receivers remain, whether one narrow source request was subsumed by a wildcard or which withdrawal should remove the last reason for the aggregate state. A correct aggregate is not a complete ledger of its causes.

Keep a derivation record: the contributing ACs and BDs, each membership epoch, Include or Exclude mode, the merge rule, the advertised key and the reference count or equivalent withdrawal condition. Without that record, the network can prove that it installed a valid wildcard while being unable to explain whose current intent still justifies it.

“Interested in every flow” is a compatibility rule with a cost

RFC 9625 deliberately fails open in two compatibility cases. If IGMP/MLD snooping is not run on an AC, that AC is considered interested in all flows. If a remote PE does not support the RFC 9251 procedures signalled by its IMET route, it is assumed to be interested in all flows. These rules preserve service for equipment that cannot express selective membership.

They also change the evidentiary meaning of an OIF entry. The entry may mean “a receiver explicitly requested this flow,” or it may mean “the network lacks the machinery to prove that no receiver needs it.” Both can produce forwarding state, but they deserve different capacity forecasts, alarms and expiry policies.

Record why interest exists. Explicit report, static provisioning, snooping-disabled default and legacy-peer default should not collapse into one boolean. Leaders who price selective multicast from a receiver count will underestimate load if compatibility defaults are invisible.

One BD can consume resources throughout the tenant

RFC 9625's security section names the changed blast radius. A client with access to one BD can cause SMET routes to be advertised and imported by PEs across the Tenant Domain. Malicious or merely uncontrolled IGMP/MLD reports can therefore affect resources beyond the ingress PE and beyond the original BD. Implementations are expected to provide filtering or control of client reports.

This is not a reason to disable the mechanism. It is a reason to move admission before amplification. Validate access identity, group and source policy, report rate, maximum state, wildcard privilege and tenant budget before a local report becomes an SBD-SMET advertisement. Apply limits at the ingress and observe the aggregate at every importing PE.

The receipt chain should show both admission and cost: which report passed which policy, which route it created, how many remote states appeared, how much memory or processing changed, when the reason expired and whether all remote state withdrew. A 200 response from a controller or a valid BGP route is not evidence that the distributed resource debt has cleared.

Gateway election chooses a worker, not a legitimate principal

Mixed OISM and non-OISM estates need IP Multicast Gateways. Eligible IPMGs advertise capability, the candidate set is narrowed by BD reachability, and a Designated Forwarder algorithm chooses one IPMG-DF for a BD. Similar gateway roles connect the Tenant Domain to MVPN or PIM domains.

Deterministic election prevents duplicate active gateways under the specified state. It does not authenticate the human or automation that enabled the role. RFC 9625 warns that a party controlling a gateway may influence the election and alter multicast forwarding. A valid winner is therefore an availability fact, not a complete authority verdict.

Preserve candidate advertisements, capability flags, route inputs, algorithm, preference, winner, management authorization and effective epoch. Alert when the elected winner diverges from the authorized gateway set, not only when two devices claim the role. Capability and permission must remain separate.

The OIF list is recomputed evidence, not a delivery receipt

At Layer 2, the PE selects (S,G) state or falls back to (*,G), then applies its OIF list according to how the frame arrived and which BD appears to be its source. The list can contain local ACs, remote tunnels and an IRB interface. It changes as local reports and remote routes change. There is no Layer 2 RPF check in this procedure.

An OIF entry is still filtered by eligibility. With ESI labels, the PE must be DF and must not return the frame to its origin segment. With local bias, the remote ingress identity decides whether a multihomed segment has already been served. Traffic from the Tenant Domain must not be sent down the SBD IRB interface, or it can be distributed again.

The correct operational question is not “was the port in the list?” It is “which state and apparent source BD were selected for this frame, which eligibility inputs were current, which elements survived suppression and which transmissions completed?” Snapshotting the list without the per-frame decision can mislabel correct suppression as loss or mistaken suppression as success.

Duplicate prevention has explicit limits

OISM preserves bridged behavior within a subnet while routing between subnets, so duplicate prevention is part of correctness. DF rules, ESI labels, local bias, IPMG behavior and the prohibition on feeding internal traffic back through the SBD IRB interface all prevent copies from circulating or returning to a served segment.

The document also states a hard limitation: if receivers for (*,G) exist in a Tenant Domain, there must not be anycast sources for G inside that domain. OISM would distribute both apparently identical (S,G) flows and receivers could get duplicates. The architecture cannot infer that two sources sharing an address are one logical event.

This is a useful boundary for automation. Address equality is not event identity. If a deployment needs anycast sources, the precondition must be evaluated and enforced before enabling the incompatible receiver state. Receiver-side duplicate observation belongs in the evidence chain because a clean control plane cannot prove that an unsupported topology was absent.

Build the receipt ladder from local report to receiver outcome

Begin with the host report: exact bytes or normalized fields, ingress identity, port, BD, EVI, Ethernet segment, tenant, policy result and timestamp. Record the membership-state transition and the ordinary-BD state it changed. Then preserve the merge into SBD state, including every contributor and the rule that widened or compressed it.

Next capture the route layer: SBD-RT, ordinary BD-RT, Tag ID, IMET capability indications, SMET flags, origin, peer, import decision and any treat-as-withdraw event. For gateways, keep capability and election receipts. For each data frame or correlated sample, keep apparent source BD, selected state, OIF list, eligibility inputs, suppressions, tunnel sends and AC transmissions.

Finally, distinguish receiver arrival, duplicate count, application consumption and service outcome. On withdrawal, prove that the last local reason disappeared, the aggregate route changed and remote state drained. RFC 9625 makes optimized reach possible; the receipt ladder shows whether that reach was authorized, bounded and effective.

Sources