Hi Wim, > There is anycast at IPv4 level for sure but I am not ware this is supported at arp level.
Precisely right. It needs to be documented and addressed if anyone is up to proposing automated IP duplicate address detection and disabling. RFC1546 is rather too old to consider here as solution :) Cheers, R. On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) < wim.henderi...@alcatel-lucent.com> wrote: > 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", 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> 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> 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> >> 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] >> >> Sent: Thursday, March 26, 2015 6:01 AM >> >> To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) >> >> Cc: 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 >> > >> >> 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 >> https://www.ietf.org/mailman/listinfo/bess >> > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
