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

Konrad Iwanicki <> Mon, 09 August 2021 21:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB0D43A176B; Mon, 9 Aug 2021 14:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5i-nVdRurxlE; Mon, 9 Aug 2021 14:09:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 579E63A1704; Mon, 9 Aug 2021 14:09:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B60761DA0897; Mon, 9 Aug 2021 23:09:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id jFWhX80TR_01; Mon, 9 Aug 2021 23:09:45 +0200 (CEST)
Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:3194:b38d:ab3e:5e37]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (Postfix) with ESMTPSA; Mon, 9 Aug 2021 23:09:43 +0200 (CEST)
To: Routing Over Low power and Lossy networks <>, Michael Richardson <>
References: <> <26245.1628534920@localhost>
From: Konrad Iwanicki <>
Message-ID: <>
Date: Mon, 9 Aug 2021 23:09:37 +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
In-Reply-To: <26245.1628534920@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Aug 2021 21:09:58 -0000

Dear Michael and all,

First of all, thank you for your kind words regarding the review. I am 
actually planning to attend the August interim, because I will be 
presenting the rnfd draft, so we can discuss the enrollment priority 
draft in depth as well.

Below I just quickly reply inline to Michael's comments as they led to a 
new version of the draft. I was actually replying to Pascal's and 
Rahul's comments while the new draft version appeared, and the new 
version still has some issues, which I wanted to point out in those replies.

So what do I do then, write another review for the new version where I 
can explain those issues?

On 09/08/2021 20:48, Michael Richardson wrote:
>      > 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.

I believe RFC 6550 uses term "parent" for any neighbor with a rank lower 
than the node itself and "preferred parent" for the parent (conceptually 
a single one) that the node uses as the next hop on its upward routes. 
This may be one of the sources of my confusion. After your explanation, 
I understand your point of view on the protocol. Thanks.

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

OK but:

1. This is not mentioned in the new version of the draft.

2. In non-storing mode, this would generate upward traffic from every 
member of a DODAG, which may be problematic. To explain, suppose that 
the MOP is indeed non-storing and that the root sets its min priority to 
0x7f to disable enrollments because it is unable to handle any more 
traffic. According to your suggestion, doing this, the root increments 
its DTSN. Per point 1. of the ordered list in Sect. 9.6 or RFC 6550, 
every node seeing the incremented DTSN from its parent issues a DAO 
message upwards. Per point 2. of the same list, the node also increments 
its own DTSN. In effect, every node in the DODAG sends a DAO to the 
root, which may swamp the root---a situation that the root wanted to 
avoid in the first place by disabling enrollments. This situation may be 
even worse if DAO-Acks are to be sent in reply to the DAOs.

3. Even if the this approach were covered in the draft, it still has 
some issues, which I was about to explain but the new version of the 
draft appeared.

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

I would say this need not be the best choice per:

a) my reply above

b) the fact that DTSN is conceptually for something else.

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

OK, now I understand. However, this also generates some further issues I 
wanted to point in my reply to Rahul's and Pascal's comments.

- Konrad Iwanicki.