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

Sebastian Moeller <moeller0@gmx.de> Thu, 25 March 2021 11:45 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 594233A1EF4 for <tsvwg@ietfa.amsl.com>; Thu, 25 Mar 2021 04:45:59 -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 K0GTWGT9IFbB for <tsvwg@ietfa.amsl.com>; Thu, 25 Mar 2021 04:45:54 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 F18AF3A1ECB for <tsvwg@ietf.org>; Thu, 25 Mar 2021 04:45:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616672706; bh=jY2LsuyHKxmYe9Jd2HS3zZJhVrHkxAYDvGdDT0K4JNk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=gDFHQBnIrlXKFvZ+Z9qXBJhkxX0kAxoztQ/Fx01EjXXG2xnm6rDZIbEViaPm6YJ1X H7b5cL6sv40NCYSM9gx2NIbhwPVPyeDTJzt1etjntQl+jOixilmBmamx+1lDIj9BIh te7uOn3z2J37PnIhzzLPDC+DR+EsVb3w44KOCYI8=
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 1Mqb1W-1m34lu0qzQ-00mXjF; Thu, 25 Mar 2021 12:45:06 +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: <HE1PR0701MB229912A63BDCDB0333F7B7CCC2629@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Date: Thu, 25 Mar 2021 12:45:04 +0100
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <84343CA8-C428-4859-9DBC-5C7C717E25B3@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> <B5AA611B-93CB-49FE-A57B-8293B4E15650@gmx.de> <HE1PR0701MB229912A63BDCDB0333F7B7CCC2629@HE1PR0701MB2299.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:AsJ/vtWBb8uat2MPjKU7+uF2m3prH90tBBzkdueHtu/i8+uz4gC MRnkx3tMPMne/zQ7aX/urH86AoclNYIeRcw+TqY24GHlYHDcpME44IrykmNT7RXXIU717zS 4t+QvHViEBgfFj0i5+ROXsrlFtyB+D8W4r3f+EILN/2Ye7YSsX1hPHFAIz3TKnnyIf9koDp JDztw8kqLZYPzA6FOjViw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:gkbZcMG6n8I=:MWkSzJBxqj8kaI45qk2jwE 2oTdPwYVqc+ENX4gzSCCyISBwpe9WQlThEPu7w4wbcVDlPHGefS2s6oQbj8OSK3LKfOC6bwtY i/mYpoU8axsN9O8Fp32hcyvGk7hWPgoG0+Bj862y6GJoihEeVqvZHp1ntmjDLr8Dltw7eVz6X NPKlBt1lgBcrgOSpzkjBOj23ho1Kheaa7m/XgPOuLWpl9ibuNwnS7bMIa3/mgILAHOXQajMHQ cngbhOgYPsgFSucLlIBewKyp0wotk4vtGzbMTCMT5599gjCT1xiNlQVIwFz4ucWaRk/leyq3S X6Tm/qAT8UXDEjKFSlUXLsOxY27kkIh7fRw9A6iDbLbsEpYB7t4WvyFNQivxp0fxuQArmsjiv 4OOSJ8/zhWbbk8+BHldb3L+7hA3mZGEYGOTgqd4TD2YvAz/ofKlHBIn9SeKJTWLj84BWnDXn8 vrBwcjlTMvcp6TonbY//IqOv6bR6gRozzKl9WrNcetwXCsPt001MDNcP+LmzoUz3J3S80s1yE s7QZsUAehN1gHzWZnAhY321wE2+r8K/BwrqL4B8Ilw4x2z/a8MGi7V766crYx5qN4adsOq9qF 1OzCrE7LplKEMq0PXGhJp6lN6m75MKYJxFin4SPN+lFRW1ejE+qKSHi4shBugrokBS61nO9dB 8c1ISEkIAeaR3I7b8meYbfXAkft/qGDr9Wp21NJP7/mLsh1yf608YQ7+9ex54/yf72XyOEoRK f33RqvhT1gEHxP355sqcTW6IJ7ybyoWjF5l9nW5QeRvR+DFAvpyWr+8TA6li2mCmnADaZ8soB lUBORXhHBH3a92NPpodFfIYEZZSjm0HyKEj+e8zkEG+eGaUgeNpII8lMxiseLszYoIYodIAij Q0DXR7bLVS9HTf+ApX9F1+pNphtz0GPQId3CdRm3Tjymsj7c4X147yUexc8HAVJJXNZgo7Yb5 Q+Xv03hKebuRdsWWOJbyoexiRcXxOXOxoD/uW7dAVohIFIqEWDnO3s1XR5K6djuUgUKXqSohG vVZabL37okZvSo62p+pJl+1L5ctHtVYfvLAHupqTxlVYzhoDBXD7sd+0SFoaXJdfLc20d/4yD 2S/0AauVq5fYipIYWCCxgekbAA6urnGgLzJ2JfO/wcFHgbOZ3A6omVisxCPWgU7/TyfcdskHD wCwzOOyRyVY7zMpamb6gZgt4+1Z9BfSuKkgKy3rdGNyQEPiUh9UejKrN621edGgyIKH28=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ePSEpF1Brhlgp4dUWKLHsqb9qkA>
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 11:46:07 -0000

Hi Ingemar,

thanks for responding.

> On Mar 25, 2021, at 12:35, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> Sebastian.. 
> 
> Isn't the updated by RFC8311 sufficient in RFC3168 ?. It refers to L4S work,
> namely the L4S ID which targets experimental standards status.

	[SM] IMHO not really, rfc8311 has no big warning signs, that those experimental standards are allowed/expected to carry negative side-effects for rfc3168-compliant AQMs and operators of rfc3168 AQM need to employ specific steps to ensure safety/functionality of their AQM to accommodate such experimental standards traffic.
	I am not trying to start a discussion about whether doing that at all is a good idea, but how to make sure that information reaches the parties that would need to follow those instructions. IMHO the link to rfc8311 does not convey enough urgency for rfc3168 deployers to go digging deeper, but I might be just naive here, not being/working for an operator.

> Also, to me it sounds odd to add an 
> Updated by : [L4S Ops - Informational RFC] 
> to a proposed standard ? ,

	[SM] Same sentiment, that why I asked. The information though seems important. If rfc3168 deployers need to do something extra to guarantee their safety and functionality, because of changes somewhere else, I believe the party responsible for those changes (aka this WG) should make sure that even casual reads of rfc3168 know about the additional steps we expect them to take.

Best Regards
	Sebastian


> In any case it is the first time in RFC3168's
> history that it happens, unless I missed something. 
> 
> /Ingemar
> 
>> -----Original Message-----
>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Sebastian Moeller
>> Sent: den 25 mars 2021 10:40
>> To: Bob Briscoe <ietf@bobbriscoe.net>
>> Cc: tsvwg@ietf.org
>> Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to
> conclude
>> 24th March 2021
>> 
>> 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
>> https://protect2.fireeye.com/v1/url?k=532c5e52-0cb76757-532c1ec9-
>> 86d2114eab2f-53274140f9ce9692&q=1&e=8a9723d1-2c84-4bf6-b7d7-
>> b62af3457d9a&u=http%3A%2F%2Fbobbriscoe.net%2F
>