IETF Logo Mail Archive

Re: [Idr] BGP Message level ACKs

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 10 March 2023 09:34 UTC

Return-Path: <swmike@swm.pp.se>
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 D80E7C1BE899 for <idr@ietfa.amsl.com>; Fri, 10 Mar 2023 01:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 (1024-bit key) header.d=swm.pp.se
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 qAlSfcOAu6c8 for <idr@ietfa.amsl.com>; Fri, 10 Mar 2023 01:34:05 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF4BC1BE894 for <idr@ietf.org>; Fri, 10 Mar 2023 01:34:05 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 53FBDAF; Fri, 10 Mar 2023 10:34:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1678440841; bh=AqABFmPMX2R9rOjqW3F+/KpBWXC2uXgPZIJw0hux3Vo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=suHOE9f/+KLkrWGuqMrHU97md8V6MPJ6UCq9MR88ozLs54XMoBp3IvsT/ZL1cMzm4 3s9YLoeuKzeBJ4r7iA/lhhSIPwNRJzkz+ooHH5E2nKoHxRw/33QsnkH1bIEIufzthN 1il0Sd7UWX/Cyc9+RDD1kYxGTw1P4obk4fG/AJ6w=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 502219F; Fri, 10 Mar 2023 10:34:01 +0100 (CET)
Date: Fri, 10 Mar 2023 10:34:01 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Robert Raszuk <robert@raszuk.net>
cc: Claudio Jeker <cjeker@diehard.n-r-g.com>, idr@ietf.org
In-Reply-To: <CAOj+MMFQjc0K9dBji+Y2DSkZsuuEwgRxNYee+0pmKOzD9iL9pQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2303101028540.2636@uplift.swm.pp.se>
References: <CAOj+MME+xOzrA3e1CKmHR2JC+fiWkV4LinuL5ovA3L0tRWORRg@mail.gmail.com> <45816498-6F09-4135-ACB4-6E51683001C7@pfrc.org> <CAOj+MMFaJViRnRqwaLXHsBbcm6g5XtUuc5kh71ScZ9OKSoBNZw@mail.gmail.com> <CA+wi2hMjjPepoPnqUu0aMH4OtkezrC+sEV7YsmO92NnG-8+Q8Q@mail.gmail.com> <CAOj+MMEjBfdVK_uJ_B4CHr5suG0Zf7CSukqywTofkDMbimFEcA@mail.gmail.com> <CA+wi2hO0e5b7R49j9giz0bxF6d1EWddH+rYG7cSjMM4aSri49g@mail.gmail.com> <CAOj+MMH_3nwoyDE7GxNSa+fLPO2VD+SWCiGxmCem0s74-E17Ww@mail.gmail.com> <ZAoIpXq8Z1vKU0g3@diehard.n-r-g.com> <CAOj+MMFQjc0K9dBji+Y2DSkZsuuEwgRxNYee+0pmKOzD9iL9pQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/D9hnltjLSy3XUOX4Yj4fg3npB_I>
Subject: Re: [Idr] BGP Message level ACKs
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: Fri, 10 Mar 2023 09:34:09 -0000

On Thu, 9 Mar 2023, Robert Raszuk wrote:

> Simplicity should not be killing usefulness.

... and perfect shouldn't get in the way of good.

Sendholdtimer is incrementally deployable, local-only (doesn't require 
peer to do anything), and thus makes things better immediately after 
deployment.

Going down this road of BGP level ACKs etc is 1-2 magnitude larger change 
(if not more), will take a lot longer to deploy, is a lot more code etc.

As we've seen from one implementation, sendholdtimer is a code changeset 
that's counted in the few tens of lines.

BGP level ACKs would most likely be magnitudes larger changeset, touching 
a lot larger part of the FSM etc.

You're free to go work on this (I'm not opposed), but please don't hold up 
sendholdtimer in the meantime.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email