Hi,

Thank you for your reply.

I believe I understand the original problem and how to overcome it very well. But my point is different.

In the original thread where you discussed this issue with Ondrej, there was the following proposal:

> "For example bird can check that the hold timer proposed by a peer is at least 2 times greater than the local keepalive timer as in the attached patch"

> "I think that rejecting session when hold timer is smaller than local keepalive (so it is clear misconfiguration), and just a warning when it is smaller than 2*keepalive would be a good approach."

(https://bird.network.cz/pipermail/bird-users/2022-April/016070.html)

And my point regarding minimum-hold-timer addresses exactly this. IMHO, it doesn't really make sense to compare local keepalive with remote holdtime and then reject the session for some reason. If you want to limit the value of holdtime that your router accepts, it makes more sense to set minimum-hold-timer for that, not keepalive.

For example, you could configure:

hold 30;

keepalive 10;

minimum-hold-timer 30;

And this won't let your peer set hold timer lower than 30. And this makes the behavior pretty straightforward.

Otherwise, with approach like "hold timer proposed by a peer is at least 2 times greater than the local keepalive timer", you end up with some obscure logic, so that people would have to go read the source code to understand why the session is not establishing.

ср, 9 нояб. 2022 г. в 13:34, Alexander Zubkov <green@qrator.net>:

Hi,

I think this "knob" is somewhat orthogonal. Because this limits the
possible values, but does not sets them. Currently you can set
keepalive and hold timers and BGP peers choose the minimum hold timer
among them. This setting is needed if you do not want you peer to set
some low hold timer for you.
But the original problem has other root. If you do not set keepalive
timer - it is calculated from negotiated hold timer, but if you set it
manually than it is fixed and if peer decides to use lower hold timer,
that can break the mechanics silently. The easiest option to
"workaround" it - is not setting keepalive timer by hand when you do
not control the peer. Than it's value will always be lower than the
hold timer (1/3 of it).
Of course if you apply the patch, than you can use the keepalive timer
to indirectly set the lower bound for the hold timer. But that looks
weird. So if there is a demand for "minimum-hold-timer" option, it is
useful by itself, IMHO.

On Wed, Nov 9, 2022 at 11:25 AM Serge G via Bird-users
<bird-users@trubka.network.cz> wrote:
>
> Hi,
>
> Not sure if it's still relevant, but I just wanted to propose another approach. Instead of comparing configured keepalive with the hold timer received from a peer, it might be more straightforward to add another knob, e.g. "minimum-hold-timer". (as on Juniper https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/minimum-hold-time.html; Nokia also has similar knob)
>
> Reason for this is that (the following is just my opinion) 'keepalive' only configures an interval for keepalive messages. And if we start using the value of keepalive timer to enforce some restrictions on peer's hold timer, this may be confusing.
>
> In other words, "minimum-hold-timer" would more clearly indicate our restrictions on hold timers. If I see "minimum-hold-timer 30" in the configuration, I understand that this device has some limitations. If I see "keepalive 10", it doesn't tell me anything about restrictions, only that this device will send keepalives every 10 secs.
>
> P.S. I haven't dealt with mailing lists before, so forgive me if I reply to the wrong thread. This is the thread I;m replying to: https://bird.network.cz/pipermail/bird-users/2022-April/016071.html
>
>