Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS - Roll Digest Vol 103, Issue 2

[Zhen Cao <[e-mail]>]

Hi Pascal,

Thanks for discussion.

ERRATA is considered as an error "at the time the document was published ",
I do not think it's the proper way to include new technique modifications.


Also, from the discussion, I feel that we agree there are problems related
to NP-DAO signaling, which is the scope of this PS document.  What you
suggested is a solution to this problem, and the way to handle it, which
can be discussed later in my opinion.

How sounds?

Zhen
On Wed, Aug 10, 2016 at 4:42 PM, Pascal Thubert (pthubert) <
[e-mail]> wrote:

>
>
>
> </PT>
>
>
>
> Do we agree on these additional two changes?
>
>
>
> My conclusion on the work to come is that:
>
>
>
> ·        in the one hand we fix RFC 6550 where it needs to be fixed, and
> I think that this should be done through ERRATA
>
> ·        in the other hand you focus your work on what’s new proposal /
> function and let the group see if that in itself is valuable enough to
> standardize
>
>
>
> What do others think?
>
>
>
> Pascal
>
>
>
> *From:* Rahul Jadhav [mailto:[e-mail]]
> *Sent:* mardi 9 août 2016 20:28
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* Routing Over Low power and Lossy networks <[e-mail]>;
> [e-mail]
>
> *Subject:* Re: [Roll] "Charter inclusion: Work in RPL control messages:
> DIS - Roll Digest Vol 103, Issue 2
>
>
>
> Thanks Pascal for the reasoning,
>
>
>
> @William, would reply you separately, since your questions are different.
>
>
>
> To begin with, i want to point out foll things:
>
> a. an assumption that the old parent can detect child node unavailability
> cannot be relied upon … in berlin i presented the scenarios where such an
> assumption doesn’t hold good.. (https://www.ietf.org/
> proceedings/96/slides/slides-96-roll-2.pdf , slide 96).
>
> b. Yes, the PathSequence usage has a problem … there is ambiguity in 6550
> which has to be handled…
>
>
>
> nonetheless, my point is we currently do not have a solution for efficient
> route invalidation in 6550... subsequent response inline…
>
>
>
>
>
> On Aug 9, 2016, at 7:01 PM, Pascal Thubert (pthubert) <[e-mail]>
> wrote:
>
>
>
> I’m unsure of that, William.
>
>
>
> All in all, I see this as an errata, and I’m not convinced that we need a
> new RFC.
>
>
>
> Here is my understanding (draft authors, please correct me if I missed
> some of your points):
>
>
>
> ·        When an old parent O loses a child, it can only send a no-path
> DAO with the same path sequence S0 as the last DAO it sent.
>
>
>
> [RJ]
>
> an old parent losing a child… this detection is non trivial … such
> detection works only if:
>
> a. there is any p2p traffic in the "previous sub-dodag" with destination
> as the switching node or any of the dependent nodes … such p2p traffic can
> be sparse or non-existent.
>
> b. parent node employs any technique to periodically detect child node
> connectivity … this is non-trivial to implement
>
> c. the target node is a sleepy node then the detection is not possible …
>
> for details pls refer slide 96 of pdf mentioned above.
>
> [/RJ]
>
>
>
>
>
> ·        A new parent N will propagate DAOs with a newer path sequence Sn
> > S0.
>
>
>
> ·        When that newer information hits a common ancestor C of O and N,
> C cleans up its stale state towards O because of the stale sequence, and
> continues propagating the new state towards the root, which in effect
> enables reachability to the child from the root and most of the DODAG, but
> not where a stale state is still present, between C and O.
>
>
>
> ·        The no-DAO is meant to clean up the state between O and C.
>
>
>
> I think I heard at the WG meeting that the no-path DAO would be ignored
> because the sequence is not incremented. To which I’ll point out the item 3
> below from RFC 6550, which was intended to cover that case:
>
>
>
> In Storing mode, a DAO message is "new" if
>
>    it satisfies any of these criteria for a contained Target:
>
>
>
>    1.  it has a newer Path Sequence number,
>
>
>
>    2.  it has additional Path Control bits, or
>
>
>
>    3.  it is a No-Path DAO message that removes the last Downward route
>
>        to a prefix.
>
>
>
> [RJ]
>
> For point 2 and 3, the logic would work only if the same previous
> PathSequence number is used to send the NPDAO/DAO message … A node cannot
> entertain any no-path DAO message with older sequence numbers. The current
> text gives an impression that a No-Path DAO will be honored regardless of
> its PathSeq (I m not sure if “the last Downward route” equates to the same
> PathSeq)
>
> [/RJ]
>
>
>
> It was pointed that next the text says:
>
>
>
>    6.  Nodes SHOULD ignore DAOs without newer sequence numbers and MUST
>
>        NOT process them further.
>
>
>
> I agree this is wrong. The spirit was:
>
>
>
>    6.  Nodes SHOULD ignore DAOs that are not “new” MUST NOT process them
>
>        further.
>
>
>
>
>
> Note that the bug above also impacts the process of getting multiple
> routes down.
>
> The whole design is to send multiple DAOs with a same sequence and NOT
> ignore them.
>
>
>
> [RJ] This is a different case. multiple DAOs generated by same target via
> different parents can have same sequence number. The case described in the
> draft is that "of a non-target node generating an NPDAO on behalf of the
> target node" and choosing a PathSequence on its behalf. But yes, the same
> sequence logic will work here in both the cases. [/RJ]
>
>
>
> e.g.
>
>
>
>                                                         If a DAO
>
>          message containing the same Target is issued to multiple
>
>          parents at a given point in time for the purpose of route
>
>          redundancy, then the Path Sequence is the same in all the DAO
>
>          messages for that same target
>
>
>
> also
>
>
>
>                                       All DAOs generated at the same
>
>    time for the same Target MUST be sent with the same Path Sequence in
>
>    the Transit Information.
>
>
>
>
>
> My suggestion to solve this problem is to post an errata along the spirit
> above and be done with it. This way we are sure that plain RFC 6550
> implementation will look at it. A new RFC may be 1) overkill and 2) ignored.
>
>
>
> [RJ]
>
> Yes the errata is required which fixes part of the problem, but still the
> overall route invalidation is not efficient and depends on old parent
> detecting child node unavailability. And this is the aim of the draft.
> Highlight the problems to begin with and subsequently work on a solution.
>
> [/RJ]
>
>
>
>
>
> Note that RPL also has a dataplane fix to clean reactively this stale
> state with the Forwarding-Error 'F' flag.
>
>
>
> [RJ]
>
> Again Forwarding-Error is a reactive mechanism to remove stale routes.
>
> [/RJ]
>
>
>
>
>
> What do others think?
>
>
>
> Pascal
>
>
>
> *From:* Roll [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *William
> *Sent:* mercredi 10 août 2016 04:08
> *To:* [e-mail]
> *Subject:* Re: [Roll] "Charter inclusion: Work in RPL control messages:
> DIS - Roll Digest Vol 103, Issue 2
>
>
>
> In my opinion, the draft draft-jadhav-roll-no-path-dao-ps-01 is quite
> relevant.
>
> I am just not confident about the second draft
> draft-jadhav-roll-no-path-dao-ps-01.
>
> We have deployed a WSN for experiments, but have not paid attention to
> that no-path DAO problem, so I still confuse about the importance of the
> draft.
>
> Jadhav and Cao, Have you implemented any testbeds for those cases written
> in the draft? Or do you have any paper analyzed those cases in more detail?
>
> If yes, I would like to do some real experiments to evaluate the
> importance of the draft.
>
>
>
>
>
> Kind regards,
>
> William
>
> PhD of Research
>
> IoT based Smart Furniture for Smart Home <http://cuddlyhomeadvisors.com/> Research
> Group
>
>
>
> -----Original Message-----
> From: Roll [mailto:[e-mail] <[e-mail]>] On
> Behalf Of [e-mail]
> Sent: Thursday, August 4, 2016 12:00 PM
> To: [e-mail]
> Subject: Roll Digest, Vol 103, Issue 2
>
>
>
> Send Roll mailing list submissions to
>
>                 [e-mail]
>
>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
>                 https://www.ietf.org/mailman/listinfo/roll
>
> or, via email, send a message with subject or body 'help' to
>
>                 [e-mail]
>
>
>
> You can reach the person managing the list at
>
>                 [e-mail]
>
>
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Roll digest..."
>
>
>
>
>
> Today's Topics:
>
>
>
>    1. Re: "Charter inclusion: Work in RPL control messages: DIS
>
>       Mod. - No-Path DAO" (Caozhen (zcao))
>
>    2. Roll ietf96 minutes (peter van der Stok)
>
>    3. Re: Roll ietf96 minutes (Ines Robles)
>
>
>
>
>
> ----------------------------------------------------------------------
>
>
>
> Message: 1
>
> Date: Thu, 4 Aug 2016 09:03:42 +0000
>
> From: "Caozhen (zcao)" <[e-mail]>
>
> To: "[e-mail]" <[e-mail]>,
>
>                 "Routing Over Low power and Lossy networks" <[e-mail]
> >
>
> Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages:
>
>                 DIS Mod. - No-Path DAO"
>
> Message-ID:
>
>                 <0ADB5996A09C254EB300AB612DA81508215887F1@SZXEMI506-MBX.
> china.huawei.com>
>
>
>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> I would like to support both drafts (I am co-author of the second draft),
> they are certainly relevant to the wg.
>
>
>
> I can contribute the review of the draft-gundogan-roll-dis-modifications.
>
>
>
> -Zhen
>
> > -----Original Message-----
>
> > From: Roll [mailto:[e-mail] <[e-mail]>] On
> Behalf Of peter van der
>
> > Stok
>
> > Sent: Monday, July 25, 2016 7:44 PM
>
> > To: Roll <[e-mail]>
>
> > Subject: [Roll] "Charter inclusion: Work in RPL control messages: DIS
>
> > Mod. - No-Path DAO"
>
> >
>
> > Dear all,
>
> >
>
> > Following the ROLL Meeting at IETF 96, we would like to know your
>
> > opinion about the drafts, presented during IETF95 and IETF96. This is
>
> > the first set of three emails. The adoption of drafts as WG drafts
>
> > will be asked independently dependent on the status of the draft.
>
> >
>
> > A: draft-gundogan-roll-dis-modifications-00
>
> >        DIS Modifications
>
> >
>
> > ?    Is the draft relevant to the working group.?
>
> > ?    Do you foresee to contribute to the work described in the draft ?
>
> > ?    Are you willing to review the draft ?
>
> > ?    Should the draft be rejected by the WG ?
>
> >
>
> > B: draft-jadhav-roll-no-path-dao-ps-01
>
> >        No-Path DAO Problem Statement
>
> >
>
> > ?    Is the draft relevant to the working group.?
>
> > ?    Do you foresee to contribute to the work described in the draft ?
>
> > ?    Are you willing to review the draft ?
>
> > ?    Should the draft be rejected by the WG ?
>
> >
>
> >
>
> > It would be nice to know the reasons why you agree or disagree with
>
> > the drafts
>
> >
>
> >
>
> > Thank you very much,
>
> >
>
> > Peter and Ines
>
> >
>
> > _______________________________________________
>
> > Roll mailing list
>
> > [e-mail]
>
> > https://www.ietf.org/mailman/listinfo/roll
>
>
>
> ------------------------------
>
>
>
> Message: 2
>
> Date: Thu, 04 Aug 2016 13:56:15 +0200
>
> From: peter van der Stok <[e-mail]>
>
> To: Roll <[e-mail]>
>
> Subject: [Roll] Roll ietf96 minutes
>
> Message-ID: <[e-mail]>
>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>
>
> Dear all,
>
>
>
> Many thanks to Dominique for the minutes.
>
> They have been uploaded.
>
>
>
> There are a few speakers denoted with xxx, whose identity could not be
> determined.
>
> Also there is some text by Don and Pascal that has got lost.
>
>
>
> Could these persons complement the information?
>
>
>
> many thanks,
>
>
>
> Peter, Ines.
>
>
>
> --
>
> Peter van der Stok
>
> vanderstok consultancy
>
> mailto: [e-mail]
>
> www: www.vanderstok.org
>
> tel NL: [phone]     F: [phone]
>
>
>
>
>
>
>
> ------------------------------
>
>
>
> Message: 3
>
> Date: Thu, 4 Aug 2016 16:22:23 +0300
>
> From: Ines  Robles <[e-mail]>
>
> To: "[e-mail]" <[e-mail]>,
>
>                 Routing Over Low power and Lossy networks <[e-mail]>
>
> Subject: Re: [Roll] Roll ietf96 minutes
>
> Message-ID:
>
>                 <CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=ScSD0PHozyX5jw@
> mail.gmail.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> The minute can be found here
>
>
>
> https://www.ietf.org/proceedings/96/minutes/minutes-96-roll
>
>
>
> Many thanks to Dominique again :-)
>
>
>
> Peter, Ines.
>
>
>
> 2016-08-04 14:56 GMT+03:00 peter van der Stok <[e-mail]>:
>
>
>
> > Dear all,
>
> >
>
> > Many thanks to Dominique for the minutes.
>
> > They have been uploaded.
>
> >
>
> > There are a few speakers denoted with xxx, whose identity could not be
>
> > determined.
>
> > Also there is some text by Don and Pascal that has got lost.
>
> >
>
> > Could these persons complement the information?
>
> >
>
> > many thanks,
>
> >
>
> > Peter, Ines.
>
> >
>
> > --
>
> > Peter van der Stok
>
> > vanderstok consultancy
>
> > mailto: [e-mail]
>
> > www: www.vanderstok.org
>
> > tel NL: [phone]     F: [phone]
>
> >
>
> > _______________________________________________
>
> > Roll mailing list
>
> > [e-mail]
>
> > https://www.ietf.org/mailman/listinfo/roll
>
> >
>
> -------------- next part --------------
>
> An HTML attachment was scrubbed...
>
> URL: <https://mailarchive.ietf.org/arch/browse/roll/attachments/
> 20160804/a0898b03/attachment.html>
>
>
>
> ------------------------------
>
>
>
> Subject: Digest Footer
>
>
>
> _______________________________________________
>
> Roll mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
> ------------------------------
>
>
>
> End of Roll Digest, Vol 103, Issue 2
>
> ************************************
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>