Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Tom Herbert <tom@herbertland.com> Thu, 08 April 2021 03:29 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478A43A365F for <tsv-art@ietfa.amsl.com>; Wed, 7 Apr 2021 20:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 Fjvx-3-aLv6h for <tsv-art@ietfa.amsl.com>; Wed, 7 Apr 2021 20:29:43 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 86CA13A3662 for <tsv-art@ietf.org>; Wed, 7 Apr 2021 20:29:43 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id a7so575159eju.1 for <tsv-art@ietf.org>; Wed, 07 Apr 2021 20:29:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RjAI90j58RozCs/dXVGSOxYpODhwzzSrpYDyN8FAs60=; b=DMcvs3OLU9wTWi5rku2qA3q7grCUeFk8vxNoc/yF8CAiCpfxkh4pv+6Qu1XTgr7tQj 9Vry+0PxNdeVDXmdk5mfXG76KKy2gXrU+3B32a/cYkeuqccQG0kMHIoywkvX4XpZnoeS zpw/F3BIa3lxBaJ6jMFHkmtyBJlDfvtv9EP3m2iRO8dKkj1C7RSvSNo2MUUdPNXONg+m RG1tXzBeCZlvVuGguJeR/5u6Td8NKoUPVh6hYN8916OrC3nT5A+XgXkcraBnGBU8HQCe lldGuZ4LV+bE1i2+I08XBUZlPhRvaBYEQFXi3UfGkoPh5xOT+1/XcRu5YKdJOI+oCMsN wA4w==
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:content-transfer-encoding; bh=RjAI90j58RozCs/dXVGSOxYpODhwzzSrpYDyN8FAs60=; b=BFNe/Y3K79M9ZnXBvPWuScC3dG3BLILuS+I3NVIaPjNpdUB5omQhaZJVggPj4mEU+g YvDw8ubIiKeelKObaDnPGLU4pT7iAPa266d0HB7ESjzA8qeTrSTkOdnabQb6bSsHk6dU 9g6nyPHpJlDL0NaT+RITZKCq/pkgvmmYiIdNLAyvBe1C1kgtQR/AMSHtnPztR9N2WL10 TyUoOx+Sl1pQ/+KorRpaaFmB2+nDJ0WOQ68qjlufHvtN+d1MKE9xHf0lV43NRex1bBTh r6wTtzriZGnvXILy1ZBKy30d/jHpvCB3g0I0wwgHaF3svP7Rr7GvXQN5YAB/HJWNLvYX GHcw==
X-Gm-Message-State: AOAM5330NTYVRCFctdvsTIxI4ZBvnohsLKWLP+lckd1lVcPMXGuNZUjG Fjy7ziD+r7WOwmE1Rz1I5DzQwMIpw2sjw3o4+qAl7Q==
X-Google-Smtp-Source: ABdhPJzjGVApzb9bLXxl9RDC98ONlM9FVxSAHhPvS8NROwQg1wZDulbMtCuf/Wcob8uZRjWbPCs5gxvc8lzsNPsM8rg=
X-Received: by 2002:a17:907:1692:: with SMTP id hc18mr7473634ejc.265.1617852580616; Wed, 07 Apr 2021 20:29:40 -0700 (PDT)
MIME-Version: 1.0
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <bf83d228-25bc-21bb-f984-d58ead6bf492@si6networks.com> <CALx6S35Kh-QAXJDAucuw5Wty37MBiwS=pqQknMZ+15b7D5Sn8A@mail.gmail.com> <34e78618-cb28-71a1-a9d3-7aec38032659@si6networks.com> <CAO42Z2zqD9_d2Fbr25Y2CV1GdzYKd167yf5DHeHna7V66pF65A@mail.gmail.com> <0bd316ac-1789-f4c6-d280-943ad6e60309@si6networks.com> <CALx6S34dMEEJ+OPUu_=FW1Y5AQuvAaHzBPEe448S7rfbMmHN_w@mail.gmail.com> <CEFDF511-9255-4913-840D-50CCBC2B7B17@gmail.com> <CALx6S36_w+zxyUt0DzQ9NKBs+SAPZDNhs_sqLBwi+qneOPSS5A@mail.gmail.com> <ef2bd4f5-3b1e-b88c-ec8f-dd9a2f9a60ba@si6networks.com> <CALx6S349X7fQR=9Dj+n5X7ovXsSjLYibv-C-+bL0nkWsYP5NGA@mail.gmail.com> <MN2PR11MB43668EDA6209CA6AF3BCC5EEB5759@MN2PR11MB4366.namprd11.prod.outlook.com> <CALx6S3447SJwdRPoG_BaXS=ihBe1xA84vxcCev1y2K4xqMYZaQ@mail.gmail.com> <a68c5a02-ad6b-1966-7fe4-678abf14af24@si6networks.com> <CALx6S36pLpF8+Y_8oDiO+UQAnXFt5STSaB5fJgjWp9jFEFv3-A@mail.gmail.com> <42039a4f-b65d-27ad-32a9-a26d0914ec0d@si6networks.com>
In-Reply-To: <42039a4f-b65d-27ad-32a9-a26d0914ec0d@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 7 Apr 2021 20:29:29 -0700
Message-ID: <CALx6S352qOQD_gvU=Lnyy6U41irs6CPJPc=oNqXqX19JcveNOg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, IPv6 Operations <v6ops@ietf.org>, "draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org" <draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/JOV-o1OeZBW3vZ0s50PorediXzc>
Subject: Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 03:29:48 -0000

On Wed, Apr 7, 2021 at 7:46 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> On 7/4/21 21:30, Tom Herbert wrote:
> > On Wed, Apr 7, 2021 at 5:03 PM Fernando Gont <fgont@si6networks.com> wrote:
> >>
> >> Hi, Tom,
> >>
> >> On 7/4/21 12:20, Tom Herbert wrote:
> >> [....]
> >>> Given that hosts are the ones creating extensions headers and other
> >>> packet formats, hosts have a vested interest in how routers are
> >>> dealing with their packets. Even before this document was created, we
> >>> have long known that extensions headers might be dropped and have been
> >>> working on mitigations to reduce the number of drops which are already
> >>> addressing some of the reasons that packets with EH. For instance,
> >>> consider draft-hinden-6man-hbh-processing-00; this is a proposal to
> >>> limit the number of HBH options to exactly one. The idea is that
> >>> routers will make it feasible for routers packets that have HBH
> >>> options, with the trade off of specifically limiting the extensibility
> >>> of the protocol. The problem is there is no data that indicates this
> >>> proposal would have the desired effect; we don't if routers would
> >>> start accepting packets that are limited to one HBH option.
> >>
> >> What does that proposal have to do with this document?
> >
> > Because that proposal is ostensibly addressing a perceived reason for
> > packets being dropped.
>
> That doesn't change what this document is doing *at all*. We're
> explaining what operators do at the time of this writing.
>
>
>
> > If it's not really a problem, then by all means
> > please chime in on 6man list where the draft is under discussion.
>
> I did raise my concerns during the last 6man minutes. My comments should
> be in the meeting minutes.
>
>
>
>
>
> >>> So my fundamental concern with this draft is that it is an entirely
> >>> qualitative description of a well known problem, however a qualitative
> >>
> >> No. It is not a well known problem. If you look at
> >> draft-hinden-6man-hbh-processing, itś clear that their assumption is
> >> that limiting the number of EHs or options solves the problem. Whereas
> >> our document essentially notes that to a large extent the problem has to
> >
> > What exactly does "large extent " mean? Does that mean that at least
> > 50% or some greater than that percentage of drops of packets with EH
> > were dropped precisely because the header chains were too long?
>
> That's not the topic that this document is addressing.
>
Fernando,

But you said "Whereas our document essentially notes that to a large
extent the problem has to do with the overall EH-chain length" so it
would appear this is indeed within the scope of the document. Clearly
that is a conclusion you've reached in writing the doc, I'm asking
that you quantify what you mean by "large extent" and provide the
basis for that quantification. If we knew the relative frequencies of
the various reasons that are mentioned, then that is useful input to
work for both send hosts and protocol development trying to mitigate
drops.

Tom

>
>
> >> do with the overall EH-chain length -- it doesn't matter if the
> >> EH-chain: it doesn matter whether you have one long EH, multiple small
> >> ones, one large EH with one large option, one large EH with many small
> >> options, or any combination of them.
> >
> > Perhaps, but again I ask for either data or references from vendors to
> > verify that supposition.
>
> Our document contains a reference to the very IEPG presentation that was
> done by a vendor.
>
>
>
>
>
> >> The fact that youŕe raising this issue and that thereś a belief that
> >> there'ś a clear and easy way to make EHs work probes that itś certainly
> >> not a well known problem.
> >>
> > That is not the only issue that is being addressed. There are also the
> > suggested limits in RFC8504 for host processing, the mitigation in
> > RFC8200 to allow intermediate nodes to ignore HBH options, and ICMP
> > errors in RFC8883 that intermediate nodes drop packets including if
> > header chains are too long.
>
> Again: what does has to do with this document.
>
> Please read the Abstract and the Disclaimer. That's what this document
> is about.
>
> You want this document to be something that it has never been, and has
> never been meaning to be.
>
> Thanks,
> --
> Fernando Gont
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>