e for upgrading the software on a VNF. Changes are a frequent occurrence in service provider networks and consume significant operational resources. Network designers and operators go to significant length to minimize customer impact. In legacy, hardware-based environments, network engineers have permanently deployed spare network element capacity to carry traffic dur- ing software upgrades, worked with vendors to implement hitless software upgrades, or in extreme cases where neither may be available or practical, they simply have to accept that maintenance activities may result in customer service disruptions. In contrast, with NFV we can spin up new versions of the software on demand-this can be used to streamline change management activities by spinning up a new VNF with the updated software version; traffic can then be moved over to the new VNF with minimal service impact. Thus, we can cost effectively minimize customer impact without having to deploy costly spare network hardware. This does require some spare capacity in the cloud that can be used to spin up the new VNF but it is taken from a pool of capacity that sup- ports multiple VNFs. This approach impacts how change management is performed, and requires corresponding ONAP functionality and analytics to enable automation. 15.2.2 NFV-RELATED CHALLENGES Although NFV promises exciting benefits, it comes with associated challenges. Capacity planning for a shared cloud infrastructure supporting large numbers of VNFs that can be dynamically spun up and down as needed has its challenges. Accurate forecasts are vital; as is timely deployment of new server capacity. However, achieving this in a very dynamic world and with variable VNF deployment timelines is challenging, especially as large numbers of new VNF technologies are being rolled out. With SO much riding on this shared infrastructure, if capacity is not available when required, it could have tremendous impact both on VNF deployment timelines, and on service reli- ability and performance. Standardizing V