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

Robert Raszuk <robert@raszuk.net> Sun, 16 April 2017 20:34 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 E6A011293E3 for <idr@ietfa.amsl.com>; Sun, 16 Apr 2017 13:34:53 -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 y6qUPhHwRlEo for <idr@ietfa.amsl.com>; Sun, 16 Apr 2017 13:34:52 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 4C2871292D0 for <idr@ietf.org>; Sun, 16 Apr 2017 13:34:51 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id k87so114885379ioi.0 for <idr@ietf.org>; Sun, 16 Apr 2017 13:34:51 -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=Y4XEuA2xzhVU/8y3iU4ZBuK3svNdx9dFjXRf87kA/Pw=; b=IZBZFJlhORx1WuPQfbRpbnomKeQEbVswtN8GZEcAjVYvX5P8I3a4+Ibs4YC9kuGogm VnRXXTFVKpL9ir+ZhziVdRxU2oi2OwoBG0LiUIZxsMHHRtegOzgLJEbDw2VM+juhjLKD 5Sr+nXoKGtaSQmN28ZHgcUzkeHe6FOwdUaSYdv7m1EA13bBpvWnUhVLSAVXuYYtKgXim ZcDcOWFooVCGNMxr2SD2uSzOK3Rebd11yhiKRHdDlgdClbd5LUisyjK3qwCrePmaSdiv jIKC5zQnSD+v0AEjJ5DY47G0YYJ1/zNIHaNC1Jq0zFcUp4PafgesmmDQubn6tkNDMzS1 F21A==
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=Y4XEuA2xzhVU/8y3iU4ZBuK3svNdx9dFjXRf87kA/Pw=; b=cRUIKLCjs4PvLIGv5SDmoXg2Sn0bki7o8PyHXZTTl2fQz+J+zSGZauXj8xQpu1j6an HBUGfZMzOSwS2NF4CLs3K1AS6XR+ZdbRAARmow09jTHWN61h2NB41K/Xwa51R209zx8C SpDa2mrZes3O467jVWSpAFjuR68yg+4Jd/wU8c94ytsbQ4NQ91/ratQEppShiO5DFqgF 7lFsj8OyA8+D5/p3HlbxbYrVeFB/SyM1iCNX3gDQkDoYvaSVAQKwPKhirAbUGhUNRm+n 7qUypgPQsSNaphSzsH8ue7rRdDGzPestiYFR7DOkUlA1ks+qbc7/bUb6AMizHapy4lkd PtTQ==
X-Gm-Message-State: AN3rC/5iiW2HehoFLM/g4Y6lhHwJFNgoJSNis/Bnu7EhN4ijBczF3Zst r1eMJYHTLy+Evt0G7WL3yDFiRLFWaA==
X-Received: by 10.107.16.135 with SMTP id 7mr6497841ioq.228.1492374890610; Sun, 16 Apr 2017 13:34:50 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Sun, 16 Apr 2017 13:34:49 -0700 (PDT)
Received: by 10.79.170.4 with HTTP; Sun, 16 Apr 2017 13:34:49 -0700 (PDT)
In-Reply-To: <579D00D9-D80F-4625-BF16-0D5112C2FA98@cisco.com>
References: <CA+b+ERmmqtUkJMtfOE9ABFHN0gNdztjOGELmirNgWRnDENrjaA@mail.gmail.com> <58C6751D.60306@foobar.org> <CA+b+ERkxvKzArYf7eefB5UL_kDMVBJERz=Qyi=zOsBm3KivAtg@mail.gmail.com> <CA+b+ERn5o-i-6shdzj_afa8Z1yQO3Ep6HmB=Fv4StSW_ge95Ew@mail.gmail.com> <CA+b+ERkBeBoz0Le4wgqZK1X76=_HKOEUYTWYBd_xnjYoaJgrsw@mail.gmail.com> <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> <579D00D9-D80F-4625-BF16-0D5112C2FA98@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 16 Apr 2017 22:34:49 +0200
X-Google-Sender-Auth: UgvHdLiJZCjCJG60VUw5DzRXae4
Message-ID: <CA+b+ERkXLg3O0hEAtokUDn4ndjixyuT4dpv9LfLVPmfsb1akug@mail.gmail.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Cc: PFRC - jhaas <jhaas@pfrc.org>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fe9c23a08d8054d4e9bdb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CuRb7-TzdJUoSa-QlkixHjd37Bo>
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: Sun, 16 Apr 2017 20:34:54 -0000

Rajiv,

I think that everyone fully agrees that in order to consider prefix as
valid the next hop to it should be reachable.

The only open question is how to detect it when you have no direct protocol
adj. established.

Jeff seems stuck with BFD .. but there is number of folks who see S-BFD as
much better fit to the problem. Yet UDP echo in some implementations
already does it today.

I think we need to evaluate pros and cons of all options before making any
more formal recommendation. At this point however I think 7880 fits best.

Kind regards,
R.



On Apr 16, 2017 10:12 PM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:

> Hi Jeff,
>
>
> >   But more importantly, you'll stop sending it toward your own peering
> and
> >   attracting blackholed traffic.
>
> Indeed. That’s key.
>
> And it could rely on the route resolvability condition to be appropriately
> modified, as described in
> https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria
> .
>
> >    RS-BFD basically reinvents the same procedure in your draft, simply
> being
> >    specific about the use of BFD as the dataplane liveness check
> mechanism.
> >    However, as you note in the RS-BFD draft, we do leave the option for
> other
> >    mechanisms.
> >
> >    I suspect the other authors of RS-BFD aren't particular where we pick
> up our
> >    text for the resolvability condition.  However, if the suggestion is
> to make
> >   a reference to your draft, you'll need to bring it back from zombie
> state
> >    and progress it. :-)
>
> Agreed. It is alive (-07 version). https://tools.ietf.org/html/
> draft-ietf-idr-bgp-bestpath-selection-criteria-07
> It can be used as a normative reference in your draft.
>
> --
> Cheers,
> Rajiv Asati
> Distinguished Engineer, Cisco
>
> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>
> Date: Tuesday, March 14, 2017 at 5:36 PM
> To: Rajiv Asati <rajiva@cisco.com>
> Cc: "robert@raszuk.net" <robert@raszuk.net>, "idr@ietf.org" <idr@ietf.org>
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
>
>     Rajiv,
>
>     On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote:
>     > Is the assumption here that the client routers have routing view
> limited to what’s provided by the Route Server? If not, then wouldn’t
> Client Routers benefit from having to invalidate the path learned from the
> remote client router as soon as the connectivity check failed?
>
>     This is what I believe the procedure says.  See section 6.
>
>     > Of course, Client Routers conveying the lack of NLRI reachability
> per NH to the Route Server, and expecting Route Server to provide a
> different NHs of the NLRIs, and expecting it to be functional, while still
> attracting the traffic for unreachable destinations since the Loc-RIB is
> still pointing to the unreachable NH for the affected NLRIs.
>
>     The thing that is somewhat different for a IXP environment running a
> route
>     server than normal eBGP is the low (to zero) likelihood of having a
> backup
>     path.  If 10/8 was learned from the route server for nexthop
> 192.0.2.1, and
>     you stop being able to reach that nexthop, removing it from your
> forwarding
>     (unreachable) is your only choice.
>
>     You *might* have a source of that path internally.  In that case, you
> can
>     use it.
>
>     But more importantly, you'll stop sending it toward your own peering
> and
>     attracting blackholed traffic.
>
>     > I wonder whether  https://tools.ietf.org/html/
> draft-ietf-idr-bgp-bestpath-selection-criteria be useful here.
>
>     In a sense of good timing, John Scudder had brought this to my
> attention
>     about an hour ago.
>
>     RS-BFD basically reinvents the same procedure in your draft, simply
> being
>     specific about the use of BFD as the dataplane liveness check
> mechanism.
>     However, as you note in the RS-BFD draft, we do leave the option for
> other
>     mechanisms.
>
>     I suspect the other authors of RS-BFD aren't particular where we pick
> up our
>     text for the resolvability condition.  However, if the suggestion is
> to make
>     a reference to your draft, you'll need to bring it back from zombie
> state
>     and progress it. :-)
>
>     -- Jeff
>
>
>