Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03

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

And my conclusion to 6MAN is that the changes of rules that are requested in the draft are useful whether or not people are willing to use the flow label as the transport for the RPL option inside the RPL domain. Since this is the question on the table for 6MAN, I think that the answer is now clearly a yes.
  
Left will be the conclusion on whether the use of the flow label to carry the RPL option is a good idea or not. I guess the answer belongs to ROLL and the last call there.
If Carsten's arguments prevail, I can extract the 6553 compression from the draft to keep the new rules separate from the particular usage of transporting 6553 flow information. 

Cheers,

Pascal


> -----Original Message-----
> From: Carsten Bormann [mailto:[e-mail]]
> Sent: jeudi 14 août 2014 13:29
> To: Pascal Thubert (pthubert)
> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;
> [e-mail] WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> >> I really would like to hear a technical argument why the flow label hack is
> needed.
> >
> > ? Then you probably missed most of my mail from yesterday ?
> > ? The sentence is a rhetorical abuse - like "our just cause" as opposed to
> "our cause is just" which can be argued -, and there is no consensus that the
> flow label technique is a hack ?
> 
> Oh, OK, I was using this as a technical term.  The Internet works because of a
> set of hacks piled on hacks.
> Generally, most people would agree that an instance of "there are some bits
> that aren't used very much - lets put our stuff there" is a hack.
> But we don't need consensus on that word, in particular if you perceive it as
> pejorative.
> 
> > For instance, the draft is asking 6MAN the right to reset a flow label at the
> ingress RPL domain. Without this right, a flow label coming from the Internet
> will be transported in the RPL domain or (more probably) implementation
> will voluntarily fail to conform 6437, and elide them regardless. I'd rather
> have a realistic rule that sets the expectations right.
> 
> OK.  That is a completely different thing.
> I certainly would support a "license to drop" draft that says "a highly
> constrained network can discard the information in flow labels".
> (Maybe with some more context.  Just as RFC 6282 allows discarding UDP
> checksums in certain well-defined cases.)
> 
> But that is not an argument at all for storing anything different in those 20
> bits.
> 
> > Another disagreement is on your assumption that compression is the only
> reason for preferring the flow label technique. We have an IOS
> implementation that is not for use in 6LoWPAN networks, and relies on the
> (stateful) storing mode. HbH has known issues in classical routers, makes the
> header chain longer and requires silicon processing or punt, so there are
> reasons not to use it there either. OTOH making a routing decision that takes
> the flow label into account is quite natural, this is what load balancers will
> do at the core. We have prototyped indexing the VRF with the RPL instance
> in the flow label, and it works like a charm.
> 
> Now it gets interesting.
> I have another draft whose main content could be summarized as "hop-by-
> hop options don't seem to work, now what".
> So why did we do RFC 6553?  That was a big mistake, no?
> We need to do the things hop-by-hop options were defined for, for a
> number of purposes.
> This is not being helped by usurping the last free 20 bits in the header for
> one, and only one, of those purposes.
> 
> > And even if compression is the reason why the flow label is used, RPL is a
> rather new routing protocol and we do not know what the world will make
> of it. For all I know it may be deployed in RoHC environments to aggregate
> femtocell traffic for instance. Assuming that the compression will always be
> 6LoWPAN is short sighted.
> 
> Since ROHC is all about flows, it indeed is very good in completely
> compressing away static flow labels.
> ROHC also is very good in completely compressing away static extension
> headers.
> I haven't done the math, but I don't see a winning argument here.
> In any case, my argument was that the header compression scheme should
> handle this, and, either way, ROHC already does!
> 
> More importantly, if RPL becomes applicable outside the constrained
> environment, the arguments that are being made about the requirements of
> (stubby) constrained environments no longer apply.
> 
> In any case: YAGNI.
> 
> > And there is no "politics", but external SDOs that base their work on our
> RFCs and that we need to treat with all respect. Facts:
> > - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a
> stateful indicator of the flow (called a contract ID). We need to be clear on
> how we position this WRT 6437 now that we shipped it. The draft makes
> that legal, as long as we extend the RPL domain to an ISA100 domain as well.
> 
> I don't know that a ISA100.11a contract ID is compatible with the proposed
> flow-label encoding of RFC 6553.
> But support for this usage could go with "license to drop" into a draft about
> constrained node network usage of flow labels.
> (In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing here;
> it mentions ISA100.11a only in the introduction.)
> 
> > - We can promote behaviors in WCI (e.g. reset the flow label to something
> valuable to the Internet at large at the backbone router) but then we need
> to document them in an RFC that they can reference.
> 
> That seems to be the above argument about "license to drop", which is
> again completely independent from the desire to compress RFC 6553.
> 
>                                   .oOo.
> 
> I won't continue belaboring this on the three mailing lists here.
> (One reason being that I'm going on vacation.)
> 
> My main point for 6man was that going down the "let's appropriate the flow
> label for this" route is not at all inevitable.
> (There also are some good contributions from this discussion for the ongoing
> quest for a good, deployable use for flow labels.)
> 
> For 6lo, the observation is that there is a place for header compression
> beyond RFC 6282, and that it is easy to get even better compression for RFC
> 6553 in the RFC 4944 framework.
> 
> For ROLL, my advice would be to take another look at RFC 6554, and see how
> that would be compressed in a 6lo context.  Most importantly, is there really
> a need for the "segments left" construction, or can the waypoints be
> discarded once visited.
> 
> Grüße, Carsten