Subject: Re: [Roll] [roll-wg/draft-ietf-roll-enrollment-priority] Propose changes to reflect major points of our discussion (PR #14)

From: Pascal Thubert <[email-masked]>
Date: Tue, 8 Feb 2022 11:12:49 +0100

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 <[email-masked]> 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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Feb 2022 11:55:46 -0500

I want to alert the list fo the discussion that is occuring at:
   https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14

Pascal has wisely decided to reply by email, and CC'ed the list, and I'd
prefer that we continued on the list.

Rahul wrote in the github:
> Also, I am having second thoughts about not allowing the 6LRs to modify
> min-priority. My primary use-case for this draft is no more
> supported. Following is my use-case:

> Consider that we have a homogenous deployment (deployment with all nodes
> having similar resources) and let's say those resources are "relatively"
> constrained.

> For e.g., in my practical deployment I had space for 50 neighbor entries
> and 50 routing entries. I had to cut-off nodes joining a 6LR if that 6LR
> already has crossed the threshold of 40 entries.

> With this draft, I was hoping to set the min-priority at the 6LR to block
> others from joining "this 6LR", but other 6LRs could have been
> available. With relatively constrained nodes and sufficiently dense
> deployment, this condition is always produced.

Pascal has asked on the list whether we are trying to fix something in RPL
that is really about NCE exhaustion:

Pascal Thubert <[email-masked]> wrote:
    PT> RPL should not be tweaked to fix ND problems. If you problem is a number of
    PT> neighbors then we need to look at how you use RFC 8505 and whether
    PT> something is missing there.
    PT> What you can already do is trial and error. the 50th child sends a NS(EARO)
    PT> and the parent rejects with a bad status. Sadly we have
    PT> "

...

    PT> Also we are missing the capability to indicate in the RA that the NCE is
    PT> getting saturated.
    PT> Maybe all that deserves a draft at 6lo?

But, if we are doing Storing mode RPL (and maybe in the future of PDAO that
will die), then it's not just NCE exhaustion that is the problem.  It's a
combination of NCE exhaustion and routing entries up the DODAG to the root
that the issue.  That's why we needed for any 6LR to make itself less
desireable for new devices.

I wonder if we really have two problems, which calls for two different
solutions?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Feb 2022 14:59:06 -0500

> https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14

To simplify what text is being discussed, I've accepted all of Konrad's
editorial comments into the main github branch.

At this point, I wonder if we shouldn't have two options:

> 1. propagating base priority settings in the DODAG,
> 2. advertising the actual priorities of individual nodes.