Hello, I have the same opinion. Silent saturation (with log). The goal is to have the same behavior on all BGP implementation.
Alexandre > On Dec 2, 2020, at 6:45 PM, Daniel Suchy <[email protected]> wrote: > > 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.
