On 3 July 2016 at 11:42, Mark Tinka <mark.ti...@seacom.mu> wrote: > > > On 2/Jul/16 17:35, Ruairi Carroll wrote: > > - ECMP issues (Mostly around flow labels and vendor support for that, also > feeds back into PMTUD issues) > > > Do you rely on the ToS field in IPv4 for ECMP? > > Nope. I use l4 tuple for flow hashing to make TCP happy. I was referring to two things:
- https://www.nanog.org/sites/default/files/wednesday.general.lotfi.mtu.6.pdf - https://tools.ietf.org/html/rfc7098 Core of the issue is that we _need_ to get an ICMP message back to the original "real server" who sent it. It's a non-issue in the SP space, but imagine if your ECMP groups were stateful in both directions... > - Maintaining 2x IP stacks is inherently expensive Vs 1 > > > How so? > Think about it in layers, with each little piece adding up to the overall cost: Implementation: - Numerous bugs in control plane features with v6 handling. - Numerous platform quirks which need time to be understood. Operational: - Need dev time to ensure applications are v6 ready. - Need SysAdmin time to evaluate kernel/userspace support and functionality - Need to maintain two sets of templates for config purposes - Need to maintain two sets of addressing policies Design: - Some switches are not suitable for v6 because of their multicast handling - Need extra time to validate designs will be v6 ready - Need engineers who understand v6 sufficiently to think in terms of Anycast and ECMP (Those who do it in v4 space are already thin on the ground) - Need engineers who understand v6 sufficiently to describe a good ACL/Firewall filtering. - Need engineers who understand v6 sufficiently to understand the peering/transit landscape (Which IS different from v4). I'll be the first one to say it sucks, but this is the reality of being a stub. My past implementation failures were all torpedo'd by lack of dev time/priority. /Ruairi > > > Mark. >