Subject: [6lo] Intdir last call review of draft-ietf-6lo-minimal-fragment-04

From: Dave Thaler via Datatracker <[email-masked]>
Date: Wed, 06 Nov 2019 15:09:56 -0800

Reviewer: Dave Thaler
Review result: Ready with Issues

The title implies the document specifies a forwarding mechanism, but it does
not, it merely provides discussion of two mechanisms in other docs (RFC 4944
and draft-ietf-lwig-6lowpan-virtual-reassembly). I would recommend at least
changing the title to be more clear as to the purpose of the doc.

Technical confusion
-------------------
1) Page 3 says the reassembly buffer contains "the link-layer address that node
B uses to forward the
   fragments".  I cannot tell whether this is referring to B's link-layer
   address that it received the fragment on, or B's link-layer address that it
   uses as a source link-layer address for forwarding it on, or the link-layer
   address of the next hop to which B forwards.

2) Page 3 also says the reassembly buffer contains "the link-layer address of
the next hop that is resolved
   on the first fragment".  I found this similarly confusing.  What does it
   mean to resolve something "on" the first fragment?  Does it mean "during
   processing of the first fragment"?  Maybe I missed it, but I couldn't find
   in RFC 4944 anywhere that says that it would do next-hop resolution before
   the datagram can be reassembled.  That would seem like a waste, if the
   fragments are then discarded (e.g., due to timer expiry) without actually
   doing any forwarding.

3) Section 3 talks about "MAC address" specifically whereas section 1 always
talked about the more
   generic "link-layer address".  Why the inconsistency?

4) Section 3 talks about "a 1280-byte reassembly buffer for each packet", but
section 2.2 talks assumes
   a "1 kB reassembly buffer".  1k != 1280 bytes.  Why the inconsistency?

5) Section 3 explains that "the first fragment must always be forwarded first",
but does not explain
   what the behavior is if a fragment other than the first fragment is received
   before the first fragment. Figure 1 shows that the fragments can be received
   out of order, since there fragment 6 is received before 5, which is received
   before 4.   Presumably it is either queued or dropped.  If it's queued, then
   section 4 is insufficient, which talks about an attacker generating a large
   number of bogus "fragment 1" fragments, since if you queue the first
   fragment received even if it's not "fragment 1", then the same attack
   presumably exists, it's not specific to "fragment 1" packets.

Grammatical nits:
-----------------

Abstract has "... to forwarding ...", which should be "to forward" or "for
forwarding"

Abstract has "to the virtual Reassembly Buffer", which seems incorrect both in
terms of capitalization (since sectoin 3 has VRB) and grammar.  Suggest "to
using virtual reassembly buffers".

Section 1, first paragraph: "though possibly" is likely a typo for "through
possibly"

Section 1, 6th paragraph: "a same datagram" is oddly worded.  Suggest either "a
datagram" or "the same datagram"

Section 2.2, grammar issue in "Assuming 1 kB reassembly buffer".  Either
"buffers" plural or "Assuming a ..."

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Nov 2019 11:23:17 +0000

Hello Dave

Many thanks for being so reactive 😊

Please see below

> -----Original Message-----
> From: Dave Thaler via Datatracker <[email-masked]>
> Sent: jeudi 7 novembre 2019 00:10
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Intdir last call review of draft-ietf-6lo-minimal-fragment-04
> 
> Reviewer: Dave Thaler

A suggestion would help : ) 

Does "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network" go the right way?

> 
> Technical confusion
> -------------------
> 1) Page 3 says the reassembly buffer contains "the link-layer address that
> node B uses to forward the

The latter. B needs to send all the fragments with the same source link-layer address because that's part of the index for the datagram in C. Proposed change:
"
the Link-Layer address that node B uses as source to forward the fragments

"

>    fragments are then discarded (e.g., due to timer expiry) without actually

RFC 4944 reassembles and then routes. We make the routing decision on the first fragment before we receive the second fragment, forward the first fragment and store that state. Unsure how to reword, your suggestion would be appreciated.

>    generic "link-layer address".  Why the inconsistency?

Fixed to "link-layer address" consistently.

>    a "1 kB reassembly buffer".  1k != 1280 bytes.  Why the inconsistency?

Fixed to
"                                                                           Assuming a reassembly buffer
   for a 6LoWPAN MTU of 1280 bytes as defined in section 4 of [6LoWPAN],
   typical nodes only have enough memory for 1-3 reassembly buffers.
"

>    presumably exists, it's not specific to "fragment 1" packets.

6LoWPAN does not mandate that all the fragments are sent in order, thus Fig1. But fragment 1 is sent first 
Quoting section 5.5 of Rfc 4944
"
                                                                   The first link fragment
   SHALL contain the first fragment header as defined below.

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 0 0 0|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: First Fragment

   The second and subsequent link fragments (up to and including the
   last) SHALL contain a fragmentation header that conforms to the
   format shown below.

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 1 0 0|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |datagram_offset|
      +-+-+-+-+-+-+-+-+

                      Figure 5: Subsequent Fragments
"

The first fragment is the one with the IPv6 address of the destination that enables to find the next hop that the other fragments will use. So it is always available before a fragment can be forwarded. So it is easy to mandate that we forward it first. 
If we do that then the only way for a next fragment to arrive first is that the first fragment was lost in the transmission by the previous node. The first fragment may be queued for retries in the previous hop but that's a really bad idea.

Proposal:

* we add text on the above to clarify
* we mandate that on a link with ARQ, the node only forwards a next fragment if the first was acknowledged.
* we clarify that a next fragment that is received with no state from a first fragment for that datagram should be dropped.

> Grammatical nits:

done
> using virtual reassembly buffers".

I think we meant to the VRB draft. Applied your recommendation in the meantime:
"
This method reduces the latency and increases end-to-end reliability in route-over forwarding.
It is the companion to using virtual reassembly buffers which is a pure implementation technique.

"
Does that read well?

> Section 1, first paragraph: "though possibly" is likely a typo for "through
Fixed

> Section 1, 6th paragraph: "a same datagram" is oddly worded.  Suggest either
> "a datagram" or "the same datagram"

Yes French uses "a" to mean like any old datagram but still the same one; fixed : )

> "buffers" plural or "Assuming a ..."

Fixed as discussed above

Many thanks Dave. I'll be waiting for you answer on the open issues above before publishing.

Take care

Pascal

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Nov 2019 21:21:58 +0000

Responses inline below.

Pascal Thubert (pthubert) <[email-masked]> wrote:
> The title implies the document specifies a forwarding mechanism, but

> it does not, it merely provides discussion of two mechanisms in other

> docs (RFC 4944 and draft-ietf-lwig-6lowpan-virtual-reassembly). I

> would recommend at least changing the title to be more clear as to the purpose of the doc.

Sure.  Other possibilities in case you like them better than that one:

·        “6LoWPAN Fragment Forwarding Techniques: Discussion and Tradeoffs”

·        “An Analysis of Various 6LoWPAN Fragment Forwarding Mechanisms”

Etc.

> 1) Page 3 says the reassembly buffer contains "the link-layer address

> that node B uses to forward the

"

"

Ok

> 2) Page 3 also says the reassembly buffer contains "the link-layer

> address of the next hop that is resolved

When you say “We made”, who is “we”?  RFC 4944?  If so, cite a specific section,
since making the routing decision on receipt of the first fragment, rather than the last,
seems non-intuitive and wasteful.   If that’s what the RFC says, then you can point it out

since this doc is (from my understanding) about discussing issues and tradeoffs with other mechanisms.

The waste is that if you choose to discard the datagram rather than forward it,
your efforts in doing the lookup are a waste of cycles, and a waste of space to store the result.

If you have a constrained node where every byte of storage is precious, having to store another

link-layer address can be burdensome, as opposed to a mechanism that only does the lookup

post reassembly, and has no such storage requirements, thus is lighter weight and arguably
better for constrained nodes.

I would encourage adding such discussion into this doc.

> 5) Section 3 explains that "the first fragment must always be

> forwarded first", but does not explain

6LoWPAN does not mandate that all the fragments are sent in order, thus Fig1. But fragment 1 is sent first Quoting section 5.5 of Rfc 4944 "

                                                                   The first link fragment

                           1                   2                   3

                         Figure 4: First Fragment

   format shown below.

                           1                   2                   3

      |datagram_offset|

      +-+-+-+-+-+-+-+-+

                      Figure 5: Subsequent Fragments "

The text we’re discussing is about the order of receipt, not the order in which they are sent.

Even if it’s forwarded first, it does not mean it was received first (e.g., whether due to packet loss
or whatever other reason).

Regarding “that’s a really bad idea”… if this draft is the one discussing tradeoffs and variations, then perhaps
it should explain why “that’s a really bad idea”.

Proposal:

If by “clarify”, you mean by reference to normative text in the RFC that specifies it, then ok.

[…]

> Abstract has "to the virtual Reassembly Buffer", which seems incorrect

> both in terms of capitalization (since sectoin 3 has VRB) and grammar.

> Suggest "to using virtual reassembly buffers".

"

"

Does that read well?

Ok.

Dave

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Nov 2019 22:36:48 +0000

Hello Dave

Please see in-line

Le 7 nov. 2019 à 22:22, Dave Thaler <[email-masked]> a écrit :

Responses inline below.

Etc.

We (== this draft) do not compare technologies. We give a generic behavior for which the LWIG draft is an implementation. So it’s not a protocol per se but a way do use RFC 4944 that was not intended in 4944.

"

"

Ok

We is this draft. The art of 4944 reassembles the packet at each hop. Once the packet is reassembled then it is routed leading to the behavior you describe, that is resolve on last fragment.

This draft forwards a fragment as soon as it is received leading to more streamlined operations, less buffer bloat and lower latency. It is indeed wasteful if some fragments are missing after the first one since the first fragment will still continue till the end. That’s the other side of the coin, similar to store and forward switching vs. switching as the frame is being received.

This is pleading for reassembly at each hop. All the benefits of forwarding fragments are gone.

But must store 1K for each message and for a long time on slow links as opposed to 80 bytes at a time.

Sure! Your remarks enlighten a lack of discussion on pro cons that can be useful to decide whether to turn on the method. There are other aspects like hidden terminal between fragments where hop 2 sending to hop 3 may interfere at hip 1 with reception of next fragment from hop 1.

                                                                   The first link fragment

                           1                   2                   3

                         Figure 4: First Fragment

   format shown below.

                           1                   2                   3

      |datagram_offset|

      +-+-+-+-+-+-+-+-+

Proposal:

Cool will work on that too

[…]

"

"

Does that read well?

Ok.

Dave

Many thanks Dave,

I’m traveling most time between now and IETF, will still try to propose text and submit to your approval with best delay.

Take care

Pascal

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Nov 2019 23:44:24 +0000

Follow ups below

From: Pascal Thubert (pthubert) <[email-masked]>

Please see in-line

Le 7 nov. 2019 à 22:22, Dave Thaler <[email-masked]<mailto:[email-masked]>> a écrit :

Responses inline below.

Etc.

That’s not how I read the document right now.
First, this document as written does not specify any behavior itself, since the document is listed as Informational only, and contains no normative references.
Second, I read section 1-2 as analysis/discussion/issues around the normative behavior stated in [RFC4944], and section 3 as analysis/discussion/issues around the normative behavior stated in [I-D.ietf-lwig-6lowpan-virtual-reassembly<https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-04#ref-I-D.ietf-lwig-6lowpan-virtual-reassembly>].
If the WG’s intent for this document is to actually specify behavior, or behavior changes, in this document, then it should use 2119 language, and have normative references, so one can claim compliance to it.
And the document would require more changes than I originally expected or argued for in my review.

See my points above about “we is this draft” meaning this draft needs to be a lot clearer that it is specifying behavioral changes that one can conform to.
I read the text as explaining what RFC 4944 itself requires.  Specifically the last sentence of the section the text above is quoted from explicitly says
“That is, the packet is fully reassembled, then (re)fragmented, at every hop.”

That’s what I’m reacting to since the bullet list is very wasteful when fully reassembled at each hop, which is the context of this section.

Furthermore, it’s arguably broken since looking up the next hop when the first fragment arrives, and then only using it once all fragments
have arrived and the packet can be fully reassembled, means the next hop information can be stale at that point and you’re forwarding it
to the wrong place, or even a place that no longer exists at that time.

The notion of forwarding each fragment as it’s received, without reassembling, starts in section 3, which is the alternative being compared
(as I read it) with the stock 4944 approach.  It’s only then that “resolve next hop on first fragment received” makes any sense to me, not back in section 1.

That’s not my reading of the existing text.  My reading is of this doc is that [I-D.ietf-lwig-6lowpan-virtual-reassembly<https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-04#ref-I-D.ietf-lwig-6lowpan-virtual-reassembly>]
is what covers that behavior (as the first paragraph of section 3 the 6lo draft explains) and the 6lo draft is just analyzing it.
If the intent Is to specify it normatively in the 6lo draft, then I believe this draft needs more work
before being ready.

Not sure that “this” refers to.  See above.  Section 1-2 are currently written to be about the case where you reassemble at each hop.
[…]

Dave

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Nov 2019 07:50:33 +0000

Hello Dave

More below

Pascal

Le 8 nov. 2019 à 00:44, Dave Thaler <[email-masked]> a écrit :

Follow ups below

Please see in-line

Responses inline below.

Etc.

Yes, I spotted that and already moved  the LWIG draft  and RFC 4944 to normative References when I handled your first run of comments.

The high level behaviour change is that fragments are forwarded before the whole message is received.

The draft introduces the abstract technique and endorses the LWIG work as canonical to 6lo within that umbrella. It is also supposed to give more information on when to use FF and on caveats/pitfalls that may be encountered and precautions to be taken.

Some gory details and optimizations that are internal to a box and could be implemented otherwise are left to the LWIG draft. The 6lo work on recoverable fragments is another way of achieving fragments forwarding. Both inherit from the FF draft and yield the same pitfalls.

We discussed whether the draft should have been std track but the chairs recommended otherwise so we wrote it without BCP 14 terms. I guess it is still time to revise that.

I’m willing to consider that very seriously.

 I’d wish to settle on those changes with you and then run the result through the group rather than the other way around. Would that work for you? Could we talk in Singapore ?

Agreed. I guess the WG was clear on what we are doing beforehand and failed to spot this. I suggest adding introduction text that describes all we discussed here.

There’s some of that too.

There’s a generic behavior and a particular way of implementing it that we present as an example. That’s probably why it was difficult to position this draft info vs std track.

Agreed 1 and 2 are a problem statement with current state of the art. This was your suggestion to receive all fragments before forwarding the first one. This recreates the bloat we avoid with this draft by streamlining fragments.

All the best,

Pascal

Dave

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Nov 2019 08:04:23 +0000

Hello again Dave;

There’s a confusion in section 1 and 2 about what is the art of RFC 4944 and what changes when forwarding fragments. The conceptual reassembly buffer already has the data needed to forward the fragment.

I need to split that in 2 sections showing what’s needed to forward fragments. I guess we need a better introduction on ff and a section before 3 that discusses the concepts of FF that the LWIG implements.

I need to work on that before coming back to you.

Regards,

Pascal

Le 8 nov. 2019 à 08:50, Pascal Thubert (pthubert) <[email-masked]> a écrit :

Hello Dave

More below

Pascal

Follow ups below

Please see in-line

Responses inline below.

Etc.

All the best,

Pascal

Dave

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Nov 2019 13:24:37 +0000

Hello again Dave

Following up let me propose changes; the updated draft text in full is at https://github.com/twatteyne/draft-watteyne-6lo-minimal-fragment/blob/master/draft-ietf-6lo-minimal-fragment-05.txt

Main changes:

An intro section as follows

  1.  Introduction

   The original 6LoWPAN fragmentation is defined in [6LoWPAN] and it is
   implicitly defined for use over a single IP hop through possibly
   multiple Layer-2 (mesh-under) hops in a meshed 6LoWPAN Network.
   Although [6LoWPAN-HC] updates [6LoWPAN], it does not redefine 6LoWPAN
   fragmentation.

   This means that over a Layer-3 (route-over) network, an IP packet is
   expected to be reassembled at every hop at the 6LoWPAN sublayer,
   pushed to Layer-3 to be routed, and then fragmented again if the next
   hop is another similar 6LoWPAN link.  This draft introduces an
   alternate approach called 6LoWPAN Fragment Forwarding (FF) whereby an
  intermediate node forwards a fragment as soon as it is received if
   the next hop is a similar 6LoWPAN link.  The routing decision is made
   on the first fragment, which has all the IPv6 routing information.
   The first fragment is forwarded immediately and a state is stored to
   enable forwarding the next fragments along the same path.

   Done right, 6LoWPAN Fragment Forwarding techniques lead to more
   streamlined operations, less buffer bloat and lower latency.  It may
   be wasteful if some fragments are missing after the first one since
   the first fragment will still continue till the 6LoWPAN endpoint that
   will attempt to perform the reassembly, and may be misused to the
   point that performances fall behind that of per-hop recomposition.
   This specification provides a generic overview of FF, discusses
   advantages and caveats, and introduces a particular 6LoWPAN Fragment
   Forwarding technique called Virtual Reassembly Buffer that can be
   used while conserving the message formats defined in [6LoWPAN].

And an intermediate section before VRB as follows:

  4.  Forwarding Fragments

   A 6LoWPAN Fragment Forwarding technique makes the routing decision on
   the first fragment, which is always is the one with the IPv6 address
   of the destination.  Upon a first fragment, a node creates a state
   and forwards the fragment.  The state is then used to forward the
   next fragments of the datagram.  Since the datagram_tag is uniquely
   associated to the source Link-Layer address of the fragment, node B
   must assign a new datagram_tag from iuts own namespace for the next
   hop and rewrite the fragment header of each fragments with that
   datagram_tag.

   Compared to Section 2, the conceptual reassembly buffer in node B now
   contains, assuming that node B is neither the source nor the final
   destination:

   *  a datagram_tag as received in the incoming fragments, associated
      to Link-Layer address of node A for which the received
      datagram_tag is unique,

   *  the Link-Layer address that node B uses as source to forward the
      fragments

   *  the Link-Layer address of the next hop C that is resolved on the
      first fragment

   *  a datagram_tag that node B uniquely allocated for this datagram
      and that is used when forwarding the fragments of the datagram

   *  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,

   *  a datagram_size,

   *  a buffer for the remainder of a previous fragment left to be sent,

   *  a timer that allows discarding a partially reassembled packet
      after some timeout.

   A node that has not received the first fragment cannot forward the
   next fragments.  This means that if node B receives a fragment, node
   A was in possession of the first fragment at some point.  In order to
   keep the operation simple, it makes sense to be consistent with
   [6LoWPAN] and enforce that the first fragment is always sent first.
   When that is done, if node B receives a fragment that is not the
   first and for which it has no state, then node B should treat this as
  an error and refrain from creating a state or attempting to forward.

   This also means that node A should perform all its possible retries
   on the first fragment before it attempts to send the next fragments,
   and that it should abort the datagram and release its state if it
   fails to send the first fragment.

   One benefit of Fragment Forwarding is that the memory that is used to
   store the packet is now distributed along the path, which limits the
   buffer bloat effect.  Multiple fragments may progress in parallel
   along the network as long as they do not interfere.  An associated
   caveat is that on a half duplex radio, if node A sends the next
   fragment at the same time as node B forwards the previous fragment to
   a node C down the path then node B will miss the next fragment.  If
   node C forwards the previous fragment to a node D at the same time
   and on the same frequency as node A sends the next fragment to node
   B, this may result in a hidden terminal problem at B whereby the
   transmission from C interferes with that from A unbeknownst of node
   A.  It results that consecutive fragments must be reasonably spaced
   in order to avoid the 2 forms of collision described above.  A node
   that has multiple packets or fragments to send via different next-hop
   routers may interleave the messages in order to alleviate those
   effects.

Does that sound right?

Pascal

From: Dave Thaler <[email-masked]>
Sent: vendredi 8 novembre 2019 00:44
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04

Follow ups below

Responses inline below.

Etc.

Dave

---

From: Dave Thaler <[email-masked]>
Date: Tue, 12 Nov 2019 20:28:29 +0000

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Friday, November 8, 2019 5:25 AM
To: Dave Thaler <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04

Hello again Dave

Following up let me propose changes; the updated draft text in full is at https://github.com/twatteyne/draft-watteyne-6lo-minimal-fragment/blob/master/draft-ietf-6lo-minimal-fragment-05.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftwatteyne%2Fdraft-watteyne-6lo-minimal-fragment%2Fblob%2Fmaster%2Fdraft-ietf-6lo-minimal-fragment-05.txt&data=02%7C01%7Cdthaler%40microsoft.com%7Ce5e6570b9eaf446511d308d7644f0bd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637088162986168475&sdata=KeNcyTWQvwKkEP9AivyWKp2d1K9uAOVhmAmcnKeRsJs%3D&reserved=0>

Main changes:

1.      Introduction

Looks good so far.  I presume that [6LoWPAN] will then be a normative reference,
based on that wording, correct?

And would the draft be a standards track doc, or what?

  4.  Forwarding Fragments

Grammar problem above: “is always is”

   of the destination.  Upon a first fragment, a node creates a state
   and forwards the fragment.

I’d recommend “a node *attempts to* create state and forward the fragment”,
since either of those could potentially fail, right?

Also should this use normative language (“a node MUST…”)?

The state is then used to forward the
   next fragments of the datagram.

There’s a logic bug here in that you’re missing saying what happens if that state doesn’t exist.
E.g., “When a node receives a fragment other than a first fragment, it MUST look up
state based on the source Link-Layer address and the datagram_tag in the received fragment.
If no such state is found, the fragment MUST be dropped; otherwise the fragment MUST be
forwarded using the information in the state found.”

Since the datagram_tag is uniquely
   associated to the source Link-Layer address of the fragment, node B
   must assign a new datagram_tag from iuts own namespace for the next

Typo: “iuts”

Grammar: “each fragments” -> “each fragment”

   datagram_tag.

Since each fragment is forwarded separately, the above bullet looks confusing.
Why do you care “when the whole packet … can be … forwarded” since you
don’t forward whole packets?

   *  a datagram_size,

Same confusion here.  Why would you have a partially “reassembled” packet
if you forward fragments without reassembling at this node?

The use of “should” is ambiguous.  Do you mean SHOULD or MUST?

Does that sound right?

Pascal

From: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 8 novembre 2019 00:44
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04

Follow ups below

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Please see in-line

Responses inline below.

Etc.

Second, I read section 1-2 as analysis/discussion/issues around the normative behavior stated in [RFC4944], and section 3 as analysis/discussion/issues around the normative behavior stated in [I-D.ietf-lwig-6lowpan-virtual-reassembly<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6lo-minimal-fragment-04%23ref-I-D.ietf-lwig-6lowpan-virtual-reassembly&data=02%7C01%7Cdthaler%40microsoft.com%7Ce5e6570b9eaf446511d308d7644f0bd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637088162986178431&sdata=cTGayubx94CV8nUsN3fmXOTKg5cQrD%2BdsVFmrvxlh%2BA%3D&reserved=0>].

That’s not my reading of the existing text.  My reading is of this doc is that [I-D.ietf-lwig-6lowpan-virtual-reassembly<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6lo-minimal-fragment-04%23ref-I-D.ietf-lwig-6lowpan-virtual-reassembly&data=02%7C01%7Cdthaler%40microsoft.com%7Ce5e6570b9eaf446511d308d7644f0bd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637088162986178431&sdata=cTGayubx94CV8nUsN3fmXOTKg5cQrD%2BdsVFmrvxlh%2BA%3D&reserved=0>]
is what covers that behavior (as the first paragraph of section 3 the 6lo draft explains) and the 6lo draft is just analyzing it.
If the intent Is to specify it normatively in the 6lo draft, then I believe this draft needs more work
before being ready.

Dave

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Nov 2019 00:30:09 +0000

Hello Dave

Continued below

Le 13 nov. 2019 à 04:28, Dave Thaler <[email-masked]> a écrit :

Hello again Dave

Main changes:

1.      Introduction

Correct. That’s RFC 4944. The VRB draft also becomes normative.

I asked for a slot at 6lo to discuss your points. That would be a key one to agree with the group.

  4.  Forwarding Fragments

Fixed

I’d suggest MAY attempt to create the state and if successful MUST use it to forward the next fragments.

Used verbatim

Typo: “iuts”

Fixed

Fixed

   datagram_tag.

Yes, my mistake. Removed that line.

   *  a datagram_size,

That’s specific to the VRB method that might store a piece of a previous fragment. In general we need to timeout the state to clean it. Replaced the partially reassembled by the FF state

Removed « should « since your verbatim text already covers this now.

Does that sound right?

Pascal

I hope you’ll be able to attend 6lo. We need to clarify the goal of the draft and the target info vs. std track.

All the best,

Pascal

Follow ups below

Responses inline below.

Etc.

Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 13 Nov 2019 01:02:32 +0000

Pascal wrote:
[…]

Ø  I’d suggest MAY attempt to create the state and if successful MUST use it to forward the next fragments.

To me, that sounds like an inappropriate use of MAY.  MAY means an implementer can choose to ignore it.
Do you really mean that an implementer can choose NOT to attempt to create the state?
If it doesn’t implement attempting to create the state, then how could the mechanism work at all?

[..]

Ø  I hope you’ll be able to attend 6lo. We need to clarify the goal of the draft and the target info vs. std track.

I just checked the schedule, and I yes can attend 6lo now.
(I think there was a conflict in the draft agenda that is no longer present in the final agenda.)

Dave

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Nov 2019 03:49:31 +0000

Hello Dave

Le 13 nov. 2019 à 09:02, Dave Thaler <[email-masked]> a écrit :

Pascal wrote:
[…]

I intended the MAY to indicate that the FF mechanism is optional. The node can always do what it did so far and either recompose the full packet to forward it or drop the packet for reasons of its own.

It could split in 2 sentences; say that the mechanism is OPTIONAL and then that when it is used the node MUST attempt to create the state; would that clarify ?

[..]

Great !

Pascal

Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 13 Nov 2019 19:33:21 +0000

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Tuesday, November 12, 2019 7:50 PM
To: Dave Thaler <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Intdir last call review of draft-ietf-6lo-minimal-fragment-04
Le 13 nov. 2019 à 09:02, Dave Thaler <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal wrote:
[…]

Yes.  Of course your entire document is optional, so I’m not sure you need to explicitly say it’s OPTIONAL as long as you don’t Obsolete any other RFC.
You could just say that “An implementation that does fragment forwarding MUST attempt to create the state…”

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Nov 2019 23:09:24 +0000

Thanks a bunch Dave

The final paragraph would looks like this:
“
A 6LoWPAN Fragment Forwarding technique makes the routing decision on the first fragment, which is always the one with the IPv6 address of the destination. Upon a first fragment, a forwarding node (e.g. node B in a A->B->C sequence) that does fragment forwarding MUST attempt to create a state and forward the fragment. This is an atomic operation, and if the first fragment cannot be forwarded then the state MUST be removed. When a forwarding node receives a fragment other than a first fragment, it MUST look up state based on the source Link-Layer address and the datagram_tag in the received fragment. If no such state is found, the fragment MUST be dropped; otherwise the fragment MUST be forwarded using the information in the state found. Since the datagram_tag is uniquely associated to the source Link-Layer address of the fragment, the forwarding node MUST assign a new datagram_tag from its own namespace for the next hop and rewrite the fragment header of each fragment with that datagram_tag.
“

Works?

Pascal

Sent: jeudi 14 novembre 2019 03:33

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 12, 2019 7:50 PM
To: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Intdir last call review of draft-ietf-6lo-minimal-fragment-04
Le 13 nov. 2019 à 09:02, Dave Thaler <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal wrote:
[…]

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 Nov 2019 00:08:44 +0000

Looks good, thanks.

Dave

Sent: Wednesday, November 13, 2019 3:09 PM

Thanks a bunch Dave

Works?

Pascal

Pascal wrote:
[…]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Nov 2019 06:15:28 +0000

Hello Dave :

I published 06 with all the changes we discussed. It I snow std track. The chairs will update the datatracker accordingly.

Many thanks again!

Pascal

Sent: jeudi 14 novembre 2019 01:09

Looks good, thanks.

Dave

Thanks a bunch Dave

Works?

Pascal

Pascal wrote:
[…]