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

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

On 21/10/2017 08:04, Ole Troan wrote:
> 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.
> 
> Absolutely. There is no protocol problem with flow labels.

When we did RFC6437, 6438 and 7098 we were perfectly aware of the deployment
issues. Fixing them is a long term play. There's background discussion in
https://tools.ietf.org/html/rfc6436

   Brian