I don't want to argue the importance of the tie breaker rules (f) and (g). They may or may not be important.
My point is that diverse-path breaks them and my rule fixes it. Here it is again: The RR Plane that advertises the best path MUST be configured with a BGP Identifier higher than that of the RR Plane that advertises the 2nd best. This must be higher than that of the Plane that advertises the 3rd best and so on. -- Jakob Heitz. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jakob Heitz > Sent: Monday, March 28, 2011 3:38 PM > To: [email protected] > Cc: IETF IDR; [email protected] > Subject: Re: [GROW] [Idr] > draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent > path selection > > The inventors of BGP added tie breaker rules > after IGP metric. > > It helps to void churn in upstream AS's that would > be caused by advertising different paths needlessly. > There may be other reasons for these rules too. > > Apparently, Pradosh found them important enough to > invent the Edge_Discriminator attribute to keep > these rules working. > > -- > Jakob Heitz. > > > > -----Original Message----- > > From: Robert Raszuk [mailto:[email protected]] > > Sent: Monday, March 28, 2011 2:31 PM > > To: Jakob Heitz > > Cc: IETF IDR; [email protected] > > Subject: Re: [Idr] [GROW] > > draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent > > path selection > > > > Jakob, > > > > Diverse-path works between RR and the client and client does not > > advertise back the best path to other IBGP peers so there > is no issue > > with churn or oscillation. > > > > Advertising different paths to possible EBGP peers is a > > feature not a bug. > > > > By definition of diverse path such path will have different > next hop > > hence the metric to next hop would be in most cases a tie breaker. > > > > If metric to next hop is the same across both paths I see no > > reason to > > mandate any rules which would force different PEs to choose > the same > > path. If operator wishes to prefer one path then the other he > > will do so > > by applying local preference. > > > > The fact that you like to see all paths in BGP to be > selected as the > > same is not sufficient reason to mandate it on the clients. I > > see more > > value and no issue keeping them diverse especially since you are > > pointing out last step in best path selection. > > > > Cheers, > > R. > > > > > > > Again, if the tie breaker reaches step (f), > > > the client will use the BGP Identifier of > > > the RR it receives the path from to choose > > > its best. > > > > > > In BGP, we like all speakers to choose the same > > > path unless IGP metrics are different. > > > > > > With diverse-path, there is a possibility that > > > different speakers choose different paths even > > > if IGP metrics are the same. > > > > > > If the clients were to receive their paths > > > from the source speaker, they would choose the > > > same path at tie breaker (f). > > > > > > draft-pmohapat-idr-fast-conn-restore proposes > > > the Edge_Discriminator attribute to fix it. > > > > > > It may not be a problem. However, the path selection is > > > different than without diverse-path, therefore > > > the behaviour needs to be stated in the draft. > > > > > > The rule I stated will remove the inconsistency. > > > > > > -- > > > 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
