Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

William McCall <> Fri, 23 April 2021 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2FB03A130B for <>; Fri, 23 Apr 2021 08:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OETDWT1w9AFP for <>; Fri, 23 Apr 2021 08:38:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A45B3A1304 for <>; Fri, 23 Apr 2021 08:38:16 -0700 (PDT)
Received: by with SMTP id 1so36686789qtb.0 for <>; Fri, 23 Apr 2021 08:38:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=enZGxDyMVjMwDkbGm54fN98K+ir11f7RupbN3x39II8=; b=Rmdoy84eRxz+GP48yMhHIfCOWJ5fX47gNU5winPi1jISkszpaLF9zCBkt4xFHiiEs5 gGs/AR2Umk1q3pTpnvcBUbbNuSEFMf0/5qAYXVJfw1EmISg4c5DMhFVeB9GXeIYtMm4r TsV9nutfpiIjRxzYVRZB+iEwzq4TOiM23XzG5s2hp3g0PghqpnC1PfCGGGOLgfU9jQao b5Wd9B0EFp9xSargyEXZq6vTzkrZfFCsV4fisSbNrjLbOiGVPAaN/oxTU0wvAxDUYJLO Jgy0lFERBFgqkwb7N6Yv5mhZXTswUnUPCOo96t5Joo8gZ0TvsEBJi/S/ISMraSAsHPIH bOHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=enZGxDyMVjMwDkbGm54fN98K+ir11f7RupbN3x39II8=; b=YlQkJKWT6Kf3gYXRCaHlqSAOr+BMUUHjRW7GwzVDtu8bO0xhd9GqUCmbnQzngR/8sP kFUw5sgFtewKyY6KKoajOEvkZ5xSktNXacN8nAoDPykpZ017MdwUuzoWv0qDJE/IQK/1 eVrvEP6/DUtvCKKL5VaLNqmjAILap8rd4RMSmuX9qtbxDVFfmcqd9JD4foRmnFOauGKQ RZnscAnGVa8KU9o+rBCDsZriqprGOaHkMhlSDEdFO8UpWvPk3fBFwNMh+LenOGpS/2yo Z/mKTfHKzsCRudb22RHh2pyxvHbL1iDr+bZbR3Tn+fw29LIAWQuhel5dHkVYnMtQaua1 Kd5Q==
X-Gm-Message-State: AOAM532kdjN1zvjfCPEfZC2TW5TDAjo5bDoP32QueIss1A44VeIVO9pH tON4BmyWl3B9TukY1P8zu+qgClAd9H6NbrHXVNU=
X-Google-Smtp-Source: ABdhPJx6aXM6WVsIaBvyRRoJFGA+r3c6LYPCR8z10iRW/9xTmT0nyVfUuk6aZiKr6b7wf4N2k4+LN72jDVdgXPapj1c=
X-Received: by 2002:ac8:4b54:: with SMTP id e20mr4380006qts.371.1619192293971; Fri, 23 Apr 2021 08:38:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <YILA1sLuzMd47LYR@snel>
In-Reply-To: <YILA1sLuzMd47LYR@snel>
From: William McCall <>
Date: Fri, 23 Apr 2021 15:38:03 +0000
Message-ID: <>
To: Job Snijders <>
Cc: "Jakob Heitz (jheitz)" <>, "" <>, Ben Cox <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Apr 2021 15:38:18 -0000

On Fri, Apr 23, 2021 at 12:43 PM Job Snijders
<> wrote:
> Hi Jakob, group,
> Thanks for the feedback, a -02 has been submitted.
> On Fri, Apr 23, 2021 at 12:56:40AM +0000, Jakob Heitz (jheitz) wrote:
> > I propose to add this text:
> >
> > It is possible that a BGP speaker presents a TCP zero receive window
> > after receiving a large batch of updates. Resetting the session to
> > such a speaker may just repeat the large batch, whereas waiting a little
> > longer may have given it a chance to recover. The possibility of this
> > occurrence makes it difficult to determine a good value for the
> > timer. The default value of the timer is therefore recommended
> > to be 15 minutes.
> In this email John Scudder appears to suggest using a separate new
> timer, and populate the timer with the default HoldTimer value (and the
> -02 draft attempts to describe exactly that).
> you propose 15 minutes; so it seems there is some convergent thinking in
> the group the proposed timers at hand is in the order of 'multiple
> minutes'.
> How long should a BGP speaker be willing to buffer on behalf of another
> BGP speaker's inability to progress message processing?
> If the oldest message in the queue is a KEEPALIVE message, and its been
> stuck there for more than HoldTimer, wouldn't we have expected the
> remote side to have killed the BGP session anyway?
> Would you mind sharing your thinking on why a default of 15 minutes is
> better than for example 180 seconds? What do others think?

15 min seems a safe default, if somewhat arbitrary.

The default has to be safe enough to survive slowness, especially
during initial convergence, across a wide variety of deployments.

What is "slow" is going to depend on the profile of the deployment. So
tunability in implementation is probably going to be more critical (at
least in my thoughts) than the default in practice.

I think this is only a piece of what BGP really ought to measure and
act against in these cases. BGP should have some understanding of
far-side message processing latency. Because if my queue is
progressing at 1 update/10 min, it is going to be really behind even
when there is progress.  I'm a big fan of a ping + nonce capability to
estimate this latency in addition to watching update outQ time. They
handle for complimentary conditions.

William McCall