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

Robert Raszuk <robert@raszuk.net> Thu, 20 April 2017 22:17 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 06ACD128CDC for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:17:46 -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 Oxyk8HMD10FZ for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:17:44 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 AB406128799 for <idr@ietf.org>; Thu, 20 Apr 2017 15:17:44 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id a103so90444459ioj.1 for <idr@ietf.org>; Thu, 20 Apr 2017 15:17:44 -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=TMslYN1F+J3gfeV/ILxk/5zPcQL3SiFvL3qBleWVyJw=; b=Ew6kFMINIm40cUF98WfngjuEerol1g/HJMHlMRTuCOtRmcOuR3+4XdMEBzwwQn9wr5 VYNmgwleue4W2eoul4MUCV56Fmut0hM5snxZ/Ao2g/JaYl1Lc9U3bYnCp7dk57R6usIB NKvPunMXTawIOHRhLtSilBRbMcEcpw/yYaVOWVOXill1JwCeE/zFlWfot31sXxAVjbru iLAwhDkQhqIg1sPWo65NQDb+5rLMKSYetdJ0b5+0kYlMlb9vEZK6JAQX89BJxfC43q4j X2nHptfZP4orY2GIUvo1WuDXBprCJAZVLx7ZkOhEQJL/8/h+Yu3IyxSGX+pD1C852REO S4Gg==
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=TMslYN1F+J3gfeV/ILxk/5zPcQL3SiFvL3qBleWVyJw=; b=dXNVyur+wbxPTA5BG7rgnYxeqlStK23JXQ09Kxxw4HlGpcUx1b+NEo/laFyiQck/tt VHAW0MDLIEG1CRwDhLXv+5KefoW3Ylir1brXj61mKe1SzsfzlD+o3vHUURTegY6anxCd jLr4p0QhTCUINmIpcqE6HSZfj+6odG6J8iOGqz6cb7dIE8ZZksV73OACexQ31kw1oIUe 8f66tBYRic4QNkmPymXNvAOYrZfYvoqgwHDupBGz40s3DBU9b5szx1LFnNFemyequ43H NCS6fTI4z+e6gIEnXeayci9UUIg5SoOlAy6Uk4ensYQEisewk3ZInc5mPQ2COlxd7ktZ 2uQg==
X-Gm-Message-State: AN3rC/75k6YL0VYOWOPrs+Tg8HdSpi9IkL7pZ9qefM7pq6yfIK3KwC2E +OeagiuLlsNg21iJZ3zM2wsLj5e2T8zi
X-Received: by 10.107.16.135 with SMTP id 7mr12537119ioq.228.1492726662658; Thu, 20 Apr 2017 15:17:42 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Thu, 20 Apr 2017 15:17:41 -0700 (PDT)
In-Reply-To: <58F89C07.8080900@foobar.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> <58F89C07.8080900@foobar.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Apr 2017 00:17:41 +0200
X-Google-Sender-Auth: 3y-vkqV5rfHPLJ7kCwfkdE94UdA
Message-ID: <CA+b+ERnZvPM0jyuMEx1cGTHS70Rw+h+Ze0KoM7cbCkvVMAKMTw@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Cc: Jeffrey Haas <jhaas@pfrc.org>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a113fe9c2798129054da082de
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cKCFRs0PI3lBd4yxfsp9GzOPFms>
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 22:17:46 -0000

Nick,

I am very happy for you that your experience with published static MTU
values is so great. Well if you go via your own switches with dark fiber I
would not expect this to be any different.

If however you operate a distributed IX and use leased circuits from other
carriers between your access switches you may be very surprised that
suddenly your MTU get's reduced due to underlying carrier reroute to
different links or applying say MPLS link protection.

We do see this occurring more and more these days and it is nasty to
troubleshoot too if you have no proper tool running. So tactfully I
recommend we do not close our minds to only those problems which one have
seen in his own shop.

On the topic of ICMP or ARP it is your choice. I prefer to know that my
upstream is down in say 2 sec rather then suffer from broken Internet link
forever as my upstream provider will not run BFD session with an office
fiber tail.

Cheers,
R.



On Thu, Apr 20, 2017 at 1:31 PM, Nick Hilliard <nick@foobar.org>; wrote:

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