Skip to main content

SRv6 Deployment Consideration
draft-tian-spring-srv6-deployment-consideration-08

Document Type Active Internet-Draft (individual)
Authors Hui Tian , Chongfeng Xie , Edmore Chingwena , Shuping Peng , Qiangzhou Gao
Last updated 2024-02-27
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-tian-spring-srv6-deployment-consideration-08
Network Working Group                                            H. Tian
Internet-Draft                                                     CAICT
Intended status: Informational                                    C. Xie
Expires: 30 August 2024                                    China Telecom
                                                            E. Chingwena
                                                       MTN Group Limited
                                                            S. Peng, Ed.
                                                             Q. Gao, Ed.
                                                     Huawei Technologies
                                                        27 February 2024

                     SRv6 Deployment Consideration
           draft-tian-spring-srv6-deployment-consideration-08

Abstract

   SRv6 has significant advantages over SR-MPLS and has attracted more
   and more attention and interest from network operators and verticals.
   Smooth network migration towards SRv6 is a key focal point and this
   document provides network design and migration guidance and
   recommendations on solutions in various scenarios.  Deployment cases
   with SRv6 are also introduced.

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

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 30 August 2024.

Tian, et al.             Expires 30 August 2024                 [Page 1]
Internet-Draft        SRv6 Deployment Consideration        February 2024

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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Advantages of SRv6  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  IP Route Aggregation  . . . . . . . . . . . . . . . . . .   4
     2.2.  End-to-end Service Auto-start . . . . . . . . . . . . . .   5
     2.3.  On-Demand Upgrade . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Simplified Service Deployment . . . . . . . . . . . . . .   7
       2.4.1.  Carrier's Carrier . . . . . . . . . . . . . . . . . .   7
       2.4.2.  LDP over TE . . . . . . . . . . . . . . . . . . . . .   8
   3.  Compatibility Challenges  . . . . . . . . . . . . . . . . . .   9
     3.1.  Fast Reroute (FRR)  . . . . . . . . . . . . . . . . . . .   9
     3.2.  Traffic Engineering (TE)  . . . . . . . . . . . . . . . .  10
     3.3.  Service Function Chaining (SFC) . . . . . . . . . . . . .  10
     3.4.  IOAM  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.5.  SRv6 header overhead  . . . . . . . . . . . . . . . . . .  11
   4.  Solutions for mitigating the compatibility challenges . . . .  12
     4.1.  Traffic Engineering . . . . . . . . . . . . . . . . . . .  12
       4.1.1.  Binding SID (BSID)  . . . . . . . . . . . . . . . . .  12
       4.1.2.  PCEP FlowSpec . . . . . . . . . . . . . . . . . . . .  12
     4.2.  SFC . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
       4.2.1.  Stateless SFC . . . . . . . . . . . . . . . . . . . .  13
       4.2.2.  Stateful SFC  . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Light Weight IOAM . . . . . . . . . . . . . . . . . . . .  14
     4.4.  Postcard Telemetry  . . . . . . . . . . . . . . . . . . .  14
     4.5.  SRv6 header compression . . . . . . . . . . . . . . . . .  14
   5.  Design Guidance for SRv6 Network  . . . . . . . . . . . . . .  15
     5.1.  Locator and Address Planning  . . . . . . . . . . . . . .  15
     5.2.  PSP . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   6.  Incremental Deployment Guidance for SRv6 Migration  . . . . .  17
   7.  Migration Guidance for SRv6/SR-MPLS Co-existence Scenario . .  17
   8.  Deployment cases  . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  China Telecom Si'chuan  . . . . . . . . . . . . . . . . .  19
     8.2.  China Unicom  . . . . . . . . . . . . . . . . . . . . . .  20

Tian, et al.             Expires 30 August 2024                 [Page 2]
Internet-Draft        SRv6 Deployment Consideration        February 2024

     8.3.  MTN Uganda  . . . . . . . . . . . . . . . . . . . . . . .  21
     8.4.  Agricultural Bank of China (ABC)  . . . . . . . . . . . .  21
     8.5.  Indosat Ooredoo Hutchison . . . . . . . . . . . . . . . .  22
     8.6.  Orange Spain  . . . . . . . . . . . . . . . . . . . . . .  24
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  25
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  26
   12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  26
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     13.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   SRv6 is the instantiation of Segment Routing deployed on the IPv6
   data plane[RFC8200].  Therefore, in order to support SRv6, the
   network must first be enabled for IPv6.  Over the past several years,
   IPv6 has been actively promoted all over the world, and the
   deployments of IPv6 have been ever-increasing which provides the
   basis for the deployments of SRv6.

   With IPv6 as its data plane, for network migration towards SRv6, both
   software and hardware need to be upgraded.  Compared with other new
   protocols, only IGP and BGP need to be extended to support SRv6,
   which significantly simplifies the software upgrade required.  While
   the hardware needs to support the new SRv6 header SRH[RFC8754], the
   design of SRv6 assures compatibility with the existing IPv6 network
   as an SRv6 SID is designed as a 128-bit IPv6 address and the
   encapsulation of an SRv6 packet is the same as an IPv6 packet.  When
   only L3VPN over SRv6 BE (Best-Effort) is deployed, there will be no
   SRH.  Therefore, no additional hardware capabilities are required but
   only software upgrade for protocol extensions.

   As the number of services supported by SRv6 increase, e.g.  SFC,
   network slicing, iOAM etc., more SIDs in the SRH may impose new
   requirements on the hardware.  Besides upgrading the hardware,
   various solutions have already been proposed to relieve the imposed
   pressure on the hardware, such as Binding SID (BSID) etc. to
   guarantee the compatibility with the existing network.  On the other
   hand SRv6 has many more advantages over SR-MPLS for the network
   migration to support new services.

   This document summarizes the advantages of SRv6 and provides network
   migration guidance and recommendations on solutions in various
   scenarios.

Tian, et al.             Expires 30 August 2024                 [Page 3]
Internet-Draft        SRv6 Deployment Consideration        February 2024

2.  Advantages of SRv6

   Compared with SR-MPLS, SRv6 has significant advantages especially in
   large scale networking scenarios.

2.1.  IP Route Aggregation

   The increasing complexity of service deployment is of concern for
   network operators, especially in large-scale networking scenarios.
   With solutions such as multi-segment PW and Option A [RFC4364], the
   number of service-touch points has increased, and the services, with
   associated OAM features cannot be deployed end-to-end.

   *  With Seamless MPLS or SR-MPLS, since the MPLS label itself does
      not have reachability information, it must be attached to a
      routable address.  The 32-bit host route needs to leak across
      domains.  For an extreme case, as shown in Figure 1a, in a large
      scale networking scenario, millions of host route LSPs might need
      to be imported, which places big challenges on the capabilities of
      the edge nodes.

   *  With SRv6, owing to its native IP feature of route aggregation as
      shown in Figure 1b, the aggregated routes can be imported across
      network domains.  For large scale networking, only very few
      aggregated routes are needed in order to start end-to-end
      services, which also reduces the scalability requirements on the
      edge nodes.

Tian, et al.             Expires 30 August 2024                 [Page 4]
Internet-Draft        SRv6 Deployment Consideration        February 2024

     /------Metro------\     /----Core----\    /------Metro-------\
LB  PE1               ASBR                    ASBR               PE2  LB
1.1.1.1                                                          2.2.2.2
    +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+
    |A |  |B |  |ER|  |  |  |PE|  |  |  |PE|  |  |  |ER|  |B |  |A |
    +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+
     SR-LSP    SR-LSP           SR-LSP             SR-LSP   SR-LSP
     |<--->|<---------->|    |<--------->|      |<--------->|<--->|
                                BGP-LSP
     |<---------------------------------------------------------->|
+---+ +---+    +---+    +---+    +---+    +---+     +---+    +---+ +---+
+IP + +IP +    +IP +    +IP +    +IP +    +IP +     +IP +    +IP + +IP +
+ETH+ +VPN+    +VPN+    +VPN+    +VPN+    +VPN+     +VPN+    +VPN+ +ETH+
+---+ +BGP+    +BGP+    +BGP+    +BGP+    +BGP+     +BGP+    +BGP+ +---+
      +SR +    +SR +    +ETH+    +SR +    +ETH+     +SR +    +SR +
      +ETH+    +ETH+    +---+    +ETH+    +---+     +ETH+    +ETH+
      +---+    +---+             +---+              +---+    +---+

                           (a) SR-MPLS

     /------Metro------\     /----Core----\    /------Metro-------\
LOC PE1               ASBR                    ASBR               PE2  LOC
A1::100::                                                        A2::200::
    +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+
    |A |  |B |  |ER|  |  |  |PE|  |  |  |PE|  |  |  |ER|  |B |  |A |
    +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+  +--+
      \_____A1::/80____/      \__A0::/80__/      \____A2::/80____/
       Aggregated Route     Aggregated Route      Aggregated Route
+---+     +----------+        +----------+          +----------+    +---+
+IP +     +    IP    +        +    IP    +          +    IP    +    +IP +
+ETH +    +w./wo.SRH +        +w./wo.SRH +          +w./wo.SRH +    +ETH+
+---+     +   ETH    +        +   ETH    +          +   ETH    +    +---+
          +----------+        +----------+          +----------+

                            (b) SRv6

      Figure 1. Large-scale Networking with (a) SR-MPLS vs. (b) SRv6

2.2.  End-to-end Service Auto-start

   In the SR cross-domain scenario, in order to set up end-to-end SR
   tunnels, the SIDs in each domain need to be imported to other
   domains.

   *  With SR-MPLS, SRGB and Node SID need overall network-wide
      planning, and in the cross-domain scenario, it is difficult or
      sometimes even impossible to perform as the node SIDs in different
      domains may collide.  BGP Prefix SID can be used for the cross-

Tian, et al.             Expires 30 August 2024                 [Page 5]
Internet-Draft        SRv6 Deployment Consideration        February 2024

      domain SID import, but the network operator must be careful when
      converting the SID to avoid SID collision.  Moreover, the pre-
      allocated SRGB within each domain needs to consider the total
      number of devices in all other domains, which raises difficulties
      for the network-wide planning.

   *  With SRv6, owing to its native IP feature of route reachability,
      if the IPv6 address space is carefully planned, and the aggregated
      routes are imported by using BGP4+ (BGP IPv6), the services will
      auto-start in the cross-domain scenario.

2.3.  On-Demand Upgrade

   The MPLS label itself does not hold any reachability information, so
   it must be attached to a routable address, which means that the
   matching relationship between the label and FEC needs to be
   maintained along the path.

   SR-MPLS uses the MPLS data plane.  When the network migrates to SR-
   MPLS, there are two ways, as shown in Figure 2:

   1.  MPLS/SR-MPLS Dual stack: the entire network is upgraded first and
       then deploy SR-MPLS.

   2.  MPLS and SR-MPLS interworking: mapping servers are deployed at
       some of the intermediate nodes and then removed once the entire
       network is upgraded

   Regardless of which migration option is chosen, big changes in a wide
   area is required at the initial stage therefore causing a long time-
   to-market.

   In contrast, the network can be migrated to SRv6 on demand.  Wherever
   the services need to be turned on, only the relevant devices need to
   be upgraded to enable SRv6, and all other devices only need to
   support IPv6 forwarding and need not be aware of SRv6.  When Traffic
   Engineering (TE) services are needed, only the key nodes along the
   path need to be upgraded to support SRv6.

Tian, et al.             Expires 30 August 2024                 [Page 6]
Internet-Draft        SRv6 Deployment Consideration        February 2024

                                           (~~~~~~MPLS/SR-MPLS~~~~~~~)
                                           (  +---+   +---+   +---+  )
     MPLS Migration Options      Option 1  (  |SM |   |SM |   |SM |  )
                                       --->(  +---+   +---+   +---+  )
                                     /     (  +---+   +---+   +---+  )
   (~~~~~~~~~~MPLS~~~~~~~~~~~)     /       (  |SM |   |SM |   |SM |  )
   (  +---+   +---+   +---+  )   /         (  +---+   +---+   +---+  )
   (  | M |   | M |   | M |  ) /            ~~~~~~~~~~~~~~~~~~~~~~~~~~
   (  +---+   +---+   +---+  ) \
   (  +---+   +---+   +---+  )   \         (~~MPLS~~|~~~~~SR-MPLS~~~~~)
   (  | M |   | M |   | M |  )     \       (  +---+ |  +---+   +---+  )
   (  +---+   +---+   +---+  )       \     (  | M | |  |SM |   |SM |  )
   ~~~~~~~~~~~~~~~~~~~~~~~~~~          --->(  +---+ |  +---+   +---+  )
                                 Option 2  (  +---+ |  +---+   +---+  )
                                           (  | M | |  |SM |   |SM |  )
                                           (  +---+ |  +---+   +---+  )
                                            ~~~~~~~~~~~~~~~~~~~~~~~~~~
        SRv6 Migration

   (~~~~~~~~~~MPLS~~~~~~~~~~~)             (~~~~~~SRv6 on demand~~~~~)
   (  +---+   +---+   +---+  )             (  +---+   +---+   +---+  )
   (  | M |   | M |   | M |  )             (  |S6 |   | M |   | M |  )
   (  +---+   +---+   +---+  ) ----------> (  +---+   +---+   +---+  )
   (  +---+   +---+   +---+  )             (  +---+   +---+   +---+  )
   (  | M |   | M |   | M |  )             (  | M |   | M |   |S6 |  )
   (  +---+   +---+   +---+  )             (  +---+   +---+   +---+  )
   ~~~~~~~~~~~~~~~~~~~~~~~~~~              ~~~~~~~~~~~~~~~~~~~~~~~~~~

         Figure 2. MPLS Domain Migration vs. SRv6 On-Demand Upgrade

2.4.  Simplified Service Deployment

   With SRv6, the service deployment can be significantly simplified in
   some scenarios.

2.4.1.  Carrier's Carrier

   When the customer of the VPN service carrier (Provider Carrier) is
   itself a VPN service carrier (Customer Carrier), it becomes the
   scenario of Carrier's Carrier.  For this scenario, with SRv6, the
   service deployment can be significantly simplified.

   To achieve better scalability, the CEs of the Provider Carrier (i.e.
   the PEs of the Customer Carriers) only distribute the internal
   network routes to the PEs of the Provider Carrier.  The customers'
   routes of the Customer Carriers (i.e. from CE3 and CE4) will not be
   distributed into the network of the Provide Carrier.  Therefore, LDP
   or Labeled BGP will be run between the CEs of the Provider Carrier

Tian, et al.             Expires 30 August 2024                 [Page 7]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   (i.e.  CE1 and CE2 in the Figure 3) and the PEs of the Provider
   Carrier (i.e.  PE1 and PE2 in the Figure 3), and LDP will be run
   between the CEs of the Provider Carrier (i.e. the PEs of the Customer
   Carriers) and the PEs of the Customer Carrier (i.e.  PE3 and PE4 in
   the Figure 3).  MP-BGP will be run between the PEs of the Customer
   Carrier.  The overall service deployment is very complex.

   If SRv6 is deployed by the Customer Carrier and the Provider Carrier,
   no LDP will be ever needed.  The Locator routes and Loopback routes
   of the Customer Carriers can be distributed into the network of the
   Provider Carrier via BGP, and within each carrier's network only IGP
   is needed.  The end-to-end VPN services can be provided just based on
   the IPv6 interconnections, and the customer carrier is just like a
   normal CE to the provider carrier, which significantly simplified the
   VPN service deployment.

           Customer Carrier     Provider Carrier     Customer Carrier
            /------------\      /-------------\      /-----------\
    +---+  +---+      +---+  +---+          +---+  +---+       +---+  +---+
    |CE3|--|PE3|      |CE1|--|PE1|          |PE2|--|CE2|       |PE4|--|CE4|
    +---+  +---+      +---+  +---+          +---+  +---+       +---+  +---+

MPLS           IGP/LDP   IGP/LDP     MP-IBGP   IGP/LDP    IGP/LDP
                      or Labeled BGP        or Labeled BGP

SR-MPLS          IGP    Labeled BGP  MP-IBGP  Labeled BGP   IGP

SRv6             IGP        BGP      MP-IBGP      BGP       IGP
             |<--------->||<---->||<---------->||<--->||<--------->|
                                     MP-IBGP
             |<--------------------------------------------------->|
      Figure 3. Service deployment with MPLS, SR-MPLS and SRv6

2.4.2.  LDP over TE

   In a MPLS network, generally RSVP-TE is deployed in the P nodes of
   the network, and LDP is running between these P nodes and the PE
   nodes.  Customers access to VPN services via the PE nodes.  This
   scenario is called LDP over TE, which is a typical deployment for
   carriers who want to achieve the TE capability over MPLS network
   while keep scalability.  However, such network configuration and
   service deployment are very complex.

   With SRv6 which can provide both TE capability and IP reachability,
   the service deployment can be significantly simplified.  Only IGP and
   BGP are needed in the network to launch VPN services.

Tian, et al.             Expires 30 August 2024                 [Page 8]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   +---+         +---+      +---+         +---+      +---+        +---+
   |CE1|---------|PE1|------|P1 |\-------/|P2 |------|PE2|--------|CE2|
   +---+         +---+      +---+  \   /  +---+      +---+        +---+
                                     /
   +---+         +---+      +---+  /   \  +---+      +---+        +---+
   |CE3|---------|PE3|------|P3 |/-------\|P4 |------|PE4|--------|CE4|
   +---+         +---+      +---+         +---+      +---+        +---+

   MPLS                LDP        RSVP-TE        LDP

   SR-MPLS                      IGP (SR-MPLS)

   SRv6                          IGP (SRv6)
                   |<-------->|<------------>|<------->|
                                   MP-BGP
                   |<--------------------------------->|
         Figure 4. Service deployment with (a) MPLS/SR-MPLS vs. (b) SRv6

3.  Compatibility Challenges

   By adopting SR Policy, state in the network devices can be greatly
   reduced, which ultimately evolves the network into a stateless
   fabric.  However, it also brings compatibility challenges on the
   legacy devices.  In particular, the legacy devices need to upgrade
   software and/or hardware in order to support the processing of SRH.

   Furthermore, as the segments in the segment list increase the SR
   Policy incrementally expands, the encapsulation header overhead
   increases, which imposes high performance requirements on the
   performance of hardware forwarding (i.e. the capability of the
   chipset).

   This section identifies the challenges for legacy devices imposed by
   SRv6 in the following SPRING use cases.

3.1.  Fast Reroute (FRR)

   FRR is deployed to cope with link or node failures by precomputing
   backup paths.  By relying on SR, Topology Independent Loop-free
   Alternate Fast Re-route (TI-LFA)
   [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a local repair
   mechanism with the ability to activate the data plane switch-over on
   to a loop-free backup path irrespective of topologies prior and after
   the failure.

   Using SR, there is no need to create state in the network in order to
   enforce FRR behavior.  Correspondingly, the Point of Local Repair,
   i.e. the protecting router, needs to insert a repair list at the head

Tian, et al.             Expires 30 August 2024                 [Page 9]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   of the segment list in the SRH, encoding the explicit post-
   convergence path to the destination.  This action will increase the
   length of the segment list in the SRH as shown in Figure 1.

3.2.  Traffic Engineering (TE)

   TE enables network operators to control specific traffic flows going
   through configured explicit paths.  There are loose and strict
   options.  With the loose option, only a small number of hops along
   the path is explicitly expressed, while the strict option specifies
   each individual hop in the explicit path, e.g. to encode a low
   latency path from one network node to another.

   With SRv6, the strict source-routed explicit paths will result in a
   long segment list in the SRH as shown in Figure 1, which places high
   requirements on the devices.

3.3.  Service Function Chaining (SFC)

   The SR segments can also encode instructions, called service
   segments, for steering packets through services running on physical
   service appliances or virtual network functions (VNF) running in a
   virtual environment [I-D.ietf-spring-sr-service-programming].  These
   service segments can also be integrated in an SR policy along with
   node and adjacency segments.  This feature of SR will further
   increase the length of the segment list in the SRH as shown in
   Figure 1.

   In terms of SR awareness, there are two types of services, i.e.  SR-
   aware and SR-unaware services, which both impose new requirements on
   the hardware.  The SR-aware service needs to be fully capable of
   processing SR traffic, while for the SR-unaware services, an SR proxy
   function needs to be defined.

   If the Network Service Header (NSH) based SFC [RFC8300] has already
   been deployed in the network, the compatibility with existing NSH is
   required.

3.4.  IOAM

   IOAM, i.e. "in-situ" Operations, Administration, and Maintenance
   (OAM), encodes telemetry and operational information within the data
   packets to complement other "out-of-band" OAM mechanisms, e.g.  ICMP
   and active probing.  The IOAM data fields, i.e. a node data list,
   hold the information collected as the packets traverse the IOAM
   domain [I-D.ietf-ippm-ioam-data], which is populated iteratively
   starting with the last entry of the list.

Tian, et al.             Expires 30 August 2024                [Page 10]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   The IOAM data can be embedded into a variety of transports.  To
   support the IOAM on the SRv6 data plane, the O-flag in the SRH is
   defined [I-D.ietf-6man-spring-srv6-oam], which implements the "punt a
   timestamped copy and forward" or "forward and punt a timestamped
   copy" behavior.  The IOAM data fields, i.e. the node data list, are
   encapsulated in the IOAM TLV in SRH, which further increases the
   length of the SRH as shown in Figure 1.

                                                            +-----------+
                                                            |IPv6 packet|
                                                            +-----------+
                                                            /           /
                                             +-----------+  / IOAM Info /
                                             |IPv6 packet|  /           /
                              +-----------+  +-----------+  +-----------+
                              |IPv6 packet|  /           /  /           /
               +-----------+  +-----------+  /           /  /           /
               |IPv6 packet|  /           /  / SF Chain  /  / SF Chain  /
+-----------+  +-----------+  /  TE Path  /  /           /  /           /
|IPv6 packet|  /TI-LFA Path/  /           /  /           /  /           /
+-----------+  +-----------+  +-----------+  +-----------+  +-----------+
|SA,DA      |  |SA,DA      |  |SA,DA      |  |SA,DA      |  |SA,DA      |
+-----------+  +-----------+  +-----------+  +-----------+  +-----------+
   SRv6 BE       SRv6 BE+        SRv6 TE       SRv6 SFC       SRv6 SFC+
                 TI-LFA                                         IOAM

   Figure 1.  Evolution of SRv6 SRH

   Compatibility challenges for legacy devices can be summarized as
   follows:

   *  Legacy devices need to upgrade software and/or hardware in order
      to support the processing of SRH

   *  As the SRH expands, the encapsulation overhead increases and
      correspondingly the effective payload decreases

   *  As the SRH expands, the hardware forwarding performance reduces
      which requires higher capabilities of the chipset

3.5.  SRv6 header overhead

   The rich network programming ability of SRv6 can meet the new network
   service requirements well.  In encapsulation mode, the SRv6 ingress
   encapsulates an outer IPv6 header and an SRH extension header into a
   packet and then forwards the packet.  This increases the packet
   header overhead.  When there are a large number of SRv6 SIDs, the
   following problems may occur:

Tian, et al.             Expires 30 August 2024                [Page 11]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   1.  The payload of packets decreases, and the effective transmission
   efficiency decreases.  For example, in an explicit path scenario, a
   maximum of 10 SRv6 SIDs may be used.  The total length of the IPv6
   header is 208 bytes.

   2.  The compatibility of devices on the live network.  As the number
   of SIDs increases, the position of the SID in the SRv6 packet may
   exceed the depth of the first read by the hardware.  As a result, the
   hardware performs the second read, and the forwarding performance
   deteriorates.

   3.  The packet header increases, which may cause the maximum
   transmission unit (MTU) to exceed the threshold.

4.  Solutions for mitigating the compatibility challenges

   This section provides solutions to mitigate the challenges outlined
   in section 2.

4.1.  Traffic Engineering

   With strict traffic engineering, the resultant long SID list in the
   SRH raises high requirements on the hardware chipset, which can be
   mitigated by the following solutions.

4.1.1.  Binding SID (BSID)

   Binding SID [RFC8402] involves a list of SIDs and is bound to an SR
   Policy.  The node(s) that imposes the bound policy needs to store the
   SID list.  When a node receives a packet with its active segment as a
   BSID, the node will steer the packet in to the bound policy
   accordingly.

   To reduce the long SID list of a strict TE explicit path, BSID can be
   used at selective nodes, maybe according to the processing capacity
   of the hardware chipset.  BSID can also be used to impose the repair
   list in the TI-LFA as described in Section 2.1.

4.1.2.  PCEP FlowSpec

   When the SR architecture adopts a centralized model, the SDN
   controller (e.g.  Path Computation Element (PCE)) only needs to apply
   the SR policy at the head-end.  There is no state maintained at
   midpoints and tail-ends.  Eliminating state in the network (midpoints
   and tail-points) is a key benefit of utilizing SR.  However, it also
   leads to a long SID list for expressing a strict TE path.

Tian, et al.             Expires 30 August 2024                [Page 12]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   PCEP FlowSpec [I-D.ietf-pce-pcep-flowspec] provides a trade-off
   solution.  PCEP FlowSpec is able to disseminate Flow Specifications
   (i.e. filters and actions) to indicate how the classified traffic
   flows will be treated.  In an SR-enabled network, PCEP FlowSpec can
   be applied at the midpoints to enforce traffic engineering policies
   where it is needed.  In that case, state needs to be maintained at
   the corresponding midpoints of a TE explicit path, but the SID list
   can be shortened.

4.2.  SFC

   Currently two approaches are proposed to support SFC over SRv6, i.e.
   stateless SFC [I-D.ietf-spring-sr-service-programming] and stateful
   SFC [I-D.ietf-spring-nsh-sr].

4.2.1.  Stateless SFC

   A service can also be assigned an SRv6 SID which is integrated into
   an SR policy and used to steer traffic to it.  In terms of the
   capability of processing the SR information in the received packets,
   there are two types of services, i.e. SR-aware service and SR-unware
   service.  An SR-aware service can process the SRH in the received
   packets.  An SR-unaware service, i.e. legacy service, is not able to
   process the SR information in the traffic it receives, and may drop
   the received packets.  In order to support such services in an SRv6
   domain, the SR proxy is introduced to handle the processing of SRH on
   behalf of the SR-unware service.  The service SID associated with the
   SR-unaware service is instantiated on the SR proxy, which is used to
   steer traffic to the service.

   The SR proxy intercepts the SR traffic destined for the service via
   the locally instantiated service SID, removes the SR information, and
   sends the non-SR traffic out on a given interface to the service.
   When receiving the traffic coming back from the service, the SR proxy
   will restore the SR information and forwards it to the next segment
   in the segment list.

4.2.2.  Stateful SFC

   The NSH and SR can be integrated in order to support SFC in an
   efficient and cost-effective manner while maintaining separation of
   the service and transport planes.

   In this NSH-SR integration solution, NSH and SR work jointly and
   complement each other.  Specifically, SR is responsible for steering
   packets along a given Service Function Path (SFP) while NSH is for
   maintaining the SFC instance context, i.e. Service Path Identifier
   (SPI), Service Index (SI), and any associated metadata.

Tian, et al.             Expires 30 August 2024                [Page 13]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   When a service chain is established, a packet associated with that
   chain will be first encapsulated with an NSH and then an SRH, and
   forwarded in the SR domain.  When the packet arrives at an SFF and
   needs to be forwarded to an SF, the SFF performs a lookup based on
   the service SID associated with the SF to retrieve the next-hop
   context (a MAC address) between the SFF and SF.  Then the SFF strips
   the SRH and forwards the packet with NSH carrying metadata to the SF
   where the packet will be processed as specified in [RFC8300].  In
   this case, the SF is not required to be capable of the SR operation,
   neither is the SR proxy.  Meanwhile, the stripped SRH will be updated
   and stored in a cache in the SFF, indexed by the NSH SPI for the
   forwarding of the packet coming back from the SF.

4.3.  Light Weight IOAM

   In most cases, after the IPv6 Destination Address (DA) is updated
   according to the active segment in the SRH, the SID in the SRH will
   not be used again.  However, the entire SID list in the SRH will
   still be carried in the packet along the path till a PSP/USP is
   enforced.

   The light weight IOAM method [I-D.li-spring-passive-pm-for-srv6-np]
   makes use of the used segments in the SRH to carry the IOAM
   information, which saves the extra space in the SRH and mitigate the
   requirements on the hardware.

4.4.  Postcard Telemetry

   Existing in-situ OAM techniques incur encapsulation and header
   overhead issues as described in section 2.  Postcard-based Telemetry
   with Packet Marking for SRv6 on-path
   OAM[I-D.song-ippm-postcard-based-telemetry], provides a solution that
   avoids the extra overhead for encapsulating telemetry-related
   instruction and metadata in SRv6 packets.

4.5.  SRv6 header compression

   draft-ietf-spring-srv6-srh-compression(C-SID) is adopted.  C-SID
   draft defines flavors for the SR endpoint behaviors, which enable a
   compressed SRv6 Segment-List encoding in the Segment Routing Header.

   Replace-C-SID Flavor a.k.a G-SRv6

   Next-C-SID Flavor a.k.a uSID

   Next-and-Replace-C-SID Flavor

Tian, et al.             Expires 30 August 2024                [Page 14]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   All the flavors are defined under the SRv6 network programming
   architecture RFC8986.

   For the SIDs in the SID list within an SRH, they may share the
   locator block, and the locator block is redundant that can be deleted
   to reduce the overhead.

   For example, the following 2 SID has the same Locator-Block and
   Argument.

      +------------------------------------------------------------------+
      | Locator-Block(A2:1/64)|Node-ID1 (01)|Func ID1 (05)|  Argument    |
      | Locator-Block(A2:1/64)|Node-ID1 (02)|Func ID1 (06)|  Argument    |
      +------------------------------------------------------------------+

   we use the different part of the SRv6 SID as a compressed SID(C-SID).
   The locator block is included in the first SID in the IPv6
   Destination address.

   The detailed behavior is defined in [I-D.ietf-spring-srv6-srh-
   compression].

   The interoperability test has been done by IOH.  About 15 testcases
   required for service interworking were passed.

5.  Design Guidance for SRv6 Network

5.1.  Locator and Address Planning

   Address Planning is a very important factor for s successful network
   design, especially an IPv6 network, which will directly affect the
   design of routing, tunnel, and security.  A good address plan can
   bring big benefit for service deployment and network operation.

   If a network has already deployed IPv6 and set up IPv6 subnets, one
   of the subnets can be selected for the SRv6 Locator planning, and the
   existing IPv6 address plan will not be impacted.

   If a network has not yet deployed IPv6 and there has not been an
   address plan, it needs to perform the IPv6 address planning first
   taking the following steps,

   1.  to decide the IPv6 address planning principles

   2.  to choose the IPv6 address assignment methods

   3.  to assign the IPv6 address in a hierarchical manner

Tian, et al.             Expires 30 August 2024                [Page 15]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   For an SRv6 network, in the first step for IPv6 address planning, the
   following principles are suggested to follow,

   1.  Unification: all the IPv6 addresses SHOULD be planned altogether,
       including service addresses for end users, platform addresses
       (for IPTV, DHCP servers), and network addresses for network
       devices interconnection.

   2.  Uniqueness: every single address SHOULD be unique.

   3.  Separation: service addresses and network addresses SHOULD be
       planned separately; the SRv6 Locator subnet, the Loopback
       interface addresses and the link addresses SHOULD be planned
       separately.

   4.  Aggregatability: when being distributed across IGP/BGP domains,
       the addresses in the preassigned subnets (e.g.  SRv6 Locator
       subnet, the Loopback interface subnet) SHOULD be aggregatable,
       which will make the routing easier.

   5.  Security: fast tracability of the assigned addresses SHOULD be
       facilitated, which will make the traffic filtering easier.

   6.  Evolvablity: enough address space SHOULD be reserved for each
       subset for future service development.

   Considering the above-mentioned IPv6 address planning principles, it
   has been adopted in some deployment cases to set Locator length
   96bits, function length 20bits, and args 12bits.

5.2.  PSP

   When Locator is imported in ISIS, the system will automatically
   assign END SID with Flavors such as PSP (Penultimate Segment Pop) and
   distribute the Locator subnet route through ISIS.

   The Flavor PSP, that is, SRH is popped at penultimate segment,
   provides the following benefits,

   1.  Reduce the load of ultimate segment endpoint.  Ultimate segment
       endpoint tends to have heavy load since it needs to handle the
       inner IP/IPv6/Ethernet payload and demultiplex the packet to the
       right overlay service.

   2.  Support of incremental deployment on existing network where the
       ultimate segment endpoint is low-end device that is not fully
       capable of handling SRH.

Tian, et al.             Expires 30 August 2024                [Page 16]
Internet-Draft        SRv6 Deployment Consideration        February 2024

6.  Incremental Deployment Guidance for SRv6 Migration

   Incremental deployment is the key for a smooth network migration to
   SRv6.  In order to quickly launch SRv6 network services and enjoy the
   benefits brought by SRv6, the recommended incremental SRv6 deployment
   steps are given as follows.  These are based on practical deployment
   experience earned from the use cases described in
   [I-D.matsushima-spring-srv6-deployment-status].

   The referenced network topology is shown in Figure 5.

                            /---- Path 1 ----\
 +------+    +----+    +---/--+           +---\--+    +----+    +------+
 |Site 1|----|PE 1|----|ASBR 1|  IP Core  |ASBR 2|----|PE 2|----|Site 2|
 +------+    +----+    +---\--+           +---/--+    +----+    +------+
                            \---- Path 2 ----/

                  Figure 5. Reference Network Topology

   Step1.  All the network devices are upgraded to support IPv6.

   Step 2.  According to service demands, only a set of selected PE
   devices are upgraded to support SRv6 in order to immediately deploy
   SRv6 overlay VPN services.  For instance, in Figure 3, PE1 and PE2
   are SRv6-enabled.

   Step 3.  Besides the PE devices, some P devices are upgraded to
   support SRv6 in order to deploy loose TE which enables network path
   adjustment and optimization.  SFC is also a possible service provided
   by upgrading some of the network devices.

   Step 4.  All the network devices are upgraded to support SRv6.  In
   this case, it is now possible to deploy strict TE, which enables the
   deterministic networking and other strict security inspection.

7.  Migration Guidance for SRv6/SR-MPLS Co-existence Scenario

   As the network migration to SRv6 is progressing, in most cases
   SRv6-based services and SR-MPLS-based services will coexist.

   As shown in Figure 6, in the Non-Standalone (NSA) case specified by
   3GPP Release 15, 5G networks will be supported by existing 4G
   infrastructure. 4G eNB connects to CSG 2, 5G gNB connects to CSG 1,
   and EPC connects to RSG 1.

   To support the 4G services, network services need to be provided
   between CSG 2 and RSG 1 for interconnecting 4G eNB and EPC, while for
   the 5G services, network services need to be deployed between CSG 1

Tian, et al.             Expires 30 August 2024                [Page 17]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   and RSG 1 for interconnecting 5G gNB and EPC.  Meanwhile, to support
   X2 interface between the eNB and gNB, network services also need to
   be deployed between the CSG 1 and CSG 2.

      +-----+
      | eNB |------\
      +-----+       \
                  +-----+
                  |CSG 2|-------+-----+             +-----+      +-----+
                 /+-----+       |ASG 1|-------------|RSG 1|------| EPC |
 +-----+     +--/--+            +-----+             +-----+      +-----+
 | gNB |-----|CSG 1|   Domain 1    |     Domain 2      |
 +-----+     +--\--+            +-----+             +-----+
                 \+-----+       |ASG 2|-------------|RSG 2|
                  |CSG 3|-------+-----+             +-----+
                  +-----+

             Figure 6. A 3GPP Non-Standalone deployment case

   As shown in Figure 6, in most of the current network deployments,
   MPLS-based network services may have already existed between CSG 2
   and RSG 1 for interconnecting 4G eNB and EPC for 4G services.

   When 5G services are to be supported, more stringent network services
   are required, e.g. low latency and high bandwidth.  SRv6-based
   network services could be deployed between CSG 1 and RSG 1 for
   interconnecting 5G gNB and EPC.

   In order to perform smooth network migration, a dual-stack solution
   can be adopted which deploys both SRv6 and MPLS stack in one node.

   With the dual-stack solution, only CSG 1 and RSG 1 need to be
   upgraded with SRv6/MPLS dual stack.  In this case, CSG 1 can
   immediately start SRv6-based network services to RSG 1 for support of
   5G services, but continue to use MPLS-based services to CSG 2 for X2
   interface communications.  The upgrade at CSG 1 will not affect the
   existing 4G services supported by the MPLS-based network services
   between CSG 2 and RSG 1.  RSG1 can provide MPLS services to CSG2 for
   4G services as well as SRv6 services to CSG 1 for 5G services.

8.  Deployment cases

   With the current network, the launch of leased line service is slow,
   the network operation and maintainence is complex, and the
   configuration points are many.  SRv6 can solve the issues above.
   There have already been several successful SRv6 deployments following
   the incremental deployment guidance shown in Section 3.

Tian, et al.             Expires 30 August 2024                [Page 18]
Internet-Draft        SRv6 Deployment Consideration        February 2024

8.1.  China Telecom Si'chuan

   China Telecom Si'chuan (Si'chuan Telecom) has enabled SRv6 at the PE
   node of the Magic-Mirror DC in Mei'shan, Cheng'du, Pan'zhihua and
   other cities.  The SRv6 BE tunnel has been deployed through the 163
   backbone network which has the IPv6 capability.  It enables the fast
   launch of the Magic-Mirror video service, the interconnection of the
   DCs in various cities, and the isolation of video services.  The
   deployment case is shown in Figure 7.

                           /---------163--------\
+------+                  /                      \                 +-------+
| Magic|    +----+    +--/-+                   +--\-+    +----+    | Magic |
|Mirror|----|PE 1|----|CR 1|    IP Backbone    |CR 2|----|PE 2|----|Mirror |
| DC 1 |    +----+    +--\-+                   +--/-+    +----+    | DC 2  |
+------+                  \                      /                 +-------+
                         +-\---+            +---/-+
                         |ASBR1|----CN2-----|ASBR2|
                         +-----+            +-----+

              IGP/IBGP             EBGP               IGP/IBGP
             |<------->|<-------------------------->|<-------->|
                                 EBGP VPNv4 Peer
             |<----------------------------------------------->|
                                L3VPN over SRv6
             |<----------------------------------------------->|

            Figure 7. China Telecom Si'chuan deployment case

   As shown in Figure 7, IGP (some cities such as Chengdu deploy ISIS,
   while other cities such as Panzhihua deploy OSPF) and IBGP are
   deployed between PE and CR, and EBGP is deployed between CRs of
   cities in order to advertise the aggregation route.  EBGP VPNv4 peers
   are set up between PEs in different cities to deliver VPN private
   network routes.

   The packet enters the SRv6 BE tunnel from the egress PE of DC, and
   the packet is forwarded according to the Native IP of the 163
   backbone network.  When the packet reaches the peer PE, the SRH is
   decapsulated, and then the IP packet is forwarded in the VRF
   according to the service SID (for example, End.DT4).

   In order to further implement the path selection, ASBRs can be
   upgraded to support SRv6.  Different SRv6 policies are configured on
   the DC egress PE so that different VPN traffic reaches the peer PE
   through the 163 backbone network and the CN2 backbone network
   respectively.

Tian, et al.             Expires 30 August 2024                [Page 19]
Internet-Draft        SRv6 Deployment Consideration        February 2024

8.2.  China Unicom

   China Unicom has deployed SRv6 L3VPN over 169 IPv6 backbone network
   from Guangzhou to Beijing to provide inter-domain Cloud VPN service.
   The deployment case is shown in Figure 8.

      /-------------\         /------------\         /-----------\
   +-/-+ Guangzhou +-\-+   +-/-+   IPv6   +-\-+   +-/-+ Beijing +-\-+
   |PE1|           |CR1|---|CR2| Backbone |CR3|---|CR4|         |PE2|
   +-\-+   Metro   +-/-+   +-\-+    169   +-/-+   +-\-+  Metro  +-/-+
      \-------------/         \------------/         \-----------/

    |<--OSPF/ISIS-->|<-EBGP->|<-Native IPv6->|<-EBGP->|<-OSPF/ISIS->|
    |<----------------------- EBGP VPNv4 Peer --------------------->|
    |<----------------------- L3VPN over SRv6 --------------------->|

                   Figure 8. China Unicom SRv6 L3VPN case

   In Guangzhou and Beijing metro networks, routers exchange basic
   routing information using IGP(OSPF/ISIS).  The prefixes of IPv6
   loopback address and SRv6 locator of routers are different, and both
   of them need to be imported into the IGP.  The 169 backbone is a
   native IPv6 network.  Between metro and backbone, the border routers
   establish EBGP peer with each other, e.g.  CR1 with CR2, CR3 with
   CR4, to form basic connectivity.  All of these constitute the
   foundation of overlay services, and have not been changed.

   PE1 and PE2 establish EBGP peer and advertise VPNv4 routes with each
   other.  If one site connects to two PEs, metro network will use multi
   RD, community and local preference rules to choose one best route and
   one backup.

   After basic routing among networks and VPN routes between the two PEs
   are all ready, two PEs encapsulate and forward VPN traffic within
   SRv6 tunnel.  The tunnel is SRv6 best effort (BE) tunnel.  It
   introduces only outer IPv6 header but not SRH header into traffic
   packets.  After encapsulation, the packet is treated as common IPv6
   packet and forwarded to the egress PE, which performs decapsulation
   and forwards the VPN traffic according to specific VRF.

   Guangdong Unicom has also launched the SRv6 L3VPN among Guangzhou,
   Shenzhen, and Dongguan, which has passed the interop test between
   different vendors.

   With SRv6 enabled at the PE devices, the VPN service can be launched
   very quickly without impact on the existing traffic.  With SRv6 TE
   further deployed, more benefits of using SRv6 can be exploited.

Tian, et al.             Expires 30 August 2024                [Page 20]
Internet-Draft        SRv6 Deployment Consideration        February 2024

8.3.  MTN Uganda

   MTN Uganda has enabled SRv6 at the MPBN PE/P nodes.  The SRv6 BE
   tunnel has been deployed through the MPBN network which has the IPv6
   capability.  It enables the fast service provisoning for mobile
   service, enterprise service and internal IT services, and also
   improves service SLA such as service monitoring and availability.
   The deployment case is shown in Figure 9.

      +-----+
      | eNB |----\
      +-----+     \
                +-----+                                   /------------\
                |CSG 2|-----+-----+      +-----+      +--/--+        +--\--+
               /+-----+     |ASG 1|------|RSG 1|------|ASBR1|        |ASBR4|
 +-----+   +--/--+    IPV6  +-----+ IPV6 +-----+      +-----+  IPV6  +-----+
 | gNB |---|CSG 1|  Domain 1   |  Domain 1  |            |   Domain 2   |
 +-----+   +--\--+          +-----+      +-----+      +-----+ IPCORE +-----+
               \+-----+     |ASG 2|------|RSG 2|------|ASBR2|        |ASBR3|
                |CSG 3|-----+-----+      +-----+      +--\--+        +--/--+
                +-----+                                   \------------/
          |<--------------ISIS------------->|<---EBGP-->|<----ISIS----->|
Phase I:
          |<-----RSVP TE----->|<--RSVP TE-->|<-OPTIONA->|<---SRv6 BE--->|
Phase II:
          |<-----------------L2/3 EVPN over SRv6 Policy --------------->|
                  Figure 9. MTN Uganda Deployment Case

   As shown in the Figure 9,

   In the phase I, SRv6 BE was deployed in MPBN network.  All services
   in the MPBN will be carried through SRv6 BE in the core network.  The
   Option A is deployed between the IPRAN network and Core network.

   In the phase II, SRv6 Policy will be deployed E2E from IPRAN to Core.
   Cross-domain path selection is available for mobile and enterprise
   services.  The service will be carried in SRv6 Policy through the
   entire MPBN network.

   L3VPN and L2VPN services will evolve to EVPN to simplify the network
   operation and management.

8.4.  Agricultural Bank of China (ABC)

   ABC has deployed the network controller and SRv6 policy over its
   backbone network to automatically optimize link traffic.  The
   deployment case is shown in Figure 10.

Tian, et al.             Expires 30 August 2024                [Page 21]
Internet-Draft        SRv6 Deployment Consideration        February 2024

          +-----+    +----+                      +----+    +-----+
          |DC-PE|----|DC-P|----------------------|DC-P|----|DC-PE|
         /+-----+    +----+                      +----+    +-----+ \
        /    |  \    /  |                          |  \    /  |     \
    +--/-+   |   \  /   |                          |   \  /   |   +--\-+
    | DC |   |    \/    |         Backbone         |    \/    |   | DC |
    +--\-+   |    /\    |                          |    /\    |   +--/-+
        \    |   /  \   |                          |   /  \   |     /
         \+-----+    +----+                      +----+    +-----+ /
          |DC-PE|----|DC-P|----------------------|DC-P|----|DC-PE|
          +-----+    +-\--+                      +-/--+    +-----+
                        \                         /
                         \+-----+         +-----+/
                          |BR-PE|---------|BR-PE|
                          +-----+         +-----+
                    Figure 10. ABC Deployment Case

   In the original network deployment, SR-MPLS TE tunnels were used to
   construct the backbone network.  There are two problems.  First,
   these tunnels must be planned and configured manually.  Second, the
   SR-TE is based on MPLS and hard to be extended to a branch to
   implement end-to-end traffic management.

   Now, The SRv6 Policy is used to implement intelligent and centralized
   path computation to carry services between data centers and between
   branches and data centers.  Multiple VPNs are divided by service, and
   SRv6 policies are selected based on the combination of VPN and DSCP.
   About 1800 SRv6 policies are deployed on the entire network.

   Both SRv6 and VxLAN are deployed at DC-PE to implement tunnel
   interworking between the DC network and the SRv6 backbone network.

   SBFD is deployed to detect SRv6 policy connectivity.  When a path
   fails, traffic can be quickly switched to other normal paths.

   The backbone network uses IFIT (In-situ Flow Information Telemetry)
   to implement service-level SLA detection.

8.5.  Indosat Ooredoo Hutchison

   Some scenarios of SRv6 usecase may require long SRv6 SID lists.  So
   the SPRING working group formed the design team to define the method
   of reducing SRH encapsulation size.

Tian, et al.             Expires 30 August 2024                [Page 22]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   Currently some vendors have implemented the compression function.
   IOH has conducted the SRv6 header compression interoperability test.
   The locator address in this interoperability test used 32 16 format
   SID, six 16-bit SID/instruction encoded with 40B of overhead compare
   to SRv6 BE (non-compression) which need 112B.  SRv6 compression could
   improve the MTU efficiency and save the bandwidth significantly.

   The test topology is shown in Figure 11.

             +-----------------+
             |                 |
           +---+    +---+    +---+
           |R21|----|R22|----|R23|
           +---+    +---+    +---+
                \     |  \     |
                 \    |   \    |
                  \   |    \   |
                   \  |     \  |
                    +---+    +---+
                    |R11|----|R12|
                    +---+    +---+
                      |  \  /  |
                      |  +--+  |
                      |  |RS|  |
                      |  +--+  |
                      |  /  \  |
                    +---+    +---+
                    |R13|----|R14|
                    +---+    +---+

            Figure 11. Test Topology

   In the test topology, R21/R22/R23 are Huawei devices, and
   R11/R12/R13/R14/RS are Cisco devices.  R11/R12/R21/R22 simulate as
   IPCORE Router, R13/R14/R23 simulate as IPRAN Router, and RS simulates
   Route Server.

   All the following test cases required for service interworking were
   passed.

   ISISv6 Control Plane Establishment

   ISISv6 Forwarding

   SRv6 OAM

   SRv6 MP-BGP Overlay Establishment

Tian, et al.             Expires 30 August 2024                [Page 23]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   SRv6 Policy uSID Explicit Path Establishment

   SRv6 L3VPNv4/v6 Data Plane Services Interop (BE/Best Path)

   SRv6 L3VPNv4/v6 Services Interop with SRv6 Policy Explicit Path
   (Automated Steering)

   SRv6 EVPN Single Home Data Plane Services Interop (BE/Best Path)

   BGP IPv4 Establishment (RS to all CE) through SRv6 EVPN Single Home
   (BE / Best Path)

   SRv6 EVPN ELAN Single Home Services Interop with SRv6 Policy Explicit
   Path (Automated Steering)

   SRv6 4PE/6PE (Global Routing Table) Services Interop (BE/Best Path)

   SRv6 EVPN VPWS over SRv6 BE

   SRv6 EVPN VPWS Interop with SRv6 uSID ExplicitPath(Automated
   Steering)

   SRv6 TI-LFA

   SRV6 EVPN ELAN Multihoming/Single-Active scenario

8.6.  Orange Spain

   OSP's network include three parts, IP Backbone Network(IPBB), Mobile
   Backhaul Network(MBH) and Fix Backhaul Network(FBH).  SRv6 has been
   deployed to achieve following goals:

   Enhanced Functionality: The IP Network should be fully capable of
   supporting existing Dialog network services as well as enabling a
   comprehensive range of new services and next-generation capabilities.

   Enhanced Capacity: The IP Network should offer a significant capacity
   upgrade of core network bandwidth and switching capacity that is
   capable of supporting current and next-generation network services
   through the near future.

   Optimum Resilience: The IP Network will support many services
   critical to the Dialog business.

   Simplicity: The network should be straightforward to implement, easy
   to understand and easy to maintain.

   The phase 1 deployment case is shown in Figure 12.

Tian, et al.             Expires 30 August 2024                [Page 24]
Internet-Draft        SRv6 Deployment Consideration        February 2024

 +-----+            ---------Controller-------
 | eNB |---\       /       /        |         \
 +-----+    \     /       /         |          \
           +-----+    +-----+    +-----+      +----+    +----+      +----+
           |CSG 1|----|POC 1|----|POP 1|------| PE |----| DN |------| DN |
           +-----+    +-----+    +-----+      +----+    +----+      +----+
 +-----+    /     \  /       \  /   |            |         |           |
 | gNB |---/       \/         \/    |            |         |   IPBB    |
 +-----+           /\         /\    |            |         |           |
                  /  \       /  \   |            |         |           |
           +-----+    +-----+    +-----+      +----+    +----+      +----+
           |CSG 2|----|POC 2|----|POP 2|------| PE |----| DN |------| DN |
           +-----+    +-----+    +-----+      +----+    +----+      +----+
           |<----------ISIS L1-------->|<-ISIS L2->|
           |<-------------SRv6 Policy------------->|
           |<-------L3VPN over SRv6 Policy-------->|
         Figure 12. Orange Spain deployment usecase

   Controller manage CSGs, POCs, POPs, PEs, and have the ability to
   analysis, control the Network.

   In phase 1, dual-stack ISISv4 and ISISv6 will be deployed in the
   Network.  SRv6 Policy will be deployed from CSG to PE.  For 4G/5G
   Service, L3VPN over MPLS will be migrated to L3VPN over E2E SRv6
   Policy.  Controller computes E2E SRv6 policy from CSG to PE.

   In phase 2, POP from MBH connect to DN directly.  The 5G traffic will
   pass through MBH and IPBB, End to End SRv6 Tunnel will be deployed
   from CSG to IPBB PE for 4G/5G service in OSP whole network.  Multi
   vendors' device shoulde be interconnected and 16 bits Compress
   solution will be deployed that time.

9.  Contributors

   The following people also gave a substantial contribution to the
   content of this document and should be considered as coauthors:

   Zhenbin Li, Huawei Technologies, lizhenbin@huawei.com

   Yaqun Xiao, Huawei Technologies, xiaoyaqun@huawei.com

   Hailong Bai, China Unicom

   Jichun Ma, China Unicom

   Huizhi Wen, Huawei Technologies, wenhuizhi@huawei.com

   Ruizhao Hu, Huawei Technologies, huruizhao@huawei.com

Tian, et al.             Expires 30 August 2024                [Page 25]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   Jianwei Mao, Huawei Technologies, maojianwei@huawei.com

   Feng Zhao, CAICT, zhaofeng@caict.ac.cn

   Tong Li, China Unicom, litong@chinaunicom.cn

   Robbins Mwehaire, MTN Uganda Ltd., Robbins.Mwehair@mtn.com

   Qingbang Xu, Agricultural Bank of China, michbang@163.com

   Primadi Hendra Kusuma, Indosat Ooredoo Hutchison,
   primadi.kusuma@ioh.co.id

   Tianran Zhou, Huawei Technologies, zhoutianran@huawei.com

   Keyi Zhu, Huawei Technologies, zhukeyi@huawei.com

10.  IANA Considerations

   There are no IANA considerations in this document.

11.  Security Considerations

   TBD.

12.  Acknowledgement

   The section on the PSP use cases is inspired from the discussions
   over the mailing list.  The authors would like to acknowledge the
   constructive discussions from Daniel Voyer, Jingrong Xie, etc..

13.  References

13.1.  Normative References

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", Work in Progress, Internet-
              Draft, draft-ietf-spring-srv6-network-programming-28, 29
              December 2020, <https://datatracker.ietf.org/doc/html/
              draft-ietf-spring-srv6-network-programming-28>.

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

Tian, et al.             Expires 30 August 2024                [Page 26]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
              DOI 10.17487/RFC5659, October 2009,
              <https://www.rfc-editor.org/info/rfc5659>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

13.2.  Informative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", Work in Progress, Internet-Draft, draft-ietf-6man-
              segment-routing-header-26, 22 October 2019,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              segment-routing-header-26>.

   [I-D.ietf-6man-spring-srv6-oam]
              Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
              Chen, "Operations, Administration, and Maintenance (OAM)
              in Segment Routing over IPv6 (SRv6)", Work in Progress,
              Internet-Draft, draft-ietf-6man-spring-srv6-oam-13, 23
              January 2022, <https://datatracker.ietf.org/doc/html/
              draft-ietf-6man-spring-srv6-oam-13>.

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
              for In Situ Operations, Administration, and Maintenance
              (IOAM)", Work in Progress, Internet-Draft, draft-ietf-
              ippm-ioam-data-17, 13 December 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
              ioam-data-17>.

   [I-D.ietf-pce-pcep-flowspec]
              Dhody, D., Farrel, A., and Z. Li, "Path Computation
              Element Communication Protocol (PCEP) Extension for Flow

Tian, et al.             Expires 30 August 2024                [Page 27]
Internet-Draft        SRv6 Deployment Consideration        February 2024

              Specification", Work in Progress, Internet-Draft, draft-
              ietf-pce-pcep-flowspec-13, 14 October 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              pcep-flowspec-13>.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
              Decraene, B., and D. Voyer, "Topology Independent Fast
              Reroute using Segment Routing", Work in Progress,
              Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
              13, 16 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
              segment-routing-ti-lfa-13>.

   [I-D.ietf-spring-nsh-sr]
              Guichard, J. and J. Tantsura, "Integration of Network
              Service Header (NSH) and Segment Routing for Service
              Function Chaining (SFC)", Work in Progress, Internet-
              Draft, draft-ietf-spring-nsh-sr-15, 6 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              nsh-sr-15>.

   [I-D.ietf-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
              Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
              S. Salsano, "Service Programming with Segment Routing",
              Work in Progress, Internet-Draft, draft-ietf-spring-sr-
              service-programming-09, 20 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-service-programming-09>.

   [I-D.li-spring-passive-pm-for-srv6-np]
              Li, C. and M. Chen, "Passive Performance Measurement for
              SRv6 Network Programming", Work in Progress, Internet-
              Draft, draft-li-spring-passive-pm-for-srv6-np-00, 5 March
              2018, <https://datatracker.ietf.org/doc/html/draft-li-
              spring-passive-pm-for-srv6-np-00>.

   [I-D.matsushima-spring-srv6-deployment-status]
              Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman,
              K., and A. Dhamija, "SRv6 Implementation and Deployment
              Status", Work in Progress, Internet-Draft, draft-
              matsushima-spring-srv6-deployment-status-15, 5 April 2022,
              <https://datatracker.ietf.org/doc/html/draft-matsushima-
              spring-srv6-deployment-status-15>.

Tian, et al.             Expires 30 August 2024                [Page 28]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   [I-D.song-ippm-postcard-based-telemetry]
              Song, H., Mirsky, G., Zhou, T., Li, Z., Graf, T., Mishra,
              G. S., Shin, J., and K. Lee, "On-Path Telemetry using
              Packet Marking to Trigger Dedicated OAM Packets", Work in
              Progress, Internet-Draft, draft-song-ippm-postcard-based-
              telemetry-16, 2 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-song-ippm-
              postcard-based-telemetry-16>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses

   Hui Tian
   CAICT
   China
   Email: tianhui@caict.ac.cn

   Chongfeng Xie
   China Telecom
   China
   Email: xiechf.bri@chinatelecom.cn

   Edmore Chingwena
   MTN Group Limited
   South Africa
   Email: Edmore.Chingwena@mtn.com

   Shuping Peng
   Huawei Technologies
   China
   Email: pengshuping@huawei.com

   Qiangzhou Gao
   Huawei Technologies
   China

Tian, et al.             Expires 30 August 2024                [Page 29]
Internet-Draft        SRv6 Deployment Consideration        February 2024

   Email: gaoqiangzhou@huawei.com

Tian, et al.             Expires 30 August 2024                [Page 30]