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> Tue, 07 March 2023 11:41 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 EB6FAC14F72D for <idr@ietfa.amsl.com>; Tue, 7 Mar 2023 03:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_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 (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 Od3ND5T4bT-p for <idr@ietfa.amsl.com>; Tue, 7 Mar 2023 03:41:54 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 12BD3C14CEFA for <idr@ietf.org>; Tue, 7 Mar 2023 03:41:53 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id c18so7557256wmr.3 for <idr@ietf.org>; Tue, 07 Mar 2023 03:41:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1678189312; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1vnONHWx1PKo1F2acu9wnK2My2AZpbJvWP4jFoOJA90=; b=UvQpEad6ySUs62qtAZwuqRyK7SKxEhtE9INvPdzUVeljwtmmSe9xYKhPe3mds6NaB8 uto+yJlrpB0yIAmx9PMKSCBO0h6w/5G4oSSmsr8eHBVTqNMoA/tYMCVlEGggUUGVbB1r CajP+cmJHkGYyI3Yd9JguisfbX9Z6MW9MqWxkNbFSLF9yUU29ds2n/VU61ky8rS9u9kG D9P5S/YC9Kxy9ukBWq/evG9d/1HDv2BPyX39qTYbX2lh0/cS9cimQ6g2AJQE2LDcKWXG tpU3bWVzu87UyaRdU0MFzRSYn+aHhlKHHsaVv4TST3U8tiKpEIbnsNYzSgNgHAcG0i5O taKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678189312; 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=1vnONHWx1PKo1F2acu9wnK2My2AZpbJvWP4jFoOJA90=; b=jxOa7RTyEfHRhVVi7gpyZ4AjUHDXP85Wm9FvcfzYWzYw2QJIAN7F5W3lGZHJpLx7I0 8UWT4bhSkLNNri8tn+2eDTG50/pniMDeLct4fUZ3QTNBh8Vkp4LYP+ptgxjIHc37MzuS +e1WC8tyUrt9cKfVdxOB1eVm2BYnVB287yqOpADSBEcOTdtAGlGW/Wa/Ta/7pzqFeWtk 0PBVnkYfwXr7F70GduwtBvqBrn83LDZ6DlqRPdcJFNsmmnmacytjI8sqNrBBR65n+kWv 3O1Gj386vrpnU5uKEDNysXZXIZCQPfiwRE4Dr3uwYUnoz+nNoNPMVdOVGvN87kg6fS3I gCrA==
X-Gm-Message-State: AO0yUKVWuBLHSFtLUM9NLR/Tmn9xd31skfiglyExYvHivpSZPqhvjwit QsXJY9XwOgyjOLrKm6YBu8c9qqK5ft1injkl4jnrTg==
X-Google-Smtp-Source: AK7set+4Nn8v64wy8q1h2IcB65Wwakns9J1Q1WOFFVKMT2ggmqp1f8N2n88Qua4REU+JTi4Eh6NI4H5aa663P2/eWSI=
X-Received: by 2002:a05:600c:a695:b0:3df:97cf:4593 with SMTP id ip21-20020a05600ca69500b003df97cf4593mr3010433wmb.6.1678189312396; Tue, 07 Mar 2023 03:41:52 -0800 (PST)
MIME-Version: 1.0
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> <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>
In-Reply-To: <alpine.DEB.2.20.2303071224040.2636@uplift.swm.pp.se>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 07 Mar 2023 12:41:41 +0100
Message-ID: <CAOj+MMFc29DOAL6QK3u9gzPBQPv3wRdhTRHRPD_1ABebtuX0=w@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Nick Hilliard <nick@foobar.org>, idr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d4de0305f64de594"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T3nRcY_eRCAd_5ngLNyaUmErtG0>
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 11:41:58 -0000

Hi,

> I don't understand how USER_TIMEOUT solves this at all. USER_TIMEOUT seems
> to address problems with the connectivity, and close the session.

Specifies the amount of time that transmitted data may remain
unacknowledged
before the TCP connection is forcibly closed.

So local socket buffer get's full because we are not receiving TCP level
ack from the peer.

/* Besides we are all talking about broken BGP peer which does not receive
new info from
us yet keeps the connection up. */


> What is it that will not clear in 8 minutes but that will clear in 60
> minutes, that you're concerned about?

8 min is not the normative MUST minimum. It is only "recommended". And not
even written in a normative language.

Thx


On Tue, Mar 7, 2023 at 12:25 PM Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Tue, 7 Mar 2023, Robert Raszuk wrote:
>
> > Hi Nick,
> >
> > Great - so would co-authors be ok to add MUST to the draft that MIN value
> > of  SendHoldTimer  should be 60 minutes ?
> >
> > If so I think it would clear any of my concerns.
>
> BGP timers in production networks run at the minutes resolution, typically
> dead timers happen in 60-180 seconds.
>
> What is it that will not clear in 8 minutes but that will clear in 60
> minutes, that you're concerned about?
>
> If the sender hasn't been able to put any data into the socket for 8
> minutes straight, what do you expect to happen that'll clear that before
> 60 minutes?
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>

v2.23.0 | Report a Bug | By Email