On Wed, 25 Nov 2015, Daniel Walton wrote:
That step in bestpath is an odd one. Cisco originally put this in to
stop a form of MED churn. This was before we really knew what MED churn
was though so that step was added and then everyone forgot about it. A
few years later we found all of these other scenarios for MED churn
which were not fixed by 'prefer older'.
Interesting, thanks.
It's been quite a saga really. It's taken quite a number of clever people
looking at MED and BGP metrics generally over, at least, a decade and a
half to tease the problem apart, understand it and (eventually) describe
how to solve it generally. Such a seemingly simple little attribute, so
much fun. :)
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).
yep, when I floated the idea of using addpath for route-server I got two
requests offline:
* one person said they would need the RS to TX everything to its clients
* one person said they would need the RS to TX the bestpath from each
neighbor AS to its clients
The user has to configure a per-neighbor knob for us to advertise either
all paths or the bestpath per neighbor AS (by default we only send the
overall bespath). To satisfy that 2nd bullet we need deterministic-med
so that we know which paths are the bestpath for each neighbor AS.
Do they _really_ want the second case though? :)
Least, does it really need to be a DMED comparison? As we learned with the
rs-client feature, getting the RS to do algorithmically expensive work per
client leads to scaling issues, which may then put off the intended users
from using it. Then we're left with code that is mostly not used...
I mean, without DMED they can still get the neighbour-AS best-path, right?
Your add-path is then doing bgp_best_selection for each neighbour-AS
subset, and produces a result which wouldn't be wrong even, just not
deterministic (but, see #10 in bgp_info_cmp)?
Or?
I'm trying to understand why the DMED bit is important to the actual
selection, or kind of orthogonal.
That would be fine with me...I can't imagine someone configuring a knob that
introduces inconsistency.
Ok, so we're going to pin it to one or the other at least.
I'd still love to find a way to get rid of it though. The
bestpath-per-neighbour users might end up agreeing, if they understand the
algorithmic performance cost?
We could probably lessen the cost by sorting, instead of the combinatorial
pair-wise comparison. But, just not doing it at all would be even cheaper.
regards,
--
Paul Jakma, HPE Networking, Advanced Technology Group
Fortune:
Do not count your chickens before they are hatched.
-- Aesop
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
