IETF Logo Mail Archive

Re: [6tisch] [6lo] [Roll] FW: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt

Robert Cragie <robert.cragie@gridmerge.com> Sun, 16 November 2014 01:42 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A621A00FE; Sat, 15 Nov 2014 17:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 clmo4GqY8GxE; Sat, 15 Nov 2014 17:42:26 -0800 (PST)
Received: from mailscan1.extendcp.co.uk (mailscan1.extendcp.co.uk [79.170.44.231]) (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 CC9721A02F1; Sat, 15 Nov 2014 17:42:25 -0800 (PST)
Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1XporA-0000OX-77; Sun, 16 Nov 2014 01:42:24 +0000
Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1Xpor9-0005Zv-Qr; Sun, 16 Nov 2014 01:42:24 +0000
Received: from host31-51-175-12.range31-51.btcentralplus.com ([31.51.175.12] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Xpor7-0005lk-Nz; Sun, 16 Nov 2014 01:42:22 +0000
Message-ID: <546800EC.9090607@gridmerge.com>
Date: Sun, 16 Nov 2014 01:42:04 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
References: <20141025070548.825.87046.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A1E80C@xmb-rcd-x01.cisco.com> <546623D2.4060207@gridmerge.com> <26D6758E-C9EA-4DB4-AD80-8B865A7E1962@tzi.org>
In-Reply-To: <26D6758E-C9EA-4DB4-AD80-8B865A7E1962@tzi.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms050400000500050202050806"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/JFi_N5qnSa0j0bC6yncw2WcMzFE
X-Mailman-Approved-At: Sat, 15 Nov 2014 22:33:00 -0800
Cc: Pascal Thubert <pthubert@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6tisch] [6lo] [Roll] FW: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Nov 2014 01:42:29 -0000

Hi Carsten,

Comments inline.

Robert

On 14/11/2014 4:05 PM, Carsten Bormann wrote:
> On 14 Nov 2014, at 05:46, Robert Cragie <robert.cragie@gridmerge.com> wrote:
>> Question - any reason the value 010001XY was chosen for the escape code?
> Note that the escape space is not taken just for RFC 6553 compression; it can be used for encoding other NHCs as well.
<RCC>Yes, I realise that one escape code can escape 2 bits of 
information from the succeeding NHC and that text for the NHC itself 
must describe how the preceding escape code(s) 2 bits are used. I think 
some extra explanatory text plus some guidance on choosing what data you 
might want to escape (i.e. that which is normally steady state and 
changes exceptionally) might help as it isn't immediately obvious.</RCC>
>
> The idea was to reserve some space around that so if we want to extend the escape space for some future NHC, we can do so while keeping it contiguous.
<RCC>OK, understood</RCC>
>
> Note also that RFC 6282 already has variable length processing for hop limit and address compression, so the impact of adding a third instance is going to be limited.  (I need to write that up some more in draft-*-lwig-6lo.)
<RCC>I don't see any issue where the IPv6 packet is reassembled every 
hop. I was wondering if there might be an issue in the case of fragment 
forwarding although with RPL (i.e. route over), I am not sure if 
fragment forwarding is actually possible anyway, so it may not be an 
issue</RCC>
>
> Since just about every data packet in a RPL network will carry an RPI, saving a single byte is worth quite some effort.
<RCC>I don't disagree and if the consensus is that it is worth the extra 
processing then I have no objection. I realise "bits in the ether" in 
constrained networks are costly compared to the still fairly trivial 
extra processing for the escape.</RCC>
>
> Grüße, Carsten
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>

v2.29.0 | Report a Bug | By Email | System Status