Re: [Int-area] Tunnels and Fragmentation

Bob Hinden <bob.hinden@gmail.com> Sat, 18 April 2020 15:38 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 D0F353A0B2C for <int-area@ietfa.amsl.com>; Sat, 18 Apr 2020 08:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 CnK7-qqo-4av for <int-area@ietfa.amsl.com>; Sat, 18 Apr 2020 08:38:42 -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 C00A93A0B2B for <int-area@ietf.org>; Sat, 18 Apr 2020 08:38:41 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id t63so4916468wmt.3 for <int-area@ietf.org>; Sat, 18 Apr 2020 08:38:41 -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=3v+o4W9XYp8sQeHSzBGTSml2vQ2lVliNTO8MA6jjcYg=; b=b0FIKkptA2h6PpSWVw7DNJo2ado4XK3OGroeE0kWUlz3py4pdGlYDlv6lO/AkP5EOQ ebBUE/zL1RDqmv1v9IX8f3POjI0RCauSXu9Oibo4UqBLw6uSqs31uad5fLBP2xxvr5UE HEQ5OZrLLPS8Wirt0XnjDB0j/DFGSADBYuH/XrE7kkmJNqutXTn9cxelojDD5j9m6lLo gODgId3Fllmxn1e4eA1y2+uzGHZYGMWKXdCW4dS4f9RefH2QFGLVCKxb0h57YXDeH34H 3slkKaCddGcFOTmiPVV62xW0BgWJ9jNEOsAdJbujXO6P+lIWC13eiz9BjKKn4MdvyWcg z2xA==
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=3v+o4W9XYp8sQeHSzBGTSml2vQ2lVliNTO8MA6jjcYg=; b=sO+H1CPN2UyEE5bTXEeUrERpmML+dO8D6Kfz4tyBb+ZDejfxtxNr5Dgao8f6ubs5Xd GZAwfNM3WX+5Mj0S3XvPzem5zHau7+WM0vOUXcYveVyNkeauBHhVVE3ZjbATPbbG3PFJ Y46fyobT8OiEz46TvQypCoOOtlTk1vz/6bLphEgbxhf4wkjGZtUJm1Ad7XSLoH8JdYcd SOnac6AYlF7V6ye7gpO7zhyq20LeZRTSnKx8B4L7Imtslz2PXdx9IEuerQpsZOWUf9LN XI4hxWJBH3ANvGa+ZytVHBcUdcUdFA8o1L4pjJ5h/T6eSRXSdKfjbviHlvHkcRT5+0mt 282w==
X-Gm-Message-State: AGi0PuY2C6M6zd4sO+NPSQaqjo9NI0ly4QpHrQ9H9iZ7w8sAUFlxIAz6 z7DFDRoGmyjoVKHBjKiPwL4=
X-Google-Smtp-Source: APiQypIPQXaLaHpJmE3Xcu4/1foWVjreFQn6JbWf7f/FCZiD94NRPauIU9T3Y/TUAzNttJtGcHIuOw==
X-Received: by 2002:a05:600c:1:: with SMTP id g1mr3890145wmc.142.1587224320263; Sat, 18 Apr 2020 08:38:40 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:1016:1367:e7c6:2260? ([2601:647:5a00:ef0b:1016:1367:e7c6:2260]) by smtp.gmail.com with ESMTPSA id k6sm2577278wma.19.2020.04.18.08.38.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2020 08:38:39 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <E7AD694C-0603-4B7F-BFA5-3066B9AF89A9@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E50D5E09-A12F-4534-B8AA-1FE93AF0203B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Sat, 18 Apr 2020 08:38:35 -0700
In-Reply-To: <2053570c8e0343ed818bea1e81fb6e9b@boeing.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, "int-area@ietf.org" <int-area@ietf.org>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
References: <85c46613772e439881e079a0037eb866@boeing.com> <9839CEEF-DC95-4AEA-9495-1BC42B241DD2@gmail.com> <2053570c8e0343ed818bea1e81fb6e9b@boeing.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/L6cmM24DFMx50FxXK31hRxX8-90>
Subject: Re: [Int-area] Tunnels and Fragmentation
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: Sat, 18 Apr 2020 15:38:44 -0000

Fred,

> On Apr 17, 2020, at 10:23 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> Hi Bob,
> 
>> -----Original Message-----
>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
>> Sent: Friday, April 17, 2020 9:38 AM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Bob Hinden <bob.hinden@gmail.com>; int-area@ietf.org
>> Subject: Re: [Int-area] Tunnels and Fragmentation
>> 
>> Fred,
>> 
>>> On Apr 16, 2020, at 2:36 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>>> 
>>> Hi, two important documents in this wg have been sitting idle for a long time and
>>> perhaps it is time to start moving them forward again. The documents are: "IP
>>> Fragmentation Considered Fragile", and "IP Tunnels in the Internet Architecture":
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
>> 
>> This doc is in the RFC Editor queue waiting for another document, it’s not “sitting idle".  It is essentially done.  The referenced
>> document (draft-fairhurst-tsvwg-datagram-plpmtud) looks like it was approved by the IESG recently, it’s state is "Approved-
>> announcement to be sent::Point Raised - writeup needed”.  Should be done soon.
> 
> Hold the phone. We now have a  robust and useful case for IPv6 fragmentation when
> applied to tunnels. Can we still update frag-fragile before it gets published? Or, do we
> have to wait and update it *after* it gets published? I would prefer before, because
> allowing to publish as-is with knowledge that an important update is coming just
> perpetuates the undeserved bad name given to fragmentation 33 years ago.

In my view, no it can not be updated.  It is past AUTH48.   We would never publish anything if we wait for anything that might happen in the future.

> 
> Also, what about intarea-tunnels? That one shows up as expired, but shouldn't we
> dust it off for publication too (after updating to accommodate new findings)?
> 
> 

I can’t speak to that, as I am not an author.

Bob



> 
>> Bob
>> 
>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/
>>> 
>>> What has changed is that we now have  a spec for robust fragmentation over tunnels
>>> while supporting a 9180 MTU (actually MRU) plus lossless path MTU discovery. The
>>> spec is known as the Overlay Multilink Network (OMNI) Interface:
>>> 
>>> https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
>>> 
>>> So, what I think needs to happen is for authors of the two intarea drafts to review
>>> the OMNI spec and update their documents accordingly. Then, maybe we can get
>>> a few docs published?
>>> 
>>> Thanks - Fred
>>> 
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>