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

Robert Raszuk <robert@raszuk.net> Wed, 15 March 2017 09:13 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 789BB12999D for <idr@ietfa.amsl.com>; Wed, 15 Mar 2017 02:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 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, 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 UIqAhcVexsuK for <idr@ietfa.amsl.com>; Wed, 15 Mar 2017 02:13:31 -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 8844612999F for <idr@ietf.org>; Wed, 15 Mar 2017 02:13:31 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id r45so7419862qte.3 for <idr@ietf.org>; Wed, 15 Mar 2017 02:13:31 -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=d5+8+lldPqX37cWD8niSorna8uA1V16AUGzl7wsg5V8=; b=X3qd7KIAbOr0O7WQEosnJQkarc1waUTVR4YKSpjDT0tM+AELUk7Rudg8rHt3Xl16R3 h+3IzUX2bA8OLy3rcBaHwAET2AnkOM+WQFJPED99VbHSdRCrXs7poA2HVJ/sX/TrMiZh c9nD06AjjPuRj2x3q4fFQRuZFlT7ECYOgKqnscVb21qMtXD/QLFUsOsqaEiixfMSw9/9 q8rIi8NrY3Rv/VBbVV1bq5rHwu6jtjkao04do8259GDCZVKjpuFxbImeLm7BcC5ufucN js1YFOW7UkFNrxr5eg9oCuu1kgsJZ+z+BCSF4/g32sDaYZJlR0gCqZ2C8kckNF8RcP+d E6kA==
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=d5+8+lldPqX37cWD8niSorna8uA1V16AUGzl7wsg5V8=; b=eBCNrvH/aygtkGFRgbaa+1Fy4yAdCqc9uh/Ly5yN2tA580xI2/+9CklwzKFZ91rkCL 6ugE2DINQ4jfhv7s8zA2IYfoeQJc3cyN6HfKGUQjg5uXm7d6iMRf+jbTYqkOHhBAeNoF j8iCKk/1qjMv/Pieo69zk9FYezM1lWOUv6vZFuBrH61VIrWBHciVW3xHOoVWRB4azgCO 61zKDmOC2QtxNuf9Rzo3rmuH/L6FXiuMIZb5tfrI+qKgk0lTYF+RHtn1bO8jlskGpFfG MVWkxYCFZp1sjgVGRoRoMdUZAMnyB3S1xUYrgaAX9hLiSAfiY7b5e+8N/JCfI6qwLzvo ZXTQ==
X-Gm-Message-State: AFeK/H36gR0zxD4JZFDnjhvrPcXzBzPo/RfHUZ9wvNKtzJ2ZDzSU0boUNBDoJFwpxT32SQGTaD99VDEU5SGUVg==
X-Received: by 10.237.37.121 with SMTP id w54mr1963661qtc.14.1489569210505; Wed, 15 Mar 2017 02:13:30 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Wed, 15 Mar 2017 02:13:29 -0700 (PDT)
In-Reply-To: <20170315000326.GO12864@pfrc.org>
References: <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> <CA+b+ERkt6MJUPR-4WX0LYZ9CG1FoNX-g4=hnqFB9iQy8WfKOww@mail.gmail.com> <20170315000326.GO12864@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 15 Mar 2017 10:13:29 +0100
X-Google-Sender-Auth: BLkOEVHZz0xHgTBigSRVVGa4IgI
Message-ID: <CA+b+ERmWUL-pVwjW8Vq+Vz8UzYDpcVBZxxhtM6WFqhmG+r35WA@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a1140f782a9206d054ac15bd2
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Z3Fg-whkDUYyGHORkfk6r2dNtko>
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: Wed, 15 Mar 2017 09:13:34 -0000

> This is no worse than an IGP event.

Well that in fact brings another alternative ... why not to simply run a
separate instance of ISIS over IX open LAN fabric interfaces ?

DIS could be on RS and even with basic hellos both RS and remote clients
will know about client being unreachable. If someone wants you can run BFD
to speed things up as well.

That addresses the reported problem without need for RS SAFI and for those
who do not want more then single path speeds up connectivity restoration
etc ... Even for those who have more then one path if ISIS timers are
enough they do not need to run BFD any more to all next hops.

Moreover *modern* IX operators will soon start adding value add services
(example: DDoS protection) for their customers for a little extra fee per
month. That in turn will be much simpler to be deployed with service chain
and IGP local flooding of for example SIDs.

Has that approach been considered here ? Again just like with data plane
gateway proposal this requires zero change on the client side and is just a
control plane config touch.

Best,
r.


On Wed, Mar 15, 2017 at 1:03 AM, Jeffrey Haas <jhaas@pfrc.org>; wrote:

> On Wed, Mar 15, 2017 at 12:08:50AM +0100, Robert Raszuk wrote:
> > 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
>
> But then you're not using a secondary RS for redundancy of your best path.
> (That may be fine.)
>
> > - 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
>
> RS operators will have to speak to what sort of policies they want, but
> this
> *does* impact what a RS chooses to do with a declaration of unreachability
> from one peer in a peer group:
> - Does it try to split the group for that peer? (Unrealistic, IMO.)
> - Does it de-pref routes with that nexthop for *all* peers on the
>   presumption that something bad has happened that the other peers haven't
>   noticed yet?
>
> Etc.
>
> Good topic for further discussion.
>
> > - BFD sessions to next hops will require per next hop MD5 for security
>
> The use of BFD security mechanisms in general is an interesting question.
> Thankfully the suggested BFD timers here are very slow which helps the
> session scaling.
>
> > - 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
>
> A significant enough fabric event will simply lose the peering sessions to
> the RS in the first place.  But losing entire "sides" of clients happens.
>
> > - 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 ?
>
> This is no worse than an IGP event.
>
> > - BFD on clients needs to work in non protocol associated mode.
> >
> > ... and I am pretty sure this is just the starter.
>
> And good fodder for discussion from IX operators.
>
> >
> > 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
> > >
>