Hey Jorge, I read your draft again in a larger context than simple 'informational how IXP network runs eVPN ARP stuff'. Generally I think it should be extended beyond 'some customer's use case' and provide BCP or 'implementation recommendations' or some such thing for the generic issue of snooping ARP/ND/DHCP/others to reduce the amount of BU_ traffic across the PEs. ARP/DHCP/ND snooping is a delicate functionality that is vastly underspecified in eVPN base and is essential for a good eVPN implementation (i.e. robust, interoperable & scalable) IMO.
Thanks for sharing all this experience BTW, insightful read that enlightened bunch of corner cases I didn't think through. Comments inline > >> a)It is worth explaining what flavor of ARP proxy eVPN implements. > >> ‘proxy ARP’ I found out has different flavors including e.g. the > >> router responding with its own MAC to requests representing remote > >> hosts. Customers & other folks are easily confused by the overloaded > >> ‘proxy ARP’ term in eVPN context. > >> > >Yes, that is a part that is underspecified for EVPN. I assume that the > >response would include the MAC address of the CE instead of the > >router's own MAC address. > > [JORGE] From draft-snr-bess-evpn-proxy-arp-nd-00: > > 4.2 Reply sub-function > > ... > > a) When replying to ARP Request or NS messages, the PE SHOULD use the > Proxy-ARP/ND entry MAC address as MAC SA. This is recommended so > that the resolved MAC can be learnt in the MAC FIB of potential > Layer-2 switches seating between the PE and the CE requesting the > Address Resolution. [Tony saiz:] agreed. I cannot imagine why it's NOT a MUST (except default GW cases where it makes sense e.g. in case of aliased case to resolve GW IP request). Small observation for 4.2b) If we want to be double-perfect we should actually not even respond if we have 2 ACs on the same ESI on the same PE ;-) Small observation for 4.3: enabling the send-refresh option is a dangerous thing. It's not only they may keep up active entries in the fast-path forever (since there is always some traffic generated by the 'probes'), it's also that the IP/MAC binding 'kept up' even if there is no traffic is sitting in all PEs as RT-2. The section talks about advantages, maybe it deserves a sentence to point out the dangers of such behavior. > >> b)It is worth explaining what is suggested behavior if eVPN > >> advertises the same IP with multiple MACs and what happens when e.g. > >> the served MAC vanishes > >> > >Doesn't the EVPN RFC already stating that the routes would be withdrawn > >in that case? > > [JORGE] Based on our current version, the IP is unique in a PE’s proxy-ARP > table, > so if a PE receives 2 RT-2s for the same IP different MAC, only one > IP->MAC binding will be picked up. [Tony saiz:] as I wrote in other email, the problem is if the first route goes, the second should be honored IMO. It seems to me we have this very case BTW with the aliased default gateways? > >> > >> c)It is worth explaining what the suggested behavior should be when > >> ‘local-bit’ MACs are being advertised from remotes (and when those > >> collide) > >> > >Does L2VPN handle that in any interesting way? I don't think EVPN > >introduces any new failure modes for duplicate MAC addresses. > > [JORGE] indeed, this draft does not introduce any new way to handle MAC > addresses in the MAC-VRFs. EVPN has a MAC duplication mechanism, there is > nothing else afaik. [Tony saiz:] agreed. > >> > >> d)eVPN draft does not explain anything about possibility to snoop @ > >> DHCP > > [JORGE] do you mean in the proxy-arp/nd draft or in the base spec? > In the proxy-arp/nd only ARP/ND messages are used. DHCP is not always there. > Not there in the IXP use-case anyway. [Tony saiz:] agreed, I just read the draft in wider scope than just IXP and that's why I'm asking. One could even talk about initially snooping IP frames directly in case eVPN "attaches" to an already running bridge and snoops already active IP traffic to learn IP/MAC bindings from bridge ports. Probably hypothetical only ;-) -- tony _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
