Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[Robert Raszuk <[e-mail]>]

Martin & Mikael,


> > My main issue with what is proposed here is that it completely ignores
> TCP
> > keepalives.
>
> What would the draft do to TCP keepalives? If the receiving application
> has stopped reading from the socket then TCP keepalives will still run as
> normal.
>

I am not sure I follow ... Isn't the objective here to detect when sender
(your bgp peer) is not sending ? Or you want to also detect local "reading
from socket" issues and RST BGP session ? Really ?

> Of course one may say ... Oh if I configure long enough timers we will be
> > fine - and that is maybe true - maybe SendHoldTimer will be just an extra
> > fuse.
>
> That seems to be what is proposed, yes.
>

Indeed.

But I am mainly worried that what is proposed here is to smash the session
because applications have problems on possibly healthy TCP connection.

See use of zero window is a very valid case in TCP.

Of course everything depends on the duration hence concern about timers.

But what was not answered was why to invent new "overlay" timer if TCP USER
TIMEOUT does exactly and much better what is being required here.

Sure there were bugs in the past, but should we get blocked by history of
TCP implementations in linux kernel ?

Thx a lot,
R.