EVPN Fast Notification and Handling for Multihoming#

Jeffrey Zhang, Wen Lin (HPE), Changwang Lin (H3C)

• Why: EVPN multihoming (DF election, local bias) assumes the Ethernet Segment type-4 route is withdrawn and processed quickly on link failure. BGP update propagation over TCP between routing engines isn't quick — delayed handling means traffic loss (DF down) or duplication (link-up local-bias lag). Per- BFD doesn't scale.
• What: A UDP-based data-plane notification originated and processed in the forwarding plane of MH peers, (near-)instantly updating DF-election/local-bias state without waiting for the BGP control plane. Optionally also notifies all remote PEs (useful for single-active backup switchover and load-balancing rebalance), preferring multicast for the notification address unless the PE count is small.
• How: UDP messages sent from the failing PE's forwarding plane to peers' forwarding planes, several sent back-to-back to compensate for UDP loss; fully independent of control-plane signaling, no EVPN protocol changes in the data plane, all local behavior — hence no interop issues.
• Where applicable: EVPN multihoming deployments generally (All-Active and Single-Active). Individual draft, early — authors are collecting comments before an adoption request; complements time-synchronized DF election (RFC 9722).