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

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

Just to add some additional references. I have made my point already and I will not further follow-up.

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Tuesday, November 20, 2018 7:08 PM
> To: Scharf, Michael
> Cc: [e-mail]; [e-mail]; draft-ietf-detnet-
> [e-mail]
> Subject: Re: [Tsv-art] [Detnet] 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.

From draft-ietf-detnet-architecture-09:

  3.2.2.3.  Packet encoding for service protection

   There are methods for using multiple paths to provide service
   protection that involve encoding the information in a packet
   belonging to a DetNet flow into multiple transmission units,
   combining information from multiple packets into any given
   transmission unit.  Such techniques, also known as "network coding",
   can be used as a DetNet service protection technique.

So, "network coding" is explicitly *in scope* of draft-ietf-detnet-architecture-09. 

And my comments are about the architectural impact of that section.

It is not clear to me why one would need an IRTF research group (NWCRG) if "network coding" was just a straightforward extension of existing MPLS or OTN protection and restoration schemes.

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

See RFCs 5390, 6357, 7068, 7339, 7683, etc. for examples where overload control is standardized. These are typical solutions in environments where five-nine availability is needed. I won't argue that these RFCs directly relate to DetNet, as these RFCs are not about routing technology. But, nonetheless, it is surprising that the working group does not worry at all about overload of newly defined functions such as PREOF, while the working group at the same time allows possibly compute-intensive solutions for that. That comes down to the assumption that compute power is never a bottleneck...

But I'll not follow-up further on that. I assume that is also a topic where other IETF areas have better expertise.

Michael


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