[openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
Alan Kavanagh
alan.kavanagh at ericsson.com
Wed Jun 11 11:24:26 UTC 2014
Hi Adrian
Thanks for the useful input, I think we are all aligning now and hopefully agreeing on how best to move forward here, it’s a tricky area but I think we can progress this. Would agree with your SR-IOV explanation and this is another variant to take on board.
I can not make it for today’s meeting but will follow up afterwords.
/Alan
From: Hoban, Adrian [mailto:adrian.hoban at intel.com]
Sent: June-11-14 7:10 AM
To: OpenStack Development Mailing List (not for usage questions); Steve Gordon; ITAI MENDELSOHN (ITAI); Chris Wright; Stephen Wong; Nicolas Lemieux
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
Hi Alan,
After completing the first pass of this I agree that the results could be misinterpreted. As you correctly point out, most of the network functions that are being looking at will be developed and deployed leveraging a range of configuration options and taking into account considerations such as performance and topology for that class of device. I reviewed the list primarily thinking about some gaps that the blueprints may be closing relating to higher performing VM based solutions. The implementations can be so very varied, so even in the bare metal case you mention, SR-IOV can offer some additional benefits to the workloads that some implementations may choose to leverage.
I also agree that we need to focus in on a couple of sample applications and prioritise what needs to be done based on a more detailed review of the requirements.
Regards,
Adrian
From: Alan Kavanagh [mailto:alan.kavanagh at ericsson.com]
Sent: Wednesday, June 11, 2014 4:32 AM
To: OpenStack Development Mailing List (not for usage questions); Steve Gordon; ITAI MENDELSOHN (ITAI); Chris Wright; Stephen Wong; Nicolas Lemieux
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
Hi Adrian et.al
Adrian thanks for taking a stab at this, I think the use case list is a little long but good to put on the map. One item I would point out is that its fairly difficult and perhaps misleading to map the blueprints list to the ETSI NFV use case, for example you can argue that based on configuration and deployment of say vCPE some may require VLAN Trunking, others will not. Similarly for SR-IOV support when you a Transport node that consumes the total CPU and NIC available on the host and would in some cases be provisioned on bare metal SR-IOV is not a required feature set. Also some of these would not require anything in addition to support apart from what we already have in Openstack, for example in the case of CDN do we needed additional feature sets, imho apart from the nice state aware scheduling and VM allocation based on specific attributes required (specific PCI device type, topology based placement, on board SSD, etc) and IP end point for delivery, do we need anything else beyond this?
Perhaps what might be more beneficial is to ensure we can deploy a given app in the current OS distro and identify the necessary configuration attributes we would need to expose, would that be a good way forward? Interested to hear from others on this front. A suggestion, is we start with use cases 2 and 7 that are more well defined and simpler to address and this is where I believe Itai had a good statement of “not boiling the ocean”, lets start with some simple ones that are well defined and well known and don’t have too many intrinsic configurations.
/Alan
From: Hoban, Adrian [mailto:adrian.hoban at intel.com]
Sent: June-10-14 10:20 PM
To: Steve Gordon; ITAI MENDELSOHN (ITAI); Chris Wright; Stephen Wong; Nicolas Lemieux
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
Hi Folks,
I'd like to propose the following text for the NFV wiki giving a high level intro to the ETSI-NFV use cases. It builds on the info Itai and Steve posted below.
Reference: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf
Use Case #1: Network Functions Virtualisation Infrastructure as a Service
- This is a reasonably generic IaaS requirement.
Use Case #2: Virtual Network Function as a Service (VNFaaS).
- This primarily targets Customer Premise Equipment (CPE) devices such as access routers, enterprise firewall, WAN optimizers etc. with some Provider Edge devices possible at a later date. ETSI-NFV Performance & portability considerations will apply to deployments that strive to meet high performance and low latency considerations.
Use Case #3: Virtual Network Platform as a Service (VNPaaS).
- This is similar to #2 but at the service level. At larger scale and not at the "app" level only.
Use Case #4: VNF Forwarding Graphs
- Dynamic connectivity between apps in a "service chain".
Use Case #5: Virtualisation of Mobile Core Network and IMS.
- Primarily focusing on Evolved Packet Core appliances such as the Mobility Management Entity (MME), Serving Gateway (S-GW), etc. and the IP Multimedia Subsystem (IMS).
Use Case #6: Virtualisation of Mobile base station
- Focusing on parts of the Radio Access Network such as eNodeB's, Radio Link Control and Packet Data Convergence Protocol, etc..
Use Case #7: Virtualisation of the Home Environment.
- Similar to #2, but with a focus on virtualising residential devices instead of enterprise devices. Covers DHCP, NAT, PPPoE, Firewall devices, etc.
Use Case #8: Virtualisation of CDNs
- Content Delivery Networks focusing on video traffic delivery.
Use Case #9: Fixed Access Network Functions Virtualisation
- Wireline related access technologies.
========
For the ETSI-NFV use case to OpenStack blueprint mapping, I would also like to propose that we add a column to the blueprints. I've taken a first stab at this.
Description
NFV Use Case Comments
Support two interfaces from one VM attached to the same network
#1 is a broadly applicable IaaS requirement.
#2 TBD?
#3 TBD?
#4 TBD?
#5 TBD?
#6 TBD?
#7 TBD?
#8 TBD?
#9 TBD?
VLAN trunking networks for NFV
#1 is a broadly applicable IaaS requirement.
#2 TBD?
#3 TBD?
#4 TBD?
#5 TBD?
#6 TBD?
#7 TBD?
#8 TBD?
#9 TBD?
Permit unaddressed interfaces for NFV use cases
#1 is a broadly applicable IaaS requirement.
#2 TBD?
#3 TBD?
#4 TBD?
#5 TBD?
#6 TBD?
#7 TBD?
#8 TBD?
#9 TBD?
SR-IOV Networking Support
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 _Potential_ intersect if forwarding graph makes any particular request about the port connectivity.
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 TBD?
#9 Needed for performance reasons.
Support for NUMA and VCPU topology configuration
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
Virt driver guest vCPU topology configuration
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
Virt driver guest NUMA node placement & topology
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
Virt driver large page allocation for guest RAM *
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
Virt driver pinning guest vCPUs to host pCPUs
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
I/O (PCIe) Based NUMA Scheduling
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
Soft affinity support for server groups
#1 is a broadly applicable IaaS requirement.
#2 TBD?
#3 TBD?
#4 TBD?
#5 TBD?
#6 TBD?
#7 TBD?
#8 TBD?
#9 TBD?
Open vSwitch-based Security Groups: Open vSwitch Implementation of FirewallDriver
#1 is a broadly applicable IaaS requirement.
#2 Needed in the non-SR-IOV based deployments.
#3 TBD?
#4 vSwitch configuration may be needed to complete the forwarding graph (service chain).
#5 Needed in the non-SR-IOV based deployments.
#6 TBD?
#7 Needed in the non-SR-IOV based deployments.
#8 TBD?
#9 Needed in the non-SR-IOV based deployments.
Framework for Advanced Services in Virtual Machines
#1 is a broadly applicable IaaS requirement.
#2 Potential lifecycle management support
#3 TBD?
#4 TBD?
#5 Potential lifecycle management support
#6 Potential lifecycle management support
#7 Potential lifecycle management support
#8 Potential lifecycle management support
#9 Potential lifecycle management support
Neutron Services Insertion, Chaining, and Steering
#1 is a broadly applicable IaaS requirement.
#2 May need to chain multiple functions to deliver a service.
#3 TBD?
#4 Closely coupled requirement needed to deliver on a forwarding graph.
#5 May need to chain multiple functions to deliver a service.
#6 May need to chain multiple functions to deliver a service.
#7 May need to chain multiple functions to deliver a service.
#8 May need to chain multiple functions to deliver a service.
#9 May need to chain multiple functions to deliver a service.
Schedule vms per flavour cpu overcommit
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
OVF Meta-Data Import via Glance
#1 is a broadly applicable IaaS requirement.
#2 Needed as one optional path to auto import platform feature requests to meet performance targets.
#3 TBD?
#4 TBD?
#5 Needed as one optional path to auto import platform feature requests to meet performance targets.
#6 Needed as one optional path to auto import platform feature requests to meet performance targets.
#7 Needed as one optional path to auto import platform feature requests to meet performance targets.
#8 Needed as one optional path to auto import platform feature requests to meet performance targets.
#9Needed as one optional path to auto import platform feature requests to meet performance targets.
Open vSwitch to use patch ports in place of veth pairs for vlan n/w
#1 is a broadly applicable IaaS requirement.
#2 Needed in the non-SR-IOV based deployments.
#3 TBD?
#4 Closely coupled requirement needed to deliver on a forwarding graph.
#5 Needed in the non-SR-IOV based deployments.
#6 TBD?
#7 Needed in the non-SR-IOV based deployments.
#8 TBD?
#9 Needed in the non-SR-IOV based deployments.
Libvirt hugepage backed memory support
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons.
#3 TBD?
#4 Closely coupled requirement needed to deliver on a forwarding graph.
#5 Needed for performance reasons.
#6 Needed for performance reasons.
#7 Needed for performance reasons.
#8 Needed for performance reasons.
#9 Needed for performance reasons.
Support userspace vhost in ovs vif bindings
#1 is a broadly applicable IaaS requirement.
#2 Needed in the non-SR-IOV based deployments.
#3 TBD?
#4 Closely coupled requirement needed to deliver on a forwarding graph.
#5 Needed in the non-SR-IOV based deployments.
#6 TBD?
#7 Needed in the non-SR-IOV based deployments.
#8 TBD?
#9 Needed in the non-SR-IOV based deployments.
NIC state aware scheduling
#1 is a broadly applicable IaaS requirement.
#2 Needed to help with service delivery
#3 TBD?
#4 Need to understand if the ports are up when deploying the service chain.
#5 Needed to help with service delivery
#6 Needed to help with service delivery
#7 Needed to help with service delivery
#8 Needed to help with service delivery
#9 Needed to help with service delivery
Add PCI and PCIe device capability aware scheduling
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons
#3 TBD?
#4 TBD?
#5 Needed for performance reasons
#6 Needed for performance reasons
#7 Needed for performance reasons
#8 Needed for performance reasons
#9 Needed for performance reasons
Snabb NFVmechanism driver
#1 is a broadly applicable IaaS requirement.
#2 Needed in the non-SR-IOV based deployments.
#3 TBD?
#4 TBD?
#5 Needed in the non-SR-IOV based deployments.
#6 TBD?
#7 Needed in the non-SR-IOV based deployments.
#8 TBD?
#9 Needed in the non-SR-IOV based deployments.
VIF_SNABB (qemu vhost-user) support
#1 is a broadly applicable IaaS requirement.
#2 Needed in the non-SR-IOV based deployments.
#3 TBD?
#4 TBD?
#5 Needed in the non-SR-IOV based deployments.
#6 TBD?
#7 Needed in the non-SR-IOV based deployments.
#8 TBD?
#9 Needed in the non-SR-IOV based deployments.
Solver Scheduler - complex constraints scheduler with NFV use cases
#1 is a broadly applicable IaaS requirement.
#2 Possibly needed for smarter scheduling decision making to help with performance.
#3 TBD?
#4 TBD?
#5 Possibly needed for smarter scheduling decision making to help with performance.
#6 Possibly needed for smarter scheduling decision making to help with performance.
#7 Possibly needed for smarter scheduling decision making to help with performance.
#8 Possibly needed for smarter scheduling decision making to help with performance.
#9 Possibly needed for smarter scheduling decision making to help with performance.
Discless VM
#1 is a broadly applicable IaaS requirement.
#2 TBD?
#3 TBD?
#4 TBD?
#5 TBD?
#6 TBD?
#7 TBD?
#8 TBD?
#9 TBD?
Network QoS API
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons
#3 TBD?
#4 Needed to capture network QoS aspects of forwarding graph.
#5 Needed for performance reasons
#6 Needed for performance reasons
#7 Needed for performance reasons
#8 Needed for performance reasons
#9 Needed for performance reasons
Persist scheduler hints
#1 is a broadly applicable IaaS requirement.
#2 Needed for performance reasons on migration.
#3 TBD?
#4 TBD?
#5 Needed for performance reasons on migration.
#6 Needed for performance reasons on migration.
#7 Needed for performance reasons on migration.
#8 Needed for performance reasons on migration.
#9 Needed for performance reasons on migration.
Port mirroring
#1 is a broadly applicable IaaS requirement.
#2 Needed for some specialized use cases.
#3 TBD?
#4 Needed based on forwarding graph for specialized use cases.
#5 Needed for some specialized use cases.
#6 Needed for some specialized use cases.
#7 Needed for some specialized use cases.
#8 TBD?
#9 Needed for some specialized use cases.
Traffic Steering Abstraction
#1 is a broadly applicable IaaS requirement.
#2 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
#3 TBD?
#4 Closely coupled requirement needed to deliver on a forwarding graph.
#5 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
#6 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
#7 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
#8 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
#9 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
Let’s discuss in our meeting tomorrow.
Regards,
Adrian
-----Original Message-----
From: Steve Gordon [mailto:sgordon at redhat.com]
Sent: Tuesday, June 10, 2014 5:15 PM
To: Stephen Wong
Cc: ITAI MENDELSOHN (ITAI); OpenStack Development Mailing List (not for usage questions); Nicolas Lemieux; Chris Wright; NICOLAS LEMIEUX; Hoban, Adrian
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
----- Original Message -----
> From: "Stephen Wong" <stephen.kf.wong at gmail.com<mailto:stephen.kf.wong at gmail.com>>
> To: "ITAI MENDELSOHN (ITAI)" <itai.mendelsohn at alcatel-lucent.com<mailto:itai.mendelsohn at alcatel-lucent.com>>,
> "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>
> Hi,
>
> Perhaps I have missed it somewhere in the email thread? Where is
> the use case => bp document we are supposed to do for this week? Has
> it been created yet?
>
> Thanks,
> - Stephen
Hi,
Itai is referring to the ETSI NFV use cases document [1] and the discussion is around how we distill those - or a subset of them - into a more consumable format for an OpenStack audience on the Wiki. At this point I think the best approach is to simply start entering one of them (perhaps #5) into the Wiki and go from there. Ideally this would form a basis for discussing the format etc.
Thanks,
Steve
[1] http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf
> On Tue, Jun 10, 2014 at 2:00 AM, MENDELSOHN, ITAI (ITAI) <
> itai.mendelsohn at alcatel-lucent.com<mailto:itai.mendelsohn at alcatel-lucent.com>> wrote:
>
> > Shall we continue this discussion?
> >
> > Itai
> >
> > On 6/9/14 8:54 PM, "Steve Gordon" <sgordon at redhat.com<mailto:sgordon at redhat.com>> wrote:
> >
> > >----- Original Message -----
> > >> From: "Steve Gordon" <sgordon at redhat.com<mailto:sgordon at redhat.com>>
> > >> To: "ITAI MENDELSOHN (ITAI)"
> > >><itai.mendelsohn at alcatel-lucent.com<mailto:itai.mendelsohn at alcatel-lucent.com>>,
> > >>"OpenStack Development Mailing List (not for usage
> > >>
> > >> Just adding openstack-dev to the CC for now :).
> > >>
> > >> ----- Original Message -----
> > >> > From: "ITAI MENDELSOHN (ITAI)"
> > >> > <itai.mendelsohn at alcatel-lucent.com<mailto:itai.mendelsohn at alcatel-lucent.com>>
> > >> > Subject: Re: NFV in OpenStack use cases and context
> > >> >
> > >> > Can we look at them one by one?
> > >> >
> > >> > Use case 1 - It's pure IaaS
> > >> > Use case 2 - Virtual network function as a service. It's
> > >> > actually
> > >>about
> > >> > exposing services to end customers (enterprises) by the service
> > >>provider.
> > >> > Use case 3 - VNPaaS - is similar to #2 but at the service
> > >> > level. At
> > >>larger
> > >> > scale and not at the "app" level only.
> > >> > Use case 4 - VNF forwarding graphs. It's actually about dynamic
> > >> > connectivity between apps.
> > >> > Use case 5 - vEPC and vIMS - Those are very specific (good)
> > >> > examples
> > >>of SP
> > >> > services to be deployed.
> > >> > Use case 6 - virtual mobile base station. Another very specific
> > >>example,
> > >> > with different characteristics than the other two above.
> > >> > Use case 7 - Home virtualisation.
> > >> > Use case 8 - Virtual CDN
> > >> >
> > >> > As I see it those have totally different relevancy to OpenStack.
> > >> > Assuming we don't want to boil the ocean hereŠ
> > >> >
> > >> > 1-3 seems to me less relevant here.
> > >> > 4 seems to be a Neutron area.
> > >> > 5-8 seems to be usefully to understand the needs of the NFV
> > >> > apps. The
> > >>use
> > >> > case can help to map those needs.
> > >> >
> > >> > For 4 I guess the main part is about chaining and Neutron between DCs.
> > >> > Soma may call it SDN in WAN...
> > >> >
> > >> > For 5-8 at the end an option is to map all those into:
> > >> > -performance (net BW, storage BW mainly). That can be mapped to
> > >>SR-IOV,
> > >> > NUMA. Etc'
> > >> > -determinism. Shall we especially minimise "noisy" neighbours.
> > >> > Not
> > >>sure
> > >> > how NFV is special here, but for sure it's a major concern for
> > >> > lot of
> > >>SPs.
> > >> > That can be mapped to huge pages, cache QOS, etc'.
> > >> > -overcoming of short term hurdles (just because of apps
> > >> > migrations issues). Small example is the need to define the
> > >> > tick policy of KVM
> > >>just
> > >> > because that's what the app needs. Again, not sure how NFV
> > >> > special it
> > >>is,
> > >> > and again a major concern of mainly application owners in the
> > >> > NFV
> > >>domain.
> > >> >
> > >> > Make sense?
> > >
> > >Hi Itai,
> > >
> > >This makes sense to me. I think what we need to expand upon, with
> > >the ETSI NFV documents as a reference, is a two to three paragraph
> > >explanation of each use case explained at a more basic level -
> > >ideally on the Wiki page. It seems that use case 5 might make a
> > >particularly good initial target to work on fleshing out as an
> > >example? We could then look at linking the use case to concrete
> > >requirements based on this, I suspect we might want to break them down into:
> > >
> > >a) The bare minimum requirements for OpenStack to support the use
> > >case at all. That is, requirements that without which the VNF
> > >simply can not function.
> > >
> > >b) The requirements that are not mandatory but would be beneficial
> > >for OpenStack to support the use case. In particularly that might
> > >be requirements that would improve VNF performance or reliability
> > >by some margin (possibly significantly) but which it can function
> > >without if absolutely required.
> > >
> > >Thoughts?
> > >
> > >Steve
> > >
> > >
> >
> >
>
--
Steve Gordon, RHCE
Product Manager, Red Hat Enterprise Linux OpenStack Platform Red Hat Canada (Toronto, Ontario)
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/36a7fd22/attachment.html>
More information about the OpenStack-dev
mailing list