nanog mailing list archives

RE: [c-nsp] LDPv6 Census Check


From: <adamv0025 () netconsultings com>
Date: Tue, 16 Jun 2020 13:24:08 +0100

From: Mark Tinka <mark.tinka () seacom mu>
Sent: Tuesday, June 16, 2020 12:09 PM

On 16/Jun/20 12:00, adamv0025 () netconsultings com wrote:

Hence my earlier comment on why I think it's not commercially feasible
to switch to v6 control plane,

Personally, I've never been a fan of a single-stack backbone. I can, however,
understand the use-case where a new or growing network is unable to
obtain anymore IPv4 space and don't want to use RFC 1918 space (yuck!).

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


 (the only thing I'd be getting is MPLS-IPv6 which I already have (or
have had) via L3VPN-6VPE),

Well, not quite.

What you currently have with 6PE is IPv6 tunneled inside MPLSv4 which runs
over IPv4. While you get the benefits of MPLS forwarding for your
IPv6 traffic, you now create a condition where your IPv6 network is in the
hands of your IPv4 network. Granted, there are many folk that run 6PE, so
whether the fate-sharing is of concern to you or not is an exercise left up to
the reader. Personally, I'd rather avoid fate-sharing whenever I can.

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). 

On the other hand, MPLSv6 is native, runs over IPv6 and does not depend on
IPv4 at all.

Ultimately, plenty of energy will need to go into supporting the additional
VPN services that go beyond plain-old MPLSv6 switching. But that can only be
promoted with the vendors after we jump the first hurdle of deploying the
1st application, basic MPLSv6 switching; get that widely adopted, and create
more awareness within the vendor community about its overall viability.

80% of our network currently runs LDPv6 and switches IPv6 traffic in MPLSv6.
Our immediate task is to get the remaining 20% supported (IOS
XE) as well.


But I'm thankful to you for doing the "ice breaking" for the rest of the
community.

As Eriq La Salle unashamedly claimed in the 1988 Eddie Murphy picture,
Coming to America, "You know me, anything for the kids :-)".

That was a good movie :D :D :D

adam



Current thread: