<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 16/Jun/20 14:24,
<a class="moz-txt-link-abbreviated" href="mailto:adamv0025@netconsultings.com">adamv0025@netconsultings.com</a> wrote:<br>
<br>
</div>
<blockquote type="cite"
cite="mid:8f8001d643d9$092bd4c0$1b837e40$@netconsultings.com">
<pre class="moz-quote-pre" wrap="">Actually I was exactly I that situation and v4 RFC 1918 space worked out just fine.</pre>
</blockquote>
<br>
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 :-).<br>
<br>
<br>
<blockquote type="cite"
cite="mid:8f8001d643d9$092bd4c0$1b837e40$@netconsultings.com">
<pre class="moz-quote-pre" wrap="">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). </pre>
</blockquote>
<br>
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 :-).<br>
<br>
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
:-).<br>
<br>
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):<br>
<ul>
<li>DNS over IPv6 took a while to arrive.</li>
<li>TACACS+ over IPv6 took a while to arrive.</li>
<li>IPv6 ACL's took a while to get proper support.</li>
<li>SNMP over IPv6 took a while to arrive.</li>
<li>NTP over IPv6 took a while to arrive.</li>
<li>SSH over IPv6 took a while to arrive.</li>
<li>OSPFv3 Authentication was very clunky.</li>
<li>Multi Topoloy IS-IS support was very clunky.<br>
</li>
</ul>
<p>You get the idea.</p>
<p>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.</p>
<p>So for me, I've never really experienced any problems from basic
IPv6 that have negatively impacted IPv4.</p>
<p>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.</p>
<p>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 :-).</p>
<p>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.<br>
</p>
<p>Mark.<br>
</p>
</body>
</html>