IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Thu, 14 August 2014 09:05 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 563751A09AC; Thu, 14 Aug 2014 02:05:28 -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 T-brZBoibDia; Thu, 14 Aug 2014 02:05:26 -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 787EA1A09A2; Thu, 14 Aug 2014 02:05:26 -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 s7E95FZ0015502; Thu, 14 Aug 2014 11:05:15 +0200 (CEST)
Received: from [192.168.217.145] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1A41D858; Thu, 14 Aug 2014 11:05:13 +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: <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com>
Date: Thu, 14 Aug 2014 11:05:12 +0200
X-Mao-Original-Outgoing-Id: 429699912.398908-3583409ce4c12fd784d40291f31fbb34
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE11CC16-DEBD-426D-BF52-CEFF927B127A@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> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/AYm0wlBUJHQkmzgtLPP9BLoCKIE
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
Subject: Re: [Roll] [6lo] 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: Thu, 14 Aug 2014 09:05:28 -0000

On 14 Aug 2014, at 10:54, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

> If the 6lo work concludes as an RFC, it should recommend to prefer the 6lo way against the flow label way.

It is a bit more complicated.

If both representations of the RFC 6553 information are in use:
A compressor may need to decide whether a flow label present in an uncompressed packet is an RFC 3697 flow label or one of these.
A decompressor may need to decide whether the information is to be represented in canonical RFC 6553 form or making use of the flow label hack.

In any case, I’m not a big fan of providing two different ways of doing the same thing, at different layers.
In particular not in the constrained environment.

I really would like to hear a technical argument why the flow label hack is needed.
(Or a political one, if that is the reason.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email