Re: [Idr] RS BFD draft

Gert Doering <gert@space.net> Wed, 19 April 2017 14:31 UTC

Return-Path: <gert@space.net>
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 972AE129AAD for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 07:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 0-8Lx6j4G-Ry for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 07:31:32 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA38129649 for <idr@ietf.org>; Wed, 19 Apr 2017 07:31:32 -0700 (PDT)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 82145602F3 for <idr@ietf.org>; Wed, 19 Apr 2017 16:31:30 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 7E7916028E; Wed, 19 Apr 2017 16:31:29 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 700BA1C3BA; Wed, 19 Apr 2017 16:31:29 +0200 (CEST)
Date: Wed, 19 Apr 2017 16:31:29 +0200
From: Gert Doering <gert@space.net>
To: Nick Hilliard <nick@foobar.org>
Cc: Jeffrey Haas <jhaas@pfrc.org>, idr wg <idr@ietf.org>
Message-ID: <20170419143129.GQ25069@Space.Net>
References: <CA+b+ERkfV4C++arFCBXnyjgkA-FtcqMmd8_9UcbKLWxR32h1EQ@mail.gmail.com> <CA+b+ERkvu296sqD_bi41++RqHiV-f+4cUpb1BPrhE6HsxeueqA@mail.gmail.com> <CA+b+ERk+XP5DvuZStYW=e1uGRWDWE-PiPdwhtkHiVK7hFui7_g@mail.gmail.com> <CA+b+ERmapG68ysZ4=6uDAH=Z+fRaprzgsyQASP4aYD=OTea_Qg@mail.gmail.com> <CA+b+ERkZ-WY5FWiDu_k=1+7tUHEApYj+mMLqZiFzTWGuvHLjGA@mail.gmail.com> <CA+b+ER=MBiFno8CDv9JgpFFmJz4cuDe_tQhm+AHx5njxJy6p6Q@mail.gmail.com> <CA+b+ER=3qy_096Q61FBQgkRSt8j0P1NTQ+EFVit0XEnWvLp6mg@mail.gmail.com> <CA+b+ERmuGSZBcboZDsRo1NDb3dsRozmcEW77KWLyzyjxK8ezww@mail.gmail.com> <20170418203823.GC9688@pfrc.org> <58F729FF.7000700@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <58F729FF.7000700@foobar.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/37AwpAD65QxrIyY0Bh3_-TzpYxE>
Subject: Re: [Idr] RS BFD draft
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 19 Apr 2017 14:31:35 -0000

Hi,

On Wed, Apr 19, 2017 at 12:12:31PM +0300, Nick Hilliard wrote:
> Jeffrey Haas wrote:
> > The RS-BFD proposal doesn't preclude other mechanisms for advertising
> > alternate paths.  I'd be interested in hearing about RS operators that have
> > any intentions of deploying BGP add-paths[1] or diverse paths.
> 
> with RS operator hat on, add-paths is interesting; diverse paths less
> so.  I'd deploy add-paths on the RS side if there were more client
> support out there for it.  Right now, this is thin on the ground.

In the context of "unreachable next-hops" (blackhole in the fabric, or
issues with the remote router) add-paths alone isn't helping much, until
router implementations actually do liveliness detection for the next-hop,
falling back to the next path if the peer is not reachable.

Now, how can we get router vendors interested in providing that...?

(I'll happily settle for "if ARP or ND fails, consider the next-hop
unreachable", which is far superior to "just black-hole", and also
superior to "we have a very fancy mechanism that only works if both
sides implement the protocol")

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279