Subject: [Roll] enrollment priority

From: Rahul Jadhav <[email-masked]>
Date: Fri, 10 Apr 2020 16:34:05 +0800

Hi Michael,

Following are my thoughts about this work:

IMO, the enrollment-priority is needed for all the use-cases mentioned
in the draft and we had ourselves faced problems [1] where this could
have helped.

The draft may not give a mechanism to calculate min-priority and I
assume there won't be just a single way to calculate it. The draft can
simply mention that value of 127 means that the proxy is not available
for the join process and the draft already does this.

The draft should make it clear that the min-priority can only be
reduced or kept the same (i.e., the min-priority absolute value can
only increase, thus reducing priority) going downstream in the
sub-DODAG. For e.g., if a 6LR sets the min-priority to 10, the
downstream 6LRs can only set the value >= 10 in their min-priority.

Consider the following scenario (the attached image will help explain):
Node C's preferred parent is node B and alt parent is node A. What
happens if the min-priority of node B changes to 127 after the node C
has joined the network with B as a preferred parent? I am assuming
that the min-priority impacts only the newly joining nodes i.e., once
node B changes the priority to 127 then node C also changes the
priority to 127 and thus no new nodes join. However, the change in
node B's min-priority may not impact node C's decision to continue
using node B as the preferred parent (?). What happens when node C has
alternate parent node A whose priority is lesser than 127. Should node
C switch to node A so as to allow new downstream nodes to join the
network?

I don't believe there would be backward compatibility issues with this
new option, but the draft can clarify this explicitly.

We tried working on a problem-statement in the past in LWIG [1] which
talked about how to handle the case where some upstream nodes cache
(routing/neighbor) is full and how would it stop the new downstream
nodes to attach in that path. Enrollment priority was referenced as a
possible solution.

Best,
Rahul

[1] https://tools.ietf.org/html/draft-ietf-lwig-nbr-mgmt-policy-03

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Apr 2020 17:44:11 -0400

> C switch to node A so as to allow new downstream nodes to join the

First, I think that if node C had a MP of 127, then it would *NOT* advertise
itself as a Join Proxy.  So if it was sending Enhanced Beacons, then it
would:
  a) set proxy prio to 0x7f.
  b) maybe even stop sending EBs [have to think about this]
  c) not accept any unencrypted traffic!

so yeah, node D would be out of luck.

If node C *does* change to node A, then it would change it's priority.
But it has to do that, and maybe there are reasons why A won't accept it.

    > new option, but the draft can clarify this explicitly.

I have added:

  This document uses the extensions mechanism designed into {{!RFC6550}}.
  It does not need any mechanism to enable it.

  6LRs that support this option, but whose parent does not send it SHOULD
  assume a value of 0x40 as their base value.
  The nodes adjust this base value based upon their observed congestion,
  emitting their adjusted DIO value to their children.

(0x40 is my wet-finger-in-the-air, seat-of-the-pants guess)

    > nodes to attach in that path. Enrollment priority was referenced as a

Good.  Would more informative cross-references help?
Do you want to co-author?

--
]               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]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Sat, 11 Apr 2020 07:49:19 +0000

Please find my resps inline.

Best,
Rahul

________________________________

itself as a Join Proxy.

[RJ] Consider non-6tisch case, where the 6LR's resources are full and does not want any new nodes to connect to it. In this case, it still needs to advertise its DIO for all the existing nodes which have already joined through it. The new nodes will see MP=127 and hence won't join. But the gist is, Node C has to keep advertising for all its existing nodes. It cannot stop sending DIOs.

So if it was sending Enhanced Beacons, then it
would:
  a) set proxy prio to 0x7f.
  b) maybe even stop sending EBs [have to think about this]
[RJ] Not sure in case of 6tisch too if it can stop sending EBs? Since it may be needed for existing nodes who have already joined.
  c) not accept any unencrypted traffic!

[RJ] Sure node A might have its own reasons to not accept it, but the MP suggests that it is willing to accept node C. The problem is when node C switches to Node A, the whole sub-DODAG rooted at C switches and this may result in node A's MP to reach 127. Since node B is now free, it's MP value will decrease. This can result in oscillations in the network.
At the very least these scenarios can be provided to the reader and if possible some mechanism/guideline to handle it.

I have added:

[RJ] Consider that a 6LR who does not support MP gets a DIO with MP=127. The 6LR will ignore the MP field and sends it DIO without MP and the downstream nodes will assume an MP of 0x40! This may be a problem.

Good.  Would more informative cross-references help?
Do you want to co-author?
[RJ] Yes, I would love to work on this problem statement.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Apr 2020 08:40:45 -0400

{sorry, this email sat unsent for too long}

    >> C switch to node A so as to allow new downstream nodes to join the

    mcr> First, I think that if node C had a MP of 127, then it would *NOT* advertise
    mcr> itself as a Join Proxy.

    RJ> Consider non-6tisch case, where the 6LR's resources are full and does
    RJ> not want any new nodes to connect to it. In this case, it still needs
    RJ> to advertise its DIO for all the existing nodes which have already
    RJ> joined through it. The new nodes will see MP=127 and hence won't
    RJ> join. But the gist is, Node C has to keep advertising for all its
    RJ> existing nodes. It cannot stop sending DIOs.

Okay, so I think that we have further confusion of Join (DODAG thing) vs
Enroll (onboarding thing) :-)
I have taken another pass through the document to make sure that all uses of
join, other than "Join Proxy" now say Enroll.

    mcr> So if it was sending Enhanced Beacons, then it
    mcr> would:
    mcr> a) set proxy prio to 0x7f.
    mcr> b) maybe even stop sending EBs [have to think about this]

    RJ> Not sure in case of 6tisch too if it can stop sending EBs? Since it
    RJ> may be needed for existing nodes who have already joined.

Yes, it probably needs to continue sending EBs.

    mcr> If node C *does* change to node A, then it would change it's priority.
    mcr> But it has to do that, and maybe there are reasons why A won't accept it.

    RJ> Sure node A might have its own reasons to not accept it, but the MP
    RJ> suggests that it is willing to accept node C. The problem is when
    RJ> node C switches to Node A, the whole sub-DODAG rooted at C switches
    RJ> and this may result in node A's MP to reach 127. Since node B is now
    RJ> free, it's MP value will decrease. This can result in oscillations in
    RJ> the network.

Agreed.
The fundamental problem is that the sub-DODAG needs to be split.
I don't think that we can do that in this option or in EBs.
It has to be done in DIOs and DAO-ACKs and...
I think that we have had proposals to deal with this before (what happened to
them?)

    > (0x40 is my wet-finger-in-the-air, seat-of-the-pants guess)

    RJ> Consider that a 6LR who does not support MP gets a DIO with
    RJ> MP=127. The 6LR will ignore the MP field and sends it DIO without MP
    RJ> and the downstream nodes will assume an MP of 0x40! This may be a
    RJ> problem.

I added some analysis to my slides today to deal with this.
I am open to other values, but I think we need to pick some value. Maybe 0,
but I think not.  Maybe rank * VALUE.

    > Do you want to co-author?

    RJ> Yes, I would love to work on this problem statement.

https://github.com/roll-wg/draft-ietf-roll-enrollment-priority
I will unicast to get permissions right.