Hi Zach, see below:
On Jul 18, 2008, at 6:05 AM, Zach Shelby wrote:
I'd like to make a bold proposal. If we now decide to take HC into use, and depreciate HC1 (momentum seems to be there); I would like to go one step further. Let's depreciate the use of the RFC 4944 mesh-header at the same time.
Good question.
draft-hui-6lowpan-hc-00 now allows us to do everything which the mesh-header does, and more. Sending packets to a global IPv6 node using the mesh header now requires both the mesh-header, plus an L3 destination address. Quite inefficient. Plus there is again the issue of implementation, testing, and interop along with a confusing spec where routing src/dst can be carried both in lowpan and IPv6 headers.. This situation is similar to that of HC1 and HC. The mesh-header will slowly depreciate anyways, especially with ROLL activity, and for interop reasons between vendors. Let's depreciate it now and stop the annoying mesh-under vs. route-over confusion.
I'm all for simplicity - it's quite significant when we're dealing with resource-constrained devices that are hard to debug. Again, I think we should be more explicit about routing vs. forwarding. The mesh header allows L2 forwarding, but there's no reason why you couldn't combine that with L3 routing. Then there's the L3 vs. L2 routing debate and, if it hasn't been obvious already, I'm all for an L3 routing approach. I wouldn't want us to relive the days of LAN emulation in dynamic, multihop networks, especially those that are resource-constrained.
LOWPAN_BC0 would still be used to eliminate duplicates.
If you're doing L3 forwarding, you probably want to carry that in an L3 header (we place it in a compressed hop-by-hop option header). In light of some of the earlier discussion with HC, I think it's time to incorporate HBH options into the HC draft.
At Sensinode we are likely the largest production deployers with the mesh-header at this time, and are willing to move to L3 at the same time as HC. How about other implementors using the mesh-header, can you support this motion? Can anyone think of a reason to keep the mesh header?
The only real advantage I see of the mesh header is that it allows you to pick an intermediate destination. But this requires packets to carry both the mesh header and L3 addressing as you pointed out above. A better application of L2 forwarding is to apply MPLS-style forwarding and utilize the traffic-engineering capabilities that it provides, but then we'd want a header that carries a label, not the mesh addressing header that carries a source and destination addresses. I think ISA100 is currently leaning in a direction of using the mesh addressing header, but this might still be in flux. On the other hand, we've had significant experience with L3 forwarding in low- power, lossy networks and must say that it's been working pretty well so far. But others with more experience in L2 forwarding should speak up as well.
-- Jonathan Hui
- Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
