is that upgrades should be transparent to the tenant (hitless). When possible, major upgrades should be decomposed into tasks that can be performed in off-peak main- tenance windows. The frequency of major upgrades (where stateful applications must redi- rect traffic away from the site being upgraded) should be very infrequent. Architecting the Network Cloud for High Availability The network cloud should use DNS-based routing to facilitate traffic redirection (e.g., use of fully qualified domain names rather than static IP addresses for routing). This section examined the interrelation between planned downtime and georedundancy, high- lighting design considerations for achieving 5-9s "carrier grade" availability. Several key conclu- sions became evident: VF availability is extremely sensitive to both planned and unplanned site downtime At least N+1 redundancy is required to achieve 5-9s availability with a 3-9s site avail- ability, even with no planned downtime At least N+2 redundancy may be required to additionally accommodate lengthy planned downtime Additional capacity must be (over)provisioned in order to ensure sufficient VF capacity to tolerate simultaneous planned and unplanned site outages Spreading the same amount of capacity across more sites greatly increases VF resiliency to lengthy planned upgrades in a 3-9s cloud environment An upgrade cycle framework is needed to ensure that no two sites used by the same VF are upgraded at the same time To summarize, VF applications should be designed for a Network Cloud environment. They should support local redundancy using multiple availability zones, L2/L3 connectivity between VMs in different availability zones, and automatic local failover. Some applications should support at least an N+2 site georedundancy with automatic geo-failover and orchestrated movement of traf- fic between georedundant sites. VF SOFTWARE DESIGN Before any software design is initiated, there should be a clear understanding of the key perfor- mance indicators (KPIs), or requirements. Ty