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

["Pascal Thubert (pthubert)" <[e-mail]>]

Great! 

Please ask the chairs for 20-30 minutes at the interim. Since we want to ship the draft, this is probably urgent enough and interesting enough to justify aa large slot with enough discussion time to reach consensus.

Keep safe;

Pascal

> -----Original Message-----
> From: Konrad Iwanicki <[e-mail]>
> Sent: mardi 10 août 2021 11:01
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Cc: [e-mail]; Michael Richardson <[e-mail]>;
> Pascal Thubert (pthubert) <[e-mail]>
> Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04
> 
> Hi Pascal and all,
> 
> Thanks for the comments. Now I have a full picture of how each of you
> envision the protocol. Before the interim, I will try up to write up all
> my remarks regarding these ideas and the issues I mentioned throughout my
> last reply, so that hopefully we have some starting point for discussion.
> 
> I will probably close the thread at this point and post an e-mail as a
> review of version 05.
> 
> Best,
> --
> - Konrad Iwanicki.
> 
> On 10.08.2021 09:24, Pascal Thubert (pthubert) wrote:
> >
> >
> >> Le 9 août 2021 à 23:10, Konrad Iwanicki <[e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/roll
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> >
>