Re: [Roll] enrollment priority

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael


Le 24 nov. 2021 à 18:26, Michael Richardson <[e-mail]> a écrit :


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.


It’s mostly to figure which is the most recent when several parents are not at the same level.

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?

Actually every text I’m aware of point to section 7 of rfc 6550.


(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


Some casual updates do not deserve to be flooded faster than normal stable DIO. But emergency and network control ones should. So we need a trigger to say that this DIO message should reset trickle. May that bit should not be in that option. It could be more generically used in DIOs.



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.

Oups i read this after thinking the same. I agree.

 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


Yes

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

Yes; at least advertise 7F for the priority if it needs to beacon for other reasons

In a 6tisch situation, it is likely that the lack of a preferred parent is
probably due to falling out of the schedule.


Yes

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?

Poison means that. Detaching means forming its own dodag with the G bit not set (not grounded)

I'm undecided if it should send a beacon at all.
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/11


No se


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    [


_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll