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

Just to repeat: I won't mandate text on this specific issue.

But there could be an implicit assumption that PREOF compute resources in the node fast path will _always_ be available. And it is entirely unclear to me if that would be a realistic assumption if the router fast path has to do complex coding on each packet, e.g. for "network coding" as explicitly mentioned in the architecture document. There could be tradeoffs on power, cost, etc. when doing such complex PREOF coding functions for every single packet. And it could be more complex than existing MPLS protection and restoration schemes.

So, one could e.g. wonder if a DetNet network could run into the situation that a DetNet node as enough bandwidth and buffer, but not enough "network coding" coding/decoding capacity, or if a DetNet node would have to announce that it can do, say, 1+1 protection with PREOF, but there are not enough transcoder resources left for doing PREOF "network coding". Then there could be architectural implications, e.g., on protocols.

Assuming that "implementers will do the right thing" would be reasonable if per-packet coding/decoding actions in PREOF are always cheap. Otherwise, one may have to consider transcoders as a potentially scarce resource that could also impact flow placement decisions - maybe somewhat similar to wavelength converters in optical networks. 

I don't know how to implement "network coding" in the fast path of a router that runs at Tbit/s. If running code has already shown that doing "network coding" at the line speed of today's routers is easily doable, this specific point may not be relevant. Clearly I am not an expert for router fast path designs.

Michael

> -----Original Message-----
> From: Norman Finn [mailto:norman.finn@mail01.huawei.com]
> Sent: Tuesday, November 27, 2018 11:32 PM
> To: Lou Berger; Scharf, Michael
> Cc: tsv-art@ietf.org; detnet@ietf.org; draft-ietf-detnet-
> architecture.all@ietf.org
> Subject: RE: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf-
> detnet-architecture-08
> 
> 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 [detnet-bounces@ietf.org] on behalf of Lou Berger
> [lberger@labn.net]
> Sent: Tuesday, November 20, 2018 10:07 AM
> To: Scharf, Michael
> Cc: tsv-art@ietf.org; detnet@ietf.org; draft-ietf-detnet-
> architecture.all@ietf.org
> 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
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet