Shall we continue this discussion? Itai
On 6/9/14 8:54 PM, "Steve Gordon" <sgor...@redhat.com> wrote: >----- Original Message ----- >> From: "Steve Gordon" <sgor...@redhat.com> >> To: "ITAI MENDELSOHN (ITAI)" <itai.mendels...@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.mendels...@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 > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev