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
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
