Closed konrad-iwanicki closed 1 year ago
Regarding the scenario -- I don't know if I got it correctly -- but if you wanted to cut off nodes joining specific 6LRs (e.g., those having 40 neighbor entries or more), you could have such 6LRs advertise a maximal value (0x7f) of their Enhanced Beacon Join priorities. You need not change the global min priority for that. Or did I misunderstood your example?
Regarding the scenario -- I don't know if I got it correctly -- but if you wanted to cut off nodes joining specific 6LRs (e.g., those having 40 neighbor entries or more), you could have such 6LRs advertise a maximal value (0x7f) of their Enhanced Beacon Join priorities. You need not change the global min priority for that. Or did I misunderstood your example?
Enhanced Beacon Join priorities works only for 6tisch scenarios. RPL has multiple different link layers it works for. They all face similar issues. My deployment scenario was using 802.15.4 link layer without tisch.
OK, now I understand. In this case, the option would have to play a dual role:
From what I concluded from our discussions and the text of the draft, the draft aims to solve only the first problem. Hmmm... I don't know if addressing both with a single priority value, or even a single option, is the way to go.
Hello Rahul
RPL should not be tweaked to fix ND problems. If you problem is a number of neighbors then we need to look at how you use RFC 8505 and whether something is missing there. What you can already do is trial and error. the 50th child sends a NS(EARO) and the parent rejects with a bad status. Sadly we have "
6LBR Registry Saturated
" but not "
6LR Registry Saturated
" Also we are missing the capability to indicate in the RA that the NCE is getting saturated. Maybe all that deserves a draft at 6lo?
Pascal
Le mar. 8 févr. 2022 à 04:46, Rahul Jadhav @.***> a écrit :
Regarding the scenario -- I don't know if I got it correctly -- but if you wanted to cut off nodes joining specific 6LRs (e.g., those having 40 neighbor entries or more), you could have such 6LRs advertise a maximal value (0x7f) of their Enhanced Beacon Join priorities. You need not change the global min priority for that. Or did I misunderstood your example?
Enhanced Beacon Join priorities works only for 6tisch scenarios. RPL has multiple different link layers it works for. They all face similar issues. My deployment scenario was using 802.15.4 link layer without tisch.
— Reply to this email directly, view it on GitHub https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14#issuecomment-1032184406, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYHN4I6W6SD7S3M4QJ3IY3U2CGZFANCNFSM5NXM4HUQ . You are receiving this because you are subscribed to this thread.Message ID: <roll-wg/draft-ietf-roll-enrollment-priority/pull/14/c1032184406@ github.com>
-- Pascal
My bad. I think this was also brought to attention during our last interim/session. I was in a way disappointed that the use-case for which I looked upon this draft is no longer satisfied. But I also get the point that maybe RPL should not solve the ND related issue.
On Tue, 8 Feb 2022 at 15:43, Pascal Thubert @.***> wrote:
Hello Rahul
RPL should not be tweaked to fix ND problems. If you problem is a number of neighbors then we need to look at how you use RFC 8505 and whether something is missing there. What you can already do is trial and error. the 50th child sends a NS(EARO) and the parent rejects with a bad status. Sadly we have "
6LBR Registry Saturated
" but not "
6LR Registry Saturated
" Also we are missing the capability to indicate in the RA that the NCE is getting saturated. Maybe all that deserves a draft at 6lo?
Pascal
Le mar. 8 févr. 2022 à 04:46, Rahul Jadhav @.***> a écrit :
Regarding the scenario -- I don't know if I got it correctly -- but if you wanted to cut off nodes joining specific 6LRs (e.g., those having 40 neighbor entries or more), you could have such 6LRs advertise a maximal value (0x7f) of their Enhanced Beacon Join priorities. You need not change the global min priority for that. Or did I misunderstood your example?
Enhanced Beacon Join priorities works only for 6tisch scenarios. RPL has multiple different link layers it works for. They all face similar issues. My deployment scenario was using 802.15.4 link layer without tisch.
— Reply to this email directly, view it on GitHub < https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14#issuecomment-1032184406 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABYHN4I6W6SD7S3M4QJ3IY3U2CGZFANCNFSM5NXM4HUQ
. You are receiving this because you are subscribed to this thread.Message ID: <roll-wg/draft-ietf-roll-enrollment-priority/pull/14/c1032184406@ github.com>
-- Pascal
— Reply to this email directly, view it on GitHub https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14#issuecomment-1032436309, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFVZK5KT6NA7IF6GAEKKGLU2DUDRANCNFSM5NXM4HUQ . You are receiving this because you commented.Message ID: @.*** com>
To reduce the churn, I've accepted all the typos and small edits from Konrad into the main/master branch of the document. Konrad, if you could rebase, that should show just your proposed changes to the option format.
I somehow failed to rebase because of conflicts, but did another pull request on top of the master:
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/15
That should be better.
I think that this is included in #15, so closing this.