On Oct 13, 2009, at 01:44, Geoff Mulligan wrote:
a simple star is not not two-node 6lowpan. I have a seen and used a simple star lowpan that was able to cover an entire house (10+ nodes) and 4861 would have worked just fine here.
If "simple star" means that every node can only reach a hub node and v.v., then 4861 does not "work".
If "simple star" means everyone can reach everyone (radio full mesh connectivity in the n*(n-1) sense without needing a mesh routing protocol), then 4861 works fine, until there is an impairment between two nodes.
If "simple star" means the hub relays all packets that need to reach other nodes (e.g., using the 6lowpan mesh header), then yes, 4861 works. Still, 6lowpan-nd would reduce the burden on all nodes involved (code size, multicast traffic), except for the quite small increase in code size on the edge router (hub, I presume).
The engineering tradeoffs are seriously arguing against burdening constrained nodes with 4861. We can't have it both ways: allow "flexibility" (by letting nodes choose between 4861 and 6lowpan-nd) and interoperability. Since 4861 breaks down as soon as the lowpan starts to get a little more complicated, it is a bad decision to retain 4861 just out of nostalgia.
This whole discussion only makes sense if you somehow believe 4861 to be simpler than 6lowpan-nd. Not so.
Discarding the 4861 option for intra-lowpan use is not a "problem", it is a welcome reduction in complexity.
It all comes down to a lesson some of us have learned the hard way: options create complexity, interoperability problems, and considerable cost. Avoid options at all cost!
Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
