"Liguangpeng (Roc, Network Technology Laboratory)" asked me to review draft-li-6lo-native-short-address-00 and to post to 6lo.
> update the draft a lot and get support from China Mobile.
but since this is yet another constrained network protocol, are there
commitments to write code?
For OpenWSN, Contiki-NG, RIOT-OS, Linux, *BSD, FreeRTOS, Thread...?
I see in your draft that you have comparison against current 6lowpan, and
that it is a few bytes shorter, but I didn't yet read deep enough to
understand how often it is shorter, and if there were cases that were simply
not supported, or if they wind up longer.
I see the bit pattern at the beginning that means it could operate in the
same network as 6lowpan, but it seems that every node that forwards will need
to understand the new format before it can be turned on.
It seems really late in the day for a new mechanism.
> Thirdly and most importantly, to avoid drawbacks brought by
> renumbering, we added a new mechanism to avoid the renumbering during
> the topology change, by adding/updating routing entries along the
> affected path. The cost is comparable with the local repair of
> RPL. Routing related procedures is refined according to this design,
> see Section 5, 6 and 8.
I'm unaware of a large need to renumber.
Maybe that's a result of lack of IPv6 deployment.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
