Subject: Re: [Iotops] Fwd: I-D Action: draft-iotops-km-iiot-frwk-00.txt

From: "Kiran Makhijani" <[email-masked]>
Date: Fri, 12 Nov 2021 12:44:34 +0000

Hi Michael,
Sincere apologies, somehow I did not see this email until now. Maybe a 
config-error with my inbox filters.

Your point is well taken and to be honest I struggled myself on how much 
detail should go in -  whether it is too much or too little. But I had 
to start somewhere. That is why,  there is nothing as a proposal, but 
some place holders and exposing different areas.

Section 5, just draws an architectural view, I tried to map IIoT levels 
to interfaces. This is where exchange of protocols and security occurs 
and help us normalize how traffic could flow in and out of a factory 
floor. One example, would highlight what (how) existing solution such as 
Detnet  edge/cloud cases come into play. Secondly, the network on the 
Industry zone itself - I had written this in previous document andI did 
not copy over (just yet). Third, there is an endpoint/device aspect its 
onboarding, addressing, trust etc.

I will try to raise this during IOTOPS, and accordingly progress the 
document.

-Kiran

------ Original Message ------
From: "Michael Richardson" <[email-masked]>
To: "Kiran Makhijani" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 10/26/2021 10:25:11 AM
Subject: Re: [Iotops] Fwd: I-D Action: draft-iotops-km-iiot-frwk-00.txt

>
>Kiran Makhijani <[email-masked]> wrote:
>     > As per the feedback from last meeting, we came up with a sketch of
>     > framework for Industrial networks. We hope to have more discussions and
>     > receive feedback on this document.
>
>Last time, we were discussing:
>      I-D.draft-km-industrial-internet-requirements
>
>I have reviewed the "iiot-frwk" document, but I don't really know what you
>intend to do with it.  You've described a whole bunch of pieces, but I can't
>really see a proposal in that satisfies:
>
>from your abstract:
>     > It suggests the use
>     > of IIN to bridge the differences between OT and IETF technologies.
>
>Section 5 deals with this, but if you intend to propose something, I've
>missed it.
>
>--
>Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Nov 2021 13:57:01 -0500

Kiran Makhijani <[email-masked]> wrote:
    > Hi Michael, Sincere apologies, somehow I did not see this email until
    > now. Maybe a config-error with my inbox filters.

(Google hates my SMTP sender, and puts a lot of stuff in spam now.)

    > Your point is well taken and to be honest I struggled myself on how
    > much detail should go in - whether it is too much or too little. But I
    > had to start somewhere. That is why, there is nothing as a proposal,
    > but some place holders and exposing different areas.

    > to interfaces. This is where exchange of protocols and security occurs

I had suggested that having a way to map IPv6 IID's (the lower 64bits) to
these other legacy systems, e.g. Modbus, Profibus, CANbus, Profinet...
so that all end points could be addressed from an IPv6 backbone via gateway
systems.   I think that would be useful work, but really, it needs to be done
along *with* someone building those gateways. ("running code")

Your document claims that tunneling these other things across ethernet/IPv6
would be too much overhead.  I strongly disagree, given Gigabit Ethernet,
it's just not an issue when the legacy transports are in the kilobit or less.
This mapping could/should be coordinated with DETNET, and I'll be that that
there people there who want to do this.

For things like Ether/IP which is strongly IPv4 focused, NAT64 *into* that
network provides a very nice way to distribute and connect networks while not
introducing weird default routes into those networks. (that's because NAT64
translates to an IPv4 address that is IPv4 on-link)

---

From: "Kiran Makhijani" <[email-masked]>
Date: Fri, 19 Nov 2021 01:41:43 +0000

Hi Michael,
Please see inline. Yes, use of IID is a good starting point.
Cheers,
Kiran

------ Original Message ------
From: "Michael Richardson" <[email-masked]>
To: "Kiran Makhijani" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 11/17/2021 10:57:01 AM
Subject: Re: Re[2]: [Iotops] Fwd: I-D Action: 
draft-iotops-km-iiot-frwk-00.txt

>systems.   I think that would be useful work,
Yes, I like the idea of mapping type/plc/devices to IID. For an 
industrial network, it gives us enough room to provide PLC & device 
binding. It definitely does tunnel free connectivity. With gateway, you 
mean the border gateway - the boundary of factory floor - the traffic 
flow out of a cite. Am I right?

>but really, it needs to be done
>along *with* someone building those gateways. ("running code”)

While "running code” at least on linux-type POC, should not be too 
difficult once we have a proper encoding format. The hard part is 
finding interest from those building such gateways.
>there people there who want to do this.
It’d depend on the design.  imagine on a factory floor you end up adding 
new health check and security sensors without really upgrading the 
bandwidth and routers. Each sensor emits a byte of information at 
regular intervals. We’d be burning 20-40 bytes of header to ship one 
byte of data. If remote visual inspections using cameras and advanced 
media technologies take off, then there is a high volume of real-time 
data.
>translates to an IPv4 address that is IPv4 on-link)
It could. But then we will have 2 things at the boundary protocol - IID 
and NAT64. May be we can build on IID first, and see if the need for 
NAT64 comes up (a personal preference for non-NATed solution)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Nov 2021 14:30:00 -0500

> Yes, I like the idea of mapping type/plc/devices to IID. For an industrial
    > network, it gives us enough room to provide PLC & device binding. It
    > definitely does tunnel free connectivity. With gateway, you mean the border
    > gateway - the boundary of factory floor - the traffic flow out of a cite. Am
    > I right?

No, I mean a gateway between the legacy systems and the IPv6/ethernet
backbone that connects parts of the factory together.  It could, yes, at the
boundary of the factory, but it could also be within the factory.

    > While "running code” at least on linux-type POC, should not be too difficult
    > once we have a proper encoding format. The hard part is finding interest from
    > those building such gateways.

Yes, the point being, if there isn't demand for such a thing, then
maybe don't write the spec.

    > It’d depend on the design.  imagine on a factory floor you end up adding new
    > health check and security sensors without really upgrading the bandwidth and
    > routers. Each sensor emits a byte of information at regular intervals. We’d
    > be burning 20-40 bytes of header to ship one byte of data. If remote visual
    > inspections using cameras and advanced media technologies take off, then
    > there is a high volume of real-time data.

I don't understand the for instance.
If the new sensor is a modbus/profibus/canbus, then it would live behind such
a gateway.
If the new sensor is IP, then there would be no tunnel.
It's only if you have a (new) need for some sensor behind (say) modbus
gateway A, to talk to an actuator behind modbus gateway B.  The distance is
too far for the modbus, so the gateways encapsulate over ethernet.
Modbus runs over RS232 and 432, and has speeds in the 100kbs maximum.
That would hardly tax a switched GbE.
And Modbus already has versions that run over TCP, and IP.

    > It could. But then we will have 2 things at the boundary protocol - IID and
    > NAT64. May be we can build on IID first, and see if the need for NAT64 comes
    > up (a personal preference for non-NATed solution)

The point of the NAT64, is to embed IPv6 to IPv4, so the two things are not
seperable, if embedding multiple RFC1918 networks into a single IPv6
management space is going to be done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [