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

Bob Hinden <bob.hinden@gmail.com> Wed, 04 September 2019 15:29 UTC

Return-Path: <bob.hinden@gmail.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 241C4120164; Wed, 4 Sep 2019 08:29:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 biNspvIpm65P; Wed, 4 Sep 2019 08:29:30 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 D789712011D; Wed, 4 Sep 2019 08:29:29 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id t17so3805760wmi.2; Wed, 04 Sep 2019 08:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dC/ky8U8Ab0ipVlXA+4hRpef0IBusJfVpESTc6gx0Ro=; b=r+jDbLzChy31IYPBL/sZ8fW4yOXHxpya4ObINfUZesFJUTHJdPOmm/YBt/ag1U2ATL 7+9kMn9sDYJPfc45wEGLTCOL/74HWLxjSTFHKf7pm6/x7tE4yPAH6zfPJxEjgmuGIbp/ gcXffDhnVhcq+YFe0z5xZJFRQgK4QB3PoeBkZDohpeuyw1/zOm4fU6QnPr6EoMtdapLZ hvt0hmJv3Uqgfz8cOXt4MmuP3TWZuiTCBX8gnf3ttN9XVdQ9qqANnjila4yJaDdSfxEE 3GxtBh/ZwKSwHzC4kF+EjyqH7UhpZSdxrcr1dADFlWcSjZxK6eWp+wAPnmbiQGfnRmTf DQQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dC/ky8U8Ab0ipVlXA+4hRpef0IBusJfVpESTc6gx0Ro=; b=lQMXXwUom/JleFI5s662pryVh8KkYUGmIxon0RnC8LG0JFGuefo2tGo1eRSD+LPHyc fodtC0vHwP9mdE4UOvBZNp3a+yDbNe8B5dVjfkbqCxHcONIBfvyex+9uxG7w3IgXdCMt wJq6u8kBjcfZsCzIRGabqSe5PZTzoZC9MtSEVCPIv3ydCoBJ86MrHXa5KKLamsDtFjL4 FnWOMmzJhBEmnC6335z6bB5yXHSy84YRDlNawkFFYNhA/rOL6JdUlXSthaMJ+0BJmYHt prMWIdkq9pePGoIH6kFe4p1ep/+ZfoEXhX5T7A0aOFCX5x9MWdoogiNaEzF1kY+8EzTs G+Zw==
X-Gm-Message-State: APjAAAWXAG9b15n7z+8TA3rQbUVJlwSLu+yKxGiX7etgQ28RK7UDgxNO a24J6ENa5YgmC7/FRIyxSH0=
X-Google-Smtp-Source: APXvYqyny+p+GsOfBEYsM/V3KDVMUKvTTb1C2eTXs5aEyuoNXJMy+0RK9GdPyviwm6kvn3yPmF+NNw==
X-Received: by 2002:a1c:f60c:: with SMTP id w12mr2752864wmc.4.1567610967258; Wed, 04 Sep 2019 08:29:27 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:f954:34b0:ff7a:6463? ([2601:647:5a00:ef0b:f954:34b0:ff7a:6463]) by smtp.gmail.com with ESMTPSA id a18sm3044735wrh.25.2019.09.04.08.29.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2019 08:29:26 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <243A9D20-8F03-4401-93D4-AF291A91B600@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_9D78046D-0D87-447A-B160-2D10E5B11C4E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 04 Sep 2019 08:29:20 -0700
In-Reply-To: <25c7130ecf734692a4f6746141d96038@boeing.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Tom Herbert <tom@herbertland.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>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
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> <CALx6S37xhhS5ezhJu6-HQmftwY9cBzuCxeaW9thTbKBa2hizcw@mail.gmail.com> <A8A10E03-6EEC-4F60-A213-7D66084BA754@gmail.com> <09d0dc428430407f8154f40d47a417dc@boeing.com> <3AF76A3A-E18D-4CC2-8FA8-6A465FD06E28@gmail.com> <25c7130ecf734692a4f6746141d96038@boeing.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/vsYizVf7hnaK0btAjd7jvisK6ks>
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: Wed, 04 Sep 2019 15:29:32 -0000

Fred,

> On Sep 4, 2019, at 7:23 AM, 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 5:08 PM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Bob Hinden <bob.hinden@gmail.com>; Tom Herbert <tom@herbertland.com>; int-area@ietf.org; IESG <iesg@ietf.org>; Joel
>> Halpern <joel.halpern@ericsson.com>; draft-ietf-intarea-frag-fragile@ietf.org; 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 2:10 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 1:57 PM
>>>> To: Tom Herbert <tom@herbertland.com>
>>>> Cc: Bob Hinden <bob.hinden@gmail.com>; Templin (US), Fred L <Fred.L.Templin@boeing.com>; int-area@ietf.org; IESG
>>>> <iesg@ietf.org>; Joel Halpern <joel.halpern@ericsson.com>; draft-ietf-intarea-frag-fragile@ietf.org; intarea-chairs@ietf.org
>>>> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
>>>> 
>>>> Tom,
>>>> 
>>>>> On Sep 3, 2019, at 1:33 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>> 
>>>>> 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”.
>>>> 
>>>> Yes, that text in in the first paragraph of the Introduction
>>>>> 
>>>>> 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.
>>>> 
>>>> Yes, but we are discussing some text from the Introduction that to my read didn’t say anything useful so I removed it.  The
>> substantive
>>>> text about tunneling in in Section 3.5.  The Introduction, is just the introduction.  The text was:
>>>> 
>>>>  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.
>>> 
>>> Yes - good text that should be retained.
>>> 
>>>> Why is that more useful than what is in 3.5? If it’s not making a recommendation, why call this out in the introduction.  There are lot
>> of
>>>> other things it doesn’t make recommendations about that aren’t in the Introduction either.
>>> 
>>> Because it sets a more appropriate tone and lets the reader know from the onset that
>>> fragmentation and encapsulation go hand in hand. And tunnel fragmentation avoids the
>>> issues raised by others in this thread.
>> 
>> I don’t know how to evaluate “tone” in an IETF specification.
>> 
>> How about if I move this text to section 5.3?  I think that’s better than in the Introduction.
>> 
>> The section would be:
>> 
>>   5.3.  Packet-in-Packet Encapsulations
>> 
>>   This document acknowledges that in some cases, packets must be
>>   fragmented within IP-in-IP tunnels.  Therefore, this document makes no
>>   additional recommendations regarding IP-in-IP tunnels.
>> 
>>   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.
> 
> Paragraph #1 beginning "This document acknowledges" looks good, but then
> why include paragraphs #2 and #3 since 'intarea-tunnels' is the place to discuss
> IP-in-IP encapsulation. So, why not shorten Section 5.3 and have it as simply:
> 
>   5.3.  Packet-in-Packet Encapsulations
> 
>   This document acknowledges that in some cases, packets must be
>   fragmented within IP-in-IP tunnels.  Therefore, this document makes no
>   additional recommendations regarding IP-in-IP tunnels.
>   See [I-D.ietf-intarea-tunnels] for further discussion.
> 

This text has been through IETF last call and IESG review, and as far as I can tell is factually correct.   Unless we want to repeat that, better to not remove it in my view.

I will plan to include the new first paragraph in the next version.

Bob