tics and tooling across diverse VNFs and services. In the next section, we will look at how ONAP facilitates different operational tasks, including service and VNF provisioning, capacity management, traffic management, fault, performance and service quality management (SQM), and change management. 15.2.3.1 Deploying and Deleting VNFs New service deployment, capacity augmentation, traffic management, and even fault and perfor- mance management all rely on ONAP's ability to automatically spin up and configure VNFs. VNF provisioning, also known as instantiation, describes deploying and configuring a new VNF. Parameters for configuring the VNF, such as IP addresses, need to be either automatically selected or input to the ONAP system-ideally from automated, external interfaces. ONAP is then responsible for determining where to spin up the new VNF, spinning up the VNFs on spare cloud capacity, configuring the VNF, and then validating that the new VNF has been successfully instantiated. Historically, network planners have expended significant time and effort designing long-term capacity augmentations; they had to plan well ahead due to the long lead times related to deploying physical network elements and (where required) provisioning high capacity links between offices. However, it is impossible to accurately predict needs too far in advance, and thus capacity ends up being suboptimally deployed. This leads to additional complexity in operating the network, with operators needing to adjust traffic routing (particularly under failure scenarios) according to avail- able capacity. ONAP and NFV together enable VNF capacity to be made available where and when it is needed. However, we still need to interconnect data centers. For very-high-speed links such as those used between IP routers, connecting two offices has historically required provisioning times on the order of months as planners first design the circuits and then field technicians manually connect circuits together at intermediate offices to establish connectivi