Reviewer: Joel Halpern Review result: Ready with Issues 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.
