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

> Le 9 août 2021 à 23:10, Konrad Iwanicki <iwanicki@mimuw.edu.pl> a écrit :
> 
> 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:
> 

Actually not OK 

The DTSN triggers DAO messages; this seems unrelated and undesirable. 

Maybe the suggestion was really to resync the DAG to a new version that would operate with the new minimum?

That’s actually not a convincing idea either, since the minimum value of priority is not configured but a Dynamic computation that may change a lot mostly during the DODAG formation.

> 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.
> 
True 
It’s not  just non storing it’s all modes

> 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.
> 
Yes we need to sync. I think Michael still has in mind that the minimum is incremented down. That was the initial idea. 

But that’s creating more problems that help mostly due to the dodag structure and cut the capability for the root to give a direct feedback to the nodes. I now think this information should be set by the root and remain throughout the dodag.

To be discussed at the next interim…

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

And my draft on versioning the configuration is also something else. We need a new sequence either in this option or global to all future status options from the root. That sequence would not alter the RPL operation as version and DTSN do.

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

Looking forward. Thanks a bunch Konrad for opening the discussion on the draft. This is incredibly helpful!

You all keep safe,

Pascal 

> 
> Best,
> -- 
> - Konrad Iwanicki.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll