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. 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. 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
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
