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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 02 December 2014 21:45 UTC

Return-Path: <pthubert@cisco.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 028CC1A8769; Tue, 2 Dec 2014 13:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.956
X-Spam-Level:
X-Spam-Status: No, score=-12.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_LITTLE=1.555, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Jau-m3Ed5ger; Tue, 2 Dec 2014 13:45:55 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C061A874B; Tue, 2 Dec 2014 13:45:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9676; q=dns/txt; s=iport; t=1417556755; x=1418766355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vJNCapW/FKVuVJGfz0tPSqIXGeQhm+hmHPw5Vi0tX1I=; b=LiZfniOqsdPHLvvnMBE3zB/0KY7Mi6f/mMSaXd9qzfl2qu1EX9i4zM8Z NQDKatJBile0b4u2TeNHaDr0EV2/zmsy2JFOD6jOC5Cy9Q4IWuTZR5G3w G/EGviKrAhV7qXgf8/sLRV91jGN54YaRFYUExro74ep6TThQua0V/8ulZ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYFAIwxflStJA2N/2dsb2JhbABbgwdSWQTEaoIcCoYfAoEgFgEBAQEBfYQCAQEBBAEBASRHCQIMBAIBCBEEAQEBCh0HJwsUCAEIAgQBDQUIAYg3DdZCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pghSwLCgwRBisHAgSDI4EfBYpKhBiBf4Q+iBM6gn6DGYkihAKCAiAVgURvgQQCHiKBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="102058771"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 02 Dec 2014 21:45:54 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB2Ljsbl025221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 21:45:54 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 15:45:53 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "robert.cragie@gridmerge.com" <robert.cragie@gridmerge.com>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAhJ356AABfA8A==
Date: Tue, 2 Dec 2014 21:45:52 +0000
Deferred-Delivery: Tue, 2 Dec 2014 21:45:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A86362@xmb-rcd-x01.cisco.com>
References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A7DE36@xmb-rcd-x01.cisco.com> <547CB095.8050709@gridmerge.com> <E045AECD98228444A58C61C200AE1BD848A85E23@xmb-rcd-x01.cisco.com> <547E1E07.8020800@gridmerge.com>
In-Reply-To: <547E1E07.8020800@gridmerge.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.155.144.155]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zz8-qwDSLIuwCdL5tGfUAID4Nv0
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: 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 21:45:58 -0000

Hi Robert:

I'm in sync with you now. I will apply the changes that you suggest.
And yes, I was confused between MH and RH, and I need to add the deep hops to the MH description.

Finally, for the fence discussion, we try to avoid it by saying that both are legal but not in a same network, so we are creating exclusive features but not deprecating them.
I know it's a trick, but that's supposed to help the transition for those who wish to transition at all.

Thanks for this!

Pascal


> -----Original Message-----
> From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
> Sent: mardi 2 décembre 2014 12:16
> 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,
> 
> 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
> >
>