Last Call Review of draft-ietf-detnet-architecture-08

Request Review of draft-ietf-detnet-architecture
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-10-05
Requested 2018-09-18
Requested by Deborah Brungard
Authors Norman Finn, Pascal Thubert, Balazs Varga, János Farkas
Draft last updated 2018-10-15
Completed reviews Rtgdir Last Call review of -08 by Henning Rogge (diff)
Secdir Last Call review of -08 by Dan Harkins (diff)
Genart Last Call review of -08 by Joel Halpern (diff)
Tsvart Last Call review of -08 by Michael Scharf (diff)
Tsvart Telechat review of -11 by Michael Scharf (diff)
Genart Telechat review of -11 by Joel Halpern (diff)
Prep for Last Call.
Assignment Reviewer Henning Rogge
State Completed
Review review-ietf-detnet-architecture-08-rtgdir-lc-rogge-2018-10-15
Reviewed rev. 08 (document currently at 13)
Review result Has Nits
Review completed: 2018-10-15


(Posting to RTG-DIR on behalf of Henning.)


I was asked to do a last-call review for the detnet architecture 08 draft... sorry for the delay.

I think the draft provides a good overview what detnet wants to do.
When read in order, some chapters seem to skip a few points that get included in later chapters (in a different context), but I think this should be easy to fix.

Here are some comments to the draft that came to my mind during reading it:

Detnet Relay Node (Page 5)

can be bridge (which should be layer2), but Detnet operates on IP layer?

Congestion Protection (Page 8)

Does Detnet differenciate between limited network capabilities because of media access and datarate? In some networks you might hit a "packet per time" limit before you hit the "byte per time" limit, which is mostly solved by aggregating multiple packets.

Explicit Routes (Page 8)

Does this mean DetNet normally uses a "frozen" state of a route, e.g.
a snapshot of a routing protocol? What happens if the route does not apply anymore (maybe this is out-of-scope for DetNet)?

Sufficient buffer (Page 10)

"Sufficient buffer" also can give you a higher amount of latency. If for whatever reason a packet arrives "too late", it might be better to drop it to recover the realtime behavior of the following packets (assuming more allocated bandwidth than necessary). This is explained in page 15 (3.3.2. Fault Mitigation) I think.

Extra Buffering for different-length paths (Page 13)

This sounds like another point where additional latency might appear.

Reduction of available bandwidth for non-DetNet packets (Page 15)

.... and increased latency.
(Mixing DetNet and non-DetNet packets sounds quite difficult if you want to keep all guarantees of DetNet)

DetNet data plane protocol stack (Page 18)

How does this diagram mesh with the standard stack layers? Are IP/MAC all "lower Layers" ?

DetNet adaptation to data plane (Page 19)

Figure 4 reads like the combination of UDP and IP (with static routes
set) would be okay for DetNet under certain circumstances... no "hop-by-hop" userspace (DetNet)-processing required?

Synchronous DetNet (Page 24)

I feel that the most important advantage of this would be the collision-free usage of the shared links between the DetNet nodes, which helps to keep the Latency to a lower limit.

Henning Rogge