Yatch, Agreed. Let's me start a different thread where I summarize your suggestion and ask for WG consensus. Thomas
On Mon, Nov 21, 2016 at 5:10 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp> wrote: > >> Sending an explicit CLEAR will speed things up, and avoid for the > >> previous preferred parent to waste energy listening to those. A > CLEAR > >> wouldn't hurt, right? > > > This is right. But, I don't think it's a SF0 job. The thing is that > SF0 > > knows nothing about RPL. > > > If SF0 provided an API to send CLEAR to a particular neighbor, RPL > > could trigger the CLEAR request to a previous preferred parent on its > > parent switch, I guess. > > Your SF0 layer could provide whatever internal API it wants to your RPL > implementation. This is hardly a standardization issue or problem; this > is a > quality of implementation issue. > > The observation of *when* RPL should clear traffic reservation may have > some > impact on the SF0 protocol, but I'd think it would be just some > implementation advice. > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
