[c-nsp] LDPv6 Census Check

Mark Tinka mark.tinka at seacom.mu
Thu Jun 11 14:58:54 UTC 2020



On 11/Jun/20 16:25, adamv0025 at netconsultings.com wrote:

> Good PR might ;)

I'm old school - build something customers want to use, and the money
follows.

Care to guess how much PR Tik Tok do :-)? But I digress.


> No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no point having them signalled also over v6 in parallel.

It's not about signaling IPv4 LSP's over IPv6.

LDPv4 creates IPv4 FEC's.

LDPv6 creates IPv6 FEC's.

The idea is to create IPv6 FEC's so that IPv6 traffic can be
label-switched in the network natively, allowing you to remove BGPv6 in
a native dual-stack core.


> Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, then might want to look at SR MPLS. 

No RSVP-TE here, thank the Lord :-).


> I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over v4...

Nothing like the real thing:

In IPv4-land, you get this:

24005  49017       105.16.Y.Z/32     Te0/0/0/2    105.16.A.B    8614773
            49017       105.16.Y.Z/32     Te0/1/0/0    105.16.C.D   8121753
            49017       105.16.Y.Z/32     Te0/7/0/5    105.16.E.F    9964543

In IPv6-land, you get this:

2c0f:feb0:X:Y::Z/128 25071   25458          BE1          Link-local
                                              25458         
BE2          Link-local


In Junos land, it looks like this:

7967               *[LDP/9] 1w5d 01:21:05, metric 1
                        >  to fe80::de38:e1ff:fe15:dc02 via ae2.0, Swap
145674

If I run an IPv6 traceroute toward a host that sits behind a router
doing LDPv6, this is what happens:

run traceroute 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
traceroute6 to 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
(2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ) from 2c0f:feb0:1:2::112, 64 hops
max, 12 byte packets
 1  ae-5-0.er6-01-fra.de.seacomnet.com (2c0f:feb0:1:2::111)  165.567 ms 
166.158 ms  166.924 ms
     MPLS Label=145786 CoS=0 TTL=1 S=1
 2  xe-0-0-0-0.cr6-02-mrs.fr.seacomnet.com (2c0f:feb0:1:2::f9)  165.682
ms 2c0f:feb0:1:2::279 (2c0f:feb0:1:2::279)  165.817 ms  168.123 ms
     MPLS Label=25494 CoS=0 TTL=1 S=1
<snip>

As you can see, just as with IPv4, IPv6 packets are now being
MPLS-switched in the core, allowing you to remove BGPv6 in the core and
simplify operations in that area of the network.

So this is native MPLSv6. It's not 6PE or 6VPE.

Your IPv4 domain could fall over and your MPLSv6 network will still be
alive, because it's neither 6PE nor 6VPE. And vice versa - your IPv6
network could die, and your MPLSv4 will be unaffected.


> I knew there's a bit of OCD hidden in this at some level :)

Safe to say the Internet is one big OCD project :-).

My OCD is sleeping at 3AM, in peace, lockdown or not, hehe.


> Apart from X months worth of functionality, performance, scalability and interworking testing -network wide code upgrades to address the bugs found during the testing process and then finally rollout across the core and possibly even migration from LDPv4 to LDPv6, involving dozens of people from Arch, Design, OPS, Project management, etc... with potential for things to break while making changes in live network.

Which you wouldn't have to do with SRv6, because you trust the vendors?

And no, LDPv6 does not call for one to migrate from LDPv4. They can live
together, side-by-side, just as native dual-stack IPv4/IPv6 does.

We are running LDPv4 and LDPv6 side-by-side, with no problems, between
IOS XR and Junos, as you can see above. This is a live network, carrying
revenue-generating, production traffic. It's not a fantasy.

Mark.


More information about the NANOG mailing list