Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt

Robert Cragie <robert.cragie@gridmerge.com> Tue, 02 December 2014 20:16 UTC

Return-Path: <robert.cragie@gridmerge.com>
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 B6B851A7023; Tue, 2 Dec 2014 12:16:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.345
X-Spam-Level:
X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LITTLE=1.555, RCVD_IN_DNSWL_NONE=-0.0001] 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 7ibxBVv57r0F; Tue, 2 Dec 2014 12:16:01 -0800 (PST)
Received: from mailscan1.extendcp.co.uk (mailscan11.extendcp.co.uk [79.170.45.20]) (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 E95A71A6FCA; Tue, 2 Dec 2014 12:16:00 -0800 (PST)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1Xvtrb-0005n8-6I; Tue, 02 Dec 2014 20:15:59 +0000
Received: from mailscanlb0.hi.local ([10.0.44.160] 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 1XvtrY-0003oV-Mg; Tue, 02 Dec 2014 20:15:59 +0000
Received: from host86-167-76-190.range86-167.btcentralplus.com ([86.167.76.190] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XvtrX-00056G-Sx; Tue, 02 Dec 2014 20:15:56 +0000
Message-ID: <547E1E07.8020800@gridmerge.com>
Date: Tue, 02 Dec 2014 20:16:07 +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: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A7DE36@xmb-rcd-x01.cisco.com> <547CB095.8050709@gridmerge.com> <E045AECD98228444A58C61C200AE1BD848A85E23@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD848A85E23@xmb-rcd-x01.cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms070306080205090906060509"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/x-zcmmGTlYWKRDSO2T9zt4FomRo
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com, 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, 02 Dec 2014 20:16:05 -0000

Hi Pascal,

Comments inline.

Robert


On 02/12/2014 3:31 PM, Pascal Thubert (pthubert) wrote:
> Hello Robert:
>
> I agree with you. This  is exactly the dilemma. But I do not read your own advice in there?
<RCC>The point I was trying to make is that whilst there may be a case 
for changing something in an incompatible way due to "limited 
deployment", it is a) hard to draw the line at what "limited" means and 
b) it's sets a precedent for a specification to change further in the 
future. Whilst I accept that progress is inevitable, it is 
counterproductive if it happens too quickly. So what I was asking in 
essence was which side of the "limited deployment" line do people see 
the use of the mesh header? I confess I am sitting on the fence at the 
moment.</RCC>
>
> For your questions on the draft:
>
>> Also a comment re. section 8, I think the 'I' field needs to be 1, as
>> 'Size' represents the HopsLft field, not the size of the header.
> I think you got it reversed. ' I' set is the can-ignore case where the size in a length in bytes to be skipped if not understood.
>
> The text says:
> "If the I Flag is set, the Size / Format field contains the Length of the 6LoRH expressed in bytes."
>
> Which  means
> (I ==0 ) => "Size field contains length in bytes"
>
> So
> "the Size field does not contain the Length in bytes" => (I=0)
<RCC>Yes, I did get it wrong. I do think the description of the 'I' bit 
could be clearer. For example, why not describe the two cases like this:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ..........    +-+
       |1|0|0|   TSE   |    Type       |                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ..........    +-+
                                        <-- Implied length -->


where 'TSE' means 'Type specific extension', which is described in each 
case of type and the length is either implied or explicitly stated after 
the type field. The other case is:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ....    +-+
       |1|0|1| Length  |    Type       |                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ....    +-+
                                        <--  Length  -->


which is the length case, which can be skipped by implementations that 
do not understand the type. 'Size' and 'length' are terms that are too 
similar in my opinion.
</RCC>

>
>
>> It also doesn't seem to cover the Deep Hops Left concept in RFC4944.
> The ' Deep Hops Left ' comes from a structural limitation of the mesh header in RFC 4944, which encodes a hops left. No such thing here.
> The idea is that you place as many consecutive RH3-6LoRH as you need.
<RCC>We are talking about MH-6LoRH not RH3-6LoRH, aren't we? Hops left 
can also be more than 6 bits? Perhaps an illustration would help.</RCC>
>   This is how we do not max out the number of hops, and also how we handle the various sizes of compressed addresses. But agreeably, we need to provide more details on address compression and how the header is stripped hop by hop.
> Which we will do as a group if we take the 6LoRH path, but would be a waste of time if the group rejects this approach overall.
>
> Thanks for your comments : )
>
> Pascal
>
>
>> -----Original Message-----
>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
>> Sent: lundi 1 décembre 2014 19:17
>> To: Pascal Thubert (pthubert); 6lo@ietf.org
>> Cc: Routing Over Low power and Lossy networks; 6tisch@ietf.org
>> Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-routing-
>> dispatch-00.txt
>>
>> Hi Pascal,
>>
>> I agree that with hindsight it could be considered a bit greedy of
>> RFC4944 to allocate 1/3 of the dispatch code space to the mesh header
>> (especially when the definition of it itself is questionable) but what
>> you are advocating is a replacement, not a framework extension. RFC6282
>> only deprecated an ESC code, i.e. something which had not yet been used,
>> which is not quite the same. This effectively makes this at best a new
>> version of 6lowpan (which is difficult to distinguish) or at worst
>> arguably a whole new protocol.
>>
>> Whilst hindsight is a wonderful thing, it can lead to the situation
>> where a standard never stands still and keeps evolving. This makes it
>> very difficult to develop products as there is always the fear that
>> something will change the next year. Upgrading products is often quite a
>> difficult process, especially in the case where there could quite
>> feasibly be thousands of deployed devices which may have limited upgrade
>> capability.
>>
>> I would like to hear what other people think about this.
>>
>> Also a comment re. section 8, I think the 'I' field needs to be 1, as
>> 'Size' represents the HopsLft field, not the size of the header. It also
>> doesn't seem to cover the Deep Hops Left concept in RFC4944.
>>
>> Robert
>>
>> On 27/11/2014 2:03 PM, Pascal Thubert (pthubert) wrote:
>>> Dear all:
>>>
>>> This is a response to the question about the compression of RFC 6553 on top
>> of RFC 6554.
>>> It seems exaggerated to consume a dispatch type for the RPL option only.
>>> But here, we introduce a routing header which is the equivalent of the mesh
>> header in RFC 4944; we propose a compressed TLV format that can encode RH3,
>> RPL option, IP-in-IP, and is further extensible, for instance for upcoming  BIER.
>>> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable
>> space for application only in Mesh-under.
>>> This draft reuses that space in Route-over with the assumption that Route-
>> over will not co-exist in a sma enetwork with Mesh-under encoded in the RFC
>> 4944 fashion.
>>> If there is effectively a need for co-existence, devices have to implement the
>> new Mesh-under format that is also proposed in the draft.
>>> Comments welcome,
>>> Pascal
>>>
>>>
>>> -----Original Message-----
>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>> Sent: jeudi 27 novembre 2014 14:36
>>> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Toutain;
>> Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann
>>> Subject: New Version Notification for draft-thubert-6lo-routing-dispatch-
>> 00.txt
>>>
>>> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt
>>> has been successfully submitted by Pascal Thubert and posted to the IETF
>> repository.
>>> Name:		draft-thubert-6lo-routing-dispatch
>>> Revision:	00
>>> Title:		A Routing Header Dispatch for 6LoWPAN
>>> Document date:	2014-11-25
>>> Group:		Individual Submission
>>> Pages:		19
>>> URL:            http://www.ietf.org/internet-drafts/draft-thubert-6lo-routing-
>> dispatch-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-routing-
>> dispatch/
>>> Htmlized:       http://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch-00
>>>
>>>
>>> Abstract:
>>>      This specification provides a new 6LoWPAN dispatch type for use in
>>>      Route-over and mixed Mesh-under and Route-over topologies, that
>>>      reuses the encoding of the mesh type defined in RFC 4944 for pure
>>>      Mesh-under topologies.  This specification also defines a method to
>>>      compress RPL Option (RFC6553) information and Routing Header type 3
>>>      (RFC6554), an efficient IP-in-IP technique and opens the way for
>>>      further routing techniques.  This extends 6LoWPAN Transmission of
>>>      IPv6 Packets (RFC4944), and is applicable to new link-layer types
>>>      where 6LoWPAN is being defined.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>> The IETF Secretariat
>>>
>>> _______________________________________________
>>> 6lo mailing list
>>> 6lo@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6lo
>>>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>