[Roll] Re: [roll-wg/draft-ietf-roll-enrollment-priority] Charlie Review during WGLC (Issue #33)

[Michael Richardson <[e-mail]>]

edit that I did are at:
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/commit/cad7670a7a9e55cd89630fad8bf7d2643a1536c4

inesrob <[e-mail]> wrote:
    > CEP: Is it possible to have an Abstract that does not first require

I have acted on most of the CEP:
You have shown OLD/NEW, but also edits, and I was confused at first as I
tried to figure out if there were words other than those marked CEP that you
wanted changed.

    > NEW:

    > This document describes a Routing Protocol for Low-Power and Lossy
    > Networks (RPL) Destination Information Object (DIO) option that can
    > be used to set a minimum enrollment priority.  The minimum priority
    > expresses the inability of the RPL DODAG globally to accept new
    > CEP: "expresses the inability" --> "assesses the ability"

_assess_ (evaluate) is not the same as express (communicate)
The point of this option is to announce/distribute the ability.

    > CEP: As mentioned, the viability of joining a new DODAG could depend
    > on other
    > factors.  It could also, for instance, depend on how saturated
    > the DODAG

Yes, many things are possible.
Having another extension point inside a container that already allows
extension points seems unnecessary to me.

    > is currently (regardless of size), or on the nature of the layer 2.
    > Perhaps this field should be equipped with a type descriptor so
    > that it
    > could provide information about other determining factors. Maybe the
    > extra bits could be carved out of the Min Priority field.

Any new measurements need to be sensible to all nodes.
The more numbers we have to less likely we'll have them evaluated consistently.

    > NEW:

    > In order to avoid the ambiguity of this term, this document refers to
    > the process (1)"Join" as enrollment, leaving the term "Join" to mean
    > (2)"Join".  The term "onboarding" (or "IoT Onboarding") is
    > increasingly used to describe what is now called (1)Join in other
    > documents, and is called enrollment in this document. However, the
    > term _Join Proxy_ is retained with its (1)"Join" meaning from
    > [RFC9031].
    > CEP: Why not "Enrollment Proxy"?

Because the act of picking a parent for a node already enrolled is also
supported, and the people who worry about this call that joining a DODAG.

    > CEP: "designed into"  -->  "specified by"
    > No mechanism is needed to enable it.
    > CEP: This sentence raises more questions than it answers, at least for me.
    > Perhaps simply leave it out (especially if you use "specified by").

We have many other mechanisms that have to be turned on by magic configuration.
This mechanism can be unilaterally enabled on any node.

    > Min Priority  A 7-bit field providing a base value for the Enhanced
    > Beacon Join priority.  A value of 0x7f (127) disables the _Join
    > Proxy_ function entirely.

    > CEP: If T were 2 bits, and Min Priority were 6 bits, you would have
    > more control over the Trickle Timer.  Do you really need 7 bits?

Not going to relitigate this now.
I don't know what those two extra meanings would be.

    > NEW:

    > The DODAG Size can be measured by the Root based on the DAO activity.
    > CEP: Couldn't you just count the number of enrollments?  Is there a
    > keepalive?

No.  Leaf nodes could be off, could have moved, could be in long-term sleep,
could have dead batteries.  The DAO *is* the keepalive response to a
trickle/DTSN (did I get right term? it's been so long)

    > NEW:

    > Future work such as [I-D.ietf-roll-capabilities] will enable
    > collection of capabilities such as this one in reports to the DODAG
    > Root.
    > CEP: I don't see how this improves the current specification.

Well, I think someone above wanted to add new metrics already.
This tells you one way that you could find out if the new metrics were
universally available, and then turn them on.

    > Section 3.2., paragraph 6:
    > OLD:

    > A 6LR, which would otherwise be willing to act as a _Join Proxy_,
    > will examine the locally adopted value of Min Priority and to that
    > number add any additional local consideration (such as upstream
    > congestion, number of NCE slots available, etc.).

    > NEW:

    > A 6LR, which would otherwise be willing to act as a _Join Proxy_,
    > will examine the locally adopted value of Min Priority and to that
    > number add any additional local consideration (such as upstream
    > congestion, number of NCE slots available, etc.).
    > CEP: Does the Min Priority control enrollment, or willingness to act
    > as a _Join Proxy_?  These seem like two different things.
    > ----------------------------------------

That's why all the discussion about the terms _Join_ is vs _Enrollment_

You can't Enroll without a Join Proxy. It's not an Enrollment Proxy, because
that's not the term we used, and the routing types couldn't give up "joining
a DODAG" as a term.

You can synchronize your 6TSCH (forinstance) from a node that announces a beacon.
When already enrolled, a node can use the Min Priority in the RFC9031
Enhanced Beacon to pick different join points.

    > Section 3.3., paragraph 1:
    > OLD:

    > A 6LR that did not support this option would not act on it or
    > propagate it in its DIO messages.  In effect, the 6LR's children and
    > grandchildren nodes could not receive any telemetry. Therefore, 6LRs
    > that support this option but do not receive it via any path SHOULD
    > assume a default value of 0x40 as their base value for the Enhanced
    > Beacon Join Priority.

    > NEW:

    > A 6LR that did not support this option would not act on it or
    > propagate it in its DIO messages.  In effect, the 6LR's children and
    > CEP: How about "subtree nodes"?

okay.

    > grandchildren nodes could not receive any telemetry. Therefore, 6LRs
    > CEP: Doesn't this imply that all DODAGs are about telemetry?  Is that
    > O.K.??

They contain metrics already.

    > that support this option but do not receive it via any path SHOULD
    > assume a default value of 0x40 as their base value for the Enhanced
    > Beacon Join Priority.
    > CEP: How long do they wait before this?  What happens if a 6LR does
    > this, but later receives the option with Min_Priority == _MAX_VALUE_?

Then there is a change.
This whole section is about how lack of accurate values affects the process.
If a better value is seen, then great.  It no longer has inaccuracies.

    > NEW:

    > *  If the value implied by the base value of 0x40 was too high, then
    > the 6LR might deflect enrollment traffic to other parts of the
    > DODAG, possibly refusing any enrollment traffic at all.  In order
    > for this to happen, some significant congestion must be seen in
    > CEP: "must" here seems wrong, and "significant" is really too ambiguous
    > the sub-DODAG where the implied 0x40 was introduced.  The 0x40 is
    > only the half-way point, so if such an amount of congestion was
    > present, then this sub-DODAG of the DODAG simply winds up being
    > more cautious than it needed to be.
    > CEP: One might, for instance, suggest that packet drop rates should
    > not exceed 5%.

Again, this is about why it's okay to make mistakes during incremental
deployment.  It's not about a policy.

    > NEW:

    > It is possible that the emporal alternation of the above two
    > situations might introduce cycles of accepting and then rejecting
    > enrollment traffic.  This is something an operator should consider if
    > they incrementally deploy this option to an existing Low-power/Lossy-
    > Network (LLN).  In addition, an operator would be unable to turn off
    > enrollment traffic by sending a maximum value enrollment priority to
    > the sub-DODAG.  This situation is unfortunate, but without this
    > option, the situation would occur all over the DODAG, rather than
    > just in the sub-DODAG that the option did not reach.

    > CEP: It is not clear what, if anything, the previous paragraph is
    > specifying.

nothing. It makes no further code requirements other than the SHOULD in the
first paragraph.


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