Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

Claudio Jeker <cjeker@diehard.n-r-g.com> Tue, 07 March 2023 09:50 UTC

Return-Path: <cjeker@diehard.n-r-g.com>
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 52957C14CE4D for <idr@ietfa.amsl.com>; Tue, 7 Mar 2023 01:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 0WGP6fXAyOfH for <idr@ietfa.amsl.com>; Tue, 7 Mar 2023 01:50:04 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C83C14CE36 for <idr@ietf.org>; Tue, 7 Mar 2023 01:50:03 -0800 (PST)
Received: (qmail 38516 invoked by uid 1000); 7 Mar 2023 09:50:01 -0000
Date: Tue, 07 Mar 2023 10:50:01 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, Job Snijders <job=40fastly.com@dmarc.ietf.org>, idr@ietf.org
Message-ID: <ZAcIyb55+oSFdNws@diehard.n-r-g.com>
References: <BYAPR08MB4872FD426205CAC6F82D22BEB3AD9@BYAPR08MB4872.namprd08.prod.outlook.com> <AM7PR07MB6248673BB25E0C0BCDBEE480A0B69@AM7PR07MB6248.eurprd07.prod.outlook.com> <CAOj+MMHF9G5-CmGPJpWja=1kgBrV=EYtzyhQr9La1722=D+ugA@mail.gmail.com> <m2edq1ac7s.wl-randy@psg.com> <ZAZSyywxxg0HkaDw@snel> <CAOj+MMGiB8iiqKbj40kZsSFAQXCQ+baGQWuA7oQ1D0qF5aygeQ@mail.gmail.com> <alpine.DEB.2.20.2303070725390.2636@uplift.swm.pp.se> <CAOj+MMGUfxd1LLta9=_HU+uMKcbVVE6ijkG84-ST0LDo3m2MYQ@mail.gmail.com> <alpine.DEB.2.20.2303070953000.2636@uplift.swm.pp.se> <CAOj+MMF8gELjxXB=kmn3eTu8X96vP7ueOTSA6Q+V_086wfO=NQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMF8gELjxXB=kmn3eTu8X96vP7ueOTSA6Q+V_086wfO=NQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Euj-6l12fkbvcG8r2eRf8VTZ3qs>
Subject: Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)
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: Tue, 07 Mar 2023 09:50:10 -0000

On Tue, Mar 07, 2023 at 10:20:41AM +0100, Robert Raszuk wrote:
> >
> > This draft is trying to detect that the receiver isn't reading from the
> > socket but still sending valid BGP keepalives etc.
> 
> 
> But we discussed this ... If network is stable and you are only putting
> keepalives say every 60 sec it will be hours before the socket buffer get's
> filled and you get first notification about it to local BGP process.
> 
> How is the solution presented in this draft helpful ?

In a perfect world there is no need for this. In a perfect world there is
no need for a lot of things because everything always works.

The goal here is to detect the one system among many thousands that
missbehaves. It is the safety valve to trigger before the issue becomes
too big to result in meltdown. It is not pretty, it is not prefect but it
damn sure works, every time, for many reasons. This is what engineering is
about, a solution that is simple, works and ensures that the problem does
not grow out of hand.

Yes, the detection requires the buffers to fill up, but that is fine. If
there is a lot of UPDATE traffic the event happens sooner. If there
is no UPDATE traffic at all then it matters less that it takes more time.
The systems are mostly in sync anyway.

-- 
:wq Claudio