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

From: Martin Turon <[email-masked]>
Date: Mon, 1 Dec 2014 08:17:39 -0800

Hi Pascal,

On Sun, Nov 30, 2014 at 12:59 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> The discussion already caused a rethinking of the idea. If it is not
> enough we can dig further.
>

Ok, this is certainly reassuring.  I'll admit my initial reaction to the
draft was based more on the understanding of intent from the call than on a
thorough read of the text.  Some of the initial text describes reassigning
the 10 bits that signal a mesh header, and that spawned the concern.

> 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.
>

Yes, providing a path to not preclude existing mesh header networks to live
on in isolation is certainly a requirement.  That mixed networks would have
to adopt this new draft seems reasonable.

> 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.
>

I won't argue with you there.  I remain an advocate for protecting the
future, while not overtly forcing deprecation on existing deployments.
Given a a clear upgrade path, and proper forward support path for mesh
header networks, your proposal certainly deserves proper review and
consideration.

> 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.
>

Splitting old and new across different networks is certainly reasonable.

One question inspired by this is how would newer dispatch implementations
deploy to a legacy dispatch network?  Imagine a large open network spanning
a city, with multiple versions of 6lo, and multiple routing protocols
running on top.  It's a very academic, futuristic example, but triggers
some basic questions like: how is versioning handled in 6lo?  I believe
versioning in 6lo currently is always done at deployment time.  It may be
worth considering a way to add an optional version dispatch in RHI to
signal what version of 6lo is being used, so mixed version networks in the
future can have a better chance of coexisting.

> 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...
>

Only HC1 and HC2 were deprecated from RFC4944 as far as I know.
Deprecating those was the right decision.  There may be more in RFC4944
that can be changed or improved, but the point is that the assumption must
be that most of it is in use today, and consideration for those networks
that use it should be made.  It sounds like you have been making those
considerations, which is appreciated.

Martin

> Pascal
>
> > Le 29 nov. 2014 à 20:24, Martin Turon <[email-masked]> 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)" <
> [email-masked]> 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: [email-masked] [mailto:[email-masked]]
> >> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Martin Turon <[email-masked]>
Date: Mon, 1 Dec 2014 08:52:10 -0800

Hi Carsten,

Yes, section 11 refers to the mesh header defined in section 5, but does
not claim exclusive use of it.

My point really is to inspire people to rethink the long held dogma that
the mesh header and mesh-under are synonymous, and counter proposed text
that codifies that view.

They need not be viewed that way, and my reading of RFC4944 doesn't mandate
that the two be equivalent.  In fact, "Appendix A. Alternatives for
Delivery of Frames in a Mesh", covers some of the alternate use cases,
design ideas, and pros/cons of using the mesh header at layer 2 or 3.

Martin

On Sun, Nov 30, 2014 at 4:35 AM, Carsten Bormann <[email-masked]> wrote:

> On 29 Nov 2014, at 20:24, Martin Turon <[email-masked]> wrote:
> >
> > The mesh header is very much in use today, and not purely for mesh-under
> conceptual designs.
>
> Hi Martin,
>
> I think it would benefit this discussion if we could learn more about
> these use cases.
> In RFC 4944, the “Mesh Header” definitely was meant for mesh-under; we
> even have a section called
>
>   11.  Frame Delivery in a Link-Layer Mesh*)
>
> to discuss the use of the Mesh Header in forwarding adaptation layer
> packets between link-layer entities.  But that of course doesn’t mean there
> aren’t other ways to make good use of the Mesh Header — I’d like to learn
> more about those.
>
> Grüße, Carsten
>
> *) The short forms “mesh-under” and “route-over” weren’t as much in use in
> 2007, so this is a long form trying to say “mesh-under”.
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Dec 2014 18:03:43 +0100

On 01 Dec 2014, at 17:52, Martin Turon <[email-masked]> wrote:
> 
> Hi Carsten,
> 
> Yes, section 11 refers to the mesh header defined in section 5, but does not claim exclusive use of it.

No, but then section 5.2 points to section 11 for further explanation what the Mesh Header is about.

> My point really is to inspire people to rethink the long held dogma that the mesh header and mesh-under are synonymous, and counter proposed text that codifies that view.

What I was trying to say is that 4944 was written from that view, and, while it is interesting to open up the semantics of the header, this would actually be a change already.

> They need not be viewed that way, and my reading of RFC4944 doesn't mandate that the two be equivalent.  In fact, "Appendix A. Alternatives for Delivery of Frames in a Mesh", covers some of the alternate use cases, design ideas, and pros/cons of using the mesh header at layer 2 or 3.

Right.  The problem really is that 4944’s Mesh Header is very inflexible: It only provides (1) a (limited) hop count, (2) a source MAC address, and (3) a destination MAC address.  Whether that is useful depends a lot on what your meshing protocol does; 4944 was rather speculative here.
Pascal’s idea is to open up the Mesh Header and make it extensible, so it can still carry the three items the old Mesh Header could carry, but can add and remove items, as needed by the forwarding mechanism.  This is achieved by going the TLV route.  It would be rather inefficient to leave the old inflexible Mesh Header consuming 1/3 of the dispatch space, requiring more bytes for the new one: so Pascal proposes reusing the space in networks configured that way.

(RFC7400 6CIOs might be useful for achieving that configuration in an automatic way, or not; this hasn’t been thought through.)

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Mon, 01 Dec 2014 18:16:53 +0000

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.
> 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
>
>
> 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
>
>
> has been successfully submitted by Pascal Thubert and posted to the IETF repository.
>
> 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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: James Woodyatt <[email-masked]>
Date: Mon, 1 Dec 2014 11:20:29 -0800

On Sun, Nov 30, 2014 at 12:59 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> [...]

> question to the group is whether that is acceptable.

I'm not sold...

> and we have just seen the very beginning of the IoT. Better fix things now

According to the IETF Datatracker, RFC 4944 is a Proposed Standard, which
puts it into the same category as "Transmission of IPv6 Packets over
Ethernet Networks" [RFC 2464 <http://datatracker.ietf.org/doc/rfc2464/>],
so I would never consider the fact that it doesn't have a STD number a good
argument for ignoring back-compatibility with it.  The statement "we have
just seen the very beginning of the IoT" is a bit harder to get my hands
around, but it sounds like a call for breaking existing deployments now
while they are thought to be rare and not a very large sunk cost, which
strikes me as a value judgment I would be wary about making.  I agree with
Martin that some consideration needs to be paid to version differentiation,
at the very least, if we're going to consider deprecating the Mesh Header
and replacing it with entirely different semantics, and even then, I may
still not be sold.

Shorter james: the draft doesn't seem acceptable to me at this time. Maybe
I'm insufficiently frightened of the foreseeable consequences of rejecting
it?

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 1 Dec 2014 19:49:42 +0000

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 [[email-masked]] on behalf of Pascal Thubert (pthubert) [[email-masked]]
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

> 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)" <[email-masked]> wrote:
>>
>> Dear all:
>>

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Dec 2014 06:41:17 +0100

On 01 Dec 2014, at 20:20, James Woodyatt <[email-masked]> wrote:
> 
> RFC 4944 is a Proposed Standard, which puts it into the same category as "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464], 

That argument would be more convincing if the situations were indeed comparable.

RFC 2464 is the basis for widely deployed plug-and-play interoperability.
*That* is what makes it mostly immutable, not the standards status.
(Which probably should be upgraded to match reality.)

With RFC 4944, we haven’t reached that level of interoperability yet.
In particular, there is *no* way to achieve out-of-the-box interoperability with the old mesh header — there is no defined way to use it, or even to find out that (and how) it should be used.
So you already have to add configuration (as in, "use mesh forwarding mechanism X") to use it.
Pascal’s proposal does not change this situation one iota: It doesn’t jeopardize interoperability where there was interoperability before.

(Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC 4944 and replaced them with RFC 6282.)

Again, I believe we need to learn more about those reported usages of the old Mesh Header before we can meaningfully continue this argument.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2014 15:31:36 +0000

Hello Robert:

I agree with you. This  is exactly the dilemma. But I do not read your own advice in there?

For your questions on the draft:

> '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)

> 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. 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

> From: Robert Cragie [mailto:[email-masked]]
> Sent: lundi 1 décembre 2014 19:17
> To: Pascal Thubert (pthubert); [email-masked]
> Cc: Routing Over Low power and Lossy networks; [email-masked]
> Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-routing-
> dispatch-00.txt
> 
> Hi Pascal,
> 
> > 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.
> > 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
> >
> >
> > To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Toutain;
> Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann
> > 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
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2014 16:28:46 +0000

+1

I wanted to answer James when I saw this. 
My answer would have been the exact same though I would certainly have failed to express it so well.

Thanks Carsten.

Pascal

> From: Roll [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: mardi 2 décembre 2014 06:41
> To: James Woodyatt
> Cc: [email-masked]; Routing Over Low power and Lossy networks; [email-masked]
> Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-
> 6lo-routing-dispatch-00.txt
> 
> > RFC 4944 is a Proposed Standard, which puts it into the same category as
> "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464],
> 
> In particular, there is *no* way to achieve out-of-the-box interoperability with
> the old mesh header — there is no defined way to use it, or even to find out that
> (and how) it should be used.
> Pascal’s proposal does not change this situation one iota: It doesn’t jeopardize
> interoperability where there was interoperability before.
> 
> (Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from
> RFC 4944 and replaced them with RFC 6282.)
> 
> Again, I believe we need to learn more about those reported usages of the old
> Mesh Header before we can meaningfully continue this argument.
> 
> Grüße, Carsten
>

---

From: James Woodyatt <[email-masked]>
Date: Tue, 2 Dec 2014 12:05:02 -0800

> With RFC 4944, we haven’t reached that level of interoperability yet.

Yes, well— I wasn't trying to make an argument that Proposed Standard
category implies the Expensive Mutability quality.  I was rebutting what
seemed to be Pascal's argument that Not Standard implies Inexpensive
Mutability by attempting to provide an existence proof in the form of RFC
2464.

In particular, there is *no* way to achieve out-of-the-box interoperability
> with the old mesh header — there is no defined way to use it, or even to
> find out that (and how) it should be used.
> Pascal’s proposal does not change this situation one iota: It doesn’t
> jeopardize interoperability where there was interoperability before.
>

Not quite true. We should be mindful of the possibility of existing
interoperability already obtained by conformance to external specifications
derived from RFC 4944. Because it's a Proposed Standard, I'm generally not
comfortable assuming that the Mesh Header is a sand castle that can be
safely demolished and rebuilt. Again, I think that's a value judgment about
existing deployments that we should be wary about making.

> Again, I believe we need to learn more about those reported usages of the
> old Mesh Header before we can meaningfully continue this argument.
>

I'm not sure that's a Need so much as a Desire, and a curious one at that.
I don't see the harm in proceeding to develop a coexistence strategy for
dealing with any existing implementations that may currently be using the
existing Mesh Header despite its rather fluid definition in the Proposed
Standard. Why is taking that precaution not a good idea?

---

From: Robert Cragie <[email-masked]>
Date: Tue, 02 Dec 2014 20:16:07 +0000

Hi Pascal,

Comments inline.

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>
> "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>

> 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2014 21:45:52 +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

> Sent: mardi 2 décembre 2014 12:16
> > 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:
> > 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.
> >   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.
> >
> top
> >> of RFC 6554.
> submission

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Dec 2014 23:37:10 +0000

Hello Martin:

One question inspired by this is how would newer dispatch implementations deploy to a legacy dispatch network?  Imagine a large open network spanning a city, with multiple versions of 6lo, and multiple routing protocols running on top.  It's a very academic, futuristic example, but triggers some basic questions like: how is versioning handled in 6lo?  I believe versioning in 6lo currently is always done at deployment time.  It may be worth considering a way to add an optional version dispatch in RHI to signal what version of 6lo is being used, so mixed version networks in the future can have a better chance of coexisting.

[PT] Well, as long as we route, we can interconnect different networks. These could be different technologies like PLC and 15.4, or these could be two 802.15.4 networks, one using the RFC 4944 MH and the other using the LoRH. As long as the IPv6 packet is reformed, routed, and then recompressed to adapt to the 6Lo compression of the outgoing link, we are safe.

Only HC1 and HC2 were deprecated from RFC4944 as far as I know.  Deprecating those was the right decision.  There may be more in RFC4944 that can be changed or improved, but the point is that the assumption must be that most of it is in use today, and consideration for those networks that use it should be made.  It sounds like you have been making those considerations, which is appreciated.

[PT] Thanks to you for a large piece.

Cheers

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Dec 2014 00:15:01 +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

> From: 6tisch [mailto:[email-masked]] On Behalf Of Richard Kelsey
> Sent: lundi 1 décembre 2014 11:50
> To: Routing Over Low power and Lossy networks; Martin Turon
> Cc: [email-masked]; [email-masked]
> Subject: Re: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-
> dispatch-00.txt
> 
> Pascal,
> 
> Given
> 
> 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
> 
> 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
> 
> > 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
> >

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Dec 2014 11:32:33 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > One question inspired by this is how would newer dispatch
    > implementations deploy to a legacy dispatch network?  Imagine a large
    > open network spanning a city, with multiple versions of 6lo, and
    > multiple routing protocols running on top.  It's a very academic,
    > futuristic example, but triggers some basic questions like: how is
    > versioning handled in 6lo?  I believe versioning in 6lo currently is
    > always done at deployment time.  It may be worth considering a way to
    > add an optional version dispatch in RHI to signal what version of 6lo
    > is being used, so mixed version networks in the future can have a
    > better chance of coexisting. 

I think that we will manage to version 6lo(wpan) only by create seperate
L2 networks... and I think that's okay, we have L3 mesh.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-