Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

Jonathan Morton <> Thu, 03 December 2020 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B3133A0964 for <>; Thu, 3 Dec 2020 11:39:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PBegWbKOZG8d for <>; Thu, 3 Dec 2020 11:39:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E62D93A0930 for <>; Thu, 3 Dec 2020 11:38:59 -0800 (PST)
Received: by with SMTP id o24so3869638ljj.6 for <>; Thu, 03 Dec 2020 11:38:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ZlUWbnBlKPFGwG2fS7aRcT06igqGZah94s9yuaCnAo=; b=BfJQGi3G+8JVLunTrC/Zd1T6BG1i19FxLM58ObS2VrPR+R+tMPADxRPUrOkbjkyyAY K2VBziR2pmyUgWfhebE55Z9mO03v5Re79uDuRC5weii7z2Q1/QexruR0F53xgmleMdut Azx2cTpgQh0t56Zv9U7s2yI12LZmDny8A4G3JmTrdPorVEnTvwm+GX81R3WB4SYWma93 EjWq6K2etwKKsryV1UwZ+2OzCE5jv35uPE0y5uOXHIajLdqkj5V6uzvxR9RigsUoSJYS ArrgZ2SihdoDY1zE3BXAlCDPps7k9lYE+xfxdl35V4mEa/9iPVsbSqE+A2y0R94MSpaW gODw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ZlUWbnBlKPFGwG2fS7aRcT06igqGZah94s9yuaCnAo=; b=LkBJIpx/LEzu8FJjxeYF+cQLDi+MxjxTmUaPex7BoQVPwPSEvbxccNV6VvH3PGqeTH rbI7ws8IJzB117SQaERTEkpXGpSDWrVayYh8JB5YVViXRl6KLqW39ULjU0K+rj29aU7j F0A4cuGlyxLV+1/nAWPnCrX72YG7ZRQ3fZ3JLArWQbRZcXr9oYZ4xq5hX/sZO3T52jsG FbytzVvoeW54Qay1oCBU6+QNNLbhqJOLCweKtNXKPknIZzIznMB7ry1bUQeOUT51qK0M IfmpNc0c89BIkyDCalQwwvwFW67XMa82DFgfSUULo/BdKhHOA8OjKtD/cog+CRrC2jSD iGKw==
X-Gm-Message-State: AOAM5319cvx0bTYx3lKy94WvaqOxGZ7MyyOTp5BPz6bHr9deIc7XfJuA 0lEhrLGIWw6jRmivbLYtl1oHjdsGw9w=
X-Google-Smtp-Source: ABdhPJw8P9pe39f2qqAfYuKeKgoF77BVu65XQFS7fdfU6syDSG+tj+yvrrG88SNxoDGHAnGw2Ca+Ng==
X-Received: by 2002:a2e:9707:: with SMTP id r7mr1781435lji.265.1607024338068; Thu, 03 Dec 2020 11:38:58 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id i27sm829713lfg.254.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 11:38:57 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Thu, 03 Dec 2020 21:38:55 +0200
Cc: Bob Briscoe <>, Ingemar Johansson S <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)
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: Thu, 03 Dec 2020 19:39:05 -0000

> On 3 Dec, 2020, at 6:40 pm, Gorry Fairhurst <> wrote:
>> Frankly, the sooner the WG understands and accepts that basic fact, the sooner we can move to a viable solution - one which does not redefine CE from the semantics established by RFC-3168 and RFC-8511, and hence does not place burdens on networks which have no interest in the L4S experiment.
> I think we need to be clear that I understand the proposal is to an Internet-wide experimental deployment.

An Internet-wide experiment will inevitably need to deal with a lot of "legacy" networks which have never even heard of L4S, have no pressing desire to change their equipment to accommodate it, and might find it challenging (or at least costly) to do so even if they desired to.  This especially includes those networks which have already invested in deploying plain old ECN, most of whom will have done so relatively recently and are still depreciating those assets.

That's precisely why L4S needs to show that it is safe to deploy into legacy networks, which may depend on existing RFC-3168 assumptions for their operation, before it can be approved for an Internet-wide experimental deployment.  We have been trying to make that point for two years already, including through several of the issues (still open) raised at the previous L4S WGLC at Montreal.  Meanwhile, ECN deployment has been increasing (see Jake's data).

 - Jonathan Morton