Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)
Tom Herbert <tom@herbertland.com> Wed, 07 August 2019 15:50 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 62602120442 for <int-area@ietfa.amsl.com>; Wed, 7 Aug 2019 08:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 ZghEqfmu6iMO for <int-area@ietfa.amsl.com>; Wed, 7 Aug 2019 08:50:01 -0700 (PDT)
Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) (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 B0538120446 for <int-area@ietf.org>; Wed, 7 Aug 2019 08:49:59 -0700 (PDT)
Received: by mail-ed1-f65.google.com with SMTP id p15so86753058eds.8 for <int-area@ietf.org>; Wed, 07 Aug 2019 08:49:59 -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; bh=KMU7DdGRQF4MiQKYfLk3d7STBvoayPnyqSuyo42Af2c=; b=qEux2wKnEv2TfD7V/V0LcUj++4g6058qooA8u2fiEY7ExuqANBY9TxpXED6NI3K2YJ NqAUeqkvwXR4B4t5G6cs/yDAkC2pp+fNG4BLlC7bvICmRnglkjnpgPCTb3eNMo4tM7y8 kufYgBbhSFaf9yK+wUmkiqSwL3bWSk3wc7LBUYWH8Sz3k/aLv7lAoqfcPdV/dEKBHq/B l9TIQ5UP9mgRStHOUUeFgBtCWIIDq9pe4nCaLKEVaG8jljUoTZoTMWW35cd9EUcgrg5F 9ZcT0GMTFegG46VXewSFGcoVg4+UiGuD2IVlM7zWYJqLwJK082IoTwfR5+aG/Z9hrpHS fhNw==
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=KMU7DdGRQF4MiQKYfLk3d7STBvoayPnyqSuyo42Af2c=; b=VX/S0sn+TXgvCdw9R5hKcLx9V28iVj6mPhoCjy3gqrI6qaFmnVUq0uUoQ5lRagoVFl U4iqIJaAVlm6GNNAHw3FfokR8Xz/1tK7Ma+U/TAvlpm5kWLO55ti7Mcv9vvyVQUZcHv5 N+g7nqXFGCswrTKmWVZdwcwcwniIgwILCypmffM4zhWF8164cVJ8t1tMZr0bxrYvXRAO XqU8UWxRB6UVc9s5XL8UD+fgiM42m4PeuPYKdxj43Ebr/PdMkXGAydhxBtkF3yB95f+I IwUMX532kqKZx9ylqNiYsaKU41JuUV2IkZ/yIQesa/cPfzJHxUgIK2T/zNqI9THFv9ce 1PLg==
X-Gm-Message-State: APjAAAUlVW7XwqmYXebvhE5KRTSqrzv8WyTCEnW2WdPUTa5UWJZlEp0O T6MKdutt6WimgDUDbpdSRI7WFmNSZu6O1A5hR82FKw==
X-Google-Smtp-Source: APXvYqy/cUV6h0jTi7bI5Ne7WcZce59/zGhzbF1RhABn6WZHVMebRBFplqbBR10RyOuhomm4i1P8e3EiyEP0gjGVR/c=
X-Received: by 2002:a50:b87c:: with SMTP id k57mr10401882ede.226.1565192997823; Wed, 07 Aug 2019 08:49:57 -0700 (PDT)
MIME-Version: 1.0
References: <156512344887.27340.5761295053779083959.idtracker@ietfa.amsl.com> <ecf3708f-d871-9ecf-02be-c70c2f890a66@si6networks.com> <CALx6S36-HK_UyJj4ssFFzcVZ8Zi8+GXcuJpCP0Er5aDBx-2DJw@mail.gmail.com> <66451cc3-2014-e9fc-f817-ba998b644b0c@si6networks.com>
In-Reply-To: <66451cc3-2014-e9fc-f817-ba998b644b0c@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 07 Aug 2019 08:49:46 -0700
Message-ID: <CALx6S37VXNTUJtEu1v9DdZ2J-+F3O3eDjPy0n8V6M=ui23UcJw@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, draft-ietf-intarea-frag-fragile@ietf.org, int-area <int-area@ietf.org>, intarea-chairs <intarea-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/frnYrp-GOOvRC2nDnzSbMW0HiX8>
Subject: Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and 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, 07 Aug 2019 15:50:04 -0000
On Tue, Aug 6, 2019 at 9:00 PM Fernando Gont <fgont@si6networks.com> wrote: > > Tom, > > On 7/8/19 04:50, Tom Herbert wrote: > > On Tue, Aug 6, 2019 at 6:17 PM Fernando Gont <fgont@si6networks.com> wrote: > >> > >> Hello, Alissa, > >> > >> Thanks for your comments! Inline... > >> > >> On 6/8/19 23:30, Alissa Cooper via Datatracker wrote: > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> Thanks for writing this document. > >>> > >>> Section 6.1 says: > >>> > >>> "Developers MAY develop new protocols or applications that rely on IP > >>> fragmentation if the protocol or application is to be run only in > >>> environments where IP fragmentation is known to be supported." > >>> > >>> I'm wondering if there should be a bit more nuance here to make the > >>> recommendation clearer. Do we think there is a case where an application > >>> protocol developed in the IETF will be known to only run in environments where > >>> fragmentation is supported? If we don't think developing such a protocol would > >>> be in scope for the IETF, then I'm wondering if that case should be called out > >>> explicitly with a stronger normative requirement. > >> > >> An application (developed in the IETF or elsewhere) might be used in > >> some controlled domain, where fragmentation may be known to be > >> supported. The message here is "unless you really know what you are > >> doing and you're in e.g. a controlled environment where fragmentation is > >> to be supported, you shouldn't rely on fragmentation". > >> > > Fernando, > > > > There were several examples given of protocols in use in controlled > > environments that use fragmentation and justify that message. In > > particular, it is used in some cases of network layer encapsulation. > > For instance, consider that a packet entering an SRV6 domain may be > > encapsulated with hundreds of bytes of overhead. > > Isn't this the same thing I noted? i.e., you might have apps using > fragmentation in controlled domains. OTOH, if you expect to use it on > the public Internet, it is not reliable. Fernando, Neither is IPv6 reliable on the public Internet :-) The fact that a protocol isn't "reliable" isn't the same thing as it being deprecated. We know that fragmentation is difficult to use on the public Internet, and have already accounted for that in deployment. It IPv6 it's easy enough to restrict packet to packets to 1280 bytes when sending into the Interner. Controlled environments, which is the subject of Alissa's comment, is a very different story. There's a great diversity of MTUs and applications. Fragmentation has been integrated to the stack and has been the standard for years and it's in use. We don't know how much it's in use since the mechanism is transparent, probably the only time we'd hear about it is when there's a problem. So fragmentation is used, possibly even in widespread use for years, working for some subset of users, and people might not even realize they are relying on it. This isn't a bad thing, that's the protocol working as intended! To say that applications need to reevaluate that on the basis that IETF thinks is risky or some vendors don't want to support is long after the fact. In other words, if it's not broke, why fix it? In any case, my view of the draft is that it's describing the current state of affairs and in no way deprecating fragmentation. If someone is productively using fragmentation, they can continue to use it. When the draft says protocols SHOULD not be developed that rely on fragmentation is reasonable. The requirement is broad enough to allow the necessary leeway. For instance, I checked the network encapsulations in Linux, I don't believe any of them go out of their way to avoid "relying" on fragmentation. UDP encapsulations don't set DONTFRAG so if the user configures a larger MTU then the underlay MTU then fragmentation will be done (if an application or protocol is serious about avoiding fragmentation that would either set DONTFRAG or enforce packet size is less than minimum MTU in the implementation). So encapsulation protocols do rely on fragmentation in some circumstances, but usually provide guidance in the specification that it should be avoided (e.g. by manipulating MTUs). I think that is reasonable. Tom > > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > >
- [Int-area] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper via Datatracker
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Tom Herbert
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Alissa Cooper
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joel M. Halpern
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Brian E Carpenter
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joel M. Halpern
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joe Touch
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Fernando Gont
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Brian E Carpenter
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Tom Herbert
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Fernando Gont
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Fernando Gont
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joe Touch
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Fernando Gont
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joe Touch
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Ron Bonica
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Fernando Gont
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Ron Bonica
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Alvaro Retana
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Tom Herbert
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Ron Bonica
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joel Halpern
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joe Touch
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Ron Bonica
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Joe Touch
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Bob Hinden
- Re: [Int-area] Alissa Cooper's Discuss on draft-i… Fernando Gont