IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 14 August 2014 14:17 UTC

Return-Path: <mcr@sandelman.ca>
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 2B1FF1A0BEC; Thu, 14 Aug 2014 07:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level:
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 dil1YK_kDMY4; Thu, 14 Aug 2014 07:16:54 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9963F1A0B7E; Thu, 14 Aug 2014 07:16:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A815C20012; Thu, 14 Aug 2014 10:19:49 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 0A9A863AC9; Thu, 14 Aug 2014 10:16:52 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EB08E638D6; Thu, 14 Aug 2014 10:16:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <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> <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 14 Aug 2014 10:16:52 -0400
Message-ID: <17279.1408025812@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/wfgi4EWrd5mywwRssbW6KdE-ilQ
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>, Ole Troan <otroan@employees.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: Thu, 14 Aug 2014 14:17:00 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    > 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.)

I read it, but I didn't understand it.
Is this something that fits into the 6lowpan adaptation header?

    > 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.

A good point, I think.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email