SRv6 Deployment Options

Segment Routing IPv6 (SRv6) is a network architecture that leverages IPv6 data plane encapsulation to enable flexible and efficient traffic engineering. It allows for the creation of explicit paths through the network by encoding routing instructions directly into packet headers. Many operators are looking for direction in how to migrate their existing networks to a SRv6 network. It is common for them to have had an IP/MPLS network for over ten years and now ready for a network refresh. Many are convinced it's time to evolve their network to segment routing. And now that SRv6 is mature, they are often planning on that deployment even if currently running SR-MPLS. How to evolve an existing IP/MPLS network to meet the new demands upon a network? Should they run ships in the night (protocol messages coexist being unaware of each other), utilize various tunneling/overlay techniques, use an interworking translation mechanism or other deployment solution? If they are currently running an IP/MPLS network how should they migrate to SRv6? This draft provides various deployment alternatives to help provide guidance to those wanting to migrate their network to SRv6. SRv6 can be deployed on a typical single-AS network (such as IP backbone network, metro network, mobile transport network, or data center network) or on an E2E network (such as an inter-AS VPN or carrier's carrier network). Before SRv6 is deployed, IPv6 address planning is needed for SID allocation. IGP and BGP designs are then implemented for network nodes, and the corresponding SIDs are advertised for services such as TE and VPN. provides an overview of the common problems encountered during SRv6 deployment and operation. It provides a foundation for further work, including potential solutions and best practices to navigate deployment. The purpose of this deployment draft is to provide an overview of the various solutions available for SRv6 deployment particularly when migrating from MPLS/SR-MPLS to SRv6.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

MPLS: Multiprotocol Label Switching RSVP: Resource Reservation Protocol SR-MPLS: Segment Routing based on MPLS SRv6: Segment Routing based on IPv6 SRMS: Segment Routing Mapping Server SIN: Ships-in-the-Night

Migrating from a traditional MPLS network to SRv6 is a significant architectural shift. A phased, gradual approach would involve first migrating to SR-MPLS (Segment Routing over MPLS) before moving to SRv6. Doing so may reduce risks, simplify operations, and ensure a smooth migration. In most deployments, an MPLS to SR-MPLS migration would be fairly minor. SR-MPLS reuses the MPLS data plane (labels) while also simplifying the control plane (removing LDP/RSVP-TE). Existing MPLS supporting hardware will often support SR-MPLS with a software upgrade so there would be no need to upgrade hardware or change existing label forwarding mechanisms. Additionally, SRv6 requires at least a partial IPv6 infrastructure. Direct, network wide, SRv6 adoption generally requires IPv6-enabled hardware and software across the network. Some legacy devices may not support SRv6 and the network may require new hardware. Some older routers may lack the TCAM capacity for 128-bit SIDs. In some environments it may be best to instead skip SR-MPLS and migrate directly to SRv6. If a network is already IPv6-ready (e.g., in data centers, 5G mobile backhaul) it may make sense to move directly to SRv6 and leverage an overlay solution for portions of the network net yet ready for migration. If the network is currently IPv4 only but is expecting to be migrated to IPv6 soon, it may make sense to directly migrate an IPv4 MPLS network to SRv6 after the IPv6 deployment. If you have greenfield deployments, where SRv6 is natively supported, it would make sense to directly migrate to SRv6. If the network support team is already experienced with IPv6 and SRv6 then it may makes sense for a direct evolution from MPLS to SRv6. Within those two philosophies, Gradual vs Direct evolution, we’ve identified three SRv6 transport network evolution strategies that operators can consider when migrating from traditional MPLS networks or deploying new SRv6-based infrastructures. The first option is SRv6 Overlay (SRv6 over MPLS/IP) where 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. The second option is Ships-in-the-Night (or Dual Stack: Independent SRv6 and MPLS). In this model, SRv6 and MPLS operate independently in the same network without interaction. And the third option is SRv6 and MPLS Interworking (Coexistence) which 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. We will detail each of these options in the following section. The following diagram depicts the high level options of gradual vs direct evolution to SRv6. An existing MPLS network can first gradually migrate to SR-MPLS before migrating to SRv6 or it can migrate directly to SRv6 and bypass SR-MPLS deployment:

Various topics are addressed, in this section, to offer options for seamless migration to SRv6. Three SRv6 migration options are highlighted which will each enable a gradual migration from current technologies, such as MPLS and SR-MPLS, and ensures an evolution path without the need for a complete forklift of existing infrastructure.

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 software upgrades. Core network routers can remain IPv4 MPLS (or SR-MPLS) while the rest of the network is migrating to SRv6. How long those core routers remain using MPLS is up to the network operator and can either be a temporary or long term solution depending upon network goals. 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 temporary migration technique with 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:

This solution is a straightforward and popular deployment option. Ships-in-the-Night (SIN) 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:

Let's take MPLS L3VPN as an example to describe how L3VPN services can migrate from MPLS to SRv6 using Ships-in-the-night. After network nodes are software upgraded to support SRv6, L3VPN services can be migrated from MPLS to SRv6 using the following procedure: Configure interface IPv6 addresses and locators. Configure IS-IS IPv6 and enable SRv6, and then configure the forwarders to advertise locator routes. 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. 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. 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. 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. Delete the MPLS tunnel, BGP peer relationships established using the IPv4 unicast address family, and MPLS configurations. After an SRv6 tunnel is established, and the network is running in SIN mode, services can then be migrated from MPLS to SRv6. Once all services have moved to SRv6, all MPLS related configuration can then be removed.

Another migration strategy is to allow an existing MPLS network to interwork with SRv6, rather than only run ships-in-the-night or overlay. 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 in situations where completely separate domains must be maintained. 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:

L2/L3 lookup<->SRv6 SID | +----| | | | | | +-------------------------------------+ | | MPLS | | SRv6 | +-------------------+ +-------------------+ <------MPLS VPN-----> <------SRv6 VPN-----> ]]>

Here are a few additional considerations when migration from MPLS to SRv6.

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.

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).

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.

N/A

The security considerations for Segment Routing are discussed in . Section 5 of describes the SR Deployment Model and the requirements for securing the SR Domain. The security considerations of also cover topics such as attack vectors and their mitigation mechanisms that also apply the behaviors introduced in this document. Together, they describe the required security mechanisms that allow establishment of an SR domain of trust. Having such a well-defined trust boundary is necessary in order to operate SRv6-based services for internal traffic while preventing any external traffic from accessing or exploiting the SRv6-based services. Care and rigor in IPv6 address allocation for use for SRv6 SID allocations and network infrastructure addresses, as distinct from IPv6 addresses allocated for end users and systems (as illustrated in Section 5.1 of , can provide the clear distinction between internal and external address space that is required to maintain the integrity and security of the SRv6 Domain. Additionally, defines a Hashed Message Authentication Code (HMAC) TLV permitting SR Segment Endpoint Nodes in the SR domain to verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation, regardless of the number of segments in the segment list. When enabled by local configuration, HMAC processing occurs at the beginning of SRH processing as defined in Section 2.1.2.1 of .

Thank you to Dhruv Dhody for providing extensive comments on this draft.