Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

[Balázs Varga A <[e-mail]>]

Hi Stewart,



Thanks for the detailed review and the great comments.

My answers inline. Update of the document in progress.



@Norm: do you have a reference for network calculus?

@Co-authors: what to do with the HSR-PRP, ISA95 references?



Cheers

Bala'zs



-----Original Message-----
From: detnet <[e-mail]> On Behalf Of Stewart Bryant
Sent: 2018. május 23. 18:02
To: Lou Berger <[e-mail]>; DetNet WG <[e-mail]>
Cc: DetNet Chairs <[e-mail]>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05



Some WG last call comments on draft-ietf-detnet-architecture



Best Regards



Stewart



=============



Abstract



   The capabilities can be managed by

   configuration, or by manual or automatic network management.



SB> I am not sure that network management (at least in the IETF is quite

SB> the right term. Most people think of what is described here as

SB> automatic network management as a routing protocol.



[Balázs Varga A] OK. I have deleted this sentence. Do not add to the abstract.

It is rather confusing.



===============



1.  Introduction



   Deterministic Networking (DetNet) is a service that can be offered by

   a network to DetNet flows.  DetNet provides these flows extremely low s/flows/flows with/ =========



   Many applications of interest to Deterministic Networking

SB> That is surely the wrong way round - the applications are interested

SB> in DN rather than DN being interested in the Apps?



[Balázs Varga A] OK. Fixed.



==========



   source

           An end system capable of sourcing a DetNet flow.



SB> Shouldn't that be a DetNet source, since you can have both DetNet

SB> and non-DetNet sources in a DetNet enabled network.



[Balázs Varga A] OK. Fixed



===========



    DetNet transit node

           A node operating at the DetNet transport layer, that utilizes

           link layer and/or network layer switching across multiple

           links and/or sub-networks to provide paths for DetNet service

           layer functions.  Optionally provides congestion protection

           over those paths.  An MPLS LSR is an example of a DetNet

           transit node.

SB> In that example it would have to be a DetNet enable/aware LSR. An

SB> ordinary LSR would not know anything about DetNet.



[Balázs Varga A] No, A DetNet aware LSR would be a relay node (S-PE).



=============



2.2.  IEEE 802 TSN to DetNet dictionary



   This section also serves as a dictionary for translating from the

   terms used by the IEEE 802 Time-Sensitive Networking (TSN) Task Group

   to those of the DetNet WG.



   Listener

           The IEEE 802 term for a destination of a DetNet flow.



   relay system

           The IEEE 802 term for a DetNet intermediate node.



   Stream

           The IEEE 802 term for a DetNet flow.



   Talker

           The IEEE 802 term for the source of a DetNet flow.



SB> Whilst I cannot comment on IEEE definitions, I am suprised that in

SB> our text a Listener is not called an 802 TSN Listener etc



[Balázs Varga A] We have used the TSN end-system. TSN end-system can be both

(Listener and Talker).



=============



   The paths are typically (but not necessarily) explicit

   routes, so that they cannot suffer temporary interruptions caused by

   the reconvergence of routing or bridging protocols.



SB> I think cannot is too strong. I think the best that you can say is

SB> "do not normally".

SB>



[Balázs Varga A] OK, Fixed.



============





   These three techniques can be applied independently, giving eight

   possible combinations, including none (no DetNet), although some

   combinations are of wider utility than others.  This separation keeps

   the protocol stack coherent and maximizes interoperability with

   existing and developing standards in this (IETF) and other Standards

   Development Organizations.  Some examples of typical expected

   combinations:



   o  Explicit routes plus service protection are exactly the techniques

      employed by [HSR-PRP].  Explicit routes are achieved by limiting

      the physical topology of the network, and the sequentialization,

      replication, and duplicate elimination are facilitated by packet

      tags added at the front or the end of Ethernet frames.



SB> ER can be done virtually as well as physically. RSVP is a type of

SB> ER, as is Adj-SID based SR, and we can design other types.



[Balázs Varga A] Agree, but these are examples. Statement is for HSR-PRP.



   o  Congestion protection alone is is offered by IEEE 802.1 Audio

      Video bridging [IEEE802.1BA-2011].  As long as the network suffers

      no failures, zero congestion loss can be achieved through the use

      of a reservation protocol (MSRP), shapers in every bridge, and a

      bit of network calculus.



SB> Network calculus needs a reference. It is not well known outside detnet.



[Balázs Varga A] Agree. Asked Norm for a reference.



================









3.2.3.  Jitter Reduction



   A core objective of DetNet is to enable the convergence of Non-IP

   networks onto a common network infrastructure.



SB> I think that  this needs to be clarified that it is the convergence

SB> of sensitive Non-IP. PW has been doing this convergence since

SB> inception, and can handle what some would expect to be sensitive

SB> applications such as TDM telephony quite well.



[Balázs Varga A] OK. Fixed.



   This requires the

   accurate emulation of currently deployed mission-specific networks,

   which typically rely on point-to-point analog (e.g. 4-20mA

   modulation) and serial-digital cables (or buses) for highly reliable,

   synchronized and jitter-free communications.  While the latency of

   analog transmissions is basically the speed of light, legacy serial

   links are usually slow (in the order of Kbps) compared to, say, GigE,

   and some latency is usually acceptable.  What is not acceptable is

   the introduction of excessive jitter, which may, for instance, affect

   the stability of control systems.

SB> See above, I think this needs a few caveats.



[Balázs Varga A] OK. Fixed.



===============





   Packet replication and elimination, also known as seamless redundancy

   [HSR-PRP], or 1+1 hitless protection, is a function of the DetNet

   service layer.  It involves three capabilities:



SB> I am concerned at the prominence of the HSR-PRP reference. As far as

SB> I can tell this is only available for fee of 300 Euro.



[Balázs Varga A] OK. Let's discuss this with the co-authors.



============



   In the simplest case, this amounts to replicating each packet in a

   source that has two interfaces, and conveying them through the

   network, along separate paths, to the similarly dual-homed

   destinations, that discard the extras.  This ensures that one path

   (with zero congestion loss) remains, even if some intermediate node

   fails.  The sequence numbers can also be used for loss detection and

   for re-ordering.



SB> Sure, but of course you need to do SRLG risk analysis, and even then

SB> two failures are not unknowm.



[Balázs Varga A] OK. Fixed.



===========







                    Packet replication and elimination



                > > > > > > > > > relay > > > > > > > >

               > /------------+ R node E +------------\ >

              > /                  v + ^               \ >

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

              > \                  v + ^               / >

               > \------------+ R relay E +-----------/ >

                > > > > > > > > >  node > > > > > > > >



                                 Figure 1



   Packet replication and elimination does not react to and correct

   failures; it is entirely passive.  Thus, intermittent failures,



SB> I think it copes with intermittent failures OK.



[Balázs Varga A] Yes, PRF and PEF can eliminate the effect of such failures. But text

intends to say that it is passive. It is not reacting to such failures. No change in text.



    mistakenly created packet filters, or misrouted data is handled just

   the same as the equipment failures that are detected handled by

   typical routing and bridging protocols.



================



   Transit nodes see DetNet nodes as end points.  All

   DetNet enabled nodes are connect to sub-networks, where a point-to-

SB> s/connect/connected/



[Balázs Varga A] OK. Fixed.



===========





   o  DetNet t-aware: An extant TSN system.  It knows about some TSN

      functions (e.g., reservation), but not about replication/

      elimination.

SB> Generic TSN is OK, but I would be cautious of requiring IEEE TSN.



[Balázs Varga A] OK.



===========



 o  DetNet s-aware: An extant IEC 62439-3 system.  It supplies

      sequence numbers, but doesn't know about zero congestion loss.



SB> IEC62439 should surely be clarified as just an example.



[Balázs Varga A] OK. All items are examples " Note some known use cases for end systems: "



===========



4.3.1.  DetNet flow types



   A DetNet flow can have different formats during while it is

SB> s/during while/as/



[Balázs Varga A] OK. Fixed.



===========



   transported between the peer end systems.  Therefore, the following

   possible types / formats of a DetNet flow are distinguished in this

   document:



   o  App-flow: native format of a DetNet flow.  It does not contain any

      DetNet related attributes.



   o  DetNet-t-flow: specific format of a DetNet flow.  Only requires

      the congestion / latency features provided by the Detnet transport

      layer.



   o  DetNet-s-flow: specific format of a DetNet flow.  Only requires

      the replication/elimination feature ensured by the DetNet service

      layer.



   o  DetNet-st-flow: specific format of a DetNet flow.  It requires

      both DetNet service layer and DetNet transport layer functions

      during forwarding.

SB> I find the relisting of these types confusing. Wheren't they defined

SB> in the section above?



[Balázs Varga A] This is inline with the previous section " Grouping of end systems ".



===========



4.3.2.  Source guarantees



   For the purposes of congestion protection, DetNet flows can be

   synchronous or asynchronous.  In synchronous DetNet flows, at least

   the intermediate nodes (and possibly the end systems) are closely

   time synchronized, typically to better than 1 microsecond.



SB> Are you talking about the flows being sync, or the network handling

of the

SB> the flows here. We have carried synchronous traffic over MPLS in the

past

SB> so I think this is a topic that requires quite careful handling to

make sure that

SB> we do not set up an over-engineered solution.



[Balázs Varga A] "Sync as a service" is assumed for some use-case.

It is not needed for some others.



==========







   The source promises that these limits will not be exceeded.  If the

   source transmits less data than this limit allows, the unused

   resources such as link bandwidth can be made available by the system

SB> s/can be made/to be made/



[Balázs Varga A] OK. Fixed.



==========



4.4.  Traffic Engineering for DetNet



   Traffic Engineering Architecture and Signaling (TEAS) [TEAS] defines

   traffic-engineering architectures for generic applicability across

   packet and non-packet networks.  From TEAS perspective, Traffic

SB> s/from/from a/



[Balázs Varga A] OK Fixed.



==========



   ..... to translate from a flow

   specification to a set of values for the managed objects that control

   each relay or end system.  The IEEE 802 has specified (and is

SB> Should that be IEEE 802 Standards Group or some such?



[Balázs Varga A] OK. Fixed.



=============





   The DetNet network reference model is shown in Figure 8 for a DetNet-

   Service scenario (i.e. between two DetNet-UNIs).  In this figure, the

   end systems ("A" and "B") are connected directly to the edge nodes of

   the IP/MPLS network ("PE1" and "PE2").



SB> I am confused as to when we should use the terms "relay node", "edge

node"

SB> and "PE". There seem.s to be inconsistency in the project on the use

SB> of these terms



[Balázs Varga A] OK. See separate mailing started by Lou. "PEx" here refers

to the nodes on the figure.



===========



   The tunnel between the service instances may have some special

   characteristics.  For example, in case of a "packet PW" based tunnel,



SB> I don't think we should use the term "packet PW" since that points

SB> to a specific PW technology and that is not the direction we are

SB> going in the data-plane part of the project.

SB> I think the text above and the text in the rest of the para is

SB> confusing for the reader.

SB> I suggest that we write something much more generic and let the DP

SB> team have a clear hand to design a good solution.



[Balázs Varga A] OK. Fixed. I have removed the " packet PW for DetNet traffic " term.

I agree that such a term is now outdated with all the data plane discussions behind us.

Text intention is to highlight the differences to rfc6658, so I have changed text to refer

"DetNet L3 service" scenario.



   there are differences in the usage of the packet PW for DetNet

   traffic compared to the network model described in [RFC6658]. In the

   DetNet scenario, the packet PW is used exclusively by the DetNet

   flow, whereas [RFC6658] states: "The packet PW appears as a single

   point-to-point link to the client layer.  Network-layer adjacency

   formation and maintenance between the client equipments will follow

   the normal practice needed to support the required relationship in

   the client layer ... This packet pseudowire is used to transport all

   of the required layer 2 and layer 3 protocols between LSR1 and LSR2".



===========







   The need for a lower-level DetNet node to be aware of individual

   higher-layer flows is not unique to DetNet.  But, given the endless

   complexity of layering and relayering over tunnels that is available

   to network designers, DetNet needs to provide a model for flow

   identification that is at least somewhat better than packet

SB> "at least somewhat better is a strange turn of phrase"



[Balázs Varga A] OK. Fixed.



===========





   Thus, rather than packet inspection, there is the option to export

   higher-layer information to the lower layer.  The requirement to

   support one or the other method for flow identification (or both) is

   the essential complexity that DetNet brings to existing control plane

   models.



SB> A very strange way of expressing the point, sounds like complexity

SB> is a virtue.



[Balázs Varga A] OK. Fixed. (essential --> necessary)



===========



Flow-IDs



   The additional (domain specific) Flow-ID can be



   o  created by a domain specific function or



   o  derived from the Flow-ID added to the App-flow,



   so that it must be unique inside the given domain.

SB> very strange English.



[Balázs Varga A] OK. Fixed (at least I hope so ...)



   Note that the

   Flow-ID added to the App-flow is still present in the packet, but

   transport nodes may lack the function to recognize it; that's why the

   additional Flow-ID is added (pushed).



SB> Again rather strange English and an unnecessary pointer to a

SB> particular implementation technique (pushed). Same comment applies

SB> to para 1 of

4.7.3


[Balázs Varga A] OK. Fixed (at least I hope so ...)



============











4.9.  Provisioning model



SB> Sections 4.9.1 and 4.9.2 seem rather tentative for an RFC that we

SB> are about to publish.



[Balázs Varga A] Agree. Historically that was a placeholder for topics we need further discussions.

I have deleted 4.9.



4.9.1.  Centralized Path Computation and Installation



4.9.2.  Distributed Path Setup



==============



5.  Security Considerations





   Furthermore, in a control system where millions of dollars of

   equipment, or even human lives, can be lost if the DetNet QoS is not

   delivered, one must consider not only simple equipment failures,

   where the box or wire instantly becomes perfectly silent, but bizarre

   errors such as can be caused by software failures.



SB> Bizare is a strange term to use. I am sure that later reviewers will

SB> ask for more text on this.

SB> I might use the term "subtle, complex, intermittent and state dependent"



[Balázs Varga A] OK. Fixed.



============







   [HSR-PRP]  IEC, "High availability seamless redundancy (HSR) is a

              further development of the PRP approach, although HSR

              functions primarily as a protocol for creating media

              redundancy while PRP, as described in the previous

              section, creates network redundancy.  PRP and HSR are both

              described in the IEC 62439 3 standard.",

              <http://webstore.iec.ch/webstore/webstore.nsf/

              artnum/046615!opendocument>.



SB> Not available at the time of this review, but my recollection is

SB> that this is not readily available without paying a large fee.



===========







   [ISA95]    ANSI/ISA, "Enterprise-Control System Integration Part 1:

              Models and Terminology", 2000,

              <https://www.isa.org/isa95/>.



SB> Should that be 2000, or 2010.

SB> Note that this seems to be a very expensive document to access.





=========



_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/detnet