> > 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. > 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? :) > Their logic was why serve two paths from ATT, just pick the bestpath from ATT and serve that one. Seems logical to me :) 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. > 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? Today no, because without DMED we wouldn't calculate what the bestpath per neighbor-AS is. > 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. If we had a code path that computed the bestpath per neighbor-AS without using DMED then the addpath-tx-bestpath-per-AS feature could function without DMED. It did not feel worth it to code such a code path though since DMED should be enabled anyway. > 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. 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. Daniel
_______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
