Hi Zhiqiang Li, Lots of thanks for your email. Please see some comments inline below. Hopefully, they will be useful.
Regards, Sasha From: 李志强 <[email protected]> Sent: Tuesday, July 28, 2026 5:09 PM To: Alexander Vainshtein <[email protected]> Cc: [email protected] Subject: [EXTERNAL] Re: [bess] A short comment on draft-li-bess-evpn-ead-multipath Hi Alexander, Thanks for your precise review and sharp observation on RFC 7432 specifications. First, we fully agree with your core conclusion: when Type 1 RDs are used (mandatory in spirit for per-ES, recommended for per-EVI), EAD routes from different PE/EVI form distinct NLRIs and cannot be supp [Image removed by sender.]<https://report.mimecastcybergraph.com/?magiclink=https%3A%2F%2Fapi.services.mimecast.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Do20nRkVXf7VUVnANkXhoOwGytEwGN0YAlyeDJn7oBTGNl2kN%26state%3DeyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.iir_1BmTm5cdZeItrTwxRLccExJ0vcsRqX8a1ghKY2EahmNaru-hKmQLm4OEC0gHeijTF2n6mnppyE3GxZ9rNvO1SLGe09kMki-CcA8jxX9jRplw8DTbCFr_FzrlQKnyrZ7IEVwDpIP74dnPn3vt9gZOrubdxDK6RKaJmLf2sqkXuDd118yWWkoq4xkdiVuGfjQWVJyczaNTKFL5twBOK3r6f9cKkus3EnR8MZ4ezoum8hy6Cevj-9hPvfZmcFyd2WaS7UfgVsP1cQo185mnWZx7U8U7ZbI_XC5PYHE4B8MZUIuF5oGXstEkdo5_e8Dag9bqDD8A6rCWSDYG8J7QUQ.1qQwNUdEV15270L5.KPdujUDqWvuAv8r3aFlJYlewFEhRMrVcS-u-3XAEDgZET2oMC0YNXu1ksh0WSkGmAkBBf_K_37RKtz-qc9nWLZ25Gyz0Gu-LzQbJ0OyY2gyTaO-2ypNc31lGIks5l3_s-xh_062HEvoF2iPBko2v8pIDInFEw2Hnbz0T81ffVMn3Z3mY_43SrYYPdlM8QBCHUebwCvvufLkZYIlbEysmV4bCwIZ7d6ELFSZ8vBBa4U_ODWRE1WlaHZJSUVckcEaZsRz_p__b1elehJy7YJWuU2TzA-PJZsqGYfkcbZwGs0UuAxnEKlFX8WuEv9u8SiB2w8n2NnspwCLUi_klX61HvLpW8vgMyf6ylMR4dUfBmvVnLoLsbOqtl5CcZ2aPdP8sKVtvOs3hpmQkpztfPB6hbH0vKBm0X1B83MlewX3uk7tfLQlXMtiPUeMI3Fsn0a9eMl0YJYO5w5J_Og6vQkUtUfRxZUTcAVqenS1HTL85UgFvDlGHksDvT_TQkxYbVWU8sT6dzLO9w-qq5gO-qJ57Rok74DSp1ttdVWsV0MCsb_UoNuu4VwQfP5QHThzY7tYi5_yKlQva_FS4PMEWvADpV2gKOJ4Gj4ERNfiBVWHy2K_NKT2IJzVa3mvihzAeaD8RjI4zEpk54OuqwoPSQpvc6vsoUf_O_opE4wfvHBd51c_2jmTkCuKOd7bwI_-co4Im1eiEN2fPPt5cRXmVGvXx5HGxmxVuZmGWMObAX8Hc1nClz46VIy00ro481jy6aOAOjpFcPt--Xxf9rxaTFNB_QNMp73_G7_MrGP8kF8exHyrR3ytiTqId9rjbX0M16K0moLQfFDO_9cYfXtZGodzzpYz70pVz86AtaITusAI.tK7q_BOAJlK48tg-KlKKcA%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback> CGBANNERINDICATOR Hi Alexander, Thanks for your precise review and sharp observation on RFC 7432 specifications. First, we fully agree with your core conclusion: when Type 1 RDs are used (mandatory in spirit for per-ES, recommended for per-EVI), EAD routes from different PE/EVI form distinct NLRIs and cannot be suppressed by standard BGP Best Path selection. Your reading of RFC 7432 is completely correct. The confusion comes from ambiguous wording in the current draft. We have no intention to "twist the BGP Path Selection algorithm" itself. The draft targets two separate practical scenarios: 1. Shared-RD deployments (more common for per-EVI cases, where Type 1 RD is only RECOMMENDED, not mandatory): With identical RD across PEs, EAD routes of the same ESI/Ethernet Tag form identical NLRIs, and default BGP single-best-path behavior suppresses redundant paths. The draft mandates BGP multipath for EAD routes to retain all valid paths — it applies an existing BGP capability to EVPN EAD, not rewrites the path selection logic. [[Sasha]] Quoting from RFC 2119 (the relevant text is highlighted): SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course From my POV the operator that decides to ignore the RECOMMENDED usage of the MAC-VRF RD deserves all the consequences of this decision. 2. Standard unique-Type-1-RD deployments: The draft works at the EVPN application layer, not BGP layer. It requires the ingress PE to logically aggregate EAD routes of the same ESI (despite different NLRIs) and pre-install all valid paths into the forwarding plane for fast failover, without touching BGP route selection at all. For the case of multiple per-ES EAD routes from one PE (due to RT overflow): these are treated as a single logical path on the receiver side and do not count as independent multipath entries. [[Sasha]] This looks to me as a local issue within a specific implementation in the ingress PE and does not require any standardization. We will revise the next version of the draft to clearly separate BGP control-plane behavior and EVPN forwarding-plane processing, to eliminate this ambiguity. Thanks again for catching this critical wording issue. Further comments are very welcome. Best regards 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.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
