Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Luigi IANNONE <[e-mail]>]

From: 6lo <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, 23 August 2022 08:57
To: Kiran M <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

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.

[LI] Addressing can follow topology or topology can follow addressing (y. Rekhter) :-)

The above is a constrain indeed.


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.

[LI] That is correct. But NSA never claimed to replace anything, Just stating that in some scenarios may bring benefits.
We are creating an issue from nothing…




And the resulting L3 header is larger since the IP address is still not fully elided. So on paper, NSA yields larger IP headers.

[LI] But does not require routing tables or routing messages. We will delete claim about better header compression.



This is why my view is that the proposed benefit is mostly the automatic routing.

[LI] “Forwarding” not routing ;-)

Which yields operational issues upon changes.

[LI] That is true. It is stated in the document. We also state that in some scenarios routing would be a better fit.
Hence the reliability document.

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.

[LI] Merry Xmas :-)
Yes, the benefits show up in specific type of networks, and some people have interest in those networks. I do not see the issue here.


This is a very specific type of L2, and NSA could be the way that L2 operates mesh under.

[LI] Interesting use case. But this is not where we are aiming.

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,

[LI] From the beginning we agreed that NSA has a specific applicability scope, that you helped to frame. So, you statement is correct but I do not see why you are brining this up since we did not claim the contrary.


and no inclined to add RFCs to the pile, so it’s only harder to converge on one.

[LI] If there are people willing to carry out some work you do see as worth to be done It does not mean “pile up RFCs” it mean having different interests.
The number of RFCs is not a dimension on which evaluate WG adoption of documents, especially if there is no such policy in the IETF.

6LoWPAN was successful in defining one protocol that 6lo could adapt to many networks. That’s the power of one.

[LI] 6LoWPAN is an excellent protocol. The charter does not mandate 6lo to work on one solution, rather the contrary (see the excerpt I put above).
6LoWPAN remain the general solution. Just provide a solution that bring benefits it its own applicability scope.
I assume you would like this last part to be even better explained in the document, which we can certainly do.

Thanks

Ciao

L.



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 <[e-mail]<mailto:[e-mail]>>
Sent: mardi 23 août 2022 7:02
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]><mailto:[e-mail]> On Behalf Of Kiran Makhijani
Sent: mardi 16 août 2022 2:08
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Monday, August 1, 2022, 7:58 AM
To:[e-mail]<mailto:[e-mail]>
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

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

https://www.ietf.org/mailman/listinfo/6lo