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 01: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 279D412008F for <int-area@ietfa.amsl.com>; Tue, 6 Aug 2019 18:50:35 -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 3f1R7jBCnpCd for <int-area@ietfa.amsl.com>; Tue, 6 Aug 2019 18:50:34 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 573A5120091 for <int-area@ietf.org>; Tue, 6 Aug 2019 18:50:31 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id k21so84418408edq.3 for <int-area@ietf.org>; Tue, 06 Aug 2019 18:50:31 -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=Em6dTN3zuwWkcjJ9nI6gSPphdeHjHHsUb+de+7R5POs=; b=TUCCwRnnDd3r2+X9hzH/UW4D4RcrYcIG4nhEFxWdeSd8ciGF5LP3ZU6xnUkAG27Sm1 T8jN9qqURCyL7JQGs7FoV+lWtkqFtPfhXR8INPneL+quIUd6JOwdKaavaYSU9dAiCETs JnSv5cTgPLTyhtqSFREfADstei9/WgnIq58K/1n7hKHgYwGeCLsmB5POnjS6pzHO4JEA G0UeeD7V7zl/mLsIrnjTyBz+MBCUc6Lao4VhfHehfnldsHnVdd0iZ3UjoPjVj0g2coxO /aAoKrkbpN4GFCqEeY7gMzdt2AJECQZXTGIACFverLtUuFxY8zNewBx+puFTnWmqCpn7 OOcg==
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=Em6dTN3zuwWkcjJ9nI6gSPphdeHjHHsUb+de+7R5POs=; b=TrF7bknJIQksKepUjfuZ+S8Z5GZC35FeKr6RbHmXk+sIl65RhKCW9LQv7kz+63Wto/ LfqMduNJ3R/hj1G6ereDxw9oZgzxwEgYFOlKYyFXN3w0sPgrtuT9CHvRbJuctc1IWvB3 snc6ODbAHGQXYv1XBSjsr3+uan/14RBvx/lACji6gBMdEAi6zCQfm48v2HZlnaGbwKYY T5V4N6W3aChyQhr6qK7p7Lv2uHPUVNtO/w4YVlWOZSwzTesgOnh9WOYds29HO/CbIym9 vAJeI3J0k2lFNhlJTBRN62OHvBCEqVynYPBIZW5HDI+fnZsyk9tmKjlHZkmwNjt3l4wV 4lAw==
X-Gm-Message-State: APjAAAWF84r29e+NwLGj5N52nQLRwdSV8pTQy769TZ45Deue7N0AfcBV 6hYswrC8IEgE0AF2NMB1/9odgTm9x6wOLgqXIq9s0Q==
X-Google-Smtp-Source: APXvYqyA1RAJrvQ8PCd62FjT3+K7uIlscfFU5fBMfrsZbOR4tkTSx56mPCnZbW6zx1+Ep54wlRbh+kl+GdI3wU7X0us=
X-Received: by 2002:a50:9646:: with SMTP id y64mr7073832eda.111.1565142629740; Tue, 06 Aug 2019 18:50:29 -0700 (PDT)
MIME-Version: 1.0
References: <156512344887.27340.5761295053779083959.idtracker@ietfa.amsl.com> <ecf3708f-d871-9ecf-02be-c70c2f890a66@si6networks.com>
In-Reply-To: <ecf3708f-d871-9ecf-02be-c70c2f890a66@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 06 Aug 2019 18:50:17 -0700
Message-ID: <CALx6S36-HK_UyJj4ssFFzcVZ8Zi8+GXcuJpCP0Er5aDBx-2DJw@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/Id_RnnZUTYdm-pGCCwyFCY-Dy1U>
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 01:50:35 -0000

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. The possibility that
the tunnel overhead causes the packet to exceed the path MTU of the
tunnel underlay needs to be considered. The typical answer, as pointed
in draft-ietf-6man-segment-routing-header-22, is to just set the MTUs
so that the addition of tunnel overhead doesn't exceed any MTU. For a
large scale domain that may not always be feasible. Using
fragmentation has been good solution in such cases.

Tom

> I wouldn't mind myself stronger advice, but this is what the wg settled on.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area