Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-20

I agree with Ben's point regarding formal archival value, and would encourage the working group to at least briefly consider the guidance for alternate formats described in the final paragraph of https://www.ietf.org/blog/support-documents-ietf-working-groups/

I don't object to publication of this document, as it was added to the DETNET charter prior to the IESG's guidance on the topic. I simply want to make sure the working group considered and ruled out alternate forms of making the use cases available in light of their goals. On a casual examination, the goals stated in the Introduction of this document would appear to be satisfied by any of the three concrete suggestions given in the IESG guidance I cite above.

There's a lot of interesting and useful information in this document.  Thanks to all who put work into getting it done!

It is not hard to tell that sections were written by different authors -- in itself, that is a good thing because it highlights the diversity of the scenarios considered and the applicability of the DetNet technology.  However, the result is an uneven treatment of the different use cases, from how they are described (some include more details and others get a higher level description), to even the number of references used.

This last point is what I would like to call out as a point of improvement: basically starting in Section 7, none of the use cases have a single reference in them...even when explicitly pointing at a resource, for example: "see the IETF99 Network Slicing BOF session agenda and materials" (§10.6).  It would increase the value of the document if relevant references were added.

I appreciate the work that went into this draft, and am balloting "No Objection". 

I also greatly appreciate the fact the draft has text to explain why it would have archival value as an RFC. However, I'm not sure I'm convinced. Much of its value is as input to other WG efforts, which I assume will eventually complete. The remaining value seems to be to provide design context to future users or the technology. While I can sort of accept that, it's an argument that could apply to almost any WG input document. (Note: I don't really expect a change due to this comment.)

Other than that, I have some specific comments:

*** Substantive ***

§2.1.1: Would it be worthwhile to discuss whether Forward Error Correction (FEC) is helpful here?

§5.1: "For example, a 1% cost reduction in some areas could save
$100B"
I really hope the math if off. $100B is 1% of $10T.

§9.1.2: "The challenge of blockchain network operation is not overall data
rates, since the volume from both block and item stays between
hundreds of bytes to a couple of mega bytes per second, but is in
transporting the blocks with minimum latency to maximize efficiency
of the blockchain consensus process."

That needs elaboration. What is the impact of latency on the consensus process? It's not obvious to me from the text how this is more impacted the ''average" application.

§17: Are there really no normative references? Please keep in mind that any reference that must be read for the reader to fully understand the draft should be normative.

*** Editorial ***

- General: 

-- There are a number of assertions that refer to the current state of technology. Words like "currently" tend to age badly in RFCs. I suggest qualifying those with something to the effect of "At the time of publication...". 

-- There seems to be some overlap between use cases. I wonder why things like "Wireless for Industrial Applications" and "Mining Industry", which describes an industrial application of wireless, are treated separately.

§3.1.1.4: "The IEC (International Electrotechnical Commission) has recently
published...": Will not age well.
§5, title: "Industrial" is not a noun. I suggest "Wireless for Industrial Applications".
§7, title: Please expand M2M in the section title.
§7.3: First sentence is a fragment.
§8.2, third paragraph: Please define "leaky feeder"
§9 and subsections: This section needs proofreading for missing articles and plurals. 
§9.1.1: s/ "amount of items"/"number of items"
§9.1.2:
- 2nd paragraph: "initiates" is a transitive verb. A node either initiates _something_, or a node is initiated.
- 3rd paragraph: 2nd sentence has multiple comma splices.
§9.1.3: typo: "todayt"
§10.3, first paragraph: "currently under development" will not age well.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3472



COMMENTS
S 3.1.1.1.5.
>      |          Availability          |             99.9999              |
>      |    precise timing required     |               Yes                |
>      | Recovery time on node failure  |     less than 50ms - hitless     |
>      |     performance management     |          Yes, Mandatory          |
>      |           Redundancy           |               Yes                |
>      |          Packet loss           |               0.1%               |

Where do these packet loss numbers come from? It seems like if you had
a .1% chance of systems damage, that would be bad,


S 3.3.2.2.
>      physical networks leveraging different technologies across the
>      country: an optical network and a microwave network for instance.
>      Each protection and automatism system between two points has two
>      telecommunications circuits, one on each network.  Path diversity
>      between two substations is key.  Regardless of the event type
>      (hurricane, ice storm, etc.), one path shall stay available so the

You may want to say "needs to"


S 3.3.3.
>      concepts of:
>   
>      o  Integrity : data cannot be altered undetectably
>   
>      o  Authenticity : the telecommunications parties involved must be
>         validated as genuine

FWIW, we typically refer to this as "data origin authentication" and
obviously it's kind of inseparable from integrity


S 5.1.
>      These networks may also contain very large numbers of devices, for
>      example for factories, "big data" acquisition, and the IoT.  Given
>      the large numbers of devices installed, and the potential
>      pervasiveness of the IoT, this is a huge and very cost-sensitive
>      market.  For example, a 1% cost reduction in some areas could save
>      $100B

This seems like a surprisingly high number given that 100B/.01 ~= 10
trillion and the entire US GDP is 20 trillion.


S 7.2.1.
>      "n", then the next cycle ("n+1") must be lossless).  After two or
>      more consecutive packet losses the network may be considered to be
>      "down" by the Application.
>   
>      As network downtime may impact the whole production system the
>      required network availability is rather high (99,999%).

Nit: you are using period-based decimals elswehre.


S 8.1.
>      where the final product (e.g.  Copper) is obtained.  Although the
>      operation is autonomous, the tracks are remotely monitored from a
>      central facility.
>   
>      In pit mines, the monitoring of the tailings or mine dumps is
>      critical in order to avoid any environmental pollution.  In the past,

Not a networking issue, but my understanding is that pit mines in
practice generate quite a bit of pollution.


S 9.1.1.
>   9.1.1.  Blockchain Operation
>   
>      A 'block' runs as a container of a batch of primary items such as
>      transactions, property records etc.  The blocks are chained in such a
>      way that the hash of the previous block works as the pointer header
>      of the new block, where confirmation of each block requires a

This is not maximally clear. The relevant point is that block N+1
transitively vouches for blocks N and before.


S 9.1.2.
>      items and the blocks to the other nodes.
>   
>      When a node initiates, it first requests the other nodes' address
>      from a specific entity such as DNS, then it creates persistent
>      connections each of with other nodes.  If node A confirms an item, it
>      sends the item to the other nodes via the persistent connections.

This is certainly one design, but it's not the only one.


S 9.3.
>   9.3.  Private Blockchain Future
>   
>      Blockchain system performance can be greatly improved through
>      deterministic networking service primarily because it would
>      accelerate the consensus process.  It would be valuable to be able to
>      design a private blockchain network with the following properties:

Hmm... I'm not sure how persuaded I am by this. Generally the rate of
block generation is quite low, compared to any plausible network.


S 11.1.8.
>   
>   11.1.8.  Mix of Deterministic and Best-Effort Traffic
>   
>      DetNet is intended to support coexistance of time-sensitive
>      operational (OT) traffic and information (IT) traffic on the same
>      ("unified") network.

This seems potentially inconsistent with 11.1.6. Perhaps you mean that
11.1.6 only applies to OT?


S 11.5.
>      addition to arriving with the data content as intended, the data must
>      also arrive at the expected time.  This may present "new" security
>      challenges to implementers, and must be addressed accordingly.  There
>      are other security implications, including (but not limited to) the
>      change in attack surface presented by packet replication and
>      elimination.

Do these requirements impose new requirements on the cryptographic
algorithms used to verify traffic?

Most of my comments have appeared in other AD's ballot positions, which is always handy when I ballot an hour and a half before a telechat, but when I noticed that Section 6 (almost in its entirety) and Section 10.3 are describing 3GPP environments, and I hadn't seen any traffic on the 3gpp-ietf-coordination mailing list about this draft, I checked last night with Georg Meyer, the 3GPP liaison to IETF, and he said he remembered discussions about this draft in SA2, but wasn't remembering recent discussions. 

He's in a meeting this week, and said he would check the draft next week. I don't think there's any reason for me to expect a problem, but given that Georg had been quite clear in previous discussions on Netslicing that 3GPP didn't have requirements for the IETF yet, it seemed helpful to make sure that 3GPP agrees with what's being said about 3GPP networks in IETF documents.

I'm actually fine publishing this draft in archival form, because if there are SDOs that AREN'T worried about any of these use cases, I sure can't think of them, so I'd expect that this would be useful in coordinating with other SDOs, and more broadly with implementers and operators who don't participate in the IETF, and I'm not Deferring or Discussing, because I'm sure the right thing will happen, whether the draft is approved today or not. 

But I thought I should ask now, rather than 5 minutes after the RFC is announced :-)

* Section 6.1.5

3GPP networks have some form of admission control to get access to these time sensitive streams. I think that it is important to mention that here 

* Section 6.2.1.

How does CPRI fit the narrative here for the fronthaul? Do you think it falls under the proprietary protocol and framing category?

* Section 7.4

What does burstless mean (especially in the context of low packet loss)?

* Section 10.3

A reference to 3GPP TS 23.501 could be useful here to describe the 5G slicing.

* Section 12

I did not see much value in this but I am assuming this was put in to keep track of out of scope items during the WG process. Could this be moved to an Appendix?

* References

The reference for 3GPP TR 38.801 wrongly cites it as an IEEE spec. Please fix this.

Typo:

* Section 9.1.3.

s/todayt/today/