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

Job Snijders <> Fri, 23 April 2021 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C60613A1BE3 for <>; Fri, 23 Apr 2021 05:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rLfRDVg6GbKi for <>; Fri, 23 Apr 2021 05:43:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A8B83A1BD8 for <>; Fri, 23 Apr 2021 05:43:07 -0700 (PDT)
Received: by with SMTP id u17so73752905ejk.2 for <>; Fri, 23 Apr 2021 05:43:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=0aSFq93sargCHs+4vcVXLinRESSLhx3BvXhip1rJ0Xk=; b=lABxGazm1hyerzayi1YIKm5DGyhFgeYg2ICr+/uB+URKeiG5nS7wVdpttppZhIF51U M/XColvofw2FDGuhOT6ELxeiyaT/86jWmtMhKUE1iJrcuFXjzLfrTwifI64nQ2feN5zt FDJ+pd/0nIA7QRLVt/svTCSoPY8caEymwHUWM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=0aSFq93sargCHs+4vcVXLinRESSLhx3BvXhip1rJ0Xk=; b=Ze1mjeRNdXuOyYf51Pa6tob2erGxAAFdBNSbbAH/m/DmiX4J9qZu1HvtoS1AtEsRgK AAsvlY5U076aKcw4NOpxWQ6k4bfZx5+LeObXuU8AMrfWT5S9VEw7wof8Vlj9h0IP4A7i ZZYEb8rAVISHi+QBWKV+VrecpgGIwa0zBnRS/iweLtDGuxa+Rdp0W0/MeNHD5g8XTu8q Vm+CBuhLwXPTdCrcNZPDGte1Zn9aU6q1qHFx6oSUF0EM8uEiSg4ht9ZlhMFe9XibUF5B qEjukOg7SpVKT4GlVYrYRMfc+0InXSrOY4/MU5TUNfx4ocZ5XdtDbCt1g+1Q3QAruGuW ySZQ==
X-Gm-Message-State: AOAM531yJjB8lQL0xgydRHPlu4QtOTFIa75sZXQvjFHY3irSm0FU09qx vxV5LC5eCrPInj0eBkDRz1zp/w==
X-Google-Smtp-Source: ABdhPJys8KWOqSdOqSipWN9AW4nALrxWQcEqq6jTgneoxihcARgc5Y2PW0SGfLzl/l1CbE+VSOPa0w==
X-Received: by 2002:a17:906:fb19:: with SMTP id lz25mr3900783ejb.544.1619181784989; Fri, 23 Apr 2021 05:43:04 -0700 (PDT)
Received: from snel ( []) by with ESMTPSA id hq16sm3712846ejc.5.2021. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Apr 2021 05:43:04 -0700 (PDT)
Date: Fri, 23 Apr 2021 14:43:02 +0200
From: Job Snijders <>
To: "Jakob Heitz (jheitz)" <>
Cc: Ben Cox <>, "" <>
Message-ID: <YILA1sLuzMd47LYR@snel>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
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 12:43:12 -0000

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

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,