Re: [Roll] About measure DODAG size and priority

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Li Zhao (liz3)
Sent: mercredi 10 février 2021 4:13
To: [e-mail]
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:[e-mail]> on behalf of Michael Richardson <mailto:[e-mail]>
Date: Sunday, February 7, 2021 at 10:11
To: mailto:[e-mail] <mailto:[e-mail]>
Subject: Re: [Roll] About merging two RFC drafts: draft-ietf-roll-enrollment-priority and DODAG size

Pascal Thubert (pthubert) <mailto:[e-mail]> 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?
    >> 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.

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

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

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

Yup.

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