[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                             C. Xie
Internet-Draft                                                     C. Li
Intended status: Informational                             China Telecom
Expires: January 9, 2020                                         S. Peng
                                                                   Z. Li
                                                                 Y. Xiao
                                                     Huawei Technologies
                                                            July 8, 2019


                         SRv6 Network Migration
               draft-xie-spring-srv6-network-migration-00

Abstract

   SRv6 has significant advantages over SR-MPLS which has attracted more
   and more attentions and interests from operators and verticals.  The
   smooth network migration towards SRv6 is a key focal point for the
   SRv6 deployers.  This document provides network migration guidance
   and recommendations on solutions in various scenarios.

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 January 9, 2020.








Xie, et al.              Expires January 9, 2020                [Page 1]


Internet-Draft           SRv6 Network Migration                July 2019


Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Advantages of SRv6  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  IP Route Aggregation  . . . . . . . . . . . . . . . . . .   3
     2.2.  End-to-end Service Auto-start . . . . . . . . . . . . . .   4
     2.3.  On-Demand Upgrade . . . . . . . . . . . . . . . . . . . .   5
   3.  Incremental Deployment Guidance for SRv6 Migration  . . . . .   6
   4.  Migration Guidance for SRv6/SR-MPLS Co-existence Scenario . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   SRv6 [I-D.ietf-spring-srv6-network-programming] has significant
   advantages over SR-MPLS and has attracted more and more attentions
   and interests from operators and verticals.  The smooth network
   migration towards SRv6 is a key focal point for the SRv6 deployers.

   SRv6 is the Segment Routing deployed on the IPv6 data plane[RFC8200].
   Therefore, in order to support SRv6, the network needs to support
   IPv6 first.  As being actively promoted all over the world, the
   deployments of IPv6 have been ever-increasing which provides the
   strong base for the deployments of SRv6.

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



Xie, et al.              Expires January 9, 2020                [Page 2]


Internet-Draft           SRv6 Network Migration                July 2019


   in the hardware it needs to support the new SRv6 header
   SRH[I-D.ietf-6man-segment-routing-header], the design of SRv6 assures
   the compatibility with the existing IPv6 network.  An SRv6 SID is
   designed as an IPv6 address with 128bits long.  From the
   encapsulation aspect 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 services supported by SRv6 increase, e.g.  SFC, network
   slicing, more SIDs in the SRH may impose new requirements on the
   hardware.  Besides hardware upgrading, various solutions
   [I-D.peng-spring-srv6-compatibility] have already been proposed to
   relief the imposed pressure on the hardware, such as BSID etc. to
   guarantee the compatibility with the existing network.  On the other
   hand SRv6 has much more advantages over SR-MPLS for the network
   migration to support new services.

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

2.  Advantages of SRv6

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

2.1.  IP Route Aggregation

   It has been many years that the operators are troubled by the
   complexity of the service deployments, especially in the large scale
   networking scenario.  With the solutions such as multi-segment PW and
   Option A, the service-touch points are increased, and the services or
   OAM cannot be deployed end-to-end.

   o  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 routes LSPs might need
      to be imported, which places big challenges on the capabilities of
      the edge nodes.

   o  With SRv6, owning to its native IP feature of route
      aggregatability as shown in Figure 1b, the aggregated routes can
      be imported across network domains.  For the large scale
      networking, only very few aggregated routes are needed in order to




Xie, et al.              Expires January 9, 2020                [Page 3]


Internet-Draft           SRv6 Network Migration                July 2019


      start end-to-end services, which also reduces the scalability
      requirements on the edge nodes.

     /------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 needs to be imported to other
   domains.




Xie, et al.              Expires January 9, 2020                [Page 4]


Internet-Draft           SRv6 Network Migration                July 2019


   o  With SR-MPLS, SRGB and Node SID need the overall network-wide
      planning.  However, in the cross-domain scenario, it is difficult
      or sometimes even impossible to perform the overall planning.  The
      node SIDs in different domains may collide.  BGP Prefix SID can be
      used for the cross-domain SID import, but it must be careful when
      converting the SID to avoid the SID collision.  Moreover, the pre-
      allocated SRGB within each domain needs to consider the total
      number of devices in all other domains, which raises the
      difficulties of the network-wide planning.

   o  With SRv6&#65292;owning to its native IP feature of route
      reachability, as long as the IPv6 address space is carefully
      planned, and the aggregated routes are imported by using BGP4+,
      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

   With either way, big changes in a wide area are required at the
   initial stage therefore causes a long time-to-market.

   On the contrary, the network can be migrated to SRv6 on demand.
   Wherever the services need to turn 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 to be aware of SRv6.  When the
   TE services are needed, only the key nodes along the path needs to be
   upgraded to support SRv6.










Xie, et al.              Expires January 9, 2020                [Page 5]


Internet-Draft           SRv6 Network Migration                July 2019


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

3.  Incremental Deployment Guidance for SRv6 Migration

   The incremental deployment is the key for smooth 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 the practical
   deployment experience earned from the cases such as China Telecom
   described in [I-D.matsushima-spring-srv6-deployment-status].

   The referenced network topology is shown in Figure 3.











Xie, et al.              Expires January 9, 2020                [Page 6]


Internet-Draft           SRv6 Network Migration                July 2019


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

                  Figure 3. 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 the possible service
   provided by upgrading part of network devices.

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

4.  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 4, in the Non-Standalone (NSA) case specified by
   3GPP Release 15 that 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.

   For supporting 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
   and RSG 1 for interconnecting 5G gNB and EPC.  Meanwhile, for
   supporting X2 interface between the eNB and gNB, network services
   also need to be deployed between the CSG 1 and CSG 2.










Xie, et al.              Expires January 9, 2020                [Page 7]


Internet-Draft           SRv6 Network Migration                July 2019


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

             Figure 4. A 3GPP Non-Standalone deployment case


   As shown in Figure 4, 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 sevices.

   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, dual-stack solution can
   be adopted which deploy 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 supporting
   5G services, but continue to using 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.

5.  IANA Considerations

   There are no IANA considerations in this document.

6.  Security Considerations

   TBD.







Xie, et al.              Expires January 9, 2020                [Page 8]


Internet-Draft           SRv6 Network Migration                July 2019


7.  References

7.1.  Normative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-
              header-21 (work in progress), June 2019.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-ietf-spring-srv6-network-
              programming-01 (work in progress), July 2019.

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

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

7.2.  Informative References

   [I-D.matsushima-spring-srv6-deployment-status]
              Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6
              Implementation and Deployment Status", draft-matsushima-
              spring-srv6-deployment-status-01 (work in progress), May
              2019.

   [I-D.peng-spring-srv6-compatibility]
              Peng, S. and Z. Li, "SRv6 Compatibility with Legacy
              Devices", draft-peng-spring-srv6-compatibility-00 (work in
              progress), October 2018.

Authors' Addresses











Xie, et al.              Expires January 9, 2020                [Page 9]


Internet-Draft           SRv6 Network Migration                July 2019


Chongfeng Xie
China Telecom
China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing  102209
China

Phone: +86-10-50902116
Email: xiechf.bri@chinatelecom.cn


Cong Li
China Telecom
China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District
Beijing  102209
China

Phone: +86-10-50902556
Email: licong.bri@chinatelecom.cn


   Shuping Peng
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: pengshuping@huawei.com


   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Yaqun Xiao
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: xiaoyaqun@huawei.com






Xie, et al.              Expires January 9, 2020               [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/