Re: [Roll] enrollment priority

[Michael Richardson <[e-mail]>]

I am resuming a thread that got lost back in April.
My todo list included adding Rahul as a co-author .  I have confirmed 
that the github contains permissions.

Let me clip down to what was the critical points:

On 2020-04-29 8:40 a.m., Michael Richardson wrote:
>      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.

In the process I was reminded that I-D.ietf-6tisch-minimal-security is 
stuck waiting on unaware-leaves and core-stateless.  I wonder if we 
could s/Join Proxy/Enrollment Proxy/ on that document as an AUTH48.

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

I glanced at draft-ietf-lwig-nbr-mgmt-policy-03.  I would guess it 
expired due to lack of time.  It seems like good work.  I'm not 
convinced we shouldn't be doing this in ROLL instead.
I know that we had presentations some year ago where there was 
stampeding elephants... I'm not sure what happened to those documents.

I am concerned about boiling ocean here: I don't think that I have 
enough clue to solve balancing the DODAG after enrollment.


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

I am open to other suggestions rather than 0x40 (64) as a default value 
when there is a failure in the middle of the dodag to support this 
option.  I think that it's a rather small edge case, but if we can solve 
it better, great.

> 
>      >> 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.
> 
> https://github.com/roll-wg/draft-ietf-roll-enrollment-priority
> I will unicast to get permissions right.

I have posted -03.
Rahul, you should have full permissions on the above repo.
I'm not sure if the problem you want to work on is the restricted 
enrollment problem, or the wider DODAG tree balancing.