Tony, Erik, Please see in-line. Thank you for your comments.
-----Original Message----- From: Erik Nordmark <[email protected]> Date: Wednesday, March 25, 2015 at 4:32 PM To: Antoni Przygienda <[email protected]>, Jorge Rabadan <[email protected]>, "Henderickx, Wim (Wim)" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [bess] ARP ND draft >On 3/25/15 10:23 AM, Antoni Przygienda wrote: >> >> Watching the presentation in the group and instead crowding the mike >> here are my comments: >> >> 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. > >> 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. >> >> 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. >> >> 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. >> > >> e)the IP duplicate detection is an interesting thing given the >> anycast/multicast and other zoo >> >Presumably not only anycast, but also for some host that might have a >single IP address and use it with different MAC addresses (I think >certain configurations of NIC bonding has that effect.) > >FWIW the SAVI RFC provides an approach to tell whether it was a change >in the IP to MAC binding or the IP address being reachable at multiple >MAC addresses at the same time (which is basically to unicast an NS to >the old MAC address - I don't know if that would work will for ARP as >well). > >That still leaves out what to do in the case of anycast addresses etc. [JORGE] As I mentioned during the session, the current draft does not support anycast addresses. The use-case we are focusing at the moment (IXPs) does not require it. We can think about it though. As for the IP “moving" to a different MAC, we have introduced this “CONFIRM” message in this implementation. We have implemented it not only for ND (unicast NS, like in NUD) but also for ARP (unicast ARP request), and seems to work well: "o In order to detect the duplicate IP faster, the PE MAY send a CONFIRM message to the former owner of the IP. If the PE does not receive an answer within a given timer, the new entry will be confirmed and activated. For instance, if IP1->MAC1 moves to IP1->MAC2, the PE may send a unicast ARP-Request/NS message for IP1 with MAC DA= MAC1 and MAC SA= PE's MAC." > >Regards, > Erik > > > >> --- tony >> >> // >> >> /There are basically two types of people. People who accomplish >> things, and people who claim to have accomplished things. The first >> group is less crowded. >> <http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>/ >> >> /~~~ Mark Twain >> <http://www.brainyquote.com/quotes/quotes/m/marktwain393535.html>/ >> >> >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
