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

Robert Raszuk <robert@raszuk.net> Thu, 20 April 2017 22:38 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 654BF1316F4 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:38:43 -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 hETk6Z1rkbA4 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:38:41 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 3C5981316E9 for <idr@ietf.org>; Thu, 20 Apr 2017 15:38:41 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id a103so91176304ioj.1 for <idr@ietf.org>; Thu, 20 Apr 2017 15:38:41 -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=VQB4UolEK+gc53ckcrfgCsjD19fjstcIeMOjX2Bk9B4=; b=q6Wc1UayjeQMs46mg2miXIdqZsujI7yBTOzhevtm9g9YKbEFIpb7NCRWFp/yGmLhc1 sXDMZuMo6gl32ILL/C+DCVlpASN9JL4I0WTSvMfjNcGzbW71mQNsvN6dfEQgxtMFGw/6 wW/GBrRUsGKzsWilyaJzEYvQBrJ/1DUm0qHrFXxG06Ms9Lizx5MBjWQMezP1sh9C3K7S hELySbPuYSHMbwxox2TixpyBGE1N4N8EFNh3mz9lVXw6YwgCRW4kbopk7L9gv5jCeJIR qGtM4iJ7FQeDvKSEUriB1E5KBezEVMkQayXDQlcj5IJhsjHVzsYSe377X2FEJ0h11NfH W3uA==
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=VQB4UolEK+gc53ckcrfgCsjD19fjstcIeMOjX2Bk9B4=; b=NoiIK1MKfY82+YOB/4kPrfFoo+GzUBSGVxgh8DY1FeD/rtSPMJOCsWk5wBnOHPnSqA Qh4V8HT/O6YOeTztKxsUrsZxzqxOv2/GA017MLv/1kRCmhzoniW8ggfR7JEnR4A+BjKR Gw9tT/TaOI38hiP/He1AiCeggssakzowU/yDGlwXUiklULXx+ckMQouU3UQbNFkTqSZT ATGZPmbBmAjc0rDPGmOklmbsGgXtAFJ8htEXAd7PCyL3QmoU5FTmFXiu4yCY9jWmzj2B uXsEBa+y2ELeW98EKWPMNKqgsK2YV/ODRIDBUt63FQIM/2CtyZ4AIEUbrX0N5AeJBbWh iiuQ==
X-Gm-Message-State: AN3rC/5cmrPewvL8Uc6ic9d8K8yEIuFfvWqXYX6aQF2LdT4yycsGXvrK dYZ8kDUQ3AjRpwUOE5MaWSC8u55Ax8C1
X-Received: by 10.36.46.81 with SMTP id i78mr6955132ita.39.1492727920438; Thu, 20 Apr 2017 15:38:40 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Thu, 20 Apr 2017 15:38:39 -0700 (PDT)
In-Reply-To: <20443E09-69D6-4061-A3B2-4606FD8BEBC9@i3d.net>
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> <CA+b+ERnZvPM0jyuMEx1cGTHS70Rw+h+Ze0KoM7cbCkvVMAKMTw@mail.gmail.com> <20443E09-69D6-4061-A3B2-4606FD8BEBC9@i3d.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Apr 2017 00:38:39 +0200
X-Google-Sender-Auth: Ea8B7FAAn97MDYMYED3S1wM7ivM
Message-ID: <CA+b+ER=+84LWvAHbqJZCPZBhYfHJVN9y_=sXnjfTg51PTp3pbQ@mail.gmail.com>
To: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Cc: idr wg <idr@ietf.org>, Nick Hilliard <nick@foobar.org>
Content-Type: multipart/alternative; boundary="001a114a93ce71c39d054da0cd2d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FegXfhmhIyVtZfUGhZavIM7xmfY>
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:38:43 -0000

Yes within a city you can use it the way you describe, But between
countries it would be rather expensive option don't you think.

Moreover I have 15000 CEs WAN and do see those issues in real. So the point
is that it would be great to come with one good solution for such problems
rather then again zoo of new features - especially since we would like
those to be implemented in line card's hardware.

Yes I know the draft name is rs-bfd ... but the problem at hand is bigger
then IX environments.

Thank you,
R.

On Fri, Apr 21, 2017 at 12:32 AM, i3D.net - Martijn Schmidt <
martijnschmidt@i3d.net> wrote:

> Robert,
>
> 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,
> Martijn
>
> On 21 April 2017 00:17:41 CEST, Robert Raszuk <robert@raszuk.net> wrote:
>>
>> 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
>>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>