Re: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf-detnet-architecture-08

["Scharf, Michael" <[e-mail]>]

Lou,

Just regarding my comment that seems unclear...

[snip]

>> In addition, I'd like to emphasize that my review comment "It is surprising that there is hardly any discussion on network robustness and safety"

>I have no idea what you mean by safety here.  Can you elaborate.

As far as I understand, DetNet introduces network functions that at least partly novel, such as PREOF.  And as PREOF explicitly allows solutions beyond 1+1 protection ("network coding" is mentioned as example). I believe that any new function typically raises operational issues.

Out-of-my-head, here are some examples of potential challenges that seem not well addressed in -09:

- PREOF (and specifically) PEF as a single point of failure: Is there any need to worry about that? As far as I can see, the document discusses failures of paths between POF and PEF, but not failures of the functions themselves. Wouldn't it make sense to discuss basic requirements such as implementing these functions redundantly etc.? And if they are implemented redundantly, does this impact the architecture, e.g., result in additional interfaces that may need standardization? 

- Overload of DetNet components: As another example for PREOF, how would a DetNet deployment ensure that PEF never gets overloaded? Buffering and resequencing of packets requires processing. Techniques to allocate buffer space alone may not be enough to ensure that PEF never gets overloaded. Is this a problem or not? And even if this problem may perhaps not really exist for 1+1, is there no need to worry about other, possibly more complex PREOF schemes that may require complex packet processing (or even coding)? Are there scaling issues in PREOF? And could this impact signaling, e.g., require control plane protocol extensions?

More generally, if the intention of DetNet is to carry mission-critical or safety-critical traffic that cannot tolerate any packet loss, let alone any downtime, wouldn't words such as "reliability", "dependability", "redundancy", "high availability", etc. be relevant in a description of the architecture? (Some of these terms are actually used in this document, mostly in references to non-IETF work.)

And this may not only matter for the data plane. Assuming that a lot of DetNet traffic requires extremely high reliability, are there architectural requirements on components outside the data plane, e.g., regarding redundancy? Obviously, control plane and management plane functions are often built today already as high availability solutions, but if the intention is to _never_ fail, isn't there a risk that DetNet may require solutions "better-than-current-IP" outside the data plane as well?

This list of topics may not be comprehensive. I just want to illustrate some examples for what could also matter when running a network _really_ deterministically, beyond the well-known congestion issue. 

However, just to be precise: I don't ask for additional text to address what is written in this e-mail.

Michael