Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

Sebastian Moeller <> Mon, 16 March 2020 09:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47B9E3A21D6 for <>; Mon, 16 Mar 2020 02:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WIpV6htJwizx for <>; Mon, 16 Mar 2020 02:19:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D0CA3A21D9 for <>; Mon, 16 Mar 2020 02:19:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1584350371; bh=pn76y/X6ZVqD4b8CHxjCeZ2VHdxPCah9P6QyOR0Stx4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=QWIJwU+0MsyLswA6WSgu5DDB2z4L4t0PGEAUNd0g3G5++Khubd4NA05tA3UIu3ihF WtpfvcGV+P7/05aRsY0sDmJoB/WbPrDlFwEw/yTkbVhaSevDnYNqUcrpfXz/WcJSDW 7wbM4KJ8jSOlS4DDDDl/qROjGOe5vKEW++LeVh9c=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MvbBu-1jTmr70efu-00sbmW; Mon, 16 Mar 2020 10:19:31 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Mon, 16 Mar 2020 10:19:27 +0100
Cc: "Rodney W. Grimes" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:oERayYMXMaQh4eDlJ3g0fU2GOEVpWHdDdR1mGiEL7H5Zq6bJ9Dn gdMdIqfFfWgbE6EXn778QvGXaa9kBzl+fY2KTct99uR4AnGVdCLscc3oDF1xbr0he+xF9re 5d2wUIf/YtcVEwwNl1Vv81cd61mxU5kvmHE1IRzyOuxxM6GiSpLnG0p/GwxiCflUMJA+rGl CmH0g2dSPYwsuy2Ng6qvA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:t2HqPVwY1F0=:MmYaA/r1KdCLdqnpfSKIfr V97MMzsiaUrYDodcklCRpA7vFtxHL4d3hf25NVoVfCkcJ5jVyQEUYiLyzU5QwUsz5D5EHdkSm nq/JV7PonyaFd6XpsO/56utj5i0eQq34h6EMsdCmUZ1EW3BDnUFsSOnvyoT/s84ZbvB7UW46T tzauzVXqSOzqUaJd3HqwtImnGpkTA41SF+Um+UZImgKEFYx7KHl5X03crfngGeHECA3hAoZTw bzHbvkOAlwxv6h8GFYciKB0lFSeMUlQxbJXhGZofTRhpNN1qX7jQNsXff6VqVqnlFb4fzL8me yvZiuhLC630DvTvvkUjaaj4XYbge05N3XCCFWfDs0DzJOA/NUQ3R6ZLa7vyCAzohc2lfarec9 l9hv56Ll4uoynyAviwG4/sEkHiW0r0GWLO502y2pBCL+yCBtBVsukSZy3+KoFttxmDX9tFbbD qPRgpiCI4PIacz4RQ0v/BMtAjsAheuOd02RVB3UBMbdKdF+u4YpWEXQBrqrgwI9XQB+ESRYmM wZLxmmFeyL8WHwJAG+V0xEwGw1KiDahN6s8BIDVCEntwA8M9IbeQy+aX1U1S2F/IYgXyCQ25C v4Iijc0sgh0ePzc4TPHRJT9y2hywmiXhIj+CC663mCf+TjOF88UdheAYsMBMhHVTb8rRaNkuG uNqmIJa/ojIvJ+i+8Y1dUwifBmRc0mITKx0NWRymkQflE2N8R9vndNzqC9BnY5YqyckZiWxmc E4OfUZKQ+zKDk3PEKitKW54ylDU1uK4+KDsLLUqvwQ0whwwG+A/QHc+a6Lz1FcsQGPH/iUFyG PyXm7HHWux3aYOjd0RJuOFfFit+r5onBJAKg+g2PPGBoJ1610euPO74ZwYcjD4+tQtcMws93l LhrdHj6YYeS5j1bumZZolAEUeVSNKEtSJd4pWjkv2YdpyL0W3C5l45AH5EPbgAR16ZtOW92tv 3v4NA5S51SIVfxkXAn7GUPbiYuRAT5LS1NAPZ+23bKphrB38O+C8h1ysWJ8ZP0rQRmytPdgfT c2aFnb1cZthkwIUia1NhHqwXpqF5scIkn737F7l+5fqHzSBeaJoCloTFRdG+mC3IFjT7tBP3J Vnv4Lmd6g4sACRlWlZvxTgC5QS8x67aQZ9XVurcpXOEQnFuQHX7DNK8Ytjox8AAks84xqFrYU 27wcyyWG6F8EKZ8zXfCA0iN21cKSNlf9x/UsEcc41RVTzeui5A1jDrVZA6Nxvy/5OYwj/w6i0 Ik5UWa/NK7NNlU1tI
Archived-At: <>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Mar 2020 09:19:50 -0000

Hi Bob,

> On Mar 15, 2020, at 11:50, Bob Briscoe <> wrote:
> Rod,
> On 14/03/2020 22:18, Rodney W. Grimes wrote:
>> Bob,
>> 	Questions and comments in line.
>>> Finding the best max packet size is an area where neither IPv4 nor IPv6 
>>> has ever found a good solution. Getting a tunnel to fragment and 
>>> reassemble is indeed painfully sub-optimal, but all the other solutions 
>>> have their own problems. It is possible the sub-optimality is often 
>>> going on under-the-covers, just because it works. I do know that, for 
>>> IPv4, the Don't Fragment (DF) flag is often ignored by tunnels, as a 
>>> preferable alternative to just ditching the traffic.
>> What do you base your "know" on?
>> Can you please site an implementaiton?
> Here's a selection of implementations that allow you to configure clearing the DF flag in order to allow fragmentation prior to encapsulation:
> 	• Cisco IOS:
> 	• Juniper JunOS:
> 	• Huawei:
> 	• Ericsson Redback:
> 	• Linux: iptables -t mangle -A PREROUTING -j DF --clear
> While searching, I also found clear-df by accident in a firewall manual (not even doing any tunnelling)

	[SM] Isn't that a gross violation of the end-to-end principle? Or is the interpretation of the DF flag here, do not deliver fragments to the end-points, but anything transparent is fair game?

> And I even discovered "clear-df" in an (expired) individual Internet Draft from Ericsson for the Yang data model of an IPv4 tunnel: 
> draft-liu-intarea-ipipv4-tunnel-yang-02

	[SM] That might be use a "cover all bases" approach without actually endorsing any such use (let's try to model actual in-the-field-reality compared to RFC-reality).

> Note, these are not to be confused with suppressing propagation of DF=1 from the arriving IP header to the outer (so that a downstream router within the tunnel is allowed to fragment). In Linux, that would be: iptables -t mangle -A POSTROUTING -j DF --clear
> So yes, I know this is often done, but I don't know how often.

	[SM] Bigger question, should the IETF actually endorse something like that?

Best Regards

> Bob
> -- 
> ________________________________________________________________
> Bob Briscoe