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

Robert Raszuk <robert@raszuk.net> Mon, 13 March 2017 09:51 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 8A2C3129566 for <idr@ietfa.amsl.com>; Mon, 13 Mar 2017 02:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 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, URIBL_BLOCKED=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 KVeItY9PivnZ for <idr@ietfa.amsl.com>; Mon, 13 Mar 2017 02:51:25 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 462B21294F7 for <idr@ietf.org>; Mon, 13 Mar 2017 02:51:25 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id y76so218153135qkb.0 for <idr@ietf.org>; Mon, 13 Mar 2017 02:51:25 -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=426XpXmuD6XjcW4pOpFG6GYFfHGKbez1taGdf7U33nU=; b=l/9x2fPHTGiaCRY5qdZg0p9hSa7LNRmnVJYnoYYrPtkhnFnq49JgGre3qRHNgBUfyK PM0aIbxgFmsU7CFvps8Dk6uOwarvovUmEDZ3GvhJ6BCR1THXs3m+aFtFsgVET8DF8iRY pQagQSNTfcOCUDwkezWif+320m6atjTtfDuZr0ZcexsFkTAPoF25+O9+dTY1YJAv9nLv h4rgbN6BzwvZ/6V1OWYLZ4k3fTzgNLTJNLW7dE/axS3uzmwQ0j9o2c3MUbdk6RL1JA89 Hb3W+dYVkAWEmN+caUts9bPV1qtAzPLe1eD7GLBPqPl/NRJxAd4U1A0vGQJ53ZKopNSF EBYA==
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=426XpXmuD6XjcW4pOpFG6GYFfHGKbez1taGdf7U33nU=; b=d8wrZ//flkCP4ROY3S5NLSw7KN6XLRG/MtAuUTF21ty5C/uo/CDN2LyoCK2rs9IkTt nlHmIQ/QWH/nicYTacQmSdcOKZdC2S+bWCYCgWnHB/NDsA1qRqtAhVnhgptb9ltNdICg ezfyBu+ZxWsNRlfp6NGdnT+gcZ9EWXafJUKy9daYFKVCSVOAzweeBAHuupb3BErZW5UG tErkWQxgGwS9yO5E9pUggaGKqFdj2CUPYugf5QAY0rHEKeXxegbILoNCc5HPgSmhDuPf nL52CBXP9Jb/+2eXJjbSzR99W23SRaT0PxYAvuW1JpuwG+555I+pwTEsAeiaK9ViBkpo grvg==
X-Gm-Message-State: AMke39nrJIhz26rcSur/p2PujWz5tuwO90tl8XAqmKpTotwIkGf8ixUo/DUnn80xtFWvgNzo4wX+Oc39RVi1yA==
X-Received: by 10.55.128.66 with SMTP id b63mr33284690qkd.297.1489398684315; Mon, 13 Mar 2017 02:51:24 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Mon, 13 Mar 2017 02:51:23 -0700 (PDT)
In-Reply-To: <m2k27tzs5k.wl-randy@psg.com>
References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <m2k27tzs5k.wl-randy@psg.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 13 Mar 2017 10:51:23 +0100
X-Google-Sender-Auth: OceeoE6G_DtOymndsEjXhSGNV4k
Message-ID: <CA+b+ERmmqtUkJMtfOE9ABFHN0gNdztjOGELmirNgWRnDENrjaA@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Content-Type: multipart/alternative; boundary=94eb2c06654c81fe3b054a99a7e6
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/S5hRujNzJyczeA3KaDA6J4OThkM>
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: Mon, 13 Mar 2017 09:51:27 -0000

Hi Randy & authors of this document,

Major comment:

Let's observe that the ultimate objective of this draft (and in fact much
more) can be achieved by assuring that clients receive more then one path
to given bgp destinations at normal operation.

That direction has been proven to work much more effectively in all other
scenarios which require fast connectivity restoration as opposed to
counting on control plane "convergence".

The following alternative techniques can be used to distribute more then
just best path between BGP clients:

*A* Use of add-paths RFC7911 from RS to clients (with eBGP support
extension)

*B* Use of diverse-path RFC6774 from RS to clients

*C* Direct EBGP peering between clients with the help of BGP Auto Discovery
https://goo.gl/KKgqfU  (now with merged work of Automagic peering at IXPs:
https://goo.gl/RJIKYM)

Let's also notice that in IX folks peering via RS have open or selective
peering policy and they send at most their clients + internal routes.
Therefor for any given b_net there will be no more then few paths. There is
no Transit Internet open peering via RS or very often even via IX.

This will allow all clients to quickly switch over to backup path which
would be with PIC already present in their data plane ahead of failure.

Moreover this will reduce churn and convergence delay when say 1000 clients
in one shot is bombarding RS using new proposed SAFI of the very same
client router going down.

Also let's keep in mind that modern routing stacks allow to much more
intelligent routing by actively and passively monitoring all alternative
paths to your interesting destinations and based on the quality of the data
plane via any peer choose the best path. That with just getting a single
path at a time is simply not possible as those "interesting destinations"
are not BGP next hops, but applications servers sitting one or more ASes
far from client.


Minor comment:

Today BFD sessions last time I checked must be bounded to a protocol. In
current IX+RS model there is no direct protocol between clients. Hence BFD
implementations on the clients needs to be augmented to auto peer with all
BGP next hops received over eBGP sessions to RS. Not impossible and in fact
perhaps good feature on its own .. but needs to be supported on all clients
just like the new SAFI draft proposes.

Kind regards,
Robert








On Mon, Mar 13, 2017 at 6:01 AM, Randy Bush <randy@psg.com>; wrote:

> note that this version is rather different and warrants reading.
>
> randy
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>