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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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