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

Mohammadpour Ehsan <> Mon, 22 March 2021 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 639C53A08BE for <>; Mon, 22 Mar 2021 08:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g_62M35cccBz for <>; Mon, 22 Mar 2021 08:33:48 -0700 (PDT)
Received: from ( [IPv6:2001:620:618:1e0:1:80b2:e058:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 082083A08C5 for <>; Mon, 22 Mar 2021 08:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=epfl; t=1616427222; h=From:To:CC:Date:Message-ID:Content-Type:MIME-Version; bh=3jbDC4wpPI1Qp3iaC+6IA4flyiUCuLgf5PUraIX65TI=; l=22932; b=Jxc4UYPvy1YJ2raAhx8ZhU+3/NbYE9lDsdlp9aOWeEmCzwa7N2ZMIrSm/fUfsWpmU CpzHzHZipVZBZ6z78QLPSXT90FWKl2l9rigdQaBFQYfXVTp392RJV93nxOz4Jh775 nI3vYp/Yd1zS0Owk0VOvk/lC2gISlqCP7B1F2QXBc=
Received: (qmail 23448 invoked by uid 107); 22 Mar 2021 15:33:42 -0000
Received: from (HELO ( (TLS, AES256-GCM-SHA384 cipher) by (AngelmatoPhylax SMTP proxy) with ESMTPS; Mon, 22 Mar 2021 16:33:42 +0100
X-EPFL-Auth: Meo08Wsu7Q1EAoj5BEpnCErAqt3LtafvkFC/dD8V0R64R0ygZDc=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 22 Mar 2021 16:33:42 +0100
Received: from ([fe80::8939:e5e2:d561:d768]) by ([fe80::8939:e5e2:d561:d768%4]) with mapi id 15.01.2106.013; Mon, 22 Mar 2021 16:33:42 +0100
From: Mohammadpour Ehsan <>
To: Lou Berger <>
CC: DetNet WG <>, "" <>
Thread-Topic: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02
Thread-Index: AQHW+8MLF9W102eQAk2Yhw/0iYu+aKpjNeAAgC0jTQA=
Date: Mon, 22 Mar 2021 15:33:42 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, fr-CH
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8608941FAD44409883DF416FBD2DFEA3epflch_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Mar 2021 15:33:54 -0000

Dear WG,

We submitted a new version of the Bounded Latency draft that addresses the comments received in the list (<>)3>); 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

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.


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<>

On 21 Feb 2021, at 23:15, Lou Berger <<>> wrote:


The WG last call is complete.


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!


On 2/5/2021 8:30 AM, Lou Berger wrote:

This starts working group last call on draft-ietf-detnet-bounded-latency-02

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
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:

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