Hello Michael I understand that you suggest to reverse the bit from my draft, so that it is set by a leaf that does not support its own routing. I agree that this minimizes the changes to the existing. But also this means that I should change RFC6775-update to specify that.
I'm happy with that approach and will do it if the WG does not disagree. What do others think? Pascal -----Original Message----- From: Roll [mailto:[email protected]] On Behalf Of Michael Richardson Sent: jeudi 22 février 2018 17:57 To: Routing Over Low power and Lossy networks <[email protected]> Cc: [email protected] Subject: Re: [Roll] A bit for ROLL Pascal Thubert (pthubert) <[email protected]> wrote: > With RPL, and probably any other route-over protocol, there is a need > to signal either way, i.e. the node handles its routing (like a > classical RPL node) or the node expects that the 6LR will manage the > routing on its behalf (like a RPL leaf). The bit is IGP-agnostic, and > it applies to any protocol. > draft-thubert-roll-unaware-leaves suggests a bit that indicates that > the 6LR that is capable to handle its routing should signal it, so the > unaware leaf does not need to set it. This *is* a new change to existing devices. > Q: Should the bit be defined in rfc6775-update as opposed to a ROLL > since it is IGP agnostic? > Side question: Is it the right approach or should the leaf set the bit > instead? I think it depends upon whether the leaf is a legacy device. We can't just plug a Windows7 PC into an arbitrary 802.15.4 network, because there generally aren't drivers. So there really isn't a legacy question. We almost always are creating new code, in which case we can create code which sets a bit which says, "Please manage my routing for me". This is not a burden, because such leaf devices do not really exist yet. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
