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

Robert Raszuk <robert@raszuk.net> Thu, 20 April 2017 22:54 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 6C184129BAA for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:54:50 -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 d9x0qQXutk2r for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 15:54:49 -0700 (PDT)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 00071129457 for <idr@ietf.org>; Thu, 20 Apr 2017 15:54:48 -0700 (PDT)
Received: by mail-io0-x230.google.com with SMTP id k87so91011391ioi.0 for <idr@ietf.org>; Thu, 20 Apr 2017 15:54:48 -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=ZLjve3QXaBjFfdOin1x3DTRIW6W4lzrkdffRGFOuhMk=; b=IyyFUV5crDSOR2G77QSq6k2Z6MLrJ5XCmxJifFDhjI/VGi7/foC1zVMH0cc8cxwMqs Ukm6YYdrOEI2CvEpdGr5TRNmLh7LcLr0NAXoNqrH78tfS2w0JwZSUxA013sHEuVEEj24 gvJNFFwWMvW4eohF+Jmi2W5mIcslCUHlB0orvln69z8FUK2iH6nanBZHAqx2Ognk8wQv 4a8F3+aTo7IW2kMHGtnsgeJg4s+cfNp727CvNgta14FwuJt8/N3+XiaeFlWEWEIC6SoT y4Oe+/3WBLa+3NeIapVsOoB60Q8AVwRgN+TGqx/J9W5aZKyVDU43lRI0ENjJyN9DATfn JAxQ==
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=ZLjve3QXaBjFfdOin1x3DTRIW6W4lzrkdffRGFOuhMk=; b=L+PfW//iEUSX5D7EOoxVreW5cGshcIcszWwou0WCbVYFFetjAGwNp+oDCuIUzzjYQ1 r8TzVYS1WVLwdlh4P7s4y3xevgqHrC8ZZAoGBrkG02FY06xdtKGnokKDuzNLrB7kEZ+H Gfs0QitYkvskKgn34GDDwIHZ5nYTX9hK64ZHHwCCIaWc7Hl8ZVbbLMGoCvYNcZwHF820 UYKz6ekQNO8owNRx3q1fU2PRsooY1FTlZtyimz8gnNcfZEnBeUP+xgLiqpb9i+o7E9Z5 gwJkIWRjoq5ws2visohEyTIY6cEmHI1ysWV0Xa15tf/S6EDon4PromXJIoVqJQN6f3xJ NA9w==
X-Gm-Message-State: AN3rC/4t2Abuqt81GNvLRYXVMVrpg4G2U8P+K6VFdjLQ+uerXLxHmp+/ Hwr6OB1QT34WIajSYaph3irrXwXfq2aL
X-Received: by 10.36.48.149 with SMTP id q143mr6701869itq.25.1492728887833; Thu, 20 Apr 2017 15:54:47 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Thu, 20 Apr 2017 15:54:46 -0700 (PDT)
In-Reply-To: <58F93B30.2010909@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> <CA+b+ERnZvPM0jyuMEx1cGTHS70Rw+h+Ze0KoM7cbCkvVMAKMTw@mail.gmail.com> <58F93B30.2010909@foobar.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Apr 2017 00:54:46 +0200
X-Google-Sender-Auth: ivc15Kj8AnBnl09VcAl6dQESymw
Message-ID: <CA+b+ER=QLQy8hTrw4Dvs7Au5uhQd=wUxdFWQqQx06Kc61n5BLg@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Cc: idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140b1601afdf6054da107fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sbUQoSeZ1CwOkrPXqk0Zogv2oj8>
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:54:50 -0000

Yes I do realize that.

But my point is that we can come up with single solution to both problems
which would work in a hardware accelerated way equally well. I am also
observing that MTU issue is applicable to long distance stretched IXes
which as I am sure you are aware is a real IX service offering by number of
IX operators today.

//R

On Fri, Apr 21, 2017 at 12:50 AM, Nick Hilliard <nick@foobar.org> wrote:

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