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

Job Snijders <job@instituut.net> Tue, 14 March 2017 22:33 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 7BA52127058 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 15:33:38 -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 m_3So2nWU8Dc for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 15:33:36 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 8FDB0129BD1 for <idr@ietf.org>; Tue, 14 Mar 2017 15:33:36 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id n11so10181581wma.0 for <idr@ietf.org>; Tue, 14 Mar 2017 15:33:36 -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:in-reply-to:user-agent; bh=gkIYqzE+30izYcGhNeluoBmQsOeCuLVlAq7Q4sJ1nNo=; b=Efvcv9sW4L6n6mk64WtyO90Y6kp64dFCo/Pz0brgxvFNT3Uho0G5BABuKnvIsTjR8+ pmxax8j/yyEnKG3VtqN9sy9TXNbXhM6X+GYPDR54YoJyvlSJF0EUDlJAlvNks0A4jCqm g8XIj7N6wcD+ndyEPgcHOwz9itj8qYETJImWSmdp086uDTluyL1162AlZRxC6s5ByJuJ 5tT6VPZUgo40pptlk+hmbr6SM48yFXRJI9EW9XSq8Q5jUIUZlX9Snd+dQcBAf8G75vHl s+o02OA8NbjfaC+owgpQGTVOqL3EKqLvihXTCx+4QEWOLi89fjQYfSNvMYo1yoGWeuoH Ns3Q==
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:in-reply-to:user-agent; bh=gkIYqzE+30izYcGhNeluoBmQsOeCuLVlAq7Q4sJ1nNo=; b=eMBKxhHXau6/asBUWfS5+NH8IVkrOAfAIgFtGQCHdJH8FiSqpt/NhlXJCKiIkMRoWS gANZz3zlhowCthy4gjQsEuSzQ6zzvgWyc6kgmspgs/tM/wgLeSfdcLXNqSh3qFYLK856 Akdcv3Pn60xxQXf96fr6VIWf6Ht6e019AxA0jCl573VOwoP8V2yCRtwb1qvnDPFJA73T 9BSKT8J3pLbIo9Y6maZr2mLSPgH65RlxZILVA4htJ0KeZ9FcYP0+mR4KkYg2jvHDzcL9 xruYejufPHufOtcGEgDlfG4QIYSfqH+H32erD76DXtJeMJMLTc15ZYGqpDB94z75VHyF wTwg==
X-Gm-Message-State: AFeK/H3eE1PFwXqSzrfdq+qidnd0aem9/2J3mhjJvHQKu0L6dJ0173UNnlf4SR4JRJ9o5w==
X-Received: by 10.28.40.65 with SMTP id o62mr1682495wmo.131.1489530814872; Tue, 14 Mar 2017 15:33:34 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by smtp.gmail.com with ESMTPSA id 63sm30810983wrh.68.2017.03.14.15.33.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 15:33:33 -0700 (PDT)
Date: Tue, 14 Mar 2017 23:33:33 +0100
From: Job Snijders <job@instituut.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "Rajiv Asati (rajiva)" <rajiva@cisco.com>, idr wg <idr@ietf.org>
Message-ID: <20170314223333.bw3caxfn34y6zlb7@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> <CA+b+ERmLDNzF=TofW=w1OwUzeLGUc-3muMckHTH6Rs=c8rc5bQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+b+ERmLDNzF=TofW=w1OwUzeLGUc-3muMckHTH6Rs=c8rc5bQ@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/U6bloSrhVQBDxQPakdFpBPNx_Bw>
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:33:38 -0000

On Tue, Mar 14, 2017 at 11:02:02PM +0100, Robert Raszuk wrote:
> > 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.
> 
> Interesting ... why would you think so ?

It is my observation that some networks will announce for instance a /16
to their upstream providers, but a /17 to their 'settlement free peers'
(which could be found at an IXP).

While there is no one single version of view of the Default-Free Zone,
we do have a an understanding of what global reachability means vs local
visibility. Through services such as http://stat.ripe.net/ you can see
instances where the /16 enjoys good visiblity on the RIS/routeviews
collectors but that more specifics also exist, which are not seem on all
collectors.

While the practise of announcing more specifics to certain classes of
BGP neighbors does not have my preference, I can follow the rationale.

The hijack case is discussed here https://ripe72.ripe.net/archives/video/203/ -
https://ripe72.ripe.net/presentations/165-invisiable-hijacking-follow-up.pdf 

To summarize: if a route server has a unique route (either by virtue of
being a more-specific of something learned over ibgp, or by being a
hijack), that route in and of itself might not be of any value.

I'd argue that for the public internet use case, it is fine to design a
solution which assumes that route servers never contain 'unique'
information, and that any participanting autonomous system will have
alternative paths either to the same prefix or a less specific.

> Imagine I connect to an IX and also have direct Transit with NTT. To
> the same IX also customers of NTT connect such that I can use IX
> switch to get to them without going via longer path of transit
> provider.

This is a valid and common scenario.

> To me their direct routes are better (BGP path selection wise) and I
> go via IX to reach them (or they go via IX to reach my content).

Correct.

> > 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.
> 
> Well that is indeed very important to verify. I am also inclined to
> the same. But have no data to validate how many paths for all nets
> RSes carry in major IXes.
>
> Moreover IXes normally use two RS today so it is trivial to make sure one
> RS sends first best the other second best to the clients (if they have
> more then one). Signalling client to RS that NH is down seems at best
> redundant.

I believe it is a common practise amongst IXP Route Server operators to
let the two (or more) route servers operate entirely _independent_ from
each other, e.g. with no BGP sessions amongest the RS's themselves.

Kind regards,

Job