idnits 2.17.1 draft-ao-nvo3-overlay-subnet-architecture-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 13 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (June 5, 2019) is 1781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-intarea-gue' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC7365' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'I-D.ao-nvo3-multi-encap-interconnect' is defined on line 343, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-07 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-13 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-07 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-vxlan-gpe (ref. 'I-D.ietf-nvo3-vxlan-gpe') ** Downref: Normative reference to an Informational RFC: RFC 7365 ** Downref: Normative reference to an Informational RFC: RFC 8014 == Outdated reference: A later version (-04) exists of draft-defoy-coms-subnet-interconnection-03 == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-encap-02 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 WG T. Ao 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track G. Mirsky 5 Expires: December 7, 2019 ZTE Corp. 6 Y. Fan 7 China Telecom 8 June 5, 2019 10 Architecture for Overlay Virtual Sub-Network Interconnection 11 draft-ao-nvo3-overlay-subnet-architecture-02 13 Abstract 15 An virtualized overlay network may be divided into several subnets 16 for the reasons of geographical location, management, or using 17 different technologies being used. For example, different customer 18 have their own preference. But all these subnets need to work 19 together to provide an end-to-end connectionif in a virtual network, 20 An extended architecture of the NVO3 and propose a new component to 21 provide the connection fucntion are introduced in this document. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 7, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 3. Architecture for subnet . . . . . . . . . . . . . . . . . . . 4 62 3.1. Stitching NVE . . . . . . . . . . . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 5.2. Informational References . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Background 71 Network virtualization using Overlays over Layer 3 (NVO3) is a 72 technology that is used to address issues that arise in building 73 large, multi-tenant data centers that make extensive use of server 74 virtualization. 76 As described [I-D.defoy-coms-subnet-interconnection] and 77 [I-D.homma-coms-slice-gateway], for network slicing in 5G, there are 78 number of reasons to compose an end-to-end network slice instance by 79 using subnets and stitching operations, thus enabling hierarchical/ 80 recursive management of slices. These subnets are the part of the 81 network slice instance, but not isolate from network slice. An 82 overlay virtual network may also be constructed of several subnets. 83 In such scenario, subnets interconnection to a virtual network is 84 required. We also can consider such interconnection as stitiching. 85 With such stitiching, several subnets can provide a end to end 86 connection in an overlay virtual network. 88 Moreover, with the progress in NVO3 WG, some of the data plane 89 encapsulations have been put forward, some are outstanding dataplane 90 for an overlay network, such as VxLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], 91 GENEVE [I-D.ietf-nvo3-geneve] and GUE [I-D.ietf-nvo3-encap], etc. 92 The consideration about these overlay encapsulations has been 93 analyzed in [I-D.ietf-nvo3-encap]. The fact is that each of them has 94 its custmers, and furthermore, some of them have been already 95 deployed in the network. So that a problem arises: for a virtual 96 network, all the hosts that connect to the same VN and want to 97 communicate with each other are required to have the same data plane 98 encapsulation. This problem limits the network scalability and 99 capacity. Especially, when the NVE is located on the vSwitch, the 100 encapsulation method on the NVE is not predictable. Allowing as many 101 types of accession as possible is more attractive for a virtualized 102 overlay network. So in such a scenario, the NVEs using same 103 techonology can be connected to the same subnet. 105 To improve the scalability and capacity of the virtualized overlay 106 network and to satisfy the subnet interconnection requirement in 107 network slicing, we propose a subnet interconnection architecture in 108 NVO3, and provide a stitching gateway between the subnets in a 109 virtual network in this document. With such architecture, the 110 subnets in an overlay virtual network with different technologies and 111 with seperate management can be interconnected. The gateway that 112 provides the connection between subnets is referred to as Stitching 113 Gateway. In particular, the Stitching Gateway generally would be 114 located in a certain kind of NVE, such NVE is called as S-NVE in the 115 following descrption. 117 2. Conventions used in this document 119 2.1. Terminology 121 NVO3: Network Virtualization using Overlay over Layer 3 123 NVA: Network Virtualization Authority 125 TS: Tenant System 127 VxLAN-GPE: Virtual extension LAN with Generic Protocol Extension 129 GENEVE: Generic Network Virtualization Encapsulation 131 GUE: Generic UDP Encapsulation 133 S-GW: Stitching Gateway. A gateway that does the stitching for 134 seperate subnet to enable them to communicate with each other. 136 S-NVE: A NVE that complete the stitching functionn as a Stitching 137 Gateway for subnets in an overlay virtual network. 139 Subnet: An Overlay Virtual Network is combined with several Subnets 140 which may use different technology or different management. 142 Network slice in this document is used as shortened version of 143 network slice instance. 145 2.2. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 3. Architecture for subnet 155 As Generic Reference Model desribed in [RFC7364], it's a DC reference 156 model for network virtualization overlays where NVEs provide a 157 logical interconnect between Tenant Systems that belong to a specific 158 VN. But if we need to support a overlay virtual network, an extended 159 reference model is shown as follows in the NVO3 architecture. 161 +--------+ +-------+ 162 | Tenant +--+ + TS | 163 | System4| | /+-------+ 164 +--------+ | .................. / 165 | +---+ +---------------+ 166 +--|NVE|---+ +---| Stitching NVE | 167 +---+ | | | (S-NVE) | 168 /. | | +---------------+ 169 / . +-----+ . 170 / . +--| NVA |--+ . 171 / . | +-----+ \ . 172 | . | \ . 173 | . | Overlay +--+--++--------+ 174 +--------+ | . | Network | NVE || Tenant | 175 | Tenant +--+ . | | || System5| 176 | System3| . \ +---+ +--+--++--------+ 177 +--------+ .....|NVE|......... 178 +---+ 179 | 180 | 181 ===================== 182 | | 183 +--------+ +--------+ 184 | Tenant | | Tenant | 185 | System1| | System2| 186 +--------+ +--------+ 188 Figure 1 Reference Model supporting subnet 190 Figure 1: Reference Model supporting subnet 192 In the above figure, a specific Stitching Gateway(S-Gateway) 193 component is introduced. Generally, the gateway is located on a NVE, 194 so we call it as S-NVE. For the TSs in the same virtual network, if 195 the NVEs which they are connected to are using defferent overlay 196 technology, want to communicate with each other, Stitching NVE(S-NVE) 197 should take over responsibilityas a gateway to provide a "bridge" for 198 the communication. Or for the TSs connecting to different subnets, 199 but belonging to a virtual network, need to communicate with each 200 other through S-NVE. 202 The difference between NVE and S-NVE is that NVE is the connection 203 between different VN, while S-NVE is the connection between subnet. 204 From the view of NVE, S-NVE is a intermidiate relay node. For the 205 two Tenant Systems belong to different subnet have to communicate 206 through a S-NVE, even though they belong to a same virtual network. 208 That is, when different NVEs want to set up tunnel, if they can't 209 connect each other directly because they are on the different 210 subnets, they can set up a tunnel with S-NVE seperately, so that the 211 S-NVE connects the two tunnels as a stitcher. There could be more 212 than one S-NVE in a virtual network. 214 3.1. Stitching NVE 216 Stitching NVE(S-NVE) is a certain kind of NVE that maybe appointed by 217 NVA or by the manager. As an essential component in the NVO 218 supporting subnet, the requirements for a Stitching NVE is : 220 1. Provide the connection for the two subnet of a virtual network. 222 2. Provides identification/ classification of customer and service 223 traffic, performs the mapping of the two tunnels. 225 3. Support at least two kinds of encapsulations, translation between 226 technologies/encapsulations when it is stitching two subnets with two 227 different technology . 229 4. Fault and performance monitoring for underlay and overlay 230 networks. 232 Regarding the [RFC8014], the Stitching NVE has a reference model as 233 showed in Figure 2. 235 | | 236 | Data-Center Network (IP) | 237 +-----------------------------------------------------------+ 238 | | | | 239 | Tunnel Overlay | | Tunnel Overlay | 240 +---------+----+ +--+----------+----+ +-----+--------+ 241 | +----------+ | | +--------------+ | | +----------+ | 242 | | Overlay | | | | Overlay | | | | Overlay | | 243 | | Module | | | | Module | | | | Module | | 244 | +----+-----+ | | +---+----------+ | | +----------+ | 245 | | | | | | | | | | 246 | NVE1 | | | tNVE| | | | NVE3 | | 247 | +---+----+ | | +---+-+ +--+--+ | | +--------+ | 248 | | VNI1 | | | |VNI1 | |VNI1 | | | | VNI1 | | 249 | +-+------+ | | +-+---+ +-----+ | | +-+------+ | 250 | | VAP1 | | |VAP1 |VAP2| | | VAP1 | 251 +----+---------+ | +---------+ | +----+---------+ 252 | +------------------+ | 253 |\ | 254 -----+-\------------------------------------------------------+------- 255 TSI1 |TSI2\ Tenant TSI1 | 256 +---+ +---+ +---+ 257 |TS1| |TS2| |TS3| 258 +---+ +---+ +---+ 259 Figure 2 S-NVE Reference Model 261 Figure 2: S-NVE reference model 263 S-NVE is a key component of the connection between NVE1 and NVE2. It 264 can be a dedicated device and be a NVE that also provide the overlay 265 network for the TSs. When the NVE takes the role of stitching 266 different subnets for different TSs, it will not forward the traffic 267 to TS, but to another VAP that supports the encapsulation the 268 destination NVE owned. 270 Take the Figure 2 as an example to illustrate how does S-NVE work. 271 NVE1 belongs to subnet1 and only support VxLAN-GPE, and NVE2 belongs 272 to subnet2 and only support GENEVE. For the two communicating TSs: 273 TS1 needs to send packets to TS3, and TS3 also needs to reply to TS1. 274 They are in the same VNID1, but the NVE they are connected to is 275 using a different encapsulation, and the they belongs to two 276 different subnet. So if the two TSes want to communicate with each 277 other, packets have to transfer at S-NVE first. For NVE1, it has no 278 sense that TS3 is connecting to NVE3, instead of assuming that TS3 is 279 connecting to S-NVE. In the same way, for NVE3, it has no sense that 280 TS1 is connecting to NVE1, instead of assuming that TS1 is connecting 281 to S-NVE. So because of the existence of the tNVE, no matter TS1/TS3 282 or NVE1/NVE3, they never perceive that they are in the different data 283 plane. NVE1 getting the packets from TS1 encapsulates them in Vxlan- 284 GPE and then send the packets to S-NVE. The S-NVE receives the 285 packets from the Vxlan-GPE tunnel and then de-encapsulate the vxLAN- 286 GPE to VAP1. Next, the S-NVE forwards packets to the Overlay Module 287 from VAP2 to have another encapsulation GENEVE on the packets. At 288 last S-NVE forwards the packet in the GENEVE tunnel to NVE3. 290 From the above, S-NVE is like a stitcher between TS1 and TS2. And 291 owning to S-NVE, even though NVE1 and NVE2 which TS1 and TS2 292 connecting belong to separate subnets and seperately have different 293 encapsulation, as long as they are in the same virtual network, they 294 would communicate each other as a Larger L2 network and no need to 295 know that they are in different subnets or using different 296 technology. 298 4. IANA Considerations 300 TBD. 302 5. References 304 5.1. Normative References 306 [I-D.ietf-intarea-gue] 307 Herbert, T., Yong, L., and O. Zia, "Generic UDP 308 Encapsulation", draft-ietf-intarea-gue-07 (work in 309 progress), March 2019. 311 [I-D.ietf-nvo3-geneve] 312 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 313 Network Virtualization Encapsulation", draft-ietf- 314 nvo3-geneve-13 (work in progress), March 2019. 316 [I-D.ietf-nvo3-vxlan-gpe] 317 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 318 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work 319 in progress), April 2019. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 327 Rekhter, "Framework for Data Center (DC) Network 328 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 329 2014, . 331 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 332 Narten, "An Architecture for Data-Center Network 333 Virtualization over Layer 3 (NVO3)", RFC 8014, 334 DOI 10.17487/RFC8014, December 2016, 335 . 337 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 338 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 339 May 2017, . 341 5.2. Informational References 343 [I-D.ao-nvo3-multi-encap-interconnect] 344 Ao, T., Mirsky, G., and F. Yongbing, "Multi-encapsulation 345 interconnection for Overlay Virtual Network", draft-ao- 346 nvo3-multi-encap-interconnect-00 (work in progress), March 347 2018. 349 [I-D.defoy-coms-subnet-interconnection] 350 Foy, X., Rahman, A., Galis, A., 351 kiran.makhijani@huawei.com, k., Qiang, L., Homma, S., and 352 P. Martinez-Julia, "Interconnecting (or Stitching) Network 353 Slice Subnets", draft-defoy-coms-subnet-interconnection-03 354 (work in progress), March 2018. 356 [I-D.homma-coms-slice-gateway] 357 Homma, S., Foy, X., and A. Galis, "Gateway Function for 358 Network Slicing", draft-homma-coms-slice-gateway-01 (work 359 in progress), March 2018. 361 [I-D.ietf-nvo3-encap] 362 Boutros, S., "NVO3 Encapsulation Considerations", draft- 363 ietf-nvo3-encap-02 (work in progress), September 2018. 365 [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., 366 Kreeger, L., and M. Napierala, "Problem Statement: 367 Overlays for Network Virtualization", RFC 7364, 368 DOI 10.17487/RFC7364, October 2014, 369 . 371 Authors' Addresses 372 Ting Ao 373 ZTE Corporation 374 No.889, BiBo Road 375 Shanghai 201203 376 China 378 Phone: +86 17721209283 379 Email: 18555817@qq.com 381 Greg Mirsky 382 ZTE Corp. 383 1900 McCarthy Blvd. #205 384 Milpitas, CA 95035 385 USA 387 Email: gregimirsky@gmail.com 389 Yongbin 390 China Telecom 391 No.109, Zhongshan Avenue 392 Guangzhou 510630 393 China 395 Email: fanyb@gsta.com