> > > The TID can fit in "reserved" field of ARO/DAR/DAC and thus can come > > at no cost. > > FWIW Complexity is the true cost, because unneeded complexity leads to > non-interoperability for no benefit. > > > Thanks to the lollipop mechanism defined in 6lowpan-nd-07 the TID can > > be implemented even in the most constrained devices which might not be > > able to consistently increment the TID. > > The lollipop stuff is not proven technology. It existed in an early draft of > OSPF, and was replaced. I assume it was replaced for a reason. > [Pascal] that's FUD. OSPF does not use lollipop because it is not the appropriate tool, not because it is a bad tool. Lollipop has evolved. RPL has one that avoids the well-known pitfalls like s1<s2<s3<s1.
> Any proven TID scheme would require stable storage on the device, so that > the device doesn't accidentally reuse old TIDs too soon. I don't think we want > to require that capability on all 6lowpan hosts, just because it is perceived too > hard to have RPL keep track of things. [Pascal] Nicolas 's point exactly. If the user of the TID has an appropriate mechanism (like a modern lollipop) then the device is allowed to reboot and loose states. So we are not requiring persistent memory. And you can't just avoid something simple in the host by pushing something undeterminably complex in the router, because a RPL router is usually the exact same hardware with the same constraints as the host. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
