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

Nick Hilliard <nick@foobar.org> Thu, 20 April 2017 11:31 UTC

Return-Path: <nick@foobar.org>
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 AC4D812949D for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 04:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4iPlilV8dsvT for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 04:31:22 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D271293F3 for <idr@ietf.org>; Thu, 20 Apr 2017 04:31:22 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v3KBVJdS043809 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Apr 2017 12:31:19 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <58F89C07.8080900@foobar.org>
Date: Thu, 20 Apr 2017 12:31:19 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.12 (Macintosh/20170323)
MIME-Version: 1.0
To: Robert Raszuk <robert@raszuk.net>
CC: Jeffrey Haas <jhaas@pfrc.org>, idr wg <idr@ietf.org>
References: <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> <20170418203108.GB9688@pfrc.org> <CA+b+ERnxjsjVbSowzBgBhrCtY5ehhn+SM+uvF3G071No-3gk6Q@mail.gmail.com>
In-Reply-To: <CA+b+ERnxjsjVbSowzBgBhrCtY5ehhn+SM+uvF3G071No-3gk6Q@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mIIQyEU9QCf7pNZ8ER2R8upJZNM>
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: Thu, 20 Apr 2017 11:31:25 -0000

Robert Raszuk wrote:
> And one of the requirements as you have heard from at least one customer is
> to test MTU of the path to such BGP next hops. Is RFC5880 BFD really best 
> tool for that ?

All IXPs have published MTUs and someone attempts to connect to an IXP
with the expectation that using a different MTU is going to cause
anything other than complete brokenness, then I'd tactfully suggest an
alternative career path.

>     As noted previously, the draft does permit for alternate means
>     beyond BFD.
>     However, we have to pick one.  Standardizing ping is likely a bad
>     idea. :-)
> 
> ​What is there to standardize ? RFC862 seems like pretty good standard
> already. 

With sufficient thrust, pigs fly just fine.

ICMP is the wrong tool in the same way that ARP request/reply is also
the wrong tool for this.  It's rubbish for this purpose because it's
usually highly deprioritised on routers, unlike bfd which is often
fast-pathed and carefully controlled.  BFD is fit for this purpose
because it's designed specifically and is supported by router vendors
for exactly this purpose.

Fast liveliness detection cannot be pawned off to an arbitrary protocol
just because that protocol replies to packets, in the same way that we
don't exchange routes over xml in https or implement ssh using udp/53,
or plough fields using a modified toyota yaris.

Nick