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

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Nov 2020 19:34:38 -0800

Hi Pascal, all,

Thanks for the updated drafts; I'm happy to see that useofrplinfo is
marking MOP 7 as "special" with respect to the flags registry.

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.

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.txt
> 
> Keep safe
> 
> Pascal
> 
> > -----Original Message-----
> > From: Alvaro Retana <[email-masked]>
> > Sent: jeudi 24 septembre 2020 17:49
> > To: Pascal Thubert (pthubert) <[email-masked]>
> > Cc: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>; draft-ietf-
> > [email-masked]; Martin Duke <[email-masked]>;
> > Routing Over Low power and Lossy networks <[email-masked]>; roll-
> > [email-masked]; Michael Richardson <[email-masked]>
> > 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2020 08:15:33 +0000

Hello Benjamin:
 
> 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:
> 
> 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

> > > Cc: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>;
> > > draft-ietf- [email-masked]; Martin Duke
> > > <[email-masked]>; Routing Over Low power and Lossy networks
> > > <[email-masked]>; roll- [email-masked]; Michael Richardson
> > > <[email-masked]>
> > > > useofrplinfo by Michael (thanks Michael!) I published a new
> > > > version of the turnon RFC
> > > > 8138 draft.
> > > >
> > > > The major changes are
> > > > - defined the operation in MOP 7 as compression on iff the Link
> > > > uses 6LoPWAN HC.
> > >
> > > 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. :-)
> > >
> > >
> > > zero (0)
> > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT
> > > be used
> > >    otherwise.
> > >
> > >
> > > Thanks!
> > >
> > > Alvaro.

---

From: Martin Duke <[email-masked]>
Date: Tue, 10 Nov 2020 15:16:08 -0800

OK,

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

Imagine 5 types of DODAG nodes:

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.

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.

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.

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.

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:
1) If A is still out there when E deploys, this bit would have been useful,
but isn't.
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.

Do I have this right?

Martin

On Tue, Nov 10, 2020 at 12:15 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> supposed
> The normative reference that you are after is
> https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
> 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.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Nov 2020 23:00:10 -0800

Hi Pascal,

I will say a bit more inline, but want to note upfront that my primary
unease here is that we seem to be assigning some (partial) semantics to MOP
value 7 here (even though we do not specify full semantics for MOP value 7):

yet there is no "trail of breadcrumbs" for someone to follow from "I want
to implement MOP 7" and end up at the sentence I quoted above.  A formal
Update to 6550 would provide such a trail, as would being listed as a
reference in the IANA registry for MOP value 7.  My current understanding
is that the only thing we have right now is "repeat this requirement in
whatever document ends up providing a full specification for MOP value 7",
and I don't think that relying on the IETF's collective memory is a great
way to enforce such a requirement -- we can and have in the past slipped up
and published RFCs that are inconsistent with requirements imposed by
previous ones.

> The only field that exists is the MOP field in the DIO and that field is 3 bits long, values 0..7.

Yes.

> This is the spec that updates RPL and changes the IANA registry to indicate that 7 is not a MOP.

Not a MOP at all, or not a "normal" MOP that behaves like 0..6?

> 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…

Yes, we are saying "if you see a MOP field that is all ones, do this".  To
me, that seems like we want to be listed as an additional reference for MOP
value 7 in the IANA registry.

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

It will stay true forever (until amended), but how does a new person making
an implementation know to find this document and do so?  [useofrplinfo]
says that MOP value 7 is special and needs dedicated handling, but it
doesn't say anything about using 8138 [on links where 6LoWPAN Header
Compression applies].  I'm missing the trail of breadcrumbs.

Thanks,

Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Nov 2020 09:59:03 +0000

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.

> 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:[email-masked]> wrote:

There we have:

"

...

...

Keep safe!

Pascal

> > > From: Alvaro Retana <mailto:[email-masked]>
> > > To: Pascal Thubert (pthubert) <mailto:[email-masked]>
> > > Cc: Benjamin Kaduk <mailto:[email-masked]>; The IESG <mailto:[email-masked]>;
> > > draft-ietf- mailto:[email-masked]; Martin Duke
> > > <mailto:[email-masked]>; Routing Over Low power and Lossy networks
> > > <mailto:[email-masked]>; roll- mailto:[email-masked]; Michael Richardson
> > > <mailto:[email-masked]>

---

From: Martin Duke <[email-masked]>
Date: Wed, 11 Nov 2020 08:26:48 -0800

Ah, OK, I see now that MOP7 in itself substitutes for the flag. I'm
satisfied.

On Wed, Nov 11, 2020 at 1:59 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> 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
>
> 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
> able to dynamically change compression state, FWIW
>
> >  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
> 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
>
> > 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
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Nov 2020 17:31:28 +0000

Hello Benjamin

> I will say a bit more inline, but want to note upfront that my primary unease
> here is that we seem to be assigning some (partial) semantics to MOP value 7
> here (even though we do not specify full semantics for MOP value 7):
> 

True; we considered the position of an implementer testing for MOP < 7 to decide if the flag was meaningful.
That implementer would have to populate the else statement and we preferred to give him instructions rather than have different implementations do different things.

> 
> yet there is no "trail of breadcrumbs" for someone to follow from "I want to
> implement MOP 7" and end up at the sentence I quoted above.  A formal
> reference in the IANA registry for MOP value 7.  My current understanding is

There was this traceability statement in https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-15#section-3 which is gone now.
I followed Alvaro's lead there; we removed it based on an interpretation of the "updates" that denotes a change in RFC 6550 implementations, which is not the case here. Using a reserved flag is not an "update" per this interpretation.

But yes, I see your point. 

> that the only thing we have right now is "repeat this requirement in whatever
> document ends up providing a full specification for MOP value 7", and I don't
> think that relying on the IETF's collective memory is a great way to enforce
> such a requirement -- we can and have in the past slipped up and published
> RFCs that are inconsistent with requirements imposed by previous ones.

True.  We have created a file to store this kind of memory. I added your quote there, please see:

https://github.com/roll-wg/RPLv2/blob/main/README.md

I've been thinking about it so more but cannot find a better answer...

Many thanks!

Pascal

> > > 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:
> > >
> > > 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.
> >
> 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.
> >
> 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.
> 
> Yes, we are saying "if you see a MOP field that is all ones, do this".  To me,
> that seems like we want to be listed as an additional reference for MOP value
> 7 in the IANA registry.
> 
> an implementation know to find this document and do so?  [useofrplinfo] says
> that MOP value 7 is special and needs dedicated handling, but it doesn't say
> anything about using 8138 [on links where 6LoWPAN Header Compression
> applies].  I'm missing the trail of breadcrumbs.
> 
> Thanks,
> 
> Ben
> 
> > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-2
> > > > 1.tx
> > > > t
> > > >
> > > > Keep safe
> > > >
> > > > Pascal
> > > >
> > > > > <[email-masked]>; Routing Over Low power and Lossy
> > > > > networks <[email-masked]>; roll- [email-masked]; Michael
> > > > > Richardson <[email-masked]>
> > > > > > - 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.
> > > > >
> > > > > 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. :-)
> > > > >
> > > > >
> > > > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST
> > > > > NOT be used
> > > > >    otherwise.
> > > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Alvaro.