If there are 3 paths: P1, P2 and P3 and 2 RR planes. Plane1 advertises best, Plan2 advertizes 2nd best.
When the bestpath P1 goes away, the client can flap to the 3rd best path, P3, before coming back to the 2nd bset path P2. Here is the initial condition: P1 is best, P2 2nd best, P3 3rd best. Plane1 advertises P1, Plane2 advertises P2 Because the advertisements from the RR planes are not synchronized, the order of events could be: 1. P1 goes down: P2 becomes best, P3 becomes 2nd best. 2. Client receives IGP message of P1 down: Client chooses P2. 3. Client receives P3 from Plane2: Client chooses P3. 4. Client receives P2 from Plane1: Client chooses P2. Possible fix: Recommend at least as many RR planes as possible paths for any destination. -- Jakob Heitz. > -----Original Message----- > From: Robert Raszuk [mailto:[email protected]] > Sent: Saturday, March 26, 2011 1:48 AM > To: Jakob Heitz > Cc: [email protected] > Subject: Re: [GROW] Potential route flap with bgp-diverse-path > > Hi Jakob, > > > Suppose 2 RR planes, plane1 advertises the best path > > and plane2 advertises the second best. > > > > If there is no second best, does plane2 advertise nothing? > > Yes it would advertise overall best if backup is missing. > > > Suppose it does. > > Ok. > > > Suppose there are 2 paths to a destination. > > P1 is best and P2 second best. > > Now P1 goes down. > > Plane1 will change its advertisement to P2. > > Plane2 will withdraw P2. > > No. > > The overall assumption is that all RRs keep all paths. So > plane 1 will > advertise P2 and plane 2 will do nothing if P1 goes down as > it already > advertised P2 to the client. > > > If the RR client receives and processes the withdrawal > > first, it will flap. > > No withdraw will happen. > > Cheers, > R. > > > Note, the messages are asynchronous. Even if plane1 > > sends his message first, the client can still process > > the message from plane2 first. > > > > A solution would be to delay any advertisements from > > the second-best plane by an interval greater than the MRAI > > timer. Not good, but I can't think of anything better. > > > > -- > > Jakob Heitz. > > > > _______________________________________________ > > GROW mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/grow > > > > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
