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

[Enke Chen <[e-mail]>]

Hi, Job:

Thanks for bringing up the stuck BGP issue, which has led to the unearth of
the Linux kernel bug and also the fix.

Here are my comments regarding your follow-up questions:

On #1: It makes sense to me. The value for TCP_USER_TIMEOUT associated with
the BGP session should be made configurable, though.

On #2: My recommendation is to use Code 4 (Hold Timer Expired), and
introduce several subcodes something like:
            1) Hold-timer expiration - Received.
            2) Hold-timer expiration - Sent.
            3) Hold-timer expiration - transport timeout.

Regards,   -- Enke

On Wed, Jan 20, 2021 at 11:09 AM Job Snijders <[e-mail]> wrote:

> Dear Enke, group,
>
> On Wed, Jan 20, 2021 at 10:20:47AM -0800, Enke Chen wrote:
> > Here is an update on the TCP_USER_TIMEOUT option in Linux for the
> > zero-window case:
> >
> > 1) There is a bug in the code, and a fix has been committed to Linux's
> > networking git:
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_netdev_net.git_commit_-3Fid-3D9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac&d=DwIBAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=YwLHSMUV8lCZF0-sG2EqV_NqDMsN_NK2NwDb3tQ6mMc&s=wJGNu2HSsZGTN8hE4F3nm5mHYno1xfnPYEOvXUbWUXU&e=
> >
> > 2) A patch has been committed to Linux's man-page repo to clarify that
> the
> > option also covers the case that buffered data remain untransmitted:
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_docs_man-2Dpages_man-2Dpages.git_commit_-3Fid-3D1942e41202aa5cc39dd8970ab62cd1b288277753&d=DwIBAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=YwLHSMUV8lCZF0-sG2EqV_NqDMsN_NK2NwDb3tQ6mMc&s=8x1m3aoMVKYAwmKwGXCPL4vlWRH45CKcHnqwCbLtHnE&e=
> >
> > Thanks.   -- Enke
>
> Wow, thank you, this is a welcome development!
>
> Two follow-up questions for the group:
>
> 1) Should the *default* BGP HoldTimer value be the input to mechanisms
>    such as the Linux TCP_USER_TIMEOUT option? (a 'Send Hold Timer') Earlier
>    on in the thread Tony Li suggested "For robustness, it makes sense that
>    the transmitter also close the connection."
>    ref:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_idr_CS7VOx42V76RfGLmXhQqM8DyNjk_&d=DwIBAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=YwLHSMUV8lCZF0-sG2EqV_NqDMsN_NK2NwDb3tQ6mMc&s=RkMmOhnl1QTDLAEAO4UFa8h5mGazaiU2sLSlj9oJIjw&e=
>
> 2) Should we request IANA to assign a new "BGP Error Notification Code"
>    for the purpose of locally correctly logging the reason the remote
>    peer was shutdown, or also use Code 4 (Hold Timer Expired) for this
>    case?
>
> John Scudder brought up that in the current version of the FSM this
> would be a 'ManualStop', but I'd like to explore the option of an
> automated termination of the connection (until IdleTimer expires).
>
> Kind regards,
>
> Job
>