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

Bob Briscoe <ietf@bobbriscoe.net> Thu, 25 March 2021 09:27 UTC

Return-Path: <ietf@bobbriscoe.net>
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 12B4C3A177A for <tsvwg@ietfa.amsl.com>; Thu, 25 Mar 2021 02:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 rCfwtr8vzuxU for <tsvwg@ietfa.amsl.com>; Thu, 25 Mar 2021 02:26:56 -0700 (PDT)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 603AC3A1779 for <tsvwg@ietf.org>; Thu, 25 Mar 2021 02:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sW9rZzfTVSwZ9cF7KFsaV6AN9Uk94KrYT1BM7KKx678=; b=zT5XH+0KYKLL0qTWKOiFqJcLow yHJThJwfG0TlMLhRUZ0JpE/ZyVo3XVgZBKzpu0ZPkp+ouw7BtrCO3UoWixVOvZHZcJd6+jsBwDlKL Pk5aLq5B4qhDn1X4bFaOqlBX2k/KDX/0cvNXmcNYtMm/nGF+QDr3VL7HInERBiuxrfTQ3G+nJIme5 p3dKkJjZmCex0XMHhUfJsWK6eBZN9JRNAekY0DZaKRBO5RLd1XNJglzRlOE6W5P15OPqrqqpU4ern hSVWScYJVir+72kq291L7wyfSCvLhodsOrq40Zbgu8XNRoAQBI018fLkViR7nv/M7khvDHLSjJvk6 dR8bGvQw==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:59072 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from <ietf@bobbriscoe.net>) id 1lPMGP-00080c-Nu; Thu, 25 Mar 2021 09:26:49 +0000
To: Steven Blake <slblake@petri-meat.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <296c7a3b-15fc-5a30-efc0-cdc27a176db3@bobbriscoe.net>
Date: Thu, 25 Mar 2021 09:26:48 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <18b86be43d62ea0a7dc55c760a50818dc68234ef.camel@petri-meat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CLmwmIa_DOz0BZSgOhNQ4SeYW-w>
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:27:01 -0000

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.



Bob

>
>
> Regards,
>
> // Steve
>
>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/