> Hi Jakob, > > > The "corner" case happens 1/2 the time. > > If you insist let's focus on it then ... > > > Initial: > > Plane1 advertises P1. > > Plane2 advertises P2. > > > > P1 goes down: > > Plane1 advertises P2. > > Plane2 advertises P3. > > > > The case that the client receives Plane2 message first > > is 50% likely. During the flap, it has: > > > > Plane1: P1 > > Plane2: P3 > > > > P1 is unreachable, so it chooses P3. > > There is no "flap" in the above. Let's see what client does > in this case ... > > Initially you have net X via P1 and P2. > > P1 goes down so P2 becomes active in prefix independent > convergence way > no packet drops other then IGP notification about P1 down bad event. > > Now RR2 sends implicit withdraw and advertises P3 over the session so > client does RIB update for net X and in place modification > for it's next > hop (assuming that P2 and P3 have even different next hops). > > In decent implementation this is not removal of the path, > drop then it's > new installation. In decent bgp implementation switching one > active and > valid next hop with a given net with another valid next hop is not > traffic impacting (if that is what you mean by route flap).
I mean it switches to P2, then to P3, then back to P2. This does not happen when using add-path. It causes churn if this router readvertises to external peers and P2 has different atributes to P3. The issue is not necessarily a problem. However, it needs to be stated in the draft, so that operators can be aware and avoid the problems. > > So with the light of this what problem are you trying to > address in the > first place ? > > > Originally, I proposed a delay on Plane2 advertisements, > > but you didn't like it. How "small" should the delay be? > > In non decent implementation the delay of advertising 2nd > best may cover > for it. I would not make any recommendation for the value at > this point > and leave it as an configuration option. > > > I think longer than MRAI, since Plane1 may be running > > that timer for its P2 advertisement. > > Well this now depends how MRAI is implemented ... does it > allow always > first transition to go or not. Besides default MRAI for IBGP > and this is > IBGP we are discussing has been for a long time recommended > to be of zero. > > > What is the "extra session"? > > Is it a 3rd RR plane? > > Additional session allows you to receive from the same RR > both best and > second best paths one on each session. Hence non of the > issues you are > describing do apply then. That makes it a 3rd RR plane. It means you are recommending at least as many RR planes as possible paths for any destination. > > Cheers, > R. > > > > > > > > -- > > Jakob Heitz. > > > > > >> -----Original Message----- > >> From: Robert Raszuk [mailto:[email protected]] > >> Sent: Sunday, March 27, 2011 1:46 PM > >> To: Jakob Heitz > >> Cc: [email protected]; IETF IDR > >> Subject: Re: [GROW] Potential route flap with bgp-diverse-path > >> > >> Hello Jakob, > >> > >>> If there are 3 paths: P1, P2 and P3 > >>> and 2 RR planes. > >>> Plane1 advertises best, Plan2 advertizes 2nd best. > >> > >> Ok. > >> > >>> 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. > >> > >> Nope it will not .. see below on comments to your description. > >> > >>> Here is the initial condition: > >>> P1 is best, P2 2nd best, P3 3rd best. > >>> Plane1 advertises P1, Plane2 advertises P2 > >> > >> Perfect ! > >> > >>> 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. > >> > >> Ok. > >> > >>> 2. Client receives IGP message of P1 down: Client chooses P2. > >> > >> Ok. > >> > >>> 3. Client receives P3 from Plane2: Client chooses P3. > >> > >> This is only when client would not have P2 at all. IMHO > >> corner case (see > >> below why) > >> > >>> 4. Client receives P2 from Plane1: Client chooses P2. > >> > >> P2 should not go away from client. > >> > >>> Possible fix: Recommend at least as many RR planes > >>> as possible paths for any destination. > >> > >> Nope. > >> > >> There are two simple solution here: > >> > >> - Presence of an extra session from client to either RR to > make sure > >> that your second best is not removed before overall best > is advertised > >> > >> - Small delay on the RR when advertising 2nd best to > clients to make > >> sure overall best is there first in some implementations just > >> configuring per session mrai may help here. > >> > >> Cheers, > >> R. > >> > >> > > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
