[c-nsp] LDPv6 Census Check

[Mark Tinka]

On 16/Jun/20 14:24, adamv0025 at netconsultings.com wrote:

> Actually I was exactly I that situation and v4 RFC 1918 space worked out just fine.

In that way, you are braver than me. But hey, if you need IPv4 and can't
get the public stuff, I won't fault you for going with the private stuff
:-).


> I've been dependent solely on v4 all my life and I still am. 
> But I see your fate-sharing argument, similar to my argument around separate iBGP infrastructure (Route-Reflector plane) for Internet vs for other customer private VPN prefixes. 
> But in the multiplanar iBGP case one plane is statistically more likely to fail than the other, whereas in case of v4 vs v6 control plane I'd say it's actually the NEW v6 that's more likely hiding some unforeseen bug. 
> So let me ask the following "devil's advocate" type of question, under the assumption that the LDPv6 is a new thing (not as proven as LDPv4), are you taking dependency away by splitting control plane to v4 and v6 or actually adding dependency - where the NEW v6 control plane components could negatively affect the existing v4 control plane components after all they share a common RE (or even RDP in Junos). 

Well, that's a bottomless rabbit hole that go could all to the way to
the data centre providing A+B power feeds, but connected to a single
grid on the outside. At some point, redundancy stops making sense and
eats into your margins as much as it does your sanity :-).

But back to the question at hand, even with 6PE, you can't avoid running
a dual-stack network... you'd need to at the edge. So if your goal is to
use 6PE to avoid running IPv6 in some native form anywhere in your
network, that won't work out, as I'm sure you know :-).

But more importantly, I, as have many others on this group, have been
running IPv6 since about 2003 (others, even longer, I'm sure). IPv6, in
and of itself, has never been an issue for me. The problems have always
been the ancillary services that need to run on top of it in order to
work. For the past 17 years, my IPv6 headaches have been about feature
parity with IPv4, mostly, in routers and switches (in general-purpose
server OS's too, but those got fixed much more quickly):

  * DNS over IPv6 took a while to arrive.
  * TACACS+ over IPv6 took a while to arrive.
  * IPv6 ACL's took a while to get proper support.
  * SNMP over IPv6 took a while to arrive.
  * NTP over IPv6 took a while to arrive.
  * SSH over IPv6 took a while to arrive.
  * OSPFv3 Authentication was very clunky.
  * Multi Topoloy IS-IS support was very clunky.

You get the idea.

I've always operated a native dual-stack network, so having to go back
and upgrade routers every so often when one of the above limitations got
fixed in a later revision of code was tiresome, but worthwhile. We take
a lot of these things for granted in 2020, but it was no joke more than
a decade ago.

So for me, I've never really experienced any problems from basic IPv6
that have negatively impacted IPv4.

The corner case I am aware of that didn't even bother IPv4 was Ethernet
switches and some popular Chinese GPON AN's that silently dropped
Ethernet frames carrying IPv6 packets because they did not know how to
handle the 0x86DD EtherType. But AFAIK, these have all been since fixed.

So based on pure experience, I don't expect this "32-year old new IPv6"
thing to be hiding some unforeseen bug that will break our IPv4 network :-).

LDPv6 was first implemented in IOS XR, Junos and SR-OS in 2015/2016, so
it has been around for a while. The biggest challenge was with IOS XR in
2015 (5.3.0) which didn't support dual-stack TLV's. So if the LDP
neighbor negotiated LDPv4 and LDPv6 in the same LDP session, IOS XR
didn't know what to do. It could do LDPv4-only or LDPv6-only, and not
both. That issue was fixed in IOS XR 6.0.1, when the Dual-Stack
Capability TLV feature was introduced. That was May of 2016, so also not
that new.

Mark.