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. 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. Wherever this work finds a home (a new 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. Regards, Pascal Le 20 août 2022 à 22:14, Michael Richardson <mcr+i...@sandelman.ca> a écrit : Alexander Pelov <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> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
signature.asc
Description: signature.asc
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
