F Error Handling As a VF is migrated into the cloud environment from a traditional tightly coupled hardware or software configuration, a new potential for error situations will likely present itself. This includes, but is not limited to, network transport errors between instances of the VF, instance unavailability, local area network (LAN) latency, and software errors. VFs need to identify these classes of error conditions and potentially retry requests as appropriate to complete the requested service success- fully instead of returning the client an error condition. 5.3.2.3 VF Software Fault Detection If a VF component instance fails, that failure should be detected in seconds (or even milliseconds) and a mechanism to initiate an automated recovery of that instance should be provided. In the cloud world, that typically involves the recreation of the VM and/or the recreation of the failed instance. If automated recovery is not possible, notification mechanisms should be in place to create an alert for Building the Network of the Future the failure. ONAP can be leveraged to utilize capabilities to monitor and react to failures and poten- tially provide recovery capabilities. In either case, care should be taken to ensure other instances can absorb and process traffic to the failed instance until a new instance is available. 5.3.2.4 VF Failure Detection and Alerting VFs should have the ability to detect failures and/or unhealthy states of instances and generate alerts that result in corrective action. These failures should include both functional failures as well as exhaustion of resources (such as threads, queue limits, or memory structures), which may lead to catastrophic failure. In order to minimize silent failures, external probes are also an essential ele- ment for achieving accurate failure detection. 5.3.2.5 VF Fast Recovery VF instances should support fast recovery from all failure types. Creation of recovered instances should be in the minutes or seconds range and should not impact or have dependencies up