Jakob,
I don't want to argue the importance of the tie breaker
rules (f) and (g). They may or may not be important.
Just because the above steps are in place there is no guarantee even
today that all bgp speakers within the domain will declare the same very
path as best. Especially RR clusters as not all RR clients clearly need
to be connected to all clusters. That is also why RRs were recommended
to be in the data plane topologically in the path between the rest of
the network and it's clients.
My point is that diverse-path breaks them and
my rule fixes it. Here it is again:
Diverse-path does not break them. It only allows for more paths to be
distributed to clients.
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.
Sorry but this rule is not applicable to your problem in the first
place. Your problem was described to be seen across RR clusters.
Moreover .. the same RR running single BGP process may serve both set of
clients: .. those interested in best path, those interested in 2nd best,
those interested in Nth best and so on. And all implementations I am
familiar with have single BGP Identifier for any given BGP speaker.
R.
-----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
