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

[Brian E Carpenter <[e-mail]>]

On 25/10/2012 19:00, Philip Levis wrote:
> 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."

I have to say it's a while since I read the draft all through, but I seemed
to remember that the packet would always be encapsulated in an outer packet,
in which case there is no problem if the outer packet's flow label is
set locally and vanishes at the ROLL boundary. If not, then yes, there's
a violation.

> 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 ter
ms 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.

I think it would be entirely possible (I am not particularly advocating this)
for RFC-roll to formally update RFC 6437 for this particular usage. Speaking
purely personally, I wouldn't oppose this, although others might object.

The reason I wouldn't oppose it is that the idea is that on the open
Internet, any forwarding device should be able to use the flow label
for ECMP, LAG or some other kind of load balancing. If the label is
set according to RFC 6437 at a well-defined point (such as the ROLL/Internet
boundary), this would be satisfied. Yes, I am being a bit heretical
about my own RFC ;-).

   Brian


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