Re: [Roll] enrollment priority

[Konrad Iwanicki <[e-mail]>]

Hello Pascal and Michael,

My replies are inline.

On 24/11/2021 21:21, Pascal Thubert (pthubert) wrote:
>> 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.

Yes. This was the motivation.

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

Me too.

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

Now, I have second thoughts about the option (and the bit). Initially, I 
thought that having a new option is nice but now I do not see 
immediately what its semantics would be. In particular, how would a node 
know whether it has already reset its Trickle counter in response to the 
option or whether it should do this just now? The same goes for the bit.

I can imagine that the option could contain another lollipop counter but 
wonder whether it is a way to go?

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

See above.

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

I would vote for advertising 7f because at least this will update nodes 
that might have cached locally the node's old join priority and that 
attempt to use it as a proxy despite its lack of the preferred parent.

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

Yes, but this is just one of the reasons.

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

I would do poisoning in this case. See above concerning the 7f value.

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

I have no strong opinion on any of the solutions. Having more than 1 bit 
seems more generic. Whether those bits will be used in a different 
manner than "binary" is probably deployment specific.

Take care,
-- 
- Konrad Iwanicki.