e efficient VNF interoperation, and since VNFs can be sourced from multiple vendors, AT&T has compiled the following best practices for VNF design: VFs must be agnostic to the details of the cloud platform (e.g., hardware, host OS, hypervi- sor) and must run on a shared standard cloud with acknowledgment to the paradigm that the cloud platform will continue to rapidly evolve and the underlying components of the platform will change regularly. The VF design must use cloud-based paradigms to enable standardization of technology, scalability, and reliability. Decomposition of network functions must be supported. The ability to reuse VFs must be supported SO that services can be created rapidly by chaining the VFs based on service needs. Long-lived state and end-user (subscriber/customer) data should be decoupled from pro- cessing logic. Geo-resiliency and the ability to deploy with local and geo-redundancy should be sup- ported for VFs. Common platform solutions (e.g., cloud-based load-balancers, databases, resiliency solu- tions, etc.) instead of vendor-proprietary solutions, should be supported where possible. Standardized mechanisms for fault configuration, accounting, performance, and security (FCAPS) functions must be supported by VFs. The VF design should meet the resiliency, availability, and performance (e.g., real-time response) requirements of the service. Transition to a cloud-based design should be transparent to the end user. VFs must be able to be instantiated and controlled via ONAP functions. A VF or its com- ponent should not interact directly with the OpenStack infrastructure. Open and standard APIs must be supported. Idempotent interfaces should be implemented in all possible cases. VFs should run without modifications on standard guest OS images. Vendor-provided guest os images should be supported with restrictions. ACKNOWLEDGMENT The authors would like to acknowledge Chris Chase for his contribution of ideas to this chapter. REFERENCES Anderson, L. 2006. Framework for Layer 2 Virtual Private Net