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

[Jakob Heitz <[e-mail]>]

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.
 

> -----Original Message-----
> From: Robert Raszuk [mailto:[e-mail]] 
> Sent: Sunday, March 27, 2011 4:02 PM
> To: Jakob Heitz
> Cc: [e-mail]; IETF IDR
> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: 
> risk of inconsistent path selection
> 
> Hi,
> 
>  > C1 will choose second best and C2 will choose best.
> 
> I am sorry but each client will choose the best and backup path among 
> the paths it receives. And this selection are normal IBGP best path 
> selection. We are not really defining an AS wide path 
> ordering in this 
> work. All we are doing is distributing more paths to clients so they 
> could use it for backup or load-balancing purposes.
> 
> Are you saying that what RR considers as backup may be chosen 
> as best by 
> the client ?
> 
> That seems to me perfectly fine. Client has no need to choose 
> the same 
> path as the RR. Because the second path would be a backup path on the 
> client. With hop by hop IP lookup this is the reality today. With 
> tunnels of some sort this becomes completely transparent, but this is 
> different story and diverse-path does not require tunneling.
> 
> Even today RRs may choose different best path when they are 
> full meshed 
> and advertise different to each client. Then client is at his own 
> freedom to choose order of paths as he likes.
> 
> Moreover the same behaviour would be in add-paths. Among advertised 
> paths there is no ordering and clients can choose whichever order it 
> consider's correct.
> 
> Cheers,
> R.
> 
> > 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:[e-mail]]
> >> Sent: Sunday, March 27, 2011 3:26 PM
> >> To: Jakob Heitz
> >> Cc: [e-mail]; 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:[e-mail]]
> >>>> Sent: Sunday, March 27, 2011 3:17 PM
> >>>> To: Jakob Heitz
> >>>> Cc: [e-mail]; 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/grow
> >>>>>
> >>>>
> >>>>
> >>
> >>
> 
>