ent components lack standard interfaces for some lifecycle operations and tend to be optimized for a particular service or not easily shared across different services. This increases cost and time to perform lifecycle operations such as initial delivery, upgrades, routine maintenance, repair of faults, etc. and requires dedicated infrastructure and skills. The time to design, integrate, and deploy infrastructure with staff trained to operate it at scale limits the flexibility of a service provider to deliver new services. New or emerging service volumes and uncertainty of growth make it hard to justify the investment and the long lead time to deliver increases risk of missing market opportunities. The ETSI NFV2 effort described above produced a specification for VNF management and orchestration (MANO). ONAP expands on ETSI MANO by adding a comprehensive service design studio to onboard resources, create services, and define lifecycle operations; closed-loop control based on telemetry, analytics, and policy-driven lifecycle management actions; a model-driven plat- form to accelerate and reduce costs of onboarding functions and eliminate VNF-specific manage- ment systems; and support for PNF. A consistent plan that includes both how ONAP capabilities replace traditional OSS/BSS sys- tems such as fault correlation, performance analysis, and element management and how these tradi- tional systems are phased out is critical for the transition period where there is a mix of traditional physical network (PNF) and new virtualized (VNF) infrastructure. Without a clear plan for both, there is a risk that traditional systems and design assumptions get integrated with service designs on the ONAP platform, thus decreasing the benefit of highly automated operation and increasing maintenance costs. Chapter 6 describes the ONAP software platform that supports the design and operation of ser- vices in a Network Cloud. This platform is visible as APIs to software designers and develop- ers creating services and virtual functions; o