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:[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
