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

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