Hello Michael Case 2 RPL is hopefully RFC 8138. Else it’s the non storing tunnel as in RFC 9008, the SCHC always encapsulating to the root and back.
Regards, Pascal > Le 13 juil. 2023 à 17:36, Michael Richardson <[email protected]> a écrit : > > > {I haven't read your draft, but I'll get to it} > > Carles Gomez Montenegro <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
