Zach - I agree. Let's do it right, and stick with route over.
When we have a solution that is proven to work, that makes sense. In
the meantime, let's not deprecate things people are using and may
still need, depending on the future successes.
I think it make a lot of sense to settle on a single HC model, since
there is proven, implemented work. I think abandoning the mesh header
in its entirety at this point is premature.
...Pete
ksjp
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.
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.
LOWPAN_BC0 would still be used to eliminate duplicates.
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?
- Zach
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
