SRv6 Deployment Options
draft-mcbride-srv6ops-srv6-deployment-01

Network Working Group                                         M. McBride
Internet-Draft                                                 Futurewei
Intended status: Best Current Practice                            Y. Liu
Expires: 8 May 2025                                         China Mobile
                                                                   Z. Li
                                                     Huawei Technologies
                                                               G. Mishra
                                                            Verizon Inc.
                                                         4 November 2024

                        SRv6 Deployment Options
                draft-mcbride-srv6ops-srv6-deployment-01

Abstract

   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.

Status of This Memo

   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 8 May 2025.

Copyright Notice

   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

McBride, et al.            Expires 8 May 2025                   [Page 1]
Internet-Draft           SRv6 Deployment Options           November 2024

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deployment Options  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Ships-In-The-Night  . . . . . . . . . . . . . . . . . . .   3
     3.2.  Interworking between MPLS and SRv6  . . . . . . . . . . .   4
     3.3.  IPv6 Address Planning . . . . . . . . . . . . . . . . . .   4
     3.4.  BGP Design  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  VPN Service Design  . . . . . . . . . . . . . . . . . . .   5
     3.6.  Evolution from MPLS to SRv6 . . . . . . . . . . . . . . .   5
   4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

McBride, et al.            Expires 8 May 2025                   [Page 2]
Internet-Draft           SRv6 Deployment Options           November 2024

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

1.1.  Requirements Language

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

2.  Glossary

   MPLS: Multiprotocol Label Switching

   RSVP: Resource Reservation Protocol

   SR-MPLS: Segment Routing based on MPLS

   SRv6: Segment Routing based on IPv6

3.  Deployment Options

   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.

3.1.  Ships-In-The-Night

   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

McBride, et al.            Expires 8 May 2025                   [Page 3]
Internet-Draft           SRv6 Deployment Options           November 2024

   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.

3.2.  Interworking between MPLS and SRv6

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

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

McBride, et al.            Expires 8 May 2025                   [Page 4]
Internet-Draft           SRv6 Deployment Options           November 2024

   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.

3.4.  BGP Design

   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.

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

3.6.  Evolution from MPLS to SRv6

   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.

McBride, et al.            Expires 8 May 2025                   [Page 5]
Internet-Draft           SRv6 Deployment Options           November 2024

   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.

4.  Conclusions

5.  IANA Considerations

   N/A

6.  Security Considerations

McBride, et al.            Expires 8 May 2025                   [Page 6]
Internet-Draft           SRv6 Deployment Options           November 2024

7.  Acknowledgement

8.  References

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

8.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-03, 5 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-liu-srv6ops-
              problem-summary-03>.

Authors' Addresses

   Mike McBride
   Futurewei
   Email: mmcbride7@gmail.com

   Yisong Liu
   China Mobile
   Email: liuyisong@chinamobile.com

   Zhenbin Li
   Huawei Technologies
   Email: lizhenbin@huawei.com

McBride, et al.            Expires 8 May 2025                   [Page 7]
Internet-Draft           SRv6 Deployment Options           November 2024

   Gyan S. Mishra
   Verizon Inc.
   Email: gyan.s.mishra@verizon.com

McBride, et al.            Expires 8 May 2025                   [Page 8]