Re: [Iotops] Fw: I-D Action: draft-km-industrial-internet-requirements-00.txt

[Kiran Makhijani <[e-mail]>]

Hello Micheal,
Apologies for late reply. I did not see this up until now. Please see 
inline [KM].

------ Original Message ------
From: "Michael Richardson" <[e-mail]>
To: "Kiran M (ietf)" <[e-mail]>; [e-mail]; 
[e-mail]
Sent: 6/21/2021 12:55:16 PM
Subject: Re: [Iotops] Fw: I-D Action: 
draft-km-industrial-internet-requirements-00.txt

>
>Kiran M (ietf) <[e-mail]> wrote:
>     > Title           : Requirements and Scenarios for Industry Internet Addressing
>     > Authors         : Kiran Makhijani
>     > Lijun Dong
>     > Filename        : draft-km-industrial-internet-requirements-00.txt
>     > Pages           : 13
>     > Date            : 2021-06-10
>
>Thank you for the interesting document.
>If you ran it through xml2rfc --v2v3 mydraft.xml and submitted "mydraft.v2v3.xml"
>then you'd get the way more readable HTML generated as well the traditional TXT.
>
[KM] OK, will do. I can generate a readable html file locally, will try 
to upload generated -v2v3.xml.
>
>     > Abstract:
>     > Industry Control Networks host a diverse set of non-internet
>     > protocols for different purposes.  Even though they operate in a
>     > controlled environment, one end of industrial control applications
>     > run over internet technologies (IT) and another over operational
>     > technology (OT) protocols.  This memo discusses the challenges and
>     > requirements relating to converegence of OT and IT networks.  One
>     > particular problem in convergence is figuring out reachability
>     > between the these networks.
>
>About: Modbus, Profibus, CANbus, Profinet, etc.
>I understood that more and more these are running over "Ether/IP", which many
>of us just call IP.   This eliminates the physical connectivity challenges,
>but opens up significant risk due to converged network and addressing.
>

>  [KM] That is right. Most of this protocols are over IP when they talk to IT-world applications and services. Certainly security is one aspect and is a challenge for both the cases - when applications are outside a site or on-site. Today, only form of protection we have is through  firewalls. But there is an  operational aspect to it as well in which communication between different bus protocols is pretty expensive and indirect (having to go through encap/decap over IP) or proprietary. For the sake of automation, improvements in inter-operation mechanisms can simplify factory operations by reducing gateway configurations.
>
>In the automotive space, ethernet (10baseT1S) seems to poised to win over
>CANbus. My observation is that the question is which year will it win,
>rather than if.  Are you seeing CANbus used outside the automobile itself, in
>industrial settings?  (Do automotive plants use CANbus in the factory?)
>
[KM] Yes, ethernet will see higher adoption overtime. But industry 
control networks are legacy networks, there is a certain level of 
comfort and confidence in fieldbus technologies. Functionally, the 
behavior for many devices is easily satisfied by I/O bus interfaces.  
Unfortunately, I don't have a clear answer to use of CANbus in the 
factory. But we can still safely assume that the number of protocols in 
industry control are quite high and will remain that way.
>
>It feels like your document ended just as it was getting into the question
>you ask about how to arrange connectivity, addressing, etc.
>Is there more to your document that you had in mind to write?
>It's hard to know what your next step in the document would be.
>
[KM] I looked at Industry control problem from service and connectivity 
aspect. As of now i believe the services related work should be in 
DETNET territory. the second part - providing a standard and efficient 
form of inter-protocol connection on a factory floor can be discussed in 
Iotops.
>
>Some thoughts I have are:
>
>1) the XYZ-over-IP would be best if they were either XYZ-over-TLS, or perhaps
>    XYZ-over-QUIC.  Sprinkle in DETNET as needed.  QUIC eliminates
>    head-of-queue blocking issues, and so allows for higher priority commands
>    to pass lower priority ones in the queue.
>    {Of course, it should have been XYZ-over-SCTP-over-IPsec, and it could be
>    so in a greenfield plant, but mindshare is not there}
>
>    The challenge in the TLS based AKE is that we have to get the certificates
>    installed, and then we have to arrange for mutual trust.
>    I think that OPC UA currently deals with this kind of thing in it's
>    configuration model, but I'm not priviledged to see those documents.
>    (You may be?)
>
>    Is that a gap you are interesting in?
[KM]  It will be great to have a discussion on the transport and 
security of industry control operations. I think OPC-UA does have TLS 
support between the application and a server in the factory - But  I 
would guess that it does not extend all the way to end devices (simply 
because fieldbus devices only perform I/O commands and do not have 
sophisticated transport).
>
>
>2) since many of the other protocols use significant shorter identifiers,
>    creating an overlay spec that embeds them in IPv6 IIDs would be
>    interesting.
>
>    This would allow IP based controllers to address Modbus, profibus,
>    profinet, sensors/actuators directly, and if the underlying gateways and
>    wiring allows, in a stateless way.
>    Stateless is good because it means that the redundancy in the wiring can
>    be exploited.
>
>    This would be interesting work, but probably the IETF does not have the
>    right people here (AT THIS TIME), to make progress on that.
>  [KM] Hmm, that's fair to certain extent. But , the IPv6 IID design type of expertise is very much here in the IETF. There are also other things of industry control relating to long-term use cases (I tried to avoid those in first draft) but we can talk about which ones are interesting to the group.

[KM] Thanks for the feedback. I will modify the document to make it 
clearer for more discussion.
>-Kiran
>--
>Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide