Re: BFD WG adoption for draft-haas-bfd-large-packets

Greg Mirsky <gregimirsky@gmail.com> Tue, 23 October 2018 16:53 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE1E130E3D for <rtg-bfd@ietfa.amsl.com>; Tue, 23 Oct 2018 09:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hZ7w7eBYoWxE for <rtg-bfd@ietfa.amsl.com>; Tue, 23 Oct 2018 09:53:28 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 C18211277D2 for <rtg-bfd@ietf.org>; Tue, 23 Oct 2018 09:53:27 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id k11-v6so2059296lja.5 for <rtg-bfd@ietf.org>; Tue, 23 Oct 2018 09:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EcQjsYs2DLdphzSueq2opEu2d53NZhyfK02VYZjr32A=; b=I1k8wjhFFGdGjrLEXQUU6wjSIxTf5xZn5SZWwnv9DpdKMx/nxSK9N8Z/6+TsIzSDUt uy8KZ+QdljJpvDtDfDoERrgkqHVLcvJ93fMMw/ag6YZe7eL0kSr+L323X6MNy6crrNYa Hafx2sk9ZKmsxp86Oa61lOzcxj1mKoQIuvR2K9cwb+1MFLchu2l/U48xZjmq3tRNQ6sD LS1EjUfkSM5VVNSBQ6Sq5u89Nmon6mBrfG7A1mm1+hDAxxLC63fY5ApKqHqMvP3MC3Ps SCaI/Cvokn4NDOC8Jlspe5qt2jD0UypVAgZg+K+oX3a3wPxkdmOgZ/WVawO4nNKIPaHl G29g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EcQjsYs2DLdphzSueq2opEu2d53NZhyfK02VYZjr32A=; b=bF9sm94b4OZRd/1H0AlmoBaz24yPoPGFmYphzmbUVckUYRAVuIckhcZQZwNNKuSx5K Rr5EJTWIPz2EEGPb4IUIFmTSO2LS+CH41hW11x/1aMTWryCcNbW53WVsI255DMEig5BL RGA3ZFnfx3uJgj7DIkLpXpb5kH4xNhHWeFoFJ9zLpRFmcgtn+Shx28H5ARtHqxMY117Q tL7/qM3n7Ndq9lZN68dH2g4WN4KyKiVPsRmgtq0aqkrF6dd0NyBGEszQ7bMP/jWydiE/ Asl9P1QrwPSCE9ZLg9YIcV0EEzJVb2oRvBb9BvEhlEcnE6s40aIrKOw0k9mnT7LP3IIw ROUQ==
X-Gm-Message-State: ABuFfoiadf6cOBO1VdacuMw/7KEJuxw4KCb5Bi6uf0fqvoOUaUsp4o83 X92yweptjGGqxrko+y05fcevsXz/J3Yjor54PxY=
X-Google-Smtp-Source: ACcGV62S7fUCwvpjmFPu+Dw0xpYcnQQW+tG1wYNYCMP0/ZMWdTO2PVtfFwkLAQByewFapfKGrIYFJffKFo+O/U3Hb5A=
X-Received: by 2002:a2e:800e:: with SMTP id j14-v6mr31981455ljg.114.1540313605763; Tue, 23 Oct 2018 09:53:25 -0700 (PDT)
MIME-Version: 1.0
References: <5BCF41E0027F048C00390652_0_50208@msllnjpmsgsv06> <5C5FC034-3730-41AD-8414-5AD7DEA5AE89@cisco.com>
In-Reply-To: <5C5FC034-3730-41AD-8414-5AD7DEA5AE89@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 23 Oct 2018 09:53:14 -0700
Message-ID: <CA+RyBmWtEbS=VmHVZY-TXh-WKX2j2h=i5yW8_qsgC=10bkZyKg@mail.gmail.com>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: afu14@bloomberg.net, rtg-bfd WG <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Content-Type: multipart/alternative; boundary="0000000000005077090578e83556"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/4Ut2yzZgeGIvzcHi0o7nueHiRmM>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2018 16:53:31 -0000

Dear All,
I agree and subscribe to the proposal to discuss the problem and the
possible solution based on BFD protocol. And adoption of this document, in
my view, is a logical step. I may point out that RFC 6423 described the use
of the existing BFD session providing connectivity verification over p2p
bidirectional MPLS-TP LSP or PW (note that BFD, in fact, provides
continuity check, not checking connectivity in transport network sense).

Regards,
Greg

On Tue, Oct 23, 2018 at 9:31 AM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Albert, Les,
>
>
>
> I tend to agree with Les that BFD doesn’t seem like the right protocol for
> this. Note that if you use OSPF as your IGP and flap the interface when the
> MTU changes, you’ll detect MTU mismatches immediately due to OSPF’s DB
> exchange MTU negotiation. Granted, control plane detection won’t detect
> data plane bugs resulting in MTU fluctuations but I don’t see this as a
> frequent event.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of "Albert Fu
> (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
> *Reply-To: *Albert Fu <afu14@bloomberg.net>
> *Date: *Tuesday, October 23, 2018 at 11:44 AM
> *To: *"rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)" <
> ginsberg@cisco.com>
> *Subject: *RE: BFD WG adoption for draft-haas-bfd-large-packets
>
>
>
> Hi Les,
>
>
>
> Given that it takes relative lengthy time to troubleshoot the MTU issue,
> and the associated impact on customer traffic, it is important to have a
> reliable and fast mechanism to detect the issue.
>
>
>
> I believe BFD, especially for single hop control-plane independent
> situation (btw, this covers majority of our BFD use case), is indeed an
> ideal and reliable solution for this purpose. It is also closely tied with
> the routing protocols, and enable traffic to be diverted very quickly.
>
>
>
> The choice of BFD timer is also one of the design tradeoffs - low BFD
> detection timer will cause more network churns. We do not need extremely
> aggressive BFD timer to achieve fast convergence. For example, with
> protection, we can achieve end to end sub-second convergence by using
> relatively high BFD interval of 150ms.
>
>
>
> In the case where the path will be used for a variety of encapsulations
> (e.g. Pure IP and L3VPN traffic), we would set the BFD padding to cater for
> the largest possible payload. So, in our case, our link needs to carry a
> mix of pure IP (1500 max payload) and MPLS traffic (1500 + 3 headers), we
> would set the padding so that the total padded BFD packet size is 1512
> bytes.
>
>
>
> As you rightly pointed out, ISIS routing protocol does support hello
> padding, but since this is a control plane process, we can not use
> aggressive timer. The lowest hello interval the can be configured is 1s, so
> with default multiplier of 3, the best we can achieve is 3s detection time.
>
>
>
> What we would like is a simple mechanism to validate that a link can
> indeed carry the expected max payload size before we put it into
> production. If an issue occurs where this is no longer the case (e.g. due
> to outages or re-routing within the Telco circuit), we would like a
> reliable mechanism to detect this, and also divert traffic around the link
> quickly. I feel BFD is a good method for this purpose.
>
>
>
> Thanks
>
> Albert
>
>
>
> From: ginsberg@cisco.com At: 10/23/18 10:45:02
>
> To: Albert Fu (BLOOMBERG/ 120 PARK ) <afu14@bloomberg.net>,
> rtg-bfd@ietf.org
> Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets
>
> Albert –
>
>
>
> Please understand that I fully agree with the importance of being able to
> detect/report MTU issues. In my own experience this can be a difficult
> problem to diagnose. You do not have to convince me that some improvement
> in detection/reporting is needed. The question really is whether using BFD
> is the best option.
>
>
>
> Could you respond to my original questions – particularly why sub-second
> detection of this issue is a requirement?
>
>
>
> For your convenience:
>
>
>
> *<snip>*
>
> *It has been stated that there is a need for sub-second detection of this
> condition – but I really question that requirement. *
>
> *What I would expect is that MTU changes only occur as a result of some
> maintenance operation (configuration change, link addition/bringup,
> insertion of a new box in the physical path etc.). The idea of using a
> mechanism which is specifically tailored for sub-second detection to
> monitor something that is only going to change occasionally seems
> inappropriate. It makes me think that other mechanisms (some form of OAM,
> enhancements to routing protocols to do what IS-IS already does **J)
> could be more appropriate and would still meet the operational
> requirements.*
>
>
>
> *I have listened to the Montreal recording – and I know there was
> discussion related to these issues (not sending padded packets all the
> time, use of BFD echo, etc.) – but I would be interested in more discussion
> of the need for sub-second detection.*
>
>
>
> *Also, given that a path might be used with a variety of encapsulations,
> how do you see such a mechanism being used when multiple BFD clients share
> the same BFD session and their MTU constraints are different?*
>
> *<end snip>*
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
>
>
>