irtual machine (VM), re-initiating failed VNFs, rerouting traffic, or spinning up new VNFs. However, not all issues can be automatically resolved-either because the issue cannot be automatically localized or the miti- gating response is either not currently automated or fundamentally cannot be automated. In such situations, the control loop will notify a network operator (human being) via ticketing or similar mechanisms SO that the operator can intervene to resolve the issue. The biggest challenge in resolving faults, performance, and service degradations is in localiz- ing and troubleshooting issues-identifying where the problem is, and what is causing it. Without knowing where the issue stems from, and in many cases the specific root cause of an issue, the abil- ity to take effective actions is seriously inhibited. Network Operations A single underlying issue will typically result in a plethora of alerts and alarms. To illustrate this, let us consider an example of a server that is dropping packets due to high server load. This issue should be alarmed on in the physical layer, where the packet loss, high load, and corresponding high CPU should be detected and alerted on. Any VNFs that reside on the server that are also impaired will also alarm. Let us assume that one of these VNFs is a network router, which is experiencing high packet loss and thus generates a corresponding alarm. This router is in turn leveraged to sup- port a mobility network service, connecting two mobility network VNFs. These mobility VNFs will also detect the packet loss experienced between the two VNFs and alarm, and corresponding mobility service alarms will also be generated. Thus, we have alarms being generated at multiple network layers, on individual components and representing the overall service experience. With all of these different alarms being simultaneously generated, how can ONAP know what automated actions to take? Even if these alarms are simply passed on to network operators to resolve, without automation to combine these 