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

[Norman Finn <[e-mail]>]

Typically, the resources for DetNet flows are reserved before the flow starts.  In the case of PREOF, the functions are at least configured before being used.  I would think that, if insufficient capability exists, the reservation/configuration would be refused.  We're talking an awful lot of 9s here, to justify this feature, so doing otherwise would be a poor implementation choice.  Do we need to say something about that, or figure that implementors will do the right thing?

-- Norm

________________________________________
From: detnet [[e-mail]] on behalf of Lou Berger [[e-mail]]
Sent: Tuesday, November 20, 2018 10:07 AM
To: Scharf, Michael
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf-detnet-architecture-08

Michael,

Thanks for the clarification.

On 11/20/2018 10:02 AM, Scharf, Michael wrote:
> 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).

at the network layer, protection and restoration is not new. There is
LFAs. FRR, 1+1, 1:n, shared mesh etc all defined in RFCs - mostly, but
not solely for MPLS.  It's also not new transport protocol layer either
as there is work (have to check if RFCs) on network coding and 1+1 --
but this is outside the scope of Detnet.


> 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?

No more so than exists in the current  RFCs related to the topic.

> - Overload of DetNet components: As another example for PREOF, how would a DetNet deployment ensure that PEF never gets overloaded?

Umm, how does an RFC ever dictate that a router/node/host isn't
overloaded?  In the normal internet case, I think this is way outside
the scope of an RFC.  For TE networks, this is what
configuration/management/control is all about - and sure we can add a
sentence on that.


> 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?

yes, there is configuration/management/control-- this can be mentioned.


>
> 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.)

The IETF generally just defines the behavior on the wire in standards
track RFCs and let others define requirement system performance levels.
I don't think we should be changing this in DetNet.


> 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?

There are plenty of high availability (and different level of
availability) implementations of systems out there.  The only think the
IETF gets involved with specifying are those aspects that impact
interoperability between systems.  (E.g., all the graceful restart
related extensions in control plane protocols). Again, I don't think
it's for DetNet to move beyond this.


> 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.

Thanks - it sounds like we're ending at the same place even if we didn't
follow the same path to get here.

Thanks again for comments/review.  I do think we'll have a better
document once the other points are addressed.

Lou

> Michael

_______________________________________________
detnet mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet