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

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

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 <[e-mail]>
> > > Sent: jeudi 24 septembre 2020 17:49
> > > To: Pascal Thubert (pthubert) <[e-mail]>
> > > Cc: Benjamin Kaduk <[e-mail]>; The IESG <[e-mail]>;
> > > draft-ietf- [e-mail]; Martin Duke
> > > <[e-mail]>; Routing Over Low power and Lossy networks
> > > <[e-mail]>; roll- [e-mail]; Michael Richardson
> > > <[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.