Re: [Roll] enrollment priority

[Rahul Jadhav <[e-mail]>]

Please find my resps inline.

Best,
Rahul

________________________________

    > 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?

First, I think that if node C had a MP of 127, then it would *NOT* advertise
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!

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.

[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 don't believe there would be backward compatibility issues with this
    > 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)

[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.

    > 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.

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