> The fallback is to only hash over addresses. Hashing over addresses+flow-label is fine too. If the flow label is zero, it's the same thing. If the flow label is set properly, it's a better hash.
I believe this is covered in the various relevant RFCs already (6437, 6438 and 7098). Regards Brian On 28/07/2018 10:38, Tom Herbert wrote: > On Fri, Jul 27, 2018 at 11:54 AM, Fernando Gont <fg...@si6networks.com> wrote: >> Tom, >> >> On 07/27/2018 07:20 PM, Tom Herbert wrote: >> [....] >>>> >>>> For example, what happens with EHs has a lot to do with engineering: >>>> they could be made to work (e.g., remove performance impact), but >>>> devices would probably be more expensive. Folks buying gear wouldn't pay >>>> for something that its not used in practice, and vendors wouldn't just >>>> "improve" the boxes for free. -- yeah, you could argue that "hey, there >>>> shouldn't be penalties for EHs, since they are part of the core IPv6 >>>> spec" -- but, while probably correct, that will not change reality. >>>> >>> Fernando, >>> >>> The irony is thatxtension headers (and alternative protocols as well), >>> including fragmentation, aren't supposed to have to "be made to work" >>> in intermediate devices. With the exception of Hop-by-Hop options they >>> are supposed to be ignored by design, and even in the case of >>> Hop-by-Hop options RFC8200 relaxed the requirements so that they can >>> be ignored. Extension headers are considered problematic only because >>> of ad hoc assumptions made for "value add", non-standard features >>> implemented in intermediate devices. >> >> Please see: >> <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03> >> >> theory != practice. And no matter how right you might be, that doesn't >> make the theory a reality. >> >> >> >>>> Not that I like the situation, but... I think the least we can do is to >>>> do a reality check wrt how things are supposed to work vs. how they >>>> actually work. >>>> >>>> For this particular case, this I-D makes that point for fragmentation: I >>>> I think we all agree that fragmentation is fragile -- making that point >>>> clear at least raises awareness of the problem, and might trigger some >>>> action on the topic (whether to correct the issue, or to circumvent it). >>>> >>> Right, but I still think that we should be more clear about the root >>> origin of problems and blunt in requesting that non-conformant >>> implementations get fixed. >> >> That is certainly not going to happen. From the pov of the folks >> operating the networks, there's nothing broken. >> >> >>> For instance, as I mentioned the ECMP >>> hasing problem with fragmentation is entriely solvable if only >>> intermediate devices will use flow label instead of trying to find >>> ports for a hash. >> >> Yes and no. There was at least a time in which the flow label wasn't set >> at all, or even was mistaenly set (e value during 3WHS, a different >> value afterwards). That means that you cannot really rely on it. If you >> cannot rely on it, you need a back-up mechanism. And that mechanism is >> inspecting the trasnport port numbers -- from that point of view, >> there's not much sense in dong ECMP with the FL if you cannot rely on it >> and somehow you'd have to be prepared to do it based on addresses and >> port numbers. > > The fallback is to only hash over addresses. Hashing over ports is not > reliable and can be problematic in itself. For instance, wrt > fragmentation, some middleboxes will use ports in the first fragment > but fall back to hashing over addresses for rest of fragments. This > mean the first fragment almost always takes a different path which can > wreak havoc on down stream devices that aren't expecting that. So > maybe it's another recommendation in this draft that middleboxes don't > use port information from first fragment to do load balancing. This is > another relatively easy fix. > > Tom > >> >> >>> Fixing devices to support this reasonable and should >>> be low cost. IMO, use of flow label for ECMP should be a strong >>> recommendation made in this draft. >> >> I wouldn't mind. However, that doesn't change the fact that >> fragmentation is fragile. >> >> That said, if you look at RFC7872, t all looks like anything that is EHs >> is dropped to some extent (while not included in the RFC, I also mesured >> IPsec, and you get similar numbers). So besides the issues that are >> specific to fragmentation, anything that is EHs gets dropped here an >> there. -- and ding ECMP with the FL will not change that. >> >> (Again: not that I'm happy with the situation... but being unhappy will >> not change reality anyway :-) ) >> >> Thanks, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fg...@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
