idnits 2.17.00 (12 Aug 2021) /tmp/idnits22240/draft-arkko-arch-virtualization-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 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 -- The document date (November 16, 2017) is 1647 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802.1Q' is mentioned on line 254, but not defined == Missing Reference: 'RFC4762' is mentioned on line 286, but not defined == Missing Reference: 'RFC4364' is mentioned on line 287, but not defined == Unused Reference: 'CC2015' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-nsh' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC8049' is defined on line 713, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-geng-coms-problem-statement-00 == Outdated reference: draft-ietf-sfc-nsh has been published as RFC 8300 == 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 (~~), 10 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: May 20, 2018 Futurewei, Future Networks 6 J. Halpern 7 B. Varga 8 Ericsson 9 November 16, 2017 11 Considerations on Network Virtualization and Slicing 12 draft-arkko-arch-virtualization-00.txt 14 Abstract 16 This document makes some observations on the effects virtualization 17 on Internet architecture, as well as provides some guidelines for 18 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 May 20, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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. Overview of IETF Virtualization Technologies . . . . . . . . 5 63 4.1. Lower layers . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Traffic Separation in VPNs . . . . . . . . . . . . . . . 6 65 4.3. Traffic Engineering and QoS . . . . . . . . . . . . . . . 7 66 4.4. Service Chaining . . . . . . . . . . . . . . . . . . . . 8 67 4.5. Management Frameworks and Data Models . . . . . . . . . . 8 68 5. Architectural Observations . . . . . . . . . . . . . . . . . 10 69 6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 71 8. Informative References . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 Network virtualization is network management pertaining to treating 77 different traffic categories in separate virtual networks, with 78 independent lifecycle management and resource, technology, and 79 topology choices. 81 This document makes some observations on the effects virtualization 82 on Internet architecture, as well as provides some guidelines for 83 further work at the IETF relating to virtualization. 85 This document also provides a summary of IETF technologies that 86 relate to network virtualization. An understanding of what current 87 technologies there exist and what they can or cannot do is the first 88 step in developing plans for possible extensions. 90 In particular, many IETF discussions earlier in the summer of 2017 91 started from a top-down view of new virtualization technologies, but 92 were often unable to explain the necessary delta to the wealth of 93 existing IETF technology in this space. This document takes a 94 different, bottom-up approach to the topic and attempts to document 95 existing technology, and then identify areas of needed development. 97 In particular, whether one calls a particular piece of technology 98 "virtualization", "slicing", "separation", or "network selection" 99 does not matter at the level of a system. Any modern system will use 100 several underlying technology components that may use different terms 101 but provide some separation or management. So, for instance, in a 102 given system you may use VLAN tags in an ethernet segment, MPLS or 103 VPNs across the domain, NAIs to select the right AAA instance, and 104 run all this top of virtualized operating system and software-based 105 switches. As new needs are being recognised in the developing 106 virtualization technology, what should drive the work is the need for 107 specific capabilities rather than the need to distinghuish a 108 particular term from another term. 110 2. Definitions 112 Network function virtualization is defined in Wikipedia as follows: 114 "Network function virtualization or NFV is a network architecture 115 concept that uses the technologies of IT virtualization to 116 virtualize entire classes of network node functions into building 117 blocks that may connect, or chain together, to create 118 communication services. 120 NFV relies upon, but differs from, traditional server- 121 virtualization techniques, such as those used in enterprise IT. A 122 virtualized network function, or VNF, may consist of one or more 123 virtual machines running different software and processes, on top 124 of standard high-volume servers, switches and storage devices, or 125 even cloud computing infrastructure, instead of having custom 126 hardware appliances for each network function." 128 We should not confuse NFV and network virtualization, the former, as 129 the name suggests is about functions virtualization, and not the 130 network. 132 The idea of network virtualization is almost as old as the networking 133 technology itself. Network virtualization is hierarchical and 134 multilayer in its nature, from layer 1 up to services on top. When 135 talking about virtualization we usually define overlay to underlay 136 relationship between different layers, bottom up. A VPN (Virtual 137 Private Network) [RFC4026] is the most common form of network 138 virtualization. The general benefits and desirability of VPNs have 139 been described many times and in many places ([RFC4110] and 140 [RFC4664]). 142 The only immutable infrastructure is the "physical" medium, that 143 could be dedicated or "sliced" to provide services(VPNs) in a multi- 144 tenant environment. 146 The term slicing has been used to describe a virtualization concept 147 in planned 5G networks. The 3GPP architecture specification 148 [TS-3GPP.23.501] defines network slices as having potentially 149 different "supported features and network functions optimisations", 150 and spanning functions from core network to radio access networks. 152 [I-D.king-teas-applicability-actn-slicing] defined slicing as "an 153 approach to network operations that builds on the concept of network 154 abstraction to provide programmability, flexibility, and modularity. 155 It may use techniques such as Software Defined Networking (SDN) and 156 Network Function Virtualization (NFV) to create multiple logical 157 (virtual) networks, each tailored for a set of services that are 158 sharing the same set of requirements, on top of a common network. 160 And, [I-D.geng-coms-problem-statement] defines slicing as a 161 management mechanism that an service provider can use to allocate 162 dedicated network resources from shared network infrastructures to a 163 tenant. 165 3. General Observations 167 Software vs. Protocols 169 Many of the necessary tools for using virtualization are software, 170 e.g., tools that enable running processes or entire machines in a 171 virtual environment decoupled from physical machines and isolated 172 from each other, virtual switches that connect systems together, 173 management tools to set up virtual environments, and so on. From 174 a communications perspective these tools operate largely in the 175 same fashion as their real-world counterparts do, except that 176 there may not be wires or other physical communication channels, 177 and that connections can be made in the desired fashion. 179 In general, there is no reason for protocols to change just 180 because a function or a connection exists on a virtual platform. 181 However, sometimes there are useful underlying technologies that 182 facilitiate connection to virtualized systems, or optimised or 183 additional tools that are needed in the the virtualized 184 environment. 186 For instance, many underlying technologies enable virtualization 187 at hardware or physical networking level. For instance, Ethernet 188 networks have Virtual LAN (VLAN) tags and mobile networks have a 189 choice of Access Point Names (APNs). These techniques allow users 190 and traffic to be put on specific networks, which in turn may 191 comprise of virtual components. 193 Other examples of protocols providing helpful techniques include 194 virtual private networking mechanisms or management mechanisms and 195 data models that can assist in setting up and administering 196 virtualized systems. 198 Protocols vs. Representations of Virtual Networks 200 Some of virtualization technology benefits from protocol support 201 either in the data or control plane. But there are also 202 management constructs, such as data models representing virtual 203 services or networks and data models useful in the construction of 204 such services. There are also conceptual definitions that may be 205 needed when constructing either protocols or data models or when 206 discussing service agreements between providers and consumers. 208 4. Overview of IETF Virtualization Technologies 210 General networking protocols are largely agnostic to virtualization. 211 TCP/IP does not care whether it runs on a physical wire or on a 212 computer-created connection between virtual devices. 214 As a result, virtualization generally does not affect TCP/IP itself 215 or applications running on top. There are some exceptions, though, 216 such as when the need to virtualize has caused previously held 217 assumptions to break, and the Internet community has had to provide 218 new solutions. For instance, early versions of the HTTP protocol 219 assumed a single host served a single website. The advent of virtual 220 hosting and pressure to not use large numbers of IPv4 addresses lead 221 to HTTP 1.1 adopting virtual hosting, where the identified web host 222 is indicated inside the HTTP protocol rather than inferred from the 223 reception of a request at particular IP address [VirtualHosting] 224 [RFC2616]. 226 But where virtualization affects the Internet architecture and 227 implementations is at lower layers, the physical and MAC layers, the 228 systems that deal with the delivery of IP packets to the right 229 destination, management frameworks controlling these systems, and 230 data models designed to help the creation, monitoring, or management 231 of virtualized services. 233 What follows is an overview of existing technologies and technologies 234 currently under development that support virtualization in its 235 various forms. 237 4.1. Lower layers 239 Some L2 technology allows the identification of traffic belonging to 240 a particular virtual network or connection. For instance, Ethernet 241 VLAN tags. There are some IETF technologies that also allow similar 242 identification of connections setup with the help of IETF protocols. 243 For instance, Network Access Identifiers may identify a particular 244 customer or virtual service within AAA, EAP or IKEv2 VPN connections. 246 4.2. Traffic Separation in VPNs 248 Technologies that assist separation and engineering of networks 249 include both end-point and provider-based VPNs. End-point VPN 250 tehchnologies include, for instance, IPsec-based VPNs [RFC4301]. 252 For providing virtualized services, however, provider-based solutions 253 are often the most relevant ones. L1VPN facilitates virtualization 254 of the underlying L0 "physical" medium. L2[IEEE802.1Q] facilitates 255 virtualization of the underlying Ethernet network Tunneling over IP 256 (MPLS, GRE, VxLAN, IPinIP, L2TP, etc) facilitates virtualization of 257 the underlying IP network - MPLS LSP's - either traffic engineered or 258 not belong here L2VPN facilitates virtualization of a L2 network 259 L3VPN facilitates virtualization of a L3 network. 261 The IETF has defined a multiplicity of technologies that can be used 262 for provider-based VPNs. The technologies choices available can be 263 described along two axes, control mechanisms and dataplane 264 encapsulation mechanisms. The two are not compeltely orthogonal. 266 In the data plane, for provider based VPNs, the first important 267 observation is that the most obvious encapsulation is NOT used. 268 While IPSec could be used for provider-based VPNs, it does not appear 269 to be used in practice, and is not the focus for any of the available 270 control mechanisms. Often, when end2end encryption is required it is 271 used as an overlay over MPLS based L3VPN 273 The common encapsulation for provider-based VPNs is to use MPLS. 274 This is particularly common for VPNs within one operator, and is 275 sometimes supported across operators. 277 Keyed GRE can be used, particularly for cross-operator cases. 278 However, it seems to be rare in practice. 280 The usage of MPLS for provider-based VPNs generally follows a pattern 281 of using two (or more) MPLS labels, top (transport) label to 282 represent the remote end point/egress provider-edge device, and 283 bottom (service) label to signal the different VPNs on the remote end 284 point. Using TE might result in a deeper label stack. 286 L2 VPNs could be signaled thru LDP[RFC4762] or MP-BGP[RFC4761], L3 287 VPN is signaled thru MP-BGP[RFC4364] 288 The LDP usage to control VPN establishment falls within the PALS 289 working group, and is used to establish pseudo-wires to carry 290 Ethernet (or lower layer) traffic. The Ethernet cases tend to be 291 called VPLS (Virtual Private LAN Service) for multi-point 292 connectivity and VPWS (Virtual Private Wire Service) for point-to- 293 point connectivity. These mechanism do augment the data plane 294 capabilites with control words that support additional features. In 295 operation, LDP is used to signal the communicating end-points that 296 are interested in communicating with each other in support of 297 specific VPNs. Information about the MAC addresses used behind the 298 provider edges is exchanged using classic Ethernet flooding 299 technology. It has been proposed to use BGP to bootstrap the exchang 300 eof information as to who the communicating endpoints are. 302 BGP can be used to establish Layer 2 or Layer 3 VPNs. Originally, 303 the BGP based MPLS VPN technology was developed to support layer 3 304 VPNs. the BGP exchanges uses several different features in MP-BGP 305 (specifically route distinguishers and route targets) to control the 306 distribution of information about VPN end-points. The BGP 307 information carries the VPN IP address prefixes, and the MPLS labels 308 to be used to represent the VPN. This technolgoy combination is 309 generally known as L3VPN. 311 This usage of BGP for VPNs has been extended to support Layer 2 VPNs. 312 This is known as EVPN. The BGP exchanges are used to carry the MAC 313 address reachability behind each provider edge router, providing an 314 Ethernet multipoint service without a need to flood unkown- 315 destination Ethernet packets. 317 In theory, the BGP mechanisms can also be used to support other 318 tunnels such as keyed GRE. That is not widely practiced. 320 There are also hybrid variations, such as adding an ARP / ND proxy 321 service so that an L3VPN can be used with an L2 Access, when the only 322 desired service is IP. 324 4.3. Traffic Engineering and QoS 326 Traffic Engineering (TE) is the term used to refer to techniques that 327 enable operators to control how specific traffic flows are treated 328 within their networks. 330 The TEAS working group works on enhancements to traffic-engineering 331 capabilities for MPLS and GMPLS networks: 333 TE is applied to packet networks via MPLS TE tunnels and LSPs. 334 The MPLS-TE control plane was generalized to additionally support 335 non-packet technologies via GMPLS. RSVP-TE is the signaling 336 protocol used for both MPLS-TE and GMPLS. 338 The TEAS WG is responsible for: 340 * Traffic-engineering architectures for generic applicability 341 across packet and non-packet networks. 343 * Definition of protocol-independent metrics and parameters. 345 * Functional specification of extensions for routing (OSPF, 346 ISIS), for path computation (PCE), and RSVP-TE to provide 347 general enablers of traffic-engineering systems. 349 * Definition of control plane mechanisms and extensions to allow 350 the setup and maintenance of TE paths and TE tunnels that span 351 multiple domains and/or switching technologies. 353 Traffic engineering is a common requirement for many routing systems, 354 and also discussed, e.g., in the context of LISP. 356 4.4. Service Chaining 358 The SFC working group has defined the concept of Service Chaining: 360 Today, common deployment models have service functions inserted on 361 the data-forwarding path between communicating peers. Going 362 forward, however, there is a need to move to a different model, 363 where service functions, whether physical or virtualized, are not 364 required to reside on the direct data path and traffic is instead 365 steered through required service functions, wherever they are 366 deployed. 368 For a given service, the abstracted view of the required service 369 functions and the order in which they are to be applied is called 370 a Service Function Chain (SFC). An SFC is instantiated through 371 selection of specific service function instances on specific 372 network nodes to form a service graph: this is called a Service 373 Function Path (SFP). The service functions may be applied at any 374 layer within the network protocol stack (network layer, transport 375 layer, application layer, etc.). 377 4.5. Management Frameworks and Data Models 379 There have been two working groups at the IETF, focusing on data 380 models describing VPNs. The IETF and the industry in general is 381 currently specifying a set of YANG models for network element and 382 protocol configuration [RFC6020]. 384 YANG is a powerful and versatile data modeling language that was 385 designed from the requirements of network operators for an easy to 386 use and robust mechanism for provisioning devices and services across 387 networks. It was originally designed at the Internet Engineering 388 Task Force (IETF) and has been so successful that it has been adopted 389 as the standard for modeling design in many other standards bodies 390 such as the Metro Ethernet Forum, OpenDaylight, OpenConfig, and 391 others. The number of YANG modules being implemented for interfaces, 392 devices, and service is exploding. 394 A service model is an abstract model, at a higher level than network 395 element or protocol configuration. A service model for VPN service 396 describes a VPN in a manner that a customer of the VPN service would 397 see it. 399 It needs to be clearly understood that such a service model is not a 400 configuration model. That is, it does not provide details for 401 configuring network elements or protocols: that work is expected to 402 be carried out in other protocol-specific working groups. Instead, 403 service models contain the characteristics of the service as 404 discussed between the operators and their customers. A separate 405 process is responsible for mapping this customer service model onto 406 the protocols and network elements depending on how the network 407 operator chooses to realise the service. 409 The L2SM WG specifies a service model for L2-based VPNs: 411 The Layer Two Virtual Private Network Service Model (L2SM) working 412 group is a short-lived WG. It is tasked to create a YANG data 413 model that describes a L2VPN service (a L2VPN customer service 414 model). The model can be used for communication between customers 415 and network operators, and to provide input to automated control 416 and configuration applications. 418 It is recognized that it would be beneficial to have a common base 419 model that addresses multiple popular L2VPN service types. The 420 working group derives a single data model that includes support 421 for the following: 423 * point-to-point Virtual Private Wire Services (VPWS), 425 * multipoint Virtual Private LAN services (VPLS) that use LDP- 426 signaled Pseudowires, 428 * multipoint Virtual Private LAN services (VPLS) that use a 429 Border Gateway Protocol (BGP) control plane as described in 430 [RFC4761] and [RFC6624], 432 * Ethernet VPNs specified in [RFC7432]. 434 Other L2VPN service types may be included if there is consensus in 435 the working group. 437 Similarly, the L3SM WG specified a sevice model for L3-based VPNs. 439 The Layer Three Virtual Private Network Service Model (L3SM) 440 working group is a short-lived WG tasked to create a YANG data 441 model that describes a L3VPN service (a L3VPN service model) that 442 can be used for communication between customers and network 443 operators, and to provide input to automated control and 444 configuration applications. 446 It needs to be clearly understood that this L3VPN service model is 447 not an L3VPN configuration model. That is, it does not provide 448 details for configuring network elements or protocols. Instead it 449 contains the characteristics of the service. 451 5. Architectural Observations 453 This section makes some observations about architectural trends and 454 issues. 456 Role of Software 458 An obvious trend is that bigger and bigger parts of the 459 functionality in a network is driven by software, e.g., 460 orchestration or management tools that figure out how to control 461 relatively simple network element functionality. The software 462 components are where the intelligence is, and a smaller fraction 463 of the intelligence resides in network elements, nor is the 464 intelligence encoded in the behaviour rules of the protocols that 465 the network elements use to communicate with each other. 467 Centralization of Functions 469 An interesting architectural trend is that virtualization and data 470 /software driven networking technologies are driving network 471 architectures where functionality moves towards central entities 472 such as various controllers, path computation servers, and 473 orchestration systems. 475 A natural consequence of this is the simplification (and perhaps 476 commoditization) of network elements, while the "intelligent" or 477 higher value functions migrate to the center. 479 The benefits are largely in the manageability, control, and speed 480 of change. There are, however, potential pitfalls to be aware of 481 as well. First off, networks need to continue to be operate even 482 under partial connectivity situations and breakage, and it is key 483 that designs can handle those situations as well. 485 And it is important that network users and peers continue to be 486 able to operate and connect in the distributed, voluntary manner 487 that we have today. Today's virtualization technology is 488 primarily used to manage single administrative domains and to 489 offer specific service to others. One could imagine centralised 490 models being taken too far as well, limiting the ability of other 491 network owners to manage their own networks. 493 Tailored vs. general-purpose networking 495 The interest in building tailored solutions, tailored Quality-of- 496 Service offerings vs. building general-purpose "low touch" 497 networks seems to fluctuate over time. 499 It is important to find the right balance here. From an economics 500 perspective, it may not be feasible to provide specialised service 501 -- at least if it requires human effort -- for large fraction of 502 use cases. Even if those are very useful in critical 503 applications. 505 Need for descriptions 507 As networks deal more and more with virtual services, there arises 508 a need to have generally understood, portable descriptions of 509 these service. Hence the creation of YANG data models 510 representing abstract VPN services, for instance. 512 We can also identify some potential architectural principles, such 513 as: 515 Data model layering 516 Given the heterogenuity of networking technologies and the 517 differing users that data models are being designed for, it seems 518 difficult to provide a single-level model. It seems preferable to 519 construct a layered set of models, for instance abstract, user- 520 facing models that specify services that can then be mapped to 521 concrete configuration model for networks. And these can in turn 522 be mapped to individual network element configuration models. 524 Getting this layered design right is crucial for our ability to 525 evolve a useful set of data models. 527 General over specific 529 In the quick pace of important developments, it is tempting to 530 focus on specific concepts and service offerings such as 5G 531 slicing. 533 But a preferrable approach seems to provide general-purpose tools 534 that can be used by 5G and other networks, and whose longetivity 535 exceeds that of a version of a specific offering. The quick 536 development pace is likely driving the evolution of concepts in 537 any case, and building IETF tools that provide the ability to deal 538 with different technologies is most useful. 540 6. Further Work 542 There may be needs for further work in this area at the IETF. Before 543 discussing the specific needs, it may be useful to classify the types 544 of useful work that might come to question. And perhaps also outline 545 some types of work that is not appropriate for the IETF. 547 The IETF works primarily on protocols, but in many cases also with 548 data models that help manage systems, as well as operational guidance 549 documents. But the IETF does not work on software, such as 550 abstractions that only need to exist inside computers or ones that do 551 not have an effect on protocols either on real or simulated "wires". 553 The IETF also does not generally work on system-level design. IETF 554 is best at designing components, not putting those components 555 together to achieve a particular purpose or build a specific 556 application. 558 As a result, IETF's work on new systems employing virtualization 559 techniques (such as 5G slicing concept) is more at the component 560 improvement level than at the level of the concept. There needs to 561 be a mapping between a vision of a system and how it utilizes various 562 software, hardware, and protocol tools to achieve the particular 563 virtualization capabilities it needs to. Developing a new concept 564 does not necessarily mean that entirely new solutions are needed 565 throughtout the stack. Indeed, systems and concepts are usually 566 built on top of solid, well defined components such as the ones 567 produced by the IETF. 569 That mapping work is necessarily something that those who want to 570 achieve some new functionality need to do; it is difficult for others 571 to take a position on what the new functionality is. But at the same 572 time, IETF working groups and participants typically have a 573 perspective on how their technology should develop and be extended. 574 Those two viewpoints must meet. 576 The kinds of potential new work in this space falls generally in the 577 following classes: 579 Virtualization selectors 581 Sometimes protocols need mechanisms that make it possible to use 582 them as multiple instances. E.g., VLAN tags were added to 583 Ethernet frames, NAIs were added to PPP and EAP, and so on. These 584 cases are rare today, because most protocols and mechanisms have 585 some kind of selector that can be used to run multiple instances 586 or connect to multiple different networks. 588 Traffic engineering 590 A big reason for building specific networks for specific purposes 591 is to provide an engineered service level on delay and other 592 factors to the given customer. There are a number of different 593 tools in the IETF to help manage and engineer networks, but it is 594 also an area that continues to develop and will likely see new 595 functionality. 597 Virtual service data models 599 Data models -- such as those described by L2SM or L3SM working 600 groups can represent a "service" offered by a network, a setup 601 built for a specific customer or purpose. 603 Some specific areas where work is likely needed include: 605 o The ability to manage heterogenous technologies, e.g., across SDN 606 and traditionally built networks, or manage both general-purpose 607 and very technology-specific parameters such as those associated 608 with 5G radio. 610 o The ability to specify "statistical" rather than hard performance 611 parameters. In some networks -- notably with wireless technology 612 -- recent advances have made very high peak rates possible, but 613 with increased bursty-ness of traffic and with potential 614 bottlenecks on the aggregation parts of the networks. The ability 615 to specify statistical performance in data models and in VPN 616 configuration would be important, over different timescales and 617 probabilities. 619 o Cross-domain: A big problem is that we have little tools for 620 cross-domain management of virtualized networks and resources. 622 Finally, there is a question of where all this work should reside. 623 There's an argument that IETF-based virtualization technologies 624 deserve proper management tools, including data models. 626 And there's another argument that with the extensive use of 627 virtualization technology, solutions that can manage many different 628 networks should be general, and as such, potential IETF work 629 material. Yet, the IETF is not and should not be in the space of 630 replacing various tools and open source toolkits that have been 631 created for managing virtualization. It seems though that work on 632 commonly usable data models at several layers of abstraction would be 633 good work at the IETF. 635 7. Acknowledgements 637 The authors would like to thank Gonzalo Camarillo, Gabriel 638 Montenegro, Alex Galis, Adrian Farrell, Liang Geng, Yi Zhao, Hannu 639 Flinck, Yi Zhao, Barry Leiba, Georg Mayer, Benoit Claise, Warren 640 Kumari, Ted Hardie, and many others for interesting discussions in 641 this problem space. 643 8. Informative References 645 [CC2015] claffy, kc. and D. Clark, "Adding Enhanced Services to the 646 Internet: Lessons from History", September 2015 (https:// 647 www.caida.org/publications/papers/2015/ 648 adding_enhanced_services_internet/ 649 adding_enhanced_services_internet.pdf). 651 [I-D.geng-coms-problem-statement] 652 67, 4., Slawomir, S., Qiang, L., Matsushima, S., Galis, 653 A., and L. Contreras, "Problem Statement of Supervised 654 Heterogeneous Network Slicing", draft-geng-coms-problem- 655 statement-00 (work in progress), September 2017. 657 [I-D.ietf-sfc-nsh] 658 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 659 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 660 November 2017. 662 [I-D.king-teas-applicability-actn-slicing] 663 King, D. and Y. Lee, "Applicability of Abstraction and 664 Control of Traffic Engineered Networks (ACTN) to Network 665 Slicing", draft-king-teas-applicability-actn-slicing-01 666 (work in progress), July 2017. 668 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 669 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 670 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 671 RFC2616, June 1999, . 674 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 675 Private Network (VPN) Terminology", RFC 4026, DOI 10.17487 676 /RFC4026, March 2005, . 679 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 680 Provider-Provisioned Virtual Private Networks (PPVPNs)", 681 RFC 4110, DOI 10.17487/RFC4110, July 2005, . 684 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 685 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 686 December 2005, . 688 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 689 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 690 10.17487/RFC4664, September 2006, . 693 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 694 LAN Service (VPLS) Using BGP for Auto-Discovery and 695 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 696 . 698 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 699 the Network Configuration Protocol (NETCONF)", RFC 6020, 700 DOI 10.17487/RFC6020, October 2010, . 703 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 704 Virtual Private Networks Using BGP for Auto-Discovery and 705 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 706 . 708 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 709 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 710 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 711 2015, . 713 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 714 Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/ 715 RFC8049, February 2017, . 718 [TS-3GPP.23.501] 719 3GPP, "3rd Generation Partnership Project; Technical 720 Specification Group Services and System Aspects; System 721 Architecture for the 5G System; Stage 2 (Release 15)", 722 3GPP Technical Specification 23.501, July 2017. 724 [VirtualHosting] 725 Wikipedia, "Virtual Hosting", Wikipedia article https:// 726 en.wikipedia.org/wiki/Virtual_hosting, August 2017. 728 Authors' Addresses 730 Jari Arkko 731 Ericsson 732 Kauniainen 02700 733 Finland 735 Email: jari.arkko@piuha.net 737 Jeff Tantsura 738 Futurewei, Future Networks 740 Email: jefftant.ietf@gmail.com 742 Joel Halpern 743 Ericsson 745 Email: joel.halpern@ericsson.com 746 Balazs Varga 747 Ericsson 748 Budapest 1097 749 Hungary 751 Email: balazs.a.varga@ericsson.com