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

Jeffrey Haas <jhaas@pfrc.org> Wed, 16 December 2020 21:37 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134103A1110 for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 13:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE2Gp6hZWswh for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 13:37:58 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 318233A110B for <idr@ietf.org>; Wed, 16 Dec 2020 13:37:58 -0800 (PST)
Received: by slice.pfrc.org (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 <jhaas@pfrc.org>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: Job Snijders <job@sobornost.net>, Robert Raszuk <robert@raszuk.net>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20201216215520.GD24940@pfrc.org>
References: <X9PHRuGndvsFzQrG@bench.sobornost.net> <CAOj+MME4OHmoqJfzNQ4Tj6+wCd1kJVHPfJsDbk_+Xh8fh5G8Dg@mail.gmail.com> <6F7C5906-51A8-43C2-8AEC-3DB74CB9941F@tix.at> <1B4E7C9D-BBFE-4865-87F9-133ACE55D122@cisco.com> <22C381D0-2174-4828-A724-FD97B2FE0BCB@tix.at> <9D6268BD-C555-4B9A-A883-9B55EEB5D5DA@juniper.net> <91D9B9F7-0DBE-45E6-84D5-2E3D9F8C44A1@tix.at> <X9kweQ5EtTL7tOAM@bench.sobornost.net> <B6F84ED2-E673-4798-AF89-DFC25EC2CCBA@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B6F84ED2-E673-4798-AF89-DFC25EC2CCBA@juniper.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RiARGSqa8AfvMbMV6EHKpHik98s>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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