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 a écrit :
Alexander Pelov 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. 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
