Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

heasley <heas@shrubbery.net> Thu, 04 August 2022 18:50 UTC

Return-Path: <heas@shrubbery.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 09ACCC15C52C for <idr@ietfa.amsl.com>; Thu, 4 Aug 2022 11:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrTp8LsulXoh for <idr@ietfa.amsl.com>; Thu, 4 Aug 2022 11:50:18 -0700 (PDT)
Received: from sea.shrubbery.net (sea.shrubbery.net [129.250.47.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C460C15C50F for <idr@ietf.org>; Thu, 4 Aug 2022 11:50:18 -0700 (PDT)
Received: by sea.shrubbery.net (Postfix, from userid 7053) id 1BCC6394D6C; Thu, 4 Aug 2022 18:50:18 +0000 (UTC)
Date: Thu, 04 Aug 2022 18:50:18 +0000
From: heasley <heas@shrubbery.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Ben Cox <ben=40benjojo.co.uk@dmarc.ietf.org>, "idr@ietf. org" <idr@ietf.org>
Message-ID: <YuwU6hQK4ywdM5ho@shrubbery.net>
References: <CAOj+MME7XnW7kDXL4muh4Qp1UvabQ9amUoU0Sn3h2axqKzswzA@mail.gmail.com> <77F3E1F0-486F-47DF-ABE4-EFDB9C2FB6D8@gmail.com> <CAOj+MMGR4f3eLEDZY++1m4Lpo9joG4L9OrWbeF6kREn-9a9onA@mail.gmail.com> <c6e44213-7667-0f67-71a4-634411cd102b@foobar.org> <CAOj+MMFajL6E42WCzC0ZqrfSBZjU-0B=ZzmtvCRPkuMzU8z5QA@mail.gmail.com> <Yun6e5jSb0OYZGAX@shrubbery.net> <CAOj+MMFRJr=cs+5DVOp72BVn_j3NgANwNftyj=jRbdsvPpg-wA@mail.gmail.com> <CANJ8pZ9oNvd0CGEbOQQpeZ1Sf-=ctVy8yhD0XFK-qYiE08BZUA@mail.gmail.com> <CAL=9YSX-iXEOQrERA5M_ZbG68UmgacchdODk7uwT3p0ZjLgJow@mail.gmail.com> <CAOj+MMFTikXbAC81mU7SiUHFq==5y5k9cSMK91B5YGVfAQLEvQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMFTikXbAC81mU7SiUHFq==5y5k9cSMK91B5YGVfAQLEvQ@mail.gmail.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/McRvkJ6UiNwJSKvGs0GPaqDfovA>
Subject: Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 04 Aug 2022 18:50:19 -0000

Thu, Aug 04, 2022 at 06:23:58PM +0200, Robert Raszuk:
> So we are trying to drop a session towards the BGP peer who does not
> respect basic RFC4271 obligation to drop the session when HOLD TIMER
> expires. That to me is already marginal (read noise corner case).

I hesitate to mention this, but a case for it to ignore a lack of reading
KAs is that it has data that is readable - ie: there is data is in its
socket's receive buffer.  If a speaker is heavily loaded, such as a
booting RS, considering a non-empty receive buffer as requivalent to
"KAs received" seems an entirely legitimate way to manage resources under
load.

How the draft addresses such a case, such as recommended values,  seems
like something for post-adoption discussion.

> Then we worry that LINUX TCP stack may have buggy implementation of
> TCP_USER_TIMEOUT and instead of fixing it locally we dismiss this option.

It being buggy is irrelevant - it need not be buggy and is also something
that I can fix, which I can not fix the neighbor, only work-around.  The
draft should not concentrate on a particular implementation's facilities
to recognize the problem, different implementations do exist.