22:00:26 <sgordon_> #startmeeting telcowg
22:00:26 <openstack> Meeting started Wed Dec 10 22:00:26 2014 UTC and is due to finish in 60 minutes.  The chair is sgordon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:31 <openstack> The meeting name has been set to 'telcowg'
22:00:34 <sgordon_> #topic roll call
22:00:47 * sgordon_ here
22:00:49 <sgordon_> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
22:00:56 <sgordon_> who is around for the telco working group meeting?
22:01:03 <amitry> Here
22:01:14 <cloudon> hi
22:01:28 <aveiga> hello
22:02:08 <sgordon_> ok, pretty full agenda for today so let's get started
22:02:27 <sgordon_> #topic use cases
22:02:50 <sgordon_> so margaret mkoderer and rprakash took action items last week
22:02:53 <sgordon_> related to use cases
22:03:03 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#VPN_Instantiation
22:03:27 <sgordon_> Margaret submitted the above regarding VPN Instantiation
22:03:50 <sgordon_> using the description/characteristics/requirements breakdown we discussed last week
22:03:54 <sgordon_> any initial thoughts?
22:04:43 <cloudon> would be good to understand the locality criteria a bit more
22:05:22 <cloudon> potentially wider applicability e.g. concepts of "network nearness"
22:05:24 <sgordon_> #info cloudon comments "would be good to understand the locality criteria a bit more" w.r.t. vpn instantiation use case
22:05:55 <sgordon_> #info potentially wider applicability for concepts such as "network nearness"
22:06:44 <sgordon_> mkoderer, any luck with regards to security segregation (DMZ/MZ concept)?
22:06:53 <sgordon_> or VNF instantiation use cases?
22:08:08 <sgordon_> will take that as no :)
22:08:21 <sgordon_> will carry that action over
22:08:42 <sgordon_> #action mkoderer and DaSchab to work on security segregation (dmz/mz concept), VNF instantiation and seperation of Infra/App Orchestration
22:09:08 <sgordon_> #action rprakash adding Mobile Network use case for GTP tunneling and will bring it next week
22:09:32 <sgordon_> any other comments wrt use cases?
22:09:43 <sgordon_> also thanks for that input cloudon :)
22:11:54 <sgordon_> #topic orchestration
22:11:56 <cloudon> Looking at the physical access to network resources case: I'm not clear if it's saying there's a gap
22:12:19 <sgordon_> cloudon, i think the intent with that was to document the use case
22:12:27 <sgordon_> if no gap than perfect (preferable even :))
22:12:31 <sgordon_> *then
22:12:54 <sgordon_> particularly the comment 'The main goal of this use case is not necessarily to implement something new but to discuss the practicability of the current implementations. If I missed an alternative implementation please add it to the list. '
22:13:28 <cloudon> so is the intention to do the analysis to see if there is a gap?
22:13:38 <sgordon_> yes
22:13:43 <cloudon> ok
22:13:53 <sgordon_> if mkoderer isn't here we may skip to discussing that aspect
22:14:04 <sgordon_> (i was hoping mkoderer might be able to update on orchestration)
22:14:27 <sgordon_> #topic Requirement Definition
22:14:33 <sgordon_> so what i wanted to talk about here was
22:14:53 <sgordon_> i think we got to a good point in terms of agreement about stating use cases at a high level, trying not to lead with a solution
22:15:15 <sgordon_> but how do we want to then turn that into a gap analysis and ultimately requirements
22:15:51 <sgordon_> i would obviously like more use cases still but want to start thinking about process for defining action :)
22:17:07 <sgordon_> did i accidentally schedule this meeting in the middle of an SDN conference or something? :)
22:17:24 <aveiga> sgordon_: no, just a firefighting session here
22:17:35 <aveiga> I think it me be worthwhile to pick one use case per week to go over
22:17:39 <sgordon_> yes
22:17:45 <aveiga> since it's not likely going to be a short conversation in most cases
22:18:06 <cloudon> is end goal to identify either existing blueprints or a gap where we need new ones?
22:18:15 <sgordon_> what i had been musing about we think about use cases in terms of description, characterstics, requirements
22:18:25 <aveiga> so we should pick one, link to an etherpad from it's section of the wiki, and go over it over the week looking at what's missing, and what, if anything, is planned to cover it
22:18:25 <sgordon_> and then the next step is success criteria?
22:18:30 <sgordon_> cloudon, both most likely
22:18:39 <sgordon_> aveiga, +1
22:19:17 <sgordon_> #info aveiga suggests picking one use case per week for review, add an etherpad link for it in the wiki and use the week to go over gaps, what's planned, what's not, define success criteria
22:19:50 <cloudon> agree - ideally the raiser would have some idea of gaps but often will need help to identify, particularly if from a telco background
22:20:28 <aveiga> cloudon: yes, and I think you bring up a good point
22:20:34 <sgordon_> certainly
22:20:39 <aveiga> the raiser field in the wiki should have email or IRC info
22:20:44 <sgordon_> i think we're really just trying to compartmentalize their thinking on it
22:20:47 <aveiga> we need to be able to include t hem will discussing the gap analysis
22:21:35 <sgordon_> right
22:21:40 <sgordon_> atm they have names against them
22:21:45 <sgordon_> not an email or irc nick though
22:22:09 <aveiga> there was another thread about that on the ML earlier, but not everyone raising an issue is necessarily a dev...
22:22:31 <sgordon_> yeah agree
22:22:51 <sgordon_> not sure everyone wants their email on the public wiki though
22:23:04 <sgordon_> probably need to check with the three current raisers
22:23:23 <aveiga> that's fine, as long as we have some way to reach them during the discussion
22:23:32 <aveiga> just a suggestion, as IRC handle would work too
22:24:01 <sgordon_> #info need a way to make sure original use case submitter is involved in future discussion, need an irc nick or email along with the name on the wiki
22:25:46 <sgordon_> ok
22:25:50 <sgordon_> #topic Design and Implementation
22:26:05 <sgordon_> i wanted to circle back on a couple of things that are still being followed through from last cycle
22:26:16 <sgordon_> just from reviewing the dash at http://nfv.russellbryant.net/
22:26:26 <sgordon_> which is generated based on the list of BPs in the wiki
22:26:41 <sgordon_> #topic http://docs-draft.openstack.org/54/136554/1/check/gate-neutron-specs-docs/53623cb/doc/build/html/specs/kilo/nfv-vlan-trunks.html
22:26:48 <sgordon_> whoops
22:26:49 <sgordon_> #undo
22:26:50 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3916350>
22:26:56 <sgordon_> #link http://docs-draft.openstack.org/54/136554/1/check/gate-neutron-specs-docs/53623cb/doc/build/html/specs/kilo/nfv-vlan-trunks.html
22:27:12 <sgordon_> ian's BP with regards to VLAN trunking is still requiring iteration and comment
22:27:25 <sgordon_> this is the one for exposing whether or not the driver in use supports VLANs
22:27:39 <amitry1> sorry, going to have to drop to head to local openstackdc meetup
22:27:45 <sgordon_> so primarily a helper if you want to use them with e.g. LinuxBridge
22:27:53 <sgordon_> np amitry1 thanks for your time
22:28:01 <sgordon_> #link https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks
22:28:05 <sgordon_> #link https://review.openstack.org/#/c/136554/
22:28:46 <sgordon_> #topic Design and Implementation - ML2 port sec extension
22:28:53 <sgordon_> #link http://docs-draft.openstack.org/73/99873/14/check/gate-neutron-specs-docs/42051c8/doc/build/html/specs/kilo/ml2-ovs-portsecurity.html
22:28:59 <sgordon_> #link https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity
22:29:04 <sgordon_> #link https://review.openstack.org/#/c/99873/
22:29:27 <sgordon_> there have been some new comments on ML2 port security extension proposal i wanted to bring some attention to
22:29:51 <sgordon_> particularly praveen's comment on december 9
22:30:07 <sgordon_> w.r.t. potentially also removing the linux bridge from the networking path
22:30:11 <sgordon_> comments welcome!
22:30:33 <sgordon_> #topic Design and Implementation - cpu pinning and large pages
22:30:42 <sgordon_> the design for these was of course approved some time ago
22:30:54 <sgordon_> nova team at large have been working hard on implementation and code is up for review
22:31:05 <sgordon_> for those willing to help please see these topics:
22:31:07 <sgordon_> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fvirt-driver-large-pages,n,z
22:31:12 <sgordon_> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fvirt-driver-cpu-pinning,n,z
22:31:36 * sgordon_ pauses for a minute to take a breath
22:31:41 <sgordon_> any thoughts/comments on the above?
22:31:43 <cloudon> if pps through the network stack is the concern, agree removing the linux bridge helps, but still won't get you to anything ike the perf of a DPDK-accel vswitch
22:31:55 <sgordon_> i know that was a bit of a brain dump but i wanted to make sure we didn't lose sigh of these
22:32:00 <sgordon_> *sight
22:32:10 <sgordon_> cloudon, agree
22:32:42 <cloudon> also statement that service VMs won't need security support is... debatable
22:32:46 <sgordon_> cloudon, it also seems like optimizing before you know you need to optimize if that makes sense
22:32:53 <aveiga> cloudon: +1 to both points
22:33:04 <sgordon_> right
22:33:12 <aveiga> sgordon_: it's optimizing partially and removing a feature to do so
22:33:19 <cloudon> certainly some VMs may themselves be providing security functions (firewalls, SBCs etc.) but in general think doidgy assumption
22:33:22 <aveiga> i.e. not fully solving the problem
22:33:39 <sgordon_> #info some concerns about suggestion of removing LB from network path in ML2 spec proposal comments
22:33:50 <aveiga> sgordon_: don't use LB
22:33:54 <aveiga> that's overloaded :-P
22:34:00 <sgordon_> #undo
22:34:01 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x35fcb90>
22:34:19 <sgordon_> #info some concerns about suggestion of removing the linux bridge from the network path in ML2 port security spec proposal comments
22:34:22 <sgordon_> betterer?
22:34:23 <aveiga> that's better
22:34:38 <sgordon_> #info cloudon notes: 1) "if pps through the network stack is the concern, agree removing the linux bridge helps, but still won't get you to anything ike the perf of a DPDK-accel vswitch" 2) "also statement that service VMs won't need security support is... debatable"
22:35:02 <sgordon_> #info concern about balance of optimization versus effectively removing a feature
22:35:11 <sgordon_> anyway - i agree but just wanted to highlight that
22:35:25 <sgordon_> as it would if acted upon diverge a fair bit from the original idea as i understood it
22:35:41 <sgordon_> well maybe not diverge, but it seems like a significant additional change on top of what was proposed
22:36:05 <aveiga> I wonder if that should be filed as a bug against the eventual implementation instead
22:36:14 <aveiga> or maybe not bug, but feature request
22:36:16 <sgordon_> yeah or separate spec if required
22:37:24 <sgordon_> #info may be better suited to an additional bug or feature request against final implementation
22:37:28 <sgordon_> #topic other discussion
22:38:02 <sgordon_> i am not sure we have quorum for the next topic but jaypipes raised an important question on the etherpad that i want to discuss
22:38:13 <sgordon_> and is perhaps worth asking on M/L and discussing again next week as well
22:38:34 <sgordon_> #topic OPNFV and OpenStack overlap/divergence?
22:38:39 <cloudon> +1
22:38:44 <sgordon_> #info "From jaypipes: Why does there seem to be completely parallel and duplicative efforts and conversations going on in the OPNFV mailing lists and sites? What is going to be done to bring alignment between folks from OpenStack and folks from OPNFV working towards common goals?"
22:38:48 <sgordon_> i have noticed this too
22:39:41 <sgordon_> in that there seem to be an increasing number of cases where things pertaining to openstack design are being discussed on the opnfv list and not the openstack one
22:39:56 <sgordon_> or both lists are being added but the follow ups arent going to both in some cases
22:40:17 <sgordon_> now the reason i say we dont have quorum is i dont know how many people actively here today are also active in opnfv
22:40:33 <sgordon_> and are well placed to help us understand how to align these efforts
22:40:49 <zhipeng> do we have an official channel?
22:41:03 <aveiga> do we have overlapping members at all?
22:41:09 <zhipeng> i am
22:41:13 <zhipeng> for one
22:41:16 <cloudon> and me
22:41:45 <sgordon_> aveiga, yeah quite a few i think
22:41:51 <sgordon_> just unsure how many are on here today
22:42:03 * aveiga needs to join the club, apparently
22:42:28 <sgordon_> aveiga, i follow the tech list primarily
22:42:45 <zhipeng> maybe should bring this as an issue to the opnfv tsc
22:42:55 <sgordon_> zhipeng, yes i think so
22:43:09 <zhipeng> to have an official decision on how to collaborate
22:43:12 <sgordon_> primarily i think what jaypipes is trying to highlight and i agree with
22:43:15 <sgordon_> is that for success
22:43:23 <zhipeng> yep
22:43:25 <sgordon_> openstack design sessions have to happen in the openstack community
22:43:33 <aveiga> +1
22:43:39 <cloudon> +1
22:43:41 <sgordon_> and there appear to be cases with specific features and even entire projects in opnfv
22:43:43 <sgordon_> where this is not the case
22:44:02 <jaypipes> sgordon_: ++
22:44:29 <aveiga> I don't think we should ask them
22:44:49 <aveiga> I think we should tell them we'd like to see them participate where they exepct openstack functionality
22:45:09 <aveiga> you can't expect openstack devs to go out and follow another working group
22:45:27 <aveiga> and tehy can't expect to have it work without putting in the requests and discussing it with us
22:45:49 <sgordon_> i agree
22:45:58 <aveiga> this might have led to the large group of people in Paris asking about why things haven't happened yet
22:46:05 <sgordon_> i follow it more from the point of view of trying to steer things over here to openstack-land
22:46:55 <zhipeng> but it is also important for openstack nfv folks to follow progress in opnfv
22:47:01 <sgordon_> aveiga, i think there is also a frustration that some things keep getting raised on the openstack list and ignored (from the sender's perspective)
22:47:20 <zhipeng> at the end of the day the bulk of the work will be at opnfv
22:47:26 <sgordon_> zhipeng, i think the challenge is that opnfv need openstack devs
22:47:47 <sgordon_> but openstack devs dont necessarily need opnfv
22:47:52 <zhipeng> devs in opnfv are openstack devs actually :P
22:48:02 <zhipeng> what i meant is openstack nfv devs
22:48:10 <sgordon_> this is the disconnect
22:48:25 <sgordon_> there should not be a difference between an "openstack nfv dev" and an "openstack dev"
22:48:26 <zhipeng> since opnfv just doing integration
22:48:33 <sgordon_> yes
22:48:41 <sgordon_> but the concern raised is that it's not just integration discussions
22:48:45 <cloudon> zhipeng: not sure opnfv is just doing integ
22:49:09 <sgordon_> as an example
22:49:10 <sgordon_> https://wiki.opnfv.org/requirements_projects/doctor_fault_mangement_and_maintenance
22:49:42 <cloudon> and e.g. https://wiki.opnfv.org/requirements_projects/high_availability_for_opnfv
22:49:50 <sgordon_> that's not just integration, that's new requirements and designs for openstack
22:50:18 <sgordon_> and the problem i forsee is that these will be brought to the openstack community later having had little/no discussion there
22:50:37 <sgordon_> resulting in spec rejection or heavy iteration being required
22:51:29 <sgordon_> the servicevm thread is another example
22:51:33 <sgordon_> it was posted to both lists
22:51:39 <sgordon_> but the discussion is as a result completely forked
22:54:03 <r-mibu> sgordon, yes i have the same concern, but opnfv team have just started projects, so we need more time to identify requirement
22:55:01 <sgordon_> r-mibu, agree - i will take an action to try frame an email to highlight the concern nonetheless
22:55:32 <sgordon_> #action sgordon_ to attempt to frame an email to OPNFV tech lists highlighting the concern jaypipes raised wrt to alignment w/ openstack
22:55:47 <jaypipes> sgordon_: cheers
22:56:43 <sgordon_> i do think it's a real concern and could ultimately hurt opnfv
22:57:02 <sgordon_> #topic other business
22:58:12 <sgordon_> anyone have anything else for the  last few minutes?
22:58:13 <sgordon_> issues?
22:58:15 <sgordon_> concerns?
22:58:17 <sgordon_> good jokes?
22:58:26 <aveiga> sgordon_: beer'o'clock?
22:58:45 <sgordon_> yeah looking that way
22:58:54 <sgordon_> i am about to get rained in on my west coast trip i suspect ;)
22:59:10 <sgordon_> alright thank you all for your input!
22:59:12 <sgordon_> #endmeeting