Suppose 2 clusters. Cluster 1 has 2 diverse path speakers, RR11 and RR12 and client C1. Cluster 2 has 2 diverse path speakers, RR21 and RR22. and client C2.
Suppose BGP Identifiers: RR11 = 11 advertises best RR12 = 12 advertises second best RR21 = 21 advertises second best RR22 = 22 advertises best If the tie breaker reaches step (f), C1 will choose second best and C2 will choose best. The rule I state will prevent the inconsistency. I assume that the IGP metric problem at the RRs has been fixed such that each RR plane sees the same IGP metric as its mates. -- Jakob Heitz. > -----Original Message----- > From: Robert Raszuk [mailto:[email protected]] > Sent: Sunday, March 27, 2011 3:26 PM > To: Jakob Heitz > Cc: [email protected]; IETF IDR > Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: > risk of inconsistent path selection > > > Exactly. So what is the problem within this thread which you > claim that > clients may "risk of inconsistent path selection" ? > > R. > > > This is standard BGP if the IGP metrics are equal. > > > > -- > > Jakob Heitz. > > > > > >> -----Original Message----- > >> From: Robert Raszuk [mailto:[email protected]] > >> Sent: Sunday, March 27, 2011 3:17 PM > >> To: Jakob Heitz > >> Cc: [email protected]; IETF IDR > >> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: > >> risk of inconsistent path selection > >> > >> Jakob, > >> > >> > To prevent clients in different clusters from choosing > >> > different bestpaths based on tie breaker (f): > >> > >> Can you restate what is the problem with the above ? > >> > >> Today clients would chose different best paths when IGP > metric to one > >> next hop is closest on one to NH1 and closest on the other to > >> NH2. And > >> this check happens well above step (f). > >> > >> How is this at all related to the diverse path draft like > the subject > >> could indicate ? > >> > >> Thx, > >> R. > >> > >> > >> > >>> Route selection tie breakers in RFC 4271 state: > >>> > >>> f) Remove from consideration all routes other than > >> the route that > >>> was advertised by the BGP speaker with the lowest BGP > >>> Identifier value. > >>> > >>> g) Prefer the route received from the lowest peer address. > >>> > >>> Suppose RR Planes use different BGP Identifier values. > >>> If they use the same BGP Identifier, a similar argument > >>> can be made for peer address. > >>> > >>> To prevent clients in different clusters from choosing > >>> different bestpaths based on tie breaker (f): > >>> > >>> 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. > >>> > >>> I'm not sure if this rule completely solves the problem. > >>> If not, then the "Edge_Discriminator attribute" proposed > >>> by draft-pmohapat-idr-fast-conn-restore may be required. > >>> Also, this would need to be applied before rule (f). > >>> > >>> -- > >>> 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
