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

Benjamin Kaduk <kaduk@mit.edu> Sat, 12 September 2020 01:17 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306203A09A2; Fri, 11 Sep 2020 18:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtfcX4TDJToa; Fri, 11 Sep 2020 18:17:33 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077753A0998; Fri, 11 Sep 2020 18:17:32 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08C1HLCY008584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Sep 2020 21:17:23 -0400
Date: Fri, 11 Sep 2020 18:17:21 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Alvaro Retana <aretana.ietf@yahoo.com>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
Message-ID: <20200912011721.GV89563@kduck.mit.edu>
References: <159968972884.1065.3876077471852624744@ietfa.amsl.com> <MN2PR11MB35659A0710E687A7C9995E6ED8270@MN2PR11MB3565.namprd11.prod.outlook.com> <20200910200744.GE89563@kduck.mit.edu> <MN2PR11MB35657AA34AA0705CC23D53DED8240@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <MN2PR11MB35657AA34AA0705CC23D53DED8240@MN2PR11MB3565.namprd11.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Ogn4h5CK1nF0n02ggsT2h7pY5zM>
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Sep 2020 01:17:35 -0000

On Fri, Sep 11, 2020 at 08:10:29AM +0000, Pascal Thubert (pthubert) wrote:
> 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. 

Indeed, that thread is progressing separately.

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

Yes!  That looks really nice to me; thanks.

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

Okay; thanks for walking through this with me.

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

(Right; sorry that was unclear.)

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

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.

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

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

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