[bess] Concerns regarding load balancing of routed unicast traffic indraft-ietf-bess-evpn-unequal-lb

[Alexander Vainshtein <[e-mail]>]

Hi,
I have some concerns about load balancing of routed unicast traffic in the Weighted Multi-Path Procedures for EVPN Multi-Homing<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-22> draft.

Load balancing of routed unicast traffic is mentioned in a single sentence in the Introduction section of the draft that says "ECMP Load-balancing for routed unicast traffic is enabled via existing L3 ECMP mechanisms".

I think that this statement is quite problematic. E.g., consider the scenario depicted in the embedded diagram below:

[cid:image002.png@01DB0901.A0AE33F0]


In this diagram:

  1.  A Layer 2 switch is dual-homed to a pair of EVPN PEs (PE-1 and PE-2) using LAG
  2.  The two PE-CE links are treated as members in an All-Active MH ES by the EVPN PEs
  3.  Multiple IP hosts from a single subnet (192.168.100.0/24) are connected to this Layer 2 switch
     *   All these hosts are configured with the same default gateway IP address
     *   They use this default gateway address for communication with a server whose IP address belongs to a different IP subnet (10.0.0.0/24), and which is connected to a remote PE (PE-3)
  4.  Each of the EVPN PEs contains a local representative of an EVI that is attached to the MH ES in question and connected to an IP-VRF using Symmetric Anycast IRB as defined in Section 4.1 of RFC 9135<https://www.rfc-editor.org/rfc/rfc9135#section-4.1>:
     *   IP address of this IRB is the address used as the default gateway of the hosts
     *   The IRB in each of the PEs belongs to an IP-VRF that locally represents the same BGP/MPLS IP VPN service instance
     *   There is an IP-VRF in PE-3 that locally represents the same BGP/MPLS IP VPN service instance and to which the server is locally connected. Please note that there are no local representatives of any EVI in PE-3
  5.  Constrained Route Distribution (RFC 4684<https://datatracker.ietf.org/doc/html/rfc4684>) is enabled in the IP/MPLS core providing connectivity between PE-1, PE-2 and PE-3.

In this scenario "existing L3 ECMP mechanisms" will not result in load-balancing of routed unicast traffic from the server to the hosts because:

  1.  PE-3 would not be aware of EVPN multi-homing because it would not receive any EVPN Ethernet A-D routes advertised by PE-1 and PE-2
  2.  ARP messages generated by any specific host behind the Layer 2 switch would be received by just one PE and, therefore, only this PE would advertise an MAC/IP Advertisement route for the {Sender MAC, Sender IP} pair in these ARP messages
     *   Each of these routes would carry route targets of both the MAC-VRF and IP-VRF, and would contain a valid label identifying the local IP-VRF in the Label2 field of their NLRI
     *   Therefore, each of these routes would be received by PE-3 an installed as a labeled host route in the RIB and FIB of IP-VRF
  3.  Existing L3 ECMP mechanisms would not provide any load balancing, because There would be just one labeled host route for each host in the RIB and FIB of IP-VRF in PE-3.


I think that this situation is well known, and there are at least two drafts on the table that address this problem:

  1.  EVPN Support for L3 Fast Convergence and Aliasing/Backup Path<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09>
  2.  Proxy MAC-IP Advertisement in EVPNs<https://datatracker.ietf.org/doc/html/draft-rbickhart-evpn-ip-mac-proxy-adv-02>.

However, neither of these drafts is referenced in the Weighted Multi-Path Procedures for EVPN Multi-Homing<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-22> draft.

Hopefully, these notes will be useful.


Regards,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.