Re: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

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