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

Brian Dickson <> Fri, 23 April 2021 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A11A03A1A18 for <>; Fri, 23 Apr 2021 11:51:34 -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, HTML_MESSAGE=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 dWet4UcX6gIb for <>; Fri, 23 Apr 2021 11:51:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C457C3A1A14 for <>; Fri, 23 Apr 2021 11:51:29 -0700 (PDT)
Received: by with SMTP id b38so15611260ljf.5 for <>; Fri, 23 Apr 2021 11:51:29 -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=O8fvU1N7dzMjjKV37ofrRAb4IeDZffObsHwF3ruSH9U=; b=kBKlJEeocOTIRpG2IPbk/0WNqG51v1LFZ/j3/xtDRaf9R/BLpXKQnJJk6+0Fn07p2t XQHnqs4KzAduxGfqLagotVqpYS8bV4xTh0I99ramOautxhHyEwJeNrOsIt7nsQb9FGpv 3RTt1PjnHyTBPrXYw6DV8x4GTBfYo+23TUgDBCXfbFW/IR6EA2l6eSZA9yS6OTXkxftM 8ub4uTU+uq4kahiiad5ouNb9slIyqReHBiyz7rNUQRCus7UDKmN0yk4tgAKCjZaRiuQS /YEhfQH+JhMDW7D84cwn/jVI3oU8kYdYOmIYoONdj5MH6J2dRz8FIm/V9WlQKRgCSigl nPAw==
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=O8fvU1N7dzMjjKV37ofrRAb4IeDZffObsHwF3ruSH9U=; b=jZnc9e6N15DNl5/qtBdANM+JvMz54PBs9pGedN+ScvzBQocYhg4KTYm6GipkQNUC6z iLt2DHTbkh5KMAdqUdY/WXpJvaq8SMjHjkEYR+S8rPHhY4F5RufS16IgoHy6INTiKBee VrchYGNelvJPBeK4CScGlXzAXTwFfldjDj/JtAzgkxhz37pC3WxAhkrSTrH8M1AELYO7 6d2vRggut3+62FF5Ov/Zx8OMs+TO3HCfi7r+83jU289Gvz7bXlU1v55J/TJQdc1a9Rlb Thg6GI9uUcYwpz3YiN3n146BgeepARNDxGcBMjhlv4C4Xwq2x4OF0p+SKeCZFQ/58Fut odLA==
X-Gm-Message-State: AOAM5325bK0MWxXjbRQ5GS/h+rQ4zxthbXM7Iu4Oh/59ev1ggirXJ3RD AgbmArsGnZH6IkKaWcOuCNaYeRSGTuaJMGk83z4=
X-Google-Smtp-Source: ABdhPJwEJJ/8nywa+B1K/jpkDEwDACcwTDtXUPAeC+ZHW3qCd1BIQlqRcmzPdeLPFTqInPwHKyG6oMFAfc4QcZpVnEI=
X-Received: by 2002:a2e:b8d2:: with SMTP id s18mr3586934ljp.148.1619203887792; Fri, 23 Apr 2021 11:51:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <YILA1sLuzMd47LYR@snel> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 23 Apr 2021 11:51:16 -0700
Message-ID: <>
To: Enke Chen <>
Cc: Job Snijders <>, "Jakob Heitz (jheitz)" <>, Ben Cox <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008d03ce05c0a848c5"
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 18:51:35 -0000

On Fri, Apr 23, 2021 at 10:31 AM Enke Chen <>

> Hi, Folks:
> The holdtimer already conveys whether the session should be timed out
> sooner or later. It makes sense to tie the new timer with it, perhaps with
> a configurable multiplier. The default could be 1, or 2.
This is a bad idea (having the only "knob" be a multiplier).

It might be okay for the default to be derived from some multiplier over
the default for holdtimer, but it is not okay for the knob to be ONLY a

Here's why:

A router with a large number of BGP sessions, where those sessions have
different characteristics, such as RTT, loss, bandwidth, etc., are very
likely to behave quite differently.
(There are any number of operational reasons a router might have
connections of this sort, it's really not worth detailing all the reasons,
but some examples would include a router with both local LAN peers
(customers) and satellite peers; peering extension providers over
multi-city links; underprovisioned peer routers; software router peers,

The operator should (MUST) have exposed controls to adjust timers on a
per-neighbor basis, and/or per-router basis (when managing large numbers of

The purpose of this proposal is not met if that level of granularity is

The operator has the ability to understand why individual peering sessions
may be behaving this way, and will need to adjust the parameters on a
per-peer basis.
Fixing a problem for one peer, should not introduce problems for another

This isn't 1995.


> Thanks.   -- Enke
> On Fri, Apr 23, 2021 at 5:43 AM Job Snijders <job=
>> 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?
>> Kind regards,
>> Job
>> _______________________________________________
>> Idr mailing list
> _______________________________________________
> Idr mailing list