Subject: [Roll] enrollment priority

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Nov 2021 09:15:35 -0500

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

   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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Konrad Iwanicki <[email-masked]>
Date: Mon, 22 Nov 2021 15:55:06 +0100

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:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 23 Nov 2021 09:05:18 +0530

Hey Michael,

Please find my review of the updates inline in the github PR
<https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/9>.
Few other comments inline below.

Regards,
Rahul

> Changes to the priority will *not*(?!) reset the trickle timer.

Not resetting trickle timer has impact. It could take several hours for the
updated option to percolate downstream in the network. I just wanted to say
it loud here.

> or was it only 0 and 1 that were useful?

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Nov 2021 05:49:45 +0000

Hello Michael

Please see https://datatracker.ietf.org/doc/minutes-interim-2021-roll-02-202108311800/

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--DsbWQ/)
I do not see a use case for it, so it looks like overdesign but I'm open to be convinced otherwise

Keep safe;

Pascal

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Konrad Iwanicki
> Sent: lundi 22 novembre 2021 15:55
> To: Routing Over Low power and Lossy networks <[email-masked]>; Michael
> Richardson <[email-masked]>
> 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.
> 
> > 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.
> > 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.
> >
> > https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/9/
> > files#diff-fe544a5ddaac2d404d7b76aa1204d54e36f5eb6618f3f52f0c0dc56dca4
> > 061faL169
> >
> > 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?
> >
> > --

---

From: Konrad Iwanicki <[email-masked]>
Date: Tue, 23 Nov 2021 10:00:25 +0100

Hi all,

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Nov 2021 07:22:34 +0000

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.

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?

Pascal

> From: Konrad Iwanicki <[email-masked]>
> Sent: mardi 23 novembre 2021 10:00
> To: Routing Over Low power and Lossy networks <[email-masked]>; Pascal
> Thubert (pthubert) <[email-masked]>; Michael Richardson
> <[email-masked]>
> > Please see
> > https://datatracker.ietf.org/doc/minutes-interim-2021-roll-02-20210831
> > 1800/
> >
> > We agreed that:
> > - 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
> 
> 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:
> 
> >> To: Routing Over Low power and Lossy networks <[email-masked]>;
> >> Michael Richardson <[email-masked]>
> >> 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.
> >>
> >>> I'm trying to edit draft-ietf-roll-enrollment-priority to reflect
> >>> the WG consensus.
> >>>
> >>> 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.
> >>>
> >>> Michael Richardson <[email-masked]>   . o O ( IPv6 IøT
> consulting
> >> )

---

From: Konrad Iwanicki <[email-masked]>
Date: Wed, 24 Nov 2021 13:40:23 +0100

Hi Pascal,

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

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.

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

>>>>> 9/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Nov 2021 13:17:30 +0000

Very good! 

Regards,

Pascal

> Le 24 nov. 2021 à 13:40, Konrad Iwanicki <[email-masked]> a écrit :
> 
> Hi Pascal,
> 
> 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:
> 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.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Nov 2021 12:25:41 -0500

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

    > 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) <[email-masked]> 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/)

okay.

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

    > 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Nov 2021 12:35:50 -0500

Instead of fixing enrollment priority, could we make the two values that
the root wants to announce: dodag size, min.priority as a capability?

I see this as pushing capabilities out the door sooner, and maybe eliminating
a document in the IESG queue.

We have so far in the document on specified the routing resource capability
as a Capability Set *Response*, a reply from the node to the root.
We haven't specified a way to announce a value from the root to the nodes.

In the document we say that capability TLVs can be carried in DIO/DAO, but
also in other messages.  I don't think we defined any.

I'm not strongly attached to this idea, but thought of it while eating lunch.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Nov 2021 20:12:30 +0000

Hello Michael

Please see below

Le 24 nov. 2021 à 18:36, Michael Richardson <[email-masked]> a écrit :

I do not see that as a capability. I believe the draft is close to fine for publication as is and needed. Capabilities are pulled from the nodes by the Root. Even the remaining capacity could be a capability. But this is different it is pushed info but the root. For that DIO is fine.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Nov 2021 20:21:15 +0000

Hello Michael

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

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

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.

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.

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

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

Yes

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

No se

---

From: Konrad Iwanicki <[email-masked]>
Date: Wed, 24 Nov 2021 21:48:04 +0100

Hello Pascal and Michael,

My replies are inline.

> It’s mostly to figure which is the most recent when several parents are 

Yes. This was the motivation.

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

Me too.

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

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?

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

See above.

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

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.

>> probably due to falling out of the schedule.

Yes, but this is just one of the reasons.

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

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

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Nov 2021 15:53:50 -0500

> Konrad Iwanicki <[email-masked]> 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

    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.