," it is simply (and rapidly) replaced with another one. Moving to a "cattle" model using NFV requires the following: (1) standardizing management interfaces to maximize commonality across VNFs from different vendors and (2) being able to rap- idly spin up new network functions on demand and migrate customer traffic to these with minimal customer impact. In a world built on custom hardware and ASICs, it was typically deemed infeasible to standardize how network elements were deployed and configured, and standardize the data generated by them, as functions were quite different. However, the move to commodity hardware and software imple- mentations of network functions opens up the opportunity to fundamentally transform network operators' operating models by standardizing much of the functionality across VNF interfaces. As VNF management interfaces become increasingly standardized, enabling common mecha- nisms for deploying, configuring, and managing VNFs, the diversity of domain knowledge and operational know-how required to manage the plethora of different types of network functions deployed in carrier networks will be reduced. OSSs and SDN platforms such as ONAP will be considerably simpler and cheaper to build as we reduce or even eliminate the need to implement vendor-specific interfaces to manage VNFs and to process vendor-specific logs, alarms, and mea- surements. Having standardized interfaces should also simplify outage management. For example, in a traditional network, localizing and resolving the more esoteric and complex service issues often necessitates involving teams representing a wide range of network elements. When there is a complex outage, many individuals join outage conference bridges (audio calls organized to do rapid triage), with the intent of identifying which specific network function (network element) is impaired and thus identify the corresponding operations team responsible for resolving the issue. This is an inefficient use of resources, driven by the complexity of some of the issues 