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

From: Lou Berger <[email-masked]>
Date: Fri, 5 Feb 2021 08:30:00 -0500

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)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 5 Feb 2021 10:30:32 -0500

This is one of the more important products of this WG and IMHO is ready for
publication.

Cheers,
Andy

On Fri, Feb 5, 2021 at 8:30 AM Lou Berger <[email-masked]> wrote:

> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: Jean-Yves Le Boudec <[email-masked]>
Date: Mon, 8 Feb 2021 11:52:08 +0100

Dear all

as co-author  I may be biased, but I do believe that this document 
contains essential information for detnets and is now ready for publication.

Best, JY

---

From: "Ethan Grossman" <[email-masked]>
Date: Tue, 9 Feb 2021 13:18:35 -0800

I have watched the evolution of this draft and I find it to be a very
important contribution to DetNet. It appears to be very close to
publication-ready, although I can't vouch for the technical details. 

Typos: I think there are two typos in this sentence: 
  In the cosidered queuing model, there are four types of flows,
   namely, 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 to AVB flows.
1) cosidered s/b considered
2) "referred to AVB flows" s/b "referred to as AVB flows" (right? If not,
please somehow clarify, e.g. if "referred" has a different meaning) 

Thanks to Jean-Yves, Norm, and the other authors for this draft. 
Ethan.

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Lou Berger
Sent: Friday, February 5, 2021 5:30 AM
To: DetNet WG <[email-masked]>
Subject: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

All,

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,

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 12 Feb 2021 12:58:08 -0800

Dear All,
I've read the current version of the draft and support progressing it to
the publication as the Informational RFC.
I have several non-blocking comments and questions for the author's
consideration:

   - In Abstract and Introduction "server" and "central server" referenced.
   Could it be used to identify an SDN controller or orchestrator? If that is
   the case or close, perhaps a more direct terminology can be used.
   - Perhaps s/un-provisioning/de-provisioning/?
   - It's been quite a long time since I've seen a network device being
   referenced as "bridge". If there's no difference modeling different types
   of networking devices in Section 3.2, perhaps "typically, bridges or
   routers" can be omitted.
   - And in the same sentence, a part of the reference model is described
   as "a wired link". Could that be some other media, e.g., wireless?
   - you may choose to use a single term from "DetNet unaware", "DetNet
   non-aware", and "non-DetNet"
   - the statement in the second paragraph's  first sentence appears very
   assertive:

   In general, when passing through a non-DetNet island, the island
   causes delay variation in excess of what would be caused by DetNet
   nodes.

I agree that under some conditions such a domain might cause higher delay
variation but I am not sure that is always the case.

   - Further in that paragraph, is stated that "... can still be calculated
   and met if and only if the following are true" though the second bullet
   appears as a conditional "An ingress conditioning function (Section 4.3)
   may be required ...". I am not sure it is clear when that second bullet is
   true - if the conditioning function is required or if it is not needed.

Regards,
Greg

---

From: Lou Berger <[email-masked]>
Date: Sun, 21 Feb 2021 16:59:25 -0500

Hi,

I have some comments as part of my shepherd review.  The comments 
largely relate to clarifying terminology and alignment with the existing 
DetNet RFCs, and the substance of most of the document -- so hopefully 
won't be too difficult to address.

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

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

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

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

- 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

That's it,

Lou

---

From: Lou Berger <[email-masked]>
Date: Sun, 21 Feb 2021 17:15:38 -0500

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Feb 2021 20:00:35 +0100

Mea maxima culpa for missing tihs deadline, but will be happy to resubmit when it comes back to IETF
review, otherwise feel free to alreay read now and consider my input:

Very nice document overall. Due to time i'll have to postpone some more knucklehead text
details to IETF review time slot.

The one very high level comment i have is that i am missing any linkage between this
document and where in the DetNet forwarding plane to apply bounded latency control.

I also looked through the architecture and could not find anything. Likewise MPLS and
IP RFCs. Aka: nowhere in the documents can i find something saying "this is a
DetNet forwarding function where bounded-latency control is to be applied".

I am not even sure if the WG knows or agrees where that would be. Without any such tie-in,
the claims of the architecture that bounded latency is provided for by DetNet
seems like an undelivered promise. and readers of our documents would likely become
very frustrated trying to figure this out because this gap is not even explicitly acknowledged.

For example, i imagine that the most simple instance of applying bounded latency
to detnet would be a DetNet MPLS deployment, where every MPLS forwarder is a
DetNet service-node? (if that is he right word), the S-Label is label switched,
hence allowing for the forwarder to have DetNet Flow awareness and tie the appropriately
selected per-flow bounded latency operations to packets of the flow.

Of course, i would have hoped to find such text in the forwarding or architecture
RFCs, but without anything so explicit thre, why not add such a simple example
to codify this tie in between he concepts presented in this draft and the 
DetNet fowarding plane.

If there are no explicit examples for the most simple detnet forwarding functions
and where/how to apply bounded latency to it, then i think that too should be
explicitly written into this document to set expectations straight.

Cheers
    Toerless

On Sun, Feb 21, 2021 at 05:15:38PM -0500, Lou Berger wrote:
> 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
> 

-- 
---
[email-masked]