1. Why this test exists
The multivendor PoC (the companion document) proved that an L3VPN can run across Nokia, Cisco and Juniper on an SR-MPLS core, and it 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 for about 18 seconds, and the Juniper PE could not join the SRv6 service at all on its release. Those are real findings, but they left one question open. Were those outages caused by SRv6 migration itself, or by the specific interop and release gaps between three vendors?
This document answers that question with a control. We rebuilt the exact same ten-node flat topology, the same addressing, the same VRF, the same route reflector, but with every node running Cisco IOS-XR. If the migration is clean here and messy in the mixed lab, the mess is interop, not SRv6. The short answer: on the same topology and the same steps, the all-Cisco migration was hitless, end to end, and the difference is entirely explained by the two interop gaps and one topology-mode choice documented in the multivendor PoC.
2. Topology and addressing
Fig. 1. All-Cisco control topology: identical layout to the multivendor lab, homogeneous IOS-XR.