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

Job Snijders <job@instituut.net> Tue, 14 March 2017 21:48 UTC

Return-Path: <job@instituut.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 003F4129B65 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 mI2iWwAArw8C for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:48:41 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8F1129B60 for <idr@ietf.org>; Tue, 14 Mar 2017 14:48:41 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id 196so15990885wmm.1 for <idr@ietf.org>; Tue, 14 Mar 2017 14:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=AxaUxIEenpzHL6SnAcJhCi8IDGRdCT4gnahcmhKvGQY=; b=CoepSIihI/dL/EuL+usDAGD+srMY0Byigll3VP2yegJHVsIlshalRg/xs50B3va0pz pqeZKB4IkS9/WaY0QblqEa9isfjRZH7T4Mzgm7ELZjG+SMugC6vIdqekNvqOeBCKqg8q cZrXOQ0pgJuDn3UV0Al94s5suuXmL7qZDmp4AkFRGBHKi1pjqfY/DkTHFRBcsaChCrsX 0rOz013m+l1IP0nms8A7bs+kfivS6zZib3sfAcP2ppttb89mWrXgVpN2fAzWc0CiqjyS QYuzcypMVzdzqL631R7pKXHhIjlr2XznBXHBUPbFoavLU0a6lflw+CM2RILWox4/dTvY 4OvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=AxaUxIEenpzHL6SnAcJhCi8IDGRdCT4gnahcmhKvGQY=; b=gpHVyO1K9Jvq0E6NpzVe92RhRODpw3D9kYFEP/FspwAPVDFD4BVThdmywei2EJcvMu P0QiwJ6BLyh0lIR7uqXicDixwJhnl1nmAtZwYBp0prZiSheQJmqT1IKvv55J+65R2BQQ En02xW22E1nWWfxU4nm94ZFvIJEs6RSn8aCYrBy+iBTkU9WIMYdsHPcYCKbMRyzPoUcJ iOUbJhCw/PjGSRVE0LFsRK4AxUmatvqnhEg88TGAH211IyUmzFDIfEPTXmv1Xzu/qtJu q//8boYh7LaNX+fPrmQC3qpf0S+czqSuteH6S8om/dAif0jKBAbHLqQCCGQoivFxX2Bh OG8w==
X-Gm-Message-State: AFeK/H3LVUbzKP4B+zoYbh+neiuBgvupvIVC1pHTlW/AdaiFIsjPp8EjH5h1aH/8MKQ9eQ==
X-Received: by 10.28.95.87 with SMTP id t84mr16394113wmb.35.1489528119788; Tue, 14 Mar 2017 14:48:39 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by smtp.gmail.com with ESMTPSA id j74sm30825558wrj.21.2017.03.14.14.48.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 14:48:33 -0700 (PDT)
Date: Tue, 14 Mar 2017 22:48:32 +0100
From: Job Snijders <job@instituut.net>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, idr wg <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Message-ID: <20170314214832.s3k37p27y7xfpfsv@Vurt.local>
References: <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> <20170314213607.GH12864@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170314213607.GH12864@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XBL0ywtXyO2pRBCmKnsw2YWacgk>
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:48:43 -0000

On Tue, Mar 14, 2017 at 05:36:07PM -0400, Jeffrey Haas wrote:
> 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.

I might be misunderstanding you, but a route server is considered (at
best) a supplementary partial view on the default-free zone. If the
route server doesn't have the route, you will have learned an
alternative route through either bilateral sessions on the IXP or
through other sources such as transit sessions, or through ebgp paths
distributed over ibgp. Any path that does not exist in the 'DFZ', but
_does_ exist on the route server, is either an artifact of hyper local
traffic engineering through deaggregation, or is a bgp hijack for the
purpose of spamming a specific subset of route server participants.

I'm somewhat inclined to accept that the route server itself may not
have alternative paths for anything it received from one of its
participants. however the likelihood of having an alternative path might
increase as the route server's constituency increases (a growth
trajectory which in turn might go hand in hand with increased chances of
intra-fabric partial unreachability between participants of the fabric).

either way, since we accepted that path hiding is an issue, we've
implicitly accepted that backup paths may exist.

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

i'm not sure i follow this scenario