Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

From: "Li Zhao (liz3)" <[email-masked]>
Date: Fri, 18 Oct 2019 03:26:56 +0000

Hello Authors,

After reviewing this draft, I have some concerns as following:

1. In section 5
   >If the link MTU does not permit to send a single DIO message with all the options packaged then the options may be spread over multiple consecutive DIO messages with the same RCSS that are sent in a rapid sequence.

What about the case that child lost one of the fragment? E.g. parent sends RIO/DCO/RIO in three packets because of MTU, child lost DCO. Next time, parent only sends out AOO with the same RCSS. So this child need to wait SEQUENCE_WINDOW for next time's full option advertisement.

2. Is AOO necessary? If DIO can fragment options and don't always send all options, can we use DIO without options to indicate the AOO? 
    The shortest DIO Base Object without DODAGID is only 8 bytes.

3. In section 6
> A child can resynchronize any of the protected options to the latest RCSS by sending a DIS Message to a candidate parent that advertises that RCSS in DIO messages. 
> The child MUST set the desired combination of 'R', 'D', 'P', 'M' and 'O' flags to indicate the option(s) that it needs updated.

Is there a case that root removes some options such as GCO after network formed? If so, parent may stop sending GCO and increment RCSS, how does child know that it should stop request GCO?

Best regards,
Li

On 2019/10/17, 23:51, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    Dear all:
    
    This update clarifies the use of the new DIO sequence counter and the method to pull the update from a  parent.
    Comments welcome!
    
    Pascal
    
    -----Original Message-----
    From: [email-masked] <[email-masked]> 
    Sent: jeudi 17 octobre 2019 17:46
    To: Pascal Thubert (pthubert) <[email-masked]>; Rahul Jadhav <[email-masked]>; Rahul Arvind Jadhav <[email-masked]>; Dominique Barthel <[email-masked]>
    Subject: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

    A new version of I-D, draft-thubert-roll-eliding-dio-information-01.txt
    has been successfully submitted by Pascal Thubert and posted to the IETF repository.
    
    Name:		draft-thubert-roll-eliding-dio-information
    Revision:	01
    Title:		Eliding and Querying RPL Information
    Document date:	2019-10-17
    Group:		Individual Submission
    Pages:		13
    URL:            https://www.ietf.org/internet-drafts/draft-thubert-roll-eliding-dio-information-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-thubert-roll-eliding-dio-information/
    Htmlized:       https://tools.ietf.org/html/draft-thubert-roll-eliding-dio-information-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-roll-eliding-dio-information
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-thubert-roll-eliding-dio-information-01
    
    Abstract:
       This document presents a method to safely elide a group of global RPL
       options by synchonizing the state associated with each of these
       options between parent and child using a new sequence counter in DIO
       messages.  A child that missed a DIO message with an update of any of
       those protected options detects it by the change of sequence counter
       and queries the update with a DIS Message.

    
    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat
    
    _______________________________________________
    Roll mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Oct 2019 13:20:12 +0000

Hello Li : )

Many thanks for your review. Your comments are really useful to improve the clarity of the doc. 
Let's see:

1. In section 5

<Pascal> The child cannot use that parent and the associated parameters including RCSS until it has synchronized. Which means that all the options must be to their latest announced level. If the child did not get them all (e.g., it missed the DCO per your example) then it needs to resend the DIS with the bits associated to the DCO. There is (very little) text about that "
  The options MAY be spread over more than one DIO
   message sent in a quick sequence and the child SHOULD wait a
   reasonable technology-dependent time before it retries the request.
"
I can clarify, what about:
"                                            The options MAY be spread over more than
   one DIO message sent in a quick sequence. It is possible that the DIS
   is not received by the parent or that a DIO that carries all or subset 
   of the options is lost in return. In that case the child needs to resend
   a DIS with the bits associated to the options that are still missing after
   reasonable technology-dependent time before it retries the request.
   The child may use any parent that advertises the RCSS to get any of
   The options up to that level. 
"

<Pascal> AOO is RECOMMENDED to elide the option. A DIO an option elided (no option, no abbreviation) and an unchanged RCSS is perfectly OK. But if an option is elided AND the RCSS is incremented then after a reasonable time-out the children will pull the options to check if they changed and the parent will need to send either the AOO or the option in full or both in which case the RCSS of the AOO wins. It is always possible to place the option in full without a AOO but if it is done with an increased RCSS in the DIO that will mechanically increase the "RCSS of the option" as seen by the children and will cause the whole subdag to pull the option to no avail. 

Changes:
Old
"
   When a protected option is unchanged from the previous DIO(s), the Root MAY
   replace it with its abbreviated version. The abbreviated version of an option
   is transported in a 4-bytes long Abbreviated Option Option (AOO). The AOO
   indicates the RCSS at which the protected option was last changed."
New
"
   The abbreviated version of an option is a replacement for any option. It does
   not advertise the content of the option but indicates the sender's value for
   the RCSS of that option. It is transported in a 4-bytes long Abbreviated
   Option Option (AOO) with a format as below:
"
+ moved elsewhere:
" 
   Protected options may be sent in full, elided, or in the abbreviated
   form.  Which form to use depends on the RCSS of the option that a
   parent maintains:

   *  A parent MAY use either form when the RCSS is not changed from a
      previous DIO; eliding options is PREFERRED in stable conditions to
      save resources.

   *  When a protected option is updated, the RCSS is mechanically
      incremented, and the new option MUST be sent in full on the first
      DIO that advertises that new RCSS and SHOULD NOT add the
      corresponding AOO.

   *  When the RCSS is updated but a protected option is unchanged, the
      parent SHOULD NOT fully elide the option as it may cause multiple
      children to resynchronize it to no avail.  The use of AOO is
      RECOMMENDED unless it may cause a desynchronization for that
      option, in which case the option SHOULD be placed in full more in
      Section 5.3. 
"

3. In section 6

<Pascal>
Not the way the spec is written. You'd need all these options or we need to add the 5 flags in the DIO to indicate which exist.
I'm open to both ways. What makes most sense for you?

Many thanks again Li, for your excellent comments.

Pascal

    Dear all:

    Pascal
    
    -----Original Message-----
    From: [email-masked] <[email-masked]> 
    Sent: jeudi 17 octobre 2019 17:46
    To: Pascal Thubert (pthubert) <[email-masked]>; Rahul Jadhav <[email-masked]>; Rahul Arvind Jadhav <[email-masked]>; Dominique Barthel <[email-masked]>
    Subject: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

    
    Abstract:

    
    
    The IETF Secretariat

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 21 Oct 2019 03:26:55 +0000

Hello Pascal,

Please see my comments inline...

Best regards,
Li

On 2019/10/18, 21:21, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Li : )

    1. In section 5

[Li] Do you mean that child should know ALL option type it needs before select the parent? E.g. one child need R/D/P/M/O to join network but another child only need R/D/P.
So how does child know this info? Is it pre-defined in child?

    
 
 [Li] Agree, AOO is better than DIO with no option. It’s a nice abbreviated mechanism for RPL Control Message.
       Can we consider to extend AOO for DAO? Maybe put AOO in a new Control Message Options, then DIO/DAO can both leverage it.
       In some case, child will send large DAO packet to parent periodically. E.g. 1. child notifies its capability to parent .2 child has several RPL Target or Transit Information (storing mode?).

    Changes:
    Old
    "

    

    3. In section 6

    <Pascal>
    Not the way the spec is written. You'd need all these options or we need to add the 5 flags in the DIO to indicate which exist.
    I'm open to both ways. What makes most sense for you?
[Li]  It sounds good if all these 5 options are needed before joining network. 

    Pascal    

        Dear all:

        Pascal
        
        -----Original Message-----
        From: [email-masked] <[email-masked]> 
        Sent: jeudi 17 octobre 2019 17:46
        To: Pascal Thubert (pthubert) <[email-masked]>; Rahul Jadhav <[email-masked]>; Rahul Arvind Jadhav <[email-masked]>; Dominique Barthel <[email-masked]>
        Subject: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

        
        Abstract:

        
        
        The IETF Secretariat

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Oct 2019 09:57:23 +0000

Hello Li (and all, please read on as there are additional things we could be doing with the draft listed below)

Let's see below

<Pascal> The draft assumes that all R/D/P/M/O are always present and always needed. This seems to be the general case. We can make it so that one option would not be present by indicating in the DIO if you think that case is relevant. Please let me know. 

But how will a child know that it does not need an option that is present? Maybe there is something in there that is mandatory to know, e.g., to act as a router. We could say that a node that does not pull all the options can only act as a leaf. Is that what you have in mind?

    

<Pascal> Yes we could. Say that the content of a non-storing DAO is fully stable, it could be all replaced by a sequence. Would you be interested in adding that?

If we have to abbreviate elements therein, per target, then we still need to indicate the target so we'll save little, and a different technique like indexing the targets with a BIER bit, would be more efficient.

Many thanks again and again Li, for your excellent comments.
    
Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 22 Oct 2019 02:28:27 +0000

Hello Pascal,

It looks good if router always need these options. And if a node wants to act as a leaf, it can only request R/D/P.

I'm interested and it's my pleasure to add some sections for AOO-DAO. I'll send it to you later.

Best regards,
Li

On 2019/10/21, 17:58, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    Let's see below

    

        

    

    Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Oct 2019 05:57:51 +0000

Hello Li

Would be great!

The xml is available on github under roll-wg.
My expectation is that the source of the non storing DAO increases a sequence nb when there is a change and abbreviates it when there is none. 

You need to think of what happens when the updated DAO is lost, eg MUST an ack or something and only abbreviate after a positive DAO ACK...

Regards,

Pascal

> Le 22 oct. 2019 à 04:29, Li Zhao (liz3) <[email-masked]> a écrit :
> 
> Hello Pascal,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Oct 2019 08:53:28 +0000

Hello Again Li:

I looked at it and an simple step could be that when a node receives a DAO-ACK for a given DAO sequence, then if the next DAO has the same content the node may reuse the DAO sequence and elide the options. It may also decide not refrain from asking an ack, at the risk that the DAO is lost and the state times out at the DAO receiver.

All the best;

Pascal

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 22 octobre 2019 07:58
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

Hello Li

Would be great!

Regards,

Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 22 Oct 2019 11:26:36 +0000

Hello Pascal,

Agree with you.
We can use AOO with last Modification DAO sequence to elide all options in DAO. In this case, we can ignore the Abbreviated Option field or set it to 0xFF. Which do you prefer?

For the DAO lost case, even in normal DAO case, node has the risk of lost DAO message. Node should set 'K' flag according to different network environment. 
It should also work in DAO-AOO case. Admin can balance the risk of lost DAO message and 4-bytes DAO-ACK load.

Best regards,
Li

On 2019/10/22, 16:53, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Again Li:

    All the best;
    
    Pascal
    
    -----Original Message-----
    From: Roll <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
    Sent: mardi 22 octobre 2019 07:58
    To: Routing Over Low power and Lossy networks <[email-masked]>
    Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
    
    Hello Li
    
    Would be great!

    
    Regards,
    
    Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 22 Oct 2019 14:36:04 +0000

Hello Again Pascal,

I've written it down but it seems that I don't have permission to push it to github.
The main change is in section 4.3 as following:

The abbreviated version of an option is a replacement for any option. 
   It does not advertise the content of the option but indicates the
   sender's value for the last modified sequence of that option. It
   is transported in a 4-bytes long Abbreviated Option Option (AOO). 
   AOO MAY be present in DIO and DAO messages as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Type  | Option Length | Abbrev. opt.  | Last Mod Seq. |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: Abbreviated Option Option Format

   Option fields:

   Option Type
      One byte indicating "Abbreviated Option", see Table 2 in
      Section 8.2

   Option Length
      MUST be set to 2 indicating Option data of 2 bytes

   Abbreviated Option
      The Option Type of the option being abbreviated

   Last Modification Sequence
      The last modified RCSS when carried in DIO or the last modified
      DAOSequence when carried in DAO

   When a node receives a DAO-ACK for a given DAO sequence, then if the 
   next DAO has the unchanged options, the node MAY reuse the DAOsequence
   and elide all options with AOO. Abbreviated Option SHOULD be ignored. 
   The Last Modification Sequence is the last DAOsequence. The next DAO 
   MAY also unset ‘K’ flag to not expect a DAO-ACK, if node can assume 
   the risk that the DAO is lost and the state times out at the DAO 
   receiver. It is RECOMMENDED in non-storing mode because DAO always has 
   the same content.

Best regards,
Li

On 2019/10/22, 19:27, "Roll on behalf of Li Zhao (liz3)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Pascal,
    
    Agree with you.

    Best regards,
    Li

        Hello Again Li:

        All the best;
        
        Pascal
        
        -----Original Message-----
        From: Roll <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
        Sent: mardi 22 octobre 2019 07:58
        To: Routing Over Low power and Lossy networks <[email-masked]>
        Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
        
        Hello Li
        
        Would be great!

        
        Regards,
        
        Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Oct 2019 15:26:41 +0000

Do you have a github account, Li?

Regards,

Pascal

> Le 22 oct. 2019 à 16:36, Li Zhao (liz3) <[email-masked]> a écrit :
> 
> Hello Again Pascal,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Oct 2019 15:43:31 +0000

Hello Li

My initial thought was that we'd not use AOO at all in DAO messages, we'd  elide all options or no option. 
I do not really see how we could do partial increments of some options and not others.
I see that your proposal requires AOOs in DAOs as well. Do you have a case in mind?
If we start replacing stuff with AOO tin DAOs things could get hairy, like I have 2 targets with a few transit each. One target changes. Or one transit changes. How would we use the AOO?

The keep it simple way is to add a section on DAO that does not use AOO at all.

Take care,

Pascal

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: mardi 22 octobre 2019 16:36
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

Hello Again Pascal,

     0                   1                   2                   3

   Option fields:

   Option Type

   Option Length

   Abbreviated Option

Best regards,
Li

    Hello Pascal,
    
    Agree with you.

    Best regards,
    Li

        Hello Again Li:

        All the best;
        
        Pascal
        
        -----Original Message-----
        From: Roll <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
        Sent: mardi 22 octobre 2019 07:58
        To: Routing Over Low power and Lossy networks <[email-masked]>
        Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
        
        Hello Li
        
        Would be great!

        
        Regards,
        
        Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Wed, 23 Oct 2019 02:00:48 +0000

Hello Pascal,

The reason why we need AOO in DAO is to distinguish whether this DAO carries elide options.

Otherwise, there is a compatibility issue if the behavior for DAO with no option changes. Because currently when node receives this DAO with no option, it does nothing according to RFC6550.

For the 2 targets case, can we use Abbreviated Option as 0x00 or 0xff to indicate all options unchanged?

Best regards,
Li

On 2019/10/22, 23:44, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Li

    
    Take care,
    
    Pascal
    
    -----Original Message-----
    From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
    Sent: mardi 22 octobre 2019 16:36
    To: Routing Over Low power and Lossy networks <[email-masked]>
    Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
    
    Hello Again Pascal,

    
         0                   1                   2                   3

       Option fields:
    
       Option Type
    
       Option Length
    
       Abbreviated Option

    Best regards,
    Li

        Hello Pascal,
        
        Agree with you.

        Best regards,
        Li

            Hello Again Li:

            All the best;
            
            Pascal
            
            -----Original Message-----
            
            Hello Li
            
            Would be great!

            
            Regards,
            
            Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Wed, 23 Oct 2019 02:26:08 +0000

Hello Pascal,

Yes. My account is dreamlich. May I know how to request the permission?

Best regards,
Li

On 2019/10/22, 23:27, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    
    Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 23 Oct 2019 02:51:33 +0000

Hello Li,
You need to fork the repo and then make the changes in your repo where you will have all the permissions.
Once the changes are done(committed and pushed) to your forked repo, you need to raise a pull-request to the roll-wg repo (usually called as upstream repo).
The changes can then be reviewed and accepted by chairs or Pascal (creator of the repo).

Regards,
Rahul
________________________________
From: Roll <[email-masked]> on behalf of Li Zhao (liz3) <[email-masked]>
Sent: Wednesday, October 23, 2019 2:26 AM
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

Hello Pascal,

Best regards,
Li

    Regards,

    Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Wed, 23 Oct 2019 03:01:57 +0000

Many thanks, Rahul. I’ve committed to my repo and raise a pull-request.

Best regards,
Li

From: Roll <[email-masked]> on behalf of Rahul Jadhav <[email-masked]>
Reply-To: Routing Over Low power and Lossy networks <[email-masked]>
Date: Wednesday, October 23, 2019 at 10:51
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

Hello Li,

Regards,
Rahul

Hello Pascal,

Best regards,
Li

    Regards,

    Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Oct 2019 12:56:49 +0000

Hello Li

The AOO abbreviates an option. It is strange to me to use it to abbreviate a full RPL control message. And I do not think we need that.

Currently there should not be a DAO with no option in it. So we do not really have a collision with RFC 6550. Still I understand your point and I'd be happy to add a flag in the DAO to say that the DAO is globally abbreviated.

Would that work for you?

Pascal

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: mercredi 23 octobre 2019 04:01
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

Hello Pascal,

Best regards,
Li

    Hello Li

    
    Take care,
    
    Pascal
    
    -----Original Message-----
    From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
    Sent: mardi 22 octobre 2019 16:36
    To: Routing Over Low power and Lossy networks <[email-masked]>
    Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
    
    Hello Again Pascal,

    
         0                   1                   2                   3

       Option fields:
    
       Option Type
    
       Option Length
    
       Abbreviated Option

    Best regards,
    Li

        Hello Pascal,
        
        Agree with you.

        Best regards,
        Li

            Hello Again Li:

            All the best;
            
            Pascal
            
            -----Original Message-----
            
            Hello Li
            
            Would be great!

            
            Regards,
            
            Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Thu, 24 Oct 2019 03:20:27 +0000

Hello Pascal,

Add new flag in DAO is a better option. I'll write it down later.

Best regards,
Li

On 2019/10/23, 20:57, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Li

    
    Would that work for you?
    
    Pascal
    
    -----Original Message-----
    From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
    Sent: mercredi 23 octobre 2019 04:01
    To: Routing Over Low power and Lossy networks <[email-masked]>
    Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
    
    Hello Pascal,

    
    
    Best regards,
    Li

        Hello Li

        
        Take care,
        
        Pascal
        
        -----Original Message-----
        From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
        Sent: mardi 22 octobre 2019 16:36
        To: Routing Over Low power and Lossy networks <[email-masked]>
        Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
        
        Hello Again Pascal,

        
             0                   1                   2                   3

           Option fields:
        
           Option Type
        
           Option Length
        
           Abbreviated Option

        Best regards,
        Li

            Hello Pascal,
            
            Agree with you.

            Best regards,
            Li

                Hello Again Li:

                All the best;
                
                Pascal
                
                -----Original Message-----
                
                Hello Li
                
                Would be great!

                
                Regards,
                
                Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Thu, 24 Oct 2019 06:56:14 +0000

Hello Again Pascal,

I've written it in https://github.com/roll-wg/eliding-dio-information/pull/2. Could you please take a look?

Best regards,
Li

On 2019/10/24, 11:20, "Roll on behalf of Li Zhao (liz3)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Pascal,

    Best regards,
    Li

        Hello Li

        
        Would that work for you?
        
        Pascal
        
        -----Original Message-----
        From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
        Sent: mercredi 23 octobre 2019 04:01
        To: Routing Over Low power and Lossy networks <[email-masked]>
        Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
        
        Hello Pascal,

        
        
        Best regards,
        Li

            Hello Li

            
            Take care,
            
            Pascal
            
            -----Original Message-----
            
            Hello Again Pascal,

            
                 0                   1                   2                   3

               Option fields:
            
               Option Type
            
               Option Length
            
               Abbreviated Option

            Best regards,
            Li

                Hello Pascal,
                
                Agree with you.

                Best regards,
                Li

                    Hello Again Li:

                    All the best;
                    
                    Pascal
                    
                    -----Original Message-----
                    
                    Hello Li
                    
                    Would be great!

                    
                    Regards,
                    
                    Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Oct 2019 13:17:37 +0000

It's now merged, Li.

We'll probably need a capability to indicate that the abbreviations are supported, in particular for DAO.

All the best

Pascal

> Sent: jeudi 24 octobre 2019 08:56
>     On 2019/10/23, 20:57, "Roll on behalf of Pascal Thubert (pthubert)" <roll-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>         Hello Li
> 
>         The AOO abbreviates an option. It is strange to me to use it to abbreviate a
> full RPL control message. And I do not think we need that.
> 
>         Currently there should not be a DAO with no option in it. So we do not
> really have a collision with RFC 6550. Still I understand your point and I'd be
> happy to add a flag in the DAO to say that the DAO is globally abbreviated.
> 
>         Would that work for you?
> 
>         Pascal
> 
>         Otherwise, there is a compatibility issue if the behavior for DAO with no
> option changes. Because currently when node receives this DAO with no option,
> it does nothing according to RFC6550.
> 
>         On 2019/10/22, 23:44, "Roll on behalf of Pascal Thubert (pthubert)" <roll-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>             Hello Li
> 
>             If we start replacing stuff with AOO tin DAOs things could get hairy, like I
> have 2 targets with a few transit each. One target changes. Or one transit
> changes. How would we use the AOO?
> 
>             On 2019/10/22, 19:27, "Roll on behalf of Li Zhao (liz3)" <roll-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>                 Hello Pascal,
> 
>                 Agree with you.
>                 We can use AOO with last Modification DAO sequence to elide all
> options in DAO. In this case, we can ignore the Abbreviated Option field or set it
> to 0xFF. Which do you prefer?
> 
>                 For the DAO lost case, even in normal DAO case, node has the risk of
> lost DAO message. Node should set 'K' flag according to different network
> environment.
>                 On 2019/10/22, 16:53, "Roll on behalf of Pascal Thubert (pthubert)"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>                     Hello Again Li:
> 
>                     I looked at it and an simple step could be that when a node receives a
> DAO-ACK for a given DAO sequence, then if the next DAO has the same content
> the node may reuse the DAO sequence and elide the options. It may also decide
> not refrain from asking an ack, at the risk that the DAO is lost and the state times
> out at the DAO receiver.
> 
>                     All the best;
> 
>                     Pascal
> 
>                     My expectation is that the source of the non storing DAO increases a
> sequence nb when there is a change and abbreviates it when there is none.
> 
>                     You need to think of what happens when the updated DAO is lost, eg
> MUST an ack or something and only abbreviate after a positive DAO ACK...
> 
>                     Regards,
> 
>                     Pascal
> 
>                     > It looks good if router always need these options. And if a node
> wants to act as a leaf, it can only request R/D/P.
>                     >
>                     > On 2019/10/21, 17:58, "Roll on behalf of Pascal Thubert
> (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:
>                     >
>                     >    Hello Li (and all, please read on as there are additional things we
> could be doing with the draft listed below)
>                     >
>                     >    Let's see below
>                     >
>                     >    [Li] Do you mean that child should know ALL option type it needs
> before select the parent? E.g. one child need R/D/P/M/O to join network but
> another child only need R/D/P.
>                     >    <Pascal> The draft assumes that all R/D/P/M/O are always present
> and always needed. This seems to be the general case. We can make it so that
> one option would not be present by indicating in the DIO if you think that case is
> relevant. Please let me know.
>                     >
>                     >    But how will a child know that it does not need an option that is
> present? Maybe there is something in there that is mandatory to know, e.g., to
> act as a router. We could say that a node that does not pull all the options can
> only act as a leaf. Is that what you have in mind?
>                     >
>                     >
>                     >
>                     >        2. Is AOO necessary? If DIO can fragment options and don't
> always send all options, can we use DIO without options to indicate the AOO?
>                     >     <Pascal> AOO is RECOMMENDED to elide the option. A DIO an
> option elided (no option, no abbreviation) and an unchanged RCSS is perfectly
> OK. But if an option is elided AND the RCSS is incremented then after a
> reasonable time-out the children will pull the options to check if they changed
> and the parent will need to send either the AOO or the option in full or both in
> which case the RCSS of the AOO wins. It is always possible to place the option in
> full without a AOO but if it is done with an increased RCSS in the DIO that will
> mechanically increase the "RCSS of the option" as seen by the children and will
> cause the whole subdag to pull the option to no avail.
>                     >
>                     >     [Li] Agree, AOO is better than DIO with no option. It’s a nice
> abbreviated mechanism for RPL Control Message.
>                     >           Can we consider to extend AOO for DAO? Maybe put AOO in a
> new Control Message Options, then DIO/DAO can both leverage it.
>                     >           In some case, child will send large DAO packet to parent
> periodically. E.g. 1. child notifies its capability to parent .2 child has several RPL
> Target or Transit Information (storing mode?).
>                     >
>                     >    <Pascal> Yes we could. Say that the content of a non-storing DAO
> is fully stable, it could be all replaced by a sequence. Would you be interested in
> adding that?
>                     >
>                     >    If we have to abbreviate elements therein, per target, then we still
> need to indicate the target so we'll save little, and a different technique like
> indexing the targets with a BIER bit, would be more efficient.
>                     >
>                     >

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Sat, 26 Oct 2019 00:54:41 +0000

Agree. We can use MOPEX to indicate the capability. Hope that MOPEX can move on in 106.

Best regards,
Li

On 2019/10/25, 21:18, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of [email-masked]> wrote:

    It's now merged, Li.

    All the best
    
    Pascal