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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
