Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
Martin Duke <martin.h.duke@gmail.com> Wed, 11 November 2020 16:27 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 AC1B93A0E96; Wed, 11 Nov 2020 08:27:01 -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 xxLYXDCe0whA; Wed, 11 Nov 2020 08:26:59 -0800 (PST)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 C4A663A0DFB; Wed, 11 Nov 2020 08:26:58 -0800 (PST)
Received: by mail-il1-x134.google.com with SMTP id x20so2482473ilj.8; Wed, 11 Nov 2020 08:26:58 -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=OrOGTnIy849IfvLbJ+z6SnN3yfIPAhJB1K2AwHyykU4=; b=KyosjpO62oNmoQDTU4ZAlPfnSoRQDzcjk0u1RqNpDB2ZxbY1ObpEYTEA6YOp8g7eU9 nU4sXQRAP8CfieHTP2gOAaBsfbFl7h2M6OGpoh3FSni8/o9WTxcXxUAQD8G+xtD37Myq lBUOf6qCNAkE5bPzueFNz5lGh0QCz7YtPGpFjG2AyKv5yEyY4o58RNfMGUb30p2kL8lu 4qXh14St/rsJZnt0Tv51tTzu6hcwMVLzgTZZ1SuAdynoy2Yr4SOuIOmQnzEQriBWSjPf n6fvMmO1blN1GCzUhM8KB1fS7T1w888NKC8hFlKXin+dOv9c9JMEqftx94K6zqkSSkKj QvMA==
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=OrOGTnIy849IfvLbJ+z6SnN3yfIPAhJB1K2AwHyykU4=; b=OdLjGufxv9dMCHIZDeDpSUuxq/InTMzgouyui5RkFd8WzbPWrOjjKLuAZtp7DDMBQ0 UuiTFOm6ynCRaH3iMRdJcv6lz6LCEMbrX5Lm/sHfN4qBAmQzrrEsdmkz42nWfu8ILSOY MdGUX3LjMuo4p83Oq7zOw4r06cmXNfTb2IXhZip2PZUt6wmaSzWx7QVG2dGFbawbJ/kJ ytCi5/XxpVUO2IxNMxRhQO2eDcNTCIaIAYoJffVW8UsaVDRzksyVVmRNLXh234AX157s d5LJWa5VzkwOQatr/ZIyCQ9/0hjLPsuTqpp6EEKzX6Q61uHsZG1WYQgVkrR3Js+pE26O M/hw==
X-Gm-Message-State: AOAM532igwJOR0+kvM6fQsxGPage+qVKVvrVs5giDokE5m4mWtRtCUfX ytLNOtGqEkyC6nW/9JyACpmpSvNyrLFYQHayO9A=
X-Google-Smtp-Source: ABdhPJzZSFt2G21Adn4aVnY/RqYVffMaXQMhVIRI9fUkXPGWEMN/HS1AaO6VOsMBwXENOHKCuo6rXvMfOiucnLTd4Pg=
X-Received: by 2002:a05:6e02:1388:: with SMTP id d8mr19259967ilo.272.1605112017931; Wed, 11 Nov 2020 08:26:57 -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> <CAM4esxSDPc74=eRqtAY2SffUe_eDVFD6yXVvejmOCH9-Z9eOzQ@mail.gmail.com> <CO1PR11MB4881D4F6EC013CE1338A0C04D8E80@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB4881D4F6EC013CE1338A0C04D8E80@CO1PR11MB4881.namprd11.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 11 Nov 2020 08:26:48 -0800
Message-ID: <CAM4esxRY1A7A_yw7+mphyAecXQjA8x99aqPp5tKVg+QNoBn=8w@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="000000000000a7535205b3d743d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/VHizvN9ocdrSoPVQZGScwty0sao>
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: Wed, 11 Nov 2020 16:27:02 -0000
Ah, OK, I see now that MOP7 in itself substitutes for the flag. I'm satisfied. On Wed, Nov 11, 2020 at 1:59 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Martin > > First of all you are correct that the whole game is to recover the bits > for RPLv2, with the idea that the features that they signaled will be > installed and that signaling the transition will be a waste. Also RPL has > very few of these flags available in the configuration option and the group > insisted on getting them back after the transition. > > Second is to thank you for your care / the depth of your attention on that > issue. It is indeed “touchy”. And it spans 3 drafts that are going through > IESG in the same window of time. > > Let’s see below > > > We will eventually get there, but this will never stop being weird to > me. :-) > > > Imagine 5 types of DODAG nodes: > > I read they support the below as opposed to the DODAG is deployed with the > below. > > 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. > > Or you need some management outside of RPL which is against the core > design point that RPL should be autonomic/self-configuring > > > 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 > > Yes, that is the transition phase > > > 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. > > Unclear what you mean. If the DODAG is deployed with a MOP < 5 D is a C. > If the MOP is 5, nodes A, B, and C will have to be leaves, and the flag > will still be off as long as there's an A in the network, else that A will > be isolated. > > > 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. > > Same as above, if the MOP is <7, the flag still works, even if E is > capable of some new MOPExt MOPs. If we use a MOPext (signaled by MOP=7), > and if there are nodes of type A in the network, tose nodes of type A will > be leaves and they'll be isolated, unless they turn into > RPL-unaware-leaves, from which compression is not expected. > > > 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: > Yes > > > 1) If A is still out there when E deploys, this bit would have been > useful, but isn't. > It's not when E deploys, it is when the DODAG is deployed or upgraded with > a MOP 7. > > > 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. > We defined this flag to enable the activation of the compression in a > brown field. Right now we have millions of nodes deployed, all of type A. > typically utility AMI meters. Having to impose a flag day to migrate to the > compression is not acceptable to our users. So we do not even propose it. > and the situation is stuck. If we have a migration scenario without a flag > day, we can ship the compression in software refreshes, and let the > customer decide if and when to turn on. > > > Do I have this right? > > You do 😊 > > Pascal > > > On Tue, Nov 10, 2020 at 12:15 AM Pascal Thubert (pthubert) <mailto: > 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 <mailto:aretana.ietf@gmail.com> > > > > Sent: jeudi 24 septembre 2020 17:49 > > > > To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com> > > > > Cc: Benjamin Kaduk <mailto:kaduk@mit.edu>; The IESG <mailto: > iesg@ietf.org>; > > > > draft-ietf- mailto:roll-turnon-rfc8138@ietf.org; Martin Duke > > > > <mailto:martin.h.duke@gmail.com>; Routing Over Low power and Lossy > networks > > > > <mailto:roll@ietf.org>; roll- mailto:chairs@ietf.org; Michael > Richardson > > > > <mailto:mcr%2Bietf@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. >
- [Roll] Benjamin Kaduk's Discuss on draft-ietf-rol… Benjamin Kaduk via Datatracker
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Alvaro Retana
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Alvaro Retana
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Alvaro Retana
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Alvaro Retana
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- [Roll] Agenda for Monday (Re: MOP==7 live discuss… Michael Richardson
- Re: [Roll] Agenda for Monday (Re: MOP==7 live dis… Pascal Thubert (pthubert)
- Re: [Roll] Agenda for Monday (Re: MOP==7 live dis… Alvaro Retana
- Re: [Roll] Agenda for Monday (Re: MOP==7 live dis… Ines Robles
- Re: [Roll] Agenda for Monday (Re: MOP==7 live dis… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Alvaro Retana
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Pascal Thubert (pthubert)
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke