Hi Jorge, As you said, it is better left to implementation decision.
Regards, Vinayak From: Jorge Rabadan (Nokia) <[email protected]> Sent: Wednesday, September 17, 2025 3:53 AM To: Joshi, Vinayak <[email protected]>; 'BESS' <[email protected]> Subject: Re: UMR in EVPN Draft - Out of order route arrival Hi Vinayak, First, the scenario you’re describing should generally be a corner case, as data centers typically deploy redundant gateways (GWs) and redundant route reflectors. We can certainly add clarifying text if needed. However, in this specific case, whether a local implementation chooses to program the MACs immediately or wait for the UMR, provided it knows for certain that it exists, is likely best left as an implementation decision. Additionally, sections 6.1.2 and 6.1.3 of the draft already describe mechanisms that help mitigate the situation you’re referring to. Hope it helps. Thanks. Jorge From: Joshi, Vinayak <[email protected]<mailto:[email protected]>> Date: Tuesday, September 9, 2025 at 5:27 AM To: 'BESS' <[email protected]<mailto:[email protected]>> Subject: [bess] UMR in EVPN Draft - Out of order route arrival You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://urldefense.com/v3/__https:/aka.ms/LearnAboutSenderIdentification__;!!NpxR!hqH8vj7_wY_SyGZmvBcLjBPqxdkudCALJ1YdOMHwNYUYY68QLy51ZLFrXYpnDKp-GdXy3jOqN7-KVdW7F_P5-xFGEYYIQwcJ$> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi all, This is about: https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-umr-mobility-03.html#name-distributed-proxy-arp-nd-so<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-sajassi-bess-evpn-umr-mobility-03.html*name-distributed-proxy-arp-nd-so__;Iw!!NpxR!hqH8vj7_wY_SyGZmvBcLjBPqxdkudCALJ1YdOMHwNYUYY68QLy51ZLFrXYpnDKp-GdXy3jOqN7-KVdW7F_P5-xFGEaG61Bw9$> Consider a BGP session disconnect-reconnect scenario between the GW and the domain router. Say all routes received from the GW are deleted by the domain router after disconnect before reconnection. It is possible that upon reconnection, the domain router might receive the regular MAC/IP routes before the UMR from the GW. The domain router cannot decide if that it might/might-not receive UMR in future. Hence it might program it might end up programming the MACs in the L2-FIB as well at least until it receives UMR. This kind of defeats the purpose of UMR. Perhaps having a config knob in the domain router would be a solution ? Since this is a local implementation in the domain router, it does not need any change in the draft. Regards, Vinayak
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
