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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 17 December 2014 08:30 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BC1A1B57; Wed, 17 Dec 2014 00:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GcCSV7HxoJJY; Wed, 17 Dec 2014 00:29:58 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3491A016F; Wed, 17 Dec 2014 00:29:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8115; q=dns/txt; s=iport; t=1418804998; x=1420014598; h=from:to:cc:subject:date:message-id:mime-version; bh=B576+RyKd6xviScfywULFDBIWA7Q7BJWVUncXdODths=; b=k12+/2jWz0jRFvBnRpaemSV3b2Q0+NxRDqe4ZT0tqalMm0DOsmY0x4+i we55A0VeG1pBOQpio1NHvB1AYUTyYGHBs6uSLMRY1NbBPAMOG3/7hE42l 14cyhuZNZbfIKjyRAmg86Aktkwc4YGCfIgqoiHRqecYBo/kk1mCubh9N6 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208,217";a="111243869"
Received: from rcdn-core-5.cisco.com ([]) by mtv-iport-3.cisco.com with ESMTP; 17 Dec 2014 08:29:57 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com []) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBH8TuGi024174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 08:29:56 GMT
Received: from xmb-rcd-x01.cisco.com ([]) by xhc-aln-x01.cisco.com ([]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 02:29:56 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "6tisch@ietf.org" <6tisch@ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>
Thread-Topic: call for consensus for the RPL RPI / RH3 compression
Thread-Index: AdAZ03ma+k+kJWwbTKWgpTyyptAZgQ==
Date: Wed, 17 Dec 2014 08:29:53 +0000
Deferred-Delivery: Wed, 17 Dec 2014 08:29:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848AC2314xmbrcdx01ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-GJ1VlfKkrILtHerEuzOhixXgnc
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [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: Wed, 17 Dec 2014 08:30:01 -0000

Dear WG :

We are now in last call for draft-ietf-6tisch-minimal-04 which describes an interoperable operation of RPL over 802.15.4e TSCH.
In order to guarantee interop, the draft must indicate which compression technique to use for the RPL option, and, if any, the RH3 as well.

The question was apparently solved at the ROLL meeting in Toronto, and we were going to use the IPv6 flow label to carry the RPI, with no compression for the RH3.
Adrian noted that since this is a deviation to RFC 6437, we should go to 6MAN to validate. We went to 6MAN in April (https://tools.ietf.org/html/draft-thubert-6man-flow-label-for-rpl) and got support from Brian Carpenter. The ask in 4 points was discussed again in Hawaii. But still no final decision to date that we could reset/reuse the flow label in LLNs.

Considering the lack of progress at 6MAN earlier in the year, we studied an alternate compression technique for the RPI at 6lo (https://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc). 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 and we proposed a new 6lowpan routing header that would reuse for Route-over the 1/3 of the total dispatch space that is used for Mesh header in Mesh-under (https://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch). There were interesting discussions and an update but there we are, no WG document anywhere that we can reference, and no consensus that 6lo will adopt that work.

Yet we need to choose one compression for the minimal version that we will submit to IESG. At some point we hoped that the NHC would cut it but as I said, the meeting in Hawaii left us with little hope that this would happen. So what should we do now? I think we need to call to 6lo and 6MAN for a decision on the topics we have been asking. And since a decision may not come in time, we also need to define our default.

My personal take is lex parsimoniae. By default, we should fall back to the simplest to implement, which is also the least change in existing implementations, and that is the original flow label approach; and I'm calling the group for consensus on that default approach.

What do you think?