Re: WGLC for draft-ietf-bfd-large-packets

Robert Raszuk <robert@raszuk.net> Thu, 17 October 2019 07:35 UTC

Return-Path: <robert@raszuk.net>
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 61BAF12006F for <rtg-bfd@ietfa.amsl.com>; Thu, 17 Oct 2019 00:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 gJVyhzJxpmHw for <rtg-bfd@ietfa.amsl.com>; Thu, 17 Oct 2019 00:35:44 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 70FBC120018 for <rtg-bfd@ietf.org>; Thu, 17 Oct 2019 00:35:44 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id u184so1007730qkd.4 for <rtg-bfd@ietf.org>; Thu, 17 Oct 2019 00:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MEv9F9hkqq8bYqXDZiaaeE3ljeB6rQ90elwiNsCh+J0=; b=dr13DBe2beYuFEHKhyjZo7N95S4G4BejV8YzECNuCA3plEe8oYZ/OpXMUUYBI2vppT kX6HFcfm/972Nye8umM3QYwS+yrdhTZEdw/avP5lyGSBZ3tdUmaGamI3Vb63+B5y6K/6 UKupA1d52FEmE7AGUE8+njscCDg0QwbWuq/LiJlSOaO/wtsWXGoAwjq2sKWgsKuR6s6W +3qG+50KuWbRSC/GvNhrZKOQrSjN7/ye+AEYInWCjhx4xtJWkyMq448Yp3KT34RPcjRQ 3Y0wlapFB8yYbo8dH5EtQKhtTjMUi2DGvcc4qvXo5heXcJfuBAJ8rX5wr1FyBYSeffHQ MK3g==
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=MEv9F9hkqq8bYqXDZiaaeE3ljeB6rQ90elwiNsCh+J0=; b=mZbR8Tn5koxBKfQsV/trt736C3lQK0BB17fBxe1wwkMjdlgdJKm1GO37IQu+KyXDw3 nXhF8sv8MN9ZXn05Ci8viiYvOEeMkQyc76Bc/jFmW10CTe72Gi4a4Ln8XpJboygHRzgP rCHo4V5Pa6LAlCjNh5E7Ic3CjHCGb+B6tH1jkWVdj+7r7ek8AhNTPMxmVsPeJB2q/QoQ 1IzIbhtqwpqeOQK5o9u1x9TQcXmJx/jezp0R6kI0OJwfCSGcztqd1qUPZjgXzUtFkjEX MpkgxfqPZnhEAqNBoYVtxleGfFzmTI2ju1Cal9a8/daKgqeliA5so36MZQRSyTVDHCBi mCVA==
X-Gm-Message-State: APjAAAUrQVXHrGl9uWgeW2O/bmaXqxmBcX6cEvZlP1KyRd063EUWU0F/ p2q2X/5tzwTPMdWhsXCLwAa4QANRXD1kaAVhM3VU6meC
X-Google-Smtp-Source: APXvYqwB+yGPDvYM5N89eCd8qxIh2gWZ7ousJPhi8cTVAGRSSuCV3615pvBalm2bCNgQbTJOhlnlDvtO8DUfm+B1Dh8=
X-Received: by 2002:a05:620a:6bc:: with SMTP id i28mr1969432qkh.219.1571297742950; Thu, 17 Oct 2019 00:35:42 -0700 (PDT)
MIME-Version: 1.0
References: <29C6F22D-AC57-446C-8013-408C4E28A94A@pfrc.org> <BYAPR11MB36384BA8A940618DA9FC3F76C18E0@BYAPR11MB3638.namprd11.prod.outlook.com> <20190918152817.GA20672@pfrc.org> <MN2PR11MB3647316C13CAA5EBD4531B06C1890@MN2PR11MB3647.namprd11.prod.outlook.com> <20190919020128.GB20672@pfrc.org> <BYAPR11MB3638E358EF9CE34818ECD010C1890@BYAPR11MB3638.namprd11.prod.outlook.com> <D95235B0-9917-4C06-97E6-1181BFF6F7CC@pfrc.org> <BYAPR11MB36383D1DF70CFA399BFF6E59C1840@BYAPR11MB3638.namprd11.prod.outlook.com> <20190926194948.GA22700@pfrc.org> <BYAPR11MB36386BB42047D9FD46F17E9BC1810@BYAPR11MB3638.namprd11.prod.outlook.com> <20191003201253.GB28365@pfrc.org> <BYAPR11MB3638ED339AE8B1D29A84D773C19E0@BYAPR11MB3638.namprd11.prod.outlook.com> <0B99493B-28C0-4BA3-BEAA-629B34DE1063@gmail.com> <CABNhwV08gsSRNKMpZr0j1tuueujUov-6MSOy7Yvdpme=Cd88kQ@mail.gmail.com>
In-Reply-To: <CABNhwV08gsSRNKMpZr0j1tuueujUov-6MSOy7Yvdpme=Cd88kQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 17 Oct 2019 09:35:33 +0200
Message-ID: <CAOj+MMHN4YivaD9caz4v-Ju9=kaovd8jrbswq=RLFMGEanPL_w@mail.gmail.com>
Subject: Re: WGLC for draft-ietf-bfd-large-packets
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ce2894059516430d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZbrKYlLHd4Tmc4wPacp6epX8d8U>
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: Thu, 17 Oct 2019 07:35:46 -0000

Dear WG,

Thank you Gyan for your note.

It very clearly highlights my primary concern expressed earlier of false
assumptions on how engineers may try to (mis)use bfd-large in multihop
cases.

Below note is a brilliant example of how one may not realize that actual
paths BFD packets take can be just a fraction of paths their data plane or
even other control plane packets may traverse over a network or set of
networks.

I am always concerned when protocol extensions being standardized are known
to only work in 1 out of 10 deployment scenarios and when chances of such
opportunity of incorrect use are evident yet no safety inline fuse exist.

Many thx,
Robert.

On Thu, Oct 17, 2019 at 1:29 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> All,
>
> I support this draft as I think this would be very useful for IPv6 use
> cases where EH headers are utilized excessively such as for an SRv6 use
> case for traffic engineering over the internet and would be a method to
> test via BFD multihop the path mtu where pmtud has failed to adjust MSS on
> endpoints due to firewalls or other devices dropping ICMP unreachable
> packet to big  messages resulting in 1280 mtu.
>