a branch office, then a firewall is likely needed at the site or in the network supporting that Internet gateway and support all their sites via a larger network-based firewall. In all cases, a firewall needs to be orchestrated and managed on the service provider's network. This function needs to be stored in a catalog where it can be instantiated in the appropriate location to meet the customer requirements. This is covered in more detail in Chapter 9. 3.3.5 MULTI AND SINGLE TENANCY Many existing network functions are multitenant by design. For example, a PE router supporting MPLS VPN services is multitenant; it supports many enterprise customers on a common plat- form. The existing PE router has many physical interfaces, typically Ethernet, that are virtualized Model A Customer Site VNF in uCPE Any Access VNF in NVP in VPLS-PE Locations Netbond and NoD Model B Customer Cloud Partner VNF in AIC - Bump in the Ethernet Model C Netbond VNF in NetBond-enabled Customer Clouds Any Access FIGURE 3.11 VNF deployment models. Building the Network of the Future (e.g., VLANs) to support many separate customers. The existing hardware supports both data plane and control plane functions. These functions may be executed on separate processors to support scale and resiliency, but they are implemented on a common hardware platform. As these functions move to a cloud model, a full redesign is possible. As long as the control plane and data plane reside on the same platform, it will likely remain a multitenant function. It is easy to think we could turn up a separate PE router instance for each customer, but the control plane would be difficult to scale if we had thousands of PE routers. If the control and data plane are disaggregated, we could con- sider single-tenant PE instances for the data plane that are customer specific and located close to the customer, yet the control plane could be multitenant and centralized scaled separately. Taking a step further, the data plane could even be distributed across many single-tenant serv