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

[Carsten Bormann <[e-mail]>]

On 01 Dec 2014, at 17:52, Martin Turon <[e-mail]> 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