I propose to add this text to the draft: Advertisements of multiple paths by multiple planes of advertisers are received asynchronously. It is not possible to order the messages reliably from different planes. This may cause churn in route selection when paths change.
To address this issue, a speaker that advertises the Nth best path, where N>1, SHOULD delay its advertisement by MRAI plus (N-1) times X. X SHOULD be a small value that is greater than the message delivery time between BGP speakers. Such a speaker should not add its own MRAI timer to this delay. A speaker that advertises the Nth best path shall initially advertise nothing if an Nth best path does not exist. Once the Nth best path changes, it should apply the above delay before sending the changed advertisement. The change may be a withdrawal. -- Jakob Heitz. > -----Original Message----- > From: Robert Raszuk [mailto:[email protected]] > Sent: Sunday, March 27, 2011 3:06 PM > To: Jakob Heitz > Cc: [email protected]; IETF IDR > Subject: Re: [GROW] Potential route flap with bgp-diverse-path > > Hi Jakob, > > > I mean it switches to P2, then to P3, then > > back to P2. This does not happen when using add-path. > > No one is trying to compare it to add-paths. > > > It causes churn if this router readvertises to external > > peers and P2 has different atributes to P3. > > What it needs to be compared against is current BGP deployments. You > best path from both RRs and when it fails you blackhole > traffic till BGP > provides you a new path. > > The external re-advertisement is also not really valid > observation. One > main reason why EBGP MRAI is longer then IBGP MRAI is exactly to > mitigate those short lived BGP transitions from being visible in the > entire Internet. > > > 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. > > If you have some text to propose which would first correctly describe > and clarify the issue I would be happy to incorporate it. > > Just keep in mind that diverse-path is a very simple way, > without need > to upgrade the client side to provide much better path switchover > results with no packet drop as compared to what is today. > > > That makes it a 3rd RR plane. > > It means you are recommending at least as many RR planes > > as possible paths for any destination. > > Nope. I think you are drawing conclusions too quickly. > > Second client-RR session would allow to advertise best and > second best > from any given RR. That means that you would never transition to 3rd > best even for fraction of time as your R2 would still be there on the > client. > > Keep in mind that some deployment proposal models from customers are > even today focused on sharing RRs and configuring some clients to get > best and some to get second best from a given RR even if RRs are in > pair. And this is just configuration as the diverse-path as will be > discussed in GROW meeting this week during the implementation > report is > a per peer knob. > > Many thx, > R. > > > > > > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
