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

Brian Dickson <> Thu, 17 December 2020 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 701E33A0FF0 for <>; Thu, 17 Dec 2020 12:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dqUk0XkogEyV for <>; Thu, 17 Dec 2020 12:24:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0F3D3A0FF2 for <>; Thu, 17 Dec 2020 12:24:55 -0800 (PST)
Received: by with SMTP id h6so156316vsr.6 for <>; Thu, 17 Dec 2020 12:24:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r/SF056eKf3g5cwWpGE7r4LRwAU+2l1kE57ofrLNpwU=; b=CzDnMEJ3zJUg5nf5D9jeYy+c42F5jO2xDZl5iJxa+f4TaB0QuTKwWT3KHpEyyvF9t6 Uo/Mfcgr/rwq9y9NbrgDWHO6L2ZvsAktaM2B7oTW2Ym5Kzja2oKeDuK9A8QgpkUlaIcA YQEilSemlSWk25pyiu90DwO8BSF5w1/PTkmCq8Wh1jF1SGpE6+HpZufuEcW0PyAv58/x 0PfvhCFxsZnuYFiHL8FB/Gekp43avtycw3vErWMSBZUvkBsYuj5Y4Lzifn12MH9DRUv4 wiK0QGDc1aqqTnPC89aly/5n/RUUNAN8PD+TnAW7jrRSbE9zLetFrzDRaBaOnDCursZC dB0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r/SF056eKf3g5cwWpGE7r4LRwAU+2l1kE57ofrLNpwU=; b=lU3MKIai7dA5YcnJLabU+YsefvBuysWSUHjwnI4/cRCfWyvRj1JtGt7i5FLGsp5a8x 8fU2e3jg8mcw+GTai4WYjVLEe1fzEWd1Q2T/iFF1D0J9l2ZZbgHSyH1m3kNbCbCxbWsO +0RApJAsK5uDv2s9hQQlPcIMqu0lCG1KwhYC9jJtgM8V5Z//VxtlXQPIdl8eSu5oMlYu a8Z+/sVOWCvEdK8oqPQnNbT/fqgh0r8dRfvkkVNMA/PQd5mR6LezKTnwme8WvF9Wevtq imxEXQqIo9f3SzXja5ip5z/eIGF+sGXkXcXZaMu2a4Qe6Q9c50XQ51e5i56DcFPGxPiM UiQw==
X-Gm-Message-State: AOAM5319VaE0GVJkpVVkOY1NVQDIihTH90rNaUnYt7a5cRm5QmPeGWhg btw8Y66ChAYE3QmB5k2ReRiTVWtFp/4tvw2vjtY=
X-Google-Smtp-Source: ABdhPJw0TV0UaITz+pOR2tyRcolYMddojRF2qFfmYv2KP3etYIqxeFOpIq/YgJKA3icmaypLYzj5/cZ+F3moiZb3HU4=
X-Received: by 2002:a67:2d84:: with SMTP id t126mr1014895vst.49.1608236694856; Thu, 17 Dec 2020 12:24:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 17 Dec 2020 12:24:43 -0800
Message-ID: <>
To: Enke Chen <>
Cc: Robert Raszuk <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000e969cf05b6aec819"
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: Thu, 17 Dec 2020 20:24:57 -0000

On Thu, Dec 17, 2020 at 11:49 AM Enke Chen <>

> Hi, Robert:
> The receiver is broken for not closing the session after the holdtime
> expires, and that certainly needs attention.
> However, the rational for trying to do something on the sender seems to be
> the following: as the session is broken and should have been terminated by
> the other side, but it's not, the sender would like to have a way that
> provides an "upper bound" for the session to be terminated
> deterministically at the transport layer.
> The TCP_USER_TIMEOUT option seems to be a good fit in this case.

I think this thread is suffering from "impedance mismatch".

There is a known issue where the actual TCP stacks of some routers are
buggy in ways that breaks things.

This proposal (TCP_USER_TIMEOUT) assumes that the local speakers' TCP stack
isn't buggy, at least with regards to the handling of that option.

I'm not opposed to using that option, but I don't think relying on that
exclusively is sufficient.

There is a layer issue, involving BGP protocol and TCP transport, where
transport and/or protocol issues (or both) are causing (or at least have
caused) global problems.

Having the BGP implementation be cognizant of the state of the TCP
connections, and handle behavior violations or boundary condition problems
expeditiously, is probably a good idea.

(The common term is "belt and suspenders", or perhaps "trust but verify".)

I.e. if the session is "broken", use all the available mechanisms in
increasing order of effectiveness (or extreme-ness) until the connection
dies, possibly with some grace periods in the escalation steps.