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
