From nobody Fri Mar 10 07:53:30 2023 Return-Path: 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 B848FC169512 for ; Fri, 10 Mar 2023 07:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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_BLOCKED=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 FA6CFhBudBlI for ; Fri, 10 Mar 2023 07:53:25 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 109CAC169502 for ; Fri, 10 Mar 2023 07:53:25 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id j19-20020a05600c191300b003eb3e1eb0caso6375439wmq.1 for ; Fri, 10 Mar 2023 07:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1678463603; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nBXBZnyX1Utrf3rvP35rEshXRIPqg01NA9NL7ybnZ9Q=; b=bJobS7lUZiFnkIoAcyAJMABdwYHZ+arT7Y2csRMOYuvmc3Y8rgOheDelQZtAAcAo7x QQT/yGIH2Pwvjtim6mGDv/bAfwLhiwXMCfaY+3Y+Qd5fqim4Ej55gwuwVH1vdazBrpKg xTQLo7GaoW1DnKLITmIzRvfl+gmyq4hspPd+fFBZaKl6VU3QQOV+mC4rjwfuUGieXcw0 0iivQy5fWpgmuaiI0iXuXYMKHszVCmkJt58CBN+Rhb6QxMrAZOfHZcGtn8AxiIIbIgPm +956Qh8IheSNQR0xnn4I/tHLoJ98OFLl1xejxE14Lu1kROeb9FGGQL0clf8WUmQ0Mkzy RtyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678463603; 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=nBXBZnyX1Utrf3rvP35rEshXRIPqg01NA9NL7ybnZ9Q=; b=iDEAqC9lYWT6xuK6duKRyXZjrXPnGtAtmy27Fj/zJPPUaguXxbGeIgfeoN8rnKeyt+ BuxllFIJnBJK11fONJMIWaDq35b5aQnXxD2KzQUpkLtRZ2N+cH1LimcjU1jBlI3wzjUs 05z5RQvFGzGcXSiE8kolWrKuRlF3ZlXSZpI+nc1PNCrz0i49d20y6HV45zfR93wtKaim JbQgPGql2JTch5j8qD+kvADMp00/DHNeSHZZFKM7m0ekcaRHL/VjbPwz4B8dVdSdLJf3 qHXT1d+Oy4P05eA/C2eeL++1bzpPtbVxFaBrj2VjL5V/VDQZEx842dZq16pxc3cr7kgf Ka2g== X-Gm-Message-State: AO0yUKVoYvNctxVej1INZxfr8Ho7r3nhvMod2pW6Seb7jb36W0ZYIL8W o2aalwLv2/4UzIywKPFt6RoQVtXXUmxYbvy6ZyqpOQbS4nWQiZ03g+Y= X-Google-Smtp-Source: AK7set+XlFeAc2kLRGkeAfXkDQgCg/500QpxS889T4kimjdkr39KWk/C6SECiuXsZUwN3R7+P0CEM6Pft9Li3M+cy+c= X-Received: by 2002:a05:600c:3b28:b0:3df:97a1:75e4 with SMTP id m40-20020a05600c3b2800b003df97a175e4mr952767wms.6.1678463603004; Fri, 10 Mar 2023 07:53:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Fri, 10 Mar 2023 16:53:12 +0100 Message-ID: To: Job Snijders Cc: Jeffrey Haas , idr@ietf.org Content-Type: multipart/alternative; boundary="000000000000d365bb05f68dc288" Archived-At: Subject: Re: [Idr] SendHoldTimer default value (was: BGP Message level ACKs) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2023 15:53:28 -0000 --000000000000d365bb05f68dc288 Content-Type: text/plain; charset="UTF-8" > Snijders wrote: >> Raszuk suggested 60 minutes. Indeed I mentioned 60 min based on the below quote from Nick: *this draft is about unsticking connections which have been jammed fortime periods longer than hours [bgpzombies], and it's normal for BGPsession uptime to be measured in months rather than hours. For example,here's the output of an entirely unremarkable dfz leaf router:* So credit here goes to him not me, Thx, Robert Snijders wrote: > Dear Jeff, all, > > Everyone - thank you so much for all the feedback so far, we'll try to > incorporate all suggestions we received in the next version of the > draft. > > On Fri, Mar 10, 2023 at 08:46:07AM -0500, Jeffrey Haas wrote: > > Please keep in mind the mix of peer scale and holdtimers that may get > > used in a deployment. I'm supportive of something like a > > sendholdtimer, when the value is long enough. > > The current version of the draft (-09) suggests 8 minutes for the > SendHoldTimer value. We the authors picked this number by simply > doubling the suggested HoldTimer value. > > Nick suggested a procedure, and a default of 20 minutes here: > https://mailarchive.ietf.org/arch/msg/idr/vaN72cmrtHXS4aBVPrwCFJ-1TMg/ > Raszuk suggested 60 minutes. > > Jeff, you say "the value needs to be long enough" > > But what is long enough? We are open to suggestions. > > Kind regards, > > Job > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --000000000000d365bb05f68dc288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Snijders <job=3D40fastly.com@dmarc.ietf.org> wrote:
=
>> Raszuk suggested 60 minutes.

Indeed I mentioned 60 min based on the below quote from Nick:=C2=A0<= /div>

this draft is about unsticking connections whic= h have been jammed for
time periods longer than hours [bgpzombies], and = it's normal for BGP
session uptime to be measured in months rather t= han hours. For example,
here's the output of an entirely unremarkabl= e dfz leaf router:

So credit here goes to = him not me,

Thx,
Robert

Snijders <job=3D40fastl= y.com@dmarc.ietf.org> wrote:
Dear Jeff, all,

Everyone - thank you so much for all the feedback so far, we'll try to<= br> incorporate all suggestions we received in the next version of the
draft.

On Fri, Mar 10, 2023 at 08:46:07AM -0500, Jeffrey Haas wrote:
> Please keep in mind the mix of peer scale and holdtimers that may get<= br> > used in a deployment.=C2=A0 I'm supportive of something like a
> sendholdtimer, when the value is long enough.

The current version of the draft (-09) suggests 8 minutes for the
SendHoldTimer value. We the authors picked this number by simply
doubling the suggested HoldTimer value.

Nick suggested a procedure, and a default of 20 minutes here:
https://mailarchive.ietf.org/a= rch/msg/idr/vaN72cmrtHXS4aBVPrwCFJ-1TMg/
Raszuk suggested 60 minutes.

Jeff, you say "the value needs to be long enough"

But what is long enough? We are open to suggestions.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--000000000000d365bb05f68dc288--