15:03:29 #startmeeting operators_telco_nfv 15:03:30 Meeting started Wed Nov 2 15:03:29 2016 UTC and is due to finish in 60 minutes. The chair is serverascode. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:34 The meeting name has been set to 'operators_telco_nfv' 15:03:41 #topic roll call 15:03:45 hi all! 15:03:59 * PerfectChaos waves 15:04:07 o/ 15:04:10 Hi 15:04:23 Hi 15:04:35 Hello 15:04:54 ok great, we have the most ppl ever :) 15:05:07 #link https://etherpad.openstack.org/p/BCN-ops-telcom-nfv-team 15:05:21 ^ that's the session from last week at at the summit 15:05:34 #link https://etherpad.openstack.org/p/ops-telco-nfv-meeting-agenda 15:05:39 ^ that's our agenda page 15:05:57 I only have one real thing on the agenda right now, feel free to add to it if you have other things to discuss 15:06:04 the one thing was our list of potential projects 15:06:19 anyone have any comments/suggestions/ideas before I go into that topic? 15:06:57 No - good organization Curtis - lets push forward 15:07:44 ok 15:07:49 #topic Potential Projects 15:08:27 so the idea was to follow the large deployment teams lead and fiind a medium to long term project to shepherd through the openstack ecosystem 15:08:43 they worked on getting network segments into neutron and were pretty successful 15:09:04 o/ (back to lurk mode) 15:09:29 basically they found a common feature or issue and worked on it over time 15:09:40 so we have a list of things from the summit at that link above 15:09:52 anyone see anything in particular that jumps out as needing to be solved? 15:10:26 NFVI benchmarking ref.platform got +4 15:10:36 Rolling/live upgrade has +3 15:10:49 right there was a lot about benchmarking in that list 15:11:14 how about the people in the meeting today? what are your issues or requirements? 15:11:15 Is there a specific use-case that can serve as a guide line ? 15:12:01 upgrading is something we (DOCOMO) would be interested in 15:12:34 We can identify a lot of challenges but with a common theme it might be easier to focus and make priorities between those challenges 15:12:38 currently, we skip releases and would like to improve on this 15:13:03 right, and it's not really possible anymore, afaik, to skip releases 15:13:39 ad_rien: what's a common theme? like "benchmarking" is a theme? is that what you mean? 15:13:55 From all the challenges I can see on the etherpad 15:14:02 #link http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/rolling-upgrades.html PWG user story on rolling upgrades 15:14:28 I get the feeling that some are rather general (i.e. upgrade is an interesting challenge but not specifc to the NFV WG If I'm right) 15:14:34 Rolling upgrades strike me as something that are generally going to be of interest to anybody 15:14:43 ...yeah, exactly what ad_rien_ just said =3 15:14:52 So this is my point. 15:15:31 There are several challenges, all look really interesting but it might make sense to identify the ones that are really specific to the NFV use-cases 15:15:40 in contrast to other openstack users, Telcos might prefer not to have very frequent rolling upgrades. 15:15:48 I guess the thing to consider is - if it's a general problem there are more likely to be other people elsewhere working on them. 15:16:12 got your point. 15:16:13 Whereas NFV-specific problems are less likely to have people who aren't use out there driving to get them solved 15:16:23 PerfectChaos: yes exactly my point 15:17:02 ok, it seems like there is a bit of a consensus that working on upgrades might not be NFV specific enough 15:17:37 that leaves us with benchmarking as a theme, at least in terms of what has been mentioned today 15:17:46 It might become critical/specific but later. 15:18:13 Just to give it a little more insight I think the possible more NFV related use case comes through with the massive cloud assumption 15:18:15 Well, if the main problems NFV/Telecoms folks are all general problems, then we shouldn't just discard the idea of looking into those. It's down to what those people will find the most useful, right? 15:18:53 If you go with the assumption that the NFV/Telcom brings with it the massive cloud - then the upgrade of massive cloud has addtional challenges 15:19:29 That said - I think somethign closer to Telcom/NFV is more appropriate 15:19:30 * PerfectChaos nods 15:19:38 Maybe we should start by simple actions/challenges and then increase the complexity step by step. 15:20:15 ForI agree with jamemcc remark but this mean that first you should be able to have an Openstack deployment accros distinct locations 15:20:35 s/ForI/I sorry for the typo 15:21:01 Is there a specific NFV use-case that can help us in our exchange ? 15:21:29 @ ad_rien yeah - agreed if I follow - So back to defining the reference implementation? 15:21:36 yes 15:22:23 by reference implementation...what does that mean? 15:22:33 is that kind of like what OPNFV is doing? 15:22:42 What is the OpenStack deployment architecture if you want to address NFV use-cases? How can you instantiate such an architecture? 15:22:48 ah, ok 15:23:25 At work we have been trying to define NFVi, specifcally around features 15:23:46 is it deployed in one location or across several locations? where are the compute nodes that host the VMs? The control plane? … 15:23:54 serverascode: NFVi ? 15:24:23 i for Infrastructure ? 15:24:30 my impression is that under the ETSI definition, OpenStack is NFV infrastrcture (NFVi) and a VIM 15:24:47 VIM = virtualized infrastructure manager 15:25:01 yepp 15:25:02 thanks 15:25:20 so that also something that can help the OpenStack community 15:25:36 and it's hard b/c it's really a spectrum of requirements 15:25:41 I get the feelings that our words (i.e. from the network community vs the distributed computing community) differ sometimes 15:25:42 ETSI NFV003 defines NFVI: totality of all hardware and software components that build up the environment in which VNFs are deployed 15:25:56 so it's more than Openstack and also includes the hardware 15:26:16 ok thanks GeraldK 15:26:23 it also could have multiple VIMs 15:26:53 but you can have different ways to deliver such a NFVi 15:26:59 see in the pad line 37 15:27:24 either a brokering approach where an orchestrator operates several VIMs or a bottom up approach 15:28:04 where OpenStack becomes cooperative enough to be able to natively federate distinct data centers/locations 15:28:21 interesting, so are we discussing reference implementations right now? kind of? 15:28:32 I think we are, kind of. 15:28:38 I would say yes (at least from my side ;)) 15:29:01 I believe Telco's want to stay in control so prefer the brokering approach 15:29:09 The first step would presumably be deciding how deep the reference implementation goes 15:29:12 There should be different scenarios, a first action can consist of identifying them 15:29:49 I almost feel like in order to get any work done we first have to define at least one or two reference implmentations 15:29:56 GeraldK: we work with Orange Labs and BT and the choice is unclear. We are trying to see what are the pros/cons of the different deployment strategies. 15:30:00 so that we at least know what we are talking about to one another 15:30:14 and then, how different would this be to the reference platform developed by OPNFV? Or, how could we collaborate with OPNFV in it? 15:30:58 I was hoping, at some level, that this group could work as a bridge between OPNFV and OpenStack Operators doing NFV 15:31:10 to work on the main topic of "NFVI benchmarking" we may not need our own reference implementation, do we? 15:31:25 serverascode: yes this makes sense 15:32:00 no I don't think we need to make our own definition, but we'd have to have some common language to do work in this group 15:33:13 ok, so we are about 30 minutes into our hour long meeting 15:33:48 * ad_rien_ is looking on google for information on the reference architecture of a OPNFV deployment 15:35:06 I think we have discussed three themes so far: 1) upgrades 2) benchmarking and 3) reference implementation definition 15:36:01 ad_rien_, maybe a good document to check current status of OPNFV is http://artifacts.opnfv.org/opnfvdocs/colorado/docs/documentation/index.html 15:36:04 Maybe a stupid question/comment but is there a link somewhere to clearly understand the differences between OPNFV and OpenStack in terms of internal mechanisms 15:36:36 not sure I get your question. OPNFV is using OpenStack. 15:36:43 ok 15:37:00 Let me reword, what does OPNFV bring? 15:37:20 that is a question I hear quite often :) 15:37:23 from my understanding 15:38:06 Basically, they bring together various pieces that combined make an NFVI. One of those pieces is OpenStack. 15:38:30 OPNFV enables administrators to program the network active equipments (in somehow, an advanced Neutron component) 15:39:11 so the reference architecture can be several openstack instances and one OPNFV to deliver a NFVi ? 15:39:20 there are several goals: integrate various upstream projects, act as intermediate body between ETSI NFV work and OpenStack, join forced to push new features to upstream projects, ... 15:40:13 ad_rien_, OPNFV builds a reference platform including OpenStack, ODL, and others 15:40:45 ok 15:41:02 there was a nice handout on OPNFV in the Summit. let me see if I can find it online 15:41:15 but If I'm correct the working group focused on NFV within the OpenStack ecosystem? 15:41:32 so do we care about ODL and others :-) ? 15:42:18 I think we do have to be aware of SDN systems like ODL, and OVN 15:42:44 certainly some NFV deployments will rely on functionality that only SDN can provide 15:43:03 but not all deployments will need that. Then there are projects like neutron-sfc 15:43:18 oh and vlan aware virtual machines which was just blogged on superuser 15:43:36 serverascode: sorry for my remarks, it was a bit provocative. I agree we should be aware but we should also focus on OpenStack, shouldn't we? 15:43:42 #link http://superuser.openstack.org/articles/four-opens/ 15:43:54 ad_rien: no worries, not provocative at all 15:44:36 Agred focus inwards toward OpenStack and represent combined knowledge interest of OPNFV and SDN 15:44:50 and ETSI 15:44:55 AFAIK, there is not reference architecture for delivering a NFVi with OpenStack, maybe we can try to identify how we can progress on that point? 15:45:02 So... since there are a -lot- of different variables which could vary wildly between use-cases even within NFV/telecom use, we'd have a hard time picking one reference implementation which would be consistently useful, I think. 15:45:05 at least as a starting step? 15:45:50 #link http://go.linuxfoundation.org/l/6342/2016-10-11/3jhnwr/6342/158966/OPNFV_WhitePaper_Paving_Way_OpenSource_NFV_101016.pdf WhitePaper on OPNFV 15:45:58 Since people were interested in benchmarking NFVI, would it instead make sense to be thinking about frameworks/infrastructure with which we might be able to test/verify/benchmark different NFVIs? 15:46:08 I couldn't find the handout, but the figure are also available in the whitepaper 15:46:12 I do think service function chaining (SFC) will probably be a common feature, and with neutron-sfc you don't technically need a 3rd party SDN controller 15:47:02 so we could do a reference arch that supports neutron-sfc 15:47:37 We (at Inria) are interested by performing such evaluations 15:47:42 also there is some interesting work around "neutron router flavors" 15:47:44 #link https://specs.openstack.org/openstack/neutron-specs/specs/newton/multi-l3-backends.html 15:47:50 I think to define reference architecture and combinging wiht what is said about focusing on OpenStack - w are saying what openstack components are included and in what arrangement to get basic NFVi working. 15:48:11 We have access to the Grid'5000 testbed so we can perform experiments in a quite easy manner 15:48:25 jamemcc: +1 15:48:43 And from my perspective this would be across at least 3 separate clouds though perhaps form testing and benchmarking we ought to pick a higher # 15:49:13 neutron-sfc is also being discussed in OPNFV (https://jira.opnfv.org/browse/VFNGRAPH-3) but I am not aware of any details on this project 15:49:55 IMHO this topic requires some discussion on collaboration with OPNFV. I am sure they would be interested on some collaboration. 15:50:12 ok, interesting, so I'm feeling a bit of consensus around some kind of "vanilla" or "minimal" NFVi reference architecture, perhaps including neutron-sfc? 15:50:21 +1 15:50:47 I think I should be able (or at least give a try) to add Orange folks in the loop 15:51:25 ok, so we have about 8 min left 15:51:46 where should we go from here? do we agree this is one area to explore? 15:51:54 the goal should be to get some benchmarking or similar, but not to have "just" a reference architecture. 15:52:27 Agreed 15:52:34 and likes it 15:52:53 ok, and do you think it would be benchmarking some kind of "vanilla" or "minimal" NFVi based on OpenStack projects? 15:53:08 so neutron-sfc for example 15:53:09 First step can be a reference architecture, Second step a scenario that inclue neutron-sfc (maybe we can push such a scenario in Rally) and Three perform some evaluations? 15:53:21 See above about benchmarking frameworks - what about, say, coming up with some standard set of benchmarking tests for those evaluations? 15:53:53 (which could subsequently be run against a different NFVI to see how it performs in comparison, if one was so inclined) 15:53:54 what I mean is: create a set of (standardized) benchmarks and test those on a reference implementation. but the focus would be the benchmarks. 15:54:24 Right. Sounds like we're on the same page, then. 15:54:31 agreed 15:54:42 cool, there is also a performance working group that we could team up with 15:54:45 PerfectChaos: can you point once again the link regarding the benchmark ? 15:55:09 that would fit in well with the user committee wanting more communication between openstack working gorups 15:55:19 we could collaborate with OPNFV and the performance team 15:55:45 ok so can I say something like we agree that: 15:55:46 We are involved in the performance WG at Inria. If I'm correct here we do not really talk about performance but more on functional benchmarks ? 15:55:52 ad_rien_: Hmm? I didn't have any links on benchmarks? 15:56:05 ah ok functional vs performance 15:56:25 "PerfectChaos: See above about benchmarking frameworks " - see above ? 15:56:41 My assumption was that it would include both functional and performance benchmarks... 15:56:45 ok 15:57:40 ad_rien_: Oh, I was just referring back to my previous comment "would it instead make sense to be thinking about frameworks/infrastructure with which we might be able to test/verify/benchmark different NFVIs?" 15:58:06 To which I think the answer is "we should be thinking about both". 15:58:13 ok, can I say something like: "We agree that this working group will develop and perform benchmarks on a NFVi reference architecture which we will determine in future meetings" 15:58:36 That seems like a good point to start from 15:58:48 what would be the timeframe for this? and would we focus on this one only or allow a second topic? 15:58:58 but definitely a good starting point 15:59:07 I think we'd have to come up with a timeframe in future meetings 15:59:14 we could certainly work on more than one thing 15:59:21 only about a minute left 15:59:26 sure. but roughly? 1 year? 15:59:50 probably something like that, at least a couple releases 15:59:55 sorry I have to end the meeting! 15:59:56 okay 16:00:01 bye 16:00:10 #endmeeting