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

[Tom Herbert <[e-mail]>]

On Fri, Oct 20, 2017 at 7:58 AM, Ole Troan <[e-mail]> wrote:

> Toerless,
>
> >>> 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?

Tom