Open Stack

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?
> 
> Itai
> 
> 
> On 6/5/14 8:20 AM, "Nicolas Lemieux" <nlemieux at redhat.com> wrote:
> 
> >At high-level I propose to split things up while looking at the use cases
> >and at a minimum address requirements for compute node (NFVI/hypervisor)
> >to some extend decoupled from the controller/scheduler (VIM). This should
> >simplify mapping to the ETSI ISG as well as provide better insertion
> >points for the vendor eco-system.
> >
> >Nic
> >
> >> On Jun 5, 2014, at 0:08, Chris Wright <chrisw at sous-sol.org> wrote:
> >> 
> >> labelled as the tl;dr version of nfv context for OpenStack developers
> >> 
> >> ETSI use case doc:
> >>http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001
> >>v010101p.pdf
> >> 
> >> I think goal is to get some translation from these high level type of
> >>use cases
> >> into context for the existing blueprints:
> >> 
> >> https://wiki.openstack.org/wiki/Meetings/NFV#Active_Blueprints
> >> 
> >> Tried to capture the relevant thread on IRC here:
> >> 
> >> 07:13 < sgordon> but we should collaborate when it comes to terminology
> >>and use
> >>                 cases
> >> 07:13 < sgordon> if it makes sense
> >> 
> >> 07:13 < russellb> #topic use cases
> >> 07:13 < sgordon> rather than independently creating two etsi ->
> >>openstack
> >>                 glossaries for example
> >> 07:13 < russellb> we've done a nice job early on with gathering a big
> >>list of
> >>                  blueprints
> >> -
> >> 07:13 < russellb> i think one big work area for us is the use cases and
> >>                  terminology translation for openstack
> >> -
> >> 07:14 < sgordon> right, and the question there is do we want to target
> >>specific
> >>                 VNFs or more generally translate the ETSI NFV use cases
> >> 07:14 < russellb> what would we like to accomplish in this area?
> >> 07:14 < sgordon> in a way it's, how do we define success
> >> 07:14 < imendel> I thought we want to drive requirements. The ETSI use
> >>cases
> >>                 are far too high level
> >> -
> >> 07:14 < russellb> from an openstack developer perspective, I feel like
> >>we need
> >>                  a "tl;dr" of why this stuff is important
> >> -
> >> 07:15 < sgordon> imendel, agree
> >> 07:15 < sgordon> imendel, i am just trying to get a feel for how we get
> >>to
> >>                 something more specific
> >> 07:15 < imendel> i gree, we need somthing specifc
> >> 07:15 < cdub> russellb: should we aim to have that for next week?
> >> 07:15 < adrian-hoban> OpenStack fits _mostly_ in what ETSI-NFV describe
> >>as a
> >>                      Virtualisation Infrastructure Manager (VIM)
> >> -
> >> 07:15 < russellb> it would be nice to have something, even brief,
> >>written up
> >>                  that ties blueprints to the "why"
> >> -
> >> 07:15 < nijaba> ijw:  would be happy to work with you on writing about
> >>this
> >> 07:15 < russellb> cdub: yeah
> >> 07:16 < russellb> maybe a few people can go off and start a first cut
> >>at
> >>                  something?
> >> 07:16 < cdub> russellb: ok, i'll help with that
> >> 07:16 < nijaba> russellb: volunteering
> >> 07:16 < adrian-hoban> russellb: Are you looking for a terminology
> >>translation
> >>                      or use cases?
> >> 07:16 < russellb> ok great, who wants to coordinate it?
> >> 07:17 < russellb> mainly use cases that the blueprints can be tied to,
> >>                  personally
> >> 07:17 < ijw> Certainly we should draw the mapping diagram, if nothing
> >>else;
> >>             it's always the first thing people want to see
> >> 07:17 < sgordon> so far ijw, cdub, nijaba
> >> 07:17 < sgordon> i am happy to assist as well
> >> 07:17 < s3wong> adrian-hoban: I think russellb was talking about why
> >>the listed
> >>                blueprints are relevant to NFV according to use cases
> >> 07:17 < russellb> cdub: OK, want to coordinate it?
> >> 07:17 < cdub> russellb: sure
> >> 07:18 < russellb> #note cdub to coordinate a first pass on starting
> >>some
> >>                  openstack use case documentation, contact him if you'd
> >>like
> >>                  to help
> >> 07:18 < adrian-hoban> I will help too
> >> 07:18 < Sam-I-Am> i'd also like to help
> >> 07:18 < russellb> OK, let's come back to this next week and review what
> >>you
> >>                  guys come up with :)
> >> 07:18 < s3wong> cdub: how can we contact you?
> >> 07:18 < cdub> chrisw at sous-sol.org
> >> 07:18 < russellb> and we'll have something more specific to poke holes
> >>in and
> >>                  discuss
> 
>