Re: [Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation

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

#6: draft-thubert-6man-flow-label-for-rpl-03  Updates: 6437 (if approved)  -
add section with explanation


Comment (by [e-mail]):

 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21030.html

 From: Carsten Bormann <cabo at tzi.org> Date: Sun, 10 Aug 2014 18:29:01
 +0200



 So far, we have mainly discussed the need for an optimization (it seems we
 now agree there is a need) and the interaction between the normative
 components of RFC 6437 and those of the draft at hand.

 I’d now like to bring up a different question:

 Is this the right approach?

 I have written up what appears to be a more natural approach in the
 strawman draft:
 http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00

 Why are we doing the flow-label thing and not the more natural thing?

 [ ] because the flow label hack works on packets that leave the 6lo
 networks.
     • but do we really need to optimize this on the non-6lo networks?
 [ ] because the flow label hack has been around for a while and is now
 cast in stone.
     • is it?
 [ ] because there is a flaw with the way this has been integrated into the
 6lo framework.
     • ______ (fill in the flaw)
 [ ] because ______ (fill in the reason)

 Inquiring minds want to know.

 Grüße, Carsten

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

 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21034.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/ipv6/current/msg21036.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/ipv6/current/msg21039.html

 From: Ole Troan <otroan at employees.org> Date: Mon, 11 Aug 2014 15:54:35
 +0200

 > I *really* don't think RFCs are algorithms to the point where we
 > need to do this. I see no reason why flow-label-for-rpl can't simply
 > declare itself an exception to this clause of RFC 6437.

 I must admit I'm uncomfortable with this draft and its approach. how can
 we be sure that we aren't opening a Pandora's box?
 I'm worried that we set a precedence, and we'll see a new set of creative
 proposals for the use of these 20 bits.

 cheers,
 Ole

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

 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21040.html

 From: Brian E Carpenter <brian.e.carpenter at gmail.com> Date: Tue, 12 Aug
 2014 08:26:19 +1200

 Well, that has been the case for a long time: see RFC 6294.

 I see the concern. 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.
 Therefore, treating RPL as a special case is the remaining option.
 But does the ROLL community actually have consensus that they want
 this special case?

    Brian

-- 
-------------------------------------------------+-------------------------
 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/6#comment:2>
6man <http://tools.ietf.org/wg/6man/>