uch as that illustrated above. When issues are detected, feedback is provided to policy designers SO that policies can be redesigned to avoid these types of issues. If interface load <= 100% then Shut down interface FIGURE 15.6 Example "bad" policy. Control loop policy 1: Control loop policy 2: If VM available memory < 20GB then If VM available memory < 15GB then Reboot VM Migrate VM FIGURE 15.7 Conflicting control loop policies. Building the Network of the Future 15.2.4.2 Identifying Operations Policies Another significant challenge is identifying the operational policies, particularly related to control loops. ONAP's policy framework empowers operators and designers to control ONAP's behavior. However, the domain knowledge that is to be captured in ONAP policies is often distributed across many network operators and engineers, making it a challenge to synthesize. As new VNF software is introduced into field environments, there are likely software bugs that are not even known to network operators and even the VNF vendors; they are only revealed over time as events are inves- tigated in depth and common patterns are revealed. Machine learning offers opportunities to come to the rescue here by helping service providers automatically learn policies. In the case of control loops, machine learning enables signatures and actions to be automatically captured by mining vast amounts of historical alarm, performance, and log data. Machine learning can identify which events are statistically correlated, and are thus candidates for alarm correlation. Machine learning can also be used in conjunction with logs capturing human operator actions and other network data to identify which signatures (correlated events) typically trigger operators to take specific actions. For example, using historical or laboratory logs that capture when operators manually reboot VMs along with a range of other network data sources (alarms, logs, performance measurements), machine learning techniques can be used to identify what combination of alar