Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

[Ole Troan <[e-mail]>]

Hi Tom,

> >>> Problem with flow label is same as with hop-by-hop option: burned because
> >>> nobody should dare use it for something useful with all the inconsistent
> >>> code out in the field.  Nothing against redefining it (with new encoding)
> >                                                          ^^^^^^^^^^^^^^^^^^^
> >> There is no encoding. It's 20 opaque bits (and always has been). Please
> >> read https://tools.ietf.org/html/rfc6437.
> >
> > Sorry, lame use of words. Meant to say "stronger definition of DO and DONTs
> > which may include new semantics". I never tried to analyze the state of
> > affairs on flow label as i did for router alert. Just taking it from what
> > i heard, last from Joel at the pechakucha.
> 
> Right. If we take Joel's findings, then it appears the conclusion is that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too high probability for failure. It would be very nice to have that fixed. Until then, we're forcing routers to parse transport headers.
> 
> Ole,
> 
> I cannot find this presentation. I did find a presentation to nanog about problems with flow labels, but that had more to do with the fact that the flow label does not have to be persistent for the life of a connection which breaks stateful firewalls that require consistent routing for a flow. I didn't see how this is a problem for ECMP itself. Is there a draft on this that details what the problems are?

I believe Joel's presentation was for a load balancer application.

Purely for ECMP it only has a consequence for reordering of packets. Which may be bad enough.
But sending packets of the same flow along different paths has problems with any network function that requires state. NAT64, virtual reassembly of fragments, ACLs and what not. Not that the network should do any of those of course.

Best regards,
Ole