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

Nick Hilliard <nick@foobar.org> Tue, 14 March 2017 11:30 UTC

Return-Path: <nick@foobar.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 3E6D7129867 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 04:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 thu7G2lSwN9V for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 04:30:42 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55ABC1294CE for <idr@ietf.org>; Tue, 14 Mar 2017 04:30:42 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from cupcake.local (87-198-221-22.static.ptr.magnet.ie [87.198.221.22]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2EBUdNX076082 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 11:30:39 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 87-198-221-22.static.ptr.magnet.ie [87.198.221.22] claimed to be cupcake.local
Message-ID: <58C7D45E.80704@foobar.org>
Date: Tue, 14 Mar 2017 11:30:38 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.11 (Macintosh/20170302)
MIME-Version: 1.0
To: Robert Raszuk <robert@raszuk.net>
References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <m2k27tzs5k.wl-randy@psg.com> <CA+b+ERmmqtUkJMtfOE9ABFHN0gNdztjOGELmirNgWRnDENrjaA@mail.gmail.com> <m2zigpxu7o.wl-randy@psg.com> <CA+b+ER=MaOqOr0A9VZ3TfgbSWgjk3eGwLKmnfr=byvOs11Ppfg@mail.gmail.com> <m2o9x4whh2.wl-randy@psg.com> <CA+b+ERnTJ4TJtgp=Jnn7k08j4dPibhB4gC69WWyQ4wDbxxr5zA@mail.gmail.com> <m260jcw5gg.wl-randy@psg.com> <CA+b+ERn5XT=SFCj+tTegASRq9PTEONH3kkpvkvRsQ3mX4_cYCQ@mail.gmail.com>
In-Reply-To: <CA+b+ERn5XT=SFCj+tTegASRq9PTEONH3kkpvkvRsQ3mX4_cYCQ@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hUQSpl28zQyu2ShsTGy2SWxSglw>
Cc: Interminable Discussion Room <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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 11:30:44 -0000

Robert,

speaking with my ixp operator hat on:

Robert Raszuk wrote:
> Any ASBR (even software running in a VM or container) today used as
> peering router can handle Internet table. That is 600K+ nets.

this statement is incorrect on production networks.

> IXes give you tiny subset of it via open or selective policy. 

this statement is incorrect on production ixps.

> Moreover
> as I mentioned in my original comment - over RS you get local customer
> and internal routes and no more. So for any net it will be usually one
> or two paths anyway. 

this statement is incorrect on production ixps.

> So if someone has one path (and client has no way of knowing) signalling
> to RS that next hop is gone is not helpful as there is no backup path RS
> could recompute and send to such client. 
>
> Learning two paths for given net with different NHs (even if RS has more
> then two) seems to provide sufficient robustness and enables you to
> measure quality to the destinations as well as do things line multipath TCP

this statement is both incorrect and wildly unrealistic on real world
networks, even from the most rarified theoretical point of view.

> Now if someone is really so weak on the edge and attaches to IX to only
> peer locally we should perhaps invent co-located with RS pair of data
> plane boxes where such weak guys would for forwarding just default to
> such data plane gateway. That way those two forwarders could have as
> many paths as RS feeds it with yet all weak clients are happy to forward
> and reach all open peers of a given IX. 
> 
> In fact most IX switches while running in L2 mode could be configured
> for L3 as well so no need to even invest new $$$ needed. 

this statement is incorrect at production ixps.

I would be happy to provide multiple counterexamples to all these points.

This draft is attempting to solve a real world problem on real world
networks.  It would be nice for ixp participants to have ideally
specified equipment providing service for clients which all had working,
network-aware multipath implementations which could react immediately to
blackholing events, but this doesn't even begin to approximate reality.
Production IXPs need to be able to provide baseline services to a
hodge-podge of different types of equipment serving the great unwashed
of the internet.  There are very few assumptions you can make about
equipment specification that will turn out to be realistic.

Nick