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

Martin Duke <martin.h.duke@gmail.com> Tue, 10 November 2020 23:16 UTC

Return-Path: <martin.h.duke@gmail.com>
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 7972B3A11DA; Tue, 10 Nov 2020 15:16:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Urq1lmGyg3ta; Tue, 10 Nov 2020 15:16:20 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A043A11DB; Tue, 10 Nov 2020 15:16:19 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id u19so260004ion.3; Tue, 10 Nov 2020 15:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4UV4Yz8d7u6yoTVE7Y+99slrM8YgQH5x8nnHsoTyzHY=; b=PPFCOSQDuzJ5pepN+Ano2UcIClml4JnKfvaI9Kdg/pGVK4H1yqaVmi3/tLwCXerN8C 2oFghImN42ejCHMJolJdx/JE5gP8c9vZgJOzGjudP+PofgLI+olTfjxkMYmDRPenJDxJ UvmliDeV9AKlNsp1D1Y6li+m8j2mLVhibDJ+kT5lrmp5B9Q/5YVP6YGEFJhiBTSTJFKp q66dLsbTlJ9Tt4uJPcLNcF4OIDB707nJ8MbVfwPeSfOCSaJYZQxuoLRXs3pgBcOGJLxV Tq0/5zFpIQ0zgfvUNLbzjrR2Vy0Y5U48GeGIEcxR3S+MU/8Ku1lUNfEVdgcZQC0zemxf ydPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4UV4Yz8d7u6yoTVE7Y+99slrM8YgQH5x8nnHsoTyzHY=; b=DQnTDOfAcCmMrVCxQAdiN3ol/vKrdgPflOaFBQlxfAWRcplN2FKXZ981791L7/uXTY XWIxmS9dVjG4CmH9G40UcvxFbyhvL069HyBOAsNtFY42jHsiC+jQAHZnTocLr2i2T5Mj 2DaiyxSpQ6H1p+X/RDRTXbkGUON5PAB4LoXtZSe2AgjozNEUwoBQAIy2g6JuqdpUAWbm OqfGLNGzarx5xcFoeTCH/W51m3PZjn3OkBZbSdJU5AUUrxfgMHgXTy7joY7hSS+va6eL ix1i9w6Eza+l7io8hoGnfbHNmtUfY5Vfe1RU9dGgLXlOanh6dO2e/Zpmdi+bnSJ8vfJ1 AuJw==
X-Gm-Message-State: AOAM5334MpJadl4dDyj7kteJ1cLuJIUm0Y9vJB6IvWakoKcxznvoyBC1 N/A7uFFAPFjIGCGijpbCUArVqDLHX1e/BybhCKA=
X-Google-Smtp-Source: ABdhPJzDpZBz7AamSz2jWysH1D59VMtti26AEjK3/1ZBTipPpHXQqMAYdb1ReQwy5nIw95hF4DOWCXRXSKztuJ80dqA=
X-Received: by 2002:a05:6602:2d93:: with SMTP id k19mr15818801iow.51.1605050178505; Tue, 10 Nov 2020 15:16:18 -0800 (PST)
MIME-Version: 1.0
References: <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <MN2PR11MB3565F2602A0DC55DE9FF3604D83F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAM4esxQBL+4wNzJTZ_+QKMCGuo4fgyxZKxr3xmFDVEAn9J7HLQ@mail.gmail.com> <E8B2CE91-7FEE-4728-A280-935B69EF3E91@cisco.com> <CAM4esxQpcWROj9mMd3iUXr1EF8kvoF8Zmq-w4BPFVW+BtDU93w@mail.gmail.com> <117497.1600481093@dooku> <MN2PR11MB356549C173D8027709AAC777D8390@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESswOs7ZQ3502dNYBN=qJp7O9Ddi=F3UL40Ce7JGknMq-wA@mail.gmail.com> <MN2PR11MB3565C3DB9AFAABD9E8F57CF4D8330@MN2PR11MB3565.namprd11.prod.outlook.com> <20201110033438.GE39170@kduck.mit.edu> <CO1PR11MB48815ED81CFBBF1EC97A2DB2D8E90@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB48815ED81CFBBF1EC97A2DB2D8E90@CO1PR11MB4881.namprd11.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 10 Nov 2020 15:16:08 -0800
Message-ID: <CAM4esxSDPc74=eRqtAY2SffUe_eDVFD6yXVvejmOCH9-Z9eOzQ@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="000000000000bc909405b3c8dd41"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/xfkC1dXnZHaTcQ8gceni_saAHQ0>
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: Tue, 10 Nov 2020 23:16:23 -0000

OK,

We will eventually get there, but this will never stop being weird to me.
:-)

Imagine 5 types of DODAG nodes:

Type     8138? this draft? MOP5?  MOP 7?
-------      -------   ------------    --------   ----------
 A             N              N             N           N
B              Y              N             N           N
C              Y              Y             N           N
D              Y              Y             Y            N
E              Y              Y              Y           Y

So if IIUC, the current state of play is that B can't gracefully deploy
into a network with A, because they have to be statically configured to
not-compress.

As long as B is upgraded to this draft (C), it can gracefully deploy in a
network with A, because compression will remain off until all the A is
gone. C and B can function together without this draft, but they won't be
able to dynamically change compression state, FWIW.

Similarly, a hypothetical D can gracefully deploy with A, as it will have
use of these flags, but doesn't really need the flags to work with B or C
unless you want to dynamically change state for some reason.

Meanwhile, E will *not *be able to gracefully deploy with A, because it
does not have a means to change its compression state using the DODAG
configuration. But because of the sentence we've discussing in this thread,
networks with C and D will have no problem because they have this text to
help them decide whether or not to compress. They will not have the ability
to dynamically change compression state.

So I guess the value of the MOP 7 behavior is... to recover the bit of the
flags? Fine, I suppose, but this would appear to have two costs:
1) If A is still out there when E deploys, this bit would have been useful,
but isn't.
2) I have no idea if the "dynamic change in compression state" use case is
valuable it all, but it would certainly foreclose the possilbilty.

Do I have this right?

Martin


On Tue, Nov 10, 2020 at 12:15 AM Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Benjamin:
>
> > That said, and my apologies for a hazy memory coming back to this after a
> > couple months, in a year or N from now when mopex is finalized, how will
> > someone looking at mopex know to use RFC8138 on links where 6LoWPAN
> > Header Compression applies (and not use it otherwise)?  We are claiming
> in
> > the -14 of this document that:
> >
> >                               For a MOP value of 7, [RFC8138] MUST be
> >    used on Links where 6LoWPAN Header Compression [RFC6282] applies and
> >    MUST NOT be used otherwise.
> >
> > but I am not sure (or have forgotten) what the chain of references is
> supposed
> > to lead someone who is implementing RPL plus MOP=7 to the requirement to
> > use RFC 8138.  I don't think we should just rely on the mopex text to do
> so,
> > since we are trying to impose the requirement with this document (which
> > predates mopex by some time), and there's not anything (other than our
> > collective memories, of course) requiring mopex to remain consistent with
> > that requirement.
>
> Just to be clear for the other readers: MOPext does not exist as a
> normative reference for this work.
> The only field that exists is the MOP field in the DIO and that field is 3
> bits long, values 0..7.
>
> The normative reference that you are after is
> https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
> This is the spec that updates RPL and changes the IANA registry to
> indicate that 7 is not a MOP.
>
> There we have:
>
> "
>
> ...
>
>   Anticipating future work to revise RPL relating to how the LLN and
>    DODAG is configured, this document changes the interpretation of the
>    [dodagcfg] Registry to be limited to Mode-of-Operation (MOP)
>    specific.  The MOP is described in [RFC6550] section 6.3.1.  The
>    Options Flags Registry is renamed, and applies to MOP values zero (0)
>    to six (6) only, leaving the flags reserved for MOP value seven (7).
>
>    In addition, this document reserves MOP value 7 for future expansion.
>
> ...
>
> 11.3.  Change MOP value 7 to Reserved
>
>    This document changes the allocation status of the Mode of Operation
>    (MOP) [ianamop] from Unassigned to Reserved.  This change is in
>    support of future work related to capabilities.
> "
>
> So basically we tell the implementations from now on to test if MOP is 7,
> and in that case, the Options Flags are undefined. In other words, if MOP
> is 7, the stack must not use the option flags as if the MOP was <7. In
> fact, 7 is no more a MOP value but a reserved thingy that can be overloaded
> in the future. And yes, we intend to do just that in MOPExt.
>
> Until that happens, implementations are at a loss if they encounter when a
> MOP field that is all ones. So we need to give them instructions to cope
> with the situation. This draft derives whether to use RFC 8138 from whether
> the 6LoWPAN compression applies to the link or not.
>
> This will stay true forever, unless another RFC amends it. When/if that
> happens, the new RFC will have to consider backward compatibility with a
> legacy implementation that implements the above.
>
> Note that this line of thought applies to 3 flags, defined respectively in:
> - https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
> - https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/
> - https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
>
> Keep safe!
>
> Pascal
>
> >
> > Thanks,
> >
> > Ben
> >
> > On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert)
> wrote:
> > > Hello Alvaro
> > >
> > > I uploaded both draft with the suggested update, please see
> > >
> > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-17.
> > > txt
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-21.tx
> > > t
> > >
> > > Keep safe
> > >
> > > Pascal
> > >
> > > > -----Original Message-----
> > > > From: Alvaro Retana <aretana.ietf@gmail.com>
> > > > Sent: jeudi 24 septembre 2020 17:49
> > > > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> > > > Cc: Benjamin Kaduk <kaduk@mit.edu>du>; The IESG <iesg@ietf.org>rg>;
> > > > draft-ietf- roll-turnon-rfc8138@ietf.org; Martin Duke
> > > > <martin.h.duke@gmail.com>om>; Routing Over Low power and Lossy networks
> > > > <roll@ietf.org>rg>; roll- chairs@ietf.org; Michael Richardson
> > > > <mcr+ietf@sandelman.ca>
> > > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
> > > > draft-ietf-roll-turnon-rfc8138-
> > > > 14: (with DISCUSS and COMMENT)
> > > >
> > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote:
> > > >
> > > >
> > > > Pascal:
> > > >
> > > > Hi!
> > > >
> > > > > Following the meeting last Monday and subsequent the update of
> > > > > useofrplinfo by Michael (thanks Michael!) I published a new
> > > > > version of the turnon RFC
> > > > > 8138 draft.
> > > > >
> > > > > The major changes are
> > > > > - removed the formal update to RFC 6550
> > > > > - refer to useofrplinfo as the justification why the flag is not
> > > > > defined for MOP 7
> > > > > - defined the operation in MOP 7 as compression on iff the Link
> > > > > uses 6LoPWAN HC.
> > > >
> > > > Thanks for these changes.
> > > >
> > > > Because we have to cycle useofrplinfo back through (when the WG is
> > > > done with it), I asked Ben/Martin to wait for that before coming
> > > > back to this document.  It'll make it easier than tracking multiple
> > > > changes. :-)
> > > >
> > > >
> > > > OTOH, I do have comments on the recent change:
> > > >
> > > > OLD>
> > > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > > the
> > > >    definition of the Flags applies to Mode of Operation (MOP) values
> > > >    zero (0) to six (6) only, leaving the flags reserved for MOP
> > > > value
> > > >    seven (7).  For a MOP value of 7, the bit in position 2 is
> > > > considered
> > > >    unallocated and [RFC8138] MUST be used on Links where 6LoWPAN
> > > > Header
> > > >    Compression [RFC6282] applies and MUST NOT be used otherwise.
> > > >
> > > > NEW>
> > > >
> > > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > > the
> > > >    definition of the Flags applies to Mode of Operation (MOP) values
> > > > zero (0)
> > > >    to six (6) only.  For a MOP value of 7, [RFC8138] MUST be used on
> > > > Links
> > > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT
> > > > be used
> > > >    otherwise.
> > > >
> > > >
> > > > Thanks!
> > > >
> > > > Alvaro.
>