{I haven't read your draft, but I'll get to it}
Carles Gomez Montenegro <carles.go...@upc.edu> wrote:
> - “Straightforward Route-Over” incurs the lowest header overhead, as it
> only requires the SCHC Dispatch (1 byte). However, it is the most
> demanding approach in terms of memory usage, since all network nodes
> (including intermediate nodes) need to store all the Rules in use in
At this point all constrained networks are purpose-built, usually for a
single application. (This is not how many thought it would work, if you go
back to 2007ish...)
As I understand SCHC, the Rules are not dynamic, and so a network built using
this method would be provisioned correctly.
> - “Tunneled, RPL-based Route-Over” incurs greater header overhead (with
> some cases in the order of 12-16 bytes, although it may be more
I'm guessing that this overhead is in the RH3, and that in the absense of
SCHC, that we'd still have to spend that overhead?
> - “Pointer-based Route-Over approach” also only requires the endpoints
> to store the Rules they will need to communicate with other
This feels like some kind of new optimized source routing mechanism?
> A question that has been raised is whether we might want to keep all
> three route-over approaches in the document or reduce the number of
> such approaches. As authors we are in favor of enabling all of them,
> since they may be complementary, and the most suitable one can be
> chosen for each deployment.
I don't object to multiple methods in theory, if there is a way to clearly
articulate (at build time), which one will be used. But it would be better
for mindshare and debugging, and code maintenance to have fewer methods.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
