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

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

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

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Li Zhao (liz3)
> Sent: jeudi 24 octobre 2019 08:56
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-
> dio-information-01.txt
> 
> 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)" <[e-mail]
> on behalf of [e-mail]> wrote:
> 
>     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)" <roll-
> [e-mail] on behalf of [e-mail]> 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
> 
>         -----Original Message-----
>         From: Roll <[e-mail]> On Behalf Of Li Zhao (liz3)
>         Sent: mercredi 23 octobre 2019 04:01
>         To: Routing Over Low power and Lossy networks <[e-mail]>
>         Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-
> eliding-dio-information-01.txt
> 
>         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)" <roll-
> [e-mail] on behalf of [e-mail]> wrote:
> 
>             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 <[e-mail]> On Behalf Of Li Zhao (liz3)
>             Sent: mardi 22 octobre 2019 16:36
>             To: Routing Over Low power and Lossy networks <[e-mail]>
>             Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-
> eliding-dio-information-01.txt
> 
>             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)" <roll-
> [e-mail] on behalf of [e-mail]> 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.
>                 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)"
> <[e-mail] on behalf of [e-mail]> 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
> 
>                     -----Original Message-----
>                     From: Roll <[e-mail]> On Behalf Of Pascal Thubert
> (pthubert)
>                     Sent: mardi 22 octobre 2019 07:58
>                     To: Routing Over Low power and Lossy networks <[e-mail]>
>                     Subject: Re: [Roll] FW: New Version Notification for draft-thubert-
> roll-eliding-dio-information-01.txt
> 
>                     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) <[e-mail]> a écrit :
>                     >
>                     > 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)" <[e-mail] on behalf of [e-mail]> 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.
>                     >    So how does child know this info? Is it pre-defined in child?
>                     >
>                     >    <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?
>                     >            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?).
>                     >
>                     >    <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
>                     >    _______________________________________________
>                     >    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
>                     _______________________________________________
>                     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
>             _______________________________________________
>             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
> 
> 
>     _______________________________________________
>     Roll mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/roll
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll