[Detnet] Warren Kumari's No Objection on draft-ietf-detnet-ip-06: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-detnet-ip-06: 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-ip/



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

I'm balloting NoObj in the "I read the protocol action, and I trust the
sponsoring AD so have no problem." / "I have no cycles" sense. Due to other
work, I was not able to review this document nearly as thoroughly as I would
have liked, but I *do* support Alvaro's (and others) DISCUSS - there are many
places where the document says that the network MUST do something, but without
the something being particularly well defined;I'm sure that the authors /
DetNet WG understand what these are, but it's not clear from the document
itself -- I'm guessing that this is defined in other documents, but I wasn't
able to easily find them.

I was mystified by " For some of the protocols 5-tuples and 6-tuples cannot be
used because the port information is not available (e.g., ICMP, IPSec ESP). 
Same can be valid for flow aggregates. " - is this that the 5/6 tuples cannot
be used for flow aggregates? I went to try and find more info on flow
aggregates, and looked in ietf-detnet-data-plane-framework (which, like many of
the referenced draft-detnet- documents should be Normative references), but it
didn't seem to have much detail (other than that "There are many techniques to
achieve aggregation" -- where is how flow aggregation actually works
documented? This document (S4.4) says that: flow aggregation "is an important
technique for improving
   scaling by reducing the state per hop", but without understanding how flows
   are aggregated, and the state needed per flow, this is hard to evaluate. In
   addition "In either case, the management or control function that provisions
   the aggregate flows must ensure that adequate resources are allocated and
   configured to provide combined service requirements of the individual
   flows." -- if this "of the individual flows", or "of the aggregate flows"?
   Presumably there will be a difference.

I found Section "5.3.  DetNet IP Traffic Treatment Procedures" to be very terse
-- I was expecting to read this and understand what *exactly* the IP Traffic
Treatment Procedures are - instead it seemed to feel more like "Implementations
must make sure that they provide the service that has been configured". The
section says: " Typical mechanisms used to provide different treatment to
different flows includes the allocation of system resources (such as queues and
buffers) and provisioning or related parameters (such as shaping, and
policing). " -- but this all feels fairly circular - where is the treatment of
traffic "when operating in an IP packet switched network." actually defined? If
I'm building a router/switch/similar, and what to provide support for DetNet
over IP, what *exactly* do I do with traffic once it has been identified? How
do I queue it differently? What happens if I cannot meet the requirement? Where
is this documented?

Apologies for not being able to review this in the depth it deserves,
W