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

Robert Raszuk <robert@raszuk.net> Tue, 14 March 2017 15:04 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 1CC901294EB for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 08:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 uizpRp9Rpxcl for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 08:04:17 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 5A7EA1294E7 for <idr@ietf.org>; Tue, 14 Mar 2017 08:04:17 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id v125so245118267qkh.2 for <idr@ietf.org>; Tue, 14 Mar 2017 08:04:17 -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=0sI4JAsaPFZDdnH7jAXtE4z8RchkXI/Ao1ygeQHtZ+8=; b=Z8xlOC+8qG5VUxeoEdjwnw/O0ztfS+nqsWIwyV3ryyk2X/ahtKAXaUsfCYRgzTiXCO hDyx0mpbonAj9CUtrPIK9b5b49O23MaTiwXjFCgfQa6xR9LJtSryLabpXMNFbqvJyH5V XzWPwNwumC1sulsImhX+TECFenn+pV8oAGh461wmvOLn09yxBpMiiIhLnxDV7NiRC7VM cF0T39pgs3y+RjU36xMUaBqdRk7g75k4NQd7Vy1x8mLVfS4so7G/eObIBQkhfDCJgCIF 1p/HtfYCM8J4tOzJcA4SUJ/GYZUCRhH2VtHACqdEzPhYF4Ids1KDCpd0ssIkHiik5FRm nPww==
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=0sI4JAsaPFZDdnH7jAXtE4z8RchkXI/Ao1ygeQHtZ+8=; b=HjttYfn/eLYDh9Z8izWpp4oOkcQLNWEy4tDBQpfSuUaPjmCs6ep12DE3fLcnMs69Gu xiTjgY84cS2DTKihRIEqx1XWDJj4ohtO/XT/sxKEnCQ2ohzTJGFAtBrOcQIt5rq+62PQ FA5gWV6WMLHpJMcBiPSjD+exaT4tkXYFGsyJOpuA47TFAKINg0VPl1vpTSNdlGKzUZyJ 97+tmkLNg0kbA6o6plG67HUtVDgSFShjPoA0z9U5Uuggl/YjtGVexDjNPbGxfZrJon2N Nn0JrVR83Iw3brY0BnpBPoO5QwwkktGVnFPqBMD/BkOGMbW3vuu+d3sK9+PRj0voaT6n 8FzQ==
X-Gm-Message-State: AFeK/H23SkXJE8Pj5xKjaVlnnsT1BmJmJU+xNn4oxWpM1hyAFOrOxvQWLIv80eYwz7Hwd1R329RXLJMQiVhqgQ==
X-Received: by 10.55.18.158 with SMTP id 30mr39544396qks.123.1489503856434; Tue, 14 Mar 2017 08:04:16 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 08:04:15 -0700 (PDT)
In-Reply-To: <20170314144330.GA48058@excession.tpb.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> <20170314144330.GA48058@excession.tpb.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 14 Mar 2017 16:04:15 +0100
X-Google-Sender-Auth: T9_JpY_ilTQRhSKaERY2h_zAs_c
Message-ID: <CA+b+ER=+C=1=orPCXPdsb+ADaD-E45ti9f2fjKMBy4OopxxW5g@mail.gmail.com>
To: Niels Bakker <niels@bakker.net>
Cc: idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a1146f482412999054ab2244e
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_5TZW4zvPmoNaTGt6_n2Ra06lSM>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.21
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 15:04:20 -0000

Not sure if we should continue this thread  ....  I think all what needs to
be said has been said already regarding proposed draft. But just to clarify
on your questions:



> 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 would require a major rearchitecting of pretty much all network
> components out there because we'd be doing away with the concept of having
> one best path that's chosen by each hop handling a packet.


​When IX client advertises​ a route to Route Server it will still advertise
best path only as he sets nhs. When RS today already import to per client
bRIB all paths (if available) and selects best then advertises it to all
peers (subject to policy).

Only change is needed is to advertise with either add-paths or diverse-path
second best. No major change at all. One line config on existing routers.


​N​
>> ow 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.
>>
>
> As Nick said, not even wrong.
>
> Route servers decouple the forwarding plane from the control plane in an
> additional way beyond what already happens inside routers for hardware
> design reasons.


​I am not saying that Route Servers should be doing forwarding ... if this
is what you are trying to address by the above comment.

RS would send all paths they know ​about to device which will act as a
forwarder in the middle of IX. Sitting close or being a function of L3
forwarding on the switch allows to have all weak clients go via such pair
of routers. No suboptimal routing as packets go via the switch anyway, no
1000 x 1000 BFD sessions between all clients, quick local repair in case of
path failure ... and such device could be used only for those open policy
destinations which do have more then one path in the first place.

Yes this is not the model IX do today ... but is this sufficient reason to
dismiss it - provided above basic solution of sending more then best path
would perhaps be not feasible.

Thx,
R.



> This draft seeks to add a mechanism to signal any dislocations, improving
> robustness of existing deployments.
>
> Regards,
>
>
>         -- Niels (former IXP operator, current IXP participant hat)
>
> --
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>