14:02:42 <sgordon> #startmeeting telcowg
14:02:42 <openstack> Meeting started Wed Oct  7 14:02:42 2015 UTC and is due to finish in 60 minutes.  The chair is sgordon. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:45 <sgordon> #topic roll call
14:02:46 <openstack> The meeting name has been set to 'telcowg'
14:02:52 <cloudon> hello again
14:02:59 <sgordon> \o/ :D
14:03:39 * pc_m lurking
14:04:02 <sgordon> ok
14:04:07 <sgordon> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:04:16 <sgordon> #topic actions from last meeting
14:04:50 <sgordon> #info sgordon reached out to Mathieu about the "Adding BGP based IP VPNs attachment use case"
14:05:17 <sgordon> #info Mathieu is still interested in pursuing documentation of this but is also involved in the BGPVPN project to actually implement
14:05:41 <cloudon> remind me - did it identify any gaps?
14:05:47 <sgordon> #link http://git.openstack.org/cgit/openstack/networking-bgpvpn/
14:05:57 <sgordon> #link https://review.openstack.org/#/c/171680/
14:06:12 <sgordon> "The implementation can rely on Neutron service extension framework.	68
14:06:12 <sgordon> Two stackforge projects attempt to fill the gap :	69
14:06:12 <sgordon> http://git.openstack.org/cgit/stackforge/networking-bgpvpn	70
14:06:12 <sgordon> http://git.openstack.org/cgit/stackforge/networking-edge-vpn"
14:06:37 <sgordon> so as i understand it he is attempting to document the use case in parallel
14:06:59 <sgordon> adrian had asked in comments on the review for more clarity around this aspect
14:07:10 <sgordon> as a number of linked specs etc were abandoned
14:07:18 <sgordon> hence why i was prodding to see if it will be updated
14:08:09 <cloudon> ok, makes sense
14:09:09 <sgordon> #info meeting time slot
14:09:31 <sgordon> #info all meetings of telcowg now at 1400 UTC Wednesdays, no alternate time for now
14:09:52 <sgordon> #info can re-discuss if contributors from other TZs express interest again in the future
14:10:17 * sgordon grabbing link for next item
14:11:04 <sgordon> #info sgordon reached out to opnfv-tech-discuss about the Promise project and potential interaction with Product WG discussion around capacity management
14:11:07 <sgordon> #link http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-October/005677.html
14:11:37 <sgordon> #info minutes from first product wg meeting on this topic are available
14:11:43 <sgordon> #link http://lists.openstack.org/pipermail/product-wg/2015-October/000758.html
14:12:01 <sgordon> i mention this here again primarily because of the potential intersection with telco/nfv requirements
14:12:09 <sgordon> for capacity planning/control etc.
14:12:57 <cloudon> Judging from minutes looks like you got some traction on engagement?
14:13:16 <sgordon> yes a little
14:13:32 <sgordon> i would still welcome a few more contributors but will happily relay back review links etc when we have them
14:14:08 <sgordon> the process is fairly similar to what we use for use cases in this group (in part because it is at least somewhat modeled on the approach used here)
14:14:19 <sgordon> so there will be gerrit reviews etc
14:14:47 <sgordon> we need to tease apart the initial drafts that were created at the product wg mid-cycle
14:15:37 <sgordon> ok i think that is all the old AIs
14:15:45 <sgordon> #topic volunteers
14:16:08 <sgordon> as above i talked to mathieu about pushing BGP along
14:16:27 <sgordon> question is if we have any other use cases we can push along and move to RFEs/Backlogs
14:16:44 <sgordon> i did create a backlog spec for the vIMS affinity piece
14:17:11 <sgordon> cloudon, do i remember correctly that you were going to try handle for the SBC case?
14:17:13 <sgordon> #link https://review.openstack.org/#/c/176301/8/usecases/sbc.rst
14:17:34 <cloudon> thought we were waiting for some more reviews?
14:18:03 <cloudon> think we discussed a few meetings back about moving to RFE etc but suggestion was it needed more eyes on it first
14:18:08 <sgordon> yeah, it's not merged atm, though technically it does have two +2s
14:18:30 <cloudon> though as that's been followed by resounding silence I'm happy to move forward
14:18:36 <sgordon> perhaps i can forward it past some neutron/nova folks and see if it makes sense
14:18:42 <sgordon> to them
14:18:48 <sgordon> and if so merge it
14:18:53 <cloudon> that would be great
14:19:06 <sgordon> i think at this point it should be ok but that is how we can ensure it is all good
14:19:25 <sgordon> once that occurs i guess there are two aspects:
14:19:39 <sgordon> 1) confirming we're sure all the linked specs actually align with what is needed
14:19:49 <sgordon> 2) a backlog item for disabling connection tracking
14:19:57 <sgordon> make sense?
14:20:06 <cloudon> think so, yes
14:20:26 <cloudon> i can take the connection tracking item
14:21:11 <sgordon> #action sgordon to email nova/neutron developers about reviewing SBC use case
14:21:38 <sgordon> #action cloudon to handle raising a backlog spec or RFE bug for disabling connection tracking
14:21:51 <sgordon> assuming that this applies more to neutron, so probably RFE bug
14:22:11 <cloudon> ok
14:24:14 <sgordon> alright
14:24:40 <sgordon> i think if we focus on moving vIMS and SBC use cases along that is the main thing i wanted to cover
14:24:46 <sgordon> any other things to raise?
14:25:08 <cloudon> is Tokyo meet finalised?
14:25:16 <sgordon> in the next meeting i would like to try and address what we want to do with a session in tokyo (i will send a reminder to the list to try ensure attendance to discuss this)
14:25:17 <sgordon> yes
14:25:20 <sgordon> 2pm tuesday
14:25:29 <sgordon> it is in the sched.org calendar
14:25:31 <sgordon> :)
14:25:40 <cloudon> great
14:25:42 <sgordon> #link http://mitakadesignsummit.sched.org/event/b060647ccd40868b30ef2ab5cab76fda#.VfAyOLOf5ak
14:25:52 <sgordon> just 40 mins this time
14:25:58 <sgordon> so probably entirely working session
14:28:41 <sgordon> ok
14:28:44 <sgordon> thanks for your time!
14:28:46 <sgordon> #endmeeting