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

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

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CE731120481 for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 04:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 70KjE0soAHOV for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 04:18:55 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org []) by ietfa.amsl.com (Postfix) with ESMTP id 8E0D81202EB for <idr@ietf.org>; Thu, 28 Mar 2019 04:18:55 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 0F2611E2D8; Thu, 28 Mar 2019 07:18:34 -0400 (EDT)
Date: Thu, 28 Mar 2019 07:18:33 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: idr@ietf.org
Message-ID: <20190328111833.GB24351@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/H2JYTnMDD7lWtReYexEMc3HyH9s>
Subject: [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 11:19:11 -0000

In IETF 104, Rüdiger responded that he'd like to see BFD in BGP be used to
prove that a link is "stable enough" before we even announce routes.

As I mentioned at the mic, the critical issue is that we have varying
implementations of when BFD must be up in differing implementations with
regard to the BGP FSM.  E.g. Up before we start the transport session
(Connect), or Up before we transition to Established, or Up after

The proposal from Mercia and Acee effective summ to "if BFD strict
negotiated, wait for BFD to come up before transition to Established".  This
provides a common point for implementations to interoperate.  There is still
potentially issue with older implementations that relied on BFD to be Up
before BGP starts its TCP session; however upon supporting this feature we
implicitly add an option where the behavior is changed.

Back to Rüdiger's point: He has a desire that the session is stable before
we start announcing routes.  In BGP RFC parlance, we do not exchange our
routes in the Update-Send process until stability is declared.

While this is doable, how do you negotiate what level of stability is
desired?  BFD, without extensions, mostly will simply declare the session
Down when enough packets are lost.  If the link quality is very bad, this
should happen quite quickly. If the link quality is partially lossy, BFD
doesn't help.  (However, see https://tools.ietf.org/html/draft-am-bfd-performance-00)

-- Jeff