Hey Tony, Thank you for your comments. Please see in-line.
-----Original Message----- From: Antoni Przygienda <[email protected]> Date: Monday, March 30, 2015 at 12:26 AM To: Jorge Rabadan <[email protected]>, Erik Nordmark <[email protected]>, "Henderickx, Wim (Wim)" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [bess] ARP ND draft >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. [JORGE] at the moment the draft is Informational and it only includes the IXP use-case, but based on the feedback we will extend it to the DC use-case. > > >Thanks for sharing all this experience BTW, insightful read that >enlightened bunch of corner cases I didn't think through. [JORGE] Thank you for your feedback. This is based on an existing implementation/shipping code and the result of the issues we found when implementing proxy-arp/nd for EVPN. > > >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). [JORGE] I am personally a bit reluctant to use “MUST” in this draft, since the use-cases can be very different. You are highlighting one example. > > >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 ;-) [JORGE] 2 ACs on the same ESI/EVI on the same PE? I suppose to are talking about VLAN-aware bundle interfaces, where each VLAN goes to a different BD? note that the proxy-arp/nd function is per broadcast domain, i.e. one per EVI for VLAN-based and VLAN-bundle and one per BD for VLAN-aware bundle interfaces. We can clarify that in the draft. > >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. [JORGE] send-fresh is optional and should be enabled/disabled depending on the use-case. The purpose is in fact keep local IP->MAC bindings active and make sure they are still valid before withdrawing the RT2s. It can also help keeping active not only the proxy entry but also the MAC-VRF entry. If the user wants to rely purely on the age-time, that should be allowed. Not sure why this is a danger? > > >> >> 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? [JORGE] Yes, if the first route is withdrawn (IP1->M1), the second (IP1->M2) will be now installed in the proxy-arp/nd table. As long as the BGP route is kept we are good. A different thing is anycast, in which case IP1->M1 and IP1->M2 are both valid at the same time. We will tackle this in the next rev. > >> >> >> >> 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. [JORGE] IMHO focusing on learning arp/nd for the time being is simpler, and it is really what we want to keep under control to reduce flooding. But we can discuss. > >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 >[email protected] >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
