From: Mark Tinka <mark.tinka@seacom.mu> Sent: Thursday, June 11, 2020 3:59 PM
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.
Right I see what you are striving to achieve is migrate from BGP in a core to a BGP free core but not leveraging 6PE or 6VPE?
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.
So considering you already had v4 FECs wouldn't it be simpler to do 6PE/6VPE, what do you see as drawbacks of these compared to native MPLSv6 please?
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?
Well my point was that if v4 FECs would be enough to carry v6 traffic then I wouldn't need SRv6 nor LDPv6, hence I'm curious to hear from you about the benefits of v6 FEC over v4 FEC (or in other words MPLSv6 vs 6PE/6VPE). adam