Re: [Roll] enrollment priority

[Michael Richardson <[e-mail]>]

let me collect replies into a single response.
I've also opened issues in github.

Konrad Iwanicki <[e-mail]> wrote:
    > As we discussed throughout the mailing list, we also need a sequence
    > number so that correct values of DODAG_Size and min_priority are
    > adopted. This in turn requires putting more information in the draft on
    > the rules of adopting the values. They are explicitly formulated in my
    > earlier e-mail about GLOBAL vs FLEXIBLE.

I thought that we needed a lollipop counter only if the values were going to
be different in different places in the DODAG.

Pascal Thubert (pthubert) <[e-mail]> wrote:
    > Please see
    > https://datatracker.ietf.org/doc/minutes-interim-2021-roll-02-202108311800/

I see that I agreed we need another lollipop counter, and I'll add that to
the document.  Is there text is another non-RFC6550 that I should use as
best-of-breed to explain the counter?

    > (https://mailarchive.ietf.org/arch/msg/roll/2MaZ4wXLVzJbmLC-LO6c--DsbWQ/)
    > I do not see a use case for it, so it looks like overdesign but I'm
    > open to be convinced otherwise

okay.

Konrad Iwanicki <[e-mail]> wrote:
    > - How do changes to min priority (and OSN) affect DIO Trickle timers?
    > [OSN == the lollipop sequence counter]

I think that if we have the counter, that increments the OSN reset the trickle
timer, but Pascal suggests an additional bit to reset the trickle?
Maybe I'm lost here.
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/13


Konrad> OK. This seems reasonable. I would thus recommend that the draft
Konrad> contain explicit rules REQUIRING the bit to be set when min priority
Konrad> changes from: 
Konrad>   - anything else to max (denoting saturation) 
Konrat>   - max to anything else as these changes would normally by the ones
Konrat>   that should be propagated fast.

We can certainly build these rules into enrollment priority option.
But, I wonder if resetting trickle has general application, and should actually be
signaled by inclusion of a new DIO option.  That removes the above implicit
logic from the nodes and moves it to the root.
(And invokes the adage about "naming and cache invalidation" being the hard problems)
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/12

    > - How does a (temporal) lack of a preferred parent affect the proxy
    > priority of the node in EBs (and in general, the node's behavior)?

If the node can't send traffic up to the root, then I think that it should
turn off EBs until it can.
In a 6tisch situation, it is likely that the lack of a preferred parent is
probably due to falling out of the schedule.

Pascal> A node that does not have a feasible parent should poison or
Pascal> detach. It does not make sense for a detached node to take
Pascal> visitors. So probably it should beacon a join priority of 0x7F.

Does detach mean to send a DIO with infinite rank?
I'm undecided if it should send a beacon at all.
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/11


Rahul> The Root should have the ability to send any value into the DODAG. If
Rahul> Root is limited to value 0/1 and if it is not possible for any 6LRs to
Rahul> update the value then we might as well restrict the parameter size to
Rahul> 1 bit! Am I missing anything here?

A goal here is to allow a device which is re-attaching to be able to judge
between several equivalent DODAGs which might be on different PANIDs, with
different capacities.   0/1 might not be enough here, and I'd prefer to err
on the side of creating a slider which we never use in the end.

https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/10

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