Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

[Brian Dickson <[e-mail]>]

On Fri, Dec 18, 2020 at 10:09 AM Enke Chen <[e-mail]>
wrote:

> Hi, Jeff:
>
> No, I am not assuming that packets are getting somewhere. The
> TCP_USER_TIMEOUT would work as long as there is "pending data" (either
> unacked, or locally queued). The data can be from the local BGP Keepalives
> or the TCP_KEEPALIVE.
>
> Thanks.  -- Enke
>
>
Actually, my point was not only about packets getting somewhere, but also
that the LOCAL implementation of the TCP stack should not be assumed to be
bug-free (in relevant ways).

Your response is still assuming that those mechanisms actually work 100%
reliably 100% of the time.

Yes, if the implementation works correctly, TCP_USER_TIMEOUT would work.
However, I'm saying the BGP code should not assume that is the case, and
put some guard-rails around the behavior.
The overhead of some small amount of checking, regardless of how it is
done, is likely quite low.

(If packets are flowing, as viewed by updates and/or keepalives being seen
from the peer, for example, it might not be necessary to invoke those
checks? Or the check might only need to be done every $INTERVAL, like every
minute or two.)

Brian


>
> On Fri, Dec 18, 2020 at 4:44 AM Jeffrey Haas <[e-mail]> wrote:
>
>> Enke,
>>
>>
>> On Dec 17, 2020, at 4:02 PM, Enke Chen <[e-mail]>
>> wrote:
>>
>> If one is paranoid that the BGP keepalive may not be generated locally,
>> then use the TCP_KEEPAVLIE option together with the TCP_USER_TIMEROUT
>> option. That would be more robust.
>>
>>
>> You're making the peculiar assumption that in broken situations that
>> packets are getting somewhere.  This is Brian's point.
>>
>> -- Jeff
>>
>> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>