Hi Wen, First, thank you for this work, I see the problem you’re trying to solve and support trying to do that. I have some questions.
Lets say for example, PEs: 1,2,3 have CE1 attached on the same all-active ES. PE4 is a remote PE participating in the same EVPN. CE1’s MAC/IP is learned in the dataplane by PE1 only, and PE1 originates the RT2 initially. At this point, with standard 7432 mechanisms, PE4 can already have aliasing and backup paths to CE1 via PEs 2 and 3 without the need to see an RT2 from either PE2 or PE3. What PE2 and PE3 might be missing locally, however, is ARP/ND state for CE1, which is and which your draft looks to solve in BGP. (If my understanding is correct?) Now if PE2 and PE3 support the proxy-adv mechanism, then they sync ARP/ND upon receipt of the RT2 from PE1. Why do PE2 and PE3 then need to originate their own RT2? If they originate RT2’s then this can influence the forwarding decisions at other remote PE’s like PE4, who lets say doesn’t understand the proxy-adv bit in the ARP/ND extended community and will see the RT2 as originating from 3 different PE’s. Is that the intention of the draft or just a consequence? Or is it the intention to keep the proxy-adv mechanism for use amongst the multihomed PE’s only? Thanks Sandy
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
