IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Fri, 21 April 2017 09:01 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 93D03129426 for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 02:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 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, URIBL_BLOCKED=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 rzbYBTdWhOEl for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 02:01:34 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 A8EF7129B43 for <idr@ietf.org>; Fri, 21 Apr 2017 02:01:34 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id r16so105863776ioi.2 for <idr@ietf.org>; Fri, 21 Apr 2017 02:01:34 -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=LSXlALAaJNXnpdf78r21Vou5sGHWBjs4/CANHZ3PjmE=; b=miBheXEdx7w1o6TfK41Bn0Pk92jmUNkqLo+DnzxQih2sJEdv8l5bIrQt98YwG1wIou CBE01IaQX3z/FD776HtkymPDjbc5eE7ZMbDs03bYH+zCypz0qzfm1yRstRhX5PP3xH1y riLY+kU3+ouZeGvc3AOCHaet2ZlUbjTwzeshq57XOk6rg103lhOL5kvEKFWmcWRtkcn7 OpQWpLMRsMZRyQ6fNyLWUJ7NfjmnBuY5Eapmpr3J8DFGVku2o++Xrx1/IabCWasq9WzB PpzRTB5c2zQhjrPaPcSNgfhqHC3K+cCfPyCfLjMo4MdQqF+pobPuqP+3NZFubyKZYYRf h1cg==
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=LSXlALAaJNXnpdf78r21Vou5sGHWBjs4/CANHZ3PjmE=; b=A58G6+pbpJ4IH1GH8a/mGU6MY/2+UPoo3EUtbPYA8Unh5qLiDy99pgB83HIM+E4OKM 628RlnDiS2CChBylAQ6M/AbYCaTbX5hrOTcehiAXQoZ2liouEhbYe8ujumgyph19/uzB Zyu+E+gERB0cfBAHBxRoU00P/r3qV2AFDYv6b4uUnbnsqwIdahvoKHgTesAuOTwiAvce TH+Mh1x5NZ9IcnSfqoXOHbT7YNMIFzM+rLT0brO7PwiHvSBdX2VvDug2pCCtDO6ShI54 nPmqyd+0UTaldQOU9d07zyrxVuqcQ2l9CKmrLSUE6jyHgokSVq3+XwmgKScz2T0RI6Xp z9CQ==
X-Gm-Message-State: AN3rC/6H/M9Kj8ig0tCyd/jzsTPFuEusBY2/TeJvemSDBPjGOgmPj35W hXGQRxGk3cwsbKzU1HjPq0j7pH9tVxNV4qI=
X-Received: by 10.36.219.195 with SMTP id c186mr9008970itg.25.1492765281103; Fri, 21 Apr 2017 02:01:21 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Fri, 21 Apr 2017 02:01:20 -0700 (PDT)
In-Reply-To: <58F9C95E.2050201@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> <CA+b+ER=QLQy8hTrw4Dvs7Au5uhQd=wUxdFWQqQx06Kc61n5BLg@mail.gmail.com> <58F9C95E.2050201@foobar.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Apr 2017 11:01:20 +0200
X-Google-Sender-Auth: lSmCE8itUm5fhjwRagLycu5YcLw
Message-ID: <CA+b+ERmyuCqn1CCK0gZVV0C5VRQstXxEN_OA6WwmMbxTjrtaBg@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Cc: idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a114f5cce50407b054da980f4
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/UbqkHxn853qzP6LCzpV4BCJrnjo>
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: Fri, 21 Apr 2017 09:01:36 -0000

The document is written, accepted, last called and published as Standard
Track RFC.

Ref: RFC 7880.

> If you are operating a private infrastructure

I am building private secure infra over public IXes. Hint: SD-WAN MTU
stability over IX matters to me.

Best,
R.


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

> Robert Raszuk wrote:
> > 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.
>
> Then I suggest you author documents to:
>
> - add a new icmp type to define reachability / mtu detection / etc
> mechanism
> - replicate whatever bits of BFD you want to port over
> - get widespread vendor support
>
> Once you've done all this, and not before, then please feel free to
> write an update to draft-ietf-idr-rs-bfd rfc to include your new
> reachability mechanism.
>
> Or you could update bfd to support mtu detection.
>
> > 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.
>
> IXP core MTU monitoring is orthogonal to draft-ietf-idr-rs-bfd.  IXP
> edge MTU monitoring is the responsibility of the ixp edge participant.
>
> If you are operating a private infrastructure in your company which
> amalgamates these roles and where you have a need to monitor for MTU
> changes, then this is a private problem which can be easily solved using
> any one of a plethora of off-the-shelf tools and there is no reason
> whatsoever for the ietf to standardise a new protocol to solve this
> corner case.
>
> I'm not going further down this rat-hole because it has nothing to with
> this draft.
>
> Nick
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.8.10 | Report a Bug | By Email