Timothy J. Salo wrote:
I think there is no question that 6lowpan is breaking new ground within the IETF. As far as I know, this is the first IETF Working Group that intends to specify a layer-two routing solution. (Yes, yes, I know. We could claim that it is actually "mesh under routing" or layer 2.5 routing, or layer 2.3457 routing. But nonetheless, 6lowpan intends to specify a routing solution that operates on link-layer addresses. And, I think this is unique within the IETF.)
Really? There is nothing in the proposed charter that suggests we will develop a mesh under routing solution. If you remember at the 69th IETF, we did come to an agreement that we would not develop a mesh-under solution at this time. The only related proposal is to develop *requirements* for such a mesh under solution which could be defined outside the IETF.
[...]
So yes, customers may, depending where they are, have as many as _two_ (not the 36 you seemed to be trying to lead us to believe) incompatible physical layer choices. (Although which two choices customers have varies by geographic, or more precisely ITU, region).
You haven't addressed my concerns about the variants of IEEE 802.15.4 (a, e, 2006). I also forgot to include ISA, which is developing their own 802.15.4 configuration, utilizing frequency agility and time synchronization. Should we ignore them too? The issue is that 802.15.4-2006 specifies only a limited set of energy-management mechanisms, which are often not satisfactory in a large number of applications. For example, there is no provision for energy-constrained FFDs. This is precisely the reason why there are new energy-management protocols being defined for 802.15.4. Furthermore, what about support for route-over which would be useful for ROLL (if it forms)? Are you ready to say that link-local multicast should never be used? How do you plan on discovering your neighbors at L3? The WG currently does not assume a particular configuration and I believe there is support to keep it that way.
Correct me if I am wrong, but you appear to be arguing that because the 802.15.4 spec offers customers two choices, then the IETF should make no effort to ensure system-level interoperability. I am not convinced that this is the right answer (or the right reasoning).
It all depends on what's included in your 'system'. If you expect 802.15.4-2006, ISA100.11a, 802.15.4e to all interoperate using the exact same network-layer mechanisms, then good luck. You might get 2 of the 3, but I highly doubt you'd get all three.
By the way, I am glad to see your support for the notion that 6lowpan is targeting 802.14.4 _networks_, rather than 802.15.4 _radios_. This permits us to at least consider making use of 802.15.4 functionality that might not be implemented in 802.15.4-compatible chips.
Yes, I am promoting networks. The issue is that just saying 802.15.4 does not define the network.
-- Jonathan Hui _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
