Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

Lou Berger <lberger@labn.net> Mon, 17 May 2021 17:54 UTC

Return-Path: <lberger@labn.net>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03533A4191; Mon, 17 May 2021 10:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=labn.onmicrosoft.com
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 q_5-dOm7-1il; Mon, 17 May 2021 10:54:26 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2112.outbound.protection.outlook.com [40.107.244.112]) (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 64E973A418D; Mon, 17 May 2021 10:54:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yb71eezFqAFnGzHWzG0c7ktVFSdGp87gzhoiQoyUw78YJsD3MzfaDMTXvSUAqT2V+IPbqvswgsAlzY90NqsfofGEq3WVJNljTackVfttTJrPLn528xoi7GitMdnXEs5OSZBX5KlFANyUYsJ/Fvmrgej3JThQlfT1l9B9z3QT6ghU3ArkYnXipATt/BgYtXFYCVQ6YdDNa8tXfL61grDvWHcaY4/M2SOPsDzKhEQuP7Q1x+rxjhXKbDhgV5wZFjanVX0zg1+pnb8uxsCe6fN+/89hR0ravtasHT/WCa3lZ+A1opVSMjocbGRbmReVFlTf8+lBK+/uqFne0Iks8XSBFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gje6R+cvaF3dLJMN7MJRkNDRJnlqKOtMBC1gfsBNx2U=; b=XpwSU1tnFWCn4MlcmWqYBBidFZEakhgAdAoc5i4UZbuzLd0fa6VIyrS6Uc9LrI7mN+u7ioPdu5Hmd1Nhk9xGis5FvhejoqKXYQoDgpjihMqyBP17zCZ8l6wnbewHCqfRXGwUHxPj/VkfNIFJWwB0bcGVQ/keU23C3itVUyVqhUSo/7hkN2Ly/M+b7Z1H2tS8f0RrJmGP9f/7ODh6/gKbTqyrpGbT2Ckg8o1gU7raiAA2+CQJMgfdneUZINs7SOKaisBiKllCnDqUH87NdyX44WFH0TS8vreyno4CSrU44h7NYwMN9ZNQ223NPjOiwWh1MtuhDDE5nKLMr6JwAkviyA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gje6R+cvaF3dLJMN7MJRkNDRJnlqKOtMBC1gfsBNx2U=; b=a3bi6pCKw/fXP7yXG+SxGJTsMYBKdZV/XlMJZcHV2wvEeBjO8v5uYkPHt58VbL4JmDFEVUxFqfEN5ySu48Nx0m39glm45ESvEnqexP1wcMJx1FFO61fCdj3ivOImUG3x0vKIZpo0+Se2uyqAZveBSxGoxRhJ5Z5U4YuJ0SLYehY=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=labn.net;
Received: from BL0PR14MB3779.namprd14.prod.outlook.com (2603:10b6:208:1c7::24) by MN2PR14MB3310.namprd14.prod.outlook.com (2603:10b6:208:1ac::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25; Mon, 17 May 2021 17:54:22 +0000
Received: from BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::109d:d2c6:1779:3c33]) by BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::109d:d2c6:1779:3c33%7]) with mapi id 15.20.4129.031; Mon, 17 May 2021 17:54:22 +0000
To: Mohammadpour Ehsan <ehsan.mohammadpour@epfl.ch>
Cc: "draft-ietf-detnet-bounded-latency@ietf.org" <draft-ietf-detnet-bounded-latency@ietf.org>, DetNet WG <detnet@ietf.org>
References: <d38af2a0-843f-e117-3368-570f4e26c105@labn.net> <371c2363-4f15-b32f-4c96-483a31ae1c77@labn.net> <8608941F-AD44-4098-83DF-416FBD2DFEA3@epfl.ch> <ba5a97d2-47ce-3a54-c754-d7007b164bea@labn.net> <6D2EFDE8-452C-40C7-B4AF-5300B995FE2B@epfl.ch> <20210407231904.GA32233@faui48f.informatik.uni-erlangen.de> <3252bf68-5069-9919-0d4f-1031740575fa@labn.net> <081D0327-E69F-4ECE-A367-50B22042316A@epfl.ch> <7C5FBD62-00D3-4F62-89D3-BCBF04CB95F1@epfl.ch> <638586a6-ff29-4b49-c8dc-000f0c864040@labn.net> <B74F67AC-2249-4D7E-BF42-14483C7C5256@epfl.ch>
From: Lou Berger <lberger@labn.net>
Message-ID: <d6c2b20a-b739-f815-77e9-272130827cc2@labn.net>
Date: Mon, 17 May 2021 13:54:17 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
In-Reply-To: <B74F67AC-2249-4D7E-BF42-14483C7C5256@epfl.ch>
Content-Type: multipart/alternative; boundary="------------6B9914E0C780F3733D9D0EE0"
Content-Language: en-US
X-Originating-IP: [100.15.108.238]
X-ClientProxiedBy: BL0PR03CA0035.namprd03.prod.outlook.com (2603:10b6:208:2d::48) To BL0PR14MB3779.namprd14.prod.outlook.com (2603:10b6:208:1c7::24)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [127.0.0.1] (100.15.108.238) by BL0PR03CA0035.namprd03.prod.outlook.com (2603:10b6:208:2d::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Mon, 17 May 2021 17:54:22 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 38f3d312-193b-4cfd-4c76-08d9195ccd4b
X-MS-TrafficTypeDiagnostic: MN2PR14MB3310:
X-Microsoft-Antispam-PRVS: <MN2PR14MB3310E5F3ECE83339B320E36DC32D9@MN2PR14MB3310.namprd14.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: mt488/JIahn4yyZWPVF3f+dtru0gVMd60irZugrg0mdJoWon0aY8pZO10gY4uW5Gj8Dw5UAbLY4OrPvpAYNRReta02GfVpfcL6pSk2Hbp/kJH0O75B3VvU046WdITPySCjneqpD93OAKZRKveBwcBjNJq3+JzdzDkm4rXDc7r1P9clDiUK7q5hFLcp4zS8BdvGWL3LxTpWhysVygk1D/uA1+exQpLzU+INrlgNysbtqUUQrjU00rsrp+jDeB95sZOTGrLkLQOFGzhOC5ru6/20CmaM4yWiXN15+nhBUmjXPMvWeMlZUkDfFl+a+ZrTgrLG2vqxTSkvaBVRlGWHXZJ6ZBpIFG3+yMeRYIBbpQWcavno/lDzhAqgmjCXGzRm5BCE538licvZM2dESHClkNHAeJtSGctVjgCuZ1EZFwYi1vmpSNMzoMEaLDxurjhrLwWicSaH+j+c9IwzYsceoGaowV/jXjQcfm+BoCvWMlWT4kTquv4A/QKXvz8SoM0cKVdcU1nMLcDAwjWreWSX/gttMUmK/xnRjRdVpxCc6KQZzd+vMHY4XKvLuQ8dMywp9smuqe32vvywg3HNRdHlVBVDKhKxgHIc12kWbmIIcf7S3YoVxEEPCm8DuxqNGp/xWVVuhVzhe/pN1TbiT4UxEl+/aAMLo2A40TNNneCoyZ5AjSBBjGVDaeJDwutXwZNrXK1X0P2weRPfwb4xAECfg33Xzf3JIc4/Gov8BRXtRzms5rcfut7wN3iolQFDlbWdiW5UwqbQc5Xz2isGgZVR4qS6ablOztr81vxiEvQ6dYXrc=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR14MB3779.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(39830400003)(346002)(136003)(396003)(16576012)(316002)(54906003)(38350700002)(30864003)(38100700002)(5660300002)(4326008)(53546011)(66556008)(478600001)(66946007)(8676002)(86362001)(16526019)(7246003)(956004)(4001150100001)(8936002)(31696002)(52116002)(186003)(966005)(31686004)(166002)(36756003)(6666004)(66476007)(7126003)(6916009)(2616005)(2906002)(83380400001)(6486002)(26005)(45640500001)(45980500001)(43740500002)(579004)(559001); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?SeZIZrToSnui09uV5SmC8QDuJFP0FnopfT8tZWpHK1BtMPdfi9oLCPad?= =?Windows-1252?Q?wDY6KvT+ucKJ4RQc65oldy8i3BArBjNweyZ3iunNfi5BGmeogs1bfTrv?= =?Windows-1252?Q?+ogGSfqW/zyLdT97eQqzmnIv+U+yot0aZzNmu4qvnAJ9Bdx2pIGaUaKd?= =?Windows-1252?Q?KG7yekAEsUcF0Dh7MZDvwVoBUdHWkcN7ks7UhdxHDZcBU3LM9JwWOdei?= =?Windows-1252?Q?iBHokckV27+PiGxUYbX/Dx2GlUsEbKS9w1hRvpHJGQSIO6geyNAWZ7H0?= =?Windows-1252?Q?p71FxBgZQyiB/Uuk80aRY8/tsngnJkiRgCMwjV4jEhIcyGGMJF7LHTUC?= =?Windows-1252?Q?FYIkNCsKThsu/+VFimpyLA1vEYrnKqqLV9HlCcyP5wkfl8D5n27/CQDd?= =?Windows-1252?Q?GfebnSi8QlpBWg+fRKO6mMna854fszIVLyHmo6NgjVMCjEABZiZfVsh3?= =?Windows-1252?Q?XlbLgSGX/9sKoqxs9mLOA82nE0oH/VB0JvG9bS2/jG07W29B9gijcqnS?= =?Windows-1252?Q?X2cgBDoaWzW4UjXTtk4S8Jcohv2tHK2FasvPZreDWndctm9p8qjcoS3F?= =?Windows-1252?Q?4/GI25jNZwkXpCN0XWhkdhj2+apYPsdaWeZboBK0/DW7kZqe3TwA6xlX?= =?Windows-1252?Q?1yP/mFspgDXXPIoqQYc2zroF8WgV+n6SjOoA72hArHnLH55e8Bn8JUKw?= =?Windows-1252?Q?deZhlzbOrKu5cOUGER+9tekFieuX/7amQ+7h+14MgPB7WR6uiILz3d2s?= =?Windows-1252?Q?HiW75k18lUIqzY0cqgx53+7dBzJBKJ+R+g+YLCI93wyEYS+oe5wQryX7?= =?Windows-1252?Q?mvw70vZ0TY6os7uVuSh1LR2OYgObGVTAO8p0mIMg7gmHrM5HYdRisFBe?= =?Windows-1252?Q?byHR9mezq/xhXa0lbwo450jqhfsJ+GNCOQI836ltxhOGENnUqQZ8GIck?= =?Windows-1252?Q?ShpEDOdXVrXbJ/0XBGdiCfG3l6M+t+e0IJeTs1YBJkuTgJAT8NZU+Pkk?= =?Windows-1252?Q?aQHKchsQwymqdY/ByuUYM9nsPO5GRBDSavkE7vDMr5CVfJyZS4Z3yDRP?= =?Windows-1252?Q?yqEk9J/zzWYYJMfBb1YUoDvdpjwhOpyMDSzen1FuGviNUp87jAfHE5UU?= =?Windows-1252?Q?aY/9KCsHPrunamXRJlgZDUAq5tXYb/kb4lNFOlewiv+uJ+gaGUXb0evf?= =?Windows-1252?Q?48GJN/LwXA0TdIVe7pJHsL+j3fj1mih2piodW0J5+NWVeEydcbX/AUs5?= =?Windows-1252?Q?UY/sZJ1s/0NuPSzVSkHINoPhNTAlpMnKxfkOHLTRrghygowV3g4aESVZ?= =?Windows-1252?Q?qhWxL+AmBKJufN8TUxP9qeqnzbv8ND71z3zyBFxhRVevYhz+GUOj2TO1?= =?Windows-1252?Q?qIrlgJYDl4jMyqOKGm0wZHHUQV/axZqCSlmNAd6JYV7zZ7QFiB/LgNVm?=
X-OriginatorOrg: labn.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 38f3d312-193b-4cfd-4c76-08d9195ccd4b
X-MS-Exchange-CrossTenant-AuthSource: BL0PR14MB3779.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2021 17:54:22.3477 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: eb60ac54-2184-4344-9b60-40c8b2b72561
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hKpc4IXKNmgTo38155w4fUC4s8D2jRVjqEKLbejpk1relquXGmgDXojKMfio+st5HN+EbKBDwwl37/5aFAroXA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3310
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/YQW54GKjXkMcZq53Gj6BpxykNgQ>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2021 17:54:32 -0000

Ehsan

Thanks for the quick turnaround!  The document has been submitted to the 
IESG.

Lou

On 5/17/2021 6:38 AM, Mohammadpour Ehsan wrote:
> Hello Lou,
>
> Thanks for the precise review; I updated the draft accordingly. You 
> can find the new version here: 
> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-06 
> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-06>.
>
>
> Best,
> Ehsan
>
>
>
> --
> Ehsan Mohammadpour
> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
> EPFL EDIC PhD student representative
> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
> https://people.epfl.ch/ehsan.mohammadpour 
> <https://people.epfl.ch/ehsan.mohammadpour>
>
>> On 15 May 2021, at 20:01, Lou Berger <lberger@labn.net 
>> <mailto:lberger@labn.net>> wrote:
>>
>> Hi Ehsan,
>>
>> Sorry about the delay.  I still see one problematic line in the new text:
>>
>>    Then,
>>    the input flows are identified using the information in (Section 5.1
>>    of [RFC8939]).  Then they are aggregated into eight macro flows based
>>    on their traffic classes.
>>
>> The term traffic classes still doesn't map well into RFC8939.  I 
>> think you mean
>>
>>    Then they are aggregated into eight macro flows based
>>    on their service requirements.
>>
>> It would be best to have this change made prior to submission for 
>> publication to the IESG. Please let me know what you think.
>>
>> Thanks,
>>
>> Lou
>>
>> On 5/10/2021 8:37 AM, Mohammadpour Ehsan wrote:
>>
>>> Dear WG chairs,
>>>
>>> Since the comments have been addressed, I was wondering if we can 
>>> proceed to the publication request.
>>>
>>>
>>> Best,
>>> Ehsan
>>>
>>>
>>>
>>>> On 19 Apr 2021, at 03:50, Mohammadpour Ehsan 
>>>> <ehsan.mohammadpour@epfl.ch 
>>>> <mailto:ehsan.mohammadpour@epfl.ch><mailto:ehsan.mohammadpour@epfl.ch 
>>>> <mailto:ehsan.mohammadpour@epfl.ch>>> wrote:
>>>>
>>>> Dear WG,
>>>>
>>>> A new version of Bounded Latency draft is uploaded 
>>>> (https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05 
>>>> <https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05><https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05 
>>>> <https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05>>). 
>>>> This version addresses all the raised comments, including the 
>>>> latest ones by Lou and Toerless.
>>>>
>>>>
>>>> Best,
>>>> Ehsan
>>>>
>>>>
>>>>
>>>> --
>>>> Ehsan Mohammadpour
>>>> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
>>>> EPFL EDIC PhD student representative
>>>> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
>>>> https://people.epfl.ch/ehsan.mohammadpour 
>>>> <https://people.epfl.ch/ehsan.mohammadpour><https://people.epfl.ch/ehsan.mohammadpour 
>>>> <https://people.epfl.ch/ehsan.mohammadpour>>
>>>>
>>>>> On 9 Apr 2021, at 14:19, Lou Berger <lberger@labn.net 
>>>>> <mailto:lberger@labn.net><mailto:lberger@labn.net 
>>>>> <mailto:lberger@labn.net>>> wrote:
>>>>>
>>>>> Eshan,
>>>>>
>>>>>     Please let the WG know when you have addressed all previous 
>>>>> raised (and discussed items) and have uploaded the new version. 
>>>>> This will unblock the publication request.
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Lou
>>>>>
>>>>> On 4/7/2021 7:19 PM, Toerless Eckert wrote:
>>>>>> Ehsan, *:
>>>>>>
>>>>>> Thanks a lot for Section 7 in the latest draft version. Helps a 
>>>>>> lot to get
>>>>>> the linkage between this doc and the DetNet architecure an QoS 
>>>>>> options.
>>>>>>
>>>>>> Alas, i do not see the concerns i raised with the authors about 
>>>>>> section 6.5 solved
>>>>>> that i send before IEF 110 in email. If you can't find that 
>>>>>> email, i can post it
>>>>>> again. Its solely about the fact that the document uses "IntServ" 
>>>>>> where it
>>>>>> should say (IntServ) "Guaranteed Service", because the second 
>>>>>> "IntServ" Service,
>>>>>> "Controlled Load" does not provide any determinisic latency 
>>>>>> guarantees (only GS does),
>>>>>> and therefore the unconstrained use of "IntServ" and not 
>>>>>> mentioning of "Guaranteed Services"
>>>>>> will be confusing to anyone who digs deeper into the IETF 
>>>>>> terminology (the refernce to rfc2212 is correct though).
>>>>>>
>>>>>> I think also tha he formulas in rfc2211 are more complex than 
>>>>>> what you write in 6.5,
>>>>>> i do like he simplification of 6.5, but it might be worth noting 
>>>>>> explicitly
>>>>>> hat those are implifications. specifically there are a bunch more 
>>>>>> parameters in
>>>>>> TSPEC/RSPEC than whats written in 6.5, and those parameters have 
>>>>>> impact on the
>>>>>> bounded latency in GS.
>>>>>>
>>>>>> Cheers
>>>>>>     Toerless
>>>>>>
>>>>>> On Thu, Mar 25, 2021 at 07:56:01AM +0000, Mohammadpour Ehsan wrote:
>>>>>>> Hello Lou,
>>>>>>>
>>>>>>> Thanks for the comment, you???re right! I will use the following 
>>>>>>> sentence:
>>>>>>>
>>>>>>> "Then they are aggregated into eight macro flows based on their 
>>>>>>> DetNet flow aggregate."
>>>>>>>
>>>>>>> Best,
>>>>>>> Ehsan
>>>>>>>
>>>>>>>
>>>>>>> P.S. The intention of "Then, the input flows are identified 
>>>>>>> using the information in (Section 5.1 of [RFC8939])???, was to 
>>>>>>> say that we use Section 5.1 of RFC8939 to identify the 
>>>>>>> individual DetNet flows.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ehsan Mohammadpour
>>>>>>> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
>>>>>>> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
>>>>>>> https://people.epfl.ch/ehsan.mohammadpour<https://people.epfl.ch/ehsan.mohammadpour?lang=en> 
>>>>>>> <https://people.epfl.ch/ehsan.mohammadpour%3Chttps://people.epfl.ch/ehsan.mohammadpour?lang=en%3E><https://people.epfl.ch/ehsan.mohammadpour%3Chttps://people.epfl.ch/ehsan.mohammadpour?lang=en%3E 
>>>>>>> <https://people.epfl.ch/ehsan.mohammadpour%3Chttps://people.epfl.ch/ehsan.mohammadpour?lang=en%3E>>
>>>>>>>
>>>>>>> On 22 Mar 2021, at 16:56, Lou Berger <lberger@labn.net 
>>>>>>> <mailto:lberger@labn.net><mailto:lberger@labn.net 
>>>>>>> <mailto:lberger@labn.net>><mailto:lberger@labn.net 
>>>>>>> <mailto:lberger@labn.net><mailto:lberger@labn.net 
>>>>>>> <mailto:lberger@labn.net>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Ehsan
>>>>>>>
>>>>>>> Thank you for the update.  I did a quick skim and it looks much 
>>>>>>> improved.  I found one bit of new language confusing:
>>>>>>>
>>>>>>>    Section 6.4
>>>>>>>
>>>>>>>    In the considered queuing model, we considered the four traffic
>>>>>>>    classes (Definition 3.268 of [IEEE8021Q]): control-data traffic
>>>>>>>    (CDT), class A, class B, and best effort (BE) in decreasing 
>>>>>>> order of
>>>>>>>    priority.  Flows of classes A and B are together referred as AVB
>>>>>>>    flows.  This model is a subset of Time-Sensitive Networking as
>>>>>>>    described next.
>>>>>>>
>>>>>>>    ....
>>>>>>>
>>>>>>>    Then,
>>>>>>>    the input flows are identified using the information in 
>>>>>>> (Section 5.1
>>>>>>>    of [RFC8939]).  Then they are aggregated into eight macro 
>>>>>>> flows based
>>>>>>>    on their traffic classes.  We refer to each macro flow as a 
>>>>>>> class.
>>>>>>>
>>>>>>> So in the first paragraph, you say "traffic classes" is defined 
>>>>>>> by 802.1Q.  in the second, you say "their traffic classes" is 
>>>>>>> defined based on [RFC8939].  I believe these are inconsistent 
>>>>>>> definitions.  I think you are trying to say that
>>>>>>>
>>>>>>>     Then they are aggregated into eight macro flows based on 
>>>>>>> their *DetNet flow aggregate.*
>>>>>>>
>>>>>>> This is assuming that the node isn't doing some sort of 
>>>>>>> independent mapping of micro-flows to macro-flows.
>>>>>>>
>>>>>>> Please let me know if I'm missing something.
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>> On 3/22/2021 11:33 AM, Mohammadpour Ehsan wrote:
>>>>>>>
>>>>>>> Dear WG,
>>>>>>>
>>>>>>> We submitted a new version of the Bounded Latency draft that 
>>>>>>> addresses the comments received in the list 
>>>>>>> (https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04<https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03> 
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04%3Chttps://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03%3E><https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04<https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03> 
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04%3Chttps://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03%3E>>); 
>>>>>>> it is now ready for submission to the IESG for publication.
>>>>>>>
>>>>>>> Thanks Lou for his comments. In the new version, we address the 
>>>>>>> comments as follows:
>>>>>>>
>>>>>>> - Abstract
>>>>>>> I think the abstract should to be updated to match the current 
>>>>>>> content of the document. I suggest just copying the 4th and 5th 
>>>>>>> paragraphs from the Introduction section.
>>>>>>>
>>>>>>>
>>>>>>> Thanks for the suggestion. The new version is updated accordingly.
>>>>>>>
>>>>>>> - general comment: classes of (DetNet) Service
>>>>>>>
>>>>>>> The document states that it uses terminology from RFC8655, it 
>>>>>>> also uses the terms "Classes of DetNet Service", " DetNet 
>>>>>>> Classes of Service"  and other similar forms of these terms. 
>>>>>>>  RFC8655 uses this term in one place " Class-of-Service schemes 
>>>>>>> (e.g., DiffServ)" and also mentions "classes of DetNet flows" 
>>>>>>>  in two places.  The data plane documents [RFC8964] and 
>>>>>>> [RFC8934] also describe Class of Service in the context of 
>>>>>>> DiffServ (and not DetNet).
>>>>>>>
>>>>>>> In reading the document it seems that it is not using CoS in the 
>>>>>>> typical way used in the IETF  or the other DetNet RFCs, and is 
>>>>>>> introducing a new definition for CoS.   II think having a 
>>>>>>> document specific definition of CoS probably isn't helpful. It 
>>>>>>> would be best to use existing DetNet terminology.  I suspect 
>>>>>>>  "flow aggregate" is the closest, but perhaps I'm missing something.
>>>>>>>
>>>>>>>
>>>>>>> Thanks for your comment. In the new version, we used the term 
>>>>>>> ???aggregate??? instead of class in section 3.1 and classes of 
>>>>>>> DetNet flows. Section 6.4 uses the term ???traffic class??? as 
>>>>>>> in IEEE802.1Q.
>>>>>>>
>>>>>>> - alignment with the Data Plane RFCs
>>>>>>>
>>>>>>> The lists in section 3.1 and in section 6.4 are not well aligned 
>>>>>>> with the Data plane documents.  These sections should be aligned 
>>>>>>> with the provisioning of IP flows, as summarized in Section  6 
>>>>>>> of RFC8939, and MPLS as summarized in Section 5 of RFC8964.
>>>>>>>
>>>>>>> Thanks for your comment. Section 3.1 is about flow admission 
>>>>>>> paradigm and not "flow creation???. The title is changed to 
>>>>>>> ???flow admission??? to avoid possible confusion. In fact, this 
>>>>>>> section is aligned with the DataPlane RFCs and in parallel with 
>>>>>>> provisioning of IP flows. We modified section 6.4 to follow the 
>>>>>>> Data plane documents.
>>>>>>>
>>>>>>>
>>>>>>> - minor comment service vs frame preemption
>>>>>>>
>>>>>>> Section 3.1 uses the term "un-provisioning", I read the text as 
>>>>>>> meaning "service preemption".
>>>>>>>
>>>>>>> In the rest of the document preemption refers to "frame 
>>>>>>> preemption" and this should be clarified.
>>>>>>>
>>>>>>> Thanks for the suggestion. In the new version, we use the term 
>>>>>>> ???service preemption??? and update the term ???preemption??? to 
>>>>>>> ???frame preemption???.
>>>>>>>
>>>>>>>
>>>>>>> - id nits, please ensure the document passes idnits without 
>>>>>>> errors, see
>>>>>>>
>>>>>>> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt 
>>>>>>> <https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt><https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt 
>>>>>>> <https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt>>
>>>>>>>
>>>>>>> Thanks for your comment about idnits. We added the missing 
>>>>>>> sections, i.e., ???security considerations??? and ???IANA 
>>>>>>> considerations??? to the draft. Also resolved other comments by 
>>>>>>> idnits.
>>>>>>>
>>>>>>> Best,
>>>>>>> Ehsan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ehsan Mohammadpour
>>>>>>> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
>>>>>>> EPFL EDIC PhD student representative
>>>>>>> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
>>>>>>> https://people.epfl.ch/ehsan.mohammadpour<https://people.epfl.ch/ehsan.mohammadpour?lang=en> 
>>>>>>> <https://people.epfl.ch/ehsan.mohammadpour<https://people.epfl.ch/ehsan.mohammadpour?lang=en>>
>>>>>>>
>>>>>>>
>>>>>>> On 21 Feb 2021, at 23:15, Lou Berger 
>>>>>>> <lberger@labn.net<mailto:lberger@labn.net>> wrote:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> The WG last call is complete.
>>>>>>>
>>>>>>> Authors,
>>>>>>>
>>>>>>> Please bring any resolutions to comments received to the list. 
>>>>>>> Once all comments are addressed please update the draft and let 
>>>>>>> the WG know that it is ready for submission to the IESG for 
>>>>>>> publications.
>>>>>>>
>>>>>>> Thank you!
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>> On 2/5/2021 8:30 AM, Lou Berger wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> This starts working group last call on 
>>>>>>> draft-ietf-detnet-bounded-latency-02
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/
>>>>>>>
>>>>>>> The working group last call ends on February 19th.
>>>>>>> Please send your comments to the working group mailing list.
>>>>>>>
>>>>>>> Please note, there was an IPR disclosure against this document
>>>>>>> submitted on January 14, 2021, see 
>>>>>>> https://datatracker.ietf.org/ipr/4581/
>>>>>>> While this disclosure came very late in the document life cycle,
>>>>>>> it appears the filing was also relatively recent (2019-10-16) and
>>>>>>> after the pre adoption IP call:
>>>>>>> https://mailarchive.ietf.org/arch/msg/detnet/1mwYdadDzTLudcuH5T5O7R_KlDs
>>>>>>>
>>>>>>> Positive comments, e.g., "I've reviewed this document
>>>>>>> and believe it is ready for publication", are welcome!
>>>>>>> This is useful and important, even from authors.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Lou (DetNet Co-Chair & doc Shepherd)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> detnet mailing list
>>>>>>> detnet@ietf.org<mailto:detnet@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> detnet mailing list
>>>>>>> detnet@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> detnet mailing list
>>> detnet@ietf.org <mailto:detnet@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/detnet 
>>> <https://www.ietf.org/mailman/listinfo/detnet>
>