Pascal, Merci very much for your response and changes in the text. While my COMMENT were non blocking, I am happy to see that you took the opportunity to improve the document.
Regards (and do not forget the deadline of Monday __) -éric -----Original Message----- From: Pascal Thubert <[email protected]> Date: Friday, 6 March 2020 at 19:58 To: Eric Vyncke <[email protected]>, The IESG <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT) Hello Eric: Many thanks for your review! Please find the proposed changes discussed below in https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14 that I just published Let's see below, and please let me know if the proposed changes work: > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > == COMMENTS == > > A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header > Chains" is applicable ? > > -- Section 4.2 and Section 7.1 -- > Should default values for the inter-frame gap be given ? We discussed this in the minimal fragment review. Initially there was no other draft so this really introduced the concept. Now all the normative text moved to minimal. So it makes sense to make a change here: before This specification introduces a concept of an inter-frame gap, which is a configurable interval of time between transmissions to the same next hop. In the case of half duplex interfaces, this inter-frame gap ensures that the next hop has completed processing of the previous frame and is capable of receiving the next one. After [I-D.ietf-6lo-minimal-fragment] requires that a configurable interval of time is inserted between transmissions to the same next hop and in particular between fragments of a same datagram. In the case of half duplex interfaces, this inter-frame gap ensures that the next hop is done forwarding the previous frame and is capable of receiving the next one. end > > -- Section 5.1 -- > With 8 bits in the Datagram_Tag, this means that a node can only > transmit/forward 256 packets over a link. While this seems suffisant, did the > author make some investigation on this limit? The text should also state what > to do when the 8 bits are not enough. > A typical 6LoWPAN node have memory for one or a few packets. Having 256 packets that transit in the fragmented form over a same hop at the same time seems very far from the capabilities of current 6LoWPAN nodes. The trend for new MACs is to support the IPv6 Min MTU, making 6LoWPAN fragmentation a thing of the past. So I believe we're good. I'm adding the last sentences of the following text in the introduction: " "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment] specifies the general behavior that all FF techniques including this specification follow, and presents the associated caveats. In particular, the routing information is fully indicated in the first fragment, which is always forwarded first. A state is formed and used to forward all the next fragments along the same path. The Datagram_Tag is locally significant to the Layer-2 source of the packet and is swapped at each hop, more in Section 6. With this specification the Datagram_Tag is encoded in one byte, and will saturate if there are more than 256 datagram that transit in the fragmented form over a same hop at the same time. This is not realistic at the time of this writing. Should this happen in a new 6LoWPAN technology, a node will need to use several Link-Layer addresses to increase its indexing capacity. " > -- Section 5.2 -- > I suggest to mention that the use of the Datagram_Tag field will be described > in section 6. Works for me. In fact, I pushed that up to the introduction, see the text above. > > -- Section 6 -- > I find it weird to read in the same paragraph "The RFRAG Acknowledgment can > optionally carry an ECN" and later "MUST echo that information by setting the > 'E'". I am not a native English speaker but may I suggest to replace the first part > with "The RFRAG Acknowledgment has a ECN" Yes, done. > > -- Section 6.1.2 -- > "An implementation may receive overlapping fragments as the result of retries > after an MTU change." Is this a security risk (RFC 8200 forbids overlapping > fragments but this is a different layers) ? I also suggest to make it a normative > "MAY" or "MUST accept". I got a similar comment in Ben's review on this : ) " [I-D.ietf-6lo-minimal-fragment] indicates that the receiving endpoint stores "the actual packet data from the fragments received so far, in a form that makes it possible to detect when the whole packet has been received and can be processed or forwarded". How this is computed is implementation specific but relies on receiving all the bytes up to the Datagram_Size indicated in the first fragment. An implementation may receive overlapping fragments as the result of retries after an MTU change. " > > -- Section 7.2 -- > Should the network observation installs global states or per destination states > ? E.g., typical IP implementations maintain a per destination Path MTU cache. I guess the same here, this is per destination for each sender and per sender for each destination. " The management system should monitor the number of retries and of ECN settings that can be observed from the perspective of both the sender and the receiver with regards to the other end-point. " > == NITS == > > -- Section 7 -- > Is it "Kbps" or "kbps" ? Long as the b is lowercase (indicating bit) I believe we're safe. But back to SI, Kilo is uppercase (because it is a multiple of the unlike milli or micro) so I favor Kbps. Please let me know if we're good with the above, Again many thanks, Eric! Pascal _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
