Hi Michael,
Many thanks for your feedback!
Please find below my inline responses:
On Thu, 13 Jul 2023 at 17:35, Michael Richardson <mcr+i...@sandelman.ca>
wrote:
>
> {I haven't read your draft, but I'll get to it}
>
>
Thanks!
> 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.
>
>
The original assumption behind SCHC was that it is possible to know a
priori which will be the values of many of the packet header fields.
Therefore, as you say, the Rules would really be static.
However, perhaps more dynamic approaches could be enabled as well. But in
any case, for sure, and as the most simple case, a purely static approach
can be considered.
> > - “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?
>
As Pascal already replied, it would be IP-in-IP, RPI, SRH, and using RFC
8138 formats for efficiency.
>
> > - “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?
>
>
It is actually a way to allow an intermediate node to quickly know which is
the IPv6 destination address in a received packet with a SCHC-compressed
header, without a need to store particular Rules for the communication
between the two involved endpoints.
> > 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.
>
>
I understand, and agree. Perhaps the methods are quite complementary. We
may need to clarify as well as possible the pros and cons of each one.
Once again, many thanks for your feedback!
Cheers,
Carles
> --
> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
