On 11/Jun/20 16:25, adamv0025@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.