Last Call Review of draft-ietf-detnet-architecture-08
review-ietf-detnet-architecture-08-genart-lc-halpern-2018-09-21-00

Request Review of draft-ietf-detnet-architecture
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-10-03
Requested 2018-09-19
Other Reviews Rtgdir Last Call review of -08 by Henning Rogge (diff)
Secdir Last Call review of -08 by Dan Harkins (diff)
Tsvart Last Call review of -08 by Michael Scharf (diff)
Tsvart Telechat review of -11 by Michael Scharf
Genart Telechat review of -11 by Joel Halpern
Review State Completed
Reviewer Joel Halpern
Review review-ietf-detnet-architecture-08-genart-lc-halpern-2018-09-21
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/5Nsli-3yVEVIsQIZjSE-H7wZrQI
Reviewed rev. 08 (document currently at 11)
Review result Ready with Issues
Draft last updated 2018-09-21
Review completed: 2018-09-21

Review
review-ietf-detnet-architecture-08-genart-lc-halpern-2018-09-21

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-detnet-architecture-08
Reviewer: Joel Halpern
Review Date: 2018-09-20
IETF LC End Date: 2018-10-03
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard

I presume that the status was selected so as to avoid the need for downrefs when other Detnet documents normatively reference this one?

Major issues: N/A

Minor issues:
    Section 3.1 states that worst case delay for priority queueing is unbounded.  That does not match my understanding.  I know that DelayBound DSCP behavior tightly (although, I think, not as tightly  as Detnet) limits both the worst case delay and the delay variation.

    It seems very odd that section 3.2.1.1 says that DetNet flows can not be throttled when earlier text says that DetNet flows do have a maximum bandwidth.  Buried in section 4.3.2 I find that what is meant by throttled is not "enforcing a rate limit", but rather "sending congestion notification to cause the source to slow down."  I think the wording about "can not be throttled" both in 3.2.1.1 and 4.3.2 should be adjusted for clarity.

    3.2.1.1 also reads oddly in that it seems to recommend providing significant buffering, when the need for and use of such buffers is a major source of jitter.

    In section 4.1.2, I realized that the Detnet Transit node terminology had mildly confused me.  The text says "DetNet enabled nodes are interconnected via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet service aware."  Reading this, and the definitions in section 2.1, it appears that a Detnet Transit node is a node that is providing transport behavior that detnet needs, but is not actually modified for detnet.  

    Section 4.4.2 talks about per flow per node state.  It would be good to have a forward reference to section 4.9 about scaling to larger networks.

Nits/editorial comments: 
     It would be good if there were some explanation for the 75% maximum number in section 3.3.1.  That there is some limit seems intuitive.  What value that limit has is not so obvious.

    Section 4.7.3 introduces an example using Ethernet Mulicast destiantions as part of labeling.  There is no earlier explanation of the use of an Ethernet MAC Multicast destination, and the text does not seem to require that the traffic be actually multicast.  Hence the reader is liable to be confused by the reference to multicast.  I rate this only a nit as it seems clear that this is an example whose details are presumably explained in another document.    Still, it would help to clarify the example.