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

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

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

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?

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