Re: [Roll] enrollment priority

Hi all,

Since after reviewing the AODV draft I was already in the "draft mode", 
I created a pull request on GitHub for roll-enrollment-priority. It 
should cover all major issues that we discussed apart from the math for 
computing the Enhanced Beacon Join priority from the base priority value 
because I believe there were no conclusions on this issue. (Sorry if I 
forgot about anything.) I also tried to do little copy-editing to keep 
the change small.

In summary, the major changes are as follows:

- I extended the option with a sequence counter and a bit for resetting 
trickle timer on demand. I also reordered some fields to better -- in my 
view -- fit the current contents of the option.

- Described the processing of the option, notably taking into account 
the sequence counter and the trickle bit.

- Did some minor updates in the compatibility section to reflect that a 
node may learn the min priority value over multiple paths.

Hope that the changes will help push the draft further.

Best,
-- 
- Konrad Iwanicki.

On 25/11/2021 21:53, Michael Richardson wrote:
> 
> Pascal Thubert \(pthubert\) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
>      > (https://mailarchive.ietf.org/arch/msg/roll/2MaZ4wXLVzJbmLC-LO6c--DsbWQ/)
>      > Konrad Iwanicki <iwanicki@mimuw.edu.pl> wrote:
>      konrad> - How do changes to min priority (and OSN) affect DIO Trickle timers?
>      konrad> [OSN == the lollipop sequence counter]
> 
>      konrad> I think that if we have the counter, that increments the OSN reset the trickle
>      konrad> timer, but Pascal suggests an additional bit to reset the
>      konrad> trickle?
> 
>      pt> Some casual updates do not deserve to be flooded faster than normal
>      pt> stable DIO. But emergency and network control ones should. So we need a
>      pt> trigger to say that this DIO message should reset trickle. May that bit
>      pt> should not be in that option. It could be more generically used in
>      pt> DIOs.
> 
>      mcr> We can certainly build these rules into enrollment priority option.
>      mcr> But, I wonder if resetting trickle has general application, and should actually be
>      mcr> signaled by inclusion of a new DIO option.
> 
>      pt> Oups i read this after thinking the same. I agree.
> 
> okay, I'll include this.
> 
>      konrad> - How does a (temporal) lack of a preferred parent affect the proxy
>      konrad> priority of the node in EBs (and in general, the node's behavior)?
> 
>      mcr> If the node can't send traffic up to the root, then I think that it should
>      mcr> turn off EBs until it can.
> 
>      pt> Yes; at least advertise 7F for the priority if it needs to beacon for other reasons
> 
> I agree, 7F (infinite) if it needs to beacon.
> Should it even beacon if it has no feasible parents?
> 
>      mcr> In a 6tisch situation, it is likely that the lack of a preferred parent is
>      mcr> probably due to falling out of the schedule.
> 
>      pt> 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.
> 
>      mcr> Does detach mean to send a DIO with infinite rank?
> 
>      pt> Poison means that. Detaching means forming its own dodag with the G
>      pt> bit not set (not grounded)
> 
>      mcr> I'm undecided if it should send a beacon at all.
>      mcr> https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/11
> 
> There seem to be a number of parts to a decision tree here.
> 
> I will start more threads.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll