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

Jeffrey Haas <jhaas@pfrc.org> Tue, 14 March 2017 21:58 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 73040129B06 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:58:56 -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 gAe80v8dln0J for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:58:55 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9E126FDC for <idr@ietf.org>; Tue, 14 Mar 2017 14:58:55 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id C52271E33B; Tue, 14 Mar 2017 18:05:05 -0400 (EDT)
Date: Tue, 14 Mar 2017 18:05:05 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Job Snijders <job@instituut.net>
Cc: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, idr wg <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Message-ID: <20170314220505.GJ12864@pfrc.org>
References: <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> <20170314214832.s3k37p27y7xfpfsv@Vurt.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170314214832.s3k37p27y7xfpfsv@Vurt.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pNPULk2lZEmjJ171ZTEl36rmklA>
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:58:56 -0000

On Tue, Mar 14, 2017 at 10:48:32PM +0100, Job Snijders wrote:
> 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.

The RS client having a source of a path via its iBGP from its internal
network is exactly what I had in mind.

RS clients having bilateral sessions with other IXP clients was somewhat
less than common when I last operated a route server, so forgive my myopia
on that point. :-)

>  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 would also caution against Internet-operations focused myopia as well
here.  RSes are deployed in environments that aren't IXPs.

For the IXP case, I tend to agree with you.  (And have been half following
the GROW threads about having the RS participate in route validation.)

> > But more importantly, you'll stop sending it toward your own peering
> > and attracting blackholed traffic.
> 
> i'm not sure i follow this scenario 

Receiving a path from the RS that is blackholing and propagating it
internally via iBGP.

-- Jeff