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

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

Hello Zhen:

The changes I proposed below really fix errors "at the time the document was published " or lack of clarity of the existing text. RFC 6550 must be clarified for the mechanism already therein; that is what I want to do here.
This does not mean that a new mechanism cannot be specified. The new mechanism has to provide value add vs. RFC6550 as it was designed to operate "at the time the document was published”.

Cheers,

Pascal

From: Roll [mailto:[e-mail]] On Behalf Of Zhen Cao
Sent: jeudi 11 août 2016 07:17
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS - Roll Digest Vol 103, Issue 2

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]<mailto:[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]<mailto:[e-mail]>]
Sent: mardi 9 août 2016 20:28
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Cc: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]] On Behalf Of William
Sent: mercredi 10 août 2016 04:08
To: [e-mail]<mailto:[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]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, August 4, 2016 12:00 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Roll Digest, Vol 103, Issue 2

Send Roll mailing list submissions to
                [e-mail]<mailto:[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]<mailto:[e-mail]>

You can reach the person managing the list at
                [e-mail]<mailto:[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]<mailto:[e-mail]>>
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>,
                "Routing Over Low power and Lossy networks" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages:
                DIS Mod. - No-Path DAO"
Message-ID:
                <[e-mail]<mailto:[e-mail]>>

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]] On Behalf Of peter van der
> Stok
> Sent: Monday, July 25, 2016 7:44 PM
> To: Roll <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
To: Roll <[e-mail]<mailto:[e-mail]>>
Subject: [Roll] Roll ietf96 minutes
Message-ID: <[e-mail]<mailto:[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]<mailto:[e-mail]>
www: www.vanderstok.org<http://www.vanderstok.org/>
tel NL: [phone]<tel:%2B31%280%29492474673>     F: [phone]<tel:%2B33%280%29966015248>



------------------------------

Message: 3
Date: Thu, 4 Aug 2016 16:22:23 +0300
From: Ines  Robles <[e-mail]<mailto:[e-mail]>>
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>,
                Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] Roll ietf96 minutes
Message-ID:
                <CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[e-mail]<mailto:CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[e-mail]>>
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]<mailto:[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]<mailto:[e-mail]>
> www: www.vanderstok.org<http://www.vanderstok.org/>
> tel NL: [phone]<tel:%2B31%280%29492474673>     F: [phone]<tel:%2B33%280%29966015248>
>
> _______________________________________________
> Roll mailing list
> [e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll


------------------------------

End of Roll Digest, Vol 103, Issue 2
************************************

_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll