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

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

Hello Benjamin:



> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --

<snip>


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

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. 

> 
> >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --

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

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

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

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> 


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

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


<snip>

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

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

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

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

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