Hi Michael, In the EB, there is an Information Element described in 15.4 (Synchronization IE) that contains a field named Join Metric (in version 2012 was named Join Priority). I think would be good to change the name of the field to avoid any misunderstanding, considering that this also goes inside an IE in the EB.
I have also a question, why not a simple binary option to decide if a node accepts Join or not? Having a range and having the nodes calculate a value in that range and decide whether join or not seems a little bit fuzzy. Would be easier just saying yes or no? What would mean a Join Priority of 0x7e vs another node advertising 0x2a? How to choose and what is the actual meaning of lower priority different than 0? sorry if I have misunderstood your point. regards, 2017-07-19 11:59 GMT+02:00 Michael Richardson <[email protected]>: > > In draft-richardson-6tisch-join-enhanced-beacon-02, I changed the > Join Proxy from a bit to a priority. (lower numbers are better) > I also removed the "I"nitate bit. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TBD-XXX |R|join priority| network ID | > +-+-+-+-+-+-+-+-+-+-+-+---------+ | > > J the Join prority value contains a number from 0 to 0x7f. Lower > > As discussed on Monday, having a way for the DODAG root to influence > whether the Join Proxy is enabled or not seems like a good thing. > > Here is the core text of roll-join-priority: > > A 6LR which would otherwise be willing to act as a Join Proxy, will > examine the minimum priority field, and to that number, add any > additional local consideration (such as upstream congestion). The > resulting priority, if less than 0x7f should enable the Join Proxy > function. > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD01|Opt Length = 1|R| min. priority | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The document has some strawman text about how/if/when the min.priority > might be updated. (Slightly confusing in this email, the "R" in the first > diagram is "Router Advertisement", while just above here, it is "Reserved") > I made the min.priority 7 bits since the join priority is 7 bits. > > I was also thinking this morning that maybe it could be 8-bits, but be > signed? > > These documents could be combined, and I would suggest that if there was > no thought that the first one (enhanced-beacon) might be turned over the > IEEE. Perhaps Pascal could explain that comment from Monday. > > > [email protected] wrote: > > A new version of I-D, draft-richardson-6tisch-roll- > join-priority-00.txt > > has been successfully submitted by Michael Richardson and posted to > the > > IETF repository. > > > Name: draft-richardson-6tisch-roll-join-priority Revision: 00 Title: > > Enabling secure network join in RPL networks Document date: > 2017-07-18 > > Group: Individual Submission Pages: 6 URL: > > https://www.ietf.org/internet-drafts/draft-richardson- > 6tisch-roll-join-priority-00.txt > > ... > > > Abstract: [I-D.richardson-6tisch-join-enhanced-beacon] defines a > method > > by which a potential [I-D.ietf-6tisch-minimal-security] can announce > > itself as a available for new Pledges to Join a network. The > > announcement includes a priority for join. This document provides a > > mechanism by which a RPL DODAG root can disable join announcements, > or > > adjust the base priority for join operation. > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
