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

Jeffrey Haas <jhaas@pfrc.org> Tue, 14 March 2017 21:29 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 536D6129B50 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:29:58 -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 Se8K2211sGK5 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:29:57 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 29857129AD0 for <idr@ietf.org>; Tue, 14 Mar 2017 14:29:57 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 959761E33B; Tue, 14 Mar 2017 17:36:07 -0400 (EDT)
Date: Tue, 14 Mar 2017 17:36:07 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>, idr wg <idr@ietf.org>
Message-ID: <20170314213607.GH12864@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> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zWG6hA27CL8-dLbmVdQqk0irzqE>
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 21:29:58 -0000

Rajiv,

On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote:
> Is the assumption here that the client routers have routing view limited to what’s provided by the Route Server? If not, then wouldn’t Client Routers benefit from having to invalidate the path learned from the remote client router as soon as the connectivity check failed?

This is what I believe the procedure says.  See section 6.

> Of course, Client Routers conveying the lack of NLRI reachability per NH to the Route Server, and expecting Route Server to provide a different NHs of the NLRIs, and expecting it to be functional, while still attracting the traffic for unreachable destinations since the Loc-RIB is still pointing to the unreachable NH for the affected NLRIs.

The thing that is somewhat different for a IXP environment running a route
server than normal eBGP is the low (to zero) likelihood of having a backup
path.  If 10/8 was learned from the route server for nexthop 192.0.2.1, and
you stop being able to reach that nexthop, removing it from your forwarding
(unreachable) is your only choice.

You *might* have a source of that path internally.  In that case, you can
use it.

But more importantly, you'll stop sending it toward your own peering and
attracting blackholed traffic.

> I wonder whether  https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria be useful here.

In a sense of good timing, John Scudder had brought this to my attention
about an hour ago. 

RS-BFD basically reinvents the same procedure in your draft, simply being
specific about the use of BFD as the dataplane liveness check mechanism.
However, as you note in the RS-BFD draft, we do leave the option for other
mechanisms.

I suspect the other authors of RS-BFD aren't particular where we pick up our
text for the resolvability condition.  However, if the suggestion is to make
a reference to your draft, you'll need to bring it back from zombie state
and progress it. :-)

-- Jeff