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

[Benjamin Kaduk <[e-mail]>]

Hi Pascal!

On Thu, Sep 10, 2020 at 12:18:48PM +0000, Pascal Thubert (pthubert) wrote:
> 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"

Ah, that would explain why I remembered seeing an "Updating RFC 6550"
section but couldn't find it in the -14!
> "
> 
> 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:

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.

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

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.

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

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

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

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

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

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

Okay, thanks for confirming.

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

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.

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

Thanks for indulging me :)

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

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

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

Works for me, thanks.

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

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

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

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.

> 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

That doesn't inspire any further comments from me.

Thanks!

Ben