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 11:20 AM, Ole Troan <[e-mail]> wrote:

> 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.
>
> Ole,

Right, but of course there's never been any requirement in IP that packets
in a flow always follow the same path or are never received out of order.
Even outside of using the flow label there are other ways that that for
packets of a flow to take different paths or be OOO (fragmentation, UDP
encapsulation, routing change, etc.). I don't see that there is a protocol
problem with flow labels that would justify a general recommendation
against their use. Maybe there should be a discussion in v6ops about this.

Tom