idnits 2.17.1 draft-wang-rtgwg-cloud-network-integration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (25 October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-agrawal-spring-srv6-mpls-interworking-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG M. Wang 3 Internet-Draft Q. Cai 4 Intended status: Informational L. Han 5 Expires: 28 April 2022 China Mobile 6 R. Chen 7 ZTE Corporation 8 25 October 2021 10 cloud-network integration 11 draft-wang-rtgwg-cloud-network-integration-00 13 Abstract 15 This document describes cloud-network integration scenario and 16 networking technologies. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 28 April 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 3. Interworking scenarios . . . . . . . . . . . . . . . . . . . 3 54 3.1. Multiple domains with common border nodes . . . . . . . . 3 55 3.2. Multiple domains with no common border nodes . . . . . . 4 56 4. Networking Technologies . . . . . . . . . . . . . . . . . . . 4 57 4.1. Metro network does not support SRv6 . . . . . . . . . . . 5 58 4.2. Some nodes of the metro network support SRv6 . . . . . . 5 59 4.3. Metro network support SRv6 . . . . . . . . . . . . . . . 5 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 With the development of Internet+, the convergence trend of cloud and 69 network is increasingly obvious. More and more services and 70 applications will be carried on the cloud data centers. In order to 71 support new services and applications requirements and meet the 72 security requirements for data not going out of the park, therefore 73 the deployment location of the cloud/data center is also lowered from 74 the original regional DC and core DC to the edge DC. 76 As the interconnection network between the regional DC and the core 77 DC, the cloud transport network is usually a backbone network. 78 However, with the deployment of the edge DC, in order to avoid new 79 construction of a huge cloud transport network, the existing metro 80 network is used to access the edge DC. The interconnection between 81 edge DCs and regional DC/core DCs is implemented through the 82 coordination between the metro and cloud transport network. 83 Therefore, the interconnection solution between the cloud transport 84 and metro network needs to be considered. 86 In addition, the access point of enterprises entering the cloud is 87 usually in the metro network, and the dedicated line entering the 88 cloud also involves the interconnection between the cloud transport 89 and metro network. 91 This document describes cloud-network integration scenario and 92 networking technologies. 94 2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 cloud transport network: It is usually a national or province 101 backbone network to achieve interconnection between multiple regional 102 clouds/core clouds deployed in the country/province. 104 3. Interworking scenarios 106 This section defines two interworking scenarios. 108 3.1. Multiple domains with common border nodes 110 In this scenario, the boundary node of the cloud transport network 111 serves as the boundary node of the metro network. As shown in the 112 figure below. Node 4 serves as the boundary node of the metro 113 network as well as the boundary node of the cloud transport network. 115 +---+ +---+ 116 +---------| 2 |--------+--------| 5 | --------+ 117 | +---+ | +---+ | 118 | | | 119 | | | 120 +----+ Metro +---+ cloud +---+ 121 | 1 | | 4 | transport | 7 | 122 +----+ +---+ +---+ 123 | | | 124 | | | 125 | +---+ | +---+ | 126 +---------| 3 |--------+--------| 6 |---------+ 127 +---+ +---+ 129 Figure 1 131 The following applies to the reference topology above: 133 * Independent IGP instance in metro region. 135 * Independent IGP instance in cloud transport region. 137 * If the scale of the metro network is large, sometimes it may reach 138 thousands or even tens of thousands of nodes. At this time, the 139 metro network will be divided into multiple IGPs. 141 * The cloud transport and metro network can have different 142 controllers or under the same controller. 144 3.2. Multiple domains with no common border nodes 146 In this scenario, the cloud transport network and the metro network 147 do not have a common border nodes, and the border node of the two 148 networks are connected by a direct link. As shown below. 150 +---+ +---+ 151 +---------| 2 |--------+ +--------| 6 | --------+ 152 | +---+ | | +---+ | 153 | | | | 154 | | | | 155 +----+ Metro +---+ +---+ cloud +---+ 156 | 1 | | 4 |------ | 5 | transport | 8 | 157 +----+ +---+ +---+ +---+ 158 | | | | 159 | | | | 160 | +---+ | | +---+ | 161 +---------| 3 |--------+ +---------| 7 |--------+ 162 +---+ +---+ 164 Figure 2 166 In the interworking scenario described in Section 3.1, since two 167 domains have the same domain boundary node, so the route mutual 168 import can be used by the border node to interconnect the two 169 domains. In this section, the EBGP needs to be deployed between the 170 domains to connect the routes of the two domains. 172 In this scenario, hierarchical controller architecture usually be 173 considered, that is, the cloud transport and metro network have an 174 independent controller, and cross-domain controllers are used to 175 achieve the coordination of the two domains. If two domains need to 176 be under the same controller, higher requirements are required, such 177 as the controller needs to support a standardized unified southbound 178 interface and so on. 180 4. Networking Technologies 182 This section defines three networking technologies. 184 4.1. Metro network does not support SRv6 186 Based on existing networks, typically, the metro network does not 187 support the SRv6 and does not have the ability to upgrade to support 188 SRv6. For example, the earlier deployed metro network supports 189 LDP/RSVP/MPLS-TP and traditional L2VPN or L3VPN services. However, 190 the recently deployed metro network may support SR-MPLS/SR-TP, but it 191 still cannot support SRv6 due to its hardware capability. 193 In this scenario, segment splicing of different network technologies 194 is mainly used to achieve end-to-end connection of services. 196 4.2. Some nodes of the metro network support SRv6 198 In some cases, the metro network devicee connected to the edge DC 199 will be upgraded or replaced to support SRv6, while the rest of the 200 devices should be kept as old as possible and not replaced, so as to 201 avoid the need for more cost investment or avoid affecting the 202 existing services of the metro network. 204 As shown in Figure 1 or Figure 2, node 4 in metro network is upgraded 205 to support SRv6, while the remaining nodes in metro network do not 206 support SRv6.Cloud transport network supports SRv6. In this 207 scenario, SRv6 is used for end-to-end service connection. The main 208 consideration is how end-to-end SRv6 traverse non-SRv6 networks. 210 Take figure 1 as an example, the metro network supports SR-MPLS, and 211 Cloud transport network supports SRv6. 212 [I-D.agrawal-spring-srv6-mpls-interworking] can be used to achieve 213 interworking. In other interworking scenarios, or other metro 214 network scenarios (such as metro networks support LDP/RSVP/MPLS-TP/ 215 SR-TP, etc.), the solution needs further discussion. 217 4.3. Metro network support SRv6 219 The metro network is a new network that supports SRv6, or a recently 220 deployed network that has the ability to support SRv6 after an 221 upgrade. Therefore, the metro network and cloud transport network 222 are the interworking of two SRv6 domains. In this case, Solutions 223 for interworking between two SRv6 domains need to be considered, 224 including the centralized controller and the distributed control 225 plane solution, and how to implement end-to-end traffic engineering. 227 5. Acknowledgements 229 TBD. 231 6. IANA Considerations 233 This document makes no request of IANA. 235 7. Security Considerations 237 TBD. 239 8. Normative References 241 [I-D.agrawal-spring-srv6-mpls-interworking] 242 Agrawal, S., ALI, Z., Filsfils, C., Voyer, D., and Z. Li, 243 "SRv6 and MPLS interworking", Work in Progress, Internet- 244 Draft, draft-agrawal-spring-srv6-mpls-interworking-06, 22 245 August 2021, . 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 Authors' Addresses 255 Minxue Wang 256 China Mobile 257 Beijing 258 China 260 Email: wangminxue@chinamobile.com 262 Qian Cai 263 China Mobile 264 Beijing 265 China 267 Email: caiqian@chinamobile.com 269 Liuyan Han 270 China Mobile 271 Beijing 272 China 274 Email: hanliuyan@chinamobile.com 275 Ran Chen 276 ZTE Corporation 277 Nanjing 278 China 280 Email: chen.ran@zte.com.cn