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

From: "William" <[email-masked]>
Date: Tue, 9 Aug 2016 19:08:28 -0700

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:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, August 4, 2016 12:00 PM
To: [email-masked]
Subject: Roll Digest, Vol 103, Issue 2

Send Roll mailing list submissions to

                 <mailto:[email-masked]> [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit

                 <https://www.ietf.org/mailman/listinfo/roll>
https://www.ietf.org/mailman/listinfo/roll

or, via email, send a message with subject or body 'help' to

                 <mailto:[email-masked]> [email-masked]

You can reach the person managing the list at

                 <mailto:[email-masked]> [email-masked]

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)" < <mailto:[email-masked]> [email-masked]>

To: " <mailto:[email-masked]> [email-masked]" <
<mailto:[email-masked]> [email-masked]>,

                "Routing Over Low power and Lossy networks" <
<mailto:[email-masked]> [email-masked]>

Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages:

                DIS Mod. - No-Path DAO"

Message-ID:

                <
<mailto:[email-masked].
com>
[email-masked]>

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:[email-masked]> mailto:[email-masked]]
On Behalf Of peter van der 

> Stok

> Sent: Monday, July 25, 2016 7:44 PM

> To: Roll < <mailto:[email-masked]> [email-masked]>

> 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

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/roll>
https://www.ietf.org/mailman/listinfo/roll

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

Message: 2

Date: Thu, 04 Aug 2016 13:56:15 +0200

From: peter van der Stok < <mailto:[email-masked]> [email-masked]>

To: Roll < <mailto:[email-masked]> [email-masked]>

Subject: [Roll] Roll ietf96 minutes

Message-ID: < <mailto:[email-masked]>
[email-masked]>

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:  <mailto:[email-masked]> [email-masked]

www:  <http://www.vanderstok.org> www.vanderstok.org

tel NL: +31(0)492474673     F: +33(0)966015248

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

Message: 3

Date: Thu, 4 Aug 2016 16:22:23 +0300

From: Ines  Robles < <mailto:[email-masked]>
[email-masked]>

To: " <mailto:[email-masked]> [email-masked]" <
<mailto:[email-masked]> [email-masked]>,

                Routing Over Low power and Lossy networks <
<mailto:[email-masked]> [email-masked]>

Subject: Re: [Roll] Roll ietf96 minutes

Message-ID:

                <
<mailto:CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[email-masked]>
CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[email-masked]>

Content-Type: text/plain; charset="utf-8"

The minute can be found here

 <https://www.ietf.org/proceedings/96/minutes/minutes-96-roll>
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 < <mailto:[email-masked]>
[email-masked]>:

> 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:  <mailto:[email-masked]> [email-masked]

> www:  <http://www.vanderstok.org> www.vanderstok.org

> tel NL: +31(0)492474673     F: +33(0)966015248

> _______________________________________________

> Roll mailing list

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/roll>
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>
https://mailarchive.ietf.org/arch/browse/roll/attachments/20160804/a0898b03/
attachment.html>

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

Subject: Digest Footer

_______________________________________________

Roll mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/roll>
https://www.ietf.org/mailman/listinfo/roll

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

End of Roll Digest, Vol 103, Issue 2

************************************

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Aug 2016 13:31:17 +0000

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.

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

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

Note that RPL also has a dataplane fix to clean reactively this stale state with the Forwarding-Error 'F' flag.

What do others think?

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of William
Sent: mercredi 10 août 2016 04:08
To: [email-masked]
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:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, August 4, 2016 12:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Roll Digest, Vol 103, Issue 2

                [email-masked]<mailto:[email-masked]>

                [email-masked]<mailto:[email-masked]>

                [email-masked]<mailto:[email-masked]>

When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..."

Today's Topics:

Message: 1

From: "Caozhen (zcao)" <[email-masked]<mailto:[email-masked]>>

To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

                "Routing Over Low power and Lossy networks" <[email-masked]<mailto:[email-masked]>>

                DIS Mod. - No-Path DAO"

Message-ID:

                <[email-masked]<mailto:[email-masked]>>

I would like to support both drafts (I am co-author of the second draft), they are certainly relevant to the wg.

-Zhen

> From: Roll [mailto:[email-masked]] On Behalf Of peter van der

> To: Roll <[email-masked]<mailto:[email-masked]>>

> [email-masked]<mailto:[email-masked]>

Message: 2

From: peter van der Stok <[email-masked]<mailto:[email-masked]>>

To: Roll <[email-masked]<mailto:[email-masked]>>

Message-ID: <[email-masked]<mailto:[email-masked]>>

Dear all,

They have been uploaded.

There are a few speakers denoted with xxx, whose identity could not be determined.

many thanks,

Peter, Ines.

--

Peter van der Stok

vanderstok consultancy

mailto: [email-masked]<mailto:[email-masked]>

www: www.vanderstok.org<http://www.vanderstok.org>

Message: 3

From: Ines  Robles <[email-masked]<mailto:[email-masked]>>

To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

                Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>

Message-ID:

                <CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[email-masked]<mailto:CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[email-masked]>>

Peter, Ines.

> mailto: [email-masked]<mailto:[email-masked]>

> www: www.vanderstok.org<http://www.vanderstok.org>

> [email-masked]<mailto:[email-masked]>

-------------- next part --------------

URL: <https://mailarchive.ietf.org/arch/browse/roll/attachments/20160804/a0898b03/attachment.html>

Subject: Digest Footer

Roll mailing list

[email-masked]<mailto:[email-masked]>

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 9 Aug 2016 23:58:03 +0530

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 <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) <[email-masked]> 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.
>  

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

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

>    6.  Nodes SHOULD ignore DAOs that are not “new” MUST NOT process them
>        further.
>  
>  

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

> 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) ove…

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

> IoT based Smart Furniture for Smart Home <http://cuddlyhomeadvisors.com/> Research Group
>  
> From: Roll [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
>  
>                 https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
>                 [email-masked] <mailto:[email-masked]>
>  
>                 [email-masked] <mailto:[email-masked]>
>  
> From: "Caozhen (zcao)" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>                 "Routing Over Low power and Lossy networks" <[email-masked] <mailto:[email-masked]>>
>                 <[email-masked] <mailto:[email-masked]>>
>                 
> > From: Roll [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of peter van der
> > Stok
> > To: Roll <[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
>  
> From: peter van der Stok <[email-masked] <mailto:[email-masked]>>
> To: Roll <[email-masked] <mailto:[email-masked]>>
> Message-ID: <[email-masked] <mailto:[email-masked]>>
> mailto: [email-masked] <mailto:[email-masked]>
> www: www.vanderstok.org <http://www.vanderstok.org/>
> From: Ines  Robles <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>                 Routing Over Low power and Lossy networks <[email-masked] <mailto:[email-masked]>>
>                 <CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[email-masked] <mailto:CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=[email-masked]>>
> https://www.ietf.org/proceedings/96/minutes/minutes-96-roll <https://www.ietf.org/proceedings/96/minutes/minutes-96-roll>
>  
> 2016-08-04 14:56 GMT+03:00 peter van der Stok <[email-masked] <mailto:[email-masked]>>:
>  
> > Dear all,
> > 
> > mailto: [email-masked] <mailto:[email-masked]>
> > www: www.vanderstok.org <http://www.vanderstok.org/>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
> > 
> URL: <https://mailarchive.ietf.org/arch/browse/roll/attachments/20160804/a0898b03/attachment.html <https://mailarchive.ietf.org/arch/browse/roll/attachments/20160804/a0898b03/attachment.html>>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
>  
>  
> [email-masked]

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 10 Aug 2016 00:29:34 +0530

Hi William, 
Pls find my comments inline.

Regards,
Rahul

> On Aug 10, 2016, at 7:38 AM, William <[email-masked]> wrote:
> 

Is/Are there any specific point(s) you are not confident about?

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

The current draft is a problem statement only draft which also addresses limitations of existing solutions. Let me give some background on how we ended up taking this problem statement more seriously … We are designing/implementing a solution and part of the solution depended upon how efficiently the routing tables are maintained or whether routing tables reflected the latest state of network topology (since decisions were to be made based upon how much a given router/6LR is loaded and one of the parameter is the routing table size of the 6LR).  We found that current route invalidation mechanism has limitations and the routing tables in most cases were carrying stale routes for a long time. We are currently working on a solution proposition to improvise on this.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Aug 2016 08:42:47 +0000

Hello Rahul:

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

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

       to a prefix.

[RJ]

<PT>

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

Before:

       to a prefix.

After:

   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:[email-masked]]
Sent: mardi 9 août 2016 20:28
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Routing Over Low power and Lossy networks <[email-masked]>; [email-masked]
Subject: Re: [Roll] "Charter inclusion: Work in RPL control messages: DIS - Roll Digest Vol 103, Issue 2

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…

On Aug 9, 2016, at 7:01 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

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

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

       to a prefix.

[RJ]

       further.

e.g.

                                                        If a DAO

also

   the Transit Information.

[RJ]

[RJ]

What do others think?

Pascal

Kind regards,
William
PhD of Research

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, August 4, 2016 12:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Roll Digest, Vol 103, Issue 2

Today's Topics:

Message: 1

-Zhen

Message: 2

Dear all,

many thanks,

Peter, Ines.

--
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]<mailto:[email-masked]>
www: www.vanderstok.org<http://www.vanderstok.org/>
tel NL: +31(0)492474673     F: +33(0)966015248

Message: 3

Peter, Ines.

2016-08-04 14:56 GMT+03:00 peter van der Stok <[email-masked]<mailto:[email-masked]>>:

> www: www.vanderstok.org<http://www.vanderstok.org/>
-------------- next part --------------

Subject: Digest Footer

---

From: Zhen Cao <[email-masked]>
Date: Thu, 11 Aug 2016 13:16:37 +0800

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) <
[email-masked]> wrote:

> ·        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:[email-masked]]
> *Sent:* mardi 9 août 2016 20:28
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Routing Over Low power and Lossy networks <[email-masked]>;
> [email-masked]
>
> *Subject:* Re: [Roll] "Charter inclusion: Work in RPL control messages:
> DIS - Roll Digest Vol 103, Issue 2
>
>
>
> 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).
>
> nonetheless, my point is we currently do not have a solution for efficient
> route invalidation in 6550... subsequent response inline…
>
>
>
>
>
> ·        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]
>
> 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
>
> ·        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.
>
>
>
> 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:
>
>
>
> 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]
>
>
>
> [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
>
> 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]
>
> *From:* Roll [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *William
> *Sent:* mercredi 10 août 2016 04:08
> *To:* [email-masked]
> *Subject:* Re: [Roll] "Charter inclusion: Work in RPL control messages:
> DIS - Roll Digest Vol 103, Issue 2
>
>
>
> 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?
>
> From: Roll [mailto:[email-masked] <[email-masked]>] On
> Behalf Of [email-masked]
>                 [email-masked]
>                 [email-masked]
>                 [email-masked]
> From: "Caozhen (zcao)" <[email-masked]>
>
> To: "[email-masked]" <[email-masked]>,
>
>                 "Routing Over Low power and Lossy networks" <[email-masked]
> >
>
>                 <0ADB5996A09C254EB300AB612DA81508215887F1@SZXEMI506-MBX.
> china.huawei.com>
>
>
>
> > From: Roll [mailto:[email-masked] <[email-masked]>] On
> Behalf Of peter van der
>
> > Stok
>
> > To: Roll <[email-masked]>
> From: peter van der Stok <[email-masked]>
>
> To: Roll <[email-masked]>
>
> Message-ID: <[email-masked]>
>
> mailto: [email-masked]
>
> www: www.vanderstok.org
>
> From: Ines  Robles <[email-masked]>
>
> To: "[email-masked]" <[email-masked]>,
>
>                 Routing Over Low power and Lossy networks <[email-masked]>
>
>                 <CAP+sJUd7ntWSjr4mTntAW=bX5XyqCfmjdPX=ScSD0PHozyX5jw@
> mail.gmail.com>
>
> 2016-08-04 14:56 GMT+03:00 peter van der Stok <[email-masked]>:
>
>
>
> > Dear all,
>
> >
>
> > mailto: [email-masked]
>
> > www: www.vanderstok.org
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Aug 2016 08:31:18 +0000

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:[email-masked]] On Behalf Of Zhen Cao
Sent: jeudi 11 août 2016 07:17
To: Routing Over Low power and Lossy networks <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:

</PT>

•        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:[email-masked]<mailto:[email-masked]>]
Sent: mardi 9 août 2016 20:28
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

[RJ]

       to a prefix.

[RJ]

       further.

e.g.

                                                        If a DAO

also

   the Transit Information.

[RJ]

[RJ]

What do others think?

Pascal

Kind regards,
William
PhD of Research

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, August 4, 2016 12:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Roll Digest, Vol 103, Issue 2

Today's Topics:

Message: 1

-Zhen

Message: 2

Dear all,

many thanks,

Peter, Ines.

--
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]<mailto:[email-masked]>
www: www.vanderstok.org<http://www.vanderstok.org/>
tel NL: +31(0)492474673<tel:%2B31%280%29492474673>     F: +33(0)966015248<tel:%2B33%280%29966015248>

Message: 3

Peter, Ines.

2016-08-04 14:56 GMT+03:00 peter van der Stok <[email-masked]<mailto:[email-masked]>>:

> tel NL: +31(0)492474673<tel:%2B31%280%29492474673>     F: +33(0)966015248<tel:%2B33%280%29966015248>
>
-------------- next part --------------

Subject: Digest Footer