IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Wed, 08 March 2023 19:14 UTC

Return-Path: <robert@raszuk.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 20060C1526E9 for <idr@ietfa.amsl.com>; Wed, 8 Mar 2023 11:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 WfChQrdghllU for <idr@ietfa.amsl.com>; Wed, 8 Mar 2023 11:14:30 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 64CBFC1522A0 for <idr@ietf.org>; Wed, 8 Mar 2023 11:14:30 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id f11so16385513wrv.8 for <idr@ietf.org>; Wed, 08 Mar 2023 11:14:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1678302868; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KCbmlj11VphkNW5OPtD9GsNZoinvlqRoVByTY+cjwCw=; b=fX//KBP2s8DtjcP0SeNIv/Rc/MfnsoZWE/3WoF2R073lPYzedzmnQwAhxoEODGYxmW ME3adR0e2KjWtuWfZf8n9rgkGRVSTLGGo4toD9KR+NlvxOZHXMzY3tl29nwGeuCbjO9X fJlt+F/h//vSgGvgxAv+976YkYYYcIO80tDAptFUcW1wZ/VqwXf9adMMrjPIBQJwL89Q qmTh/YvBiIGD58GW4eZ4h3fCV2EH/xT6nw6YBzYOCDR7rCBVRgZQgdP8+3ZjpAKY7p00 x19SfOc6OH1ec499ItrAoUqjvmn63+nLfQIPbuTzLbM9KDUi3RHGIana8/Dc/Aumam/S FW7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678302868; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KCbmlj11VphkNW5OPtD9GsNZoinvlqRoVByTY+cjwCw=; b=F2mIorPBYk/Yg9EZVn8IPtdLjMvZcTKLgxfn/BuwfzM5UvgCvgHmmcHgJQVoLzTBkJ GuS58vdz3pwC7SzQqeUiNrbWJsZQLe+JrLE47wzYpUfJJt62F6Mf0LA6Mgm27tfl2+3u drVlpS/kG0R9hfIHPDNzQ3hR+d4O78bIGelq2S04L19QhkLmsEgPJIEqnNmIISmdogua FdVFLywzs/Zsi4CSe9g4iUX2bu9JsdUF4qYbkWUCMtFE4/pfTZ6Ogksn/z+ZX/LFR7Dw i/OlnXkzuNlce0X/0tyNIZH5h9MtugFizLCxYxnitWw8eh5odsaNAzEGndhBPt/6U/hr cL5g==
X-Gm-Message-State: AO0yUKVhfFJmTn1pepiA4CMpYOY71rsSlir5GQOuYcNG7jIHPazF1B3I 8mpE8ySuolEOJ+RzEBGbC9QpWg9ro8y3pvBKyrAw7w==
X-Google-Smtp-Source: AK7set/8MmW2jeKa3bcvWD5d6XBHTSvp3gc/4civLYntAh5MKzYsorcRqeTU47iCaCQOFjgukE6Ph/BUOHE7CoCwsJ8=
X-Received: by 2002:a5d:46c8:0:b0:2c7:139f:38c0 with SMTP id g8-20020a5d46c8000000b002c7139f38c0mr4254779wrs.6.1678302867948; Wed, 08 Mar 2023 11:14:27 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR08MB4872FD426205CAC6F82D22BEB3AD9@BYAPR08MB4872.namprd08.prod.outlook.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> <alpine.DEB.2.20.2303071107360.2636@uplift.swm.pp.se> <3caaea46-cc66-f084-ec9b-98783d6daa49@foobar.org> <CAOj+MME=-drWX_1=9T8jqBGvEfwB59PmjLoh65i8wvdppKFKYg@mail.gmail.com> <alpine.DEB.2.20.2303071224040.2636@uplift.swm.pp.se> <CAOj+MMFc29DOAL6QK3u9gzPBQPv3wRdhTRHRPD_1ABebtuX0=w@mail.gmail.com> <alpine.DEB.2.20.2303071246590.2636@uplift.swm.pp.se> <DB2B7372-D021-4E86-AF83-C6A55EF72D75@pfrc.org> <alpine.DEB.2.20.2303081108250.2636@uplift.swm.pp.se> <9505159A-F31F-4C1C-84BB-C9A2E7E46ED4@pfrc.org> <alpine.DEB.2.20.2303081757460.2636@uplift.swm.pp.se> <8B30B017-295F-4D4E-B8EA-FF0E15471F47@pfrc.org> <5085ba88-8af8-93d2-1fd4-e990a3abe9b9@foobar.org>
In-Reply-To: <5085ba88-8af8-93d2-1fd4-e990a3abe9b9@foobar.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 08 Mar 2023 20:14:16 +0100
Message-ID: <CAOj+MMHUeMC7wYC9ihTozTGL0Fn9v0nU4JBWkKkhjtY+6FierQ@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Cc: Jeffrey Haas <jhaas@pfrc.org>, idr@ietf.org
Content-Type: multipart/alternative; boundary="00000000000045330c05f6685616"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/d3w4bMa3PC21NTb5eQ1ImnGUs0s>
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: Wed, 08 Mar 2023 19:14:34 -0000

Hi Nick and all,

I was trying to explore options on what we can do today to manage the case
you are describing.

Well it seems that there could be a completely different alternative. As we
all know each implementation maintains today a counter of (at least BGP
UPDATE) messages sent to each peer.

So using your favourite choice of protocol for telemetry you could write
few lines of python script and get those counters every say 10 min. Then
simple comparison easily shows which peer is stuck and where some
additional action is needed to take place without even bringing the session
down by the router.

That counter could actually be sent as INFO to syslog. Implementation could
get smart and could send N minutes delta of messages sent per peer. I fact
I do see that such information could be already useful beyond detecting a
"stuck peer".

And I am not trying in any way to dismiss the current draft. At min I would
like to see added to the draft "WARNING ONLY" option.

Best,
Robert


On Wed, Mar 8, 2023 at 7:42 PM Nick Hilliard <nick@foobar.org> wrote:

> Jeffrey Haas wrote on 08/03/2023 18:35:
> > Does that solve the entirety of this problem?  No.  And that no is
> > why I'm not presenting the timeout as "this is THE SOLUTION to the
> > problem".  At best, it's a useful tool in helping out.
>
> for sure it's a workaround for implementation bugs, but zooming out, it
> helps in two separate ways: 1. resolving symptoms and 2. pointing the
> finger at the source of the breakage. Both these things are
> independently worthwhile.
>
> Nick
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email