Interworking & Migration¶

Most networks don't start from zero. Migrating from MPLS or SR-MPLS to SRv6 requires a clear strategy for coexistence during the transition. This page covers the common migration paths and interworking mechanisms.

Migration Strategies¶

Option 1: Greenfield (Clean Start)¶

New network built entirely on SRv6, no MPLS legacy.

Day 0: Deploy SRv6 from scratch
       No MPLS, no LDP, no RSVP-TE

Who chose this: Iliad (Italy), Rakuten Mobile (Japan), Telecom District (Mexico) — all started as new operators and deployed SRv6-only networks from day one.

Pros: Simplest architecture, no interworking complexity Cons: Only possible for new networks

Option 2: Parallel Overlay (Ship-in-the-Night)¶

Run SRv6 and MPLS as two separate planes on the same physical infrastructure:

┌─────────────────────────────────┐
│        Physical Network          │
│                                  │
│  ┌──────────┐  ┌──────────┐    │
│  │ MPLS     │  │  SRv6    │    │
│  │ Plane    │  │  Plane   │    │
│  │ (legacy) │  │  (new)   │    │
│  └──────────┘  └──────────┘    │
└─────────────────────────────────┘

1. Deploy SRv6 alongside existing MPLS
2. Migrate services one by one from MPLS to SRv6
3. Decommission MPLS when all services are migrated

Pros: Low risk, gradual migration, rollback possible Cons: Dual-stack complexity during transition

Option 3: SR-MPLS → SRv6 uSID (Incremental)¶

If you already have SR-MPLS, the migration to SRv6 is simpler because both share the SR architecture:

1. Phase 1: Deploy SR-MPLS (replace LDP/RSVP with segment routing)
2. Phase 2: Upgrade nodes to support SRv6 uSID
3. Phase 3: Enable SRv6 on upgraded nodes, use interworking for non-upgraded
4. Phase 4: Complete migration, disable SR-MPLS

Option 4: Direct MPLS → SRv6 (Skip SR-MPLS)¶

Some operators skip SR-MPLS entirely and go directly from traditional MPLS to SRv6 uSID. This avoids a double migration but requires more careful planning.

Who chose this: According to their public announcement, Telefonica VIVO went directly to SRv6 uSID to avoid double migration costs.

Interworking Mechanisms¶

SR-MPLS ↔ SRv6 Gateway¶

A gateway node translates between SR-MPLS and SRv6 at the domain boundary:

graph LR
    subgraph SR-MPLS Domain
        A[PE1] -->|MPLS Labels| B[P1]
    end

    B -->|SR-MPLS| GW[Gateway Node]

    subgraph SRv6 Domain
        GW -->|SRv6 SIDs| C[P2]
        C --> D[PE2]
    end

What the Gateway Does¶

1. SR-MPLS → SRv6: Receives MPLS packet, pops labels, encapsulates with SRv6 SRH
2. SRv6 → SR-MPLS: Receives SRv6 packet, decapsulates, pushes MPLS labels

BGP Multi-Domain¶

BGP can signal both SR-MPLS and SRv6 SIDs for the same VPN prefix, allowing the gateway to perform the translation:

BGP Update for prefix 10.0.0.0/24:
  ├── SR-MPLS Label: 24001
  └── SRv6 SID: fcbb:bb01:0002::DT4

Binding SID (BSID) for Cross-Domain¶

A Binding SID represents an entire SR Policy as a single SID. This enables stitching across domains:

Domain A (SR-MPLS): PE1 → BSID=24999 → Gateway
Domain B (SRv6):    Gateway → fcbb:bb01:0002::DT4 → PE2

The BSID at the gateway maps to the SRv6 segment list in Domain B.

VPN Service Interworking¶

For L3VPN and EVPN services spanning both domains:

MTU Considerations During Migration¶

SRv6 encapsulation adds overhead. During migration, you may have mixed MTU requirements:

Recommendation: Ensure all links in the SRv6 domain support at least 9100 bytes MTU (jumbo frames) to accommodate SRv6 encapsulation without fragmenting inner packets with a 1500-byte MTU.

Gateway Implementation Details¶

The gateway node is the linchpin of any SR-MPLS/SRv6 interworking deployment. It must maintain forwarding state for both data planes and perform real-time header translation at line rate.

Packet Walk: SR-MPLS to SRv6¶

The following diagram shows the step-by-step transformation of a packet crossing from an SR-MPLS domain into an SRv6 domain through a gateway node.

Ingress (SR-MPLS side)                          Egress (SRv6 side)
═══════════════════════                          ═════════════════════

  ┌─────────────────────┐                        ┌─────────────────────────────┐
  │ Transport Label: 16002│                       │ IPv6 Header                 │
  │ Transport Label: 16005│                       │   SA: fcbb:bb01:0100::      │
  │ VPN Label: 24001     │                        │   DA: fcbb:bb01:0002::DT4   │
  │ ──────────────────── │                        │ ─────────────────────────── │
  │ Inner IPv4 Packet    │                        │ Inner IPv4 Packet           │
  │   10.0.0.0/24        │                        │   10.0.0.0/24              │
  └─────────────────────┘                        └─────────────────────────────┘

         │                                                  ▲
         │  Step 1: Receive MPLS packet                     │
         │  Step 2: Pop all MPLS labels                     │
         │  Step 3: VPN label 24001 → lookup SRv6 SID       │
         │  Step 4: Encapsulate with IPv6 + optional SRH    │
         │  Step 5: Forward into SRv6 domain                │
         └──────────────────────────────────────────────────┘

Step-by-step breakdown:

Packet Walk: SRv6 to SR-MPLS (Reverse Direction)¶

The reverse direction mirrors the process:

Ingress (SRv6 side)                              Egress (SR-MPLS side)
═══════════════════                              ═════════════════════

  ┌─────────────────────────────┐                ┌─────────────────────┐
  │ IPv6 Header                 │                │ Transport Label: 16007│
  │   DA: fcbb:bb01:0100::E     │                │ VPN Label: 24050     │
  │ SRH (optional)              │                │ ──────────────────── │
  │ ─────────────────────────── │                │ Inner IPv4 Packet    │
  │ Inner IPv4 Packet           │                │   172.16.0.0/24      │
  └─────────────────────────────┘                └─────────────────────┘

         │                                                  ▲
         │  Step 1: Receive SRv6 packet at gateway SID      │
         │  Step 2: Decapsulate (remove IPv6 + SRH)         │
         │  Step 3: Look up destination → find MPLS labels   │
         │  Step 4: Push VPN label + transport labels        │
         │  Step 5: Forward into SR-MPLS domain              │
         └──────────────────────────────────────────────────┘

BGP Signaling at the Gateway¶

The gateway learns both MPLS labels and SRv6 SIDs for the same prefix through BGP multi-protocol extensions. A dual-stack PE (or the gateway itself acting as a route-reflector client) receives BGP VPN updates carrying both types of reachability information.

BGP VPNv4 Update from PE2 (SRv6-capable):
  Route Distinguisher: 65000:100
  Prefix: 10.0.0.0/24
  Next-Hop: fcbb:bb01:0002::
  Extended Community: RT 65000:100
  ├── Prefix-SID Attribute:
  │     SRv6 SID: fcbb:bb01:0002::DT4
  │     SID Structure: (block=32, node=16, function=16, arg=0)
  └── MPLS Label: 24001 (for SR-MPLS peers)

BGP VPNv4 Update from PE1 (SR-MPLS-only):
  Route Distinguisher: 65000:100
  Prefix: 172.16.0.0/24
  Next-Hop: 10.255.0.1
  Extended Community: RT 65000:100
  └── MPLS Label: 24050

The gateway maintains a cross-reference table that maps each VPN prefix to both its MPLS label and its SRv6 SID, enabling bidirectional translation:

Binding SID Deep Dive¶

The Binding SID (BSID) is one of the most powerful abstractions in the SR architecture, defined in RFC 9256 (SR Policy Architecture). It is essential for multi-domain migration.

What Is a Binding SID?¶

A BSID is a single SID (either an MPLS label or an SRv6 SID) that represents an entire SR Policy -- including all its segment lists, weighted paths, and constraints. When a packet is steered onto a BSID, the node that owns the BSID expands it into the full segment list of the associated policy.

Without BSID:
  Ingress PE must know the FULL path across all domains:
  [16001, 16002, 16005, fcbb:bb01:0002::1, fcbb:bb01:0003::DT4]
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     SR-MPLS segments              SRv6 segments

With BSID:
  Ingress PE only needs to know:
  [16001, 16002, 24999]
                 ^^^^^
            BSID at gateway — represents the entire SRv6 path

Why BSID Is Critical for Migration¶

BSID provides domain isolation: neither domain needs to understand the other's SID format, addressing scheme, or internal topology.

BSID Stitching Across Domains¶

In a multi-domain network, each domain boundary has a gateway that owns a BSID. Traffic is stitched from one domain to the next by chaining BSIDs:

graph LR
    PE1[PE1<br/>SR-MPLS] -->|"Label stack: [16002, BSID-A]"| GW1[Gateway 1<br/>BSID-A = 24999]
    GW1 -->|"SRv6: [fcbb:bb01:0005::1, BSID-B]"| GW2[Gateway 2<br/>BSID-B = fcbb:bb02:0001::PE]
    GW2 -->|"Final SRv6 SID list"| PE2[PE2<br/>SRv6]

1. PE1 pushes [16002, BSID-A(24999)] -- transport to Gateway 1, then the BSID
2. Gateway 1 receives the packet, matches BSID-A (24999), and expands it into the SRv6 segment list for Domain B: [fcbb:bb01:0005::1, BSID-B]
3. Gateway 2 receives the packet, matches BSID-B, and expands it into the final SRv6 segments to reach PE2

BSID Allocation: Static vs Dynamic¶

Worked Example: SR-MPLS Traffic Hitting a BSID¶

Consider traffic from an SR-MPLS domain that needs to reach 10.0.0.0/24 behind PE2 in the SRv6 domain:

1. PE1 (SR-MPLS) receives customer traffic for 10.0.0.0/24
2. BGP next-hop resolves to Gateway via SR-MPLS transport
3. PE1 pushes label stack:
     ┌──────────────────────────┐
     │ Transport: 16005 (to GW) │
     │ BSID: 24999              │  ← represents SRv6 SR Policy to PE2
     │ ======================== │
     │ Customer IPv4 packet     │
     └──────────────────────────┘

4. Packet arrives at Gateway, transport label already popped (PHP)
5. Gateway processes BSID 24999 → expands into SRv6 SR Policy:
     ┌─────────────────────────────────────┐
     │ IPv6 SA: fcbb:bb01:0100::           │
     │ IPv6 DA: fcbb:bb01:0005::1          │  ← first SRv6 segment
     │ SRH: [fcbb:bb01:0002::DT4]          │  ← remaining segments
     │ =================================== │
     │ Customer IPv4 packet                 │
     └─────────────────────────────────────┘

6. Packet traverses SRv6 domain using standard SRv6 forwarding
7. PE2 processes End.DT4 → decapsulates and delivers to VRF

Control Plane Coexistence¶

During migration, the control plane must advertise reachability information for both SR-MPLS and SRv6 simultaneously. This section covers how IS-IS and BGP handle dual data-plane coexistence.

IS-IS with Dual SR Data Planes¶

IS-IS can advertise both SR-MPLS Prefix-SIDs and SRv6 Locators in the same IGP instance. There is no need to run separate IS-IS instances for each data plane.

IS-IS LSP from Node R5 (dual-stack capable):
  ├── TLV 135 (IPv4 Reachability):
  │     Prefix: 10.255.0.5/32
  │     Sub-TLV: Prefix-SID = 16005 (MPLS label = SRGB base + 5)
  │
  └── TLV 236 (IPv6 Reachability):
        Prefix: fcbb:bb01:0005::/48
        Sub-TLV: SRv6 Locator
          Algorithm: 0
          SRv6 End SID: fcbb:bb01:0005::1

BGP Multi-Protocol: Dual SID Signaling¶

BGP VPNv4/VPNv6 and EVPN routes can carry both MPLS labels and SRv6 SIDs simultaneously, enabling the gateway to choose the appropriate encapsulation based on the egress domain.

BGP VPNv4 Update (dual-stack PE advertising both):
  ├── NLRI: RD:65000:100 10.0.0.0/24
  ├── Next-Hop: 10.255.0.2 (IPv4) / fcbb:bb01:0002:: (IPv6)
  ├── Extended Communities:
  │     Route Target: 65000:100
  ├── MPLS Label: 24001
  └── SRv6-VPN SID TLV:
        SRv6 SID: fcbb:bb01:0002::DT4
        SID Behavior: End.DT4 (63)
        SID Structure: BL=32, NL=16, FL=16, AL=0

Preference and Fallback Logic¶

When a node has both SR-MPLS and SRv6 paths available for the same destination, a preference mechanism determines which is used:

! Example: IOS XR preference configuration concept
router bgp 65000
  address-family vpnv4 unicast
    ! Prefer SRv6 transport when available
    transport prefer srv6
    ! Fall back to SR-MPLS if SRv6 path is unavailable
    transport fallback sr-mpls

SID Allocation Planning¶

A well-designed SID allocation plan is critical for a successful SRv6 deployment. Poor planning leads to renumbering, operational complexity, and scaling limitations.

Choosing Your SID Block¶

Per RFC 9602, the recommended SRv6 SID block ranges are:

Locator Structure¶

The SRv6 locator is structured as follows per RFC 8986 and RFC 9800:

|<---------- Locator ---------->|<-- Function -->|<- Argument ->|
|<-- Block -->|<---- Node ----->|                |              |
|   B bits    |     N bits      |    F bits      |   A bits     |
|             |                 |                |              |
 fcbb:bb01   :     0005        :     0001       :   0000
 (32 bits)       (16 bits)        (16 bits)        (variable)

uSID Considerations¶

For uSID (micro-SID) deployments as defined in RFC 9800, the structure changes significantly:

Standard SRv6 SID (128-bit):
|<--- Locator (48-bit) --->|<- Function (16-bit) ->|<- Args (64-bit) ->|
  fcbb:bb01:0005              :0001                   :0000:0000:0000

uSID Container (128-bit, carrying up to 6 micro-SIDs):
|<- Block (32-bit) ->|<----- 6 x 16-bit uSIDs ------>|
  fcbb:bb01            :0005:0007:0003:0002:0000:0000
                        ^^^^  ^^^^  ^^^^  ^^^^
                        uSID1 uSID2 uSID3 uSID4  (2 slots empty = end)

Numbering Plan Example: Medium Network (100 Nodes)¶

The following allocation plan covers a medium-size service provider with 100 nodes across 4 regions:

SRv6 Block: fcbb:bb01::/32  (uSID block)

Region allocation (bits 33-40 = region ID):
  Region 1 (Core):        fcbb:bb01:01XX::/40   (nodes 0x0100 - 0x01FF)
  Region 2 (East):        fcbb:bb01:02XX::/40   (nodes 0x0200 - 0x02FF)
  Region 3 (West):        fcbb:bb01:03XX::/40   (nodes 0x0300 - 0x03FF)
  Region 4 (Data Center): fcbb:bb01:04XX::/40   (nodes 0x0400 - 0x04FF)

Per-node function allocation (16-bit function space):
  0x0001       End (node SID)
  0x0002       End.X (adjacency SID, link 1)
  0x0003       End.X (adjacency SID, link 2)
  0x0010-001F  End.DT4 (L3VPN v4, up to 16 VRFs)
  0x0020-002F  End.DT6 (L3VPN v6, up to 16 VRFs)
  0x0030-003F  End.DT2U (EVPN unicast)
  0x0040-004F  End.DT2M (EVPN multicast)
  0x0050-005F  Flex-Algo End SIDs (Algo 128-143)
  0xFE00-FEFF  Reserved for BSID (static)
  0xFF00-FFFF  Reserved for future use

Example node assignments (Region 1 -- Core):

Common Mistakes to Avoid¶

Migration Phases (Detailed)¶

This section expands the high-level migration options into a structured, phased approach with specific actions, verification steps, and rollback plans for each phase.

Phase 0: Assessment and Planning¶

Objective: Understand the current state and design the target architecture.

Verification: Review the plan with network operations, get sign-off from stakeholders.

Rollback: N/A -- this phase is planning only.

Phase 1: Parallel Deployment (SRv6 Underlay)¶

Objective: Enable SRv6 on the network alongside MPLS. No production traffic uses SRv6 yet.

Actions:
  1. Enable IPv6 on all core links (if not already enabled)
  2. Advertise SRv6 locators in IS-IS (TLV 236)
  3. Continue advertising SR-MPLS Prefix-SIDs (TLV 135)
  4. Configure SRv6 End SIDs on upgraded nodes
  5. Do NOT configure any SRv6 VPN services yet

Verification checklist:

• All upgraded nodes advertise their SRv6 locator in IS-IS
• show segment-routing srv6 sid shows allocated SIDs on each node
• SRv6 locators are reachable via IPv6 ping from all nodes in the domain
• SR-MPLS forwarding is completely unaffected -- verify with traffic counters
• IS-IS adjacencies are stable, no SPF churn

Rollback: Remove SRv6 locator advertisements from IS-IS. Remove SRv6 SID configuration from nodes. This has zero impact on production MPLS traffic since no services use SRv6 yet.

Phase 2: Service Migration¶

Objective: Migrate VPN services from SR-MPLS to SRv6 transport, starting with non-critical services.

Migration order (recommended):
  1. Internal/management VPNs (lowest risk)
  2. Non-revenue L3VPN customers (test accounts, lab VPNs)
  3. Standard L3VPN customers (one at a time)
  4. EVPN services
  5. TE-dependent services (last, most complex)

For each service migration:

Verification:

• show bgp vpnv4 unicast vrf CUST-A shows SRv6 SID in the best path
• Traffic counters on SRv6 interfaces are incrementing
• Customer-facing SLAs are met (latency, jitter, packet loss)
• No MPLS-encapsulated traffic for the migrated VRF remains

Rollback: Revert the transport preference to SR-MPLS. Since both MPLS labels and SRv6 SIDs are advertised during the transition, traffic immediately falls back to MPLS. This is a sub-second switchover if using BGP next-hop tracking.

Phase 3: Optimization¶

Objective: Enable advanced SRv6 features and optimize the network.

Verification:

• uSID forwarding works: packets traverse multiple hops with a single 128-bit container SID
• Flex-Algo paths are computed and installed correctly
• No RSVP-TE tunnels remain in the forwarding table
• End-to-end service validation passes for all VPN customers

Rollback: Each optimization can be rolled back independently. For example, disabling Flex-Algo only affects traffic using those algorithms; default algo 0 traffic is unaffected.

Phase 4: MPLS Decommission¶

Objective: Remove all MPLS forwarding state from the network.

Decommission order:
  1. Remove LDP configuration (if any LDP sessions remain)
  2. Remove RSVP-TE configuration
  3. Remove SR-MPLS Prefix-SID advertisements from IS-IS
  4. Remove SRGB/SRLB configuration
  5. Disable MPLS forwarding on interfaces
  6. Clean up any MPLS-specific ACLs, QoS policies, OAM

Verification:

• show mpls forwarding-table is empty on all nodes
• No LDP or RSVP-TE sessions exist
• IS-IS no longer carries any SR-MPLS Prefix-SID TLVs
• All services continue to operate over SRv6
• Monitoring confirms zero MPLS-encapsulated packets on any link

Rollback: Re-enable SR-MPLS Prefix-SIDs in IS-IS and MPLS forwarding on interfaces. Since BGP VPN routes can carry MPLS labels again once advertised, services can be reverted to MPLS transport. However, this rollback requires careful re-configuration, which is why a thorough soak period before Phase 4 is essential.

Brownfield Coexistence Patterns¶

Pattern 1: Core-First Migration¶

Upgrade core/backbone routers to SRv6 first, keep edge on SR-MPLS:

[Edge SR-MPLS] → [Core SRv6] → [Edge SR-MPLS]
                  Gateway at boundary

Pattern 2: Edge-First Migration¶

Upgrade edge/PE routers first, keep core on SR-MPLS:

[Edge SRv6] → [Core SR-MPLS] → [Edge SRv6]
               Gateway at boundary

Pattern 3: Region-by-Region¶

Migrate one region at a time:

[Region A: SRv6] ↔ Gateway ↔ [Region B: SR-MPLS] ↔ Gateway ↔ [Region C: SRv6]

Further Reading¶

• SRv6 vs SR-MPLS - Detailed comparison
• uSID / SRv6 Compression - How uSID reduces overhead
• Performance & Scaling - MTU impact analysis
• Real-World Deployments - Migration stories

References¶

1. RFC 8402 - Segment Routing Architecture - Defines the SR architecture covering both SR-MPLS and SRv6 data planes
2. RFC 9256 - SR Policy Architecture - Defines Binding SID and multi-domain SR Policy stitching
3. RFC 9602 - Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture - IANA allocation of the 5f00::/16 SRv6 SID block
4. RFC 9800 - Segment Routing over IPv6 with Micro-Segments - Defines the uSID (micro-SID) architecture for compressed SRv6
5. RFC 8986 - SRv6 Network Programming - Defines SRv6 SID structure, behaviors (End, End.DT4, End.DX2, etc.)
6. draft-ietf-spring-srv6-interop - SRv6 interoperability considerations