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

Jeffrey Haas <jhaas@pfrc.org> Thu, 28 March 2019 15:52 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 B0CBB120322 for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 08:52:08 -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 7BMDxMkulSFF for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 08:52:07 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D25B8120511 for <idr@ietf.org>; Thu, 28 Mar 2019 08:52:05 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id C3F9F1E2D8; Thu, 28 Mar 2019 11:51:44 -0400 (EDT)
Date: Thu, 28 Mar 2019 11:51:44 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: acee@cisco.com, "idr@ietf. org" <idr@ietf.org>
Message-ID: <20190328155144.GB2120@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> <20190328151954.GA2120@pfrc.org> <CAOj+MMHOktd3PuE_9GZvGd8_VxVU0HodLnjOCmBJxDH2JYTuWQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOj+MMHOktd3PuE_9GZvGd8_VxVU0HodLnjOCmBJxDH2JYTuWQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZXlowxHrM6NkXNpQvo7bWVLthno>
Subject: Re: [Idr] =?iso-8859-1?q?ietf-104_responding_to_R=FCdiger=27s_commen?= =?iso-8859-1?q?t_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:52:15 -0000

On Thu, Mar 28, 2019 at 04:36:49PM +0100, Robert Raszuk wrote:
> Yes clarification of the scope is needed.
> 
> But my broader point also was to clarify which operational model fits best
> to different scenarios.

While I agree it's a useful discussion, either in IDR or BFD, it's partially
orthogonal here.

The draft is not about whether we should run BFD.  The draft is about when
we run BFD how we should behave to do the Right Thing and interoperate.

> We have clearny two options:
> 
> * keeping up/down of bgp session on say loosy links

In some cases a religious discussion.  There are scenarios where BGP
stability is more important than whether packets go over a lossy network or
not.

> * extend the notion of valid/invalid next hop in the same env.

Again, a religious discussion.  In environments where nexthop reachability
is intended to be highly reliable, things like rs-bfd nexthop behaviors may
be desirable.  For ibgp, it's generally more preferable to leverage BGP
protecting the underlying IGP.  In cases where there's no IGP, reliability
of connectivity will impact whether you want to do this or not.

-- Jeff