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

Konrad Iwanicki <iwanicki@mimuw.edu.pl> Wed, 04 August 2021 20:31 UTC

Return-Path: <iwanicki@mimuw.edu.pl>
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 DEC3F3A0932; Wed, 4 Aug 2021 13:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 SmuSBnBRf8Gg; Wed, 4 Aug 2021 13:31:30 -0700 (PDT)
Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63443A0931; Wed, 4 Aug 2021 13:31:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 88679600A06EB; Wed, 4 Aug 2021 22:31:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mimuw.edu.pl
Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xNQPj0a1kBOg; Wed, 4 Aug 2021 22:31:23 +0200 (CEST)
Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:6021:1a6c:1c03:8001]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Wed, 4 Aug 2021 22:31:22 +0200 (CEST)
From: Konrad Iwanicki <iwanicki@mimuw.edu.pl>
To: roll@ietf.org
Cc: roll-chairs@ietf.org
Message-ID: <f7a504ac-764d-09e9-d969-067e6a21646a@mimuw.edu.pl>
Date: Wed, 4 Aug 2021 22:31:15 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/SiFBGb3GdZpVbQG5ChhpExRvZco>
Subject: [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: Wed, 04 Aug 2021 20:31:33 -0000

Dear authors,

This is the first review I am doing for IETF's draft, so any suggestions 
on how I could improve the quality of my future reviews are welcome.

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

However, par. 2 of sect. 2.1 (starting with "6LRs that support this 
option") states that "nodes adjust this base value based upon their 
observed congestion, emitting their adjusted DIO value to their children."

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


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.

Therefore, if the draft changes this policy with respect to the 
introduced option, I would expect it to state this change explicitly. 
Such a change would also require answering several questions, notably:
- From which parent do we process the option?
- If only from the preferred parent, what happens if a node has none?
- If from any, then what happens if a node gets different values of min 
priority or DODAG_Size from different parents?

However, I believe that a meta question worth answering first is: Do we 
want to have different min priority values in different subtrees or just 
one global value for the entire DODAG?

Either of the answers in my view requires explicit formulation and 
preferably also an explanation in the draft.


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.

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.


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?


5. It should be made clearer in the draft what is actually being configured.

The only place where field "proxy priority" of EB appears in the entire 
draft is par. 8 of sect. 1. Reading the draft for the first time I was 
confused what min priority for the option is used for and what is 
actually adjusted at various places.


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.

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.

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


Finally, I have numerous small editorial suggestions, but they seem 
immaterial at this point.

Hope the review helps.

Best,
-- 
- Konrad Iwanicki.