idnits 2.17.1 draft-arkko-arch-virtualization-01.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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 623 has weird spacing: '...mapping syste...' -- The document date (March 5, 2018) is 2234 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802.1Q' is mentioned on line 332, but not defined == Missing Reference: 'RFC4762' is mentioned on line 364, but not defined == Missing Reference: 'RFC4364' is mentioned on line 365, but not defined == Unused Reference: 'CC2015' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-nsh' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC8049' is defined on line 866, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-bryskin-teas-use-cases-sf-aware-topo-model-02 == Outdated reference: A later version (-04) exists of draft-geng-coms-problem-statement-00 == Outdated reference: A later version (-10) exists of draft-king-teas-applicability-actn-slicing-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational J. Tantsura 5 Expires: September 6, 2018 Nuagenetworks 6 J. Halpern 7 B. Varga 8 Ericsson 9 March 5, 2018 11 Considerations on Network Virtualization and Slicing 12 draft-arkko-arch-virtualization-01 14 Abstract 16 This document makes some observations on the effects of 17 virtualization on Internet architecture, as well as provides some 18 guidelines for further work at the IETF relating to virtualization. 20 This document also provides a summary of IETF technologies that 21 relate to network virtualization. An understanding of what current 22 technologies there exist and what they can or cannot do is the first 23 step in developing plans for possible extensions. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 6, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. General Observations . . . . . . . . . . . . . . . . . . . . 4 62 4. Virtualization in 5G Networks . . . . . . . . . . . . . . . . 6 63 5. Overview of IETF Virtualization Technologies . . . . . . . . 6 64 5.1. Selection of Virtual Instances . . . . . . . . . . . . . 7 65 5.2. Traffic Separation in VPNs . . . . . . . . . . . . . . . 7 66 5.3. Traffic Engineering and QoS . . . . . . . . . . . . . . . 9 67 5.4. Service Chaining . . . . . . . . . . . . . . . . . . . . 10 68 5.5. Management Frameworks and Data Models . . . . . . . . . . 10 69 6. Architectural Observations . . . . . . . . . . . . . . . . . 12 70 7. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 14 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 9. Informative References . . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 75 1. Introduction 77 Network virtualization is network management pertaining to treating 78 different traffic categories in separate virtual networks, with 79 independent lifecycle management and resource, technology, and 80 topology choices. 82 This document makes some observations on the effects of 83 virtualization on Internet architecture, as well as provides some 84 guidelines for further work at the IETF relating to virtualization. 86 This document also provides a summary of IETF technologies that 87 relate to network virtualization. An understanding of what current 88 technologies there exist and what they can or cannot do is the first 89 step in developing plans for possible extensions. 91 In particular, many IETF discussions earlier in the summer of 2017 92 started from a top-down view of new virtualization technologies, but 93 were often unable to explain the necessary delta to the wealth of 94 existing IETF technology in this space. This document takes a 95 different, bottom-up approach to the topic and attempts to document 96 existing technology, and then identify areas of needed development. 98 In particular, whether one calls a particular piece of technology 99 "virtualization", "slicing", "separation", or "network selection" 100 does not matter at the level of a system. Any modern system will use 101 several underlying technology components that may use different terms 102 but provide some separation or management. So, for instance, in a 103 given system you may use VLAN tags in an ethernet segment, MPLS or 104 VPNs across the domain, NAIs to select the right AAA instance, and 105 run all this top of virtualized operating system and software-based 106 switches. As new needs are being recognised in the developing 107 virtualization technology, what should drive the work is the need for 108 specific capabilities rather than the need to distinghuish a 109 particular term from another term. 111 2. Definitions 113 Network function virtualization is defined in Wikipedia as follows: 115 "Network function virtualization or NFV is a network architecture 116 concept that uses the technologies of IT virtualization to 117 virtualize entire classes of network node functions into building 118 blocks that may connect, or chain together, to create 119 communication services. 121 NFV relies upon, but differs from, traditional server- 122 virtualization techniques, such as those used in enterprise IT. A 123 virtualized network function, or VNF, may consist of one or more 124 virtual machines running different software and processes, on top 125 of standard high-volume servers, switches and storage devices, or 126 even cloud computing infrastructure, instead of having custom 127 hardware appliances for each network function." 129 We should not confuse NFV and network virtualization, the former, as 130 the name suggests is about functions virtualization, and not the 131 network. 133 The idea of network virtualization is almost as old as the networking 134 technology itself. Network virtualization is hierarchical and 135 multilayer in its nature, from layer 1 up to services on top. When 136 talking about virtualization we usually define overlay to underlay 137 relationship between different layers, bottom up. A VPN (Virtual 138 Private Network) [RFC4026] is the most common form of network 139 virtualization. The general benefits and desirability of VPNs have 140 been described many times and in many places ([RFC4110] and 141 [RFC4664]). 143 The only immutable infrastructure is the "physical" medium, that 144 could be dedicated or "sliced" to provide services(VPNs) in a multi- 145 tenant environment. 147 The term slicing has been used to describe a virtualization concept 148 in planned 5G networks. The 3GPP architecture specification 149 [TS-3GPP.23.501] defines network slices as having potentially 150 different "supported features and network functions optimisations", 151 and spanning functions from core network to radio access networks. 153 [I-D.king-teas-applicability-actn-slicing] defined slicing as "an 154 approach to network operations that builds on the concept of network 155 abstraction to provide programmability, flexibility, and modularity. 156 It may use techniques such as Software Defined Networking (SDN) and 157 Network Function Virtualization (NFV) to create multiple logical 158 (virtual) networks, each tailored for a set of services that are 159 sharing the same set of requirements, on top of a common network. 161 And, [I-D.geng-coms-problem-statement] defines slicing as a 162 management mechanism that an service provider can use to allocate 163 dedicated network resources from shared network infrastructures to a 164 tenant. 166 3. General Observations 168 Software vs. Protocols 170 Many of the necessary tools for using virtualization are software, 171 e.g., tools that enable running processes or entire machines in a 172 virtual environment decoupled from physical machines and isolated 173 from each other, virtual switches that connect systems together, 174 management tools to set up virtual environments, and so on. From 175 a communications perspective these tools operate largely in the 176 same fashion as their real-world counterparts do, except that 177 there may not be wires or other physical communication channels, 178 and that connections can be made in the desired fashion. 180 In general, there is no reason for protocols to change just 181 because a function or a connection exists on a virtual platform. 182 However, sometimes there are useful underlying technologies that 183 facilitiate connection to virtualized systems, or optimised or 184 additional tools that are needed in the the virtualized 185 environment. 187 For instance, many underlying technologies enable virtualization 188 at hardware or physical networking level. For instance, Ethernet 189 networks have Virtual LAN (VLAN) tags and mobile networks have a 190 choice of Access Point Names (APNs). These techniques allow users 191 and traffic to be put on specific networks, which in turn may 192 comprise of virtual components. 194 Other examples of protocols providing helpful techniques include 195 virtual private networking mechanisms or management mechanisms and 196 data models that can assist in setting up and administering 197 virtualized systems. 199 There may also be situations where scaling demands changes in 200 protocols. An ability to replicate many instances may push the 201 limits of protocol mechanisms that were designed primarily or 202 originally for physical networks. 204 Selection vs. Creation and Orchestration 206 Two primary tasks in virtualization should be differentiated: 207 selection of a particular virtual instance, and the tasks related 208 to how that virtual instance was created and continues to be 209 managed. 211 Selection involves choosing a particular virtual instance, or an 212 entrypoint to a virtual network. In its simplest form, a customer 213 could be hardwired by configuration to a particular virtual 214 instance. In more complex cases, the connecting devices may have 215 some settings that affect the choice. In the general case, both 216 the connecting devices and the network they are connecting to it 217 have a say in the choice. 219 The selection choice may even be dynamic in some cases. For 220 instance, traffic pattern analysis may affect the selection. 222 Typically, however, connecting devices do not have a say in what 223 the virtual instance does. This is directed by the network 224 operator and its customers. An instance is specified, created, 225 and needs to be continously managed and orchestrated. The 226 creation can be manual and occur rarely, or be more dynamic, e.g., 227 an instance can actually be instantiated automatically, and only 228 when the first connecting device connects to it. 230 Protocols vs. Representations of Virtual Networks 232 Some of virtualization technology benefits from protocol support 233 either in the data or control plane. But there are also 234 management constructs, such as data models representing virtual 235 services or networks and data models useful in the construction of 236 such services. 238 There are also conceptual definitions that may be needed when 239 constructing either protocols or data models or when discussing 240 service agreements between providers and consumers. 242 4. Virtualization in 5G Networks 244 Goals for the support of virtualization in 5G relate to both the use 245 of virtualized network functions to build the 5G network, and to 246 enabling the separation of different user or traffic classes into 247 separate network constructs called slices. 249 Slices enable a separation of concerns, allow the creation of 250 dedicated services for special traffic types, allow faster evolution 251 of the network mechanisms by easing gradual migration to new 252 functionality, and enable faster time to market for new new 253 functionality. 255 In 5G, slice selection happens as a combination of settings in the 256 User Equipment (UE) and the network. Settings in the UE include, for 257 instance, the Access Point Name (APN), Dedicated Core Network 258 Indicator (DCN-ID) [TS-3GPP.23.401], and, with 5G, a slice indicator 259 (Network Slice Selection Assistance Information or NSSAI) 260 [TS-3GPP.23.501]. This information is combined with the information 261 configured in the network for a given subscriber and the policies of 262 the networks involved. Ultimately, a slice is selected. 264 A 5G access network carries a user's connection attempt to the 5G 265 core network and the Access Management Function (AMF) network 266 function. This function collects information provided by the UE and 267 the subscriber database from home network, and consults the Network 268 Slice Selection Function (NSSF) to make a decision of the slice 269 selected for the user. When the selection has been made, this may 270 also mean that the connection is moved to a different AMF; enabling 271 separate networks to have entirely different network-level service. 273 The creation and orchestration of slices does not happen at this 274 signalling plane, but rather the slices are separately specified, 275 created, and managed, typically with the help of an orchestrator 276 function. 278 The exact mechanisms for doing this continue to evolve, but in any 279 case involve multiple layers of technology, ranging from underlying 280 virtualization software to network component configuration mechanisms 281 and models (often in YANG) to higher abstraction level descriptions 282 (often in TOSCA), to orchestrator software. 284 5. Overview of IETF Virtualization Technologies 286 General networking protocols are largely agnostic to virtualization. 287 TCP/IP does not care whether it runs on a physical wire or on a 288 computer-created connection between virtual devices. 290 As a result, virtualization generally does not affect TCP/IP itself 291 or applications running on top. There are some exceptions, though, 292 such as when the need to virtualize has caused previously held 293 assumptions to break, and the Internet community has had to provide 294 new solutions. For instance, early versions of the HTTP protocol 295 assumed a single host served a single website. The advent of virtual 296 hosting and pressure to not use large numbers of IPv4 addresses lead 297 to HTTP 1.1 adopting virtual hosting, where the identified web host 298 is indicated inside the HTTP protocol rather than inferred from the 299 reception of a request at particular IP address [VirtualHosting] 300 [RFC2616]. 302 But where virtualization affects the Internet architecture and 303 implementations is at lower layers, the physical and MAC layers, the 304 systems that deal with the delivery of IP packets to the right 305 destination, management frameworks controlling these systems, and 306 data models designed to help the creation, monitoring, or management 307 of virtualized services. 309 What follows is an overview of existing technologies and technologies 310 currently under development that support virtualization in its 311 various forms. 313 5.1. Selection of Virtual Instances 315 Some L2 technology allows the identification of traffic belonging to 316 a particular virtual network or connection. For instance, Ethernet 317 VLAN tags. 319 There are some IETF technologies that also allow similar 320 identification of connections setup with the help of IETF protocols. 321 For instance, Network Access Identifiers may identify a particular 322 customer or virtual service within AAA, EAP or IKEv2 VPN connections. 324 5.2. Traffic Separation in VPNs 326 Technologies that assist separation and engineering of networks 327 include both end-point and provider-based VPNs. End-point VPN 328 tehchnologies include, for instance, IPsec-based VPNs [RFC4301]. 330 For providing virtualized services, however, provider-based solutions 331 are often the most relevant ones. L1VPN facilitates virtualization 332 of the underlying L0 "physical" medium. L2[IEEE802.1Q] facilitates 333 virtualization of the underlying Ethernet network Tunneling over IP 334 (MPLS, GRE, VxLAN, IPinIP, L2TP, etc) facilitates virtualization of 335 the underlying IP network - MPLS LSP's - either traffic engineered or 336 not belong here L2VPN facilitates virtualization of a L2 network 337 L3VPN facilitates virtualization of a L3 network. 339 The IETF has defined a multiplicity of technologies that can be used 340 for provider-based VPNs. The technologies choices available can be 341 described along two axes, control mechanisms and dataplane 342 encapsulation mechanisms. The two are not compeltely orthogonal. 344 In the data plane, for provider based VPNs, the first important 345 observation is that the most obvious encapsulation is NOT used. 346 While IPSec could be used for provider-based VPNs, it does not appear 347 to be used in practice, and is not the focus for any of the available 348 control mechanisms. Often, when end2end encryption is required it is 349 used as an overlay over MPLS based L3VPN 351 The common encapsulation for provider-based VPNs is to use MPLS. 352 This is particularly common for VPNs within one operator, and is 353 sometimes supported across operators. 355 Keyed GRE can be used, particularly for cross-operator cases. 356 However, it seems to be rare in practice. 358 The usage of MPLS for provider-based VPNs generally follows a pattern 359 of using two (or more) MPLS labels, top (transport) label to 360 represent the remote end point/egress provider-edge device, and 361 bottom (service) label to signal the different VPNs on the remote end 362 point. Using TE might result in a deeper label stack. 364 L2 VPNs could be signaled thru LDP[RFC4762] or MP-BGP[RFC4761], L3 365 VPN is signaled thru MP-BGP[RFC4364] 367 The LDP usage to control VPN establishment falls within the PALS 368 working group, and is used to establish pseudo-wires to carry 369 Ethernet (or lower layer) traffic. The Ethernet cases tend to be 370 called VPLS (Virtual Private LAN Service) for multi-point 371 connectivity and VPWS (Virtual Private Wire Service) for point-to- 372 point connectivity. These mechanism do augment the data plane 373 capabilites with control words that support additional features. In 374 operation, LDP is used to signal the communicating end-points that 375 are interested in communicating with each other in support of 376 specific VPNs. Information about the MAC addresses used behind the 377 provider edges is exchanged using classic Ethernet flooding 378 technology. It has been proposed to use BGP to bootstrap the exchang 379 eof information as to who the communicating endpoints are. 381 BGP can be used to establish Layer 2 or Layer 3 VPNs. Originally, 382 the BGP based MPLS VPN technology was developed to support layer 3 383 VPNs. the BGP exchanges uses several different features in MP-BGP 384 (specifically route distinguishers and route targets) to control the 385 distribution of information about VPN end-points. The BGP 386 information carries the VPN IP address prefixes, and the MPLS labels 387 to be used to represent the VPN. This technolgoy combination is 388 generally known as L3VPN. 390 This usage of BGP for VPNs has been extended to support Layer 2 VPNs. 391 This is known as EVPN. The BGP exchanges are used to carry the MAC 392 address reachability behind each provider edge router, providing an 393 Ethernet multipoint service without a need to flood unkown- 394 destination Ethernet packets. 396 In theory, the BGP mechanisms can also be used to support other 397 tunnels such as keyed GRE. That is not widely practiced. 399 There are also hybrid variations, such as adding an ARP / ND proxy 400 service so that an L3VPN can be used with an L2 Access, when the only 401 desired service is IP. 403 5.3. Traffic Engineering and QoS 405 Traffic Engineering (TE) is the term used to refer to techniques that 406 enable operators to control how specific traffic flows are treated 407 within their networks. 409 The TEAS working group works on enhancements to traffic-engineering 410 capabilities for MPLS and GMPLS networks: 412 TE is applied to packet networks via MPLS TE tunnels and LSPs. 413 The MPLS-TE control plane was generalized to additionally support 414 non-packet technologies via GMPLS. RSVP-TE is the signaling 415 protocol used for both MPLS-TE and GMPLS. 417 The TEAS WG is responsible for: 419 * Traffic-engineering architectures for generic applicability 420 across packet and non-packet networks. 422 * Definition of protocol-independent metrics and parameters. 424 * Functional specification of extensions for routing (OSPF, 425 ISIS), for path computation (PCE), and RSVP-TE to provide 426 general enablers of traffic-engineering systems. 428 * Definition of control plane mechanisms and extensions to allow 429 the setup and maintenance of TE paths and TE tunnels that span 430 multiple domains and/or switching technologies. 432 A good example of work that is currently considered in the TEAS WG is 433 the set of models that detail earlier IETF-developed topology models 434 with both traffic engineering information and connection to what 435 services are running on top of the network 436 [I-D.bryskin-teas-use-cases-sf-aware-topo-model] 437 [I-D.bryskin-teas-sf-aware-topo-model]. These models enable 438 reasoning about the state of the network with respect to those 439 services, and to set up services with optimal network connectivity. 441 Traffic engineering is a common requirement for many routing systems, 442 and also discussed, e.g., in the context of LISP. 444 5.4. Service Chaining 446 The SFC working group has defined the concept of Service Chaining: 448 Today, common deployment models have service functions inserted on 449 the data-forwarding path between communicating peers. Going 450 forward, however, there is a need to move to a different model, 451 where service functions, whether physical or virtualized, are not 452 required to reside on the direct data path and traffic is instead 453 steered through required service functions, wherever they are 454 deployed. 456 For a given service, the abstracted view of the required service 457 functions and the order in which they are to be applied is called 458 a Service Function Chain (SFC). An SFC is instantiated through 459 selection of specific service function instances on specific 460 network nodes to form a service graph: this is called a Service 461 Function Path (SFP). The service functions may be applied at any 462 layer within the network protocol stack (network layer, transport 463 layer, application layer, etc.). 465 5.5. Management Frameworks and Data Models 467 There have been two working groups at the IETF, focusing on data 468 models describing VPNs. The IETF and the industry in general is 469 currently specifying a set of YANG models for network element and 470 protocol configuration [RFC6020]. 472 YANG is a powerful and versatile data modeling language that was 473 designed from the requirements of network operators for an easy to 474 use and robust mechanism for provisioning devices and services across 475 networks. It was originally designed at the Internet Engineering 476 Task Force (IETF) and has been so successful that it has been adopted 477 as the standard for modeling design in many other standards bodies 478 such as the Metro Ethernet Forum, OpenDaylight, OpenConfig, and 479 others. The number of YANG modules being implemented for interfaces, 480 devices, and service is growing rapidly. 482 (It should be noted that there are also other description formats, 483 e.g., Topology and Orchestration Specification for Cloud Applications 484 (TOSCA) [TOSCA-1.0] [TOSCA-Profile-1.1], common in many higher 485 abstract level network service descriptions. The ONAP open source 486 project plans to employ it for abstract mobile network slicing 487 models, for instance.) 489 A service model is an abstract model, at a higher level than network 490 element or protocol configuration. A service model for VPN service 491 describes a VPN in a manner that a customer of the VPN service would 492 see it. 494 It needs to be clearly understood that such a service model is not a 495 configuration model. That is, it does not provide details for 496 configuring network elements or protocols: that work is expected to 497 be carried out in other protocol-specific working groups. Instead, 498 service models contain the characteristics of the service as 499 discussed between the operators and their customers. A separate 500 process is responsible for mapping this customer service model onto 501 the protocols and network elements depending on how the network 502 operator chooses to realise the service. 504 The L2SM WG specifies a service model for L2-based VPNs: 506 The Layer Two Virtual Private Network Service Model (L2SM) working 507 group is a short-lived WG. It is tasked to create a YANG data 508 model that describes a L2VPN service (a L2VPN customer service 509 model). The model can be used for communication between customers 510 and network operators, and to provide input to automated control 511 and configuration applications. 513 It is recognized that it would be beneficial to have a common base 514 model that addresses multiple popular L2VPN service types. The 515 working group derives a single data model that includes support 516 for the following: 518 * point-to-point Virtual Private Wire Services (VPWS), 520 * multipoint Virtual Private LAN services (VPLS) that use LDP- 521 signaled Pseudowires, 523 * multipoint Virtual Private LAN services (VPLS) that use a 524 Border Gateway Protocol (BGP) control plane as described in 525 [RFC4761] and [RFC6624], 527 * Ethernet VPNs specified in [RFC7432]. 529 Other L2VPN service types may be included if there is consensus in 530 the working group. 532 Similarly, the L3SM WG specified a sevice model for L3-based VPNs. 534 The Layer Three Virtual Private Network Service Model (L3SM) 535 working group is a short-lived WG tasked to create a YANG data 536 model that describes a L3VPN service (a L3VPN service model) that 537 can be used for communication between customers and network 538 operators, and to provide input to automated control and 539 configuration applications. 541 It needs to be clearly understood that this L3VPN service model is 542 not an L3VPN configuration model. That is, it does not provide 543 details for configuring network elements or protocols. Instead it 544 contains the characteristics of the service. 546 6. Architectural Observations 548 This section makes some observations about architectural trends and 549 issues. 551 Role of Software 553 An obvious trend is that bigger and bigger parts of the 554 functionality in a network is driven by software, e.g., 555 orchestration or management tools that figure out how to control 556 relatively simple network element functionality. The software 557 components are where the intelligence is, and a smaller fraction 558 of the intelligence resides in network elements, nor is the 559 intelligence encoded in the behaviour rules of the protocols that 560 the network elements use to communicate with each other. 562 Centralization of Functions 564 An interesting architectural trend is that virtualization and data 565 /software driven networking technologies are driving network 566 architectures where functionality moves towards central entities 567 such as various controllers, path computation servers, and 568 orchestration systems. 570 A natural consequence of this is the simplification (and perhaps 571 commoditization) of network elements, while the "intelligent" or 572 higher value functions migrate to the center. 574 The benefits are largely in the manageability, control, and speed 575 of change. There are, however, potential pitfalls to be aware of 576 as well. First off, networks need to continue to be operate even 577 under partial connectivity situations and breakage, and it is key 578 that designs can handle those situations as well. 580 And it is important that network users and peers continue to be 581 able to operate and connect in the distributed, voluntary manner 582 that we have today. Today's virtualization technology is 583 primarily used to manage single administrative domains and to 584 offer specific service to others. One could imagine centralised 585 models being taken too far as well, limiting the ability of other 586 network owners to manage their own networks. 588 Tailored vs. general-purpose networking 590 The interest in building tailored solutions, tailored Quality-of- 591 Service offerings vs. building general-purpose "low touch" 592 networks seems to fluctuate over time. 594 It is important to find the right balance here. From an economics 595 perspective, it may not be feasible to provide specialised service 596 -- at least if it requires human effort -- for large fraction of 597 use cases. Even if those are very useful in critical 598 applications. 600 Need for descriptions 602 As networks deal more and more with virtual services, there arises 603 a need to have generally understood, portable descriptions of 604 these service. Hence the creation of YANG data models 605 representing abstract VPN services, for instance. 607 We can also identify some potential architectural principles, such 608 as: 610 Data model layering 612 Given the heterogenuity of networking technologies and the 613 differing users that data models are being designed for, it seems 614 difficult to provide a single-level model. It seems preferable to 615 construct a layered set of models, for instance abstract, user- 616 facing models that specify services that can then be mapped to 617 concrete configuration model for networks. And these can in turn 618 be mapped to individual network element configuration models. 620 Getting this layered design right is crucial for our ability to 621 evolve a useful set of data models. 623 Ability to evolve modelling tools and mapping systems 624 The networks and their models are complex, and mapping from high 625 abstraction level specifications to concrete network 626 configurations is a hard problem. 628 It is important that each of the components can evolve on its own. 629 It should be possible to plug in a new language that represents 630 network models better. Or replace a software component that 631 performs mapping between layers to one that works better. 633 While this should normally be possible, there's room to avoid too 634 tight binding between the different aspects of a system. For 635 instance, abstraction layers within software can shield the 636 software from being too closely tied with a particular 637 representation language. 639 Similarly, it would be an advantage to develop algorithms and 640 mapping approaches separately from the software that actually does 641 that, so that another piece of software could easily follow the 642 same guidelines and provide an alternate implementation. Perhaps 643 there's an opportunity for specification work to focus more on 644 processing rules than protocol behaviours, for instance. 646 General over specific 648 In the quick pace of important developments, it is tempting to 649 focus on specific concepts and service offerings such as 5G 650 slicing. 652 But a preferrable approach seems to provide general-purpose tools 653 that can be used by 5G and other networks, and whose longetivity 654 exceeds that of a version of a specific offering. The quick 655 development pace is likely driving the evolution of concepts in 656 any case, and building IETF tools that provide the ability to deal 657 with different technologies is most useful. 659 7. Further Work 661 There may be needs for further work in this area at the IETF. Before 662 discussing the specific needs, it may be useful to classify the types 663 of useful work that might come to question. And perhaps also outline 664 some types of work that is not appropriate for the IETF. 666 The IETF works primarily on protocols, but in many cases also with 667 data models that help manage systems, as well as operational guidance 668 documents. But the IETF does not work on software, such as 669 abstractions that only need to exist inside computers or ones that do 670 not have an effect on protocols either on real or simulated "wires". 672 The IETF also does not generally work on system-level design. IETF 673 is best at designing components, not putting those components 674 together to achieve a particular purpose or build a specific 675 application. 677 As a result, IETF's work on new systems employing virtualization 678 techniques (such as 5G slicing concept) is more at the component 679 improvement level than at the level of the concept. There needs to 680 be a mapping between a vision of a system and how it utilizes various 681 software, hardware, and protocol tools to achieve the particular 682 virtualization capabilities it needs to. Developing a new concept 683 does not necessarily mean that entirely new solutions are needed 684 throughtout the stack. Indeed, systems and concepts are usually 685 built on top of solid, well defined components such as the ones 686 produced by the IETF. 688 That mapping work is necessarily something that those who want to 689 achieve some new functionality need to do; it is difficult for others 690 to take a position on what the new functionality is. But at the same 691 time, IETF working groups and participants typically have a 692 perspective on how their technology should develop and be extended. 693 Those two viewpoints must meet. 695 The kinds of potential new work in this space falls generally in the 696 following classes: 698 Virtualization selectors 700 Sometimes protocols need mechanisms that make it possible to use 701 them as multiple instances. E.g., VLAN tags were added to 702 Ethernet frames, NAIs were added to PPP and EAP, and so on. These 703 cases are rare today, because most protocols and mechanisms have 704 some kind of selector that can be used to run multiple instances 705 or connect to multiple different networks. 707 Traffic engineering 709 A big reason for building specific networks for specific purposes 710 is to provide an engineered service level on delay and other 711 factors to the given customer. There are a number of different 712 tools in the IETF to help manage and engineer networks, but it is 713 also an area that continues to develop and will likely see new 714 functionality. 716 Virtual service data models 717 Data models -- such as those described by L2SM or L3SM working 718 groups can represent a "service" offered by a network, a setup 719 built for a specific customer or purpose. 721 Some specific areas where work is likely needed include: 723 o The ability to manage heterogenous technologies, e.g., across SDN 724 and traditionally built networks, or manage both general-purpose 725 and very technology-specific parameters such as those associated 726 with 5G radio. 728 o The ability to specify "statistical" rather than hard performance 729 parameters. In some networks -- notably with wireless technology 730 -- recent advances have made very high peak rates possible, but 731 with increased bursty-ness of traffic and with potential 732 bottlenecks on the aggregation parts of the networks. The ability 733 to specify statistical performance in data models and in VPN 734 configuration would be important, over different timescales and 735 probabilities. 737 o Mapping from high abstraction level specifications to concrete 738 network configurations. 740 There is a lot of work on data models and templates at various 741 levels and in different representations. There are also many 742 systems built to manage these models and orchestrate network 743 configuration. But the mapping of the abstract models to concrete 744 network configurations remains a hard problem, and it certainly 745 will need more work. 747 There are even some questions about how to go about this. Is it 748 enough that we specify models, and leave the mapping to "magic" of 749 the software? Are the connections something that different 750 vendors compete in producing good products in? Or are the mapping 751 algorithms something that needs to be specified together, and 752 their ability to work with different types of network equipment 753 verified in some manner? 755 o Cross-domain: A big problem is that we have little tools for 756 cross-domain management of virtualized networks and resources. 758 Finally, there is a question of where all this work should reside. 759 There's an argument that IETF-based virtualization technologies 760 deserve proper management tools, including data models. 762 And there's another argument that with the extensive use of 763 virtualization technology, solutions that can manage many different 764 networks should be general, and as such, potential IETF work 765 material. Yet, the IETF is not and should not be in the space of 766 replacing various tools and open source toolkits that have been 767 created for managing virtualization. It seems though that work on 768 commonly usable data models at several layers of abstraction would be 769 good work at the IETF. 771 Nevertheless, the IETF should understand where the broader community 772 is and what tools they use for what purpose, and try to help by 773 building on those components. Virtualization and slicing are 774 sometimes represented as issues needing a single solution. In 775 reality, they are an interworking of a number of different tools. 777 8. Acknowledgements 779 The authors would like to thank Gonzalo Camarillo, Gabriel 780 Montenegro, Alex Galis, Adrian Farrell, Liang Geng, Yi Zhao, Hannu 781 Flinck, Yi Zhao, Barry Leiba, Georg Mayer, Benoit Claise, Daniele 782 Ceccarelli, Warren Kumari, Ted Hardie, and many others for 783 interesting discussions in this problem space. 785 9. Informative References 787 [CC2015] claffy, kc. and D. Clark, "Adding Enhanced Services to the 788 Internet: Lessons from History", September 2015 (https:// 789 www.caida.org/publications/papers/2015/ 790 adding_enhanced_services_internet/ 791 adding_enhanced_services_internet.pdf). 793 [I-D.bryskin-teas-sf-aware-topo-model] 794 Bryskin, I. and X. Liu, "SF Aware TE Topology YANG Model", 795 draft-bryskin-teas-sf-aware-topo-model-01 (work in 796 progress), March 2018. 798 [I-D.bryskin-teas-use-cases-sf-aware-topo-model] 799 Bryskin, I., Liu, X., Guichard, J., Lee, Y., Contreras, 800 L., and D. Ceccarelli, "Use Cases for SF Aware Topology 801 Models", draft-bryskin-teas-use-cases-sf-aware-topo- 802 model-02 (work in progress), March 2018. 804 [I-D.geng-coms-problem-statement] 805 67, 4., Slawomir, S., Qiang, L., Matsushima, S., Galis, 806 A., and L. Contreras, "Problem Statement of Supervised 807 Heterogeneous Network Slicing", draft-geng-coms-problem- 808 statement-00 (work in progress), September 2017. 810 [I-D.ietf-sfc-nsh] 811 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 812 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 813 November 2017. 815 [I-D.king-teas-applicability-actn-slicing] 816 King, D. and Y. Lee, "Applicability of Abstraction and 817 Control of Traffic Engineered Networks (ACTN) to Network 818 Slicing", draft-king-teas-applicability-actn-slicing-01 819 (work in progress), July 2017. 821 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 822 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 823 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 824 RFC2616, June 1999, . 827 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 828 Private Network (VPN) Terminology", RFC 4026, DOI 10.17487 829 /RFC4026, March 2005, . 832 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 833 Provider-Provisioned Virtual Private Networks (PPVPNs)", 834 RFC 4110, DOI 10.17487/RFC4110, July 2005, . 837 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 838 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 839 December 2005, . 841 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 842 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 843 10.17487/RFC4664, September 2006, . 846 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 847 LAN Service (VPLS) Using BGP for Auto-Discovery and 848 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 849 . 851 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 852 the Network Configuration Protocol (NETCONF)", RFC 6020, 853 DOI 10.17487/RFC6020, October 2010, . 856 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 857 Virtual Private Networks Using BGP for Auto-Discovery and 858 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 859 . 861 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 862 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 863 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 864 2015, . 866 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 867 Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/ 868 RFC8049, February 2017, . 871 [TOSCA-1.0] 872 OASIS, "Topology and Orchestration Specification for Cloud 873 Applications Version 1.0", OASIS OASIS Standard, http:// 874 docs.oasis-open.org/tosca/TOSCA/v1.0/os/ 875 TOSCA-v1.0-os.html, November 2013. 877 [TOSCA-Profile-1.1] 878 OASIS, "TOSCA Simple Profile in YAML Version 1.1", OASIS 879 OASIS Standard, http://docs.oasis-open.org/tosca/TOSCA- 880 Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile- 881 YAML-v1.1.html, January 2018. 883 [TS-3GPP.23.401] 884 3GPP, "3rd Generation Partnership Project; Technical 885 Specification Group Services and System Aspects; General 886 Packet Radio Service (GPRS) enhancements for Evolved 887 Universal Terrestrial Radio Access Network (E-UTRAN) 888 access; (Release 15)", 3GPP Technical Specification 889 23.401, December 2017. 891 [TS-3GPP.23.501] 892 3GPP, "3rd Generation Partnership Project; Technical 893 Specification Group Services and System Aspects; 3G 894 Security; Security architecture and procedures for 5G 895 System; (Release 15)", 3GPP Technical Specification 896 23.501, December 2017. 898 [VirtualHosting] 899 Wikipedia, "Virtual Hosting", Wikipedia article https:// 900 en.wikipedia.org/wiki/Virtual_hosting, August 2017. 902 Authors' Addresses 903 Jari Arkko 904 Ericsson 905 Kauniainen 02700 906 Finland 908 Email: jari.arkko@piuha.net 910 Jeff Tantsura 911 Nuagenetworks 913 Email: jefftant.ietf@gmail.com 915 Joel Halpern 916 Ericsson 918 Email: joel.halpern@ericsson.com 920 Balazs Varga 921 Ericsson 922 Budapest 1097 923 Hungary 925 Email: balazs.a.varga@ericsson.com