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

[Jeffrey Haas <[e-mail]>]

On Tue, Dec 15, 2020 at 10:55:54PM +0000, John Scudder wrote:
> It came up earlier in the discussion that HOLDTIME serves at least two
> different purposes: neighbor liveness detection, and as a metric of BGP
> protocol health. If the proposal is adopted, the former use is potentially
> problematic in deployments where the hold time gets cranked down to a very
> small number.[*] Of course, you can argue that this is a bad use of the
> BGP hold time, and that the operator should use BFD instead, but sometimes
> this isn’t done, for whatever reason. 
> 
> Because of this sad state of affairs, it seems to me that if we adopt this
> proposal, there should be a new hold time introduced, call it TX_HOLDTIME
> if you like. It could have the same default value as HOLDTIME, but (and
> this is the important bit) would not inherit any non-default value of
> HOLDTIME, it would have to be explicitly changed separately.

+1 to this.  Don't overload holdtime (negotiated) with the transmit blocked
semantic.  As noted elsewhere in the thread, a new timer that perhaps takes
hints from tcp session state (a layer violation! but not the first we'd
have) is sufficient to trigger a Stop event in the FSM.  

And that said, we'd likely need an Ungraceful Stop for RST to avoid gumming
up lingering tcp state.

-- Jeff