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

Jeffrey Haas <> Wed, 16 December 2020 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 134103A1110 for <>; Wed, 16 Dec 2020 13:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sE2Gp6hZWswh for <>; Wed, 16 Dec 2020 13:37:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 318233A110B for <>; Wed, 16 Dec 2020 13:37:58 -0800 (PST)
Received: by (Postfix, from userid 1001) id 4DDB91E356; Wed, 16 Dec 2020 16:55:20 -0500 (EST)
Date: Wed, 16 Dec 2020 16:55:20 -0500
From: Jeffrey Haas <>
To: John Scudder <>
Cc: Job Snijders <>, Robert Raszuk <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Dec 2020 21:37:59 -0000

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