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

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

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

> Le 10 août 2014 à 18:29, "Carsten Bormann" <[e-mail]> a écrit :
> 
> 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
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll