cloud-network integration

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.

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

Interworking scenarios This section defines two interworking scenarios.

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.

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.

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.

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.

Networking Technologies This section defines three networking technologies.

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.

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

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.

Acknowledgements TBD.

IANA Considerations This document makes no request of IANA.

Security Considerations TBD.