Re: [Roll] AD Review of draft-ietf-roll-turnon-rfc8138-07

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

Hello Alvaro

Many thanks (again) for your review!


> > Bottom line is that the simplification removes the text to turn
> > "forgotten nodes" into leaves and any special knowledge of the leave
> > support in this specification. Which removes a number of the pain points that
> you raised.
> 
> I think that the simplification is a good thing! :-)

Adopted then

> ...
> > > (3) §3 says that ""T" flag is defined only for MOP value between 0 to 6".
> > > The current registry is not set up for this type of assignment, so
> > > it needs to be updated (see more specifics below).
> >
> > Basically added text in IANA section to make all flags " defined only
> > for MOP value between 0 to 6"
> 
> I've been thinking about this some more, and I think we're getting into putting-
> the-cart-before-the-horse [1] territory.
> 
> [1] https://en.wikipedia.org/wiki/Cart_before_the_horse
> 
> 
> There's no special meaning assigned to MOP = 7, yet.  This document talks
> about it because you (the WG, etc.) already know about the future intent.  But
> that has not been specified anywhere, and there are no other specifics about
> that change here...nor should there be.
> 
> IOW, I'm thinking that instead of changing the registry in this document, we
> should leave it as is and make no statement as to which MOPs the new flag
> applies to.  That explanation will come later when the RPLv2 work is done -- we
> can go into the details at that time.

Agreed for the registry part. 
All we want is to say that the code should check for MOP<7 before it uses the flag.
To prepare for this the current draft onlyt changes the name of the registry as below.

"
6.  IANA Considerations

   IANA is requested to assign a new option flag from the Registry for
   the "DODAG Configuration Option Flags" that was created for [RFC6550]
   as follows:

      +---------------+---------------------------------+-----------+
      | Bit Number    | Capability Description          | Reference |
      +---------------+---------------------------------+-----------+
      | 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC  |
      +---------------+---------------------------------+-----------+

                Table 1: New DODAG Configuration Option Flag

   The DODAG Configuration Option Flags defined so far will be obsolete
   for RPL Mode of Operation (MOP) above and including 7.

   IANA is requested to update the name of the Registry from "DODAG
   Configuration Option Flags" to "DODAG Configuration Option Flags for
   RPL MOP 0..6".

   When MOP values of 7 and more are defined, a new registry will be
   needed.
"

Should I remove the text after the table or is it OK?



> 
> This should simplify more.  Thoughts?
> 
> 

Please keep in mind that we want the core written today to disregard the flag (I guess that means use a default that is TBD) for MOP >= 7. Said this way, we still need text, and we need to define the default. I suspect it should be "ON" but I need to check with the ML.


> 
> ...
> > > ...
> > > 11 Abstract
> ...
> 
> The Abstract still says that the document Updates rfc6550:
> 
> Suggestion>
>    This document updates RFC 8138 by defining a bit in the RPL DODAG
>    Configuration Option to indicate whether compression is used within the
>    RPL Instance, and specify the behavior of when the bit is set and reset.
> 
> 

Did you mean
"
     This document updates RFC 8138 by defining a bit in the RPL DODAG
     Configuration Option to indicate whether compression is used within the
     RPL Instance, and specify the behavior of RFC 8138-capable nodes
     when the bit is set and reset.

"

?

> 
> ...
> > 3. The RPL DODAG Configuration Option
> ...
> 
> The text in this section says that "The new "T" flag is encoded in one of the
> reserved bits in the RPL DODAG Configuration Option."
> 
> [] s/"T" flag is encoded in one of the reserved bits/"T" flag is encoded in the
> Flags field
> 

Done

> 
> 
> ...
> > > 244 5.1. Inconsistent State While Migrating
> ...
> > > 250 Some nodes will see the flag and start sourcing packets in the
> > > 251 compressed form while other nodes in the same RPL Instance are
> > > still
> > > 252 not aware of it. Conversely, in non-storing mode, the Root will
> > > 253 start using [RFC8138] with a Source Routing Header 6LoRH
> > > (SRH-6LoRH)
> > > 254 that routes all the way to the parent router or to the leaf.
> > >
> > > [minor] I don't understand how the second sentence reverses
> > > ("Conversely") the statement in the first sentence...or how the mode
> > > affects the outcome of nodes (including the Root) sending compressed
> > > packets when others may not still be aware of the flag or able to
> > > support receiving the packets...
> >
> > I forgot to re-fix that one after the major change. The conversely was
> > opposing storing vs. non storing. Any suggestion?
> 
> Just start with "In storing mode...", and take "conversely" out. ;-)
> 

Done

> 
> > > [minor] "[RFC8138] with a Source Routing Header 6LoRH (SRH-6LoRH)"
> > > sounds redundant. Also, this is the only place in the document where
> > > the use of rfc8138 is coupled with the SRH-6LoRH. Not wrong, just
> > > redundant and inconsistent. If needed, the sentence can be restructured.
> >
> > Well, that's probably our only discrepancy. The SRH66LoRH (compressed
> > IPv6 RH type 3, really) is specific to the Root and to non-storing. It
> > shows packets could fly with the compression as soon as the root knows
> > the bit is set and way before the nodes are aware of it. The next
> > sentence is "
> > To ensure that a packet is forwarded across the RPL DODAG in the form
> > in which it was generated, it is required that all the RPL nodes
> > support [RFC8138] at the time of the switch.
> >
> > "
> >
> >
> > I can reword if that leaves confusion and would appreciate suggestions.
> 
> Let's leave is at is.
> 

Cool

> ...
> > 5.3. Rolling Back
> 
> [major] The last sentence in the last paragraph changed from "used as a leaf"
> to "used as a RUL"...the "MUST" makes the reference for RUL Normative.  If
> you don't want UNAWARE-LEAVES to be Normative, then change it back.

A leaf is not enough in storing mode, because the service 6LR cannot know if the next hop is the final destination. So TRUL it has to be. Note that in non-storing mode it would know because the RH3 is consumed.

I made the RUL draft reference normative then. They should progress together anyway.


> 
> I'll wait for one more update before starting the IETF Last Call.
> 
> Thanks!
> 

Thank YOU, Alvaro!

For the IANA section, I see that Michael also clarified why we want this code to limit the bit to lower MOPs. Please give us your thoughts.

I'll need to poll the list on the default beyond MOP 7, will do that separately to attract attention.

Take care,

Pascal