Thanks Kiran; My view is that IPv6 must smoothly / silently adapt to the network as it exists, which is something that SCHC can help happen. 6LoWPAN can implicitly derive the IPv6 address from the 8 or 16 bits address, that’s the base of the design, with a resulting very short header; in that case the IPv6 address can be fully elided.
OTOH, NSA forces 1) a tree structure and 2) the addresses along that structure. This places constraints on the OT network and that may deter adoption in some cases. So on paper, NSA has a lower adoption field than 6LoWPAN. And the resulting L3 header is larger since the IP address is still not fully elided. So on paper, NSA yields larger IP headers. This is why my view is that the proposed benefit is mostly the automatic routing. Which yields operational issues upon changes. So it’s a pro/cons. I see the pro winning in a very constrained / very specific type of wired sensors, like Xmas tree lights where you replace the lights with sensors. This is a very specific type of L2, and NSA could be the way that L2 operates mesh under. Note that I do not oppose encoding a source route header in an IP address. SRv6 might do that in some fashion. I’m just no convinced that it beats 6LoWPAN in the general case, and no inclined to add RFCs to the pile, so it’s only harder to converge on one. 6LoWPAN was successful in defining one protocol that 6lo could adapt to many networks. That’s the power of one. This is how we got adoption with Wi-Sun, Thread, ISA100.11a, you name it. With NSA, we’d dilute this power for a L2 network that is not even clearly identified? All the best; Pascal From: Kiran M <kiran.i...@gmail.com> Sent: mardi 23 août 2022 7:02 To: Pascal Thubert (pthubert) <pthub...@cisco.com>; carle...@entel.upc.edu; 6lo@ietf.org Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03 Hello Pascal, My apologies for late reply (I am taking some time off). Since I last wrote, thread has progressed quite a bit. Anyways...· What attracted my attention is the header structure in Figure 6. It is often the case that field devices are smaller 8-bit or16-bit addresses connected to a PLC. The general practice today is to encapsulate device address and function code/command to an actuator over TCP. This is an indirect communication to the actuator. I thought it would be interesting if we could directly address the device and send the command over. By having topological structure, one benefit is that association to PLC or controller will always be there due to parent/child relationship in this address structure. This gives us savings of bits on wire, on both address and payload, because if the actuator is directly addressed, the payload only contains the command. When an OT operator sees this device in an HMI or SCADA systems, they see direct actuator's address, without any mapping. It is my personal opinion (I maybe wrong) that IPV6 as is will be an overkill for factory floors. Moreover, I like the asymmetry in the header that source and destination can be variable length - the server above could be IPv6 in the IT world, and actuator could be NSA in OT world. I find NSA type of mechanisms give better fine-tuning of limited domain industrial networks. With regards to SCHC, maybe it is a better approach but I do not know enough. Two potential benefits over SCHC maybe that the operator need not assign an IPV6 address to actuators/field devices; second, since we know that the shop floor topology and actuator's location do not change, no need to maintain the state... but I am just guessing. Having said that, many forwarding related questions came up, which I should be dealt separately and some are already raised. - Kiran On 8/16/2022 1:42 PM, Pascal Thubert (pthubert) wrote: Hello Kiran Note that the core of the work is an autoconfiguration model along a fixed tree structure, and the desired “side effects” are implicit routing and short addresses. For short addresses, we already have SCHC and 6LoWPAN so that would not be a sufficient argument. Now, I do not see how your point on IIoT matches this specification. Since a main objection (though not the only one) is the lack of applicability, this may help. Could you please elaborate? In particular, which industrial protocol would benefit from this automatic assignment of IP addresses (vs. Say, mapping the protocol address into an IID or something)? Many thanks in advance; Pascal From: 6lo <6lo-boun...@ietf.org><mailto:6lo-boun...@ietf.org> On Behalf Of Kiran Makhijani Sent: mardi 16 août 2022 2:08 To: carle...@entel.upc.edu<mailto:carle...@entel.upc.edu>; 6lo@ietf.org<mailto:6lo@ietf.org> Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03 Hello, I have quickly skimmed through the document and would like to see this work progress. I see that the focus is mainly on wireless constrained devices, however, in industrial networks with field devices it is useful to have short and variable addressing schemes on a factory floor. Variable addressing approach is more interesting here because, on one side the controllers may use IPv6 addresses and field-devices on the other end can very well be shorter addresses. I support this document and wouldn't mind contributing to the alignment with above mentioned scenario. Cheers, Kiran ________________________________ From: Carles Gomez Montenegro [mailto:carle...@entel.upc.edu] Sent: Monday, August 1, 2022, 7:58 AM To:6lo@ietf.org<mailto:6lo@ietf.org> Subject: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03 Dear 6lo WG, This message starts a call for WG adoption for draft-li-6lo-native-short-address-03. (Link below: https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-03) Considering that some folks may be on vacation currently or in the next few days, the call will end on the 22nd of August, EOB. Please state whether you are in favor of adopting this document. Also, any comments you may have, and/or expressions of interest to review the document, will be very much appreciated. Thanks, Shwetha and Carles _______________________________________________ 6lo mailing list 6lo@ietf.org<mailto:6lo@ietf.org> https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
