Aww, c'mon Robert, I think it's a great idea. You just need to clean up a few loose ends.
-- Jakob Heitz. x25475. 510-566-2901 > -----Original Message----- > From: Robert Raszuk [mailto:[email protected]] > Sent: Tuesday, March 29, 2011 1:03 AM > To: Jakob Heitz > Cc: [email protected]; IETF IDR > Subject: Re: [GROW] Potential route flap with bgp-diverse-path > > Hi Jakob, > > I have discussed this proposed text with other diverse-path > co-authors > and we concluded that such additional constrain is not required. > > The reason is that BGP implementations deployed today can > easily delay > reaction by BGP to IGP bad events flooding while in the same time > switchover of the data plane to a pre-installed backup path > will happen > instantaneously in FIB. This will result in no data plane > traffic drop > as well as no BGP churn of any kind. > > Many thx, > R. > > > 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
