Open Stack

----- Original Message -----
> From: "Steve Gordon" <sgordon at redhat.com>
> To: "ITAI MENDELSOHN (ITAI)" <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>
> > 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