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

Robert Raszuk <robert@raszuk.net> Fri, 07 July 2017 08:17 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 B9EA21241FC for <idr@ietfa.amsl.com>; Fri, 7 Jul 2017 01:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 hkTPfnZr5RNQ for <idr@ietfa.amsl.com>; Fri, 7 Jul 2017 01:17:45 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 9B37A1204DA for <idr@ietf.org>; Fri, 7 Jul 2017 01:17:45 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id k192so28375436ith.1 for <idr@ietf.org>; Fri, 07 Jul 2017 01:17:45 -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=cWfF134QotqenzzWAreaNH0oh6f6SVpYCwDOiHK5Je0=; b=M4XZRNWUqln07Tdz7iZvIhXkmEsPn6/LO1Hs7tuHr4IVskLrguAxS6/bPd8Z3qCC3j GgPvMDmw3B+5L5SFeLgE54aDinIUH28rWWBrINin1HvaRontj+8vzjirVHEepAGjfnHE emH702MMk0SIv/08kSE6+rPRZSo177ULBV/vUoko6P1ut5DsHIasfI7t/dNuGKC//SxI JsJvgcfv7N8JkMqT+d0gJMydL9aPpBG/B+oRWOp5fvyiu1AyDdlA4VE0KmlH+NLKaA11 HhGVksNI7xOsflX43pvkwHsSoKgsNgl5y/JBuZE4fgJHPLHd2aTXD7NBGABMwtgv/2ZK Q/bw==
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=cWfF134QotqenzzWAreaNH0oh6f6SVpYCwDOiHK5Je0=; b=HkPccagO1Pg8m0zTSMMTEqIBBPTs5/m49xk+pz9l9wUjm2pNhYGuD/aLb6QDYQmrI5 W3Ie5fli+wjiLZiim1OhSsg2VYpKQ5gzAJt5n/aNWWD+psF9qNap7kuAmcOJUYhYl8KY Am29kKDyEY4Us4OyQBtUfBLW4TxfuFCRco2NDQCKFiWCRLIMSRMhsmQyDcFYjm6wBVgB XlRIesghPGq1eBppiV3JZ9Kyl//q2hnmXn5AIDjSIM4hAljnH9ckqPom4VxTlLbTRigV R24en3Vg7bvtdVxdPYvGz5BH6kffKd196LDvuxDWHVvy2A/ZpKSQ2QYj9YzBp53XmMST 2gLQ==
X-Gm-Message-State: AIVw110NsFyOmQbCGsLUnYh2qUKfem+kJrPb18zSkDlZ9m1kWMIfwo7b U5Dhyo677cLn5OAVW1mP2CDj/fV/Kg==
X-Received: by 10.107.138.17 with SMTP id m17mr1390621iod.155.1499415464781; Fri, 07 Jul 2017 01:17:44 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.32.15 with HTTP; Fri, 7 Jul 2017 01:17:43 -0700 (PDT)
In-Reply-To: <390074f5-d322-c32e-cb63-dc0f0b07d428@nipper.de>
References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <FBD5248C-33C6-436C-8B01-FAE2658B0768@juniper.net> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <m2van9z3jp.wl-randy@psg.com> <CACWOCC8tPVD20SJ60h-=NGbPMG3Fae2a0TY5rMFb=EnN7H-C6Q@mail.gmail.com> <m2o9t1z1hj.wl-randy@psg.com> <CACWOCC_bQitHeR9tHc5tPsXmoSDDLQH764equTAHrP854fYh-A@mail.gmail.com> <BF65C4DC-D2F5-41AF-8454-D43B403E328B@juniper.net> <CACWOCC9cmz7ARnWNowCCEu3Rt_NiyuWgJMZ3pWfmxZ_BO8Ovjw@mail.gmail.com> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <CA+b+ERkHehpgXS3UaQAW+KQ1ak9j=wx-=wbtQ6ZiW-LQu2Z4fA@mail.gmail.com> <A35C87AE-364D-462F-AE27-A8E2DF693BDA@juniper.net> <CA+b+ERkz6suMQ=KL0Y4bvE5_HwXfEr9TpY_L1RBBKr0V2H9T3g@mail.gmail.com> <390074f5-d322-c32e-cb63-dc0f0b07d428@nipper.de>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 7 Jul 2017 10:17:43 +0200
X-Google-Sender-Auth: hJQ6Bwa-O957FDD-1CMcLzuARnk
Message-ID: <CA+b+ER=O2pgC3SKxpr34HuMwBOO_d7+UBe1OVDpWKJqOi_nHsw@mail.gmail.com>
To: Arnold Nipper <arnold@nipper.de>
Cc: "John G. Scudder" <jgs@juniper.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fea802638e80553b5de37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/h_Fa9wsJ85vnErdVeXgWFEv3RIY>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.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: Fri, 07 Jul 2017 08:17:48 -0000

Hi Arnold,

vast majority run BIRD as RS and it is BCP to do per client (ASN) best path


​Perhaps it is a Common Practice but it is hardly "​Best" one. That must be
why so many folks already complain today about their RS scaling issues.

Copying OPEN policy nets and paths to individual per client views seems
very suboptimal for RS design. Well you get what you paid for :).

To contrast that let me remind everyone that Route Server design in Cisco
IOS XE keep all common policy paths in single global BGP "view" and only
when there is static or dynamic (by communities) policy moves subject to
policy paths to individual views. So clients get sigma of per view + global
updates. And you can run on your existing x86 RS blade too.

The draft under discussion breaks this design and its scaling properties.

Now to someone who mentioned that this is all about weak client routers
let's face the numbers.

The data from various route servers (two in Asia, one in EU and one in US)
I have captured recently show:

IX1 - 250K IPv4 total paths
IX2 - 167K IPv4 total paths
IX3 - 50K IPv4 total paths
IX4 - 30K IPv4 total paths

So with 120 bytes per path (this is size of BGP path data structure in
efficient BGP code base) even if you send all clients all paths with
add-paths you need on client control plane total RAM of:

IX1 -  30 MB RAM
IX2 -  20 MB RAM
IX3 -  6 MB RAM
IX4 - 3.5 MB RAM

​So what problem is this draft trying to solve ? Save max 10s of ​MB of RAM
on the client ?

Note also that even add-paths is optional. Most IX already today have two
Route Servers. So it is trivial to have such one route-server to act as
primary sending overall best path and second one acting as backup sending
2nd best. (The IOS XE definition of second best mandates different next hop
then overall all best).

All what is needed is few implementation twicks in your RS code vendor to
address the problem at hand.

Cheers,
Robert.