Issue with unsigned integer LOCAL_PREF
Daniel Suchy
danny at danysek.cz
Wed Dec 2 18:45:36 CET 2020
Hello,
commercial BGP implementations (Juniper, Nokia, Cisco) usually
implements silent saturation based on your point (2) in such cases,
Quagga does this too (see route_value_adjust function [1]; which handles
these overflows). It's not limited to locpref, also other attibutes can
be modified by addition/subtraction.
I suggest to follow this practice also in Bird code, as this behavior is
commonly expected here.
Length of relevant attributes are defined in RFC and I don't expect any
move from 32b to 64b integers here - as this will break compability
between speakers.
- Daniel
[1]
https://github.com/Quagga/quagga/blob/88d6516676cbcefb6ecdc1828cf59ba3a6e5fe7b/bgpd/bgp_routemap.c#L148
On 12/1/20 5:51 PM, Ondrej Zajicek wrote:
> There are at least three reasonable behaviors for fixed-range
> arithmetics:
>
> 1) silent overflow (current behavior)
>
> 2) silent saturation (as you suggested)
>
> 3) explicit (logged) error
>
> Not really sure which is better. (1) is likely least astonishment (for
> fixed-range), (2) is most useful when overflows are intentional, (3) is
> most useful when overflows are unintentional.
>
> I have minor preference for (3), but no strong preference either way to
> change anything. Also note that in cases when fixed-range attributes have
> lower range than 32bits (i.e. 16bit preference and 24bit ospf_metrics),
> we generate explicit error on overflow on assignment.
>
> Or perhaps we should just move to arbitrary-range integers .. many new
> RFCs already use 64bit attributes anyways.
More information about the Bird-users
mailing list