[PATCH] bgp deterministic med

[Ondrej Zajicek]

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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20111124/fb9d0394/attachment-0001.asc>