[Roll] Proposed changes to roll-enrollment-priority to reflect major points of our discussion (PR #14)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 10 February 2022 16:55 UTC

From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <CADPqcJ+nODjV5C9xdtT=POh=jXvmGz2WYEwXAimF9kJjnk27CA@mail.gmail.com>
References: <roll-wg/draft-ietf-roll-enrollment-priority/pull/14@github.com> <roll-wg/draft-ietf-roll-enrollment-priority/pull/14/c1032184406@github.com> <CADPqcJ+nODjV5C9xdtT=POh=jXvmGz2WYEwXAimF9kJjnk27CA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 10 Feb 2022 11:55:46 -0500
Message-ID: <19341.1644512146@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/dPfa2i2ysGkTGtvKgpSCFHaKTzA>
Subject: [Roll] Proposed changes to roll-enrollment-priority to reflect major points of our discussion (PR #14)
Precedence: list

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 <pascal.thubert@gmail.com> 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   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

Attachment: signature.asc

Re: [Roll] [roll-wg/draft-ietf-roll-enrollment-pr… Pascal Thubert
[Roll] Proposed changes to roll-enrollment-priori… Michael Richardson
Re: [Roll] Proposed changes to roll-enrollment-pr… Michael Richardson

[Roll] Proposed changes to roll-enrollment-priority to reflect major points of our discussion (PR #14)

Attachment: signature.asc