



Network Working Group                                         M. McBride
Internet-Draft                                                 Futurewei
Intended status: Informational                                    Y. Liu
Expires: 25 December 2025                                   China Mobile
                                                                   Z. Li
                                                     Huawei Technologies
                                                               M. Durmus
                                                              E. Erdogan
                                                                Turkcell
                                                               G. Mishra
                                                            Verizon Inc.
                                                            23 June 2025


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

Abstract

   When deciding to migrate a network from MPLS/SR-MPLS to SRv6, common
   questions involve how to go about performing the migration, what's
   the least amount of impact to an existing network and what existing
   techniques are available.  This document presents various migration
   options for networks being upgraded from MPLS/SR-MPLS 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 25 December 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





McBride, et al.         Expires 25 December 2025                [Page 1]

Internet-Draft           SRv6 Deployment Options               June 2025


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Progressive vs Direct Evolution . . . . . . . . . . . . . . .   3
   4.  Deployment Options  . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Overlay . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Ships-In-The-Night  . . . . . . . . . . . . . . . . . . .   6
     4.3.  Interworking between MPLS and SRv6  . . . . . . . . . . .   7
   5.  Considerations  . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  IPv6 Address Planning . . . . . . . . . . . . . . . . . .   8
     5.2.  BGP in SRv6 . . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  VPN Service Design  . . . . . . . . . . . . . . . . . . .  10
     5.4.  Migration steps . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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.  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, utilize various
   tunneling/overlay techniques, use an interworking translation
   mechanism or other deployment solution?  If they are currently



McBride, et al.         Expires 25 December 2025                [Page 2]

Internet-Draft           SRv6 Deployment Options               June 2025


   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 an overview of the various solutions
   available for SRv6 deployment particularly when migrating from MPLS/
   SR-MPLS to SRv6.

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

   SRMS: Segment Routing Mapping Server

   SIN: Ships-in-the-Night

3.  Progressive vs Direct Evolution

   Migrating from a traditional MPLS network to SRv6 is a significant
   architectural shift.  A phased, progressive approach would involve
   first transitioning 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
   transition would be a fairly minor upgrade.  SR-MPLS reuses the MPLS



McBride, et al.         Expires 25 December 2025                [Page 3]

Internet-Draft           SRv6 Deployment Options               June 2025


   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.
   Full network SRv6 adoption requires IPv6-enabled hardware and
   software across the network.  Also, 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
   transition 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 an upgrade.  If the network
   is currently IPv4 only but is expecting to be upgraded to IPv6 soon,
   it may make sense to directly transition 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 upgrade
   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, Progressive vs Direct evolution, we’ve
   identified three SRv6 transport network evolution strategies that
   operators can consider when transitioning 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 progressive
   vs direct evolution to SRv6.  An existing MPLS network can first
   progressively migrate to SR-MPLS before migrating to SRv6 or it can
   migrate directly to SRv6 and bypass SR-MPLS deployment:








McBride, et al.         Expires 25 December 2025                [Page 4]

Internet-Draft           SRv6 Deployment Options               June 2025


                      +---------+ +---------+ +---------+
                      |  MPLS   | | SR-MPLS | |  SRv6   |
                      +---------+ +---------+ +---------+

                           |          |  |         |
              Progressive  +----------+  +---------+

                           |                       |
              Direct       +-----------------------+

                      Figure 1: Progressive vs Direct

4.  Deployment Options

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

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



McBride, et al.         Expires 25 December 2025                [Page 5]

Internet-Draft           SRv6 Deployment Options               June 2025


   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               |
                  +----------------------------------+

                        Figure 2: Overlay using 6PE

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



McBride, et al.         Expires 25 December 2025                [Page 6]

Internet-Draft           SRv6 Deployment Options               June 2025


   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   |
               +----------------+         +----------------+

                        Figure 3: Ships-in-the-night

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



McBride, et al.         Expires 25 December 2025                [Page 7]

Internet-Draft           SRv6 Deployment Options               June 2025


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

                          Figure 4: Gateway IW

5.  Considerations

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

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



McBride, et al.         Expires 25 December 2025                [Page 8]

Internet-Draft           SRv6 Deployment Options               June 2025


   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.













McBride, et al.         Expires 25 December 2025                [Page 9]

Internet-Draft           SRv6 Deployment Options               June 2025


   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.






McBride, et al.         Expires 25 December 2025               [Page 10]

Internet-Draft           SRv6 Deployment Options               June 2025


   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.

6.  IANA Considerations

   N/A

7.  Security Considerations



8.  Acknowledgement



9.  References

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




McBride, et al.         Expires 25 December 2025               [Page 11]

Internet-Draft           SRv6 Deployment Options               June 2025


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

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


   Mehmet Durmus
   Turkcell
   Email: mehmet.durmus@turkcell.com.tr


   Ersin Erdogan
   Turkcell
   Email: ersin.erdogan@turkcell.com.tr


   Gyan S. Mishra
   Verizon Inc.



McBride, et al.         Expires 25 December 2025               [Page 12]

Internet-Draft           SRv6 Deployment Options               June 2025


   Email: gyan.s.mishra@verizon.com


















































McBride, et al.         Expires 25 December 2025               [Page 13]
