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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 04 December 2014 00:15 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 EFE441ACF5E; Wed, 3 Dec 2014 16:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2eyhhOdxZJlI; Wed, 3 Dec 2014 16:15:03 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627D71A8A0D; Wed, 3 Dec 2014 16:15:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7196; q=dns/txt; s=iport; t=1417652104; x=1418861704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mzeWqeNqJTws7hKvFD6KkoNl4KN3pwtATKxDHbQsJiU=; b=ALAvYY7hus+FjKhBe2FlPPnn2OURclIlPQLGbqDbQVyqt99IBkt5F1wd D1aevMa81dZhsGKEDOjw9bW5+BCkYCCwfmdF3JhtKPord0Fpm6H41ss+L 0B4BXgp8/fvyVK26cvDb1WE0tzVrKH8fIv+6Ze37mMI/eRjX6pG62SK71 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAN6mf1StJA2J/2dsb2JhbABagwZSWATEJIIcCoF7AYNLUAKBFRYBAQEBAX2EAgEBAQQBAQFrCQIMBAIBCBEEAQEBCh0HJwsUCAEIAgQBDQUIAYg1DdZHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pahTQKHTEHBoMegR4FiiGFboQWh1Y4gnWPR4I1gUNvgQNCgQABAQE
X-IronPort-AV: E=Sophos;i="5.07,511,1413244800"; d="scan'208";a="102455880"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 04 Dec 2014 00:15:02 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB40F2jj027086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 00:15:02 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 18:15:02 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Richard Kelsey <Richard.Kelsey@silabs.com>, "Routing Over Low power and Lossy networks" <roll@ietf.org>, Martin Turon <mturon@nestlabs.com>
Thread-Topic: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAPpEACAAH86VIACrHUAgAMJP3A=
Date: Thu, 4 Dec 2014 00:15:01 +0000
Deferred-Delivery: Thu, 4 Dec 2014 00:14:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A88C4D@xmb-rcd-x01.cisco.com>
References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A7DE36@xmb-rcd-x01.cisco.com>, <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com>, <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> <ae8da1f7210644f384c6191c8a38274f@SN2PR0701MB1038.namprd07.prod.outlook.com>
In-Reply-To: <ae8da1f7210644f384c6191c8a38274f@SN2PR0701MB1038.namprd07.prod.outlook.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.106]
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/H52kgZEaJ0xtaczLp4dMvBYKjNc
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Roll] [6tisch] 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: Thu, 04 Dec 2014 00:15:11 -0000

This is interesting, Richard.

At the same time, we need to keep it globally simple, such that by reading a value on a box we can figure interoperability.
Maybe we could have profiles that define where the various ranges are taken from?

Cheers,

Pascal


> -----Original Message-----
> From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Richard Kelsey
> Sent: lundi 1 décembre 2014 11:50
> To: Routing Over Low power and Lossy networks; Martin Turon
> Cc: 6tisch@ietf.org; 6lo@ietf.org
> Subject: Re: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-
> dispatch-00.txt
> 
> Pascal,
> 
> Given
> 
>   "we have just seen the very beginning of the IoT"
> 
> and
> 
>   "... to allow in a different network to use the bits
>    differently knowing that devices will have to be
>    homogeneous inside one network."
> 
> perhaps a better approach would be to define new 6LoWPAN encodings without
> nailing down where they go in the full space.  Suppose this new draft instead of
> specifying meanings for 10xxxxxx specified a block of 64 consecutive encodings
> xxxxxx.
> If someone wants to use this new encoding and the 4944's MESH they could put
> the new encodings somewhere other than 10xxxxx.
> Or the MESH values somewhere else and put the new encodings at 10xxxxx.
> 
> Allowing the actual codes used be determined by the network would avoid
> having to nail down which encodings were compatible with which other ones.
> You could mix and match.
> All a device needs to know is that encoding A starts at value N and encoding B
> starts at value M.  In setting up a network the starting values could be chosen to
> make the dispatching bit-based as it is now, or some other scheme could be
> used.
> 
> Just a thought.
> 
>    -Richard
> 
> ________________________________________
> From: Roll [roll-bounces@ietf.org] on behalf of Pascal Thubert (pthubert)
> [pthubert@cisco.com]
> Sent: Sunday, November 30, 2014 3:59 AM
> 
> Hi Martin,
> 
> The discussion already caused a rethinking of the idea. If it is not enough we can
> dig further.
> 
> The idea as presented in the draft now is not to deprecate the mesh header but
> to allow in a different network to use the bits differently knowing that devices
> will have to be homogeneous inside one network.
> 
> You were the advocate to protect the future by not consuming too many bits in
> the NHC proposal. You also realize that the mesh header consumes 1/3 of the
> whole dispatch space, without a way to extend what's done inside. This is not
> protecting the future.
> 
> The new proposal allows to encode the existing MH with limited change but now
> it is extensible. The price to pay is different network. And the question to the
> group is whether that is acceptable.
> 
> Even if there are implementations today, RFC 4944 is not an internet std and we
> have just seen the very beginning of the IoT. Better fix things now than later...
> 
> Pascal
> 
> > Le 29 nov. 2014 à 20:24, Martin Turon <mturon@nestlabs.com> a écrit :
> >
> > Hi Pascal,
> >
> > I thought the call where this idea of overloading the mesh header was
> presented was met with general discontent.
> >
> > Also, the rfc4944 calls it the mesh header, it isn't called the mesh-under
> header.  The mesh header is very much in use today, and not purely for mesh-
> under conceptual designs.
> >
> > I would be wary of proposals that greatly alter the 6lo header, especially the
> dispatch bits, rather than extend it in very general ways.
> >
> > Martin
> >
> >> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)"
> <pthubert@cisco.com> 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
> >
> > _______________________________________________
> > 6tisch mailing list
> > 6tisch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tisch
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch