On 16/Jun/20 14:24, adamv0025@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):

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.