Re: [Roll] using the flow label instead of hop by hop

[Philip Levis <[e-mail]>]

On Oct 24, 2012, at 9:08 AM, Brian E Carpenter wrote:

> On 24/10/2012 15:40, Ralph Droms wrote:
>> Seems to me this conversation ought to include 6man fairly soon.
> 
> If ROLL wants to go this way, I agree. I *think* the proposal does
> no violence to the 6man RFCs, but that's only my opinion.
> 
>   Brian

Brian,

My thought process is simple. From my reading, the proposal violates RFC6437:

 "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1."

Its seems to me that using the flow label as more efficient representation of a hop-by-hop option isn't a "compelling operational security reason." It's an optimization. There hasn't yet been any evidence or data presented on the potential efficiency benefits this will have (hand-waving "energy" is not evidence). Adding *more* complexity to RPL though an alternative representation of the hop-by-hop header seems to me to add complexity without much benefit. If there were evidence indicating that in a large number of operational scenarios this optimization would lead to a significant savings, then that might be compelling. But my experience is that the overall benefit of this compression is going to be minimal. Using the flow label in a way which someone reading RFC6437 would not guess or assume is problematic from an interoperability standpoint. So, significant possible cost in terms of interoperability, significant cost in terms of increased complexity, minimal gain in terms of performance.

If 6man obsoletes RFC6437 such that this proposed use doesn't violate a MUST, then I'd be all ears. RFC6437 does say that you MAY modify a flow label of zero (so routers may fill it in for end hosts that not do so), says that the end host SHOULD set it to a non-zero value, and that nodes MUST keep non-zero labels unchanged. I don't want to repeat the headache that NATs introduced by violating end-to-end in an unanticipated way.

Phil

------

Philip Levis
President, Kumu Networks
Associate Professor, Stanford University
http://csl.stanford.edu/~pal