Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

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

Hello Martin

First of all you are correct that the whole game is to recover the bits for RPLv2, with the idea that the features that they signaled will be installed and that signaling the transition will be a waste. Also RPL has very few of these flags available in the configuration option and the group insisted on getting them back after the transition. 

Second is to thank you for your care / the depth of your attention on that issue. It is indeed “touchy”. And it spans 3 drafts that are going through IESG in the same window of time.

Let’s see below

> We will eventually get there, but this will never stop being weird to me. :-)

> Imagine 5 types of DODAG nodes:

I read they support the below as opposed to the DODAG is deployed with the below.

Type     8138? this draft? MOP5?  MOP 7? 
-------      -------   ------------    --------   ----------  
 A             N              N             N           N        
B              Y              N             N           N
C              Y              Y             N           N
D              Y              Y             Y            N
E              Y              Y              Y           Y

> So if IIUC, the current state of play is that B can't gracefully deploy into a network with A, because they have to be statically configured to not-compress.

Or you need some management outside of RPL which is against the core design point that RPL should be autonomic/self-configuring

> As long as B is upgraded to this draft (C), it can gracefully deploy in a network with A, because compression will remain off until all the A is gone. C and B can function together without this draft, but they won't be able to dynamically change compression state, FWIW

Yes, that is the transition phase

>  Similarly, a hypothetical D can gracefully deploy with A, as it will have use of these flags, but doesn't really need the flags to work with B or C unless you want to dynamically change state for some reason.

Unclear what you mean. If the DODAG is deployed with a MOP < 5 D is a C. If the MOP is 5, nodes A, B, and C will have to be leaves, and the flag will still be off as long as there's an A in the network, else that A will be isolated.

> Meanwhile, E will not be able to gracefully deploy with A, because it does not have a means to change its compression state using the DODAG configuration. But because of the sentence we've discussing in this thread, networks with C and D will have no problem because they have this text to help them decide whether or not to compress. They will not have the ability to dynamically change compression state.

Same as above, if the MOP is <7, the flag still works, even if E is capable of some new MOPExt MOPs. If we use a MOPext (signaled by MOP=7), and if there are nodes of type A in the network, tose nodes of type A will be leaves and they'll be isolated, unless they turn into RPL-unaware-leaves, from which compression is not expected.

> So I guess the value of the MOP 7 behavior is... to recover the bit of the flags? Fine, I suppose, but this would appear to have two costs:
Yes

> 1) If A is still out there when E deploys, this bit would have been useful, but isn't.
It's not when E deploys, it is when the DODAG is deployed or upgraded with a MOP 7. 

> 2) I have no idea if the "dynamic change in compression state" use case is valuable it all, but it would certainly foreclose the possilbilty.
We defined this flag to enable the activation of the compression in a brown field. Right now we have millions of nodes deployed, all of type A. typically utility AMI meters. Having to impose a flag day to migrate to the compression is not acceptable to our users. So we do not even propose it. and the situation is stuck. If we have a migration scenario without a flag day, we can ship the compression in software refreshes, and let the customer decide if and when to turn on. 

> Do I have this right?

You do 😊

Pascal


On Tue, Nov 10, 2020 at 12:15 AM Pascal Thubert (pthubert) <mailto:[e-mail]> wrote:
Hello Benjamin:

> That said, and my apologies for a hazy memory coming back to this after a
> couple months, in a year or N from now when mopex is finalized, how will
> someone looking at mopex know to use RFC8138 on links where 6LoWPAN
> Header Compression applies (and not use it otherwise)?  We are claiming in
> the -14 of this document that:
> 
>                               For a MOP value of 7, [RFC8138] MUST be
>    used on Links where 6LoWPAN Header Compression [RFC6282] applies and
>    MUST NOT be used otherwise.
> 
> but I am not sure (or have forgotten) what the chain of references is supposed
> to lead someone who is implementing RPL plus MOP=7 to the requirement to
> use RFC 8138.  I don't think we should just rely on the mopex text to do so,
> since we are trying to impose the requirement with this document (which
> predates mopex by some time), and there's not anything (other than our
> collective memories, of course) requiring mopex to remain consistent with
> that requirement.

Just to be clear for the other readers: MOPext does not exist as a normative reference for this work.
The only field that exists is the MOP field in the DIO and that field is 3 bits long, values 0..7.

The normative reference that you are after is https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
This is the spec that updates RPL and changes the IANA registry to indicate that 7 is not a MOP.

There we have:

"

...

  Anticipating future work to revise RPL relating to how the LLN and
   DODAG is configured, this document changes the interpretation of the
   [dodagcfg] Registry to be limited to Mode-of-Operation (MOP)
   specific.  The MOP is described in [RFC6550] section 6.3.1.  The
   Options Flags Registry is renamed, and applies to MOP values zero (0)
   to six (6) only, leaving the flags reserved for MOP value seven (7).

   In addition, this document reserves MOP value 7 for future expansion.

...

11.3.  Change MOP value 7 to Reserved

   This document changes the allocation status of the Mode of Operation
   (MOP) [ianamop] from Unassigned to Reserved.  This change is in
   support of future work related to capabilities.
"

So basically we tell the implementations from now on to test if MOP is 7, and in that case, the Options Flags are undefined. In other words, if MOP is 7, the stack must not use the option flags as if the MOP was <7. In fact, 7 is no more a MOP value but a reserved thingy that can be overloaded in the future. And yes, we intend to do just that in MOPExt.

Until that happens, implementations are at a loss if they encounter when a MOP field that is all ones. So we need to give them instructions to cope with the situation. This draft derives whether to use RFC 8138 from whether the 6LoWPAN compression applies to the link or not.

This will stay true forever, unless another RFC amends it. When/if that happens, the new RFC will have to consider backward compatibility with a legacy implementation that implements the above. 

Note that this line of thought applies to 3 flags, defined respectively in:
- https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
- https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/
- https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/

Keep safe!

Pascal

> 
> Thanks,
> 
> Ben
> 
> On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wrote:
> > Hello Alvaro
> >
> > I uploaded both draft with the suggested update, please see
> >
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-17.
> > txt
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-21.tx
> > t
> >
> > Keep safe
> >
> > Pascal
> >
> > > -----Original Message-----
> > > From: Alvaro Retana <mailto:[e-mail]>
> > > Sent: jeudi 24 septembre 2020 17:49
> > > To: Pascal Thubert (pthubert) <mailto:[e-mail]>
> > > Cc: Benjamin Kaduk <mailto:[e-mail]>; The IESG <mailto:[e-mail]>;
> > > draft-ietf- mailto:[e-mail]; Martin Duke
> > > <mailto:[e-mail]>; Routing Over Low power and Lossy networks
> > > <mailto:[e-mail]>; roll- mailto:[e-mail]; Michael Richardson
> > > <mailto:[e-mail]>
> > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
> > > draft-ietf-roll-turnon-rfc8138-
> > > 14: (with DISCUSS and COMMENT)
> > >
> > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote:
> > >
> > >
> > > Pascal:
> > >
> > > Hi!
> > >
> > > > Following the meeting last Monday and subsequent the update of
> > > > useofrplinfo by Michael (thanks Michael!) I published a new
> > > > version of the turnon RFC
> > > > 8138 draft.
> > > >
> > > > The major changes are
> > > > - removed the formal update to RFC 6550
> > > > - refer to useofrplinfo as the justification why the flag is not
> > > > defined for MOP 7
> > > > - defined the operation in MOP 7 as compression on iff the Link
> > > > uses 6LoPWAN HC.
> > >
> > > Thanks for these changes.
> > >
> > > Because we have to cycle useofrplinfo back through (when the WG is
> > > done with it), I asked Ben/Martin to wait for that before coming
> > > back to this document.  It'll make it easier than tracking multiple
> > > changes. :-)
> > >
> > >
> > > OTOH, I do have comments on the recent change:
> > >
> > > OLD>
> > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > the
> > >    definition of the Flags applies to Mode of Operation (MOP) values
> > >    zero (0) to six (6) only, leaving the flags reserved for MOP
> > > value
> > >    seven (7).  For a MOP value of 7, the bit in position 2 is
> > > considered
> > >    unallocated and [RFC8138] MUST be used on Links where 6LoWPAN
> > > Header
> > >    Compression [RFC6282] applies and MUST NOT be used otherwise.
> > >
> > > NEW>
> > >
> > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > the
> > >    definition of the Flags applies to Mode of Operation (MOP) values
> > > zero (0)
> > >    to six (6) only.  For a MOP value of 7, [RFC8138] MUST be used on
> > > Links
> > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT
> > > be used
> > >    otherwise.
> > >
> > >
> > > Thanks!
> > >
> > > Alvaro.