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

[Michael Richardson <[e-mail]>]

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