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

Nick Hilliard <nick@foobar.org> Thu, 20 April 2017 22:50 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 0F1DC128C82 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:50:31 -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 Egfgb4ij7MFt for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:50:29 -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 CFD4D129BAA for <idr@ietf.org>; Thu, 20 Apr 2017 15:50:28 -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 v3KMoPQT047173 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Apr 2017 23:50:25 +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: <58F93B30.2010909@foobar.org>
Date: Thu, 20 Apr 2017 23:50:24 +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: 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> <58F89C07.8080900@foobar.org> <CA+b+ERnZvPM0jyuMEx1cGTHS70Rw+h+Ze0KoM7cbCkvVMAKMTw@mail.gmail.com>
In-Reply-To: <CA+b+ERnZvPM0jyuMEx1cGTHS70Rw+h+Ze0KoM7cbCkvVMAKMTw@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/z4N--NPD4V7F-4EvzAyQNYcDFKw>
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:50:31 -0000

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

So what you're saying is that if someone builds infrastructure which is
identifiably unfit for its intended purpose, it might break in nasty but
entirely predictable ways.

At this stage, I think it's important to say that this draft is not
about MTUs, and that if you have core MTU problems on your inter-domain
l2 network, you have problems which are both bigger and not particularly
related to this draft.

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

We're talking about bfd session brokering via route servers in
inter-domain routing situations, not residential / b2b access models.

Nick