Just adding openstack-dev to the CC for now :). ----- Original Message ----- > From: "ITAI MENDELSOHN (ITAI)" <[email protected]> > 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" <[email protected]> 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 <[email protected]> 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> [email protected] > >> 07:18 < russellb> and we'll have something more specific to poke holes > >>in and > >> discuss > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
