Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

Sebastian Moeller <moeller0@gmx.de> Thu, 25 March 2021 09:41 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78A3A1BA0 for <tsvwg@ietfa.amsl.com>; Thu, 25 Mar 2021 02:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 Uqv_QlaOWHzU for <tsvwg@ietfa.amsl.com>; Thu, 25 Mar 2021 02:41:44 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E4E3A1BC1 for <tsvwg@ietf.org>; Thu, 25 Mar 2021 02:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616665215; bh=hXsqTYtrLBN/TTkvhBLHscLPLZjbIJ7hX/+2rtPmAXo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=gz4opBdd7CAIIb7fTpZJHfWng2XWbpjsdeL4ew4UYqGZj+MwXtAeJwn9PgJoaTKGW NWpoF1tcxe6+NFcI77kI+2x2TR2CllSu68JwdM2fiUd4rqyHgmRKZPtJ2/q5G7C/lR oORjK6zEvk+lHnOy09hqw4Lj14XH6yufrb/J/a9s=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLQxN-1l8W8z4AXz-00IYcI; Thu, 25 Mar 2021 10:40:15 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <296c7a3b-15fc-5a30-efc0-cdc27a176db3@bobbriscoe.net>
Date: Thu, 25 Mar 2021 10:40:13 +0100
Cc: Steven Blake <slblake@petri-meat.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5AA611B-93CB-49FE-A57B-8293B4E15650@gmx.de>
References: <e9da704b-7705-baf9-a82c-39d4fe4e7ef1@erg.abdn.ac.uk> <98c8af7ffd471d6c353006c92c7deb3c28441557.camel@petri-meat.com> <0958b1c7-f4d2-ac7c-c127-b6fefef8f554@bobbriscoe.net> <18b86be43d62ea0a7dc55c760a50818dc68234ef.camel@petri-meat.com> <296c7a3b-15fc-5a30-efc0-cdc27a176db3@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:wxW+O65DmSF17fmFoRH2Em+oBvLIFGz18I17MPWjkruhAeS3Xdf yfD9Dbfrs5h/8S/k5jGVfHwOXZvgNwRYz/HxSf9IUxmcWNf6WK6xJDOUE7Eah/n3hyCJf9h RDuY061SumXJJSBIuELXuTI1jZ959h1/pHbReBslvpTbLgDkF2hN1SZ7NJwErE7ZxZEEZMS 8S8Isfl90Dn1izpe9MQ5w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:4oEDXbS/2kY=:qcX8StgxG0DGE6mYwpKz0P ed/T6GswvjIHkhmBf01sGd6Fs3Pbh8ohIRoLibVXzJB+P0haKn70c7bNwJbBzL4KKBPtNYOZ8 yRhnL2Oe3ti9UF4c70qrckP8wT+sZLRcZ4dHksDUNtSZcttrDP9whvIyTpRo+VMnrrDr//ir/ UFnESV47b+vjwHQff/4usx0dYB++9pUj/Lcp3kFiNoYTwJ0NDFk9EGvYUXvHe+AKoKHoouaDO /z6ERKU8rsqJeQiQA3+PPimmcpZ78HfEErKeplJA3xYAyNrMl3eEo3XFDl5TtxSuzxv2/Osdx BbtgbAmkqYWxJ136fz0Xt+BHDii2n5Wtpi/3foKrtwhjkztNvAGWDg7TeiQ/Ou39VERUJ0PPe cEiejTLSpvwsze71PwsVvSwpgjmCffes0HAdDvQjDY/F5pPeY/rqQs+OGEZEN0vR6EOOlsuXV iAptVmLRpF7uH1Qb+N2Uetxzf4lUTzhLCFU1WiLA3/i2Qei+zMSfLrvBlQNVSAu2Y2HHamYFw mEy9wJDeQLB4yu+0TPc7dwlkblAhJmo1q2I8AuKW4jRqRpW8UDCxXSWgrxIMGDK2f5Abg9Wja cies7wyexM63Ijetyhq13ZknkUut1vffSg9QmaRFzla4XJUC6IS6BmAv/5CnwupONt/7lO9VZ 0TRf4H+xzNzGz51TcXDoRoHt/cdna+O0as8IAi3OT874Oh8ykCuU/bn8xnUJR7sLkXMWkbNfM eIwMCkHIDaX90HCiofhmslzQKa2QN9JXwy7TwYge6RgVF4CDFKkiVUWpZ0U+4OkGPs0C+9jXB 5hZQnXv54zonx9Di+Td1rLPd3owcV+L1Qw6UnZhgeZFNjFo8FeTIQ+Q4M8JrAQhmC8RKDYjwS ueXwCr45NiEoJFwu02pOqLNp49vVmVj/nK7afNW8AoxKCJj+8TrY9I4T6a/7nbqytfTK+cSn3 Wf8VzvEneusl0rs1sjvqD47Q5vAWdEV8GsdEgY/TN/LFLj6IHhxw1SFQxvF7Olj9t73ZPeegq D4GN/hkyf0G8xJ1GsTHrMcTfYR8EPm6YB04kpkNEaTLWbwjghcsKYPSIGL9y1YSH2jdtxO6oY HaM5+DklfTqpdxnAkmRsy6KepTRnFi8r68thUzMvyIN70zwUOrtYlR9zYIV2wLqHECdljW5ku ZNgWsGOWYRBd8gp46/gla1iEjVDoYR8UqYa9YryDQoesqfa6YVyAKl7Jx4M1hDRfzy7cQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mnNLc-SRyHkWAF5ouptN4qxfHis>
Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 09:41:55 -0000

Hi Bob,


> On Mar 25, 2021, at 10:26, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Steven,
> 
> On 24/03/2021 23:12, Steven Blake wrote:
>> On Wed, 2021-03-24 at 22:50 +0000, Bob Briscoe wrote:
>>> Steven,
>>> 
>>> 
>>> On 23/03/2021 00:56, Steven Blake wrote:
>>>> Sec. 4 (Operator of a Network) of the draft presumes that deployed
>>>> equipment is capable to classifying packets specifically on ECT(1).
>>>> Have the authors confirmed that this feature is available on
>>>> commonly
>>>> deployed operator gear (e.g., IOS-XR, JUNOS)?
>>> [BB]
>>> (Aside: I think you're reading an old (-01) draft. That section has
>>> been
>>> Sec. 5. since draft-02 on 22 Feb 2021.
>>> See my response to the initial adoption call about the probable cause
>>> of
>>> this confusion - suspected problems with the IETF tools servers.
>>> )
>> Oops! You're right. s/Sec. 4/Sec. 5.
>> 
>> 
>>> To your point, I checked the manuals of one or two OSs of common
>>> makes
>>> of router before I proposed the WRED technique for addition to the
>>> draft. And I discussed the hardware capabilities with people within
>>> one
>>> or two router vendors. In the cases I checked, the CLI limits the
>>> flexibility that the admin has to define classifiers as general bit
>>> patterns. However the hardware underneath does have that flexibility.
>>> So
>>> this would require a CLI update for the routers I checked. The Linux
>>> classifier architecture does provide sufficient flexibility for such
>>> a
>>> classifier.
>>> 
>>> I also suggested the ECT(1) tunnel bypass technique, but I didn't
>>> exhaustively check the manuals of all the different types of tunnel
>>> (there are dozens).
>>> 
>>> I think this list of techniques is most useful for router
>>> developers,
>>> who can then find the easiest and most efficient one for their
>>> particular kit; whether they have to update the CLI, or whether they
>>> can
>>> find a way for their users to configure their unmodified systems in
>>> the
>>> field.
>> 
>> So operators that *don't wish to participate in L4S experiments* may
>> need to update *their* deployed software? Ask your favorite router
>> vendor how many customer-specific releases they are maintaining because
>> customers don't want to move forward once they get a working validated
>> release.
> 
> [BB] There is a common belief that, if any RFC3168 FIFO AQMs exist, they will be rare. But Jake and Jonathan raised the concern that it still needs to be possible to deploy RFC3168 routers from now onwards. In that case, operators that *don't wish to participate* would be updating their config, and l4sops then gives router developers ideas for how they might be able to prevent an existing implementation of RFC3168 from acting on ECT(1), given an ECN implementation is likely to be hard-coded against the ECN codepoints.


	[SM] This asks the question, how would an operator that is about to enable an rfc3168 AQM know that he better read and follow the L4S-ops ID/RFC? Are we expecting all operators to read and follow all RFCs meticulously all the time? 
	IMHO an operator intending on employing an rfc3168 AQM might read RFC3168 and RFCs referenced from there (which is IMHO already less likely), while an operator interested in L4S might read all of the L4S IDs/RFCs. But here we would need the rfc3168 deploying operators to read and follow an L4S ID/RFC...
	I guess adding an updated by to rfc3168 pointing to the L4S-ops RFC might offer a solution, but can/should a informational RFC update a PS document (honest question, I am just not sure about whether our process permits that)?

Best Regards
	Sebastian

P.S.: This is basically the same issue I have with the only mildly related NQB ID: in both contexts, we seem to expect parties genuinely not interested in the topic of the ID to act in a specific way to accommodate either the NQB or the L4S IDs/RFCs. And in both cases arguably bad things happen if those parties do not follow the recommendations.


> 
> 
> 
> Bob
> 
>> 
>> 
>> Regards,
>> 
>> // Steve
>> 
>> 
>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/