EVPN Fast Notification and Handling for Multihoming

Introduction 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. 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) 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 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.

Specification To speed up the process, the notification SHOULD be sent in the forwarding plane via UDP per and , 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. 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: The notification is only sent when an MHES comes up or goes down. The load information is set to 0 and ignored by the receiving PEs. In all cases, the notification carries an indication if the originating PE was a DF on the MHES. The exact encoding is TBD.

Security Considerations To be added.

IANA Considerations To be added.

Acknowledgments