On 3 July 2016 at 11:42, Mark Tinka <mark.tinka@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.