| Internet-Draft | SRv6 Deployment Options | October 2024 |
| McBride, et al. | Expires 24 April 2025 | [Page] |
This document presents various options to help provide deployment direction to those whose networks will be upgraded to an SRv6 environment. Whether the existing network is IPv4, IPv6, MPLS, SR-MPLS or other, this draft provides direction on how to seemlessly upgrade to SRv6.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 upgrade their existing networks to a SRv6 network. Should they run ships in the night, utilize various tunneling techniques or other deployment solution? If they are currently running an IP/MPLS network how should they transition to SRv6? This draft provides various deployment alternatives to help provide guidance to those wanting to upgrade 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.¶
[I-D.liu-srv6ops-problem-summary] 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 the solutions and best practices for SRv6 deployment.¶
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 [RFC2119].¶
MPLS: Multiprotocol Label Switching¶
RSVP: Resource Reservation Protocol¶
SR-MPLS: Segment Routing based on MPLS¶
SRv6: Segment Routing based on IPv6¶
Various topics are addressed, in this section, to offer options for seamless transition to SRv6. These options will enable a transition from current technologies, such as RSVP-TE and SR-MPLS, and ensures an evolution path without the need for a complete forklift of existing infrastructure.¶
This solution is likely the easiest and most popular deployment option. It may also be the costliest deployment option. Ships-in-the-Night is a technique that allows all routers to run multiple routing processes at once. This technique is used with IPv4 and IPv6 and can also be used with protocols such as MPLS and SRv6. IPv4 and IPv6 are separate protocols and can't work together without some form of translation mechanism. Some networks run dual stack where both IPv4 and IPv6 run over the same infrastructure as ships-in-the-night. Same is true for protocols such as MPLS and SRv6 which can also be integrated into the same network as ships-in-the-night.¶
There are drawbacks to running protocols ships-in-the-night. Maintaining two protocols can, for instance, 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.¶
One deployment decision is to allow an existing MPLS network to interwork with SRv6, rather than only run ships-in-the-night. [I-D.ietf-spring-srv6-mpls-interworking] describes SRv6 and MPLS/SR-MPLS interworking procedures. The interworking problem is generalized into various interworking scenarios and these scenarios are stitched either by transport interworking or service interworking. New SRv6 behaviors, and MPLS labels, stitch the end to end path across different data planes. This 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).¶
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 withteh 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 separte 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 rout 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 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. In addition, 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.¶
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.¶
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:¶
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, services can be migrated from MPLS to SRv6.¶
N/A¶