| Internet-Draft | EVPN MH Fast Notification | March 2026 |
| Zhang, et al. | Expires 3 September 2026 | [Page] |
EVPN supports powerful multihoming features, but it depends on the timely notification and handling of link going down or coming up on multihomed Ethernet Segments, which may not be guaranteed by the nature of control plane BGP signaling. When the handling is delayed, traffic duplication or loss may happen. This document specifies a UDP-based notification that can be originated and processed (near) instantly, greatly eliminate the potential traffic duplication or loss.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
EVPN [RFC7432] supports powerful multihoming features, but it depends on the timely notification and handling of link going down or coming up on multihomed Ethernet Segments, which may not be guaranteed by the nature of control plane BGP signaling. When the handling is delayed, traffic duplication or loss may happen.¶
PEs attached to a Multi-Homed Ethernet Segment (MHES) elect a Designated Forwarder (DF) and optionally elect a Backup Designated Forwarder (BDF). All the PEs in an EVPN instance learn the DF/BDF roles through the Primary/Backup-bit (P/B-bit) [RFC8214] in the EVPN Layer 2 Attributes Extended Community advertised with the EVPN Ethernet AutoDiscovery (type-1) route.¶
In the EVPN multihoming case, all the PEs on the MHES will receive a copy of the BUM traffic. In single-active multihoming case, only the DF sends the traffic to its locally attached MHES. In all-active multihomng case, the forwarding to the MHES depends on the following:¶
With the MPLS data plane, if the traffic originated from the same MHES on another PE, it is not forwarded to the MHES at all by any receiving PE. Otherwise, only the DF forwards BUM traffic to the MHES.¶
With the IP data plane (e.g., VXLAN), locally originated BUM traffic is forwarded to all MHESes regardless of the DF status. Remote BUM traffic is dropped on an MHES if the source PE is also attached to the MHES. Otherwise, only the DF forwards to the MHES. This behavior is called Local Bias.¶
If the MHES goes down on a DF, a new DF (typically the pre-elected BDF) needs to quickly take over and forward traffic on the local ES.¶
Remote ingress PEs need to quickly know the changes on a remote MHES, too. In the case of Single-Active, if the DF's link goes down on an MHES, the remote ingress PEs need to quickly switch to sending unicast to the new DF. In the case of All-Active, the remote ingress PEs may load balance to all the peers on the remote MHES, so any down event needs to be quickly notified to all remote ingress PEs.¶
In the case of Local Bias, if the MHES goes down on a PE, other PEs on the same MHES need to quickly update their Local Bias state, so that BUM traffic from that PE will be forwarded by the DF (which could be the current one or a new one - the original pre-elected BDF - if that PE was the DF) on the MHES.¶
Conversely, if the MHES comes up on a PE, other PEs on the same MHES need to quickly update their Local Bias state so that BUM traffic from that PE is no longer forwarded to the MHES even by the DF.¶
If the handling is delayed, traffic duplication/loss will happen. However, the delay is easy to happen due to the following reasons:¶
The "slow" control plane (e.g., a routing engine) needs to learn the MHES state change and then originate or withdraw a corresponding EVPN Ethernet Segment (type-4) route and EVPN Ethernet Auto Discovery (type-1) per ES route.¶
The route is subject to various BGP route propagation control/effects and even TCP flow control.¶
The receiving PE's "slow" control plane needs to get the route, process it, and then update the forwarding states in the "fast" forwarding plane (e.g., the line cards).¶
As a result, significant duplication/loss could happen, especially in scaled scenarios.¶
While BFD [RFC5880] can be used to quickly detect the link faliures, one BFD sessoin would be needed for each MHES, with the BFD packets sent all the time. This document specifies an alternative light-weight solution.¶
To speed up the process, the notification SHOULD be sent in the forwarding plane via UDP per [I-D.zzhang-rtgwg-router-info] and [I-D.zzhang-bess-dynamic-overlay-lb], and handled in the forwarding plane on the receiving PEs.¶
The MHES down notification on a DF in the case of Single-Active or of any role in the case of All-Active MAY be sent via multicast to all PEs, so that for unicast traffic destined to the MHES they can quickly switch to sending to the pre-elected BDF in case of Single-Active, or load balancing to the rest of the PEs on the MHES in the case of All-Active. This significantly speeds up the global repair on the ingress PEs, reducing the importance of egress protection.¶
If multicast is not available, the above mentioned-notification to all PEs MAY be sent via unicast, or may be skipped to avoid the burden of individual notifications.¶
Additionally, except in the case of down notifications already being sent to all PEs as mentioned in the previous paragraph:¶
If Local Bias is used, any MHES up/down event SHOULD be notified via unicast to known peers on the MHES (so that they can update their Local Bias state, and if the down event is on the DF the BDF can take over).¶
If Local Bias is not used, any MHES down event on a DF SHOULD be notified via unicast to the BDF on the MHES (so that the BDF can quickly take over).¶
To compensate for potential loss of the unreliable UDP notifications, several copies SHOULD be sent quickly in a row.¶
[I-D.zzhang-bess-dynamic-overlay-lb] specifies that MHES PEs can dynamically signal link loads on the MHES so that remote ingress PEs may load-balance unicast traffic to different MHES PEs based on the dynamic load information.¶
Even if the dynamic load-balancing based on dynamic load information is not used, the same UDP notification specified in {{!I-D.zzhang-bess-dynamic-overlay-lb" is used for the fast notification in this document, with the following differences:¶
To be added.¶
To be added.¶