Internet-Draft cloud-network integration October 2021
Wang, et al. Expires 28 April 2022 [Page]
Workgroup:
RTGWG
Internet-Draft:
draft-wang-rtgwg-cloud-network-integration-00
Published:
Intended Status:
Informational
Expires:
Authors:
M. Wang
China Mobile
Q. Cai
China Mobile
L. Han
China Mobile
R. Chen
ZTE Corporation

cloud-network integration

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.

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.

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

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.

6. IANA Considerations

This document makes no request of IANA.

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, , <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, , <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

Minxue Wang
China Mobile
Beijing
China
Qian Cai
China Mobile
Beijing
China
Liuyan Han
China Mobile
Beijing
China
Ran Chen
ZTE Corporation
Nanjing
China