NF interfaces to provide common mechanisms for deploying, configuring, and managing network functions requires an industry-wide commitment. Making this transformation a reality is a tough task, and will require significant partnerships and push from standards bod- ies, the open source communities, network operators, and VNF vendors. Standards bodies are the Building the Network of the Future traditional forum used by the telecommunications industry to converge on agreements, but increas- ingly service providers are leveraging engagements and contributions in open source communities to drive change. Another challenge results from the introduction of new network interfaces that must be man- aged by network operators. After years of eliminating network layers (e.g., ATM), virtualization is introducing additional complexity by introducing separate layers-the physical layer (compute and storage platforms, also referred to as the hardware layer) and logical (VNF/software) layer(s). Historically, these two layers were combined within a single, integrated hardware/software platform (network element) and a given type of network element was managed by a proprietary EMS and a single operations team. With the new division introduced, different operations teams will typically manage the hardware and the software layers. An issue at the hardware layer (cloud servers) that impacts the software layer (VNF) will alarm at both layers. Without appropriate intelligence and automation, the alarming on the hardware and software layers could result in both the hardware operations team and the team managing the VNF to simultaneously respond to the issues reported and investigate root cause in parallel. This would be a tremendous waste of valuable operational resources, as in reality only the hardware team needs to investigate; the VNF team may have to mitigate the issue by re-instantiating the failed VNF on new hardware (if not an automated func- tion), but it would be a waste of resources looking for potential root causes of the impair