bgp keepalive & hold timers

[Ondrej Zajicek]

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 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."