Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[joel jaeggli <[e-mail]>]

On 11/3/12 3:38 AM, Brian E Carpenter wrote:
> On 02/11/2012 20:01, joel jaeggli wrote:
>> On 11/1/12 4:16 AM, Ole Trøan wrote:
>>>>>>> Yes, but the whole point of the IPv6 option architecture was to avoid
>>>>>>> the issues seen with IPv4 options.
>>>>>> The only thing in that IPv6 would avoid is requiring routers to parse
>>>>>> *all* options, just to find the ones that need to be processed by
>>>>>> routers.
>>>>> Yes.
>>>> No. The only extension header that *needs* to be parsed by intermediate
>>>> routers is the hop-by-hop options header, and that is the first one (if
>>>> present).
>>>>
>>>> (You can legitimately argue that the hbh header and the routing header
>>>> are effectively useless, but that doesn't break fundamental
>>>> connectivity.)
>>>>
>>>> IPv6 routers should have nothing to do with fragmentation.
>> That horse left the barn when we use L4 headers as part of a
>> load-balancing hash key.
>>
>> While the potential for reordering due to differing path selection is
>> superficially irrelevant in the core (I do have four 4 ECMPed
>> cross-country paths in the US with about 12ms difference in rtt between
>> the shortest and longest), when fronting a stateful device like load
>> balancer(s) or firewall(s)  it is not.
>>
>> Now, if the flow label were reliably immutable and non-zero it might be
>> a suitable replacement for the L4 header in the hash calculation.
> So, ask your suppliers to implement RFC 6437/6438. It's the best we can do.
Unfortunately I have a network to run in the interim.
>     Brian
>
>