Open Stack

Shall we continue this discussion?

Itai

On 6/9/14 8:54 PM, "Steve Gordon" <sgordon at redhat.com> wrote:

>----- 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
>
>