Re: [Roll] enrollment priority

[Konrad Iwanicki <[e-mail]>]

Hi Pascal,

On 24/11/2021 08:22, Pascal Thubert (pthubert) wrote:
> I think we're in sync, Konrad.
> 
> 1) For the trickle question, Rahul also mentioned it in his review:
> 
> I believe that there's the normal run time where the value changes in acceptable ranges, and there's emergency condition like a Root reaching saturation. Or maybe some coordination between DODAGs that triggers a min value in each DODAG, and we want that value to spread out fast.
> 
> Those latter cases cannot wait hours for the DIO to trickle out. I believe it should be up to the root to decide. So there should be a signal like a bit that says whether or not to reset Trickle.
> 
> The "OSN" should be independent of that. It should be incremented (and wrapping) with the new advertisements. Things are easier when each field has a clear function, side effects can be clever but are complex to manage.

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

> 2) The min priority value used is the one associated with the most recent "OSN" seen, and that's not limited to preferred parent. That's one of the arguments to keep it intact as propagated.
> 
> A node that does not have a feasible parent should poison or detach. It does not make sense for a detached node to take visitors. So probably it should beacon a join priority of 0x7F.
> 
> Either way, its OSN in DIOs will not be incremented and a node that sees a a fresher OSN one will use that one and continue beacon a proper value.
> 
> Does all this make sense?

Yes. This is precisely what I meant. In case, a node does not have a 
preferred parent it should advertise a join priority of 0x7F (i.e., the 
priority in beacons not in DIOs because the ones in DIOs are fixed by 
the root as we agreed). What I wanted to suggest is adding this 
requirement/recommendation to the draft, so that it is clear that 
having/not having a preferred parent also affects the join priority in 
beacons (EBs).

Best,
-- 
- Konrad Iwanicki.

>> -----Original Message-----
>> From: Konrad Iwanicki <[e-mail]>
>> Sent: mardi 23 novembre 2021 10:00
>> To: Routing Over Low power and Lossy networks <[e-mail]>; Pascal
>> Thubert (pthubert) <[e-mail]>; Michael Richardson
>> <[e-mail]>
>> Subject: Re: [Roll] enrollment priority
>>
>> Hi all,
>>
>> On 23/11/2021 06:49, Pascal Thubert (pthubert) wrote:
>>> Hello Michael
>>>
>>> Please see
>>> https://datatracker.ietf.org/doc/minutes-interim-2021-roll-02-20210831
>>> 1800/
>>>
>>> We agreed that:
>>> - as Konrad says again here we need a new lollipop counter
>>> - as Rahul points out in his review the min priority is propagated
>>> unchanged in DIOs, what I understand Konrad calls GLOBAL
>>> - as Huimin said on Aug 19th we must define the behavior of the node,
>> which logic to use to increment the minimum priority from the DIO to place
>> in the beacon.
>>>
>>> GLOBAL vs FLEXIBLE was discussed, and I answered Konrad about the
>>> FLEXIBLE on Aug. 12th
>>> (https://mailarchive.ietf.org/arch/msg/roll/2MaZ4wXLVzJbmLC-LO6c--DsbW
>>> Q/) I do not see a use case for it, so it looks like overdesign but
>>> I'm open to be convinced otherwise
>>
>> Precisely, we agreed on what I call GLOBAL. In addition, from the
>> discussion in my e-mail, there are two additional issues outstanding (one
>> was mentioned by Michael). I believe we did not come to a conclusion
>> regarding them:
>>
>> - How do changes to min priority (and OSN) affect DIO Trickle timers?
>> [OSN == the lollipop sequence counter]
>>
>> - 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)?
>>
>> Best,
>> --
>> - Konrad Iwanicki.
>>
>>>> -----Original Message-----
>>>> From: Roll <[e-mail]> On Behalf Of Konrad Iwanicki
>>>> Sent: lundi 22 novembre 2021 15:55
>>>> To: Routing Over Low power and Lossy networks <[e-mail]>;
>>>> Michael Richardson <[e-mail]>
>>>> Subject: Re: [Roll] enrollment priority
>>>>
>>>> Hi Michael,
>>>>
>>>> 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.
>>>>
>>>> Take care,
>>>> --
>>>> - Konrad Iwanicki.
>>>>
>>>> On 22/11/2021 15:15, Michael Richardson wrote:
>>>>>
>>>>> I'm trying to edit draft-ietf-roll-enrollment-priority to reflect
>>>>> the WG consensus.
>>>>>
>>>>> I think that we agreed that the nodes within the DODAG should not
>>>>> change their enrollment priority.  It can be set by the root in it's
>>>>> DIO, and it will propogate through the DODAG according to the normal
>>>> trickle settings.
>>>>> Changes to the priority will *not*(?!) reset the trickle timer.
>>>>>
>>>>> https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/
>>>>> 9 is the pull request I just made, which may be easier to see the
>>>>> changes.
>>>>>
>>>>> specifically, I've deleted this line:
>>>>>
>>>>> https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/
>>>>> 9/
>>>>> files#diff-fe544a5ddaac2d404d7b76aa1204d54e36f5eb6618f3f52f0c0dc56dc
>>>>> a4
>>>>> 061faL169
>>>>>
>>>>>       The nodes then adjust this base value based upon their observed
>>>>>       congestion, emitting their adjusted DIO value to their children.
>>>>>
>>>>> I actually find that there isn't a lot else to delete.
>>>>>
>>>>> I am concerned that I did not understand the WG consensus correctly,
>>>>> so I am have not yet published this version.
>>>>>
>>>>> Do we want to retain the ability for the root to send a value 0-0x7f
>>>>> into the DODAG, or was it only 0 and 1 that were useful?
>>>>>
>>>>> --
>>>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
>> consulting
>>>> )
>>>>>               Sandelman Software Works Inc, Ottawa and Worldwide
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>
>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>