Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

Jeffrey Haas <jhaas@pfrc.org> Tue, 14 March 2017 20:59 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 71CFF129B0D for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 13:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 UE1_-xvfjgNS for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 13:59:45 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A1EF1129B11 for <idr@ietf.org>; Tue, 14 Mar 2017 13:59:45 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 30A531E33B; Tue, 14 Mar 2017 17:05:56 -0400 (EDT)
Date: Tue, 14 Mar 2017 17:05:56 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: Nick Hilliard <nick@foobar.org>, idr wg <idr@ietf.org>
Message-ID: <20170314210555.GG12864@pfrc.org>
References: <CA+b+ERmmqtUkJMtfOE9ABFHN0gNdztjOGELmirNgWRnDENrjaA@mail.gmail.com> <58C6751D.60306@foobar.org> <CA+b+ERkxvKzArYf7eefB5UL_kDMVBJERz=Qyi=zOsBm3KivAtg@mail.gmail.com> <CA+b+ERn5o-i-6shdzj_afa8Z1yQO3Ep6HmB=Fv4StSW_ge95Ew@mail.gmail.com> <CA+b+ERkBeBoz0Le4wgqZK1X76=_HKOEUYTWYBd_xnjYoaJgrsw@mail.gmail.com> <CA+b+ERnBL9Q3ep1JrC9HQp3B3AYmiQ8ctTssK1g4L_ueTTRaMQ@mail.gmail.com> <CA+b+ER=cZiBfWj4=+uKeqsWwypGFz3p+Tvx8Q2dD3hFFXSC4=w@mail.gmail.com> <CA+b+ER=f-S118JtY--n-B0P+CB0yvy_rw3JaJpWw02n7prQ=Ww@mail.gmail.com> <20170314204212.GD12864@pfrc.org> <CA+b+ERk3S_eZrE+r7jE7toNmLrm7r4H8cW=64kyhv1UFQruiGw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+b+ERk3S_eZrE+r7jE7toNmLrm7r4H8cW=64kyhv1UFQruiGw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/J5S-pUVgAtPWVleBSpJEwWahTIU>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
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: Tue, 14 Mar 2017 20:59:46 -0000

On Tue, Mar 14, 2017 at 09:45:28PM +0100, Robert Raszuk wrote:
> In fact to me this is basic 4271 as you should not use a path (even single
> path) if you can not validate if the next hop to it is reachable.
> 
> I think we all in BGP did not pay that much attention to reachability on
> multiaccess LANs ​as most peering happens on p2p links where the same
> problem does not happen.

For first party nexthops, BGP timers can address this to some extent.

BGP timers are too long, hence BFD.

For third party nexthops, you can have persistant bad forwarding.  Normal
BGP procedure doesn't help you here.

So, we agree that the case isn't given good attention in the core specs.

> > The one "common" use case where this may be of benefit outside of a
> > route-server environment is BGP "VPNs" that are constructed using IPSEC
> > tunnels with the network effectively an NBMA subnet.
> >
> 
> ​See all SD-WANs today need more then one path such that they make
> forwarding decision by probing all alternative overlay links and based on
> the applied logic switch over to better or lower cost or less delay path.
> If you give them just single path this is all no longer possible. That is
> what worries me in this the most if you would like to utlize this new NH
> NOTIFCATION SAFI for WAN VPNs.

The new SAFI is targeted specifically for the RS case and hasn't received
specific consideration for other use cases yet.  Feel free to kick off that
as a topic, although I'd suggest doing so separably from the rs-bfd thread.

-- Jeff