idnits 2.17.1 draft-dong-teas-enhanced-vpn-control-plane-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-teas-enhanced-vpn]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-01 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-04 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-03 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: May 7, 2020 F. Qin 6 China Mobile 7 November 4, 2019 9 Control Plane Considerations for Enhanced VPN 10 draft-dong-teas-enhanced-vpn-control-plane-00 12 Abstract 14 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 15 needs of new applications, particularly including the applications 16 that are associated with 5G services. An enhanced VPN may be used 17 for 5G transport network slicing, and will also be of use in more 18 generic scenarios. [I-D.ietf-teas-enhanced-vpn] describes the 19 framework and candidate component technologies for providing enhanced 20 VPN services. This document describes the control plane 21 requirements, functions and considerations to enable VPN+ services. 22 Specifically, the scalability of control plane is analyzed, and the 23 proposed optimization mechanisms are described. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 7, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements on Control Plane . . . . . . . . . . . . . . . . 3 67 2.1. Support of Isolation . . . . . . . . . . . . . . . . . . 3 68 2.1.1. Data Plane Isolation . . . . . . . . . . . . . . . . 3 69 2.1.2. Control Plane Isolation . . . . . . . . . . . . . . . 4 70 2.2. Attributes of Network Slice . . . . . . . . . . . . . . . 5 71 2.3. Number of Network Slices . . . . . . . . . . . . . . . . 5 72 3. Control Plane Functions . . . . . . . . . . . . . . . . . . . 6 73 3.1. Distributed Control Plane . . . . . . . . . . . . . . . . 6 74 3.2. Centralized Controller . . . . . . . . . . . . . . . . . 7 75 4. Scalability Considerations . . . . . . . . . . . . . . . . . 8 76 4.1. Distributed Control Plane . . . . . . . . . . . . . . . . 8 77 4.2. Centralized Control Plane . . . . . . . . . . . . . . . . 9 78 5. Optimization Mechanisms . . . . . . . . . . . . . . . . . . . 9 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 9.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Driven largely by needs arising from the 5G mobile network, the 90 concept of network slicing has gained traction [TS28530]. Network 91 slicing requires to partition the physical network to several pieces 92 to provide each network slice with the required networking, 93 computing, and storage resources and functions to meet the 94 requirement of slice tenants. As specified in 95 [I-D.ietf-teas-enhanced-vpn], a transport network slice is a virtual 96 (logical) network with a particular network topology and a set of 97 shared or dedicated network resources, which are used to provide the 98 network slice consumer with the required connectivity, appropriate 99 isolation and specific Service Level Agreement (SLA). 101 Virtual private networks (VPNs) have served the industry well as a 102 means of providing different tenants with logically separated 103 networks in a common network. Basically the VPN service is provided 104 with two network layers: the overlay and the underlay. The underlay 105 is responsible for establishing the network paths based on the 106 network infrastructure, and managing the network resources to meet 107 the requirement of overlay. The overlay is used to distribute the 108 membership and reachability information of different tenants, and 109 provide separation of services between tenants. 111 The enhanced VPN service (VPN+) [I-D.ietf-teas-enhanced-vpn] is 112 targeted at new applications which require better isolation from both 113 control plane and data plane's perspective and have more stringent 114 performance requirements than can be provided with existing overlay 115 VPNs. To meet the requirement of enhance VPN services, a number of 116 virtual networks need be created, each with a subset of the underlay 117 network topology and a set of network resources allocated to meet the 118 requirement of a specific enhanced VPN or a group of enhanced VPNs. 119 In the context of 5G, each virtual network is considered as a 120 transport network slice. 122 This document gives analysis to the control plane requirements, 123 functions and considerations to enable enhanced VPN service. The 124 focus of this document is on the underlay of the enhanced VPN, i.e. 125 the transport network slice. 127 2. Requirements on Control Plane 129 2.1. Support of Isolation 131 2.1.1. Data Plane Isolation 133 Isolation in data plane is the fundamental requirement of services 134 which are deployed in a shared network infrastructure. Depends on 135 the level of data plane isolation, the requirement can be categorized 136 as soft isolation and hard isolation [I-D.ietf-teas-enhanced-vpn]. 138 Soft isolation means that traffic of one application or tenant cannot 139 be received or inspected by any other application or tenant in the 140 same network. Usually soft isolation does not have strict resource 141 or performance requirement, the underlying network resource can be 142 shared by multiple applications or tenants, which is useful to 143 achieve better economy with statistical multiplexing. However, with 144 soft isolation, when service in one of the virtual networks 145 experience some event such as traffic burst or congestion, this may 146 result in negative impacts to other virtual networks in terms of 147 packet loss, delay and jitter, etc. 149 On the other hand, hard isolation means that any event happened to 150 the traffic of one application or tenant in one virtual network will 151 not interfere any other application or tenant in the same network, 152 which means the characteristics of service can be guaranteed or more 153 predictable. To achieve this, at least some of the network resource 154 need to be dedicated, which may reduce the economy of multiplexing to 155 some extent. Hard isolation is required by services that usually 156 have their own private networks and expect to have the same network 157 characteristics even in a shared network. 159 It is expected that the requirement of some services or tenants can 160 be met with soft isolation, while hard isolation is required for 161 services or tenants which require guaranteed or more predictable 162 performance. 164 Although the soft are hard isolation characteristics are provided by 165 the forwarding plane of network devices, the control plane needs to 166 be aware of the data plane capability and provide necessary support 167 for both soft and hard isolation. Specifically, network information 168 needed for both soft and hard isolation needs to be collected and 169 distributed in the network, and the route and path computation should 170 be performed based the collected information to generate the 171 forwarding entries for each virtual network. 173 2.1.2. Control Plane Isolation 175 From routing's perspective, isolation in control plane can be 176 achieved in different levels: isolation of routing database, and 177 isolation of routing instances. 179 Isolation of routing database can enable customized routing and TE 180 attributes for different virtual networks. This can be used to 181 generate customized virtual network topologies and compute customized 182 paths for different applications or tenants. The Multi-Topology 183 Routing (MTR) mechanisms [RFC4915] [RFC5120] provides the basic 184 functionality to define separated topology and routing database for 185 different virtual networks. MTR was not widely used in current 186 network due to lack of use cases and some constraints in IP 187 forwarding, but it can be considered as a candidate technology for 188 enhanced VPN, especially when used with data plane technologies such 189 as Segment Routing (SR) [RFC8402]. There are also emerging 190 technologies, such as Flex-Algo as described in 192 [I-D.ietf-lsr-flex-algo], which can provide customization of the 193 topology and attributes for constraint route computation. 195 Isolation of routing instances can provide further customization and 196 flexibility, as different tenants or applications may choose their 197 preferred routing protocols and provision it with customized 198 parameters, and the operation of one routing instance can be 199 independent from others. The cost of routing instance isolation is 200 that it requires further complexity and more overhead of control 201 plane resources, in some cases the scalability can become 202 challenging. 204 2.2. Attributes of Network Slice 206 According to the definition of transport network slice in 207 [I-D.ietf-teas-enhanced-vpn], a transport network slice can be 208 characterized by two major types of attributes: the network slice 209 topology and the resources associated with the network slice. Each 210 network slice tenant can specify his requirement on the connectivity 211 and topology between the endpoints, and the requirement on service 212 performance. 214 Depending on the deployment of network slices, it is possible that 215 several network slices may have the same topology, and with soft 216 isolation it is possible that several network slices may share the 217 same set of network resource. While each transport network slice is 218 determined by the combination of the topology and the resource. 220 The control plane SHOULD be able to describe and distribute both the 221 topology attributes and the network resource attributes of each 222 network slice. 224 2.3. Number of Network Slices 226 In 5G scenarios, the number of network slices in a network is 227 relevant to how network slicing is used in the network and the 228 evolution of 5G for vertical industrial services. Although there is 229 no clear answer so far about how many network slices will be deployed 230 in a network, the potential number of network slices is analyzed by 231 classifying the network slicing deployment scenarios into three 232 typical phases. 234 In the initial phase, network slicing can be used to isolate 235 different types of business of one operator. For example, in a 236 converged multi-service network, different network slices can be 237 created to carry mobile service, fixed broadband service and 238 enterprise service respectively, each type of service may be managed 239 by a separate department or management team. Some particular service 240 types, such as multicast service may also be deployed in a dedicated 241 network slice. It is also possible that an network infrastructure 242 operator can provide network slices to other network operators as 243 wholesale service. In this phase, the number of network slices in a 244 network would be relatively small, such as in the order of 10 or so. 245 This could be the typical case in the beginning of network slicing 246 deployment. 248 In the second phase, network slicing can be used to provide isolated 249 virtual networks for tenants of different vertical industries. At 250 the early stage of the vertical industrial service deployment, a few 251 tenants in some typical industries will begin to use network slicing 252 to support their business, such as smart grid, public safety, games 253 etc. Considering the number of the vertical industries, and the 254 number of top tenants in each industry, the number of network slices 255 may increase to around 100. 257 In the third phase, with the evolution of 5G, network slicing could 258 be widely used by both vertical industrial tenants and premium 259 business tenants. The total amount of network slices could increase 260 to the order of 1000 or more. While it is expected that the number 261 of network slices would be still less than the number of traditional 262 VPN services in the network. 264 The control plane needs to be able to support different deployment 265 phases of network slicing, and the number of network slices required 266 in each phase. 268 3. Control Plane Functions 270 In order to meet the requirements as described in section 2, the 271 control plane of enhanced VPN could be based on a hybrid of 272 centralized controller and distributed control plane. 274 3.1. Distributed Control Plane 276 In the overlay of enhanced VPN, the distributed control plane is used 277 to advertise the routing information of different applications 278 tenants. BGP based L3VPN [RFC4364] and EVPN [RFC7432] can provide 279 the functionality needed for the overlay control plane of enhanced 280 VPN. Whether some extensions in overlay control plane are needed 281 will depend on the service requirements. This is out of the scope of 282 this document. 284 In the underlay of enhanced VPN, the distributed control plane is 285 responsible for advertising and collecting the customized topology 286 and resource information of the virtual networks associated with 287 different enhanced VPNs. A network node may participate in multiple 288 virtual networks, in this case the node needs to obtain the 289 information of each virtual network it participates in, so that the 290 node can generate the routing and forwarding entries for each virtual 291 network independently. 293 Currently there are several candidate mechanisms for the underlay 294 control plane. Either Multi-Topology Routing (MTR) [RFC4915] 295 [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo] can be used to 296 specify and distribute the customized topology and some of the TE 297 attributes of the virtual networks, then independent route 298 computation could be performed based on the routing database of each 299 virtual network. However, in order to support both hard and soft 300 isolation in one network, some extensions would be needed to specify 301 and distribute the network resource information of the underlay 302 network and its association with each virtual network. Such 303 extensions are defined in [I-D.dong-lsr-sr-enhanced-vpn] and other 304 accompanying documents. 306 3.2. Centralized Controller 308 With the introduction of SDN, a centralized controller can be used to 309 collect the network topology and associated attributes from the 310 underlay network, and provide global computation and optimization for 311 the traffic engineered (TE) paths. Several existing control 312 protocols have been designed for the interaction between the 313 controller and the network nodes. While in order to provide the 314 required functionality for different virtual networks, necessary 315 extensions to these protocols would be needed. 317 o BGP-LS [RFC7752] provides mechanisms to distribute the topology 318 and TE information of the underlay network to the centralized 319 controller. In the context of enhanced VPN, It be further 320 extended to distribute the topology and resource attributes of the 321 virtual networks to the controller. 323 o PCEP [RFC5440] provides mechanisms for Path Computation Elements 324 (PCEs) to perform path computations in response to Path 325 Computation Client (PCC) requests. It can also be used for the 326 creation and deletion of PCE-initiated paths in the network 327 [RFC8281]. In the context of enhanced VPN, It can be further 328 extended for path computation request, responses and path 329 provisioning within a particular virtual network. 331 o Netconf/YANG [RFC6241] [RFC7950] provides mechanisms for the 332 configuration of network device and protocols. In the context of 333 enhanced VPN, some extension to existing data models may be needed 334 for the configuration of virtual network specific attributes. 336 The detailed protocol extensions are out of the scope of this 337 document and will be specified in separate documents. 339 4. Scalability Considerations 341 With the development and evolution of 5G network slicing, more and 342 more transport network slices will be deployed. In different 343 transport network slices derived from the same underlay network, the 344 computed paths between the same pair of network nodes can be 345 different, and the resource used for packet forwarding and processing 346 in different network slices can also be different. In order to 347 provide routing in different transport network slices, several 348 aspects need to be considered, such as whether separated routing 349 protocols or routing instances need to be provided for different 350 transport network slices, and how to identify the same network node 351 or link in different transport network slices. The answer to these 352 problems will impact the scalability of both the control plane and 353 the data plane. 355 In this section, the scalability of control plane is analyzed to 356 understand whether or not the control plane mechanisms could support 357 the required amount of transport network slices. 359 4.1. Distributed Control Plane 361 As network slicing requires to provide customized topology and 362 resource attributes to different applications or tenants, it is 363 expected that more state will be introduced into the underlay 364 network. The scalability of the distributed control plane of the 365 underlay network needs to be considered in the following aspects: 367 o The number of protocol instances to be maintained on each node 369 o The number of the protocol sessions to be maintained on each node 371 o The number of routes to be advertised in the network 373 o The amount of information and attributes associated with each 374 route to be advertised 376 o The number of route computation (i.e. SPF) to be executed on each 377 node 379 As the number of network slices increases, it is expected that for 380 some of the aspects listed above, the overhead in control plane may 381 be not be affordable. For example, the overhead of maintaining 382 separated logical routing systems for different network slices is 383 higher than maintaining separate routing instances, which is also 384 higher than maintaining separated network topologies in the same 385 routing instance. In order to meet the requirement of increasing 386 network slices in future, It is suggested to choose the control plane 387 mechanisms which could improve the scalability while still provide 388 the required functionality. 390 4.2. Centralized Control Plane 392 Although the SDN approach can reduce the amount of control plane 393 overhead in the distributed control plane, SDN may transfer some of 394 the scalability concerns from the network to the centralized 395 controller, thus the scalability of the controller with network 396 slicing also needs to be considered. 398 In order to provide global optimization for TE paths in different 399 network slices, the controller needs to keep the information of all 400 the network slices up to date. To achieve this, the controller may 401 need to maintain a communication channel with each network node in 402 the network. When there is significant change in the network and 403 multiple network slices requires global optimization, there may be a 404 heavy processing burden at the controller, and a heavy load in the 405 network surrounding the controller for the distribution of the 406 updated network state. 408 5. Optimization Mechanisms 410 For the distributed control plane, several optimization mechanisms 411 are proposed to reduce the overhead and improve the control plane 412 scalability. 414 The first mechanism is to reduce the amount of control plane 415 sessions. For network slices which have the same peering 416 relationship between two adjacent nodes, it is proposed that one 417 single control session is shared by multiple network slices, 418 information of different network slices can be exchanged over the 419 same control session, with necessary information to distinguish them 420 in the control message. This could reduce the overhead of 421 maintaining large amount of control sessions, and could also reduce 422 the amount of routing information flooding in the network. 424 The second mechanism is to decouple different types of attributes of 425 a network slice, so that different types of information can be 426 advertised and processed separately in control plane. One example is 427 to decouple the topology and resource attribute of the network slice. 428 This can reduce the amount of route computation introduced by the 429 increased number of network slices. For a group of network slices 430 which have the same network topology, the result of topology based 431 computation could be shared, which means the SPF computation only 432 needs to be executed once for this group of network slices. This 433 way, the computation overhead could be reduced, especially when there 434 are a large number of network slices, with only a small set of 435 different network topologies. In order to obtain this optimization 436 benefit, network nodes need to be aware of which set of network 437 slices have the same topology, even if the other attributes of the 438 network slices (e.g. resource attributes) are different. Some 439 mechanism to decouple the topology attributes and other attributes of 440 the network slices would be needed. This methodology also applies to 441 other attributes which can be processed independently. 443 For the centralized control plane, it is considered that the 444 centralized controller is deployed as a complementary mechanism to 445 the distributed control plane rather than a replacement, so that the 446 computation burden in control plane could be shared by both the 447 centrazlied controller and the network nodes, thus the scalability of 448 both could be improved. 450 6. IANA Considerations 452 This document makes no request of IANA. 454 Note to RFC Editor: this section may be removed on publication as an 455 RFC. 457 7. Security Considerations 459 TBD 461 8. Acknowledgements 463 The authors would like to thank Zhibo Hu for his review and 464 suggestions to this document. 466 9. References 468 9.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 9.2. Informative References 477 [I-D.dong-lsr-sr-enhanced-vpn] 478 Dong, J. and S. Bryant, "IGP Extensions for Segment 479 Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced- 480 vpn-01 (work in progress), October 2018. 482 [I-D.ietf-lsr-flex-algo] 483 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 484 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 485 algo-04 (work in progress), September 2019. 487 [I-D.ietf-teas-enhanced-vpn] 488 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 489 Framework for Enhanced Virtual Private Networks (VPN+) 490 Service", draft-ietf-teas-enhanced-vpn-03 (work in 491 progress), September 2019. 493 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 494 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 495 2006, . 497 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 498 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 499 RFC 4915, DOI 10.17487/RFC4915, June 2007, 500 . 502 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 503 Topology (MT) Routing in Intermediate System to 504 Intermediate Systems (IS-ISs)", RFC 5120, 505 DOI 10.17487/RFC5120, February 2008, 506 . 508 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 509 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 510 DOI 10.17487/RFC5440, March 2009, 511 . 513 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 514 and A. Bierman, Ed., "Network Configuration Protocol 515 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 516 . 518 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 519 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 520 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 521 2015, . 523 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 524 S. Ray, "North-Bound Distribution of Link-State and 525 Traffic Engineering (TE) Information Using BGP", RFC 7752, 526 DOI 10.17487/RFC7752, March 2016, 527 . 529 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 530 RFC 7950, DOI 10.17487/RFC7950, August 2016, 531 . 533 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 534 Computation Element Communication Protocol (PCEP) 535 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 536 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 537 . 539 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 540 Decraene, B., Litkowski, S., and R. Shakir, "Segment 541 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 542 July 2018, . 544 [TS28530] "3GPP TS28.530", 2016, 545 . 548 Authors' Addresses 550 Jie Dong 551 Huawei Technologies 553 Email: jie.dong@huawei.com 555 Zhenbin Li 556 Huawei Technologies 558 Email: lizhenbin@huawei.com 560 Fengwei Qin 561 China Mobile 563 Email: qinfengwei@chinamobile.com