IETF Logo Mail Archive

Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Carsten Bormann <cabo@tzi.org> Tue, 12 August 2014 08:40 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 830921A079F; Tue, 12 Aug 2014 01:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] 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 uBnI5sB4P3yw; Tue, 12 Aug 2014 01:40:53 -0700 (PDT)
Received: from 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 7F2101A0376; Tue, 12 Aug 2014 01:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7C8eM80025798; Tue, 12 Aug 2014 10:40:22 +0200 (CEST)
Received: from [192.168.217.145] (p54890742.dip0.t-ipconnect.de [84.137.7.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 67334B76; Tue, 12 Aug 2014 10:40:21 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com>
Date: Tue, 12 Aug 2014 10:40:19 +0200
X-Mao-Original-Outgoing-Id: 429525619.778124-1efd2775c48ffb70aab8faa6350b1af9
Content-Transfer-Encoding: quoted-printable
Message-Id: <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/JFIhH_97mBv4lSPxBM7vAnXbqWU
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
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: Tue, 12 Aug 2014 08:40:55 -0000

On 12 Aug 2014, at 09:15, Ines Robles <mariainesrobles@googlemail.com> wrote:

> This technique saves bytes

Again, the straw man at http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00
saves the same number of bytes.  Actually, for common cases, it enables one additional optimization (saving one more byte) that is not available with the flow label hack.  (On the other hand, due to the way RFC 6282 works, the flow label hack saves one byte where both it and ECN are in use and the common case does not apply.)

The disadvantage of the RPL mesh header is that this approach is not available outside 6lo networks (i.e., networks employing adaptation layers that use RFC 6282).  I’m not aware yet of a use case where that is a problem.

In either encoding (RPL mesh header or flow label), it is probably a good idea anyway to unpack the compressed information back into the RPL IPv6 option when leaving the 6lo networks.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email