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:[email protected]] > Sent: Thursday, March 26, 2015 6:01 AM > To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge) > Cc: [email protected] > 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" <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
