Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection

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:raszuk@cisco.com] 
> Sent: Sunday, March 27, 2011 3:26 PM
> To: Jakob Heitz
> Cc: grow@ietf.org; 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:raszuk@cisco.com]
> >> Sent: Sunday, March 27, 2011 3:17 PM
> >> To: Jakob Heitz
> >> Cc: grow@ietf.org; 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
> >>> GROW@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/grow
> >>>
> >>
> >>
> 
> 