1. Why this test exists
The multivendor PoC proved an L3VPN could run across Nokia, Cisco and Juniper on an SR-MPLS core, then tried to move that live service to SRv6. That migration was not clean: dual-stacking the underlay cost about 41 seconds, flipping a Cisco egress silently blackholed a Juniper peer, and the Juniper PE could not join the SRv6 service at all on its release. The all-Cisco control PoC then answered the obvious question by rebuilding the same topology on one vendor: there the migration was hitless end to end, which pinned every multivendor outage on named interop and release gaps rather than on SRv6.
That left one gap in the argument. The Cisco control proved a single vendor can migrate cleanly, but Cisco is the vendor whose defaults happen to favour the clean path. It carries SRv6 locators in a separate IS-IS multi-topology, so dual-stacking the underlay never touches the live IPv4 plane. Nokia defaults the other way. This document is the second control: the same ten-node flat topology, the same addressing, the same VRF and route reflector, with every node running Nokia SR OS. The question it answers is narrower and more useful than “does SRv6 migration work”. It is “what is actually fundamental to an SRv6 migration, and what is just each vendor’s topology-model choice showing through?”
The short answer, proven live below: the customer-service cutover is zero-downtime on Nokia, just as it is on Cisco, using a make-before-break model that is arguably the safest of the three vendors. The one difference is the underlay step, and it is not a defect. Nokia carries SRv6 locators in the native IPv6 topology rather than in a separate multi-topology, so a real SRv6 underlay requires enabling native IPv6 routing, which re-runs the shared SPF once. On this simulator that reconverge was measurable; on hardware it is a planned, near-hitless event. Everything else about the migration was hitless.