On Wed, Nov 23, 2011 at 09:13:17PM +0400, Alexander V. Chernikov wrote:
In case of always-compare-med traffic flow became suboptimal and fixing this (due to large number of peers) will significantly increase number of such hacks in route-maps on border routers.
Yes, always-compare-med without normalization (or just zeroing) of MEDs on border routers does not make sense.
I do not insist to make RFC4271 behavior the default one, but the ability to turn this on is (IMHO) mandatory.
It is supported for example by Quagga and Juniper. The latter one uses deterministic MED by default.
But as you already wrote the patch i could look at it.
It will be great. This version is rather hackish.
The patch IMHO does not work. Suppose this example: Route A - neigbor ASN 1, MED 100, IGP 30 Route B - neigbor ASN 2, MED irrelevant, IGP 20 Route C - neigbor ASN 1, MED 200, IGP 10 (local pref and path lengths are same) When just B and C are in the table, C is chosen (by IGP cost). When A appears later, B should be chosen according to RFC 4271 (C is removed from consideration by less prefered MED, ties are broken by IGP cost), your patch chooses A (because rte_better says A is better than C, so it is handled as the first case in rte_recalculate()). BTW, this behavior (that the new route is not selected, but changes ordering between two already present routes) is what IMHO made the RFC 4271 behavior crazy.
BTW, do you have some kind of IM? or IRC ? Or you prefer ML discussions?
I prefer ML discussions (and don't use IM). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."