Internet DRAFT - draft-wang-rtgwg-cloud-network-integration
draft-wang-rtgwg-cloud-network-integration
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]
