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

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

Hello Benjamin

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

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

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:

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

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.



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

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

> 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"?

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
"

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

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]"


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

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.



> 
> 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/?
> 

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