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

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

Hello Rahul:

A number of good points down there. Let us see:

[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]

<PT>

RPL does not seek to rapidly clean up routes that are not being used. This is done to maintain the control cost below the traffic cost. That was an initial requirement for the protocol design.  In practice this is also why RFC 6550 has the Forwarding-Error 'F' flag. I agree that a change in that philosophy, or an addition to support more aggressiveness, is a different draft. TBD is whether we need/want that. If you look at it, the general case is hard to figure because you never know. Maybe a used is changing a battery; if so, the loss of the node is transient, and the node will come back. Cleaning up states during that period is a waste of resources. This is why we have a MAY in:

   5.  If messages to an advertised Downward address suffer from a
       forwarding error, Neighbor Unreachable Detection (NUD), or
       similar failure, a node MAY mark the address as unreachable and
       generate an appropriate No-Path DAO.

As it goes, RPL includes detection mechanisms, based on DTSN in the DIO, see section 9.6. As you say, this is only applicable to certain cases, e.g. not to sleeping devices with unknown schedules. This can be useful when RPL operates in non-LLN interfaces for instance, when there is a scheduled return channel, or in case of mobility.

   Destination Advertisement Trigger Sequence Number (DTSN): 8-bit
         unsigned integer set by the node issuing the DIO message.  The
         Destination Advertisement Trigger Sequence Number (DTSN) flag
         is used as part of the procedure to maintain Downward routes.
         The details of this process are described in Section 9<https://tools.ietf.org/html/rfc6550#section-9>.

…

   1.  If a node hears one of its DAO parents increment its DTSN, the
       node MUST schedule a DAO message transmission using rules in
       Sections 9.3<https://tools.ietf.org/html/rfc6550#section-9.3> and 9.5<https://tools.ietf.org/html/rfc6550#section-9.5>.


</PT>




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]

<PT>

True, this needs to be clarified.  Again this is errata land, not new RFC. I’d suggest

Before:



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.




After:



                  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 a same Path Sequence number and either



       * it has additional Path Control bits, or



       * it is a No-Path DAO message







The point on ”the last Downward route to a prefix “ is really related to sending no-paht DAO to a parent. You only want to do that if you destroyed the last Downward route to a prefix or a host. Removing that text from above means that we also need to clarify


Before:




   2.  On receiving a unicast DAO, a node MUST compute if the DAO would
       change the set of prefixes that the node itself advertises.  This
       computation SHOULD include consultation of the Path Sequence
       information in the Transit Information options associated with
       the DAO, to determine if the DAO message contains newer
       information that supersedes the information already stored at the
       node.  If so, the node MUST generate a new DAO message and
       transmit it, following the rules in Section 9.5<https://tools.ietf.org/html/rfc6550#section-9.5>.  Such a change
       includes receiving a No-Path DAO.

After:

   2.  On receiving a unicast DAO, a node MUST compute if the DAO would
       change the set of prefixes that the node itself advertises.  This
       computation SHOULD include consultation of the Path Sequence
       information in the Transit Information options associated with
       the DAO, to determine if the DAO message contains newer
       information that supersedes the information already stored at the
       node.  If so, the node MUST generate a new DAO message and
       transmit it, following the rules in Section 9.5<https://tools.ietf.org/html/rfc6550#section-9.5>.  Such a change

       includes removing the last Downward route to a particular target

       upon receiving a No-Path DAO.

</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]<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]     F: [phone]



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

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]     F: [phone]
>
> _______________________________________________
> 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