Re: [Roll] [6man] #8 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-rpl-mesh-00

["6man issue tracker" <[e-mail]>]

#8: draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-
rpl-mesh-00


Comment (by [e-mail]):

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08808.html


 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Sun, 10 Aug 2014 17:05:34 +0000

 Hi Carsten

 I think you jumped too quickly on my suggestion at 6lo.

 It makes a lot of sense to work on a 6lo routing dispatch and in
 particular enable the compression of all RPL artifacts.

 It will take some time to figure out what goes in there but my suggestion
 at 6lo includes routing header compression, RPL option, but also source
 destination if we decide to route fragments.

 I hope this happens and I'll see with Laurent if we use a respin of his
 draft or I start a new one.

 This work will be beneficial in the long run, but doubly fails to address
 the issues at stake here:

 - the draft proposes to update the rules in 6437 with stateful and with
 domain scoped operations. This is used by the draft itself but also by
 published and deployed standards that came up before 6437 (eg ISA100.11a)
 and we are now acknowledging and legalizing a de facto situation.

 - it will take a year or 2 at best to agree on the new routing dispatch
 and its operation. We need an improvement now. And btw we cannot
 necessarily assume 6lo together with RPL, I know of at least one RPL
 implementation that does not use that compression.

 Finally, Using a dispatch for the RPL option alone seems like a waste, but
 that is a discussion for 6lo. I'll publish there when I'm back from
 vacations.

 Cheers,

 Pascal

 -------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08811.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Sun, 10 Aug 2014 21:07:04 +0200

 On 10 Aug 2014, at 19:05, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:

 > - it will take a year or 2 at best to agree on the new routing dispatch
 and its operation. We need an improvement now. And btw we cannot
 necessarily assume 6lo together with RPL, I know of at least one RPL
 implementation that does not use that compression.

 I don’t understand why we can’t do the saner equivalent of the flow label
 hack now and come up with a source routing header (which is not covered by
 the flow label hack) later.

 Please tell us more about how ISA100.11a uses the flow label; that is
 information that has been lacking from the discussion so far.

 Grüße, Carsten

 ------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08817.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Tue, 12 Aug 2014 10:40:19 +0200

 On 12 Aug 2014, at 09:15, Ines Robles <mariainesrobles at googlemail.com>
 wrote:

 > This technique saves bytes

 Again, the straw man at http://tools.ietf.org/html/draft-bormann-6lo-rpl-
 mesh-00
 saves the same number of bytes.  Actually, for common cases, it enables
 one additional optimization (saving one more byte) that is not available
 with the flow label hack.  (On the other hand, due to the way RFC 6282
 works, the flow label hack saves one byte where both it and ECN are in use
 and the common case does not apply.)

 The disadvantage of the RPL mesh header is that this approach is not
 available outside 6lo networks (i.e., networks employing adaptation layers
 that use RFC 6282).  I’m not aware yet of a use case where that is a
 problem.

 In either encoding (RPL mesh header or flow label), it is probably a good
 idea anyway to unpack the compressed information back into the RPL IPv6
 option when leaving the 6lo networks.

 Grüße, Carsten

 -------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08824.html

 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Wed, 13 Aug 2014 16:51:21 +0000

 I disagree, Carsten.

 To save all the bytes, we need to update the 6MAN rules and allow to
 change a non-zero flow label, be it only to reset and elide it when coming
 from the Internet.
 More in my other answer to you today...

 Pascal

 -----------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08818.html

 From: Brian E Carpenter <brian.e.carpenter at gmail.com>
 Date: Wed, 13 Aug 2014 11:38:53 +1200
 Ines,

 Can you perhaps clarify the exact question you are asking 6man?

 (I'm thinking that 6man isn't being asked whether the number
 of bits saved is a useful energy saving, or whether Carsten's
 proposal is better.)

 Regards
    Brian

 On 12/08/2014 19:15, Ines Robles wrote:
 > Hi,
 >
 > On April, it was discussed and got consensus in ROLL [
 > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html].
 >
 > This technique saves bytes, as was demonstrated by Xavier in his
 > implementation [ start on Slide 41 -
 >
 https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf].
 > Maybe we should enumerate the advantages and disadvantages of using it.
 > (Some of these are tracked in ticket #5, #6 and #7).
 >
 >
 > Anyway, demostratedIt needs the 6man approval to go forward.
 >
 > Cheers,
 >
 > Ines
 -------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08820.html

 From: Ines Robles <mariainesrobles at googlemail.com>
 Date: Wed, 13 Aug 2014 11:00:12 +0300

 Hi Brian,

 Thanks for your comment.

 Actually, I did not ask a question, I just wanted to say that the Pascal's
 draft got consensus at ROLL in april, and the WGLC was done between 6man
 and ROLL to know the 6man opinion about the use of flow-label (tickets #5,
 #6 and #7). With the new Carsten proposal (6lo draft), we (constrained
 environment WGs) should analyze this approach and decide the further steps
 on Pascal draft related with that.

 Thanks,

 Ines


 ---------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08822.html

 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Wed, 13 Aug 2014 16:37:27 +0000

 Hi Brian:

 The question to 6MAN is really whether the use that the draft makes of the
 flow label within the RPL domain is acceptable or not. In particular
 Section 1.3 does not force a particular usage of the flow label inside the
 LLN, it simply updates the rules of what is allowed and what is not within
 that domain, knowing that the root will set the label properly towards the
 Internet and reset it from the Internet.

 It is up to ROLL and other external standards adopting the work (ISA100,
 WCI) to decide of its usefulness.

 Cheers,

 Pascal


 --------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08819.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Wed, 13 Aug 2014 03:19:12 +0200

 On 13 Aug 2014, at 01:38, Brian E Carpenter <brian.e.carpenter at
 gmail.com> wrote:

 > Can you perhaps clarify the exact question you are asking 6man?

 Well, I’m not Ines, but I’m trying to find out why we are in this peculiar
 position of discussing this draft right now.

 ROLL has a routing protocol that requires some data to be shipped around
 together with IP packets.
 RFC 6553 and 6554 define ways to do this that are consistent with the IP
 architecture.
 Unfortunately, the overhead (signal-to-fluff ratio) is relatively high,
 and in this area of application, that matters.

 Normally, the next step would have been looking at ways to do header
 compression.
 We did talk about compressing ROLL, but with a view to compressing the
 (control plane) ROLL messages, not so much about the (data plane) IP
 packets themselves.  GHC is trying to be a reasonably useful, but also
 reasonably general way to do the control plane messages.

 For the data packets, the flow label (and its now predominant non-use)
 provides an attractive hole in the IPv6 packets to ship around the RFC
 6533 information, but not the RFC 6554 information.
 In 6lo networks, normally RFC 6282 compresses away empty flow labels, but
 it is cheap to put them in, so a flow label really only costs 3 bytes
 (instead of 8 bytes RFC 6553 costs).  The most useful information from RFC
 6553 can be stuffed into 19 bits, as demonstrated by the draft we are
 discussing here.

 RFC 6282 has extension points (GHC uses one of them), but not really
 useful ones for the ROLL data plane.
 So it appears it never occurred to us that the best way to handle these 19
 bits is to actually sidestep RFC 6282, and use the existing extension
 points of RFC 4944.  Until Laurent showed one way of doing this.  I just
 went from there and did a strawman using Laurent’s idea for compressing
 the RFC 6553 option, in a way that is as efficient as (or, in most cases,
 actually more efficient than) using the flow label hole.

 So to me it seems there no longer is a good technical argument to ask 6man
 to liberate the flow label for carrying RFC 6553.
 But that is maybe something that should now be discussed between 6lo and
 ROLL; I don’t think that this is a 6man issue (unless the answer is a
 simple “sure, go ahead, take it, we don’t need it any more anyway”, which
 is not what I have perceived RFC 6437 to say).
 When 6lo and ROLL have generated consensus on the need to do this, we may
 or may not want to go back to 6man and actually pry that flow label hole
 out of your fingers.

 Grüße, Carsten

 -------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08823.html

 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Wed, 13 Aug 2014 16:48:06 +0000

 Hello Carsten:

 In my view, this work is not competing with 6lo: for the specific value of
 keeping the draft whatever 6lo decides to do:

 - If this draft is not adopted, the flow label from LLN will probably stay
 all zeroes as it is today and the goal of 6437 will not be achieved. There
 is no way a device will waste 20 bits for a random that has no value
 inside the LLN. The text tells the RPL root to set the flow label.

 - If this draft is not adopted, the root of the LLN will have to forward
 the flow label coming from the Internet down to the end destination
 device, deep in the mesh, wasting 20 bits in each frame. These is a waste
 that 6lo compression will not be allowed to legally elide if today we
 decide that we do not allow it. Note: even if the correspondent sets the
 FL to zeroes to help the LLN, there is no way to guarantee that the flow
 label will not be set on the way since that much is lawful.

 - If the draft is not adopted, existing usages in shipping standards that
 incorporate IPv6 will stay borderline/unlawful. E.g. the draft legalizes
 the way ISA100.11a uses the flow label for a stateful flow identification
 within the ISA100 domain.

 - If the draft is not adopted, we have no leverage over WCI that is
 defining the backbone router for ISA100.11a devices. The draft indicates
 that the root should ensure that the flow label is correctly set when
 going outside, which is a minor increment to WCI, if pushed in due time
 with a proper RFC number that demands it.

 The need for this work was agreed at ROLL. We need a better solution than
 available, for application in RPL domains, that are often but not
 necessarily congruent with 6LowPAN domains.

 I'm fully supportive to have a 6lo compression that will improve the
 situation for a 6lowpan network, and at this point we have 3 proposals on
 the table, Laurent's, yours, and mine, which is to have a routing dispatch
 for route-over in parallel to the mesh dispatch that is mesh-under. I do
 hope we create a momentum there and converge. But there is no guarantee.

 All in all, I will not drop something that works now, with running code
 and all, and reached last call status, against the sirens of a compression
 that will not solve the issues above.

 Cheers,

 Pascal

 ------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08826.html

 From: Philip Levis <pal at cs.stanford.edu>
 Date: Wed, 13 Aug 2014 12:07:04 -0700

 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:

 > If this draft is not adopted, the flow label from LLN will probably stay
 all zeroes as it is today and the goal of 6437 will not be achieved.

 Pascal, I'm trying to reconcile your claim that the goal of 6437 is to
 allow enclosed networks to use the flow label with Brian's statement

 > Actually that's why I don't want to see a formal
 > update to 6437, because the only rational update would be to allow
 > any closed domain to invent its own usage. We had that argument at
 > length during the development of 6437, and decided against it.

 Phil

 --------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08830.html

 From: Brian E Carpenter <brian.e.carpenter at gmail.com>
 Date: Thu, 14 Aug 2014 08:52:56 +1200


 Right. I'm drawing a very subtle line between (a) stating an exception
 to 6437 for this particular usage and (b) opening the door to other
 usages. Since 6man clearly didn't want (b) during the development of
 6437 I think we do need to limit ourselves to (a).

     Brian
 --------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08828.html

 From: Philip Levis <pal at cs.stanford.edu>
 Date: Wed, 13 Aug 2014 12:11:48 -0700

 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:

 > The need for this work was agreed at ROLL. We need a better solution
 than available, for application in RPL domains, that are often but not
 necessarily congruent with 6LowPAN domains.

 This seems to me to be the strong technical argument in favor of the
 draft. While Carsten's approach seems better technically, it only works
 for 6lowpan, and RPL should be independent of the underlying link layer.

 Phil

 -------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08829.html

 From: Ralph Droms <rdroms.ietf at gmail.com>
 Date: Wed, 13 Aug 2014 15:49:45 -0400

 On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis <pal at cs.stanford.edu>
 wrote:

 > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:
 >
 >> The need for this work was agreed at ROLL. We need a better solution
 than available, for application in RPL domains, that are often but not
 necessarily congruent with 6LowPAN domains.
 >
 > This seems to me to be the strong technical argument in favor of the
 draft. While Carsten's approach seems better technically, it only works
 for 6lowpan, and RPL should be independent of the underlying link layer.

 Could we consider Carsten's approach a compression mechanism for the RPL
 information options, rather than a replacement, thereby allowing a one-to-
 one translation between compressed mode on 6lowpan networks and
 uncompressed mode in other networks?

 - Ralph

 ------------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08831.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Wed, 13 Aug 2014 23:02:30 +0200

 >> This seems to me to be the strong technical argument in favor of the
 draft. While Carsten's approach seems better technically, it only works
 for 6lowpan, and RPL should be independent of the underlying link layer.

 The transport of RPL specific information for data plane packets already
 *is* independent of the underlying link layer, as specified in RFC 6553
 and RFC 6554.  All we are talking about here is an optimization for those
 (for 6553, specifically; actually 6554 is probably the one even more in
 need).

 > Could we consider Carsten's approach a compression mechanism for the RPL
 information options, rather than a replacement, thereby allowing a one-to-
 one translation between compressed mode on 6lowpan networks and
 uncompressed mode in other networks?

 Indeed, that is probably the best way to view this approach.
 (In the next version of the draft, I’ll emphasize this.)

 My assumption here is:
 — Any subnet that could not live with transporting RFC 6553 as is, i.e. 8
 bytes extra compared to the flow label approach (for uncompressed
 packets*), already needs (and, at this point, has) a header compression
 solution for the expansive IPv6 header anyway.
   So adding RFC 6553 compression to that solution is the natural approach.
 — All subnets that can live with the IPv6 header as is, also can live with
 RFC 6553 as is.

 This argument is on a technical level.
 I’m not talking about cognitive dissonance**) here, or political issues.
 If there are important political issues (I have no idea what the
 ISA100/WCI talk is about), they probably need to be brought out in the
 open here.

 Grüße, Carsten

 *) less difference for header-compressed packets, e.g., 5 bytes for 6lo.
 **) http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, section
 2.6

-- 
-------------------------------------------------+-------------------------
 Reporter:  [e-mail]            |       Owner:
     Type:  defect                               |  [e-mail]
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/8#comment:1>
6man <http://tools.ietf.org/wg/6man/>