Hello all I took the action on last week's call to explain why the VLAN trunking to VM bp is a relevant use case for NFV - here's my take.
The big picture is that this is about how service providers can use virtualisation to provide differentiated network services to their customers (and specifically enterprise customers rather than end users); it's not about VMs want to set up networking between themselves. A typical service provider may be providing network services to thousands or more of enterprise customers. The details of and configuration required for individual services will differ from customer to customer. For example, consider a Session Border Control service (basically, policing VoIP interconnect): different customers will have different sets of SIP trunks that they can connect to, different traffic shaping requirements, different transcoding rules etc. Those customers will normally connect in to the service provider in one of two ways: a dedicated physical link, or through a VPN over the public Internet. Once that traffic reaches the edge of the SP's network, then it makes sense for the SP to put all that traffic onto the same core network while keeping some form of separation to allow the network services to identify the source of the traffic and treat it independently. There are various overlay techniques that can be used (e.g. VXLAN, GRE tunnelling) but one common and simple one is VLANs. Carrying VLAN trunking into the VM allows this scheme to continue to be used in a virtual world. In this set-up, then any VMs implementing those services have to be able to differentiate between customers. About the only way of doing that today in OpenStack is to configure one provider network per customer then have one vNIC per provider network, but that approach clearly doesn't scale (both performance and configuration effort) if a VM has to see traffic from hundreds or thousands of customers. Instead, carrying VLAN trunking into the VM allows them to do this scalably. The net is that a VM providing a service that needs to have access to a customer's non-NATed source addresses needs an overlay technology to allow this, and VLAN trunking into the VM is sufficiently scalable for this use case and leverages a common approach. Calum Calum Loudon Director, Architecture +44 (0)208 366 1177 METASWITCH NETWORKS THE BRAINS OF THE NEW GLOBAL NETWORK www.metaswitch.com _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev