Re: [Idr] WG LC for draft-ietf-idr-bgp-sendholdtimer-03 (3/23 to 4/12/2024) - Extended to 4/19/2024

[William McCall <[e-mail]>]

On Mon, Apr 15, 2024 at 8:32 AM Robert Raszuk <[e-mail]> wrote:

> Hi,
>
> Just for the record I do not support this WG LC.
>
> The proposed solution is not granular enough. While it is better
> than nothing, why to concentrate energy on a solution which may only react
> to stuck peer for hours (send buffer fill time when only keepalives are
> sent) and only cover subset of cases ?
>
> I am aware of at least one implementation of the TCP stack that is not
well architected to implement this as a feature. And it is widely used.

Today, draft-ietf-idr-bgp-sendholdtimer can be implemented on this stack
very easily and could see a reasonable solution to a problem that is proven
to have caused me problems in my network. Implementing TCP user timeout
logic would get a lot messier in terms of time-to-delivery. And I realize
that is not the overriding concern of IETF, but I can be selfish sometimes
:)

> We have proposed a TCP extension (which is already in the main kernel
> distro for a long time) which addresses the problem in a much more
> universal way.
>
> https://www.ietf.org/archive/id/draft-chen-idr-tcp-user-timeout-01.txt
>
> This draft proposes to use BGP KEEPALIVES or UPDATES to detect peer
> liveness while the proper way is to accomplish the same using TCP User
> Timeout.
>
> Of course some say - BGP folks do not always have freedom to access
> underlying OS TCP stack - that is true. But I would expect that the quality
> document going out of IDR WG would discuss all options so interested
> developer can choose (or check if his TCP stack already is fine) by for
> example merging draft-ietf-idr-bgp-sendholdtimer
> & draft-chen-idr-tcp-user-timeout
>

I support your draft as well as a separate doc. It's sensible, if a bit
more experimental than what is being proposed here. Mostly for the same
reasons that Mr. Haas has already brought up.

I don't support merging them. Too complicated and they're complimentary
processes that require some thought in a separate sense.

Would you be good with approaching it from two separate angles? I'd love to
work with you and Eric on it, if so.
-- 
William McCall