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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Tue, 18 April 2017 04:09 UTC

Return-Path: <rajiva@cisco.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 29D8B1270A7 for <idr@ietfa.amsl.com>; Mon, 17 Apr 2017 21:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 OCMCGaLZa2nx for <idr@ietfa.amsl.com>; Mon, 17 Apr 2017 21:09:31 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8DC120454 for <idr@ietf.org>; Mon, 17 Apr 2017 21:09:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7962; q=dns/txt; s=iport; t=1492488571; x=1493698171; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Cl9tlWgfmr4+BSkJyLIA5DOLfRDqnPuUc1bjtE+j1Ik=; b=NULpfPwQWzev6T8yMz467gwR84WYRyEiPky2vMueAE6T0djQ1AKplVQQ ygiGXK4dTQvmwqMJTvmSCJsK4G6ZhoyVbercU4HC3xnPFUQSpkBxsa63k ySZzWVQA1G0fHG2UNOUNO1gmIoDv8VUAYhMdAV7ZMXbCDY3F2Uj91XxfV w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAgBFkPVY/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KFZE+IYgdjUKCDy6FdgIag2s/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEjEUUFBwQCAQgRAwECAQICJgICAh8RFQgIAgQOBYl/Aw0IDqpMg?= =?us-ascii?q?iaHNw2DXQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFR4FcASsKgVmBCoJRgU8?= =?us-ascii?q?TDhYXD4JgLoIxBYZ3giyIJIsZOwGHA4MsgyhKhESRRosHiQIBHziBBWMVVQGGU?= =?us-ascii?q?3WGXoEwgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.37,217,1488844800"; d="scan'208";a="232289720"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 04:09:30 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3I49Tli021425 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2017 04:09:29 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 23:09:29 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 23:09:29 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
CC: PFRC - jhaas <jhaas@pfrc.org>, idr wg <idr@ietf.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
Thread-Index: AQHSmnRjZQMhW6yq5kum3Hd4lOeZoKGSjLmAgABQ7oCAAAtWgP//sAtXgAKMygD//8REAIAASs2AgDN6BYCAAFHJgIABzk4A
Date: Tue, 18 Apr 2017 04:09:29 +0000
Message-ID: <9D31CFD8-48AC-4115-9485-47E3ABC018EF@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> <CA+b+ERkXLg3O0hEAtokUDn4ndjixyuT4dpv9LfLVPmfsb1akug@mail.gmail.com>
In-Reply-To: <CA+b+ERkXLg3O0hEAtokUDn4ndjixyuT4dpv9LfLVPmfsb1akug@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.225.205]
Content-Type: text/plain; charset="utf-8"
Content-ID: <30610E610F085A43AAE3630EBBC9A014@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mvanTqdqA4gFT0TnU_ahFJ-BCNs>
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, 18 Apr 2017 04:09:33 -0000

Hi Robert,

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

Indeed. 

> 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.

UDP echo as in IP SLA?



>    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.

RFC7881 to be exact (since it defines procedures for using S-BFD usage in IPv4, IPv6, and MPLS environments).
RFC7880 describes a generalized mechanism.
-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: <rraszuk@gmail.com>; on behalf of "robert@raszuk.net"; <robert@raszuk.net>;
Date: Sunday, April 16, 2017 at 4:34 PM
To: Rajiv Asati <rajiva@cisco.com>;
Cc: PFRC - jhaas <jhaas@pfrc.org>;, "idr@ietf.org"; <idr@ietf.org>;
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

    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 <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 <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