On September 24, 2018 10:00:05 AM GMT+02:00, Kenth Eriksson
<[email protected]> wrote:
>On Fri, 2018-09-21 at 15:52 +0200, Ondrej Zajicek wrote:
>> CAUTION: This email originated from outside of the organization. Do
>> not click links or open attachments unless you recognize the sender
>> and know the content is safe.
>>
>>
>> On Fri, Sep 21, 2018 at 11:58:41AM +0000, Kenth Eriksson wrote:
>> > So the preference value in BIRD is not the same as administrative
>> > distance? I believe both Juniper and Cisco treats lower preference
>> > value / administrative distance value as a more preferred route.
>> >
>> >
>> >
>https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-default-route-preference-values.html
>> >
>> > Is preference value inverted in BIRD?
>>
>> It has same position/usage as administrative distance in
>> Juniper/Cisco,
>> but it is inverted (lower is better) relative to them.
>>
>> Generally, for property called 'metric' or 'distance' it makes sense
>> that
>> lower is better, while for 'preference' it makes sense that higher is
>> better, it this sense Cisco and BIRD have it in natural way, while
>> Juniper
>> has it inverted.
>>
>
>I believe Cisco uses administrative distance, which is inverted from
>how BIRD has defined its preference value. This wiki article has a
>table for Cisco AD.
>
>https://en.wikipedia.org/wiki/Administrative_distance
>
>I still think BIRD confuses a user here (at least me). Consider the
>following route in BIRD;
>
>172.20.4.41/32 unicast [ospf1 2018-09-21] * I (110/50)
>[172.20.4.41]
> via 172.20.4.41 on p1-1-1-1-2
>
>The preference value is 110 and higher is better. The OSPF metric is 50
>and lower is better. If BIRD were to use administrative distance
>instead of preference, then you know that lower is always better.
BGP LOCAL_PREF is the higher the better. There is no worldwide consensus, even
in BGP there is MED which is the lower the better. We might even vote what is
better, whether the lower or the higher value.
So the original developers of BIRD wisely chose one of these two approaches. I
don't know whether they had long discussions before or they just wisely flipped
a coin. I don't even know how this was solved in Cisco in 1998 and whether they
knew it and did it as a kind of strange vendor lock in or whatever else.
I don't think that the development time is worth the outcome. Taking into
account that there are many users who would need to change their filters
because of this backwards incompatible change, it is an utter nonsense to ever
do it.
Showing 110/50 is confusing, anyway, we can show it in a better way to not
confuse the user. Could you please suggest a better format or even send in a
patch? This is quite easy to change in ospf_get_route_info() in file
proto/ospf/ospf.c
We also don't have the keyword AD in our docs so it may be a problem for people
coming from Cisco. If you could send a docs patch (doc/bird.sgml) to mention it
and point to the preference, you're also welcome.
>Any plans to support AD?
Not at this moment. This feature would be redundant to preference, wouldn't it?
Maria
