IETF Logo Mail Archive

Re: [Roll] Alvaro's review on turnon Rfc 8138 07

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 06 July 2020 17:23 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 D8B9A3A17C2 for <roll@ietfa.amsl.com>; Mon, 6 Jul 2020 10:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t0hFherpSwP2 for <roll@ietfa.amsl.com>; Mon, 6 Jul 2020 10:23:03 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530D93A17C1 for <roll@ietf.org>; Mon, 6 Jul 2020 10:23:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5A585389A6; Mon, 6 Jul 2020 13:20:09 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MqqS96fyrigA; Mon, 6 Jul 2020 13:20:08 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E8C5389A5; Mon, 6 Jul 2020 13:20:08 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7EBB354C; Mon, 6 Jul 2020 13:23:00 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "'roll-ads@tools.ietf.org'" <roll-ads@tools.ietf.org>
In-Reply-To: <MN2PR11MB35657CEB09EA8FB7F1BF8391D8690@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB35657CEB09EA8FB7F1BF8391D8690@MN2PR11MB3565.namprd11.prod.outlook.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: Mon, 06 Jul 2020 13:23:00 -0400
Message-ID: <23854.1594056180@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/FT4NnaQkwI9rUbX1dhWrhIRx7ls>
Subject: Re: [Roll] Alvaro's review on turnon Rfc 8138 07
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: Mon, 06 Jul 2020 17:23:06 -0000

Pascal Thubert \(pthubert\) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
    > This takes us to 2) The above is why in the current text the leaf that
    > does not support the compression SHOULD act as a RUL, so it is an
    > external target and thus the default for it is to decompress before
    > forwarding. Alvaro and I are talking about MUSTing that, with the
    > argument that a RUL supporting the RPL compression looks like an
    > oxymoron.

The problem is that this is a new rule (new code), and the point was to
allow rfc8138 to be turned on without new code, right?

When we did RFC8138, it was stated that it would get deployed in greenfields
only, and that we didn't need signaling.
That's not the case, so we have jumped on this work to do "something".

This document is not supposed to accomodate old nodes: compression is either
supported on every node, or not yet supported on every node.

To determine that dynamically, we need capabilities.
What we have in this document is an operator controlled bit, not dynamic at
all.

I'm not sure when it mutated it's purpose :-)

I believe that the document has tried to do too many things.
Maybe just cut out everything that is not about that bit.
For instance, section 5, paragraph 3:

   If the
   compression is turned on, the node cannot forward compressed packets
   and therefore it cannot act as a router.

should just say, "the node/network fails"

>   To ensure that a packet is forwarded across the RPL Instance in the
>   form in which it was generated, it is required that all the routers
>   support [RFC8138] at the time of the switch, and that all nodes that
>   do not support [RFC8138] only operate as leaves.

I believe it is a misconfiguration (operator error) to turn on rfc8138 if
there are nodes that do not support it.  Just don't deal with that.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email