Re: [Roll] MOP 7 Reserved/Specification (draft-ietf-roll-useofrplinfo / draft-ietf-roll-unaware-leaves / draft-ietf-roll-turnon-rfc8138)

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 13 December 2020 21:24 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1D83B3A0A50 for <roll@ietfa.amsl.com>; Sun, 13 Dec 2020 13:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 EgluDaztyPNC for <roll@ietfa.amsl.com>; Sun, 13 Dec 2020 13:24:53 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67683A0A4F for <roll@ietf.org>; Sun, 13 Dec 2020 13:24:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C3C693898C; Sun, 13 Dec 2020 16:27:22 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r8etPHr6LPvX; Sun, 13 Dec 2020 16:27:21 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 69BE23898B; Sun, 13 Dec 2020 16:27:21 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6507B5D1; Sun, 13 Dec 2020 16:24:50 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org, Alvaro Retana <aretana.ietf@gmail.com>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>
In-Reply-To: <CAMMESsy5+pWAcoNwN7qxH6M_wcgYZp8uOYLDzgNmc2Qw4orSHQ@mail.gmail.com>
References: <CAMMESsxO4uA88U0--e3HNdmcMuLXWvTdTPtKC+mAH05+4pLYVQ@mail.gmail.com> <11059.1607633510@localhost> <SJ0PR11MB4896A52BA83DEEBFAC592A54D8CA0@SJ0PR11MB4896.namprd11.prod.outlook.com> <CAMMESsy5+pWAcoNwN7qxH6M_wcgYZp8uOYLDzgNmc2Qw4orSHQ@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sun, 13 Dec 2020 16:24:50 -0500
Message-ID: <21974.1607894690@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/BgwEvCsR21c8eoFfH5_Mn04DdOg>
Subject: Re: [Roll] MOP 7 Reserved/Specification (draft-ietf-roll-useofrplinfo / draft-ietf-roll-unaware-leaves / draft-ietf-roll-turnon-rfc8138)
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: Sun, 13 Dec 2020 21:24:56 -0000

I'm removing the tripe-document CC:
    <draft-ietf-roll-unaware-leaves@ietf.org>rg>,
    "roll-chairs@ietf.org" <roll-chairs@ietf.org>rg>,
    <draft-ietf-roll-turnon-rfc8138@ietf.org>rg>,
    <draft-ietf-roll-useofrplinfo@ietf.org>

and just putting the WG back in the discussion.

Alvaro Retana <aretana.ietf@gmail.com> wrote:
    > Yes, I know, the IESG is a pain.  As Pascal said, the reasoning can be
    > counterintuitive -- it took me a while to get it, and now I agree that
    > it is not complex.  Martin also got it.

    > Individual explanations don't scale and don't prevent others from
    > asking the same question.  Pre-emptive notes matter only if considered
    > in context and if they are top of mind.  A permanent record is what I
    > think is better.

What I'm hearing here is that we need to move MOP=7 Reserved into a document
of it's own.

   _Considerations for evolution of RPL_
   updating RFC6550.

   {like RFC7346, which took a mere 12 months to publish after all the
   details were discussed over dinner at a Vancouver IETF meeting.
   Forgive my cynicism.}

    > I'm ok if you want to leave the text as is — no need to talk about this
    > anymore.  With any luck, there will be no issues and we can approve the
    > documents before the holidays.

Uhm, okay.

    > If you decide to change something, I have a suggestion for
    > §4.1.2/UseofRPLInfo:

    >    Nodes that support this specification may need to operate in
    > networks where MOP 7 is used.  As explained in rfc6550, if the MOP is
    > not supported, it must only join the network as a leaf.  To facilitate
    > the integration into LLNs using MOP 7, a document that defines
    > functionality using DODAG Configuration Option Flags MAY specify
    > required behaviors (see §4.1.3).

That doesn't really say anything to me.

I would write somewhere. Where I don't know.

----

RFC6550 does not provide a way for a DODAG root node to know what
capabilities are ubiqutiously available on an RPL LLN.
This lack includes both control plane (RPL) and data plane (RFC8505, RFC8138,
RFC8931, etc.) capabilities.
[capex] is an upcoming effort to deal with in a systematic way.

Until such time as [capex] can be finished, major control plane options are
expected to be defined in an backwards compatible way, or to be make
judicious use of the remaining available MOP values (4, 5 and 6 being still
free).   A major change in control plane behaviour for which a node
does not understand causes the node to join in leaf mode only
(RFC6550, section 9.2)

The above logic takes care of the control plane, but leaves the data plane
options in the dark.  For a node to join in leaf mode it still needs to be
able to communicate in the data plane.
For this reason, [useofrplinfo], [turnon-rfc8138], [unaware-leaves] define
*ad-hoc* mechanisms to enable data-plane options.  This permits Flag Day-free
incremental deployment of new firmware as explained in [useofrplinfo] section 4.1.3.

Because the mechanism are adhoc, and use a very limited resource of flags in
the DIO header,  there is a desire not to maintain them longer than
necessary.   Negotiating data-plane options in the DIO header as at best, a
hack.  Attaching them to the MOP value is also a bit of a hack, but RFC6550
did not give us any other way to do revise the protocol in an incremental manner.

The WG also wishes to establish that many of these innovations will become
mandatory going forward, and so has established that by the time the
WG allocates MOP==7, that these data plane options will no longer be optional.
It is likely that MOP==7 will be allocated by [mopex] to extend the MOP
values, and will include a capability negotiation mechanism at both the data
plane and control plane.

However, while we can not entirely predict the future, for the data plane
options, we know which ones we want permanently on in the future, and so we
are declaring them so in each document, based upon the MOP value.
Based upon advice from IANA, the WG has marked MOP==7 as Reserved, because
the WG has specific plans for it.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide