On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
Note: This ballot was opened for revision 09 and is now closed.
(Suresh Krishnan) Yes
(Deborah Brungard) No Objection
(Alissa Cooper) No Objection
Roman Danyliw No Objection
Comment (2020-02-16 for -12)
Thank you for this easy to read document and the work to produce it. Concur with Barry that [FRAG-ILE] and [LWIG-VRB] should be normative.
Benjamin Kaduk (was Discuss) No Objection
Comment (2020-03-21 for -14)
Thank you for addressing my Discuss (and Comment) points! In the security considerations, perhaps "fragment 1" would be better as "first-fragment" to avoid questions of zero- vs. one-indexing.
(Mirja Kühlewind) No Objection
Comment (2020-02-18 for -12)
I agree with one of Ben's comments in that I'm not certain about the intended document status as PS. I think Informational might be more appropriate, as it rather describes an approach based on existing protocols than a normative protocol specification. Thanks for quickly addressing the TSV-ART comments (and thanks Jörg for the TSV-ART review)!
(Barry Leiba) No Objection
Comment (2020-02-19 for -12)
Thanks for an interesting and well-written document. Just a batch of editorial comments: — Section 2.2 — poor network behavior and, occasionally, trouble at application layer. That experience led to the definition of "Path MTU discovery" [RFC8201] (PMTUD) protocol that limits fragmentation over the Internet. This is missing two definite articles (“the”), one after “trouble at” and one after “definition of”. "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security threats that are linked to using IP fragmentation. The 6LoWPAN fragmentation takes place underneath, but some issues described there may still apply to 6LoWPAN fragments. I think this makes FRAG-ILE a normative reference (necessary security issues). It would also be useful to have a “see Section 7” forward pointer here, so it’s clear that the specific issues are discussed later in this document. Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. I think this makes 4919 a normative reference (necessary terminology and concepts). Quoting the "Multiprotocol Label Switching (MPLS) Architecture" [RFC3031]: with MPLS, 'packets are "labeled" before they are forwarded'. At subsequent hops, there is no further analysis of the packet's network layer header. Rather, the label is used as an index into a table which specifies the next hop, and a new label". There’s a quote mismatch here: you should not end the quote after “forwarded”... but there should be a paragraph break after “forwarded.”, which makes the quoting awkward. I suggest handling the quote differently and eliminating the need for awkward cross-paragraph quotation. So it would look like this: NEW "Multiprotocol Label Switching (MPLS) Architecture" [RFC3031] says that with MPLS, 'packets are "labeled" before they are forwarded.' It goes on to say, “At subsequent hops, there is no further analysis of the packet's network layer header. Rather, the label is used as an index into a table which specifies the next hop, and a new label". END — Section 2.3 — This specification uses the following terms: I would say it “defines” these terms, no? 6LoWPAN endpoints: The nodes in charge of generating or expanding a 6LoWPAN header from/to a full IPv6 packet. The 6LoWPAN endpoints are the points where fragmentation and reassembly take place. I gather that the usual case is that the 6LoWPAN endpoints are the first and last nodes in an unbroken string of 6LoWPAN nodes, yes? If that’s correct, I think it would add to easy understanding if you said that. (And if it’s not correct, we might want to figure out why I got that impression.) — Section 4 — 4. Limits of Per-Hop Fragmentation and Reassembly There are at least 2 limits to doing per-hop fragmentation and reassembly. See [ARTICLE] for detailed simulation results on both limits. Should this be “limitations”, rather than “limits”? It seems so. Also throughout Section 6. — Section 5 — error and refrain from creating a state or attempting to forward. Make it “refrains”. — Section 6 — (Change “limits” to “limitations” throughout the section.) Doesn’t this section need LWIG-VRB to be a normative reference? because the IP header is required to route the fragment and is only present in the first fragment. This sounds as if the IP header has to do some routing. If you say “is required in order to route...”, that ambiguity goes away. — Section 7 — along a path, but each node suffers a lesser hit. this is because Capitalize “This”. An implementation MUST protect itself to keep the number of VRBs within capacity, and that old VRBs are You need another word before “that”: maybe “ensure”? This sounds difficult and mostly useless in a 6LoWPAN network since the fragmentation is not end-to-end. “Sounds”? “Is”, I should think; no? — Section 9 — Also many thanks to Georgies Papadopoulos I believe it’s “Georgios”. and Francesca Palombini For their constructive reviews through the IESG process. Lower-case “for”. And did Sarah, Joerg, and Francesca really review this through the IESG process, when the IESG process is just now starting? + + + + + + + + + + + + + + + + + + + + The following are comments from Murray Kucherawy, incoming ART AD. Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director. - - - - - - - - - - - - - - - - - - - - Section 2.2 does a great job of laying out the context for this work. The only thing that came up for me reading this is the SHOULD NOT in Section 7, where I think they might consider adding a sentence or two about why an implementer might decide to deviate from that advice.
(Alexey Melnikov) No Objection
Comment (2020-02-10 for -11)
I like this document.
Alvaro Retana No Objection
(Adam Roach) No Objection
Comment (2020-02-19 for -12)
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.
Martin Vigoureux No Objection
Éric Vyncke No Objection
Comment (2020-02-19 for -12)
Thank you for the work put into this document. It is very easy to read. Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS. As I reviewed draft-ietf-6lo-fragment-recovery before this document, I put some COMMENTs in my review of draft-ietf-6lo-fragment-recovery that also apply to this document. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Is there a reason why this document uses "Link-Layer address" while the companion, draft-ietf-6lo-fragment-recovery, uses "MAC address" ? This is cosmetic of course but if the concept is the same, using the same wording could only improve the readability of the documents. Same applies for "datagram_tag" vs "Datagram_Tag" ;-) -- Section 5 -- "Multiple fragments may progress in parallel" is not really correct as the rather travel "simultaneously" as they follow the same path but at different steps (i.e. not like using parallel links). -- Section 6 -- The "no per-fragment routing" can also be seen as an advantage as it forces all fragments to be in order. == NITS == Is the case in "Link-Layer" correct? I am a non native speaker but I would have used "link-layer".