Hello Xavi Fully Agreed on your point in join priority.
This new thing is not a anyway, it is the expression of a willingness, aka a preference. IPv6 has introduced the concept in RAs with RFC 4191. The preference is NOT a metric, it is NOT to be confused/aggregated with the Rank; and to the 802.15.4 join priority that we derive from Rank for the time distribution, your point exactly. We are extending RFC 4191 in 2 ways: 1) to use more bits because nodes are not just selecting a router but a router within a mesh and this has consequences; also a Boolean does not allow to load balance, e.g. Hou's draft on parents selection based on number of children; 2) we are adding another value which is the Proxy Preference (is that being too rich?) If the DAG root is getting saturated (e.g. bandwidth) it should be able to signal it with lowering preferences that is propagated in DIOS. If a node is even more saturated for its own reasons (e.g. neighbor cache) it should be able to signal that with a preference that it lower than that of its parent. Balancing and saturation are relative things, we need to provide a rationalization to compare apple to apple. OF0 does exactly that for Rank. In order to throttle the join process we need something similar to express willingness to accept more joins/children in an abstract fashion. We can make the mechanism optional since the problem mostly affects large networks. But I think that we must be ready because there is a saturation point where the problem will show up and another where the join will perpetually fail. Does that make sense? Pascal I like the number, which rationalizes the willingness. We'll have to provide rules Regards, Pascal Le 21 juil. 2017 à 05:17, Xavier Vilajosana <[email protected]<mailto:[email protected]>> a écrit : 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]<mailto:[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]<mailto:[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]<mailto:mcr%[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
