Thanks a bunch for your review, Michel! I'll update the doc accordingly early next year.
The fragmentation and the forwarding of fragments are finally getting a hot topic, and was discussed at the last 6TiSCH interim. I'll probably present on the draft and the rationale behind some of the technical choices therein at the next interim on Jan 6th, 7AM pacific, if you can attend? Take care, Pascal From: 6lo [mailto:[email protected]] On Behalf Of Michel Veillette Sent: jeudi 22 décembre 2016 18:21 To: [email protected] Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Hi Pascal First, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fragments] is very appreciated. This draft addresses multiple issues associated to the transfer of large payloads. - Minimize frame overhead. - Increase efficiency and reduce latency compared to a reassembly at each router. - Complementary to the concept of TSCH tracks. - Guaranty a fix routing during the transfer which often result in a more deterministic performance. The following properties defined in this draft are important to us and need to be preserved. - End to end transfer of 6lo fragment without reassembly at each router - Optional use of acknowledgment and retries - Support of multiple fragments in transit - Label based routing These are my comments on the current version. 1) datagram tag I recommend that you globally replace "datagram tag" with a space by "datagram_tag" with an underscore to clearly indicate that you refer to the field within RFRAG. 2) Typo Section 8.1, second line, replace "adnd" by "and" 3) Reference to ND In section 8.1, I recommend that you remove the reference to ND in "a ND resolution to get the MAC address associated to IP_nxt". Some stacks don't use ND to perform this function. 4) label routing Is it possible to extend the concept of label based routing to subsequent IP packets part of the same flow in both directions (upstream and downstream)? The issue I want to resolve is the following. In an RPL non storing mode network, the 6LBR can create an alternate source route to go around a non functional router. This approach forces a route downstream, but not upstream unless the source route is replayed on the reverse direction. Can we define a new field (label), distinct from the datagram_tag, with a lifespan longer than a single IP packet transfer and used to perform this label based routing? Any suggestions to resolve this issue is appreciated. Regards, [cid:[email protected]] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
