Summary

  • RFC 9746 lets eligible All-Active EVPN encapsulations advertise a preferred split-horizon method. The advertised administrative choice becomes operational only under the required agreement among the segment's participants.
  • A mismatch, including a default SHT advertisement, sends the relevant NVEs back to the encapsulation-specific default. In MPLSoUDP, that can require valid nonzero ESI labels previously omitted under local bias.
  • Compatibility admission therefore needs a resource plan and service-scoped verification, not merely an approved configuration. Route grouping, peer membership and actual BUM filtering determine whether the intended optimization survives.

The third device changes the economics

Two upgraded network edges use MPLS over UDP on an All-Active Ethernet segment. They advertise local bias and a zero ESI label, avoiding label allocation where their chosen procedure does not need it. A third edge joins the segment and advertises the default split-horizon type. The first two must now use the encapsulation's default method and update their advertisements with valid nonzero ESI labels.

This is the compatibility example in RFC 9746, section 2.4, not a reported outage. Its significance is nevertheless practical. The new participant has not edited the other devices' administrative settings. Their advertised preference can remain local bias. Their forwarding obligation has changed because membership changed. A saving earned under one peer set becomes a resource requirement under another.

Published in March 2025, RFC 9746 updates RFC 7432 and RFC 8365. It changes signaling and selection, not the two underlying filtering algorithms. The document's Proposed Standard status, and the absence of listed errata in today's formal search, establish the specification being examined. Neither establishes implementation support or measured production reliability.

What must not come back

The protected boundary is a multihomed customer edge. A broadcast, unknown-unicast or multicast frame originating there must not return to it through another provider edge. Split horizon identifies where that frame entered and suppresses the return path; successful suppression must coexist with delivery to legitimate destinations.

The ESI method carries a source-segment identifier that the egress can use to prevent forwarding onto that segment. In MPLS this involves the ESI label. Local bias instead identifies the ingress NVE from the outer tunnel's source IP and filters on local segments shared with that NVE. The ingress must also replicate access-originated BUM traffic locally to its directly connected segments, regardless of the DF election state. That local replication is part of the mechanism, not an optional performance tweak.

The methods have different operating boundaries. Local bias is for All-Active multihoming and requires that the next hop not change between NVEs attached to the same segment. It is not a Single-Active substitute. ESI-based filtering can serve both redundancy modes and different network domains. RFC 9746 notes possible resource, encapsulation and local-delivery benefits of local bias; it offers no universal latency saving or capacity figure.

A preference needs a compatible set

The split-horizon type, SHT, occupies bits 6 and 7 of the ESI Label Extended Community Flags. The current IANA registry retains three assigned values: 00 for default behavior, 01 for local bias and 10 for ESI-based filtering; 11 remains unassigned. The rest of today's Flags registry has evolved since publication, so an old diagram of its unassigned bits is not a current inventory.

Choice exists only where the encapsulation supports both methods. MPLSoGRE, MPLSoUDP, Geneve and SRv6 are listed as capable of doing so. VXLAN, NVGRE and VXLAN-GPE remain local-bias-only; MPLS and SR-MPLS remain ESI-only. A nondefault SHT cannot manufacture a capability the tunnel lacks. Single-Active combined with nonzero SHT requires treat-as-withdraw processing, rather than an attempt to negotiate local bias.

For a given EVI on the same ES, inconsistent advertised SHT values require all the NVEs to revert to the default for the encapsulation. Receiving even one same-segment 00 advertisement requires an upgraded NVE to revert its operational SHT, irrespective of its administrative choice. A 00 route is consequently decisive evidence, but not proof of an old software version: an upgraded participant can intentionally choose the default too.

There is no majority rule. Two local-bias preferences do not defeat one default advertisement. There is also no single global default. MPLSoUDP returns to ESI filtering; VXLAN's baseline is local bias. Geneve depends on its Ethernet option and source identifier. SRv6's default source-ES filtering is analogous to the ESI method, not a claim that an ordinary MPLS label appears in every SRv6 packet.

The label saving has an exit condition

Advertising 01 may permit a zero ESI label. That is a genuine optimization because an unused label need not be allocated. It is not permission to keep zero after the operational method changes. Operational ESI filtering requires a valid nonzero advertisement, and the default-state zero-label permissions are constrained by the encapsulation and need for the label.

In the MPLSoUDP example, the upgraded pair must issue route updates when the default participant arrives. The general zero-label transition rule includes an exception when all the non-upgraded participants support only local bias. It should not be simplified into “every fallback always allocates a label.” Equally, a dashboard showing an unchanged administrative 01 must not conceal a missing label under an ESI operating baseline.

Operators should therefore treat available fallback resources as part of compatibility, rather than count only the resources used by today's optimized state. This is an operational recommendation, not a sizing formula in the RFC. The public sources provide neither a vendor label-pool limit nor a measured interval between route update and hardware programming.

Aggregation cannot erase the method

Multi-encapsulation advertisements make the unit of control more exacting. Encapsulations sharing one A-D per ES route must use the same split-horizon method. A group containing a single-method encapsulation must advertise 00; a group in which every encapsulation supports both methods may express 01 or 10. MPLS and VXLAN cannot simply share a route carrying one convenient preference.

Where different EVI subsets require different methods, section 3 requires distinct routes or route groups. Each EVI's Route Target occurs in one, and only one, A-D per ES route for that segment; multiple routes have distinct Route Distinguishers. The specification's example separates VXLAN/default, MPLSoUDP/local bias and Geneve/ESI filtering. The last group needs the valid nonzero label and the Ethernet option, not just the right bits.

All NVEs within a given EVI must support a common encapsulation. Splitting route groups does not repair that missing common capability. A change review that records “ES approved” while ignoring EVI and encapsulation membership has aggregated away the very conditions that determine the operating method.

A fallback is not an incident report

RFC 9746's security analysis says a valid SHT change on one attacked device should not disrupt traffic under its procedures, though forwarding behavior may change. That qualified statement is not a zero-outage warranty for arbitrary invalid configurations, unverified implementations or exhausted fallback resources. Default operation itself is not a failure, and an unobserved operational method should be reported as unknown rather than assumed broken.

The useful acceptance test exercises the actual transition. Introduce and remove a default participant in a bounded test segment; observe the relevant advertisements, label allocation and filtering entries. Follow BUM traffic from its access ingress to expected recipients, and confirm it does not return to the originating customer edge. Record duplicates, loss and loops over a stated window. A quiet source interface alone proves neither legitimate delivery nor successful rollback. These are proposed verification practices, not new RFC telemetry fields or a universal convergence SLA.

Sources and limits

No vendor adoption count, production incident, resource limit or measured recovery time was established. The three-device scenario is the standard's example; the featured image is AI-generated conceptual photography, not deployment evidence.