Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
More than happy to help out, I think we are on a good path by focusing on the current BP's we have. I will not make it to IRC meeting today, but will comment afterwords. I think Adrian also pointed out one other point just to put on the table so we set the tone and scope accordingly, that is some of these BP's while being NFV related and not NFV essential but also benefit the generic cases too imho. For example the port-mirroring is in some cases a feature "some NFV services" would utilise" (lots of strange stuff in the wild :-) ) this and others would never need this. Alan -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: June-11-14 6:54 AM To: Alan Kavanagh Cc: OpenStack Development Mailing List (not for usage questions); ITAI MENDELSOHN (ITAI); Chris Wright; Stephen Wong; Nicolas Lemieux Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context - Original Message - > From: "Alan Kavanagh" > To: "OpenStack Development Mailing List (not for usage questions)" > , "Steve > > Hi Adrian et.al > > Adrian thanks for taking a stab at this, I think the use case list is > a little long but good to put on the map. One item I would point out > is that its fairly difficult and perhaps misleading to map the > blueprints list to the ETSI NFV use case, for example you can argue > that based on configuration and deployment of say vCPE some may require VLAN > Trunking, others will not. > Similarly for SR-IOV support when you a Transport node that consumes > the total CPU and NIC available on the host and would in some cases be > provisioned on bare metal SR-IOV is not a required feature set. Also > some of these would not require anything in addition to support apart > from what we already have in Openstack, for example in the case of CDN > do we needed additional feature sets, imho apart from the nice state > aware scheduling and VM allocation based on specific attributes > required (specific PCI device type, topology based placement, on board > SSD, etc) and IP end point for delivery, do we need anything else beyond > this? > > Perhaps what might be more beneficial is to ensure we can deploy a > given app in the current OS distro and identify the necessary > configuration attributes we would need to expose, would that be a good > way forward? Interested to hear from others on this front. A > suggestion, is we start with use cases 2 and 7 that are more well > defined and simpler to address and this is where I believe Itai had a > good statement of “not boiling the ocean”, lets start with some simple > ones that are well defined and well known and don’t have too many intrinsic > configurations. > > /Alan Yes, thanks all - it's great to see plenty of people putting forward their thoughts on this :). I agree that it is somewhat problematic to map the ETSI NFV use cases "as is" directly to the list of blueprints, finding an appropriate way to distil them into the hard requirements of the most minimal configurations of each is key. I definitely agree concentrating on doing this for a subset of them that are particularly well defined first is the best way to start off without spreading our efforts too thinly. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
- Original Message - > From: "Alan Kavanagh" > To: "OpenStack Development Mailing List (not for usage questions)" > , "Steve > > Hi Adrian et.al > > Adrian thanks for taking a stab at this, I think the use case list is a > little long but good to put on the map. One item I would point out is that > its fairly difficult and perhaps misleading to map the blueprints list to > the ETSI NFV use case, for example you can argue that based on configuration > and deployment of say vCPE some may require VLAN Trunking, others will not. > Similarly for SR-IOV support when you a Transport node that consumes the > total CPU and NIC available on the host and would in some cases be > provisioned on bare metal SR-IOV is not a required feature set. Also some of > these would not require anything in addition to support apart from what we > already have in Openstack, for example in the case of CDN do we needed > additional feature sets, imho apart from the nice state aware scheduling and > VM allocation based on specific attributes required (specific PCI device > type, topology based placement, on board SSD, etc) and IP end point for > delivery, do we need anything else beyond this? > > Perhaps what might be more beneficial is to ensure we can deploy a given app > in the current OS distro and identify the necessary configuration attributes > we would need to expose, would that be a good way forward? Interested to > hear from others on this front. A suggestion, is we start with use cases 2 > and 7 that are more well defined and simpler to address and this is where I > believe Itai had a good statement of “not boiling the ocean”, lets start > with some simple ones that are well defined and well known and don’t have > too many intrinsic configurations. > > /Alan Yes, thanks all - it's great to see plenty of people putting forward their thoughts on this :). I agree that it is somewhat problematic to map the ETSI NFV use cases "as is" directly to the list of blueprints, finding an appropriate way to distil them into the hard requirements of the most minimal configurations of each is key. I definitely agree concentrating on doing this for a subset of them that are particularly well defined first is the best way to start off without spreading our efforts too thinly. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
- Original Message - > From: "Steve Gordon" > To: "Stephen Wong" > > - Original Message - > > From: "Stephen Wong" > > To: "ITAI MENDELSOHN (ITAI)" , > > "OpenStack Development Mailing List (not for usage > > questions)" > > > > Hi, > > > > Perhaps I have missed it somewhere in the email thread? Where is the > > use case => bp document we are supposed to do for this week? Has it been > > created yet? > > > > Thanks, > > - Stephen > > Hi, > > Itai is referring to the ETSI NFV use cases document [1] and the discussion > is around how we distill those - or a subset of them - into a more > consumable format for an OpenStack audience on the Wiki. At this point I > think the best approach is to simply start entering one of them (perhaps #5) > into the Wiki and go from there. Ideally this would form a basis for > discussing the format etc. > > Thanks, > > Steve > > [1] > http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf To try and kick start things I have created a table on the wiki [1] based on the *DRAFT* NFV Performance & Portability Best Practises document [2]. This really lists workload types rather than specific applications, although I've put in an examples column we can populate with them. I find it a useful way to quickly break down some of the characteristics of NFV applications at a glance. What do people think of this as something to start with? Remember, it's a wiki! So anyone is welcome to either expand the table or start adding more concrete user stories (e.g. around ETSI NFV use case number 5 that Itai and I have been referring to, or any other VNF for that matter) in this section (we may/want need to create a separate page but for now it seems OK to get started here). Thanks, Steve [1] https://wiki.openstack.org/wiki/Meetings/NFV#Use_Cases [2] http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20&%20Portability%20Best%20Practises.pdf ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
#5 is a good reference point for the type of apps we can encounter in NFV. I guess it's a good idea to start with it. Itai Sent from my iPhone > On Jun 10, 2014, at 7:16 PM, "Steve Gordon" wrote: > > - Original Message - >> From: "Stephen Wong" >> To: "ITAI MENDELSOHN (ITAI)" , >> "OpenStack Development Mailing List (not for usage >> questions)" >> >> Hi, >> >>Perhaps I have missed it somewhere in the email thread? Where is the >> use case => bp document we are supposed to do for this week? Has it been >> created yet? >> >> Thanks, >> - Stephen > > Hi, > > Itai is referring to the ETSI NFV use cases document [1] and the discussion > is around how we distill those - or a subset of them - into a more consumable > format for an OpenStack audience on the Wiki. At this point I think the best > approach is to simply start entering one of them (perhaps #5) into the Wiki > and go from there. Ideally this would form a basis for discussing the format > etc. > > Thanks, > > Steve > > [1] > http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf > >> On Tue, Jun 10, 2014 at 2:00 AM, MENDELSOHN, ITAI (ITAI) < >> itai.mendels...@alcatel-lucent.com> wrote: >> >>> Shall we continue this discussion? >>> >>> Itai >>> On 6/9/14 8:54 PM, "Steve Gordon" wrote: - Original Message - > From: "Steve Gordon" > To: "ITAI MENDELSOHN (ITAI)" , > "OpenStack Development Mailing List (not for usage > > Just adding openstack-dev to the CC for now :). > > - Original Message - >> From: "ITAI MENDELSOHN (ITAI)" >> 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 > > -- > Steve Gordon, RHCE > Product Manager, Red Hat Enterprise Linux OpenStack Platform > Red Hat Canada (Toronto, Ontario)
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
- Original Message - > From: "Stephen Wong" > To: "ITAI MENDELSOHN (ITAI)" , "OpenStack > Development Mailing List (not for usage > questions)" > > Hi, > > Perhaps I have missed it somewhere in the email thread? Where is the > use case => bp document we are supposed to do for this week? Has it been > created yet? > > Thanks, > - Stephen Hi, Itai is referring to the ETSI NFV use cases document [1] and the discussion is around how we distill those - or a subset of them - into a more consumable format for an OpenStack audience on the Wiki. At this point I think the best approach is to simply start entering one of them (perhaps #5) into the Wiki and go from there. Ideally this would form a basis for discussing the format etc. Thanks, Steve [1] http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf > On Tue, Jun 10, 2014 at 2:00 AM, MENDELSOHN, ITAI (ITAI) < > itai.mendels...@alcatel-lucent.com> wrote: > > > Shall we continue this discussion? > > > > Itai > > > > On 6/9/14 8:54 PM, "Steve Gordon" wrote: > > > > >- Original Message - > > >> From: "Steve Gordon" > > >> To: "ITAI MENDELSOHN (ITAI)" , > > >>"OpenStack Development Mailing List (not for usage > > >> > > >> Just adding openstack-dev to the CC for now :). > > >> > > >> - Original Message - > > >> > From: "ITAI MENDELSOHN (ITAI)" > > >> > 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 > > > > > > > > > > > -- Steve Gordon, RHCE Product Manager, Red Hat Enterprise Linux OpenStack Platform Red Hat Canada (Toronto, Ontario) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
Shall we continue this discussion? Itai On 6/9/14 8:54 PM, "Steve Gordon" wrote: >- Original Message - >> From: "Steve Gordon" >> To: "ITAI MENDELSOHN (ITAI)" , >>"OpenStack Development Mailing List (not for usage >> >> Just adding openstack-dev to the CC for now :). >> >> - Original Message - >> > From: "ITAI MENDELSOHN (ITAI)" >> > 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
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
- Original Message - > From: "Steve Gordon" > To: "ITAI MENDELSOHN (ITAI)" , "OpenStack > Development Mailing List (not for usage > > Just adding openstack-dev to the CC for now :). > > - Original Message - > > From: "ITAI MENDELSOHN (ITAI)" > > 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
[openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
Just adding openstack-dev to the CC for now :). - Original Message - > From: "ITAI MENDELSOHN (ITAI)" > 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" 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 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
