Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]

["Pascal Thubert (pthubert)" <[e-mail]>]

> 
> > 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