RTGWG                                                            M. Wang
Internet-Draft                                                    Q. Cai
Intended status: Informational                                    L. Han
Expires: 28 April 2022                                      China Mobile
                                                                 R. Chen
                                                         ZTE Corporation
                                                         25 October 2021


                       cloud-network integration
             draft-wang-rtgwg-cloud-network-integration-00

Abstract

   This document describes cloud-network integration scenario and
   networking technologies.

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 28 April 2022.

Copyright Notice

   Copyright (c) 2021 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.




Wang, et al.              Expires 28 April 2022                 [Page 1]


Internet-Draft          cloud-network integration           October 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Interworking scenarios  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Multiple domains with common border nodes . . . . . . . .   3
     3.2.  Multiple domains with no common border nodes  . . . . . .   4
   4.  Networking Technologies . . . . . . . . . . . . . . . . . . .   4
     4.1.  Metro network does not support SRv6 . . . . . . . . . . .   5
     4.2.  Some nodes of the metro network support SRv6  . . . . . .   5
     4.3.  Metro network support SRv6  . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   With the development of Internet+, the convergence trend of cloud and
   network is increasingly obvious.  More and more services and
   applications will be carried on the cloud data centers.  In order to
   support new services and applications requirements and meet the
   security requirements for data not going out of the park, therefore
   the deployment location of the cloud/data center is also lowered from
   the original regional DC and core DC to the edge DC.

   As the interconnection network between the regional DC and the core
   DC, the cloud transport network is usually a backbone network.
   However, with the deployment of the edge DC, in order to avoid new
   construction of a huge cloud transport network, the existing metro
   network is used to access the edge DC.  The interconnection between
   edge DCs and regional DC/core DCs is implemented through the
   coordination between the metro and cloud transport network.
   Therefore, the interconnection solution between the cloud transport
   and metro network needs to be considered.

   In addition, the access point of enterprises entering the cloud is
   usually in the metro network, and the dedicated line entering the
   cloud also involves the interconnection between the cloud transport
   and metro network.

   This document describes cloud-network integration scenario and
   networking technologies.







Wang, et al.              Expires 28 April 2022                 [Page 2]


Internet-Draft          cloud-network integration           October 2021


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

   cloud transport network: It is usually a national or province
   backbone network to achieve interconnection between multiple regional
   clouds/core clouds deployed in the country/province.

3.  Interworking scenarios

   This section defines two interworking scenarios.

3.1.  Multiple domains with common border nodes

   In this scenario, the boundary node of the cloud transport network
   serves as the boundary node of the metro network.  As shown in the
   figure below.  Node 4 serves as the boundary node of the metro
   network as well as the boundary node of the cloud transport network.


                        +---+                 +---+
              +---------| 2 |--------+--------| 5 | --------+
              |         +---+        |        +---+         |
              |                      |                      |
              |                      |                      |
            +----+    Metro        +---+      cloud       +---+
            | 1  |                 | 4 |     transport    | 7 |
            +----+                 +---+                  +---+
              |                      |                      |
              |                      |                      |
              |         +---+        |        +---+         |
              +---------| 3 |--------+--------| 6 |---------+
                        +---+                 +---+

                                  Figure 1

   The following applies to the reference topology above:

   *  Independent IGP instance in metro region.

   *  Independent IGP instance in cloud transport region.

   *  If the scale of the metro network is large, sometimes it may reach
      thousands or even tens of thousands of nodes.  At this time, the
      metro network will be divided into multiple IGPs.




Wang, et al.              Expires 28 April 2022                 [Page 3]


Internet-Draft          cloud-network integration           October 2021


   *  The cloud transport and metro network can have different
      controllers or under the same controller.

3.2.  Multiple domains with no common border nodes

   In this scenario, the cloud transport network and the metro network
   do not have a common border nodes, and the border node of the two
   networks are connected by a direct link.  As shown below.


                  +---+                             +---+
        +---------| 2 |--------+           +--------| 6 | --------+
        |         +---+        |           |        +---+         |
        |                      |           |                      |
        |                      |           |                      |
      +----+    Metro        +---+       +---+      cloud       +---+
      | 1  |                 | 4 |------ | 5 |     transport    | 8 |
      +----+                 +---+       +---+                  +---+
        |                      |           |                      |
        |                      |           |                      |
        |         +---+        |           |         +---+        |
        +---------| 3 |--------+           +---------| 7 |--------+
                  +---+                              +---+

                                  Figure 2

   In the interworking scenario described in Section 3.1, since two
   domains have the same domain boundary node, so the route mutual
   import can be used by the border node to interconnect the two
   domains.  In this section, the EBGP needs to be deployed between the
   domains to connect the routes of the two domains.

   In this scenario, hierarchical controller architecture usually be
   considered, that is, the cloud transport and metro network have an
   independent controller, and cross-domain controllers are used to
   achieve the coordination of the two domains.  If two domains need to
   be under the same controller, higher requirements are required, such
   as the controller needs to support a standardized unified southbound
   interface and so on.

4.  Networking Technologies

   This section defines three networking technologies.








Wang, et al.              Expires 28 April 2022                 [Page 4]


Internet-Draft          cloud-network integration           October 2021


4.1.  Metro network does not support SRv6

   Based on existing networks, typically, the metro network does not
   support the SRv6 and does not have the ability to upgrade to support
   SRv6.  For example, the earlier deployed metro network supports
   LDP/RSVP/MPLS-TP and traditional L2VPN or L3VPN services.  However,
   the recently deployed metro network may support SR-MPLS/SR-TP, but it
   still cannot support SRv6 due to its hardware capability.

   In this scenario, segment splicing of different network technologies
   is mainly used to achieve end-to-end connection of services.

4.2.  Some nodes of the metro network support SRv6

   In some cases, the metro network devicee connected to the edge DC
   will be upgraded or replaced to support SRv6, while the rest of the
   devices should be kept as old as possible and not replaced, so as to
   avoid the need for more cost investment or avoid affecting the
   existing services of the metro network.

   As shown in Figure 1 or Figure 2, node 4 in metro network is upgraded
   to support SRv6, while the remaining nodes in metro network do not
   support SRv6.Cloud transport network supports SRv6.  In this
   scenario, SRv6 is used for end-to-end service connection.  The main
   consideration is how end-to-end SRv6 traverse non-SRv6 networks.

   Take figure 1 as an example, the metro network supports SR-MPLS, and
   Cloud transport network supports SRv6.
   [I-D.agrawal-spring-srv6-mpls-interworking] can be used to achieve
   interworking.  In other interworking scenarios, or other metro
   network scenarios (such as metro networks support LDP/RSVP/MPLS-TP/
   SR-TP, etc.), the solution needs further discussion.

4.3.  Metro network support SRv6

   The metro network is a new network that supports SRv6, or a recently
   deployed network that has the ability to support SRv6 after an
   upgrade.  Therefore, the metro network and cloud transport network
   are the interworking of two SRv6 domains.  In this case, Solutions
   for interworking between two SRv6 domains need to be considered,
   including the centralized controller and the distributed control
   plane solution, and how to implement end-to-end traffic engineering.

5.  Acknowledgements

   TBD.





Wang, et al.              Expires 28 April 2022                 [Page 5]


Internet-Draft          cloud-network integration           October 2021


6.  IANA Considerations

   This document makes no request of IANA.

7.  Security Considerations

   TBD.

8.  Normative References

   [I-D.agrawal-spring-srv6-mpls-interworking]
              Agrawal, S., ALI, Z., Filsfils, C., Voyer, D., and Z. Li,
              "SRv6 and MPLS interworking", Work in Progress, Internet-
              Draft, draft-agrawal-spring-srv6-mpls-interworking-06, 22
              August 2021, <https://datatracker.ietf.org/doc/html/draft-
              agrawal-spring-srv6-mpls-interworking-06>.

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

Authors' Addresses

   Minxue Wang
   China Mobile
   Beijing
   China

   Email: wangminxue@chinamobile.com


   Qian Cai
   China Mobile
   Beijing
   China

   Email: caiqian@chinamobile.com


   Liuyan Han
   China Mobile
   Beijing
   China

   Email: hanliuyan@chinamobile.com





Wang, et al.              Expires 28 April 2022                 [Page 6]


Internet-Draft          cloud-network integration           October 2021


   Ran Chen
   ZTE Corporation
   Nanjing
   China

   Email: chen.ran@zte.com.cn













































Wang, et al.              Expires 28 April 2022                 [Page 7]