From nobody Thu Mar 25 02:41:56 2021 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: <296c7a3b-15fc-5a30-efc0-cdc27a176db3@bobbriscoe.net> Date: Thu, 25 Mar 2021 10:40:13 +0100 Cc: Steven Blake , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <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 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 09:41:55 -0000 Hi Bob, > On Mar 25, 2021, at 10:26, Bob Briscoe wrote: >=20 > Steven, >=20 > On 24/03/2021 23:12, Steven Blake wrote: >> On Wed, 2021-03-24 at 22:50 +0000, Bob Briscoe wrote: >>> Steven, >>>=20 >>>=20 >>> 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. >>=20 >>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> 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. >>=20 >> 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. >=20 > [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?=20 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. >=20 >=20 >=20 > Bob >=20 >>=20 >>=20 >> Regards, >>=20 >> // Steve >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/