IETF Logo Mail Archive

Re: [Roll] call for consensus for the RPL RPI / RH3 compression

Carsten Bormann <cabo@tzi.org> Fri, 19 December 2014 08:17 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550C51A1F70; Fri, 19 Dec 2014 00:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.15
X-Spam-Level:
X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] autolearn=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 S-XKuoXnST4l; Fri, 19 Dec 2014 00:17:36 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CC01A6F20; Fri, 19 Dec 2014 00:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sBJ8HW8j016764; Fri, 19 Dec 2014 09:17:32 +0100 (CET)
Received: from [IPv6:2002:5489:adc::6808:fbcd:141:fd50] (unknown [IPv6:2002:5489:adc:0:6808:fbcd:141:fd50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3k3jcC33Dkz7wgK; Fri, 19 Dec 2014 09:17:31 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com>
Date: Fri, 19 Dec 2014 09:17:29 +0100
X-Mao-Original-Outgoing-Id: 440669849.57781-3faa6d6f23ae1f2b2a2a1a43a0411230
Content-Transfer-Encoding: quoted-printable
Message-Id: <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/4s858NUnhmEa-2J6iZV4ffCL8t8
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>
Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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: <http://www.ietf.org/mail-archive/web/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: Fri, 19 Dec 2014 08:17:37 -0000

On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Decision in Hawaii was that the NHC draft could not be accepted as is, since we should compress also the RH3, and without a clear view of how that would happen, the details of the NHC compression could not be determined. So the NHC approach was abandoned

That is not at all what I recollect from Hawaii.

The current smorgasbord is:

— various ways to hijack the flow label (dead)
— the 6553-NHC proposal
— ideas for a new mesh header

I’m not going to beat the dead horse of the flow label hijack.

The 6553-NHC proposal mainly needs a decision between the three variants (flip a coin, if need be).
If time is of the essence, 6553-NHC is the natural thing to do.
We can always do an RFC 6554 NHC compression separately.

The MH proposal is forward-looking and probably the right thing for the evolution of 6lo, but probably also not compatible with a tight time schedule.

Now, what is the rush?
RFC 6553/6554 do exist.

So we get to choose between rushing 6553-NHC to completion or using 6553/6554 for now and doing the MH work right (or. more likely than just the first, both).
I don’t have an opinion on wether we need to rush 6553-NHC, but if we need to rush anything, this one it is.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email