On Wed, Nov 09, 2022 at 05:34:07PM +0100, Ondrej Zajicek via Bird-users wrote:
The whole issue is a bit silly, as it is a result of too many knobs that sometimes does not make sense. Setting keepalive independently of hold time, when hold time is negotiated (so consistency cannot be validated in config-parse time), is just bad design. It would be better if keepalive could be defines as a fraction of negotiated hold time.
Thinking about it, perhaps a better approach would be to just scale the keepalive timer based on (negotiated hold time / configured hold time). I was against this approach in the past as my reading of RFC 4271 is that the KeepaliveTime FSM attribute is initialized from the HoldTime FSM attribute at the beginning, and later the HoldTime is negotiated, but there is no mention of updating the KeepaliveTime (on the contrary, it uses phrases like 'initial value of KeepaliveTimer'). But now i checked RFC 4273, and it pretty much supposes there is keepalive scaling: Time interval (in seconds) for the KeepAlive timer established with the peer. The value of this object is calculated by this BGP speaker such that, when compared with bgpPeerHoldTime, it has the same proportion that bgpPeerKeepAliveConfigured has, compared with bgpPeerHoldTimeConfigured. Do you know whether other major BGP implementations use KeepAlive scaling, or not? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."