Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

Tom Herbert <tom@herbertland.com> Tue, 03 September 2019 20:34 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCB61208FA for <int-area@ietfa.amsl.com>; Tue, 3 Sep 2019 13:34:10 -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=ham 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 CdAf2s7VSDj4 for <int-area@ietfa.amsl.com>; Tue, 3 Sep 2019 13:34:07 -0700 (PDT)
Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (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 7C2D61208F5 for <int-area@ietf.org>; Tue, 3 Sep 2019 13:34:07 -0700 (PDT)
Received: by mail-ed1-x543.google.com with SMTP id f19so6054550eds.12 for <int-area@ietf.org>; Tue, 03 Sep 2019 13:34:07 -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=exzQpJWVpDzhK4tuPHmSROarjS6C8S8XE+chM+KARYk=; b=LQcRPHDn2T5y8tD7GrDsfpZXkrYP/kKvs0ptIC+3nKBp9pUxvpQhHRxENM+3HZu2+D 75JbsaF9Kywh7AXmqN1sE8+cmd6h49Tl8zKVy4THFn6unQHRETENPedp1wpDWDv2Uy6g 85RAQzAGowdGsqCVBSTZSVbAgwktQMae9CGxblSCmGJ0wGWjpO3Dt65J/tG1SopM8LDp 6S9bGYHy3KI+5+pdWtJDANW2Ai796N+PGImQTuohKBkZHj0IONuAZ918Q7hj7BzkSD0O OEo+sqdHKnTqTEp8k83IVQ4shcGgZNw2pXjlgbr4+YlYVDv0Fs2/TrwX9fiitdpzckEl 7JlQ==
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=exzQpJWVpDzhK4tuPHmSROarjS6C8S8XE+chM+KARYk=; b=RhjKoo9U0lFwSXbXbZ086h8V71ngwwNyIuHehJCRyZ2WMhd8rP2jcO7r+aRfdWKX45 zgfjzQbB0039FnCunyFtYw4Xr+WoaTs4bwQTmUdR+tyciCdmrVJhLeRZMngbkzNpWPkB zrcKJwCxkzqU7nIaF6HsmLerNt22g+UL4tCFZ9xDxWUgjCYPAEwwSZMn8Oh7+DpBkulW IvejzXxgJDvuEI+9MtICPvcnlwZFfVFcSorYD9wlMSYdrf/MYe92v3RltRXuh2sHbwm7 z81qKLXytpPx3SQtMjKm9AT5wR+jCwAQMfhzGJeFaTb5QsSXWmbrxNNQq9w9YiuLvJ7z tx+w==
X-Gm-Message-State: APjAAAXZZ3DyZBhK1GJo4/uz5jgc1osRN3YHgcvaFbyDDtb4FycBtf/y e7PQK1g1H7pqIe1ILN6lueQuyFY+yioMVyJOu0q0Ow==
X-Google-Smtp-Source: APXvYqxp99Dr5cSPmmt8IRqHvnLwbvHK5JWRmiSRHb0tPlvmmR2KKRwp5weHb5C1k7P2+q+rjAT/5BudbuvOV6AY1yE=
X-Received: by 2002:a17:907:2102:: with SMTP id qn2mr25002213ejb.266.1567542845804; Tue, 03 Sep 2019 13:34:05 -0700 (PDT)
MIME-Version: 1.0
References: <156751558566.9632.10416223948753711891.idtracker@ietfa.amsl.com> <B7C5DF29-92B2-477B-9C30-F47E338038EE@strayalpha.com> <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <9331E721-F7F8-4C22-9BE4-E266726B3702@gmail.com> <7bfbaf5fa12c4a9bac3e46ece5dfdcde@boeing.com> <0BF34BFA-5F30-4EE1-9F5E-18D9ECA8D424@gmail.com>
In-Reply-To: <0BF34BFA-5F30-4EE1-9F5E-18D9ECA8D424@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 3 Sep 2019 13:33:54 -0700
Message-ID: <CALx6S37xhhS5ezhJu6-HQmftwY9cBzuCxeaW9thTbKBa2hizcw@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "int-area@ietf.org" <int-area@ietf.org>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/9Hwz68YwEs84YfuITmSQ_jPFrhI>
Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 20:34:23 -0000

Bob,

I agree with Fred. Note, the very first line of the introduction:

"Operational experience [Kent] [Huston] [RFC7872] reveals that IP
fragmentation introduces fragility to Internet communication".

This attempts to frame fragmentation as being generally fragile with
supporting references. However, there was much discussion on the list
about operational experience that demonstrates fragmentation is not
fragile. In particular, we know that fragmentation with tunnels is
productively deployed and has been for quite some time. So that is the
counter argument to the general statement that fragmentation is
fragile. With the text about tunneling included in the introduction I
believe that was sufficient balance of the arguments, but without the
text the reader could be led to believe that fragmentation is fragile
for everyone all the time which is simply not true and would be
misleading.

Speaking of balance, the introduction also mentions that:

"this document recommends that upper-layer protocols address the
problem of fragmentation at their layer"

But the "problem" of fragmentation is in intermediate devices that
don't properly handle it as the draft highlights. So it seems like
part of addressing the problem should also be to fix the problem! That
is implementations should be fixed to deal with fragmentation. IMO,
this should be another high level recommendation that is mentioned in
the introduction.

Tom



Tom





On Tue, Sep 3, 2019 at 1:01 PM Bob Hinden <bob.hinden@gmail.com> wrote:
>
> Fred,
>
> > On Sep 3, 2019, at 12:45 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Bob,
> >
> >> -----Original Message-----
> >> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> >> Sent: Tuesday, September 03, 2019 9:10 AM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Joe Touch <touch@strayalpha.com>om>; Alissa Cooper <alissa@cooperw.in>in>; Joel Halpern
> >> <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; int-area@ietf.org; IESG <iesg@ietf.org>rg>; intarea-
> >> chairs@ietf.org
> >> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
> >>
> >> Fred,
> >>
> >>> On Sep 3, 2019, at 7:33 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >>>
> >>> Why was this section taken out:
> >>>
> >>>> 1.1.  IP-in-IP Tunnels
> >>>>
> >>>>  This document acknowledges that in some cases, packets must be
> >>>>  fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels].
> >>>>  Therefore, this document makes no additional recommendations
> >>>>  regarding IP-in-IP tunnels.
> >>
> >> This text in the Introduction was removed because, as noted in Warren Kumari
> >> Comment (2019-08-07 for -15), this didn’t need to be in the introduction, and it didn’t say very much that isn’t described later in the
> >> document.
> >>
> >> The normative text in Section 5.3. "Packet-in-Packet Encapsulations” is unchanged.  I think Section 5.3 covers the topic.  It includes the
> >> reference to [I-D.ietf-intarea-tunnels].
> >
> > While I agree that both passages supply a working vector to 'intarea-tunnels',
> > the two strike very different tones. The former gives a balanced citation, while
> > the latter calls it a "corner case" - twice!
> >
> > Whether we like it or not, fragmentation and encapsulation will continue to
> > be associated with each other no matter what gets documented here. So,
> > a respectful handoff to 'intarea-tunnels' would be appreciated.
>
> You are talking about text in the Introduction of the document.
>
> The important substance relating to tunnels is in Section 5.3.   The text is:
>
>    5.3.  Packet-in-Packet Encapsulations
>
>    In this document, packet-in-packet encapsulations include IP-in-IP
>    [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP
>    [RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473].  [RFC4459]
>    describes fragmentation issues associated with all of the above-
>    mentioned encapsulations.
>
>    The fragmentation strategy described for GRE in [RFC7588] has been
>    deployed for all of the above-mentioned encapsulations.  This
>    strategy does not rely on IP fragmentation except in one corner case.
>    (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473).
>    Section 3.3 of [RFC7676] further describes this corner case.
>
>    See [I-D.ietf-intarea-tunnels] for further discussion.
>
> Seems fine to me, in tone and substance.
>
> Bob
>
>
> >
> > Fred
> >
> >> Bob
> >>
> >>
> >>>
> >>> Tunnels always inflate the size of packets to the point that they may exceed
> >>> the path MTU even if the original packet is no larger than the path MTU. And,
> >>> for IPv6 the only guarantee is 1280. Therefore, in order to robustly support
> >>> the minimum IPv6 MTU tunnels MUST employ fragmentation.
> >>>
> >>> Please put this section of text back in the document where it belongs.
> >>>
> >>> Thanks - Fred
> >>>
> >>>> -----Original Message-----
> >>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch
> >>>> Sent: Tuesday, September 03, 2019 7:06 AM
> >>>> To: Alissa Cooper <alissa@cooperw.in>
> >>>> Cc: Joel Halpern <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; int-area@ietf.org; The IESG
> >> <iesg@ietf.org>rg>;
> >>>> intarea-chairs@ietf.org
> >>>> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
> >>>>
> >>>> Hi, all,
> >>>>
> >>>> So let me see if I understand:
> >>>>
> >>>> Alissa issues a comment.
> >>>>
> >>>> We discuss this on the list and come to a rare consensus on a way forward.
> >>>>
> >>>> The new draft is issued that:
> >>>>
> >>>> a) ignores the list consensus
> >>>> b) removes a paragraph not under the DISCUSS (1.1)
> >>>> c) now refers to vague “other documents” without citation
> >>>> d) most importantly:
> >>>>
> >>>>    REMOVES a key recommendation that we MAY use frag where it works
> >>>>
> >>>>    Asserts the false claim that IP fragmentation “will fail” in the Internet,
> >>>>    despite citing evidence that the *majority of the time* it does work
> >>>>            e.g., for IPv6, sec 3.9
> >>>>
> >>>> What happened? Why is a change this substantial not reflecting the *list consensus*?
> >>>>
> >>>> Joe
> >>>>
> >>>>> On Sep 3, 2019, at 5:59 AM, Alissa Cooper via Datatracker <noreply@ietf.org> wrote:
> >>>>>
> >>>>> Alissa Cooper has entered the following ballot position for
> >>>>> draft-ietf-intarea-frag-fragile-16: No Objection
> >>>>>
> >>>>> When responding, please keep the subject line intact and reply to all
> >>>>> email addresses included in the To and CC lines. (Feel free to cut this
> >>>>> introductory paragraph, however.)
> >>>>>
> >>>>>
> >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>
> >>>>>
> >>>>> The document, along with other ballot positions, can be found here:
> >>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----------------------------------------------------------------------
> >>>>> COMMENT:
> >>>>> ----------------------------------------------------------------------
> >>>>>
> >>>>> Thanks for addressing my DISCUSS.
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Int-area mailing list
> >>>>> Int-area@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/int-area
> >>>>
> >>>> _______________________________________________
> >>>> Int-area mailing list
> >>>> Int-area@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/int-area
> >
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area