Subject: [Roll] About merging two RFC drafts: draft-ietf-roll-enrollment-priority and DODAG size

From: "Huimin She (hushe)" <[email-masked]>
Date: Thu, 4 Feb 2021 09:40:57 +0000

Hi all,

Thanks for the nice discussions. Here are the answers for the questions raised in the interim meeting.

Question 1: Do we need the DODAG size as a complement to enrollment priority?
Answer: Yes.
1a) Enrollment priority is a metric providing the abstraction of battery power, network bandwidth and available memory.
      It represents the willingness of a 6LR to act as a joining proxy. 
      While DODAG size provides more information for a new node to decide which DODAG to join.
1b) The DODAG size is not only useful for a new node to choose a DODAG to join, but also useful for load balance between multiple DODAGs since nodes are able to migrate between DODAGs after knowing the DODAG size.

Question 2: Is 2-byte enough for encoding the DODAG size?
Answer: Yes.
2a) If we directly use the 2-byte, the max size is 65535 which might not be enough.
2b) An alternative encoding format is as follows:
- 4 bits for the unit. Let's set x = 0, 1, 2, ..., 15, so the unit equals to 2^x , i.e, unit = 1, 2, 4, 8, ..., 2^15.
- 12 bits for the value.
So the max number is 2^15 * 2^12, which is big enough for representing the DODAG size.

Please let me know your thoughts. Thank you.

Best regards,
Huimin

On 2021/2/4, 01:30, "Michael Richardson" <[email-masked]> wrote:

    Huimin She (hushe) <[email-masked]> wrote:
        > Thanks for the nice discussion in the IETF interim meeting.

        > Attached please find the slides we presented. The draft is available
        > here: https://github.com/roll-wg/dodag-metric

        > It is a good idea if our two drafts can be merged. How shall we
        > proceed?

    As ietf-roll-enrollment-priority is already adopted, if it is the will of the
    WG to include your metric, then merging it in would make sense.
    I suggest a pull request on github at
      https://github.com/roll-wg/draft-ietf-roll-enrollment-priority.git
    would make sense.

    (Add Huimin She as a co-author, and Pascal too if desired)

    Maybe do the pull request first, and let's bring that discussion to the WG.

    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Feb 2021 10:03:17 +0000

Hello Huimin:

1) I agree that the (min) Priority in the draft could inherit from the DODAG size and is still quite different, since it could also reflect other gating factors such as an administrative willingness, the bandwidth availability / utilization near the Root, the memory in the Root more routes, etc... So constraining that the DODAG size derives from the priority degrades the value of the priority dramatically
2) I like the 12+4 bits representation that seems to bring the best of both worlds. I agree that it addresses the issues raised at the call.

Bottom line:
- I support the merge
- Is there another important information from the Root that we may want to add before we close the draft?
- to Michael's point, happy to contribute to the draft.

You all take care,

Pascal

> -----Original Message-----
> From: Huimin She (hushe) <[email-masked]>
> Sent: jeudi 4 février 2021 10:41
> To: Michael Richardson <[email-masked]>; [email-masked]
> Cc: [email-masked]; Pascal Thubert (pthubert) <[email-masked]>;
> Li Zhao (liz3) <[email-masked]>
> Subject: About merging two RFC drafts: draft-ietf-roll-enrollment-priority and
> DODAG size
> 
> Hi all,
> 
> 1b) The DODAG size is not only useful for a new node to choose a DODAG to
> join, but also useful for load balance between multiple DODAGs since nodes
> are able to migrate between DODAGs after knowing the DODAG size.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Feb 2021 17:09:40 +0000

Dear all 

As agreed at the interim, I pushed some changes in the draft to add the DODAG Size to the new option.

I leave the ball to Huimin to take more of his original work and complete the changes.

My own diffset is here 
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/commit/e3d3d0b57ba6339b292718670ae4332730ffb03d

for now I commented out 
<!--  
It may also be added by a router on part of the sub-tree as a result of some (out of scope for this document) management function.
6LRs that see this DIO Option SHOULD increment their minimum enrollment priority if they observe congestion on the channel used for enrollment traffic.
The exact mechanism is a local decision, and may be the subject for future work.
-->

I'm concerned that the undocumented/future behavior will create comments at the IESG. 
My observation is that we should either define the process fully or not mention it at all.
Also, the common practice for DIO values that they are set by the Root and propagated unchanged seems relevant here to start with, so I reworded the github text in that direction.

Please feel free to comment / contradict, it's easy to roll back any of the above.

Keep safe;

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 16:56:05 -0500

Pascal, thanks for starting this process!
I'm going to wait for Huimin to add his name to the author list, and
then I'll push an update document.

Your text puts both values into a single Metric.
I was thinking it would be two metrics, but upon reflection, it probably does
belong in a single metric object.

What would an appropriate default be if the metric is introduced in the
middle of the DODAG?
   https://datatracker.ietf.org/doc/html/draft-ietf-roll-enrollment-priority-03#section-2.1

doc> The size of the DODAG is measured by the Root based one the DAO
doc> activity. It represents a number of routes not a number of nodes, and
doc> can only be used to infer a load in an homogeneous network where each
doc> node advertises the same number of addresses and generates roughly the
doc> same amount of traffic

I really that we would measure in terms of number of routes.

pt> I'm concerned that the undocumented/future behavior will create comments
pt> at the IESG.  My observation is that we should either define the process
pt> fully or not mention it at all.

I concur that we will get comments, and yet, I think that we really do want
to allow for "future work".

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 6 Feb 2021 22:21:32 +0000

Hello Michael 

There’s always room for future improvements. But do we necessarily need to point it out ? I’ve had to rewrite / remove similar text in recent IESG reviews and I now believe in focusing on what’s there not what could have been or may be one day.

Regards,

Pascal

> Le 6 févr. 2021 à 22:56, Michael Richardson <[email-masked]> a écrit :
> 
> 

Not sure what you mean by this. Same record ?

>   https://datatracker.ietf.org/doc/html/draft-ietf-roll-enrollment-priority-03#section-2.1

Not sure it should be ; that’s the text I commented out and wanted to discuss with you. My initial understanding was that it didn’t happen but rereading I found the text allowed it. Same as above allowing that it is injected in the middle raises many questions for which I have no answer like on which occasion that happens, and what sense it makes. Eg the dodag size cannot be invented by a node in the middle; realistically not can a meaningful priority for the same reasons.

> I really that we would measure in terms of number of routes.

You mean nodes not routes? Sadly we have no way to know that, do we?

> to allow for "future work".

More than comments; they ask for crisp specification, backward compatibility and security issues...

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 21:11:13 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    >> Your text puts both values into a single Metric.  I was thinking it
    >> would be two metrics, but upon reflection, it probably does belong in
    >> a single metric object.
    >>

    > Not sure what you mean by this. Same record ?

Yes, I mean, you've extended the single metric object to have two things.
We could have created two metric objects at a small byte cost.
More flexibility, but maybe more than is actually needed.

    >> What would an appropriate default be if the metric is introduced in
    >> the middle of the DODAG?

    > Not sure it should be ; that’s the text I commented out and wanted to
    > discuss with you. My initial understanding was that it didn’t happen
    > but rereading I found the text allowed it. Same as above allowing that
    > it is injected in the middle raises many questions for which I have no
    > answer like on which occasion that happens, and what sense it makes. Eg
    > the dodag size cannot be invented by a node in the middle;
    > realistically not can a meaningful priority for the same reasons.

So my reason to including it mid-DODAG is because, otherwise, we have to use
capabilities or something to figure out what happens when the root is
emitting it, and it's not getting to the leaves.

    doc> The size of the DODAG is measured by the Root based one the DAO
    doc> activity. It represents a number of routes not a number of nodes,
    doc> and can only be used to infer a load in an homogeneous network where
    doc> each node advertises the same number of addresses and generates
    doc> roughly the same amount of traffic

    > You mean nodes not routes? Sadly we have no way to know that, do we?

I really like that we could measure routes easily, so lets use that.

    pt> I'm concerned that the undocumented/future behavior will create
    pt> comments at the IESG.  My observation is that we should either define
    pt> the process fully or not mention it at all.
    >>
    >> I concur that we will get comments, and yet, I think that we really do
    >> want to allow for "future work".

    > compatibility and security issues...

Yup.

---

From: "Huimin She (hushe)" <[email-masked]>
Date: Sun, 7 Feb 2021 08:23:05 +0000

Hi Mikael,

I have added my name to the author list.

To Pascal and all,
1) I think the DODAG size represents number of nodes.
2) If the metric is introduced in the middle of the DODAG, how about setting the DODAG size to 0, meaning a useless number?

Best regards,
Huimin

On 2021/2/7, 06:21, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

    Hello Michael 

    Regards,

    Pascal

    Take care,

    Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 7 Feb 2021 08:58:17 +0000

Hello Huimin 

How does the Root figure the number of nodes? RPL does not give you that. But if everyone injects exactly the same number of routes (1?) then the dodag balancing that you want works just the same.

What would be the value of injecting the option in the middle of the network? What are the security considerations associated? 

Note that it is very hard to figure the load of a multipath several hops down and that routing based on load is prone to oscillation unless great care is given to the control system. Do you want to open that box?

All in all we want something simple, that does the work you need, and that is fully specified, no corner case, the we go smoothly through the review process.

Take care;

Pascal

> Le 7 févr. 2021 à 09:23, Huimin She (hushe) <[email-masked]> a écrit :
> 
> Hi Mikael,
>

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Wed, 10 Feb 2021 03:12:56 +0000

Hello Michael/Pascal,

If we measure DODAG size in terms of number of routes,  probably we should consider:
In non-storing mode, whether the external routes should be included.
In storing mode, routes are always aggregated. Root can’t get correct route number.
In mop 0, there is no DAO reported. So root can’t get route number too.

Another problem is how to indicate the priority value, currently roots don’t sync any rpl information, we can’t make sure single root can get the correct priority. For example, if root A knows there is another root B with higher uplink throughput and fewer route number, A could lower its priority.

Best regards,
Li

From: Roll <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Sunday, February 7, 2021 at 10:11
To: [email-masked] <[email-masked]>
Subject: Re: [Roll] About merging two RFC drafts: draft-ietf-roll-enrollment-priority and DODAG size

Yup.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Feb 2021 08:10:26 +0000

Hello Li:

Great questions. 

> In non-storing mode, whether the external routes should be included.
Ultimately that's the Root decision based on admin. We need to provide a default, I suggest that default is yes.

> In storing mode, routes are always aggregated. Root can't get correct route number.
They are typically not aggregated in the common sense (shorter prefix). They are collated but you can still count them.

> In mop 0, there is no DAO reported. So root can't get route number too.
True, we'll have to add text on this. 

Keep safe!

Pascal

From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: mercredi 10 février 2021 4:13
To: [email-masked]
Subject: [Roll] About measure DODAG size and priority

Hello Michael/Pascal,

If we measure DODAG size in terms of number of routes,  probably we should consider:
In non-storing mode, whether the external routes should be included.
In storing mode, routes are always aggregated. Root can't get correct route number.
In mop 0, there is no DAO reported. So root can't get route number too.

Another problem is how to indicate the priority value, currently roots don't sync any rpl information, we can't make sure single root can get the correct priority. For example, if root A knows there is another root B with higher uplink throughput and fewer route number, A could lower its priority.

Best regards,
Li

From: Roll <mailto:[email-masked]> on behalf of Michael Richardson <mailto:[email-masked]>
Date: Sunday, February 7, 2021 at 10:11
To: mailto:[email-masked] <mailto:[email-masked]>
Subject: Re: [Roll] About merging two RFC drafts: draft-ietf-roll-enrollment-priority and DODAG size

Pascal Thubert (pthubert) <mailto:[email-masked]> wrote:
    >> Your text puts both values into a single Metric.  I was thinking it
    >> would be two metrics, but upon reflection, it probably does belong in
    >> a single metric object.
    >>

    > Not sure what you mean by this. Same record ?

    >> What would an appropriate default be if the metric is introduced in
    >> the middle of the DODAG?
    >> https://datatracker.ietf.org/doc/html/draft-ietf-roll-enrollment-priority-03#section-2.1

    > Not sure it should be ; that's the text I commented out and wanted to
    > discuss with you. My initial understanding was that it didn't happen
    > but rereading I found the text allowed it. Same as above allowing that
    > it is injected in the middle raises many questions for which I have no
    > answer like on which occasion that happens, and what sense it makes. Eg
    > the dodag size cannot be invented by a node in the middle;
    > realistically not can a meaningful priority for the same reasons.

    >>
    >> I really that we would measure in terms of number of routes.

    > You mean nodes not routes? Sadly we have no way to know that, do we?

    pt> I'm concerned that the undocumented/future behavior will create
    pt> comments at the IESG.  My observation is that we should either define
    pt> the process fully or not mention it at all.
    >>
    >> I concur that we will get comments, and yet, I think that we really do
    >> want to allow for "future work".

    > More than comments; they ask for crisp specification, backward
    > compatibility and security issues...

Yup.

--
Michael Richardson <mailto:[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide