Summary

  • RFC 9856 gives EVPN two interoperable places to suppress redundant multicast copies: at the source-facing PE in Warm Standby, or at each receiver-facing PE in Hot Standby.
  • A Single Flow Group is a configured and signalled statement that sources belong together. It does not compare payloads, clocks, codec state, sequence continuity, or application readiness.
  • One accepted copy at one receiver proves a local filtering outcome, not source equivalence or end-to-end continuity. Operators need a seven-field redundancy receipt that joins the network decision to receiver evidence and rollback authority.

The reassuring picture is a receiver with no duplicate counter increments. Two geographically separated encoders are sending what the service owner calls the same programme, yet the receiver sees one copy. RFC 9856 makes that outcome possible in an EVPN built on the multicast procedures of RFC 9251 and RFC 9625. It describes how redundant sources are grouped and how one copy is selected. The visible calm, however, is only the end of a longer chain of claims.

The chain begins with equivalence. It passes through a suppression decision, BGP state, label programming and packet forwarding. It ends at receivers that may not all make the same choice or experience the same transition. If those stages are collapsed into the sentence “redundancy worked,” a network state is allowed to stand in for an application result.

A group is a declaration, not a comparison

RFC 9856 calls a source redundant when it transmits a Single Flow Group, or SFG, while another source transmits the same SFG. An SFG can be expressed as (*,G), grouping any source sending to group G, or as (S,G), where S may be a source prefix of any length. The SFG flag in the BGP Multicast Flags Extended Community marks the associated S-PMSI A-D route as carrying this meaning.

That vocabulary solves an interoperability problem. PEs can agree on what is being selected and suppressed. It does not answer the application question that precedes selection: are these packets genuinely interchangeable?

The specification assumes the redundant sources send the same flow and are not bursty. It does not prescribe a comparator for sequence numbers, timestamps, encoder state, generation identity, content freshness, or semantic correctness. A source can therefore be correctly classified and correctly selected while emitting stale, damaged, delayed, or simply different content. The SFG flag proves that a route carries a declared group. It is not a health certificate.

That distinction should change the order of an operator's evidence. The source or application owner should first say what “same” means, over what sample, with what tolerances, and who accepted the result. Network selection evidence can then be attached to that basis. Without it, the fabric may be suppressing a better copy in favour of a worse one with perfect protocol compliance.

Warm Standby concentrates the decision upstream

Warm Standby elects one Single Forwarder among the PEs attached to redundant sources. A non-SF PE discards matching packets received on its local attachment circuits. The SF forwards packets from only one local attachment circuit; if several such circuits deliver the SFG, choosing among them is a local implementation matter.

The election reuses the DF-election machinery of RFC 8584. A preference-based procedure can deliberately favour one PE, and the specification supplies a lowest-PE-IP fallback for an algorithm or capability mismatch. These rules make the control decision deterministic. They do not make it an observation of media quality or source readiness.

Warm Standby advertises an S-PMSI A-D route when the first packet for the configured SFG arrives. When traffic ceases, the route is withdrawn; an inactivity timer is recommended, but no universal timer value is imposed. After a failure and withdrawal, another upstream PE can become the SF. Because the duplicate traffic is suppressed close to the sources, the tenant network carries less redundant traffic. The trade-off stated by the RFC is longer failover than Hot Standby.

This mode produces an appealingly compact story—one upstream selection for the tenant fabric—but important evidence remains local. Which attachment circuit did the SF choose? When did it decide that traffic had ceased? When did other PEs receive the withdrawal? How many packets did receivers miss or see twice during the handover? RFC 9856 defines no universal zero-loss guarantee, switchover ceiling, or receiver acceptance test. Those measurements belong to the deployment.

Hot Standby distributes the decision downstream

Hot Standby sends the redundant copies across the tenant network. Upstream PEs associate every source with an Ethernet Segment, including single-homed sources, and identify packets using source-ESI labels. Each downstream PE accepts the label for its selected primary source ES and discards the others.

The price of faster local choice is additional bandwidth and control-plane work. S-PMSI A-D advertisements are triggered by configuration rather than by the arrival of traffic. A present route can therefore show that a source is configured for the SFG without showing that useful packets are arriving. Multipoint BFD may monitor the P-tunnels that carry the flow, but tunnel liveliness is not encoder health, clock coherence, content freshness, or payload integrity.

Hot Standby also resists a convenient global simplification. The RFC explicitly allows different downstream PEs to select different primary S-ESIs according to local policy. Each attached receiver may get one accepted copy while different parts of the network accept different physical sources. “Active source” is consequently a receiver-side mapping, not necessarily one estate-wide value.

When the last relevant A-D per-EVI or per-ES route for a primary is withdrawn, a downstream PE changes its selection. A mass withdrawal can affect many tenant domains if the source ES is shared. If the last S-PMSI A-D route for an SFG disappears, the downstream PE should remove its S-ESI-label RPF check. Each transition changes the filtering authority. It should be observed, not inferred from a final steady-state counter.

Seven fields for a redundancy receipt

The practical answer is not another protocol extension. It is a compact record that prevents unlike evidence from being compressed into one green status. A useful redundancy receipt contains seven fields:

  1. Equivalence basis: tenant and SFG expression; source inventory; payload, sequence and time comparison method; tolerances; sample; and the responsible application owner.
  2. Suppression authority: warm or hot mode; decision location; election or local-policy identifier; effective configuration version; and the capability set actually present.
  3. Active-source state: the SF PE and chosen attachment circuit for Warm Standby, or the primary S-ESI at every relevant downstream PE for Hot Standby.
  4. BGP signalling: the S-PMSI A-D and A-D per-ES/EVI routes, route targets, SFG flag, DF preference, ESI/DCB labels, and the withdrawal generation observed by each decision point.
  5. Receiver observation: accepted source or label, packet and byte counters, gaps, duplicates, reordering, application freshness, and a privacy-minimised sample of receivers.
  6. Switchover timing: failure trigger, detection source, withdrawal arrival, election or S-ESI change, last old packet, first accepted new packet, and measured loss or duplication interval.
  7. Rollback: prior selection, reversible configuration, restoration authority, abort criteria, expiry or closure reason, and unresolved operational debt.

This receipt is an operating proposal, not an RFC 9856 field or an IETF compliance certificate. Its value is precisely that it respects the boundary of the standard. BGP evidence answers a BGP question. Label state answers a filtering question. Receiver sampling answers an outcome question. Application comparison answers an equivalence question.

Selection is only one part of redundancy

Standards are most useful when they make the shared minimum precise. RFC 9856 supplies common classification, signalling, election and filtering behaviour for a defined EVPN setting. It does not require implementations to support both standby modes, so a mixed estate also needs an explicit capability record. IANA's allocation of the SFG and ESI-DCB bits gives implementations shared vocabulary; registry entries do not prove that a particular device supports, propagates, programs, or correctly operates the feature.

The governance mistake would be to demand that the network protocol prove the application. The opposite mistake would be to treat the limit of the protocol as a reason not to demand proof at all. A redundancy receipt holds the middle ground: keep the interoperable claim narrow, then join it to locally accountable evidence.

The clean receiver screen can remain the objective. It should not be the whole audit. An operator should be able to show why the sources were considered equivalent, who selected which copy, what the control plane said, what receivers experienced, how long the transition took, and how the decision could be reversed. Only then does “one copy” become evidence of redundancy rather than evidence that suppression happened.

Sources