IETF Logo Mail Archive

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

Job Snijders <job@sobornost.net> Wed, 16 December 2020 19:39 UTC

Return-Path: <job@sobornost.net>
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 0C82E3A0E58 for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 11:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, T_SPF_TEMPERROR=0.01, UNPARSEABLE_RELAY=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 L-ma-K3D0ibp for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 11:39:11 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2853A0E53 for <idr@ietf.org>; Wed, 16 Dec 2020 11:39:10 -0800 (PST)
Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 39AD9601AE for <idr@ietf.org>; Wed, 16 Dec 2020 19:39:08 +0000 (UTC)
Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id c54d7045 for <idr@ietf.org>; Wed, 16 Dec 2020 19:39:06 +0000 (UTC)
Resent-From: Job Snijders <job@sobornost.net>
Resent-Date: Wed, 16 Dec 2020 19:39:06 +0000
Resent-Message-ID: <X9piWm5YGmAyR8Qq@bench.sobornost.net>
Resent-To: idr@ietf.org
Date: Wed, 16 Dec 2020 19:35:56 +0000
From: Job Snijders <job@sobornost.net>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: Claudio Jeker <cjeker@diehard.n-r-g.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <X9phnLQWPIVrcjwo@bench.sobornost.net>
References: <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> <CAOj+MMFySPXpE8QxcO+7szKzQ78faQASYKnBUYg_h_aLd=P4Lg@mail.gmail.com> <BYAPR11MB3207412804697588E4AA3F03C0C60@BYAPR11MB3207.namprd11.prod.outlook.com> <20201216093614.GI68083@diehard.n-r-g.com> <4E9BEA12-998A-4AD1-B342-4F26AA6EBA69@cisco.com> <20201216174319.GM68083@diehard.n-r-g.com> <BYAPR11MB320759EE6ABC8AB863BC1838C0C50@BYAPR11MB3207.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BYAPR11MB320759EE6ABC8AB863BC1838C0C50@BYAPR11MB3207.namprd11.prod.outlook.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-8zc_d92KzZ_I2a2gvz8dbWDyME>
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 19:39:16 -0000

Jumping in to pick a nit about perceived asymmetry and practical
reality.

On Wed, Dec 16, 2020 at 06:50:51PM +0000, Jakob Heitz (jheitz) wrote:
> There is no evidence of any problem with its received routes, only
> with the routes it sent to the stuck peer. 

* The routes received from the stuck peer might block a healthier route from being used

* The routes to be sent towards the stuck peer might contain routing information for healthier routes for destinations the stuck peer is advertising.

Both the local node and the stuck peer are operating on stale routing
information. Even though the signalling observably is stuck in 'only
one' direction, the staleness applies to both directions because BGP
nodes converge together: a problem in 1 direction is a problem for both
directions, for both nodes.

Kind regards,

Job

v2.23.0 | Report a Bug | By Email