On Wed, 25 Nov 2015, Daniel Walton wrote:
On the (non-deterministic) 'oldest' test. Should we kill that
too then? I'd be fine for making it do the remote-ID check (i.e.
making COMPARE_ROUTER_ID unconditionally always the case).
I wouldn't, if we do we may have users start hitting MED churn.
Hmm, but if we're getting to the Remote-ID checks then IGP and MED have
already been passed and not chosen a preference? After that we're either
down the "select oldest" code-path or the "select on remote-IDs"
code-path.
The former is only locally deterministic, but not deterministic across
hosts.
The latter should totally order the paths, and reliably always select one
path, across hosts, according to the peer injecting it into iBGP, or the
eBGP peer it was received from.
Is that right?
Wouldn't the latter be more preferable?
With the latter, I /know/ ahead of time what my BGP will converge on. With
the former, it could be completely unpredictable, differing from day to
day on arbitrary factors, inc. the phase of the moon (don't laugh - your
servers could be on a grid using tidal hydro-electric power, supply phase
and freq could differ slightly depending on the tides, maybe affecting
timing of things. ;) ).
Also, Cumulus wants to sort of raise cluster-list length check, because
you had topologies where everything was selecting the same way by
remote-ID. That meant COMPARE_ROUTER_ID must have been enabled?
Do they _really_ want the second case though? :)
Their logic was why serve two paths from ATT, just pick the bestpath
from ATT and serve that one. Seems logical to me :)
But it does mean having to do N sets of best-path comparisons, where N is
the number of neighbour ASes. Ok, I imagine often each set will be just 1
path (only 1 peering to that AS), and that'll be cheap. However, where
it's cheap (each set of N tends be 1 in size), it's also "useless" in the
sense it produces same result as send-all.
The more the "|N| tends to be 1" isn't the case, the more expensive this
gets. The cases where this is most useful to clients will be the cases
where it is the most expensive to do centrally.
Least, does it really need to be a DMED comparison?
Technically no, we just need to know what the bestpath is per
neighbor-AS but DMED figures this out for us so we take advantage of
that. Without DMED we do not have a code path to compute the bestpath
per neighbor-AS.
Aha. Ok. Got ya now.
So, we could equally still nuke DMED, and then just do the
best-neighbour-as-path in the most efficient manner (i.e. sort the paths
first and do a single-pass through each set, instead of comparing across
every combination)?
Today no, because without DMED we wouldn't calculate what the bestpath per
neighbor-AS is.
I will help with a sorted version of best-neighbour-as-path, if it means
we can get rid of DMED :).
I don't think it is something we could chop...we can't really say "the
only option for our bestpath algorithm is non-deterministic". Agree
100% it could be made more effecient.
Hmm... If we don't make COMPARE_ROUTERID the default, it's not
deterministic anyway (other than in a trivial local sense) - regardless?
regards,
--
Paul Jakma, HPE Networking, Advanced Technology Group
Fortune:
IF I HAD A MINE SHAFT, I don't think I would just abandon it. There's
got to be a better way.
-- Jack Handley, The New Mexican, 1988.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
