Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode

Jeffrey Haas <jhaas@pfrc.org> Thu, 28 March 2019 15:20 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 8F526120453 for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 08:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a53-akdVDh5C for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 08:20:16 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8A12033C for <idr@ietf.org>; Thu, 28 Mar 2019 08:20:15 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id C8FF91E2D8; Thu, 28 Mar 2019 11:19:54 -0400 (EDT)
Date: Thu, 28 Mar 2019 11:19:54 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "idr@ietf. org" <idr@ietf.org>
Message-ID: <20190328151954.GA2120@pfrc.org>
References: <20190328111833.GB24351@pfrc.org> <CAOj+MMGorV9StNVCvDyHgHHTdg+u0EQ0VDT-L6AVVUQTKGkwfQ@mail.gmail.com> <FBE4CC86-EE29-4E44-AC27-171D4DDD8FEC@cisco.com> <CAOj+MMGcKsuEomSBw_1MtaYwND4+VQjE2LjqEBAeoHKvpeA3DA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMGcKsuEomSBw_1MtaYwND4+VQjE2LjqEBAeoHKvpeA3DA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gEgZb6d7zcOmyU9KNd8xg8alTAU>
Subject: Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 15:20:18 -0000

Robert,

On Thu, Mar 28, 2019 at 03:26:09PM +0100, Robert Raszuk wrote:
> Yes you have bfd for bgp. Use case is for ebgp to bring bgp down as soon as
> your peer goes down without cranking up bgp keepalives.
> 
> Well as it was presented today the scope of current proposal is much
> broader. Hence the comments.

I find it likely that the draft needs some clarity as to whether we'd want
this capability present (or not) when BFD is not intended to be used on the
link.

Your example of "we're doing ibgp, please don't use BFD for BGP":
- If we did want to use BFD, please use strict.
- If we didn't want to use BFD, we might still want to specify strict as a
  capability so that by not having it come up you didn't end up in one of
  your interop scenarios.

-- Jeff