reased latency. Automation for configuration management as well as activation, deactivation, and movement of vPE will become VNF specific. Even with VNF-specific logic, movement of forwarding plane VNF instances will cause service discontinuity (i.e., outages). One of the solutions is to provide continuous (i.e., nonstop) forwarding capability for middle box VNFs in a multihomed design where a single customer end point is connected to two different forwarding VNF instances. The problem of managing quality-of-service capability (rate shaping), described in Section 3.4.1 forces an active- standby design rather than a load-balanced design of two forwarding VNF instances. This is due to the existence of BGP sessions between each of the vPE forwarding VNF instances and end custom- ers. Movement of the forwarding VNF instance will cause the BGP session to reset, resulting in a short-duration outage. The best we can do is to manage BGP timers to keep the duration of such outages to 10 of seconds. Setting BGP timers too low can cause unnecessary BGP resets if a circuit has a very short duration outage.* In summary, middle box VNF design is complex and requires VNF-specific logic in order to make the design resilient. This is a point that is often lost when network virtualization is compared to running Web services over a traditional cloud. Web services use host VNFs and therefore can rely entirely on the cloud platform capabilities for resiliency. 3.5 NFV ECONOMICS Traditional networks follow a near-fixed-cost model. Network design utilizes dedicated hardware for each function, independently scaled at each location. Capacity is added incrementally, by adding plugs in deployed shelves, and since the time needed to enhance capacity by deploying new shelves can be substantial, there is a tendency to deploy more shelf capacity than needed. On the other hand, NFV allows a variable-cost model that has been widely supported in cloud architectures for IT workloads. Service providers have been on an aggressive multiyear journey t