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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 15:15:28 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-roll-turnon-rfc8138-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The situation w.r.t. MOP values 5, 6, and 7 seems inconsistent to me.
We are not allocating them, but we are changing the RFC 6550 behavior in
the presence of at least one of them (but are not currently claiming to
Update 6550).  I have some further thoughts in the COMMENT section, but
I don't think the current state is consistent enough to be approved
as-is.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The description of the RFC 8138 as a "packet compression technique"
throughout the document (e.g., "with the [RFC8138] compression turned
on") has been fairly confusing to me, since as I understand it, RFC 8138
defines a new routing header that just happens to have, as a primary
design consideration, a compression technique included.  So, the
incompatibility between non-8138 and 8138 nodes relates to the
understanding of the header, not the compression within the header.  As
8138 itself puts it: "It is expected that a router that does not
recognize the 6LoRH general format detailed in Section 4 will drop the
packet when a 6LoRH is present."  The discussion in (e.g.) section 5.2
then makes more sense when we have a mix of different header formats in
the same network, etc.  In my mind, the "T" flag is controlling "do we
use RFC 8138" and not "do we use RFC 8138 compression" (but perhaps I'm
just confused!).

This also (perhaps tangentially) relates to the concern brought up at
WG-adoption time relating to whether this is an appropriate mechanism
for conveying this kind of configuration.  If the intent is to say "this
DODAG uses RPL with a given routing header format", that seems a fairly
reasonable match for DODAG configuration information (though not
perfect), whereas "use this compression format for your RPI" seems
somewhat farther removed.  I say it's not a perfect fit for two reasons:
(1) as I understand it, the routing header behavior applies to the whole
RPL instance, not just the specific DODAG, so if there was an "RPL
Instance Configuration Option" that would be better; and (2) the
description in RFC 6550 of the Option is "used to distribute
configuration information for DODAG Operation", but "DODAG Operation" is
not defined.  If it was defined to be affecting the global configuration
for RPL operation within the DODAG that seems a better match for my
understanding of what it's intened to do.  (To be fair, my understanding
is shaped largely by looking at the existing 'A' flag and pondering that
it's not really related to DODAG formation/modification, and
extrapolating from a single data point is risky.)  An Update to RFC 6550
to clarify this aspect of the DODAG Configuration Option would make me
more comfortable with using this mechanism to affect what routing header
is used on the network.

Section 1

   Enabling [RFC8138] requires a Flag Day where the network is upgraded
   and rebooted.  Otherwise, if acting as a Leaf, a node that does not

[My inner pedant notes that this is not true for greenfield deployments,
where the "upgrade" is in place on first boot.]

Section 2.2

   SubDAG:  Subset of a DAG that is a child of a node

(nit) This seems a little ambiguous as to whether the node in question
is included (and also whether inclusion is based on transitive child
relationship vs. direct, though that interpretation doesn't acutally
make sense); perhaps "subset of a DAG that is itself a DAG, rooted at a
given node"?

Section 3

   This specification defines a new flag "Enable RFC8138 Compression"
   (T).  The "T" flag is set to turn-on the use of the compression of
   RPL artifacts with [RFC8138] within the DODAG.  The new "T" flag is
   encoded in position 2 of the reserved Flags field in the RPL DODAG
   Configuration Option, and set to 0 in legacy implementations as
   specified in Section 6.7.6 of [RFC6550].

(I agree with the other comments about "position 2" needing further
explanation, even if that's just a more prominent pointer to the
relevant IANA registry.)

   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
   the DIO Base Object.  This specification applies to MOP values 0 to
   6.  For a MOP value of 7, the compression MUST be used by default
   regardless of the setting of the "T" flag.

I see that this is getting discussed elsewhere already, but it's not
entirely clear to me why we need to be so precise about the future
behavior.  Won't it be fine if whatever document allocates MOP value 7
also says whether or not to use compression^Wthe 8138 header format?
We could say something about "unless otherwise specified by the document
allocating the MOP value, this specification applies", even.

Section 5.2

   the RPL Instance may potentially join any DODAG.  The network MUST be
   operated with the "T" flag reset until all nodes in the RPL Instance
   are upgraded to support this specification.

nit: maybe s/reset/unset/?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Sep 2020 21:35:47 -0400

Benjamin Kaduk via Datatracker <[email-masked]> wrote:
    > We are not allocating them, but we are changing the RFC 6550 behavior
    > in the presence of at least one of them (but are not currently claiming
    > to Update 6550).  I have some further thoughts in the COMMENT section,

I don't know why we aren't Updating 6550.
That's news to me.  I had just assumed we were, and hadn't checked.
I should have.  I see that we are updating 8138, which itself does not update
6550, because 8138 deals with dataplane things only.

We are changing the RFC6550 behaviour in the presence of 0,1,2,3,4,5,6.
But, we are leaving the meaning of this bit when MOP=7 UNDEFINED, to be
defined in a future document.

In short: the bits are really valuable, and we want them back when we do what
we colloquially call "RPLv2".  Because every bit counts for this header that
is always present.

MOP is mostly the highest-level concept.
A node that does not know the MOP can participate as an RPL aware leaf.
(And we now admit RPL unaware leaves, aka "hosts" in another document)

We figure we might discover some horrible pathology in one of the other MOPs,
and we might need 5 or 6 to be able fix it quickly.

We are using MOP=7 as our escape to get more bits, and to let us remove
a decade of accumulated crud.  For instance, the in-band security stuff which
can never work, and which was published against my advice.

We will need a bit of time to get the mopex and planned capabilities sorted
right, and the set of people working on this stuff, and participating in the
IETF is unfortunately still small.

turnon-rfc8138 is the first document that really attempts to address
non-greenfield deployments!

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Sep 2020 12:18:48 +0000

Hello Benjamin

Many thanks for the depth of your review and the considerable amount of time you must have spent on it!

> We are not allocating them, but we are changing the RFC 6550 behavior in the
> presence of at least one of them (but are not currently claiming to Update
> 6550).  I have some further thoughts in the COMMENT section, but I don't
> think the current state is consistent enough to be approved as-is.

As Michael said on this thread. 

You'll find that we had a mention that we update RFC 6550 till -07, e.g., https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-05

This changed with "AD Review of draft-ietf-roll-turnon-rfc8138-07"

"

155	3.  Updating RFC 6550

[major] I don't think that a formal Update to rfc6550 is necessary.
In general, a formal Update indicates (at least to me) that an rfc6550 implementation has to also support this specification.  IOW, all RPL routers will have to support the new flag to be compliant with rfc6550.  Also, rfc8138 did not formally Update rfc6550.
"

So on that one, I will ask you to talk to Alvaro (cc). I am still looking for the final words on what "updates" means!

I'm holding the publication till you and Alvaro agree on this item. For the rest, let's see below:

> on") has been fairly confusing to me, since as I understand it, RFC 8138 defines
> a new routing header that just happens to have, as a primary design
> consideration, a compression technique included. 

Well, I see it differently. RFC 8138 does not define new IPv6 headers. You can always transform an IPv6 packet to the RFC 8138 encoding and back with the IPv6 headers that already exist. It is an extension of the 6LoWPAN Header Compression.
The reason for so many words in the RFC is that we define how to perform the forwarding operations without the need to uncompress.
Making the forwarding a lot simpler for the constrained code than it is with normal IPv6 (think of the swapping with the RH etc...) was another goal of that spec.

> So, the incompatibility
> between non-8138 and 8138 nodes relates to the understanding of the header,
> not the compression within the header.  

True, regardless on whether we agree on the sentence above.

> As
> 8138 itself puts it: "It is expected that a router that does not recognize the
> 6LoRH general format detailed in Section 4 will drop the packet when a 6LoRH
> is present."  The discussion in (e.g.) section 5.2 then makes more sense when
> we have a mix of different header formats in the same network, etc.  In my
> mind, the "T" flag is controlling "do we use RFC 8138" and not "do we use RFC
> 8138 compression" (but perhaps I'm just confused!).

I can live with that. We never went into that discussion doing, say https://tools.ietf.org/html/rfc6282. 
We just call that compression but the same concern applies.

> This also (perhaps tangentially) relates to the concern brought up at WG-
> adoption time relating to whether this is an appropriate mechanism for
> conveying this kind of configuration.  If the intent is to say "this DODAG uses
> RPL with a given routing header format", that seems a fairly reasonable match
> for DODAG configuration information (though not perfect), whereas "use this
> compression format for your RPI" seems somewhat farther removed.

OK

>  I say it's not a perfect fit for two reasons:
> (1) as I understand it, the routing header behavior applies to the whole RPL
> instance, not just the specific DODAG, so if there was an "RPL Instance
> Configuration Option" that would be better; 

We went through that, and initially I wanted per-instance operation too. But this would have required a synchronization between multiple roots in a large instance and RPL has nothing to ensure at that. So we went for a per DODAG operation. Note that packets in a DODAG stay in that DODAG.

> and (2) the description in RFC
> 6550 of the Option is "used to distribute configuration information for DODAG
> Operation", but "DODAG Operation" is not defined.  If it was defined to be
> affecting the global configuration for RPL operation within the DODAG that
> seems a better match for my understanding of what it's intended to do.  (To be
> fair, my understanding is shaped largely by looking at the existing 'A' flag and
> pondering that it's not really related to DODAG formation/modification, and
> extrapolating from a single data point is risky.) 

Maybe you and Alvaro could also consider https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-40#section-4. In this draft, which is rather simple, we went through a sequence of do / undo's in the review handling of IETF last call and beyond. Those opposite pieces of advice came from very seasoned reviewers, Stewart, Alvaro, Eric V. and yourself. 

This is not an easy experience for the authors. I guess I can live with it, having gone through IETF last calls before. But maybe there's something to look at a bit more.

To your point, the intent of the option is to carry the parameters that dictate how RPL operates in the DODAG, in lieu of the traditional way of using CLI on each node, which arguably is not an easy thing in a large network of constrained nodes. We wanted RPL to be self-descriptive, more autonomic if you like, and that made it attractive to ANIMA. Sadly we missed homenet.

> An Update to RFC 6550 to
> clarify this aspect of the DODAG Configuration Option would make me more
> comfortable with using this mechanism to affect what routing header is used
> on the network.

That was my intention. I'll trust you guys on that once you reach an agreement.

> [My inner pedant notes that this is not true for greenfield deployments, where
> the "upgrade" is in place on first boot.]
> 

True; Isn't that the flaggest days of all ; ) ?

What about 
"
    Enabling [RFC8138] on a running network requires a Flag Day where the
   network is upgraded and rebooted.
"

> (nit) This seems a little ambiguous as to whether the node in question is
> included (and also whether inclusion is based on transitive child relationship vs.
> direct, though that interpretation doesn't acutally make sense); perhaps
> "subset of a DAG that is itself a DAG, rooted at a given node"?

My reading, and the intention, is that the node is excluded. One is not one's child.

What I like in your proposal is that it indicates that the subDAG is a DAG, which is a property of the subDAG.
Another property is that it is a DODAG even if the outer DAG itself is not.
Please look at https://www.nist.gov/dads/HTML/subtree.html; I do not feel like debating with Paul Black myself 😉
What about (placing redundant dots on i's which Paul's definition does not)
"
A DODAG rooted at a node which is a child of that node and a subset of a larger DAG
"

> explanation, even if that's just a more prominent pointer to the relevant IANA
> registry.)

OK then. What about:

"
                                                                                  The new "T" flag is
   encoded in position 2 of the reserved Flags field in the RPL DODAG
   Configuration Option (counting from bit 0 as the most significant
   bit) and set to 0 in legacy implementations as specified respectively
   in Sections 20.14 and 6.7.6 of [RFC6550]"

> I see that this is getting discussed elsewhere already, but it's not entirely clear
> to me why we need to be so precise about the future behavior.  Won't it be
> fine if whatever document allocates MOP value 7 also says whether or not to
> use compression^Wthe 8138 header format?

What we aim to do is provide a well-defined behavior for RPL V1 (MOP<7) and for RPL V2 (MOP==7)  in the code that is written today.

Say that the MOP 6 spec redefines the "T" flag. A legacy node written today will misunderstand it and misbehave. We want to avoid that and ensure backwards compatibility so we lock the flag, make it MOP independent for RPL V1. But then, the flags will be obsolete in a future world where all nodes support RFC 8138 and encode the RPI as 0x23. So we decided for this spec as well as for https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo to lock the flags we define for all MOPs in RPL V1 and reopen their definition in RPL V2 (where MOP is 7) and above.

This way a spec that define MOP 6  will know that the "T" flag is understood in a certain fashion by the nodes even if they do not know what to do with the MOP. The conjunction of this and RFC 6550 will for a node running code written today to operate as a leaf in a MOP 6 DODAG - because it does not understand MOP 6 - yet have the default behavior of complying with the "T" flag as defined here, so it can be a well-behaved leaf.

For MOP 7 all bets are off. The expectation is that the "T" flag will not be needed because RFC 8138 will be part of the base mandate. If it Is not, will people can still define the "T" flag again, but that will be part of the new spec. The trouble is that an implementation of today will not use the redefined flag but take compression for granted. If the MOP 7 redefines the flag, an implementation of today will not operate properly. So we accept for MOP 7 what we refuse for MOP < 7.

As it goes, I do not expect people will keep legacy nodes in a RPL V2 network. Too many things change. We add capability negotiation, we add SDN (P-DAO), the MOP is in a MOP-EXT option, ... a RPL V1 will be a second class citizen.

> nit: maybe s/reset/unset/?

Done.

The temporary diff is stored in https://github.com/roll-wg/roll-turnon-rfc8138/commit/c581c66eed7efbaf4476c0a6cd8bb70714aa56ae
Please let me know if I need to do more for the COMMENT piece

Many thanks again!

Pascal

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Sep 2020 13:07:44 -0700

Hi Pascal!

> This changed with "AD Review of draft-ietf-roll-turnon-rfc8138-07"

Ah, that would explain why I remembered seeing an "Updating RFC 6550"
section but couldn't find it in the -14!
> I'm holding the publication till you and Alvaro agree on this item. For the rest, let's see below:

With thanks to Michael for the explanation, I will quote a bit and reply
here since I am replying to the other bits, too:

% We are changing the RFC6550 behaviour in the presence of 0,1,2,3,4,5,6.
% But, we are leaving the meaning of this bit when MOP=7 UNDEFINED, to be
% defined in a future document.

Defining the behavior when the bit is set seems like fairly normal
procedures for allocating something from an IANA registry -- your
implementation knows that the flags are managed by the registry and what to
do if a bit is set that you don't support is well-specified.  That applies
to MOPs 0..6; but the situation for MOP 7 seems slightly different.  If we
were *just* leaving the bit undefined/free for reuse in that situation,
that is probably also something that we can do in a normal "allocate a bit
from an IANA registry" document without need for Updates.  But that's not
all we're doing; we're also saying that if you see MOP==7, then you have to
use the 8138 header/compression/whatever-we-end-up-calling-it.  Yet we are
*not* allocating MOP==7.  So either we are changing the RFC 6550 semantics
for the DODAG Configuration Option or we are placing normative requirements
on some future document that does allocate MOP==7, and I think we have
significant experience to suggest that one RFC placing normative
requirements on future RFCs is not a reliable mechanism ... which makes me
want to go with the "updates 6550" option.  Perhaps marking MOP==7 in the
registry as a placeholder with this doc as a reference could also work, but
it might make mopex a bit messier, procedurally.

> Making the forwarding a lot simpler for the constrained code than it is with normal IPv6 (think of the swapping with the RH etc...) was another goal of that spec.

I am willing to admit the possibility that an outcome leaving me (but not
many other people) confused is the best outcome.

To phrase it differently: "the wire representation of the header is
different (and in at least most cases a lot shorter)".  I can see how
calling this "compression" makes sense, and "the [RFC8138] compressed
header" would not have left me as confused.  I think that seeing "the
[RFC8138] compression" had gotten me thinking that compression was an
optional feature of 8138, so you could have 8138-with-compression and
8138-without-compression, and somehow only the formmer was problematic.

> We just call that compression but the same concern applies.

(Oops, maybe my remark above fits better here.)

> We went through that, and initially I wanted per-instance operation too. But this would have required a synchronization between multiple roots in a large instance and RPL has nothing to ensure at t…

Hmm "packets in a DODAG stay in that DODAG" suggests that my understanding
was incorrect about the scope for which the routing header applies.  IIRC
there's expected to be some backbone bridging going on between DODAG roots
in a multi-DODAG RPL instance but I forget the details (and whether they
can do the necessary packet munging to translate to/from 8138 format).

> This is not an easy experience for the authors. I guess I can live with it, having gone through IETF last calls before. But maybe there's something to look at a bit more.

There may be a broader picture to look at, yes.  I suspect that we are
having to give so much attention and seeing so much churn because this is a
setting where the bits are precious and we want to conserve them as much as
we can, while ensuring that what we specify willy actually work at
conserving them so they are available for reuse (as opposed to discovering
later that we inadvertenly left something that was interpreting the bit and
would break if we tried repurposing it).

> To your point, the intent of the option is to carry the parameters that dictate how RPL operates in the DODAG, in lieu of the traditional way of using CLI on each node, which arguably is not an eas…

Okay, thanks for confirming.

> That was my intention. I'll trust you guys on that once you reach an agreement.

To be clear, I'm looking at something vaguely along the lines of

OLD:

   The DODAG Configuration option is used to distribute configuration
   information for DODAG Operation through the DODAG.

NEW:

   The DODAG Configuration option is used to distribute configuration
   information affecting the construction and maintenance of the DODAG, as
   well as operational parameters for RPL on the DODAG, through the DODAG.

>    network is upgraded and rebooted.

Thanks for indulging me :)

> A DODAG rooted at a node which is a child of that node and a subset of a larger DAG

I think my confusion stems from trying to interpret "child" as being a node
(as in the parent/child node relationship) vs a tree.  If you think it's
clear, please keep it unchanged, but your proposal looks fine to me as
well (though there might be singular/plural questions if the node in
question has multiple children).

>    in Sections 20.14 and 6.7.6 of [RFC6550]"

Works for me, thanks.

> What we aim to do is provide a well-defined behavior for RPL V1 (MOP<7) and for RPL V2 (MOP==7)  in the code that is written today.

Understood.  I think (as I managed to clarify my own thinking earlier) that
I'm mostly concerned about the V2 (MOP==7) case.

> For MOP 7 all bets are off. The expectation is that the "T" flag will not be needed because RFC 8138 will be part of the base mandate. If it Is not, will people can still define the "T" flag again,…

I am interpreting "an implementation of today will not use the redefined
flag but take compression for granted" as meaning that if this document
just allocates the "T" flag normally, an implementation written
~now that supports the "T" flag would have to interpret that bit as
indicating use of 8138/compression even for MOP==7, and we don't want do do
that since we expect it to be redundant for MOP==7.

This, in light of my comment above, makes me think that what we really want
to do is just say that "the allocation of the T flag applies only for MOP
values 0 through 6; the bit in position 2 is considered unallocated for MOP==7
at the time of this writing (consult IANA for current information)".
Whether or not 8138 compression actually is the only choice for MOP==7 can
then be left to the mopex spec, without prior restraint from this document.

> Please let me know if I need to do more for the COMMENT piece

That doesn't inspire any further comments from me.

Thanks!

Ben

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 10 Sep 2020 16:58:33 -0400

Hi!

Jumping in here on the Updates/MOP 7 point.

The only reason we’re trying to treat MOP 7 differently is because we (the
WG) know that the mopex draft is coming…which is the future document that
will define what 7 really means.

However, we’re still not there…and the mopex draft should be the one
defining all the changes.

I think the easiest thing to do at this point is to ignore mopex, and the
knowledge that things will change in the future…because we still don’t know
exactly what that future will be…this extension should then simply be
defined as other extensions have been: applicable to all MOPs.  When mopex
comes we can deal with the respective Updates, changes to the registries,
etc.

Alvaro.

On September 10, 2020 at 4:07:54 PM, Benjamin Kaduk ([email-masked]) wrote:

Hi Pascal!

> Many thanks for the depth of your review and the considerable amount of
time you must have spent on it!
in the
> You'll find that we had a mention that we update RFC 6550 till -07, e.g.,
https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-05

> In general, a formal Update indicates (at least to me) that an rfc6550
implementation has to also support this specification. IOW, all RPL routers
will have to support the new flag to be compliant with rfc6550. Also,
rfc8138 did not formally Update rfc6550.
> "
>
> So on that one, I will ask you to talk to Alvaro (cc). I am still looking
for the final words on what "updates" means!

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Sep 2020 14:08:57 -0700

> comes we can deal with the respective Updates, changes to the registries,

That seems like it's setting us up for exactly the situation that
Pascal/Michael want to avoid -- if we allocate the T flag "normally" then
an implementation written next month will treat the bit in position 2 as
the T flag, independnetly of the MOP value.  When MOP==7 finally comes
along then the bit is burned and can't be repurposed, so long as that
implementation is still deployed, and that can't be fixed by Updates or
registry changes.

Is it so bad to say that the bit allocation is only defined for a subset of
MOPs?

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Sep 2020 05:42:28 +0000

Hello Benjamin 

There might be a misunderstanding here.

The current text is good to this respect -we only define the flag for MOP<7) and this is the product of Alvaro’s work with us. I believe we all agree on that goal.

What we decided not to do for MOP 7 is to start doing IANA work and split the registry. The reason is that the current registry applies to all existing mops and 7 does not exist. If 7 or later reuses the flags then that will be the time for IANA work.

The tricky piece is what we code now for MOP 7 so it can be reused in the future. The point is that this is a transition technique so we need to align the default to the world after the transition. 

My reading of the argument on the table is the subtle question of updating RFC 6550. I read that the time bomb  on a Flag is a change in RPL’s way and that it would justify the claim that this is effectively an update.

I tend to agree with this. If Alvaro agrees too then I MHO we could resolve the issue by restoring the update signal, is that right?

I’ll answer your other point in your longer mail.

Many thanks for caring!!!

Pascal

> Le 10 sept. 2020 à 23:09, Benjamin Kaduk <[email-masked]> a écrit :
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Sep 2020 08:10:29 +0000

<snip>

> implementation has to also support this specification.  IOW, all RPL routers will
> have to support the new flag to be compliant with rfc6550.  Also, rfc8138 did
> not formally Update rfc6550.
> > "
> >
> With thanks to Michael for the explanation, I will quote a bit and reply here
> since I am replying to the other bits, too:
> 
> Defining the behavior when the bit is set seems like fairly normal procedures
> for allocating something from an IANA registry -- your implementation knows
> that the flags are managed by the registry and what to do if a bit is set that you
> don't support is well-specified.  That applies to MOPs 0..6; but the situation for
> MOP 7 seems slightly different.  If we were *just* leaving the bit
> undefined/free for reuse in that situation, that is probably also something that
> we can do in a normal "allocate a bit from an IANA registry" document without
> need for Updates.  But that's not all we're doing; we're also saying that if you
> see MOP==7, then you have to use the 8138 header/compression/whatever-
> we-end-up-calling-it.  Yet we are
> significant experience to suggest that one RFC placing normative requirements
> on future RFCs is not a reliable mechanism ... which makes me want to go with
> the "updates 6550" option.  Perhaps marking MOP==7 in the registry as a
> placeholder with this doc as a reference could also work, but it might make
> mopex a bit messier, procedurally.

We considered that latter option and dismissed it. Will create a IANA registry when a MOP-EXT needs to reuse the flags. 
Might not be needed for a while. 

I read that the proposal on the table is to restore the 'updates' to support the fact that we timebomb the DODAG configuration flags to MOP<7. I tend to agree with it.

Yes, let us follow that up separately with Alvaro. 

<snip>

> To phrase it differently: "the wire representation of the header is different
> (and in at least most cases a lot shorter)".  

Yes

> I can see how calling this
> "compression" makes sense, and "the [RFC8138] compressed header" would
> not have left me as confused.  I think that seeing "the [RFC8138] compression"
> had gotten me thinking that compression was an optional feature of 8138, so
> you could have 8138-with-compression and 8138-without-compression, and
> somehow only the former was problematic.

Oh, that I can do. I looked at the first and third paragraphs and from this discussion it seem I could improve them a bit:

"
   The design of Low Power and Lossy Networks (LLNs) is generally
   focused on saving energy, which is the most constrained resource of
   all.  The routing optimizations in the "Routing Protocol for Low
   Power and Lossy Networks" [RFC6550] (RPL) such as routing along a
   Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node
   and the associated routing header compression and forwarding
   technique specified in [RFC8138] derive from that primary concern.

   Enabling [RFC8138] on a running network requires a Flag Day where the
   network is upgraded and rebooted.  Otherwise, if acting as a Leaf, a
   node that does not support the compression would fail to communicate;
   if acting as a router it would drop the compressed packets and black-
   hole a portion of the network.  This specification enables a hot
   upgrade where a live network is migrated.  During the migration, the
   compression remains inactive, until all nodes are upgraded.

   This document complements [RFC8138] and signals whether it should be
   used within a RPL DODAG with a new flag in the RPL DODAG
   Configuration Option.  The setting of this new flag is controlled by
   the Root and propagates as is in the whole network as part of the
   normal RPL signaling.

"

<snip>

> > > (1) as I understand it, the routing header behavior applies to the
> > > whole RPL instance, not just the specific DODAG, so if there was an
> > > "RPL Instance Configuration Option" that would be better;
> >
> > We went through that, and initially I wanted per-instance operation too. But
> this would have required a synchronization between multiple roots in a large
> instance and RPL has nothing to ensure at that. So we went for a per DODAG
> operation. Note that packets in a DODAG stay in that DODAG.
> 
> Hmm "packets in a DODAG stay in that DODAG" suggests that my
> understanding was incorrect about the scope for which the routing header
> applies.  IIRC there's expected to be some backbone bridging going on
> between DODAG roots in a multi-DODAG RPL instance but I forget the details
> (and whether they can do the necessary packet munging to translate to/from
> 8138 format).

OK, I need to reword. 
Your memory serves you well: an instance can aggregate multiple DODAGs, with a backbone, each DODAG having its own root connected to the same backbone. This is where the backbone router draft plays by the way. There could also be a routing protocol forming an "area 0".
What  I meant is that the packets that are in the DODAG do not jump into another DODAG with the same instance. That's the nature of the graph.
Initially the DODAG was a stub, so the packet could only enter / exit via the root. With useofRPL info and unaware leaves, we opened to external destination connected at the leaf edge.

<snip>

> > > An Update to RFC 6550 to
> > > clarify this aspect of the DODAG Configuration Option would make me
> > > more comfortable with using this mechanism to affect what routing
> > > header is used on the network.
> >

This text is from RFC 6550 not this draft. What I can do to implement this change is this:
"
3.  Updating RFC 6550

   The DODAG Configuration Option is defined in Section 6.7.6 of
   [RFC6550].  Its purpose is extended to distribute configuration
   information affecting the construction and maintenance of the DODAG,
   as well as operational parameters for RPL on the DODAG, through the
   DODAG.  As shown in Figure 1, the Option was originally designed with
   4 bit positions reserved for future use as Flags.

"

<snip> 

> > > (nit) This seems a little ambiguous as to whether the node in
> > > question is included (and also whether inclusion is based on transitive child
> relationship vs.
> > > direct, though that interpretation doesn't acutally make sense);
> > > perhaps "subset of a DAG that is itself a DAG, rooted at a given node"?
> >
> > Please look at https://www.nist.gov/dads/HTML/subtree.html; I do not
> > feel like debating with Paul Black myself 😉
> > What about (placing redundant dots on i's which Paul's definition does
> > not) "
> > A DODAG rooted at a node which is a child of that node and a subset of
> > a larger DAG "
> 
> I think my confusion stems from trying to interpret "child" as being a node (as
> in the parent/child node relationship) vs a tree.  If you think it's clear, please
> keep it unchanged, but your proposal looks fine to me as well (though there
> might be singular/plural questions if the node in question has multiple
> children).

The change was applied in the previous commit. I'm happy with it.

<snip>

> > > behavior.  Won't it be fine if whatever document allocates MOP value
> > > 7 also says whether or not to use compression^Wthe 8138 header format?
> > > We could say something about "unless otherwise specified by the
> > > document allocating the MOP value, this specification applies", even.
> >
> > What we aim to do is provide a well-defined behavior for RPL V1 (MOP<7)
> and for RPL V2 (MOP==7)  in the code that is written today.
> 
> Understood.  I think (as I managed to clarify my own thinking earlier) that I'm
> mostly concerned about the V2 (MOP==7) case.

Yep, that will continue in the other thread with Alvaro.

> >
> > For MOP 7 all bets are off. The expectation is that the "T" flag will not be
> needed because RFC 8138 will be part of the base mandate. If it Is not, will
> people can still define the "T" flag again, but that will be part of the new spec.
> The trouble is that an implementation of today will not use the redefined flag
> but take compression for granted. If the MOP 7 redefines the flag, an
> implementation of today will not operate properly. So we accept for MOP 7
> what we refuse for MOP < 7.
> 
> I am interpreting "an implementation of today will not use the redefined flag
> but take compression for granted" as meaning that if this document just
> allocates the "T" flag normally, an implementation written ~now that supports
> the "T" flag would have to interpret that bit as indicating use of
> 8138/compression even for MOP==7, and we don't want do do that since we
> expect it to be redundant for MOP==7.
> 
> to do is just say that "the allocation of the T flag applies only for MOP values 0
> through 6; the bit in position 2 is considered unallocated for MOP==7 at the
> time of this writing (consult IANA for current information)".

Yes, this is what the text tries to say. Your wording might be more accurate, though. 
What about
"

   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
   the DIO Base Object.  This specification applies to MOP values 0 to
   6.  For a MOP value of 7, the bit in position 2 is considered
   unallocated and [RFC8138] MUST be used by default.
"

> then be left to the mopex spec, without prior restraint from this document.

I do not believe so. 

People who implement this spec will write code like
If (MOP<7) { /* use the T flag */ } else { /* argl what do I do here ???? */ }

We cannot leave that open ended can we? 

We discussed that in the ML and decided to provide the sensible default that is that RPL v2 will mandate support of RFC 8138.

I pushed the new set of diffs in github as https://github.com/roll-wg/roll-turnon-rfc8138/commit/f330051fa0286c4ea5efa5d7dcff61bec81e486b

The other recent changes I made for your review are also visible, here https://github.com/roll-wg/roll-turnon-rfc8138/commits/master

Please note that the change set includes restoring the update thingy.

Many thanks again!!!

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Sep 2020 12:23:50 -0400

Benjamin Kaduk <[email-masked]> wrote:
    > from an IANA registry" document without need for Updates.

Up to here, we agree.

    > But that's not
    > *not* allocating MOP==7.

Tthat's exactly what we don't want to do.

We are saying NOTHING about rfc8138 when MOP==7.
Nor are we saying that the T-bit exists (or doesn't exist).

What behaviour is default and what behaviour is negotiated, and how it it
negotiated, and how the results are turned on, would be up to a document that
specifies MOP=7 (or larger mopex)

As an analogy, when we did the ToS->DSCP + bits-that-became-ECN
change, we did this for IP_version==4 and IP_version==6.
We specifically did not change it for IP_version==7 or 8.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Sep 2020 09:26:17 -0700

> Nor are we saying that the T-bit exists (or doesn't exist).

That's not how I read:

       For a MOP value of 7, the compression MUST be used by default
   regardless of the setting of the "T" flag.

> specifies MOP=7 (or larger mopex)

What you describe here is more along the lines of what I expected.

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Sep 2020 19:16:35 +0000

Now I’m unsure Michael and I agree anymore. 

What will today’s developer code?

We ask him to test if mop is < 7

What value will the developer place in his code if the test returns false?

If there is no code the Boolean will be uninitialized and the result will depend on the type of variable and the compiler. 

Whatever the developer does the code will end up having a behavior, compression or not.

 Leaving it to the implementation will have some people choose true and others false. This is not what we want.

We want to control what the code does so we can expect it in the future and build our backward compatibility based on that sure knowledge.

Before the draft the default was no compression. Quite naturally since initially it did not exist.

Also we discussed on the ML that for RPLv2 all implementations MUST support the compression. 

In which case it is a better default for a coder today to decide to use the compression for mop 7, isn’t it?

I hope I make the case right. Just think you’re coding it!

Take care,

Pascal

> Le 11 sept. 2020 à 18:26, Benjamin Kaduk <[email-masked]> a écrit :
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Sep 2020 15:37:25 -0400

> regardless of the setting of the "T" flag.

While I think that's probably what we'll conclude, this wasn't in for WGLC
that I recall.  I think that this also must have gotten in during IESG review.

Pascal, can we make this say:
    For a MOP value of 7, there is no "T" flag, and the compression
    behaviour will be defined by future work.

---

From: Martin Duke <[email-masked]>
Date: Fri, 11 Sep 2020 12:53:08 -0700

>     behaviour will be defined by future work.
I believe this text would be sufficient to lift my DISCUSS, though I don't
completely understand the interaction between MOP and versioning in this
protocol.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 11 Sep 2020 16:24:52 -0400

On September 11, 2020 at 3:37:32 PM, Michael Richardson wrote:

> Pascal, can we make this say: For a MOP value of 7, there is no "T" flag,
> and the compression behaviour will be defined by future work.

If we do that, this would be the first document to indicate that the
flags apply to some MOPs and not other.  In this case the bit used for
the T flag would still be available for MOP 7.

Besides possibly updating rfc6550 to indicate that this is possible,
we will also need to update the registry so that we can show how the
bits are allocated: bit 2 is allocated for 0-6, and available for MOP
7.

All that can be done.

I was trying to avoid that work given that we don't know exactly what
MOP 7 will be; while there's a chance that the mopex draft will build
on the changes we would do here, there could also be a chance that it
doesn't.

In any case, this is probably something that needs to be discussed in the WG.

Alvaro.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Sep 2020 18:17:21 -0700

> Yes, let us follow that up separately with Alvaro. 

Indeed, that thread is progressing separately.

>    the Root and propagates as is in the whole network as part of the

Yes!  That looks really nice to me; thanks.

> Initially the DODAG was a stub, so the packet could only enter / exit via the root. With useofRPL info and unaware leaves, we opened to external destination connected at the leaf edge.

Okay; thanks for walking through this with me.

> This text is from RFC 6550 not this draft. What I can do to implement this change is this:

(Right; sorry that was unclear.)

>    4 bit positions reserved for future use as Flags.

That's along the lines of what I was imagining (but I recognize that it's
kind of a significant change at a late stage in the process, and am not
trying to push for making this change if this is not reflecting what the
intent and consensus of the WG has been all along.  One nit about the
specific text: the construction "is extended to <X> as well as <Y>" is
often used to indicate that a thing was originally specified to do <Y> is
being modified to also allow <X>, which is in some sense the reverse of
what is happening here.  (But perhaps only in some sense, and not
unambiguously so.)  Alternately, if this is just clarifying the original
intent, different wordings are possible, but I don't have the background to
know if that's the case.

> > then be left to the mopex spec, without prior restraint from this document.

It seems that this part is going to depend on the other thread, so I won't
touch on it here.  I do see your point that getting the implementations to
do the right thing is ultimately what we need to get right.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Sep 2020 18:21:54 -0700

> completely understand the interaction between MOP and versioning in this

I believe it would also be sufficient to lift my DISCUSS (given the
discussion we've had already) ... but it is unclear whether it is actually
the right thing to do.  I'm hoping that Michael (or others in the WG, of
course) will chime in on the "what do we want an implementation to do?"
question.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Sep 2020 13:42:44 -0400

> What value will the developer place in his code if the test returns

That's a good question.
Pascal, it your intention that 8138 be turned on in this case?

I'm not opposed to that conclusion, but I thought that the goal was to move
the signaling to mopex/capabilities/TBD?

Would there be cases in the future where ONLY 8138 compression would be coded?

We have set the situation where if a node does not understand the MOP, it can
be a leaf, but 8138 incompatibility makes that not work.

    > We want to control what the code does so we can expect it in the future
    > and build our backward compatibility based on that sure knowledge.

    > Also we discussed on the ML that for RPLv2 all implementations MUST support the compression.

Just consider that for some link layers, 8138 compression might not make sense.

    > I hope I make the case right. Just think you’re coding it!

We're assuming someone coding today.
Someone who is not writing MOP=7 code, has no mopex or capabilities code,
because we haven't defined that.
We agree that the "T" flag does not exist, and should be checked.
Such a node would be a leaf.

I can live with defaulting 8138 to be on for MOP=7 for link layers for which
8138 is appropriate. (Someone coding today will know what link layers they
have)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 12 Sep 2020 21:52:13 +0000

Hello Michael 

I agree that for some link layer compression is not useful. I expect that this means higher power devices on less constrained links. For those there is configuration and management that can override the default . 

For unmanaged high volumes of low power devices and constrained radios, I’d rather have it on. And I agree that the node can only be a leaf in a mop 7 network.

Take care,

Pascal

> Le 12 sept. 2020 à 19:52, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Sep 2020 14:15:21 +0000

Hello Benjamin and Alvaro

I published the latest to have a fresh reference point.

There seems to be an agreement that 
1) we need to tell the implementer what to do when MOP ==7
2) The changes are updating RFC 6550 formally.

This is reflected in draft 15 as published.

Please let me know if I mossed something!

Take care,

Pascal

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: vendredi 11 septembre 2020 21:17
> To: Benjamin Kaduk <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; Routing Over Low power
> and Lossy networks <[email-masked]>; [email-masked]; Alvaro Retana
> <[email-masked]>; Ines Robles <[email-masked]>;
> [email-masked]; The IESG <[email-masked]>
> Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-
> 14: (with DISCUSS and COMMENT)
> 
> If there is no code the Boolean will be uninitialized and the result will depend
> on the type of variable and the compiler.
> 
> We want to control what the code does so we can expect it in the future and
> build our backward compatibility based on that sure knowledge.
> 
> >>> to MOPs 0..6; but the situation for MOP 7 seems slightly different.
> >>> If we were *just* leaving the bit undefined/free for reuse in that
> >>> situation, that is probably also something that we can do in a
> >>> normal "allocate a bit from an IANA registry" document without need for
> Updates.
> >>
> >> Up to here, we agree.
> >>
> >>> But that's not
> >>> all we're doing; we're also saying that if you see MOP==7, then you
> >>> have to use the 8138
> >>> header/compression/whatever-we-end-up-calling-it.  Yet we are
> >>> *not* allocating MOP==7.
> >>
> >> What behaviour is default and what behaviour is negotiated, and how
> >> it it negotiated, and how the results are turned on, would be up to a
> >> document that specifies MOP=7 (or larger mopex)
> >

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 18 Sep 2020 08:47:14 -0700

[Cutting the list a little.]

Pascal:

Hi!

I think we should talk live about this — if there’s time on the Interim
(Inés?), then maybe we can do it there since the RPLv2 topic seems to be on
the agenda.  Or we could do it before — give me a couple of options for
next week.  It would be ideal to have you, Michael and one of the Chairs,
at least, on the call — we can of course open the call to anyone once we
figure out a time that works.

Thanks!

Alvaro.

On September 18, 2020 at 10:15:24 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

Take care,

Pascal

Pascal

> We want to control what the code does so we can expect it in the future
and
> Before the draft the default was no compression. Quite naturally since
initially
> it did not exist.
>
> Also we discussed on the ML that for RPLv2 all implementations MUST
support
> the compression.
>
> In which case it is a better default for a coder today to decide to use
the
> compression for mop 7, isn’t it?
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Sep 2020 16:57:35 +0000

Hello Alvaro

I’m available 8->11AM eastern every day next week but Thursday where it’s till 10 AM :)

Take care

Pascal

Le 18 sept. 2020 à 17:47, Alvaro Retana <[email-masked]> a écrit :

Pascal:

Hi!

I think we should talk live about this — if there’s time on the Interim (Inés?), then maybe we can do it there since the RPLv2 topic seems to be on the agenda.  Or we could do it before — give me a couple of options for next week.  It would be ideal to have you, Michael and one of the Chairs, at least, on the call — we can of course open the call to anyone once we figure out a time that works.

Thanks!

Alvaro.

On September 18, 2020 at 10:15:24 AM, Pascal Thubert (pthubert) ([email-masked]<mailto:[email-masked]>) wrote:

Take care,

Pascal

Pascal

> To: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
> Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; Routing Over Low power
> and Lossy networks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alvaro Retana
> <[email-masked]<mailto:[email-masked]>>; Ines Robles <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>
> > Le 11 sept. 2020 à 18:26, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> a écrit :
> >
> >> Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
> >> Michael Richardson <[email-masked]<mailto:[email-masked]>> . o O ( IPv6 IøT consulting )

---

From: Martin Duke <[email-masked]>
Date: Fri, 18 Sep 2020 10:43:52 -0700

So I think this update somewhat clarifies the meaning of the original text,
but I am still somewhat concerned about that meaning. Perhaps I just don't
understand how DIO versioning works.

Are the MOP codepoints meant to represent different ways of parsing the DIO
base object? It seems very odd to me that this document is describing
behavior in any way for MOP 5 and up, as there is no IETF consensus on what
these codepoints are going to represent. Is the intent of this language to
avoid having to write in every future specification "nodes using this MOP
MUST use RFC 8138 and the T bit is reserved."?

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 18 Sep 2020 14:45:51 -0400

Martin:

Hi!

We (the authors and me) are having a live discussion about this next week.  I don’t think this is the final version.  Please hold tight.

The WG has an interim programmed for Sep/30, where we may discuss the overall direction as well.

Thanks!

Alvaro.

On September 18, 2020 at 1:44:04 PM, Martin Duke ([email-masked]) wrote:

So I think this update somewhat clarifies the meaning of the original text, but I am still somewhat concerned about that meaning. Perhaps I just don't understand how DIO versioning works.

Are the MOP codepoints meant to represent different ways of parsing the DIO base object? It seems very odd to me that this document is describing behavior in any way for MOP 5 and up, as there is no IETF consensus on what these codepoints are going to represent. Is the intent of this language to avoid having to write in every future specification "nodes using this MOP MUST use RFC 8138 and the T bit is reserved."?

On Fri, Sep 18, 2020 at 7:15 AM Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
Hello Benjamin and Alvaro

Take care,

Pascal

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Sep 2020 20:47:57 +0000

It’s not an easy one Martin

With this bit we cover a transition after which we reclaim the bits. So we want a time bomb.

After the transition the thing signaled by the bit will be always on.

For a number of reasons there will be a RPLv2 and that one we decided will have MOP7.

The leaves 5 and 6 that can still be defined with the bits meaningful. Those may never be defined.

The question is what the cider does today in his code for those value of MOP. We need to tell him something...

Keep safe.

Pascal

Le 18 sept. 2020 à 19:44, Martin Duke <[email-masked]> a écrit :

On Fri, Sep 18, 2020 at 7:15 AM Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
Hello Benjamin and Alvaro

Take care,

Pascal

Pascal

---

From: Martin Duke <[email-masked]>
Date: Fri, 18 Sep 2020 14:02:50 -0700

Again, I don't understand the protocol evolution model here, but isn't the
coder *already* in a fix if she encounters an unknown MOP?

On Fri, Sep 18, 2020, 13:48 Pascal Thubert (pthubert) <[email-masked]>
wrote:

> So I think this update somewhat clarifies the meaning of the original
> text, but I am still somewhat concerned about that meaning. Perhaps I just
> don't understand how DIO versioning works.
>
> Are the MOP codepoints meant to represent different ways of parsing the
> DIO base object? It seems very odd to me that this document is describing

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 22:04:53 -0400

> coder *already* in a fix if she encounters an unknown MOP?

YES, but, for an unknown MOP, they can become an RPL-aware leaf.
However, they can't if they don't know if they are allowed to turn on 8138 or
not. (or maybe forbidden from having it off!)
For almost any other control plane option, it wouldn't matter, but this is
actually a dataplane control option.

** Perhaps I'm being too anal about saying that MOP==7 that 8138 action should not be
** defined here, but by a future document.

I'm actually now convinced I am.
I think it's fine to say that for MOP==7, one should assume 8138 is turned
on, for media on which it makes sense.

8138 is afterall, a 6lowpan thing, and RPL can run on other media!

Part of the issue is that the *mopex* document assumes that MOP==7 will mean
that there is a mopex. (as I recall).

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Sep 2020 20:31:07 -0400

okay, here is my summary of the issues that are outstanding for roll-turnon-rfc8138.
I am writing this in the hope that I've captured everything.

1) Will RFC8138 be enabled for MOP==7?  For what media?
   I see that my notion that it should be undefined is not reasonable, and I
   step back from this.

2) In what way does the format of the DIO Base Object depend upon the MOP
   value?  It seems that we need to update 6550 to say something.

3) While RUL document mandates that RULs must support 8138, it is not
   clear to me if RULs can operate in a pre-8138 network. What if they
   send 8138 compression?
   It may be that none of the compressions that 8138 creates
   will ever be emitted by a RUL, since they are all about IPIP compression
   and RH3 compression, but I haven't checked.

4) we seem to be fine for 802.15.4 networks of all sorts.
   I suspect that we are okay for all the other layers (BTLE, DECT, BACnet)
   that leverage rfc4944 through the various upgrades.  But, we are sure?
   What happens on devices with multiple interfaces of different types?
   Maybe this is an RFC8138 issue really.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Sep 2020 11:22:11 +0000

All very good questions, Michael, 

And it seems that we are converging. 

I read the quasi-suggestion that we align the default for MOP 7 to whether 6LoWPAN HC is running on the medium? Looks good.

I have one last question, how does this discussion impact useofrpl and unaware-leaves, since they both define flags in the RPL DODAG config option. Should we converge the language? Do they all update RPL?

Talk to you all in a few hours,

Pascal

> From: Michael Richardson <[email-masked]>
> Sent: lundi 21 septembre 2020 02:31
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Ines
> Robles <[email-masked]>; Alvaro Retana
> <[email-masked]>
> Subject: Agenda for Monday (Re: MOP==7 live discussion )
> 
>

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 21 Sep 2020 05:51:26 -0700

Hi!

I can’t stay the whole 2 hours…so I want to bash the agenda to add another
question at the top.

() Should the MOP 7 Updates to rfc6550 be part of the turnon,
unaware-leaves, useofrplinfo drafts?  I believe the answer is no, and I
would like to make the case on the call.

BTW, on (3), unaware-leaves says that the RUL is not expected to support
rfc8138.   Not expected is not the same as saying that they never will send
compressed data…

Thanks!

Alvaro.

On September 21, 2020 at 7:22:26 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

I read the quasi-suggestion that we align the default for MOP 7 to whether
6LoWPAN HC is running on the medium? Looks good.

I have one last question, how does this discussion impact useofrpl and
unaware-leaves, since they both define flags in the RPL DODAG config
option. Should we converge the language? Do they all update RPL?

Pascal

> okay, here is my summary of the issues that are outstanding for
roll-turnon-
> rfc8138.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Sep 2020 13:34:38 +0000

Hello Alvaro,

I cannot believe we’ll need 2 hours. But certainly we can start with the high level discussions on how this impacts the 3 drafts, before we dive in how to treat RFC 8138 with MOP 7.

Take care,

Pascal

From: Alvaro Retana <[email-masked]>
Sent: lundi 21 septembre 2020 14:51
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Michael Richardson <[email-masked]>; Ines Robles <[email-masked]>
Subject: RE: Agenda for Monday (Re: MOP==7 live discussion )

Hi!

I can’t stay the whole 2 hours…so I want to bash the agenda to add another question at the top.

() Should the MOP 7 Updates to rfc6550 be part of the turnon, unaware-leaves, useofrplinfo drafts?  I believe the answer is no, and I would like to make the case on the call.

BTW, on (3), unaware-leaves says that the RUL is not expected to support rfc8138.   Not expected is not the same as saying that they never will send compressed data…

Thanks!

Alvaro.

On September 21, 2020 at 7:22:26 AM, Pascal Thubert (pthubert) ([email-masked]<mailto:[email-masked]>) wrote:
All very good questions, Michael,

Pascal

> From: Michael Richardson <[email-masked]<mailto:[email-masked]>>
> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Ines
> Robles <[email-masked]<mailto:[email-masked]>>; Alvaro Retana
> <[email-masked]<mailto:[email-masked]>>

---

From: Ines Robles <[email-masked]>
Date: Mon, 21 Sep 2020 16:39:56 +0300

Hi,

Questions tracked here: https://codimd.ietf.org/roll_MOP_20200921?both

The 2 hours are reserved just in case, I hope everything is solved before
the 2 hours :)

br, Ines

On Mon, Sep 21, 2020 at 4:34 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Alvaro,
>
>
>
> I cannot believe we’ll need 2 hours. But certainly we can start with the
> high level discussions on how this impacts the 3 drafts, before we dive in
> how to treat RFC 8138 with MOP 7.
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* Alvaro Retana <[email-masked]>
> *Sent:* lundi 21 septembre 2020 14:51
> *To:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked];
> Michael Richardson <[email-masked]>; Ines Robles <
> [email-masked]>
> *Subject:* RE: Agenda for Monday (Re: MOP==7 live discussion )
>
>
>
> Hi!
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Sep 2020 12:12:32 +0000

Dear all

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/

There is also a HTML versions available at:
https://www.ietf.org/id/draft-ietf-roll-turnon-rfc8138-16.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-16

Please let me know if there is some issue left with this!

Keep safe,

Pascal

> Sent: samedi 19 septembre 2020 04:05
> To: Martin Duke <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>; Pascal Thubert (pthubert)
> <pthubert=[email-masked]>; Benjamin Kaduk <[email-masked]>;
> Alvaro Retana <[email-masked]>; [email-masked]; Routing Over
> Low power and Lossy networks <[email-masked]>; Ines Robles
> <[email-masked]>; [email-masked];
> The IESG <[email-masked]>; Alvaro Retana <[email-masked]>
> not. (or maybe forbidden from having it off!) For almost any other control
> plane option, it wouldn't matter, but this is actually a dataplane control option.
> 
> I think it's fine to say that for MOP==7, one should assume 8138 is turned on,
> for media on which it makes sense.
> 
> Part of the issue is that the *mopex* document assumes that MOP==7 will
> mean that there is a mopex. (as I recall).
> 
> 
> 
> --

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 24 Sep 2020 11:48:31 -0400

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

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: Thu, 24 Sep 2020 15:54:52 +0000

OK Alvaro, 

I'll make that change in both unaware leaves and this, since they are aligned to similar wording.

Take care,

Pascal

> 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]>
> > 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
> 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. :-)
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Sep 2020 16:25:10 +0000

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