14:03:37 <sgordon_> #startmeeting telcowg
14:03:38 <openstack> Meeting started Wed Dec  3 14:03:37 2014 UTC and is due to finish in 60 minutes.  The chair is sgordon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:42 <openstack> The meeting name has been set to 'telcowg'
14:03:42 <sgordon_> #topic roll call
14:03:52 <ian_ott> hi
14:03:55 <ybabenko> hi
14:03:56 <mkoderer> hi
14:03:58 <DaSchab> hi
14:04:04 <TheDarkKhan> Hi
14:04:10 <pczesno> hi
14:04:10 <rprakash> hi
14:04:17 <cgoncalves> hello
14:04:26 <gmatefi> hi
14:04:28 <madhumohan> Hi
14:04:30 <sgordon_> hi all, sorry for the delay
14:04:32 <rprakash> yes telcowg
14:04:34 <ajo> hi :)
14:04:36 <sgordon_> looks like i forgot to update my calendar
14:05:02 <sgordon_> #topic use cases
14:05:30 <sgordon_> i endeavored to update the wiki page to provide some guidance on contributing use cases
14:05:33 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Contributing_Use_Cases
14:05:52 <sgordon_> and i see jrakerevelant has started a new entry:
14:05:58 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Access_to_physical_network_resources
14:06:38 <sgordon_> did anyone have a chance to look at these?
14:06:49 <rprakash> you mean
14:06:52 <rprakash> https://global.gotomeeting.com/join/842007621
14:06:53 <sgordon_> probably not as they were created in the last 24 hrs i am guessing
14:07:05 <sgordon_> rprakash, ?
14:07:10 <rprakash> sorry delete thst
14:07:21 <rprakash> v
14:07:29 <DaSchab> link to nfv draft is broken
14:07:52 <rprakash> Possible current implementations include:
14:07:52 <rprakash> L3 gateways
14:07:52 <rprakash> SNAT
14:07:52 <rprakash> L3 forwarding
14:07:52 <rprakash> Floating IPs
14:07:53 <rprakash> External provider networks, e.g. VLAN backed
14:07:55 <rprakash> L2 gateways, currently only possible with 3rd party software (?
14:08:10 <ian_ott> not yet, thanks for proposing the template
14:08:26 <sgordon_> DaSchab, looks like somebody modified it to point to a docbox
14:08:35 <sgordon_> i had actually originally uploaded the pdf to the wiki
14:09:34 <rprakash> I wanted to see GTP tunneling added and will be working on revising an old Blue Print
14:09:43 <ybabenko> should we concentrate on "services" or "features" when we speak about usecases
14:09:58 <sgordon_> ybabenko, so that is what i have tried to help frame
14:10:05 <ybabenko> currently we have a mix : two "services" and one "feature"
14:10:13 <sgordon_> consensus last week seemed to be that we want to focus on "what" we want to do
14:10:15 <sgordon_> instead of "how"
14:10:30 <ybabenko> I think we should target features of openstack which are either missing or are not there ß
14:10:41 <sgordon_> that is we should use the use cases to THEN extract requirements
14:11:06 <sgordon_> ybabenko, the problem is without a documented use case, can you get them added to openstack
14:11:11 <sgordon_> the answer is increasingly, no
14:11:14 <margaret__> hi
14:11:41 <sgordon_> for those coming in we're discussing https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases
14:11:45 <rprakash> AT the Paris Summit there were dicussions on what to do
14:12:12 <jrakerevelant> hi
14:12:18 <jrakerevelant> sry for being late
14:12:57 <rprakash> Since neutron dnsmaq is being replaced the code for any change for telcowg in neutron will be unstable
14:13:00 <sgordon_> rprakash, yes - and one of the big items was to work harder on documenting use cases that we can then use to define and drive requirements
14:14:10 <mkoderer> sgordon_: btw should we have reviews on that use-cases? I just wondering if gerrit would make more sense..
14:14:36 <rprakash> OK  I added one for Mobile Carrier - "GTP tunnel support for mobile network for NFV VNFs like SGW, PGW, MME (https://blueprints.launchpad.net/neutron/+spec/provider-network.type-gtp -needs update for resubmission)
14:14:51 <sgordon_> mkoderer, my thinking is that git/gerrit is a bit too heavy to get contributions from the people we want to hear from
14:14:54 <sgordon_> particularly operator
14:15:12 <rprakash> THE BP is old one duing quatum time frame and anyone who wants to help me update is welcome
14:15:15 <sgordon_> mkoderer, ideally the use case ends up in the problem statement of blueprint(s) and is reviewed via gerrit then
14:16:25 <mkoderer> sgordon_: I just have the feeling that we end-up with many use-cases in totally different state and nobody reads them ;)
14:16:26 <rprakash> How many use cases we are planning to have for operators this K12?
14:16:38 <jrakerevelant> sgordon_:  since i was late, did i miss any comments on my use case?
14:16:52 <mkoderer> sgordon_: but ure right... gerrit would be too heavy
14:17:02 <sgordon_> mkoderer, rprakash i think i'll worry about upper limits when we actually have too many coming in
14:17:05 <sgordon_> :)
14:17:10 <mkoderer> k
14:17:26 <sgordon_> mkoderer, rprakash i would like to have 6 as a start to have a good baseline
14:17:31 <sgordon_> and agree the quality is variable
14:17:35 <rprakash> I did not see any discussions on any use case lets begin with number 1
14:17:50 <sgordon_> primarily atm there is very little editing of the wiki page aside from one or two individuals
14:18:17 <sgordon_> the first two use cases were contributed loose cycle and agree, they dont necessarily meet the framing we discussed last week
14:18:20 <rprakash> Is Virtual IMS the first one?
14:18:29 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Session_Border_Controller
14:18:31 <sgordon_> no the SBC
14:19:01 <sgordon_> i actually like the high level desc and characteristics put forward here
14:19:19 <sgordon_> as calum did try somewhat to keep characteristics and requirements as separate things
14:19:33 <sgordon_> any other thoughts?
14:19:49 <ybabenko> Why use-cases is referring to a particular vendor?
14:19:52 <ybabenko> Perimeta Session Border Controller, Metaswitch Networks.
14:20:09 <rprakash> The SBC use case is folowed bt bunch of requirements that are mostly completed in Juno
14:20:21 <jrakerevelant> so an application as a "use case" is desirable?
14:20:33 <ybabenko> jrakerevelant: see discussion above
14:20:40 <jrakerevelant> or shouldnt it be application : one or more use cases?
14:20:51 <margaret__> An application as a use case helps focus all the features/gaps that need to be filled
14:20:51 <sgordon_> ybabenko, because they submitted it
14:20:59 <sgordon_> ybabenko, other vendors are welcome to do same
14:21:17 <jrakerevelant> ybabenko: oh sorry
14:21:20 <margaret__> Else we get into a theoretical debate. I like the use case since it focuses on performance
14:21:20 <sgordon_> ybabenko, theoretically different implementations of same function may have different requirements
14:21:21 <ybabenko> sgordon_: that is fine as long as we stay vendor neutrol in wiki
14:21:25 <mkoderer> I guess the best way would be if Telcos would summit the use-cases :)
14:21:30 <dalgaaf> I would prefer to make it generic and independent of vendors
14:21:31 <sgordon_> mkoderer, ++++++1
14:22:03 <sgordon_> dalgaaf, great - generic use case is welcomed too
14:22:07 <rprakash> The seesion border use cas case will be a simple VoiP call from  end point 1 to end point 2
14:22:15 <margaret__> But the VNF vendors are will the rubber meets the road for the telcos
14:22:20 <jrakerevelant> mkoderer: hey we did submit one :)
14:22:28 <dalgaaf> would we even be able to check this use case against this vendors app from the openstack side?
14:22:39 <mkoderer> jrakerevelant: yeahh :)
14:22:43 <margaret__> The SBC is focused on performance and the types of things which need to be configured to meet that which impacts openstack
14:22:55 <sgordon_> dalgaaf, the key question for me is - are you willing to propose a generic version of the use case
14:22:57 <sgordon_> if the answer is no
14:22:58 <jrakerevelant> mkoderer: I still need to refine it though
14:23:02 <sgordon_> then i am inclined to keep what we have
14:23:21 <sgordon_> the more people helping with collating of relevant use cases, ideally from providers
14:23:26 <sgordon_> the less this becomes an issue
14:23:33 <rprakash> Sure the VoiP call has o meet those criterion listed on site and we can quatify them like 150 ms end to end delay etc.
14:23:33 <jrakerevelant> sgordon_: +1
14:23:55 <margaret__> If you look in details (which i only started doing now) - the SBC features drive features needed for high performance VNFs
14:24:13 <sgordon_> right
14:24:22 <margaret__> So unless you find a specific example that metaswitch suggested which is only useful for their app - i say we accept their proposal
14:24:23 <sgordon_> calum intentionally took his high level characteristics
14:24:27 <jrakerevelant> rprakash: QoS will be one of the hardest things to implement anyway, why not start with low hanging fruit?
14:24:28 <sgordon_> and then spelled out what that means
14:25:09 <margaret__> We need another use case that is focused more on instantiation of VNFs.
14:25:14 <ybabenko> jrakerevelant: QoS and troughput performane with small packets
14:25:43 <rprakash> THE QoS of  one call in terms of RTT, delay, jitter,BW  of 1 session and then comes the capacity of VNF for VoIP to handles that capacity as a VM
14:26:11 <rprakash> say 1 million sessions per VNF
14:26:33 <sgordon_> #info margaret__ notes we need a use case focussed more on instantiation of VNFs
14:27:05 <sgordon_> #info rprakash notes requirements of a VoIP call, impacts on QoS in terms of RTT, delay, jitter, VW of 1 session and then comes the capacity of VNF for VoIP to handles that capacity as a VM
14:27:05 <jrakerevelant> rprakash: that can only be proven/ disproven with a specific implementation of the function
14:27:08 <margaret__> I didn't mean it to be a replacement of SBC proposal - just another angle which flushes out openstack issues
14:27:09 <rprakash> Some can pickup Asterisk opensource or if Metswicth provides one and model the requirements
14:27:18 <sgordon_> margaret__, understood
14:27:57 <sgordon_> i guess what i would like to be able to get to is for a few volunteers with use cases in mind
14:28:10 <sgordon_> to take the action item to try and write them up in the next week or so
14:28:23 <sgordon_> it does not have to be exhaustive but rather something to get the conversation moving forward
14:29:28 <margaret__> I have been working with another vendor in the OPNFV group on a vPE instantiation - let me see if we can pull this together for this - but I can't attend the next IRCs for the rest of the year
14:29:57 <sgordon_> yes understand
14:29:58 <rprakash> Openstack can provision any VNF  using heat template and provide Resources South Bound and API to call Nort Bound and treating VoIP media, all we need to know is how will data call be evaluated in terms of performance matrix we agree for VoIP call and how much the VoIP VNF can handle
14:30:06 <sgordon_> i think if you just shoot us an email margaret__ we can try discuss
14:30:18 <sgordon_> i am sure attendance will wane as we get closer to the break for many people
14:30:42 <rprakash> OK then can we move to case 2 , assign few voluteers o this and move to second
14:31:01 <mkoderer> sgordon_: we will add use-cases for "securtiy segregation (dmz/mz concept)", VNF instantiation and seperation of Infra/App Orchestration
14:31:52 <jrakerevelant> mkoderer: +1
14:32:02 <mkoderer> DaSchab will do that ;)
14:32:06 <sgordon_> #action margaret__ to work with another vendor in OPNFV group on vPE instantiation use case - will provide via mail (cant attend IRC meetings for remainder of year)
14:32:38 <rprakash> Security segregation , its using Netwurn Security Group for VNF? using port level blocking etc?
14:32:41 <jrakerevelant> mkoderer: if it is allowed I can add our examplary LLD
14:32:45 <sgordon_> #action mkoderer and DaSchab to work on security segregation (dmz/mz concept), VNF instantiation and seperation of Infra/App Orchestration
14:33:00 <ybabenko> jrakerevelant: your use-case is basically a HW-GW for legacy services if i understand correctly?
14:33:12 <jrakerevelant> ybabenko: yes
14:33:21 <jrakerevelant> jrakerevelant: which is solvable
14:33:31 <jrakerevelant> ah talking to myself
14:33:38 <jrakerevelant> ybabenko: which is solvable
14:33:41 <mkoderer> jrakerevelant: we need to discuss that offline :P
14:33:50 <jrakerevelant> mkoderer: sure
14:34:17 <jrakerevelant> ybabenko: it doesnt need to be HW
14:34:33 <rprakash> where is the link for security Segreegation?
14:34:38 <mkoderer> rprakash: no never had a closer look to that
14:34:41 <sgordon_> #info jrakerevelant use case is effectively HW-GW for legacy services - though not necessarily HW
14:34:49 <mkoderer> rprakash: we will add our use-case soon :)
14:34:59 <DaSchab> ...and we will describe the use-cases in a generic way without vendor specific solutions
14:36:46 <rprakash> Note VNF isolation comes at mutiple levles - Tenant, Security Gruops, and may be Firewall and even some policy from  orchestartion tweaking Security Groups in neutron, so not clear to me here what specific we want to achieve here
14:38:05 <sgordon_> ok
14:38:12 <jrakerevelant> rprakash: one of the things you might want to have are separate physical servers for different VMs
14:38:15 <sgordon_> thank you to those who volunteered above, it is much appreciated
14:38:31 <sgordon_> #topic orchestration
14:38:33 <rprakash> HW-GW  for legacy not clear to me how itf its the use case as even in OPNFV we want COTS based implementaions
14:38:42 <sgordon_> mkoderer, i believe you had added some links to discuss to the agenda?
14:38:45 <sgordon_> #chair mkoderer
14:38:45 <openstack> Current chairs: mkoderer sgordon_
14:39:07 <sgordon_> #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/051473.html
14:39:11 <jrakerevelant> rprakash: What do you mean, how will I e.g. connect a physical eNodeB to my vEPC
14:39:31 <mkoderer> yep
14:39:41 <jrakerevelant> sorry for offtopic
14:39:56 <mkoderer> #topic Telco Orchestration
14:39:57 <sgordon_> np
14:40:01 <ybabenko> rprakash: we need HW-GW to connect to legacy services .... I would expect to terminate my overlay there
14:40:20 <mkoderer> so I had several discusstion about orchestration
14:40:27 <jrakerevelant> we can move that to the ML?
14:40:37 <jrakerevelant> to close the use case discussion
14:40:43 <mkoderer> jrakerevelant: +1
14:40:45 <sgordon_> +1
14:40:56 <sgordon_> also it doesn't have to be perfect from the get go
14:41:01 <sgordon_> we discuss and we iterate as needed
14:41:02 <jrakerevelant> please continue mkoderer :)
14:41:22 <mkoderer> ok so I try to finalize the document
14:41:24 <mkoderer> #link https://etherpad.openstack.org/p/telco_orchestration
14:41:36 <mkoderer> current state is more or less a brain storming document
14:41:55 <rprakash> well eNodeB (Physical) to vEPC (virtual) will have a tenant *(carrier) specific link (pipe) that will be secured using the two end point interfaces terminating on those phy/virt devices
14:42:09 <rprakash> lets move to Orchestartion (sorry folks)
14:42:39 <mkoderer> so I will work on that the next day and then push it to the wiki
14:43:35 <mkoderer> sgordon_: I also included that "internal" and "external" questions
14:43:47 <sgordon_> right
14:44:17 <sgordon_> i like the framing of it
14:44:28 <rprakash> This is very extensive staring VNF to template to TOSCA not sure I have studied this to comment but certainly if its for NFV, we need to split this at VIM, VNF , OSS?BSS layaers fpor Orchestration as functions to implement
14:44:37 <sgordon_> i think on that thread angus was looking very specifically for examples of "what do you need from heat that we arent addressing today"
14:44:53 <sgordon_> i think some of it is in here and this is a good manifesto
14:45:00 <rprakash> I will go over it and can I edit ie?
14:45:05 <sgordon_> but we may need to break it up into digestable chunks for consideration
14:45:27 <rprakash> or send comment to whoever owns it?
14:45:31 <mkoderer> rprakash: sure feel free.. you can also respond via M/L
14:45:42 <mkoderer> #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/051473.html
14:45:57 <ybabenko> rprakash: do you have a better suggestion for the format of VNF? how would you like it to be packaged for orhestration?
14:47:16 <mkoderer> and there is already an intressting spec for heat that solves some of the internal OpenStack issues
14:47:19 <mkoderer> #link https://review.openstack.org/#/c/53313/
14:47:26 <mkoderer> so it's multi region support for heat
14:48:03 <sgordon_> yes
14:48:17 <mkoderer> I already talked to the heat ppl.. they would we quite open to help us with our requirments
14:48:48 <sgordon_> seems to be making good progress too
14:48:48 <sgordon_> yes
14:49:03 <sgordon_> i think they need help navigating the acronym soup and getting to the heart of what you need
14:49:10 <ybabenko> mkoderer: i think we should really make this topic (multi site support) a killer req for NFV so that enough attention is given to it in the community?
14:49:13 <mkoderer> sgordon_: should I put that document as seperate wiki page under telcowg?
14:49:18 <sgordon_> hopefully that is where we can work together :)
14:49:20 <rprakash> Yes multi-region in heat as a resource is scheduled for Kilo and this will allow disctributed orchestaion of VNFs, but more of such we will have to compile to get orchestartions as its very wide
14:49:23 <sgordon_> mkoderer, the etherpad?
14:49:26 <jrakerevelant> multi-region heat will be great
14:49:28 <ybabenko> mkoderer: +1 for separate wiki page
14:49:40 <mkoderer> sgordon_: at the end when it's "mature" enough
14:49:43 <sgordon_> yes i think so
14:49:54 <margaret__> multi-site is a definite for NFV crowd
14:49:54 <sgordon_> etherpad is good for continuing to massage the content
14:50:10 <sgordon_> #info heat multi-region support progressing well
14:50:17 <rprakash> We can possibly compile different BPs for Orchetsration together on our telcowg site
14:50:52 <sgordon_> #link https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
14:51:02 <sgordon_> #link https://blueprints.launchpad.net/heat/+spec/multi-region-support
14:51:38 <mkoderer> ok fine.. that's all from my side
14:51:42 <mkoderer> any other topics?
14:52:34 <sgordon_> #topic other business
14:52:44 <sgordon_> i had a question that's actually about a requirement
14:52:51 <mkoderer> sgordon_: I received a mail about an "Telco WG Ecosystem" meeting
14:53:07 <sgordon_> vlan trunking into vms, there are a couple of proposals related to this to at least allow it when using LinuxBridge
14:53:25 <sgordon_> im trying to gauge interest/demand in doing something about same for OVS...
14:53:32 <rprakash> I wanted to add Mobile Network use case for GTP tunneling and will bring it next week
14:53:39 <sgordon_> mkoderer, yes carol is setting that up at the moment
14:53:45 <jrakerevelant> sgordon_:  How many people are requesting this?
14:53:48 <sgordon_> #action rprakash add ingMobile Network use case for GTP tunneling and will bring it next week
14:53:52 <sgordon_> #undo
14:53:52 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x3c43ad0>
14:53:58 <sgordon_> #action rprakash adding Mobile Network use case for GTP tunneling and will bring it next week
14:54:02 <sgordon_> rprakash, thanks !
14:54:12 <sgordon_> jrakerevelant, that's the million dollar question :)
14:54:40 <ybabenko> jrakerevelant: +1
14:54:44 <sgordon_> i believe it's coming up from vEPC use cases, or more specifically implementations thereof
14:55:14 <gmatefi> sgordon_ : vlan trunking mainly interesting for packet processing related applications, where linux bridge is not considered to be powerful enough
14:55:27 <sgordon_> right
14:55:41 <sgordon_> the reason that the work is starting with LB is that doing it for OVS is going to be more...involved
14:56:09 <rprakash> Most 3GPP use GTP U & GTP  C (v2) and so may split this into two and will think over how to do that in Control and Data planes
14:56:18 <ybabenko> but this means that you must use OVS, right?
14:56:46 <ybabenko> but OVS is used only in part of SDN solutions which we would probably see in NFV environment
14:56:58 <rprakash> Yes it will require OVS in Data Plane (GTP-U) and possibly GTP-C in MME path
14:59:35 <rprakash> is it time we leave the floor to neutron-DVR
14:59:55 <Swami> rprakash: thanks
14:59:57 <rprakash> Any conclusions for telocwg?
15:00:05 <jrakerevelant> thanks sgordon_ for hosting
15:00:07 <sgordon_> yes it is
15:00:13 <sgordon_> lots of volunteers for use cases
15:00:16 <sgordon_> which is excellent
15:00:19 <mkoderer> thx all
15:00:20 <sgordon_> thank you all for that!
15:00:23 <sgordon_> #endmeeting