Subject: [bess] Expected forwarding behaviour of RT2 + ESI, for part EVPN implementations

From: Sandy Breeze <[email-masked]>
Date: Fri, 26 Feb 2021 17:21:17 +0000

Dear WG,

Recently, I discovered 2 EVPN implementations with no support for multihoming functions.
In both cases, vendor says RFC7432 section 8 is completely not implemented.  One
implementation blackholes forwarding to MAC routes received from elsewhere in the EVPN
domain which contain non-zero ESI, and the other implementation learns them in the
control-plane but fails to program the forwarding plane, and traffic ends up being flooded
unknown unicast.

In both cases, the implementations I refer to are within a ToR and VxLAN is the forwarding
plane, which I believe RFC8365 defers to RFC7432 for its route resolution mechanism.

In section 9.2.2, RFC7432 mandates that if local PE decides to install, then it should do
so when both RT1 and RT2 have been received, to avoid installing when there is a mass
withdraw event.

What would the WG expect the behaviour be, for those implementations who do not understand
non-zero ESI attached to an RT2?  Contemplating possible outcomes;

a) Ignore ESI and treat as any other single-homed RT2?  (Downside is lack of L2ECMP
towards the ES, but probably safer than flooding it)
b) Treat as withdraw / drop route?  Though resulting forwarding behaviour could be traffic
flooded unknown unicast
c) Blackhole the route locally so traffic to that MAC is dropped?
d) Something else?

All suggestions welcome,

Regards
Sandy