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

[Job Snijders <[e-mail]>]

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://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac
> 
> 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://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=1942e41202aa5cc39dd8970ab62cd1b288277753
> 
> 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://mailarchive.ietf.org/arch/msg/idr/CS7VOx42V76RfGLmXhQqM8DyNjk/

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