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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Jul 2015 09:33:32 +0000

Hello Timothy:

The premise is that you do not get a stack to work with another by magic, and an ISA100.11a  implementation would not work with ZigBee IP even if both claim 6loWPAN. There will soon be a fourth generation of 802.15.4 and you know that there are many variations on what you do in there, including TSCH, frame formats, you name it.

One must have a clear definition of what to pick from the standards at all layers to achieve interworking, and a conformance body is required that will validate a given profile and provide a stamp that guarantees interop. 

I saw opposition on option 1 from 2 camps, neither of which, I understand, is compatible with RFC 4944 by the book or could interop with ZigBee IP, for instance. Either they use Mesh header to put stuff that is not a MAC address, or they use escape encoding that was never standardized. All in all, they would not be able to forward a packet from one another though they certainly work perfectly fine if the subnet is a silo. 

If we get rid of the fantasy that there's a single 6LoWPAN network, and that all devices can plug into it, then we see that there will be multiple bodies like ZigBee IP defining profiles and ensuring connectivity of compliant implementations. A device would be designed for one such profile, where the use of either legacy mesh or option 1 would be enforced. Or a device could be compliant with multiple such profiles in which case there would be a need for configuration or discovery.

To your question, I do not think that the particular use of the dispatch would be discovered on the fly, but rather imposed in the beacons. If we take that path we could define ways to do that.

But there's a more complex opposition against option 1, more difficult to debate technically, and that is the political side, having to go and defend the case against other bodies outside the IETF. So the authors were asked to provide additional options, which are additions to the protocol. Do you have any advice on them?

Cheers,

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Timothy J. Salo
> Sent: mardi 7 juillet 2015 23:01
> To: Routing Over Low power and Lossy networks; [email-masked]
> Subject: Re: [Roll] FW: New Version Notification for draft-thubert-6lo-
> routing-dispatch-04.txt
> 
> > Please consider those options, and come discuss them at 6Lo:
> >
> >        Option 1 considers that a network where this specification applies
> >        is physically separate from a network where the Mesh Header
> >        defined in [RFC4944] is used.  With that assumption, the Mesh
> >        Header dispatch space can be reused.
> 
> How is this configured?  Does it require manual configuration?
> Or, can it be reliably detected automatically?
> 
> -tjs
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Jul 2015 13:48:29 -0700

On Jul 9, 2015, at 02:33, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> If we get rid of the fantasy that there's a single 6LoWPAN network, and that all devices can plug into it, then we see that there will be multiple bodies like ZigBee IP defining profiles and ensuring connectivity of compliant implementations.

I don’t remember ever adopting this fantasy, yet I still have concerns about proceeding with this draft.

> A device would be designed for one such profile, where the use of either legacy mesh or option 1 would be enforced.

I can see this happening under the terms of the current draft. I think it’s important to consider what “device” likely means in this context. We’re talking about commodity implementation modules. When you design a finished product, you choose the commodity implementation module that implements the specific profile of 6LoWPAN for which it was certified to interoperate.

> Or a device could be compliant with multiple such profiles in which case there would be a need for configuration or discovery.

If am deeply skeptical that this assertion will be proven if we proceed with this draft. I expect it to be much more likely that one or two specific profiles will be implemented as commodity modules, and devices that use them will be forced in hardware to use exactly one profile at all times.

—james

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 10 Jul 2015 12:10:17 -0700

On Tue, Jun 30, 2015 at 12:09 PM, Gabriel Montenegro <
[email-masked]> wrote:

> Thanks, Pascal.
>
> I see that options 1 and 2 reuse the mesh header. And option 3 reuses
> NALP. All three of these reuse previously assigned values.
>

My reading of Option 3 in Section 3.3 is that it uses bit patterns that
have not been assigned yet.  In particular, bit patterns of the form
11x1xxxx.

I was under the impression that one of the options was going to use a new
> type out of the ESC+<type> space. Sure, as you mention in the new draft
> revision, that is not defined clearly yet (though there is something being
> prepared), but neither is any of the stuff in the draft.
>

That is certainly another option to consider.

The point is that it would be good to have at least one option that does
> not reuse anything previously assigned (other than ESC, which is there for
> that purpose and is in our control to further define).
>

I agree that we should strongly consider encodings that allow both existing
assigned bit patterns and the TBD bit patterns to co-exist in the same
6LoWPAN frame.  If we can, we should avoid straight up reuse of
bit-patterns without any way to distinguish how to interpret between the
old and new.

Oh, and request noted. It would definitely be good to discuss this in
> Prague.

Agree.

--
Jonathan Hui