onclude that they are related and that the server is the underlying offender. Policies also govern ONAP's responses to the detected issue; in this example specifying that the impacted VNFs should be migrated to a new server, taking the failed server out of service, and logging the underlying server issue SO that the failed hardware can be scheduled for repair. Policies can become rather sophisticated; for example, allowing for differ- ent actions to be attempted depending on the success of previously attempted actions, and dynami- cally invoking automated, active tests on VNFs and service performance. However, although the move to this policy-based mode increases flexibility, it also introduces additional risk, requires the lifecycle management of policies and also introduces the need to carefully understand potential policy interactions. We thus need to be careful to provide a balance between the flexibility and the risk, complexity, and manageability of policy-based control. We discuss this more in Section 15.2.4.1. As service designers and network operators design control loops, they should keep customer experience in the forefront of their policy designs. Service quality management (SQM) comple- ments traditional fault and performance management, by detecting issues that may otherwise be flying under operations' radar (i.e., were not detected within the network) and by quantifying the customer impact of known network impairments. Building the Network of the Future Service performance measurements, as discussed in Section 15.2.3.1, can be used to detect degraded customer experience. By relating degraded customer experience with known network faults and performance impairments, we can identify and consequently mitigate issues that may not have been detected within the network (i.e., silent failures). And by relating the customer impact to the known network events, we can prioritize resolution activities based on customer impact, or schedule customer impacting mitigation actions to minimize overall customer impa