Hi Pascal,
From: 6lo <6lo-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert) Sent: Sunday, 21 August 2022 21:45 To: Michael Richardson <mcr+i...@sandelman.ca> Cc: Alexander Pelov <a...@ackl.io>; 6lo <6lo@ietf.org> Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03 I agree about your point on BIER Michael. The cool thing with it is that it can do both unicast and multicast both with the short address. Also it will reroute on failure. I’m still thinking about whether the model is relevant in IIoT as was claimed in this thread. I have not seen that any of the tenant of the listed protocols expressed interest in this work. Can someone want a network that cannot heal? This is against all we’ve done since arpanet. Which makes it mind boggling, and worth thinking twice. In the typical IIoT case of a control loop (which typically requires a deterministic network) reroute must be real fast, faster than classical healing can happen anyway. So the various routing plans must be ready in advance and in case of a failure we’d need to instantly switch plan. So on paper this draft could be a contender for IIoT use cases, though as you point out, not without the redundant plan. And so would BIER. Just walk a tree depth first assigning a bit at each step and you have the BIER version of the assignment. [LI] Thanks. The above must be considered in the discussion about the reliability draft. Anyway I still see the proposed addresses as non IP, more like BIER or 15.4 short addresses that have to be associated to real iP so the real IP is elided in the packet. And I do not see how this matches the 6lo charter. [LI] The document explains how to go from NSA compressed address to a full IPv6 address and vice-versa. NSA addresses are IPv6 addresses. As for the charter, it states: 6lo focuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of: * limited power, memory and processing resources [LI] NSA, because of the stateless feature helps reducing memory usage (no routing table) and processing resources (no routing updates to process). * hard upper bounds on state, code space and processing cycles [LI] NSA fits these constrains as well. * optimization of energy and network bandwidth usage [LI] NSA reduce network usage because there are not routing messages and hence reduces energy consumption. Please have a look to the third paper of the workshop: https://conferences.sigcomm.org/sigcomm/2022/workshop-fira.html [LI] Note that there is no claim about “doing better than …” Wherever this work finds a home (a new WG?), [LI] The charter also state: 6lo works on small, focused pieces of work, but does not take on larger cross-layer efforts. [LI] I would say that 6lo is a small focused piece of work that does not require a whole specific WG. it will have to document requirements and show convincing uses cases, which has timidly started in this thread but with more handwaiving than actual facts - though I liked the DC sensor use case. And then confront with alternative solutions like ROLL/ BIER till the group selects the best match. [LI] We tried already to answer these questions. The comments received in this thread is going a long way in helping us improve even more the document. Thanks for all the feedback. Ciao L. Regards, Pascal Le 20 août 2022 à 22:14, Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> a écrit : Alexander Pelov <a...@ackl.io<mailto:a...@ackl.io>> wrote: I'd be happy to discuss specific scenarios/use-cases that come from a real-world need. In any case, I think these are required before accepting the draft as a WG item. Well, there really aren't any formal requirements to adopt a draft as a WG item. It's a decision reserved for the WG chairs to make in any way that they see fit. Typically, they observe a consensus that the WG wants to work on it. That means that the WG is willing to spend agenda time on the document. But, over time the Adoption call has become overly bureaucratic due to the belief that documents that are adopted MUST be published. This has resulted in the adoption call being overly litigated. See https://datatracker.ietf.org/doc/draft-carpenter-gendispatch-rfc7221bis/ for some opinions and of course RFC7221. However, like you, I am not feeling very confident that there are real use cases, and that this document it not simply the result of researchers who looked at RFC6550, did a page count and decided it must be hard and that it shouldn't be so difficult, so let's invent something new, even though we have no actual use case. That is the research institute way, where success is measured in papers published, rather than products shipped. This is not the IETF way. The IETF way is to see that there is a problem that can not be solved with existing technology, write a paper about the failures of the existing things, having tried them, and then do some experiments to see what else could be done. Write some (running) code, do experiments and then report on it in an attempt to get rough consensus. I've actually seriously considered the datacenter situation. It's a core use for ANIMA's ACP. I can unicast some presentations, but I'm not sure that I want the links public yet. I like the idea of an incrementally deployable swarm of management devices powered by the network. I have been thinking about how to do PoE in/out in a daisy chain/tree. I hadn't thought about using the 100baseT1 that the automotive industry likes. One concern that I have with NSA is that I think the network can get renumbered whenever there are new devices. -- Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ 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
