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

Robert Raszuk <> Sat, 24 April 2021 09:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A47E3A1875 for <>; Sat, 24 Apr 2021 02:28:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ikCgK3ENg1Nl for <>; Sat, 24 Apr 2021 02:28:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE0333A1872 for <>; Sat, 24 Apr 2021 02:28:02 -0700 (PDT)
Received: by with SMTP id j4so41564762lfp.0 for <>; Sat, 24 Apr 2021 02:28:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PUtbXavmG/vtSY592+m/WPEbDxUdmZTI4XYQjH7ypNs=; b=RBTRW9cPNImJzPGkKy+Q28zNl0IKE3mlu5BtMPSoGhg4FIctQhYuy2NlAaVjx+KBoX 6xdl00FFu3jun1GrFjFJz1V3q1W1zUYX/veNYintRDD/iGg6lMt+GJhxa/bvXM58YfqT tjlwPq7D7VpZzXhfNMR+wU8olR+MF714gs/EUaeMrOjftyFEQhbMbo03M8BP9M9r5Sc5 GJKYZEZTyq3ZBpE6bvod8fnklGEoFmz5qFRKdXVSKBMMtRvtiboK3QRL/tQHaHU3x4mt wClk50hfUZ1YSUnOtoVWlwblof/YHFqWqMbrQrG2eTFkFEujgNl5xmB8LHOx7/0Yj+0o O4/A==
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=PUtbXavmG/vtSY592+m/WPEbDxUdmZTI4XYQjH7ypNs=; b=l+cDBVhqvKsY62y8oR6fOBu9pHqtUWyJTdzaLEAHGTmZq6SXJDw7cxhhlC7B4ZouOR eWukpmZ0ElXIvLQL5xEiJD2yFATzK1y0Eacqw5Vya3U6AjG5NnsphTYEyVGxaKkk0K7i I1+lE6HGWMuwLIpCernEdOokA1D5QWypKMuOo31rip+id20GCWcCcuCE4KbEhfZfpw6h bhLi+1kTpYGLUzvA8VEr6EiwpbdX7MitAhFeUftIjJE12sXRt0cpQR50v+jOXnlSts2v 9Yhz7+FVLu+nyTClctxpmikqXSGyGeStgpINuGFGFWEY/Ou2P7Y50MfUxfJsCu06Jnjj CT7w==
X-Gm-Message-State: AOAM5329wZacJUUpEM18iNxfX7gtp2au8hqSdkayTp2c1asNjd2P4QXI IPIAXOY3g7/VsFDuUv5bDCqC2zw/sa0y6xmM1YFEsKkJX4TOcA==
X-Google-Smtp-Source: ABdhPJxRH/G5ekL0CeDCpcktrb48q0zk9S8IJ0tnXlLjlTJGDtA3Q5o7JOZK1WPEYNxpDMAF1u3qbjVfhSHzz/0DtJU=
X-Received: by 2002:ac2:46f5:: with SMTP id q21mr826181lfo.541.1619256480338; Sat, 24 Apr 2021 02:28:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sat, 24 Apr 2021 11:27:50 +0200
Message-ID: <>
To: Jeffrey Haas <>
Cc: Ben Cox <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000004fa72505c0b4873f"
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: Sat, 24 Apr 2021 09:28:08 -0000

Hi Jeff,

> So what we are discussing is breaking data plane just because control
> plane
> > has experienced 15 min (or worse recommended 4 min) inability to send
> > keepalives.
> A good analogy is the negative impacts of stale routes when you use
> Graceful
> Restart for BGP.  Can you live with the routes in that flavor of stale for
> that long?

Unfortunately the answer is "it depends". If my stale route is single
default to the world with working data plane I think the answer is clearly

So that IMHO sort of raises the question if this should be the default

Then honestly I am not quite clear how it should be handled on sessions
which are setup with draft-ietf-idr-long-lived-gr-00

> * Should we perhaps test data plane before declaring peer's failure and
> > before we reset the session ? (I understand that the paramount motivation
> > is BGP consistency here though - but this is one of those cases where one
> > size may not fit all).
> In many of these scenarios, BFD or ping would show the interface up.  It's
> the TCP session that is stalled out.


I was rather thinking about checking data plane not to the subject peer but
beyond it (through it). For iBGP - testing next hops. For eBGP some known
test servers in yr network or in the Internet.

> > * Should we first withdraw received routes from our peers before
> resetting
> > the session ? At least data plane will have a chance to converge to a
> > different set of links with no sudden packet drops.
> Would you describe the drain scenario with the involved parties and what
> the
> congestion state is as part of that?  I don't think I'm understanding the
> above point.

If I know I will bring BGP sessions down to you (in any case not only with
this draft) I should withdraw paths from all of my peers received over such
session and previously advertised (as best or as add-paths) before
resetting it. So the control plane clears before we touch the data plane.
Just to make the end to end reachability with no or minimal data plane