Re: [Detnet] WG Last Call: draft-ietf-detnet-problem-statement-03

["Pascal Thubert (pthubert)" <[e-mail]>]

Thanks a bunch Stewart ;

Please see below - by OK I mean undisputed agreement and changed made in the repo, to be published with the next version unless opposition shows up;

From: detnet <[e-mail]> On Behalf Of Stewart Bryant
Sent: jeudi 3 mai 2018 16:57
To: János Farkas <[e-mail]>; DetNet WG <[e-mail]>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-problem-statement-03


This is basically ready, but I think a few items need attention before this goes to the IESG:

   As a result of this work, it will be possible to establish a multi-

   hop path over the IP network,



SB> I think that should be an IP or MPLS network

[PT>] OK





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



  The goals of Deterministic Networking are to enable the migration of

   applications that use special-purpose fieldbus technologies (HDMI,

   CANbus, ProfiBus, etc... even RS-232!) to packet technologies in

   general, and the Internet Protocol in particular, and to support both

   these new applications, and existing packet network applications,

   over the same physical network.



SB> I think there should be some text here indicating that DN is

SB> required to support these migrations when there are critical

SB> timing and reliability issues.

SB>

SB> Where such issues are not critical, the Pseudowires or L2TP tunnels

SB> will normally be adequate. Indeed they have proved adequate for TDM

SB> and SDH emulation which are quite fickle services to emulate.

[PT>] OK



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



       *  Need a packet loss ratio beyond the classical range for a

          particular medium, in the range of 10^-9 to 10^-12, or better,

          on Ethernet, and in the order of 10^-5 in Wireless Sensor Mesh

          Networks;



SB> I am worried whether or not we are setting unreasonable expectations

SB> here.  How many packet copies do we think we need to send

SB> to reduce the BER by 10?

[PT>] I think these numbers are associated with the concept of PRE. If a typical Ethernet gives you 10-5 then PRI should reach 10-10

Arguably this considers only one fault at a time.





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



   4.  Robust defenses against misbehaving hosts, routers, or bridges,

SB> s/defenses/defences/

       both in the data and control planes, with guarantees that a

       critical flow within its guaranteed resources cannot be affected

       by other flows whatever the pressures on the network;



[PT>] UK vs. US. Which do we usually pick?



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



These limits may depend in the technology that is used to

   seu th epath up, whether it is centralized or distributed.



SB> Hopefully no my fat fingers in my marked up copy, but it should be:

SB> "set the path"

[PT>] Yes, Kiran spotted it first ; )



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



   3.  The path is installed using RSVP-TE, associated with flow

       identification, per-hop behavior such as replication and

       elimination, blocked resources, and flow timing information.



SB> This is too prescriptive on approach for a problem statement.

SB> There might well be an approach that surfaces from the Segment Routing

SB> or VPN+ work based on use of the IGP.



[PT>] Yes, but at some point the resources along the path must be blocked.

How is that done? What if the IGP selects a different path?

I guess SR works as long as the SR is strict or the path between routers in the SR cannot change, and resources are aplenty.

What about this:



    The path may be installed using a control protocol such as RSVP-TE,

    associated with flow identification, per-hop behavior such as Packet

    Replication and Elimination, blocked resources, and flow timing information.

    Alternatively, the routing and flow information may be placed in-band in the

    packet, e.g., using Segment Routing, in which case the packet is routed

    along a prescribed source route path following forwarding indications that

     are present in the packet.





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



  Security must cover:



SB> I think should be "Security must also cover". If not the dynamic

SB> requirement which is unique to DN should be top of the list.



 o  the protection of the signaling protocol



SB> True, but isn't this currently out of scope (and not sure about the next point)



[PT>] What about:



The overall security of a deterministic system must cover:



Thanks again Stewart!



Pascal