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

Job Snijders <job@instituut.net> Tue, 14 March 2017 22:21 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 4E1BD127058 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 15:21:36 -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 sp4t1f65GUYE for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 15:21:34 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 7A0D21315BD for <idr@ietf.org>; Tue, 14 Mar 2017 15:21:34 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id v186so74840379wmd.0 for <idr@ietf.org>; Tue, 14 Mar 2017 15:21:34 -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=zKo1wIiaXCnpENKDBdUBciAhFrirEeqATne8caDWf1M=; b=eIvJ8PKbfXKeSMVjgTUwLUvqbNnRTAyMlJF0UK+UiLflBCYbBZzvlr3qQZ8Kg8HS0+ NtCpIcURxycDdfx/fvnhh8Z16YHQWKuQV7Ta0DJFUvP4RX1fYnbwdLGip0747EkkRPX8 QboYq78FoqF0uHTOenGovzGAL7quCDvq8KRWKcQzfxRrmgZFnrZCy/W9JsZ7SzaTAXv9 LO0rXwHQaGQzEaHdC3mMM3ATlYYGCGzjkSh9vZOmh5n6uqFk39/32g911eUzrr34rxS6 3n9CXVVqv6GBHWAINzEEDpmUZ4XV468pCJU2NI8ywh+tiCfGadKK/bYLj2BMdY5yu6jp q8ag==
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=zKo1wIiaXCnpENKDBdUBciAhFrirEeqATne8caDWf1M=; b=Ae+DMUUgWCtOUpn6vZ/+hMp/GSuaLtRmZFDkl0AuJ5aopOk4C4XiTdaFiKGPiURxCy iAvRNoHXx8LPS80BSRpxtA+bACL/FPbYGLXt/yPk+VPvBkmU92h52mDwc30ccrENciY2 /Eef1XommsKNvIwCR83ou1Thdtb6FKtw4iJsrFXELVp3nasoIP6G9O4dMICFUL33ayGG U7gNruMj0faQcsZNCGHWVOgHoWopJ6H8fqV5noelgH1F68bYj4qrPBxcxZMkuZlkpVcV kbjKGA3hTQq5NCReuz2A+x5iZV1X4Y4z4BU7I2xNCQVMY7rl3+wVGGBhrWe4F4HJ6uEl LTgw==
X-Gm-Message-State: AFeK/H3JNP1ZRrLKsRZOU4OboIsqCOmzZdLQvO+BjLmKDqP0ZpxAHL7bKp2uOo3NE3G2HQ==
X-Received: by 10.28.146.207 with SMTP id u198mr16607048wmd.36.1489530092772; Tue, 14 Mar 2017 15:21:32 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by smtp.gmail.com with ESMTPSA id 128sm17151977wmp.11.2017.03.14.15.21.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 15:21:25 -0700 (PDT)
Date: Tue, 14 Mar 2017 23:21:24 +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: <20170314222124.bfxbvgbzk4n27rh3@Vurt.local>
References: <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> <20170314220505.GJ12864@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170314220505.GJ12864@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1POdto9Eyz3j6VArAMlckz_5rp8>
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 22:21:36 -0000

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

Glad we uncovered this discrepancy, it is safe to assume that in many
cases (i say 'many' because we have no well established metric system
for this), both bilateral and multilateral sesions exist. Any
specification will need to be engineered with this in mind.

If someone is looking to receive as many BGP routes and paths as
possible, you'll set up sesions with whoever wants to, this includes
both direct and route servers. With the rise of network automation based
on public peering directories such as peeringdb.com, this process
becomes even more streamlined. The process effort of denying bilateral
peering requests because you can see the remote network through the
route server, or tuning the route server to not be used when there is a
bilateral session, would outweight just setting up bgp indiscriminately. 

> >  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.

This is new information for me.

> 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.

gotcha, yes.