15:01:46 <serverascode> #startmeeting operators_telco_nfv
15:01:47 <openstack> Meeting started Wed Nov 30 15:01:46 2016 UTC and is due to finish in 60 minutes.  The chair is serverascode. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:51 <openstack> The meeting name has been set to 'operators_telco_nfv'
15:02:03 <serverascode> #topic roll call
15:02:07 <ad_rien_> o/
15:02:11 <ad_rien_> hi all
15:02:17 <serverascode> hi ad_rien_
15:02:32 <GeraldK> hi
15:02:38 <GeraldK> btw, what does "o/" mean?
15:03:06 <serverascode> it's meant to be like a person putting their hand up
15:03:15 <serverascode> saying "I'm here" :)
15:03:50 <GeraldK> serverascode: yes, I saw it was used in this context. thanks for the explanation of "hands up"
15:04:31 <serverascode> anyone else here for the ops telecom/nfv meeting or just us three?
15:05:07 <GeraldK> some public holiday today in some countries?!?
15:05:08 <serverascode> ok so far just the three of us :)
15:05:18 <serverascode> I know one person said they were not able to make it today
15:05:23 <ad_rien_> I didn't see your email
15:05:35 <ad_rien_> BTW serverascode so maybe this can explain that
15:06:25 <serverascode> ad_rien_ yes good point. I have only been emailing the openstack-operators list, I think perhaps I should gather everyone's email to sent out notices
15:07:01 <serverascode> #link http://lists.openstack.org/pipermail/openstack-operators/2016-November/012213.html
15:07:52 <ad_rien_> serverascode:  thanks for the link
15:08:41 <serverascode> #action serverascode to put a contact section in the agenda etherpad
15:08:54 <serverascode> I think I will gather contact emails and send out to more than just the ops list
15:09:21 <serverascode> ok, so otherwise, the only thing I had on the agenda was continuing our conversation on NFVi/multi-site etc
15:09:33 <serverascode> anyone have anything else to add to the agenda?
15:10:01 <serverascode> if so just go ahead and add it
15:10:14 <serverascode> #link https://etherpad.openstack.org/p/ops-telco-nfv-meeting-agenda
15:10:30 <serverascode> #topic mid to long term project around NFVi
15:11:06 <serverascode> so last meeting we had a good discussion about NFVi and also we tried to figure out if multi-site/region/cloud was also part of that
15:11:32 <serverascode> I noticed that OPNFV has a multi-site project
15:11:34 <serverascode> #link https://wiki.opnfv.org/display/multisite/Multisite+Deployment+Environment
15:11:56 <serverascode> anyone have any further thoughts on that?
15:12:13 <jamemcc> Hi - Jamey McCabe here now also.
15:12:17 <serverascode> if we do think that multi-site is important to us, then it might make sense to work with that OPNFV project
15:12:28 <serverascode> hi jamecc :)
15:12:58 * ad_rien_ is giving a look to the OPNFV link
15:13:09 <serverascode> there is also some kind of related project called kingbird
15:13:11 <serverascode> #link https://wiki.openstack.org/wiki/Kingbird
15:13:30 <serverascode> not sure how that relates to multi-site or the tricircle project...
15:13:37 <ad_rien_> yyes
15:14:42 <ad_rien_> tricricle is now only focusing on the network part
15:14:52 <ad_rien_> kingbird seems to address everything
15:15:04 <ad_rien_> (i.e. like the initial goal of Tricircle)
15:15:17 <GeraldK> as a proposal: there had been some confusion last meeting around what is a "NFVI reference architecture". we seem to mean something like OpenStack + neutron-sfc, right? From ETSI point of view, OpenStack is the VIM and runs on top of the NFVI, so maybe be choosing a different name for the intended reference architecture could solve our confusions. what do you think?
15:16:02 <serverascode> GeraldK right my mistake, I keep saying NFVi
15:16:23 <GeraldK> e.g. use "minimal benchmarking reference architecture"?
15:16:57 <ad_rien_> I'm still confused about what will be the minimal benchmarking reference.
15:17:12 <ad_rien_> several independant openstack instances? only one?
15:17:20 <GeraldK> serverascode: np. just that we use NFVI now already in several places e.g. the Etherpad
15:17:46 <serverascode> ad_rien_ yes this is where we got stuck last meeting :)
15:17:58 <GeraldK> let's talk first about the test/benchmarks we want to initially work on. then, we can see what benchmark reference architecture we need
15:18:26 <serverascode> GeraldK I agree
15:18:49 <jamemcc> I agree
15:18:54 <ad_rien_> I'm not working for a telco so please feel free to start the discussion ;)
15:19:20 <ad_rien_> As I mentioned, I just want to see whether there can be common actions with the massively distributed WG
15:19:43 <serverascode> my thinking has been that service function chaining (SFC) is a key feature for minimal benchmarking reference
15:20:26 <serverascode> so an openstack VIM which has the ability to do SFC, probably via networking-sfc
15:20:39 <serverascode> but that's just me
15:21:36 <serverascode> anyone have any thoughts on that?
15:21:39 <GeraldK> i did not propose this benchmarking topic :)
15:22:07 <GeraldK> not sure what the people proposing it had in mind when proposing it
15:22:33 <ad_rien_> If I'm right the idea was to identify limitations/missing features
15:22:51 <ad_rien_> of the Openstack vanilla code w-r-t the NFV use-cses
15:23:33 <ad_rien_> By conducting such experiments it will be possible to present strong arguments to the different openstack projects
15:23:39 <serverascode> that was my impression, where also the simple creation of a reference architecture is also valuable
15:24:14 <serverascode> just doing that would be of some use, and then testing it from both a functional and performance view would also be beneficial
15:24:31 <jamemcc> I didn't either - but it made sense to me.  I interpreted Benchmarking as a performance topic.  Performance being response time and throughput.  So minimal benchmarking could be measuring something like response time and throughput within and across openstack instances.
15:24:36 <serverascode> and would likely allow us to work with various groups like OPNFV, OpenStack Performance group, etc
15:25:24 <serverascode> I think the word "benchmarking" might have also been used in such a way that it also meant functional testing
15:25:40 <serverascode> so not just performance, but actually ensuring the features we need are there and are working
15:26:21 <serverascode> But, I am typing a lot, and what this group does is up to the group, which means we need to solve the problems we are actually encountering
15:26:23 <ad_rien_> +1
15:26:51 <jamemcc> I thought of it as having a baseline/minimal architecture that provided a recognized throughput and from that you could have a few persuits.  1. Imporve (or at least maintain) performance release over release.  Have a better measure on which vendors or specialized projects could claim great imporvements.
15:27:10 <ad_rien_> jamemcc:  +1  serverascode:  can you elaborate the use-case you envision
15:27:16 <ad_rien_> please?
15:28:18 <serverascode> I haven't though too much about the use case, but my thinking was mostly around networking-sfc
15:28:20 <serverascode> #link http://docs.openstack.org/developer/networking-sfc/
15:28:59 <serverascode> I am not a telecom expert by any stretch, but it seems to me like SFC is pretty important to most use-cases
15:29:06 <ad_rien_> ok
15:29:38 <ad_rien_> do you think we can find a key thread that will guide us in our action
15:30:00 <ad_rien_> i.e. a concrete use-case that can illustrate the networking-sfc you mention
15:30:42 <ad_rien_> i.e. what are the software components that should be deployed? and where (i.e; how these services should be consolidated through the different VMs)
15:30:47 <serverascode> the most common thing I see with SFC is "virtual customer premise equipment" (vCPE)
15:30:52 <ad_rien_> ok
15:31:07 <serverascode> but I'm not too sure how valuable that actually is?
15:31:10 <ad_rien_> so the idea can be to identify what is the minimal infrastructure
15:31:46 <ad_rien_> for being able to provide vCPE? and I guess that the VM that host the vCPE should be deployed as close as possible to
15:31:57 <ad_rien_> the customer location?
15:32:12 <jamemcc> Just following the line of thinking of a functional benchmark.  Bascially could define a number of somewhat simple and straightforward NFV use cases: e.g. Firewall, Load Balancer, Audio / Video Conferencing or maybe the benchmark would be an arrangement of a few of those that sets up the "chain"
15:32:41 <GeraldK> jamemcc +1
15:32:51 <serverascode> yeah that'd be great :)
15:33:34 <ad_rien_> ok but we should chose one, shouldn't we?
15:33:46 <ad_rien_> at least for moving forward
15:33:54 <serverascode> probably one to start then add more use-cases as we see fit
15:34:00 <ad_rien_> ok
15:35:09 <serverascode> thoughts? concerns about using a vCPE an SFC use case for our minimal reference architecture?
15:35:13 <GeraldK> if I remember right, we had choosen in total 3 or 4 mid to long term projects. should we also spend some meeting time on those?
15:35:51 <serverascode> ok, how about I write up a basic vCPE + SFC use-case and we discuss next meeting, and we move on to other potential projects?
15:35:54 <GeraldK> serverascode: sounds good to me
15:36:02 <ad_rien_> +&
15:36:03 <ad_rien_> +1
15:36:04 <ad_rien_> sorry
15:36:15 <serverascode> #action serverascode write up basic vCPE + SFC use case to discuss next meeting
15:36:38 <serverascode> #topic Other mid-to-long term projects to consider working on
15:37:05 <serverascode> ok GeraldK did you have some other project ideas?
15:37:56 <GeraldK> from the meeting we also had Rolling/live upgrades/updates and VNF onboarding with many votes
15:38:20 <GeraldK> I am interested in the rolling/live upgrades
15:38:58 <GeraldK> for an operator, each upgrade comes at high cost (for integration, testing, ..) and high risk
15:39:20 <serverascode> yeah and in a telecom environment it could be even harder
15:39:52 <serverascode> are you most concerned about the openstack control plane, or the virtual machine data plane?
15:39:55 <GeraldK> so, currently, operators tend to even skip some releases and just upgrade when an important new function/feature/improvement is available
15:40:42 <serverascode> and I don't think you can skip versions any more
15:41:08 <GeraldK> whereas the goal could be to reduce the efforts and risks such that telcos are more willing to upgrade more often
15:42:18 <serverascode> I do think that is an important topic and would be worth spending time on
15:42:21 <GeraldK> as far as I know, if we as a Telco get a new version from our integrator, this will skip a few OS releases. but of course that means extra (proprietary) efforts on the integrator side
15:42:31 <ad_rien_> with the adoption of OpenStack on top of containers, such upgrades should become easier
15:42:49 <ad_rien_> but I agree the distributed context of telcos makes the story more complex
15:43:33 <GeraldK> Telcos are very conservative on this regards. in the past with the legacy HW upgrades had been very rare.
15:43:45 <serverascode> GeraldK are you interested in this from a high-level, like how to approach upgrading? or the actual technical details?
15:44:53 <serverascode> and do you care about the openstack API uptime or just that your virtual machines stay up and running and don't lose any packets?
15:45:08 <GeraldK> more high-level I would say. what are requirements from operators/telcos, how can those be realized by openstack and where do we see gaps that we could then trigger to be addressed
15:45:42 <GeraldK> I care about the Telco service staying up and running and not loosing any calls / connections during the upgrade
15:46:04 <serverascode> ok
15:46:20 <GeraldK> as well as reducing the complexity and efforts to test the new versions
15:46:35 <serverascode> good point on testing, that is hard to do
15:47:04 <serverascode> I think it would be worthwhile putting together an upgrading document of some kind, something that discusses these requirements and issues
15:48:19 <GeraldK> during the upgrade phase you might even have entities running different versions in parallel
15:49:21 <serverascode> do you want to put together maybe a paragraph or so on this project idea and we can discuss it more next meeting?
15:49:26 <GeraldK> +1 to start a document. it can also collect ongoing activites around upgrading
15:49:49 <GeraldK> okay. I can give it a start.
15:50:18 <serverascode> #action GeraldK write up a paragraph or so on the upgrading project idea to discuss next meeting
15:50:33 <serverascode> ok about 10 min left, anything we are missing today?
15:51:13 <serverascode> ad_rien_ jamemcc any additional thoughts?
15:51:18 <jamemcc> In our LCOO workign group we also have raised the issue and pretty much agreed we share the concern and situation and approach as stated by GeraldK.  We want this topic to get more attention - basically upgradeability.  We found though as we started to dig a little deeper that we couldn't easily identify user stories and that our being behind 2-4 releases made it really our own issue - nothing we could point out for an upcoming release.
15:51:18 <jamemcc> But I can try to generate interest / help for this from the LCOO members.
15:51:32 <ad_rien_> not on my side.. (sorry a few busy and so not so reactive today)
15:51:45 <serverascode> ad_rien_ no worries :)
15:52:18 <GeraldK> jamemcc, can you point me to some docs / discussion on this?
15:52:30 <serverascode> jamecc is the LCOO mostly starting to work on user stories to start?
15:53:28 <jamemcc> Kind of a mixed bag - we are pushing joint user stories - but we also have involvement in current projects so are trying to also generate more cooperation around projects the various members are already workign on.
15:53:51 <jamemcc> Yeah GeraldK - I'll try to pull from some of our early meeting notes
15:54:06 <GeraldK> thanks jamemcc
15:54:56 <serverascode> ok, well that was a good meeting, we certainly have some direction to go in now :)
15:55:29 <serverascode> anyone have any last comments?
15:56:06 <serverascode> if you want me to send you an email before each meeting, feel free to put your email in the agenda page
15:56:18 <serverascode> under "contact emails"
15:56:29 <serverascode> otherwise I usually email the openstack operators list the day before as well
15:56:34 <jamemcc> Thanks Curtis - good job
15:57:07 <serverascode> thanks jamemcc :)
15:57:17 <serverascode> I'll end the meeting and we'll talk in a couple weeks
15:57:22 <serverascode> #endmeeting