Sorry for being slow to respond....was busy eating turkey :)
On Thu, Nov 26, 2015 at 5:06 AM, Paul Jakma <[email protected]> wrote:
> 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. ;) ).
>
I forget the details but if you have two ebgp paths and the only difference
between them is router-id and you change bestpath based on that it is
possible to MED churn.
> 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?
We only do the "prefer oldest" check if both paths are external so
router-ids would have always been compared in the RR scenario, regardless
of the compare-router-id knob.
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.
More expensive yes, expensive to the point that it is an issue, not that we
have seen.
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)?
Why don't we do the sorting and single-pass through each set but keep
DMED? Nuking DMED is not an option IMO.
>
>
> 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?
>
True but I've never heard anyone complain about this scenario...if the only
delta is router-id most folks don't care I guess.
Daniel
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
