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

Robert Raszuk <robert@raszuk.net> Tue, 14 March 2017 23:08 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 06439129B23 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 16:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[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 LszM9tSxzzOA for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 16:08:52 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 615EE129440 for <idr@ietf.org>; Tue, 14 Mar 2017 16:08:52 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id n21so637740qta.1 for <idr@ietf.org>; Tue, 14 Mar 2017 16:08:52 -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=3MUHRUOGgdgIv3Hes/TcIScOCTiYXrt57Xf5yJljmoE=; b=RP5WjaEUqSntEElxrB+rMQUmOijcnWX3lMwlTRjaEN7kENQt4sU9Q79r8HgjKKi5rf PfB6CoSIeUqHi0+DNZG8BEXe/StfGYPRC9CI20z2y72NxUP8gn8BfY4CxVfhD8Wf30QL HaWyoKU/5PDFuXKtHIWZqPUwH1Kr/gJZhx3Eqf3iKa++lo+mBbmnHLIa0n6Vg4rpNe/p SL+edtEIJUHG8jz1wvv8UmCNJjqXHwpiyzR5dGVCuBSC1CnegJT/LMlq1R+ibCwXwtbX UsSZwwIrpXQidmeBslBszqWfK4V/kRRiL96S8NU6cE/M1+8eHUn6Ygtox5qn9sU55tOy 2q4g==
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=3MUHRUOGgdgIv3Hes/TcIScOCTiYXrt57Xf5yJljmoE=; b=fIOJ7eTwiL1xoXyYhykHKWpxM/aOj0CLogz9fQCUhgE5tWxjzf2lIh+/DceV0pbXNB WkuMCZt1VmvycFXJDHuhAdj3TxAx8o75WePl8mwVgXRinNazDZjrhSd4S9gx1eAu+QK6 +fbP8eB8TUzM7qnoNUq/Oy8C+KVzmDf7HMV2JPiJyjoCECGfUBThmaIOeEumBhdxV4o+ pXpWaIq5jdDB/HeaYFMSvQep4c+6K0CJU7/NKjXgrXC3yfMh0OBe825AOURU7j63n1Vr OUMw4R3X+oMRChqG0vZXf4+i2ty2kHMhZyRP1hnlUZ67A2LKHK5roWcUPcuSL3b1d0rv /ePg==
X-Gm-Message-State: AFeK/H3nWO29fV9JMO0qPJ3W85I2xJPuFn71IVB6bQ/nGXT2Z4gPqon/8O++6x+/q8vidNRCmo9uWVgvvWpqnQ==
X-Received: by 10.200.62.145 with SMTP id y17mr156589qtf.53.1489532931539; Tue, 14 Mar 2017 16:08:51 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 16:08:50 -0700 (PDT)
In-Reply-To: <20170314225855.GN12864@pfrc.org>
References: <CA+b+ERnBL9Q3ep1JrC9HQp3B3AYmiQ8ctTssK1g4L_ueTTRaMQ@mail.gmail.com> <CA+b+ER=cZiBfWj4=+uKeqsWwypGFz3p+Tvx8Q2dD3hFFXSC4=w@mail.gmail.com> <CA+b+ER=f-S118JtY--n-B0P+CB0yvy_rw3JaJpWw02n7prQ=Ww@mail.gmail.com> <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <CA+b+ERmLDNzF=TofW=w1OwUzeLGUc-3muMckHTH6Rs=c8rc5bQ@mail.gmail.com> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <CA+b+ERmMOyqb8HFtNXyDr8e+MNxA7EWmJFukUNgSjAU+69f5CA@mail.gmail.com> <20170314225855.GN12864@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 15 Mar 2017 00:08:50 +0100
X-Google-Sender-Auth: weT5IESoxqy9Wst-QZn74T7FN-c
Message-ID: <CA+b+ERkt6MJUPR-4WX0LYZ9CG1FoNX-g4=hnqFB9iQy8WfKOww@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Job Snijders <job@instituut.net>, "Rajiv Asati (rajiva)" <rajiva@cisco.com>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=f403045e6b28440ad8054ab8e97b
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jrBxRrsOCXKGrp2wBvktLb1vbfE>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.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: Tue, 14 Mar 2017 23:08:54 -0000

Ok so we have history covered :)

- - -

Apart of that the more I think about this the more reasons pop-up which
question both justification and value in informing RS about next hop
reachability from clients to clients of Internet Exchanges.

Let's summarize those again:

- RS may not have other paths

- RS may send more then best path to clients

- RS come in pairs and it is trivial to send different paths from each of
the RS with zero upgrade to clients

- RS clients are grouped per their policies .. per client RIB requires a
lot of overhead on route servers to address the case where only one client
in the group suffers from some unreachable next hop

- BFD sessions to next hops will require per next hop MD5 for security

- IX have often more then one lan ... say 1500 and 9000 MTU. Next hops
again may be different on both.

- BFD session timers can't be unified on the clients as some clients are
local and some remote. Remote both in the case of distributed IX as well as
in the case of IX customers just connecting to IX with fiber without any
*local* metal.

- Clients will likely report churn of the same next hop being unreachable
reasonable in the same time

- When client reports unreachable next hop to RS .. it removes the path
from client's RIB. But when does it add it again ? Note eBGP to RS are all
fine .. would clients now not only keep BFD sessions to active peers but
also trying to establish BFD to unreachable peers then notify RS that the
peer is back ?

- BFD on clients needs to work in non protocol associated mode.

... and I am pretty sure this is just the starter.

r.





On Tue, Mar 14, 2017 at 11:58 PM, Jeffrey Haas <jhaas@pfrc.org>; wrote:

> On Tue, Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote:
> > And just for the record here the idea for NH SAFI has been proposed by
> Ilya
> > & myself in 2012 ...
> >
> > https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-cost-00
>
> rs-bfd started with that as a likely way to handle carrying the RS state.
> However, we reached two conclusions:
> - the draft was inactive.
> - and even if we used it, it was an awkward fit for the mechanism.
>
> https://www.ietf.org/proceedings/93/slides/slides-93-idr-3.pdf
>
> Similarly, BGP-LS was given a try and decided to be too heavy weight.
>
> So, we're closer to where we started. :-)
>
> -- Jeff
>