Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Tom Herbert <tom@herbertland.com> Tue, 06 March 2018 19:41 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 D755B12D7E4 for <int-area@ietfa.amsl.com>; Tue, 6 Mar 2018 11:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 50u7pRAOdMHu for <int-area@ietfa.amsl.com>; Tue, 6 Mar 2018 11:41:36 -0800 (PST)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 5203C126BF3 for <int-area@ietf.org>; Tue, 6 Mar 2018 11:41:36 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id l206so26313214qke.1 for <int-area@ietf.org>; Tue, 06 Mar 2018 11:41:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+lrlwhXmQC7PkiEJep+vfNOl6ZOHN3wVI8dmcRxvUAU=; b=tkECvb+lNDHUga6XeQCFPrwiY9orohiHWPeIHN2ML+q7nAgdtUYZIJHjG/es0zftux zhi5a9zEnifqkgT3AMcs/FsULnPd+91kH01LHMjNX+noQ+vgW5NKOiOz8/xTDnmZQybx dz3Iu3aRJdPukmqTXmDh8YWkmfTB8ZGDSvoSwafyKOGM2GEIeAJbD+fyp63zde5KwiHq LbxL+1IDdZMQP5wCqUw+N4Ee05vYzBCG6/WMlB/P2cl/OiSCD68MBuw1fB8jfxzHcBsx 9jDIqUu+CtHv6nh/zv+3gTY8Zqhi6nUr22YK956bLbGJFF0H5vcYUpC8VcIyMYrxj2Cv I/Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+lrlwhXmQC7PkiEJep+vfNOl6ZOHN3wVI8dmcRxvUAU=; b=j+bgBBiY0zNCrOSAkgPAjvViirs7tYAXgCaY6lcYgpedqE7I3JX0qDEMeHyBWmZHf6 bp7nni28QAFGq2Mr5t1CY5HGAxTFJfHP4BkKJcHHOSmzp42UAyM9HI2wxQBCSRMWfFHg WPbCvGofueRBybHFemM6x/vyfBWJJ+VDJk/SrOHzw1f77IR2gNh7hkpjJPNzWlGNfG4i XBGR67Cc83Nw88hHxRQutfmEykYmg5Q265FuyCI24fxICZmpw/lF7smXjE54f8Y42nvW u54Leew9pUeMvq+qhSWyh7lGZIwEySeBf8Sdt//X9Vi/7/wkTkvbSFXSXMsDX9f/kaDq NhQg==
X-Gm-Message-State: AElRT7GqoK3edP4dO4ai9jcAt4aPvXJQoYN/I7nHv/RBnoj4F6jtmUdR 9Bponotkjy+kZPPL3N5uWzg9R3Lipjf8eqsUPZfn7A==
X-Google-Smtp-Source: AG47ELu3HPzhCkzvTe2pMlmfYqjLHVRBWj5kaIWVUsTtVY+8DnRFgRHVE2elPfrR/DX5RARbg5yPfafLSW3U2C5ygh0=
X-Received: by 10.55.110.7 with SMTP id j7mr30290177qkc.168.1520365295291; Tue, 06 Mar 2018 11:41:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.26.181 with HTTP; Tue, 6 Mar 2018 11:41:34 -0800 (PST)
In-Reply-To: <FA95FB35-C4C4-45E9-A604-8E96367BFE00@employees.org>
References: <BLUPR0501MB2051C0DCCE28384FCD08F7C4AEDA0@BLUPR0501MB2051.namprd05.prod.outlook.com> <CALx6S37q8zLQidnyFRBnQSkzFv6ZegohpCTSRnARjikbNSa_yw@mail.gmail.com> <3B1D63EF-36E4-4AA5-B51D-36CC7614A7D9@strayalpha.com> <FA95FB35-C4C4-45E9-A604-8E96367BFE00@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 06 Mar 2018 11:41:34 -0800
Message-ID: <CALx6S36N4V1irHhnCd6r2CTOfr8zB7d8=gpJWkjKtue5cERsXg@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Joe Touch <touch@strayalpha.com>, Ron Bonica <rbonica@juniper.net>, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/dNJv7c8IUPxZOtc32IOrJKgr0uM>
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
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, 06 Mar 2018 19:41:38 -0000

On Tue, Mar 6, 2018 at 11:16 AM, Ole Troan <otroan@employees.org> wrote:
> Joe,
>
>> Agreed but note that draft tunnels will update that RFC in some important ways.
>
> With other concerns than those raised in e.g. 4459 and 7597?
> Unfortunately there are cases where there are no other choice than to do fragmentation/reassembly on tunnel endpoints, but still the recommendation holds.
> It is so problematic, that it is strongly recommended to engineer the network to avoid that happening.
>
Hi Ole,

That may be recommendation, but that is not was has been done all
networks. I worked in two very large datacenter networks that use a
lot encapsulation, but they didn't do anything special to engineer the
network for encapsulation. There was reluctance to set an MTU below
1500 and jumbo frames were always discussed, but in the end they
deploying them seem to be more complicated than it was worth. So
fragmentation did occur pretty regularly at tunnel ingress.

Fragmentation never popped up as a problem because of some mitigating
factors: 1) packets from the Internet be encapsulated usually were
already less than 1500 bytes(when encapsulating for VIPs) 2) This
always generated precisely two fragments 3) encapsulation is being
done on a closed network so there is no chance of DOS attack on the
reassembly cache (fragments from the Internet are dropped) 4)
encapsulation is otherwise rare relative non-encapsulation, so
lowering the MTU would only benefits the special case and hurts the
common case.

Tom

> Cheers,
> Ole
>