To be clear: RFC4861 section 7.2.7 explains the anycast behaviour in IPv6. I am not aware of such thing at IPv4/ARP level. Do you have a pointer? There is anycast at IPv4 level for sure but I am not ware this is supported at arp level.
From: <Henderickx>, Wim Henderickx Date: Monday 30 March 2015 07:38 To: Robert Raszuk Cc: Erik Nordmark, Antoni Przygienda, "bess@ietf.org<mailto:bess@ietf.org>", Jorge Rabadan Subject: Re: [bess] ARP ND draft At interface level you get dad in most stacks I know. Sent from my iPhone On 30 Mar 2015, at 06:45, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Hi Wim, What makes you say that in IPv4 there is no anycast ? All anycase I have played so far is IPv4 :) Cheers, r. On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> wrote: We will update the draft to highlight the IPv6 anycast behaviour better as pointed out by RObert. In IPv4 there is no anycast behaviour and as such there should be one option possible. On 30/03/15 04:59, "Antoni Przygienda" <antoni.przygie...@ericsson.com<mailto:antoni.przygie...@ericsson.com>> wrote: >Yes, but of course I brought it up to show that 'the last one simply wins' as >suggested by the draft is not enough IMO. A good architecture should probably >keep track of what it served as answer and when the answer is invalid or a >new, better one exists, provide a GARP. > >As well, when PE2 sends a newer MAC it may not be a good strategy to serve a >GARP if PE1's MAC has already been offered. That could lead IMO to e.g. >gateway chasing problems. > >--- 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. >~~~ Mark Twain > > >> -----Original Message----- >> From: Henderickx, Wim (Wim) >> [mailto:wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>] >> Sent: Thursday, March 26, 2015 6:01 AM >> To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) >> Cc: bess@ietf.org<mailto:bess@ietf.org> >> Subject: Re: [bess] ARP ND draft >> >> For this case you should sent a GARP with the new MAC/IP >> >> >> >> >> On 25/03/15 18:56, "Antoni Przygienda" >> <antoni.przygie...@ericsson.com<mailto:antoni.przygie...@ericsson.com>> >> wrote: >> >> >> > 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? >> > >> >The scenario I had in mind was when eVPN PE receives >> > >> >From PE2 IP1/M1 and later >> >From PE3 IP1/M2 >> > >> >while having answered with IP1/M1 per proxy alrady. Additionally, in >> >such situation ends up seeing >> > >> >From PE2 IP1/<no MAC> >> > >> >So the answer it gave is not valid anymore all of a sudden. >> > >> >--- tony _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
