alarms, multiple independent operations teams will all be notified of the issues being experienced at the different network layers, and they will all independently start their investigation. However, in reality, the only team that can actively repair the underlying issue is the team responsible for the server that is dropping the packets; the operations teams or automation at the higher layers may be able to take actions to mitigate the impact of the server issues (e.g., by moving the corresponding VMs to a different physical server), if they can isolate the issue to the offending server. We use correlation [CORRELATION] to associate the alarms across physical and different network software layers, and between neighboring network elements and at the service level. Correlation and other alarm dampening techniques reduce the number of automated responses or tickets opened with operators by many orders of magnitude compared with the number of alarms. In the example above, the plethora of alarms generated at the hardware, IP, and mobility element and service layers can all be associated together and isolated to the offending server. By generating a single, correlated alarm, the impaired server will be automatically identified, as will be the impact of that impairment on corresponding VNFs and network services. With this resulting signature of the event identified, ONAP can then look up policies (rules) to determine what action(s) to take- whether this be automated actions such as moving the impacted VNFs to a new server, or ticketing for further human investigation and repair. The control loop events that are detected, the correlations that are performed and the resulting actions to be taken are all specified by service designers and network operators via ONAP policies. In our above example, policies are defined to specify the alarms that are to be generated for the server, VNFs and service layer monitoring, and the specific correlation rules that inform ONAP's correlation engine on how to associate these alarms to c