IPv6 deployment excuses

Sun Jul 3 10:01:11 UTC 2016

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