Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 09 August 2021 18:49 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F1A3A12B1; Mon, 9 Aug 2021 11:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADTmlRQlq-0P; Mon, 9 Aug 2021 11:49:06 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992A03A1337; Mon, 9 Aug 2021 11:48:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BC94389B8; Mon, 9 Aug 2021 14:53:24 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eKah7feTszZr; Mon, 9 Aug 2021 14:53:15 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AC6A389B1; Mon, 9 Aug 2021 14:53:15 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8303DC65; Mon, 9 Aug 2021 14:48:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
cc: roll-chairs@ietf.org
In-Reply-To: <f7a504ac-764d-09e9-d969-067e6a21646a@mimuw.edu.pl>
References: <f7a504ac-764d-09e9-d969-067e6a21646a@mimuw.edu.pl>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Mon, 09 Aug 2021 14:48:40 -0400
Message-ID: <26245.1628534920@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mVips1a7hkTQ_BPatNDHbCV_JtQ>
Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2021 18:49:21 -0000

Konrad Iwanicki <iwanicki@mimuw.edu.pl> wrote:
    > I have the following major issues with the draft. Perhaps some of them have
    > been covered during some meetings (sorry for missing those); my comments are
    > based just on what I got from the draft (and the related drafts).


    > 1. I was confused by two seemingly contradictory statements.

    > Par. 2 of sect. 2 (starting with "With this specification") states that the
    > introduced option "MUST be propagated down the DODAG without modification"
    > (compared to what is issued by the DODAG root).

Good catch.  I will remove the words "without modification"

    > What I understand is that the adjustment applies only in a particular
    > case. More specifically, if a node receives the option, it copies it to its
    > DIOs without any modification. In contrast, if the node does not receive the
    > option but is capable of processing it, then it synthesizes the option for
    > its DIOs by taking as the min priority the base value (0x40) adjusted with
    > the node's local observations.

Agreed.

    > This seems inconsistent, though.
    > In particular, two children with the same parent can emit DIOs with different
    > values of min priority. Why not simply omit the option in such a case?

So you are assuming the DAG:

         A
        / \
       B   C
      / \   \
     D  E   F

And "A" does not know to send this option, so both B and C assume a value of 0x40.
Then, each one adjusts this based upon their local conditions.
D+E might see a value of 0x50 (if B added 16), while F might see a value of
0x60 (if C added 32).
This would make new nodes prefer to enroll with D or E, rather than F.

The reason is that perhaps B has more resources than C for new children.

    > 2. The draft implicitly assumes a DIO processing policy that differs from
    > RPL's original one.

    > More specifically, throughout the draft, it is implied or assumed that a node
    > processes the option received only from its parent(s).
    > For example:
    > - par. 8 of sect. 1 (starting with "A network operator might"): "... it would
    > like to adjust the enrollment priority (the proxy priority field of [...])
    > among all nodes in the subtree of a congested link.";

    > - par. 1 of sect. 2.1 (starting with "A 6LR which did not support"):
    > "Children and grandchildren nodes would therefore not receive any telemetry
    > via that path and need to assume a default value.";

    > - par. 2 of sect. 2.1: "6LRs that support this option, but whose parent does
    > not send it [...]" and the rest of the paragraph as well.


    > In contrast, RFC 6550, sect. 8.2.3 states that DIOs not only from parents but
    > also other neighbors must be processed by a node. This guarantees correct
    > route formation and maintenance.

Yes, it's true.  A node should evaluate DIOs from other sources, and if those
sources are better, then it should switch parents.  But at any point, a node
really has only one parent.
The other nodes are potential parents, but not parents.
Perhaps RFC6550 has some other terms which I've neglected to use.

    > 3. Even if the draft identified a single parent as the only source of min
    > priority values for a node, there still would be a problem of value
    > consistency.

    > Since the DODAG root can change its values of min priority and DODAG_Size and
    > since a node can change its parents, there may still be a case when the node
    > must decide whether to adopt the newly received values or not. Without a
    > proper conflict resolution policy, it may be the case that when the root, for
    > example, disables enrollment, then enables it again, then the DODAG may
    > exhibit strange behaviors: the root's decision may not be propagated to all
    > nodes, a decision may be revoked by nodes that have already accepted it, and
    > the like.

A root that did this, would have to increment the DTSN right each time it
changed it's mind.

    > There are many ways in which such conflict resolution can be provided. If I
    > may suggest anything, I would recommend adding to the option a lollipop
    > sequence counter (like those described in RFC 6550, sect. 7.2), let's call it
    > osn. It would effectively order different versions of the option values
    > produced by the DODAG root. In effect, whenever a node received an option (be
    > it from a parent or another neighbor, depending on the way the previous
    > issues are addressed), it would adopt the min priority and DODAG_Size values
    > the option carries if and only if the osn value in the received option is
    > greater than the node's locally stored osn. This would guarantee eventual
    > consistency and avoid strange behaviors such as those mentioned above.

I'm not convinced we need another lollipop counter.
I think that we already have that.

    > 4. Why put DODAG_Size in the option?

    > I can imagine that other services/protocols would like to use it as well, and
    > extracting this information from an option related solely to enrollment does
    > not seem the best idea. I have been thinking for some time about an option
    > for RPL that would provide some aggregate information about the DODAG to the
    > nodes, such as its size, max depth, and the like. The option could also be
    > used in the enrollment process. Do you think this makes sense?

We agreed to merge two drafts.  The DODAG_Size came from the other draft.
We think that the two values are very much related and it made sense to send
them together.

    > Apart from these major issues, I have also a few editorial suggestions.

    > A. After the par. 1 of sect. 1, I would introduce a subsection heading
    > titled, for instance, "Terminology Disambiguation" to prepare the readers for
    > what they are going to see next.

okay, I have re-organized some text.

    > B. Similarly, before par. 5 of sect. 1 (starting with "It has become clear
    > that not every routing member"), I would introduce a subsection heading
    > titled "Motivation and Overview", just "Overview", or something along these
    > lines.



    > C. I would promote the "Terminology" subsection to a section.

    > D. I would move par. 1 of sect. 2 (starting with "The size of the DODAG is
    > measured by the Root") toward the end of sect. 1 as it has little to do with
    > the option definition.

okay.

    > E. I would fix the bullet list in sect. 2.1 so that it renders correctly in
    > the text version of the draft.

markdown issue.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide