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

Robert Raszuk <robert@raszuk.net> Tue, 14 March 2017 12:27 UTC

Return-Path: <rraszuk@gmail.com>
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 8A2B112957D for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 05:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 g6ARIRN-g-nK for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 05:27:44 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 2669712955C for <idr@ietf.org>; Tue, 14 Mar 2017 05:27:44 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id n21so54029761qta.1 for <idr@ietf.org>; Tue, 14 Mar 2017 05:27:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XhuZBAA9kBMxL2IrXiWYC817CWbDLpRzcWv88ucDw60=; b=PrLqfVWTBZwZYYz3FVSCWbv1zojSh6OY9SEYgJecBTjQuummYEZaG1QeXCU96C5jLU DEA+iMAfbEYokAXS2rth2mns3RG/MjkgbX4S0iAE6KAiIVHi760WCZVeW01kb/MUKjkh ml81Ule39MYz9DZ0wXYYPzFk2TgDaHZpL9ieGhnesJTIB4tGi7jLpTg96lxZKTUXbrL4 gpRNPOwmAJUVS4ITM8s9lP7L1IPUjPDwbGRSEEo1a5CFipjrNDKmlGqTnKsFdUiktSaW YVWkAFnEDnuKmJN0lpnsZZ26RkeEtnalYCxPWFNjMkR6PJBSU7uSi4QZDd7dLsU1SYTN DTkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XhuZBAA9kBMxL2IrXiWYC817CWbDLpRzcWv88ucDw60=; b=GA6Cu136s2ismrxu6/y9RwQa63ZVcZsRBb+qtPaYC2wO82Ok12Kp54PqRgRtfRxmFn j82mFl4Fj92g5XVdZWXIKEyzrOvB9LVn1l2ALdJZ++q6iI9syO+FMP3gs486eu9dgflT BqE52qKvGfS0HO4VXLP+Etmp0KqNwrcTQTM25PEmZ6oVn1rDVIZHjIB320d0Wv+k89Hq 9U1ADDN3HtdBaepTu6j92q2me9QKBz3q3BcgSdr6lchWRdLg1jAmG1peP6lju66HhvRC ILRsvjiHrb0vCNfzdrGFi9aKr0B+vSicGCA7ZLiuGSHck3szYcPTLoPx6zaZbFC80kA9 luWA==
X-Gm-Message-State: AMke39kVTqrwjF9UVU62aMDhShg9dclMxgemVfcyepbUtbsNYsQ28wiMFUMGEaTPA5CL4pqx6XLY61aFwpCa3g==
X-Received: by 10.200.62.145 with SMTP id y17mr39861503qtf.53.1489494463092; Tue, 14 Mar 2017 05:27:43 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 05:27:42 -0700 (PDT)
In-Reply-To: <58C7D45E.80704@foobar.org>
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> <58C7D45E.80704@foobar.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 14 Mar 2017 13:27:42 +0100
X-Google-Sender-Auth: 1mfcVxHvEXqg7s_uzjDgVYOSVRo
Message-ID: <CA+b+ERnFFEi=cbNN7s0cnmE3vxm-hZ8jzXq1sUGYaWxL2efpuA@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Content-Type: multipart/alternative; boundary=f403045e6b285e2127054aaff4ee
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/39MqVF89K2H07rzBifxSAM_gsIw>
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 12:27:45 -0000

Nick,

If someone is using weak BGP stacks which can not handle two BGP paths per
net .. sorry that to me does not justify inventing new SAFI.

Moreover the idea behind the new SAFI is flawed since it assumes RS always
would have a secondary path to send to client. Otherwise noise of 1000
peers bombarding RS with message "NH-X is not reachable" is pretty useless
if given net has only one NH on the RS.

Moreover those weak clients which can not run best path for RS received
nets are now subject to handle 1000 BFD sessions ... it really does not
sound right that an edge can do the latter just fine and not the former.

Last to address real world problem - I proposed very easy solution which
you as an IXP operator can enable today via simple config on your switch
and treat such switch (or pair of switches) as default forwarder. Done !
Fully backward compatible with existing IXP deployment too.

Thanks,
R.










On Tue, Mar 14, 2017 at 12:30 PM, Nick Hilliard <nick@foobar.org>; wrote:

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