Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 07 January 2015 14:59 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 8CE341A90D7; Wed, 7 Jan 2015 06:59:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iCXAIthAPyqv; Wed, 7 Jan 2015 06:59:03 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25711A6F2B; Wed, 7 Jan 2015 06:59:02 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E62C920098; Wed, 7 Jan 2015 10:04:23 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 2B6DB637FE; Wed, 7 Jan 2015 09:59:01 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 14E9963745; Wed, 7 Jan 2015 09:59:01 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD848B102F2@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com>, <CE9445B8-BA8E-4112-B892-6BCDED74D8DC@gmail.com> <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com> <11092.1420586011@sandelman.ca> <E045AECD98228444A58C61C200AE1BD848B102F2@xmb-rcd-x01.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
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: Wed, 07 Jan 2015 09:59:01 -0500
Message-ID: <14523.1420642741@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/uIQnBUpF4aHvcAFq_tZNhk4VFj0
Subject: Re: [Roll] [6tisch] [6lo] 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, 07 Jan 2015 14:59:06 -0000

Thank you Tom for point at RFC2663 for "address domain". 

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > 6LoWPAN HC and the new draft proposals (NHC, dispatch, all apart from
    > the flow label) are encoding procedures that can be reversed so as to
    > restore the original packet. 
    > The term sub IP, should it refer to an encapsulation like a vlan, would
    > be inappropriate. If it refers to an adaptation layer below IP, it
    > would apply.  

So, again, I think a key reason why the various HC are not a sub-IP protocol
is because rfc6553 does not create new addressing domains with the RPL
InstanceID.

Can we agree that this is not a sub-IP signalization problem.

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