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

["Li Zhao (liz3)" <[e-mail]>]

Hello Pascal,

Please see my comments inline...

Best regards,
Li

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

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

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


      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. 
    "
    
    
    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.
    
    <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?).


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


    Many thanks again Li, for your excellent comments.
    
    Pascal    
    
    On 2019/10/17, 23:51, "Roll on behalf of Pascal Thubert (pthubert)" <[e-mail] on behalf of [e-mail]> 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: [e-mail] <[e-mail]> 
        Sent: jeudi 17 octobre 2019 17:46
        To: Pascal Thubert (pthubert) <[e-mail]>; Rahul Jadhav <[e-mail]>; Rahul Arvind Jadhav <[e-mail]>; Dominique Barthel <[e-mail]>
        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
        [e-mail]
        https://www.ietf.org/mailman/listinfo/roll
        
    
    _______________________________________________
    Roll mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/roll
    _______________________________________________
    Roll mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/roll