[Detnet] Suresh Krishnan's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT)

[Suresh Krishnan <[e-mail]>]

Suresh Krishnan has entered the following ballot position for
draft-ietf-detnet-architecture-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 3.2.1.1.

Given that we also know some of the downsides as well of large buffers, I think
a pointer to some background might be warranted here. I would recommend a basic
reference to something like

Bufferbloat: Dark Buffers in the Internet, Communications of the ACM, January
2012,

* Section 3.2.2.2.

It is not obvious to me how the POF cannot be the last operation at the
receiver. Can you clarify? Also, do intermediate nodes apply the POF? I can see
the need for them to do PRF and PEFs but I am not sure applying the POF at
intermediate nodes can necessarily help the low latency and low jitter goals.

   The order in which a DetNet node applies PEF, POF, and PRF to a
   DetNet flow is implementation specific.

* Section 3.2.3.

RFC7426 does not contain much specific information about explicit route setup.
Is there a particular section you want to point to. If not, I don't think this
reference is of much use. RFC8453 is listed twice.

* Section 3.3.1.

Not sure why this is a requirement but I do wish to note that there are no such
worst-case latency guarantees for best effort traffic (aka non-Detnet) in
current networks. Can you clarify?

   o  DetNet flows can be shaped or scheduled, in order to ensure that
      the highest-priority non-DetNet packet is also ensured a worst-
      case latency.

* Section 4.1.1.

This text "Peers with Duplicate elimination." seems to be completely out of
place under the "Packet sequencing" heading below Figure 2. Copy and paste
error?

* Section 4.3.2.

I found the expression "number of bit times" confusing. I have understood "bit
time" to mean the amount of time taken to emit a bit from a network interface.
Based on that definition, this expression does not make sense. Is there a
better reference/definition of what you mean?

* Section 4.5.

There might be some other recent IETF defined mechanisms that might be relevant
to mention here as well. e.g. RFC8289 (Codel), RFC8033 (PIE) etc.

* Section 4.7.2.

While IPv6 does offer a mechanism to add/remove a flow id (flow label) not sure
what kind of mapping you were thinking for IPv4. If this is not possible, I
think a note to that effect might be useful here.

* Sections 5 and 6

I also support Alissa and Benjamin's DISCUSSes (on privacy and security) and
would like to see them addressed.