SRv6 Deployment Options

4.1. Overlay

With an overlay model, one technology runs on top of the other. The underlying network provides transport, while the overlay provides services. With SRv6 over MPLS, SRv6 packets are encapsulated in MPLS (e.g., in a brownfield migration scenario). SRv6 is deployed as an overlay on top of an existing MPLS transport network. The underlying network remains unchanged, and SRv6 tunnels are encapsulated over the infrastructure. Overlays are useful for gradual migration, allowing operators to introduce SRv6 services without disrupting the existing MPLS/IP core and only minimal changes to the existing network. This allows early adoption of SRv6 features (e.g., network programming, service chaining). There is some overhead due to additional encapsulation (SRv6 headers over MPLS/IP) and it does not fully leverage native SRv6 capabilities in the data plane. It's a common migration technique because migration is fairly easy, it works with existing IPv4 MPLS networks, provides incremental deployment with only the services provider edge (PE) routers needing SRv6 upgrades. Core network routers can remain IPv4 MPLS (or SR-MPLS) while the rest of the network is transitioning to SRv6.¶

For instance, we could utilize a IPv6 provider edge (6PE) overlay if the backbone does not support IPv6. SRv6 services on transit nodes are forwarded through IPv6 over MPLS. 6PE is an MPLS-based overlay mechanism that allows IPv6 traffic to be transported over an IPv4/MPLS core network without requiring IPv6 support on core (P) routers. It leverages MP-BGP and MPLS label stacking to tunnel IPv6 packets across an existing IPv4/MPLS infrastructure. Edge routers connect IPv6 islands and encapsulate IPv6 in MPLS. When it’s challenging to provision dual stack on the core network, a 6PE (or L3VPN, L2VPN, etc) overlay could be used as a transition while retaining the capability to evolve to SRv6 in the future. BGP is used to advertise the SRv6 locator and loopback routes of the ingress and egress.¶

The following diagram depicts using 6PE as the MPLS overlay between SRv6 capable PE nodes:¶

             +--+   +--+                  +--+   +--+
             |PE|   |P |       MPLS       |P |   |PE|
             +--+   +--+                  +--+   +--+

               |      |        6PE         |      |
               |      +--------------------+      |
               |                                  |
               |               SRv6               |
               +----------------------------------+

4.2. Ships-In-The-Night

This solution is a straightforward and popular deployment option. Ships-in-the-Night is a technique that allows all routers to run multiple routing processes at once. SRv6 and MPLS operate independently in the same network without interaction. They coexist as separate "ships in the night," with no interworking between them. This technique is commonly used with IPv4 and IPv6 and can also be used with MPLS and SRv6. IPv4 and IPv6 are separate protocols and can't work together without some form of translation mechanism and same is true for MPLS and SRv6. As with MPLS and SRv6, networks run dual stack where both IPv4 and IPv6 run over the same infrastructure as ships-in-the-night.¶

Ships-in-the-Night is suitable for networks where SRv6 and MPLS serve different purposes (e.g., MPLS for existing VPNs, SRv6 for new services). Complete isolation, of the two control and data planes, avoids interoperability issues and provides flexibility to deploy SRv6 incrementally.¶

There are drawbacks to running protocols ships-in-the-night such as inefficient resource usage (parallel control planes and data planes) and no synergy between the two technologies. Some routers may struggle with simultaneous MPLS + SRv6. Managing two control planes increases overhead. Some operators prefer gradual migration (Overlay) rather than parallel operation. Maintaining two protocols may introduce additional security vulnerabilities if not managed correctly. Dual-stack networks have an increased attack surface because of both IPv4 and IPv6 being maintained. This may also be true with MPLS and SRv6. The cost of maintaining both networks can be prohibitive as well. Managing and configuring two separate networks can be complex. Ships-in-the-night networks can consume more memory and processing power on networking devices.¶

The following diagram depicts using Ships-in-the-night SRv6 and MPLS over the same infrastructure:¶

            +----------------+         +----------------+
            |    SRv6 Node   |         |    MPLS Node   |
            | (IPv6/Segment  |         | (Label-Switched|
            |    Routing)    |         |     Path)      |
            +-------+--------+         +-------+--------+
                    |                           |
            (SRv6 over IPv6 Dataplane)          |
                    |                           |
                    v                           v
            ============================================
            ||        Shared Physical Network         ||
            || (e.g., Fiber, Ethernet, or IP Backbone)||
            ============================================
                    ^                           ^
                    |                           |
                    |                (MPLS over LDP/RSVP)
                    |                           |
            +-------+--------+         +-------+--------+
            |    SRv6 Node   |         |    MPLS Node   |
            +----------------+         +----------------+

4.3. Interworking between MPLS and SRv6

Another migration strategy is to allow an existing MPLS network to interwork with SRv6, rather than only run ships-in-the-night or overlay. [I-D.ietf-spring-srv6-mpls-interworking] describes SRv6 and MPLS/SR-MPLS interworking procedures which can roughly be compared to translation solutions such as NAT or 464XLAT. This strategy enables interworking between SRv6 and MPLS domains. Translation mechanisms (e.g., Segment Routing Mapping Server or SRMS) are used to map SRv6 SIDs between the two domains. This option allows hybrid operation (e.g., SRv6 at the edge, MPLS in the core). Interworking requires additional control-plane mechanisms for SID translation and may add complexity in managing two different forwarding paradigms. New SRv6 behaviors, and MPLS labels, stitch the end to end path across different data planes. The interworking document assumes SR-MPLS-IPv4 for MPLS domains but the design equally works for SR-MPLS-IPv6, LDP-IPv4/IPv6 and RSVP-TE-MPLS label binding protocols. It provides transport interworking solutions such as SRv6 over MPLS (6oM) and MPLS over SRv6 (Mo6) along with service interworking solutions such as SRv6 to MPLS(6toM) and MPLS to SRv6 (Mto6).¶

Using a gateway is an Interworking (IW) example which supports both BGP SRv6 based L2/L3 services and BGP MPLS based L2/L3 services for a service instance. It terminates service encapsulation and performs L2/L3 destination lookup in a service instance:¶

+-------------------+                             +-------------------+
|   ....|S-RR|....  |                             |  ....|S-RR|.....  |
|   :   +----+   :  |                             |  :   +----+    :  |
|   :            :  |                             |  :             :  |
|----+          +-------------------------------------+          +----|
|PE1 |          |             IW border node          |          | PE2|
|----+          | VPN Label<->L2/L3 lookup<->SRv6 SID |          +----|
|               |                                     |               |
|               +-------------------------------------+               |
|      MPLS         |                             |       SRv6        |
+-------------------+                             +-------------------+
<------MPLS VPN----->                             <------SRv6 VPN----->

5.1. IPv6 Address Planning

SRv6 requires a network running IPv6 and forwards packets based on native IPv6. Interface IPv6 addresses need to be configured prior to SRv6 configuration. IP address planning is an important part of network design and directly affects subsequent routing, tunnel, and security designs. Well-designed IP address planning makes service provisioning and network OAM much easier. When SRv6 needs to be deployed on a network, if IPv6 has been deployed and IPv6 addresses have been planned, the original IPv6 address planning does not need to be modified, and we only need to select a reserved network prefix and use it to allocate SRv6 locators. If neither IPv6 has been deployed on a network, nor IPv6 addresses have planned, IPv6 address planning can be performed by determining the principles for IPv6 address planning on the network, determining the method of IPv6 address allocation, and hierarchically allocating IPv6 addresses.¶

During IPv6 address planning, for an E2E SRv6 network for instance, each network domain is configured with a network prefix for locator allocations to devices in this domain, allowing advertisement of only an aggregated locator route to devices outside the domain. If no IPv6 loopback interface has been configured on the network, the locator and loopback address with the same network prefix can be allocated so that only the aggregated route shared by the locator and loopback address needs to be advertised, thereby reducing the number of routes. A separate network prefix is allocated to the access and aggregation layers, and another separate network prefix is allocated to the IP core layer. Only an aggregated IPv6 route (locator and loopback address) is advertised between the aggregation and IP core layers. SRv6 service nodes only need to learn the aggregated route and the specific routes in the local domain to carry E2E SRv6 services. In addition, the number of service configuration points is reduced to two: ingress and egress. As such, the specific routes of a domain are not flooded to other domains. In addition, route changes, such as route flapping, in one domain do not cause frequent route changes in another domain. This enhances security and stability within the network.¶

5.2. BGP in SRv6

On an SRv6 network, in addition to the conventional route advertisement function, BGP also supports information exchange between forwarders and a controller. Forwarders use BGP-LS (Link State) to report information, such as the network topology and latency, to the controller for path computation. To support SR, forwarders need to report SR information to the controller through BGP-LS. Additionally, the controller uses BGP SR Policy to deliver SR path information. For this reason, on an SRv6 network, BGP design needs to consider not only the IPv6 unicast address family peer design and VPN/EVPN address family peer design, but also the BGP-LS address family peer design and BGP IPv6 SR-Policy address family peer design.¶

In a VPN network (which uses MP-BGP to distribute VPN routes), a Route Reflector (RR) eliminates the need for a full mesh by allowing PE routers to peer only with the RR, which then reflects VPN routes to all other PEs. BGP treats VPNv4 (IPv4 VPN) and VPNv6 (IPv6 VPN) as different address families. Both VPNv4 and VPNv6 need to be enabled in MP-BGP when using both addresses families in, for example, Ships-in-the-night deployments. A single VPN can be supported by both MPLS and SRv6 simultaneously in SIN mode, but the two control planes operate independently, and seamless interworking requires additional mechanisms.¶

BGP information types have various roles in SRv6. VPNv6 routes carry customer VPN routes with SRv6 SIDs (End.DT6, End.DX4, etc.). BGP-LS collects and distributes SRv6 topology info to controllers (e.g., for SDN) and BGP SRv6 policies distribute SRv6 Traffic Engineering (TE) policies (e.g., Flex-Algo, explicit paths).¶

5.3. VPN Service Design

SRv6 VPN services can use BGP as the unified signaling control plane to provide L2/3 service connections. EVPN can be used to carry both L3VPN and L2VPN services in SRv6, thereby simplifying protocols. Hierarchical VPN is widely deployed on MPLS networks to reduce the number of routes on access devices at network edges. E2E VPN is recommended for SRv6 networks because only service access points, instead of transit nodes, need to be configured. Also, transit nodes do not need to be aware of services, and this in turn facilitates both deployment and maintenance.¶

5.4. Migration steps

Let's take MPLS L3VPN as an example to describe how L3VPN services can evolve from MPLS to SRv6. After network nodes are upgraded to support SRv6, L3VPN services can be migrated from MPLS to SRv6 using the following procedure:¶

1. Configure interface IPv6 addresses and locators.¶

2. Configure IS-IS IPv6 and enable SRv6, and then configure the forwarders to advertise locator routes.¶

3. Establish BGP peer relationships between the controller and forwarders using the IPv6 unicast address family, and enable BGP-LS and BGP IPv6 SR-Policy. The controller delivers SRv6 Policies, and SRv6 TE tunnels are established on forwarders.¶

4. On Forwarders, establish BGP VPNv4 peer relationships using IPv6 addresses so that BGP VPNv4 peers advertise VPN routes to each other. The color attribute of the VPN routes is consistent with that of SRv6 Policies to ensure that VPN routes can recurse to the SRv6 Policy.¶

5. Each forwarder has two routes with the same prefix, one carrying the MPLS VPN label received from the BGP peer established using IPv4 addresses and the other carrying the VPN SID received from the BGP peer established using IPv6 addresses. If the two routes have the same attributes, a forwarder by default preferentially selects the route received from the BGP peer established using IPv4 addresses, and services can still be carried over MPLS tunnels.¶

6. Configure a route policy so that the forwarder preferentially selects the route received from the BGP peer established using IPv6 addresses. Then, traffic will be automatically switched to SRv6 tunnels, and L3VPN services will be migrated to the SRv6 tunnels.¶

7. Delete the MPLS tunnel, BGP peer relationships established using the IPv4 unicast address family, and MPLS configurations.¶

After an SRv6 tunnel is established, services can be migrated from MPLS to SRv6.¶

9.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

9.2. Informative References

[I-D.ietf-spring-srv6-mpls-interworking]

Agrawal, S., Filsfils, C., Voyer, D., Dawra, G., Li, Z., and S. Hegde, "SRv6 and MPLS interworking", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-mpls-interworking-00, 17 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00>.

[I-D.liu-srv6ops-problem-summary]

Liu, Y., Voyer, D., Graf, T., Miklos, Z., Contreras, L. M., Leymann, N., Song, L., Matsushima, S., Xie, C., and X. Yi, "SRv6 Deployment and Operation Problem Summary", Work in Progress, Internet-Draft, draft-liu-srv6ops-problem-summary-05, 8 May 2025, <https://datatracker.ietf.org/doc/html/draft-liu-srv6ops-problem-summary-05>.