Re: [6lo] Shipping RPL Unaware Leaves

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Wed, 11 March 2020 14:13 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C9B3A00D9; Wed, 11 Mar 2020 07:13:03 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dmQVhT7OYAYS; Wed, 11 Mar 2020 07:13:02 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 314753A00C1; Wed, 11 Mar 2020 07:13:01 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 02BEChh2012878; Wed, 11 Mar 2020 15:12:44 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 347201D53C1; Wed, 11 Mar 2020 15:12:42 +0100 (CET)
Received: from 10.192.137.220 by webmail.entel.upc.edu with HTTP; Wed, 11 Mar 2020 15:12:43 +0100
Message-ID: <00f3fd6077945717fd2cae2618ba3b3e.squirrel@webmail.entel.upc.edu>
In-Reply-To: =?utf-8?q?=3CMN2PR11MB35651792CF4ABA5A79E36430D8FC0=40MN2PR11MB?= =?utf-8?q?3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: =?utf-8?q?=3CMN2PR11MB35651792CF4ABA5A79E36430D8FC0=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Wed, 11 Mar 2020 15:12:43 +0100
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: "Pascal Thubert \(pthubert\)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: "6lo@ietf.org" <6lo@ietf.org>, "Routing Over Low power and Lossy networks" <roll@ietf.org>, "Rahul Jadhav" <nyrahul@outlook.com>, "suresh@kaloom.com" <suresh@kaloom.com>, "Alvaro Retana" <aretana.ietf@gmail.com>, iot-directorate@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 11 Mar 2020 15:12:44 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/wtleOsL6FJupW34Yn6EB91wg2YY>
Subject: Re: [6lo] Shipping RPL Unaware Leaves
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2020 14:13:04 -0000

Dear all,

The proposed update is fine with us (Shwetha and Carles), considering the
53 ARO status values that would still be available. There appear to be no
backwards issues either.

Would anyone in the 6Lo WG (or anyone receiving this email) have any
concerns with the proposal below by Pascal and folks?

If yes, please do chime in!

Thanks,

Shwetha and Carles




> Dear all :
>
> As you may know, draft-ietf-roll-unaware-leaves is blocking the whole
> cluster C130 https://www.rfc-editor.org/cluster_info.php?cid=C310 and we
> want to ship it now (WG milestone: Mar 2020 - Initial submission). The
> issue we have with it is the fact that we allow encapsulate the ARO status
> in a RPL status and we need bits to signal that.
>
> To free the necessary bits the proposal on the table is to reduce the
> possible values for the ARO status to 0-63.
> This can be done by a simple IANA action that can be taken from
> draft-ietf-roll-unaware-leaves but we wanted to ensure that both ROLL and
> 6lo agree with the proposal:
>
>
> 12.1.  Resizing the ARO Status values
>
>    IANA is requested to modify the Address Registration Option Status
>    Values Registry as follows: The unassigned values range is reduced
>    from 11-255 to 11-63.
>
>
> NB: this will free 2 bits in the Extended Address Registration Option and
> the Extended Duplicate Address Message, could become handy in the future.
>
> Is there an issue with this that we are missing?
>
> Pascal
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>