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

" - Martijn Schmidt" <> Thu, 20 April 2017 22:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A74C41316F2 for <>; Thu, 20 Apr 2017 15:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k28lGahYI2pU for <>; Thu, 20 Apr 2017 15:32:39 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9565E127977 for <>; Thu, 20 Apr 2017 15:32:38 -0700 (PDT)
X-Footer: aTNkLm5s
Received: from localhost ([]) by with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Fri, 21 Apr 2017 00:32:27 +0200
Date: Fri, 21 Apr 2017 00:32:13 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----SXTV0168540H5RTGN8VF3L6XYPP14K"
Content-Transfer-Encoding: 7bit
To:, Robert Raszuk <>, Nick Hilliard <>
CC: idr wg <>
From: " - Martijn Schmidt" <>
Message-ID: <>
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Apr 2017 22:32:42 -0000


Distributed IX operators typically use dark fiber or DWDM wavelengths as underlying circuits in their VPLS fabric for exactly this reason. If they do cobble together their network with various 3rd party, say, "ethernet solutions", I doubt they'll have a good reputation in the market for long. 

Best regards, 

On 21 April 2017 00:17:41 CEST, Robert Raszuk <> wrote:
>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
>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
>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
>forever as my upstream provider will not run BFD session with an office
>fiber tail.
>On Thu, Apr 20, 2017 at 1:31 PM, Nick Hilliard <> wrote:
>> Robert Raszuk wrote:
>> > And one of the requirements as you have heard from at least one
>> 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
>> with the expectation that using a different MTU is going to cause
>> anything other than complete brokenness, then I'd tactfully suggest
>> 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
>> >     idea. :-)
>> >
>> > ​What is there to standardize ? RFC862 seems like pretty good
>> > 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
>> just because that protocol replies to packets, in the same way that
>> don't exchange routes over xml in https or implement ssh using
>> or plough fields using a modified toyota yaris.
>> Nick

Sent from my Android device with K-9 Mail. Please excuse my brevity.