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

[Jeffrey Haas <[e-mail]>]

> On Apr 15, 2024, at 2:44 PM, Robert Raszuk <[e-mail]> wrote:
> 
> Hi Jeff,
> 
> > My suggestion to you is to rethink whether your objection is "this doesn't
> > work" or "this is an incomplete solution". 
> 
> I thought I already expressed myself that I think the latter. 

Thanks for confirming.  This was to help clarify that you find specific technical issue with the draft in WGLC, only that the draft in WGLC doesn't address a portion of the problem space.

> 
> > Support for tcp user timeout is nowhere near pervasive enough to try to
> > force this as the only option to address the issue. 
> 
> If I would go for  "TCP User Timeout" as the only option I would not suggest including in the current subject draft a paragraph or a section simply listing the alternative. It does not even need to be a formal merge .. the current author list of draft-ietf-idr-bgp-sendholdtimer could stay intact. 
> 
> Or if you think this could be dangerous when "excessively short timer values can lead to unstable BGP when there's CPU congestion that delays timely acks" then subject draft should say perhaps even as normative MUST to either keep it to 0 for BGP connections or set it to safe value ("safe" being perhaps reasonably long). 

Fundamentally, anyone who's done BGP for a length of time understands the behavior in terms of blocked sockets.  Nothing here is deeply controversial, only that it's an incomplete solution for the "slow fill" scenario.

As I noted in my prior response, the behaviors of the TCP user timeout as applied to BGP aren't well understood.  Thus, it's inappropriate to recommend the feature as a specific mitigation in the current document.  With better study, the user timeout document could also proceed in IDR.

If you think the "slow fill" scenario is inadequately addressed in the sendholdtimer document, feel free to suggest updated text to the authors and the Working Group.

Thanks.

-- Jeff