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

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

Hello Alvaro 

I’ll respond at length tomorrow.
Still I wanted to start on one item tonight.
I agree about the wheels and cart thing. We do not want that and thought we avoided it.

We do not know what mop>7 will be. We do not say that this flag will not be valid. We say that we do not know if it is valid either. So what we want is an implementation of today should process the bit only if the mop is less than 7.  We want code now to protect the future so the flag can reused.

As it goes that implementation will not know the mop either so it can only be a leaf. So a legacy node will only just itself if is misbehaves. 

What would help is if we specify that all mop>7 support the compression. But that was not really agreed so far though it’s in the air...

Take care,
Pascal

> Le 20 juil. 2020 à 21:10, Alvaro Retana <[e-mail]> a écrit :
> 
> On July 9, 2020 at 10:38:29 AM, Pascal Thubert wrote:
> 
> 
> Pascal:
> 
> Hi!
> 
> 
> ...
>> We decided to stick he *normal* scenario is migrate slowly the nodes with
>> the bit off and when all are migrated turn the bit on. The complex case is
>> that of "forgotten nodes", e.g., nodes for which there was never a new code
>> for this draft and for the compression, to try to serve them still. We
>> decided no to handle that case. They will have to be decommissioned or
>> maintained in a legacy network.
>> 
>> 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! :-)
> 
> 
> 
> ...
>>> (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.
> 
> This should simplify more.  Thoughts?
> 
> 
> 
> ...
>>> ...
>>> 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.
> 
> 
> 
> ...
>> 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
> 
> 
> 
> ...
>>> 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. ;-)
> 
> 
> 
>>> [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.
> 
> 
> 
> ...
>> 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.
> 
> 
> I'll wait for one more update before starting the IETF Last Call.
> 
> Thanks!
> 
> Alvaro.