22:00:21 <steveg> #startmeeting telcowg
22:00:22 <openstack> Meeting started Wed Jan  7 22:00:21 2015 UTC and is due to finish in 60 minutes.  The chair is steveg. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:25 <openstack> The meeting name has been set to 'telcowg'
22:00:29 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup
22:00:34 <steveg> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
22:00:39 <steveg> #topic roll call
22:00:50 <ijw> o/
22:00:50 <steveg> who's around for the telco working group meeting?
22:01:01 <steveg> hi cloudon, ijw, amitry
22:01:03 <cloudon> hi
22:01:09 <amitry> hola
22:02:02 <steveg> ok
22:02:07 <steveg> #topic action items from last meeting
22:02:24 <steveg> #info DaSchab was aiming to get an initial use case draft on wiki by end of next week
22:02:31 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Security_Segregation_.28Placement_Zones.29
22:03:03 <steveg> the above use case regarding security segregation/placement zones was recently added to the wiki for review
22:03:56 <steveg> #info rprakash was adding Mobile Network use case for GTP tunneling and will bring it next week
22:04:18 <steveg> i got sent a draft of this via email in ODT format, im just confirming that it's ok to upload to the wiki
22:04:27 <ijw> It's not telco-specific, it's a fairly common requirement in enterprise cases too given that you might e..g have requirements to keep financial data separate
22:05:01 <ijw> Well, more accurately, the idea of dedicated hosts is
22:05:07 <steveg> right
22:05:34 <steveg> i have not had a chance to review it specifically
22:05:42 <ijw> The question of whether you would divide a cloud with a single control plane among multiple security levels of network - that's a matter of taste, but I wouldn't, I would consider it a violation of airgap security between your DNZ and the more secure bits of the network
22:05:46 <steveg> but are we saying this is more broadly in scope for say win the enterprise?
22:05:56 <ijw> (I'm skimming here so please tell me if I've misunderstood)
22:06:02 <steveg> as am i :)
22:06:23 <ijw> I think (a) zones of differing workload security: yes, it's not telco-specific, but we may want to put our name to it
22:06:24 <steveg> daschab is not here as i believe the other timeslot is when he is usually able to attend
22:06:45 <ijw> (b) zones in different security domains on the network - probably something we should consider making recommendations about (in my instance, against)
22:06:46 <steveg> yeah, i think it still makes sense to record the telco use cases for such to ensure they are catered to
22:07:31 <ijw> So if we do stuff that's best-practice related I wonder where we put it?
22:07:50 <steveg> barrett1, ^^ ?
22:07:59 <steveg> yeah
22:08:23 <steveg> i mean broadly the only current deliverable would arguably be the ops guide
22:08:29 <ijw> DaSchab isn't around to discuss his side, I take it?
22:08:33 <steveg> yeah
22:08:41 <steveg> pretty sure he is EU based
22:08:42 <cloudon> might be a dumb qn as just skimming it too, but can this not be achieved by using host aggregates to represent the placement zones?
22:08:44 <steveg> could be wrong though
22:08:47 <barrett1> Best Practice info could get added into the OpenStack Ops Guide
22:09:04 <ijw> cloudon kinda - more of a question is why you wouldn't just use multiple clouds
22:09:21 <ijw> cloudon: I don't think AZs work because he's saying 'compute, network and storage are all divided'
22:09:37 <ijw> ... and if they are then the only commonailty is actually keystone
22:09:41 <ijw> Possibly glance
22:10:00 <cloudon> yup, fair points
22:11:50 <steveg> #info (a) zones of differing workload security: yes, it's not telco-specific, but worth tracking and recording telco use cases thereof
22:12:07 <steveg> #info (b) zones in different security domains on the network - probably something we should consider making recommendations about - best practices --> ops guide?
22:12:39 <steveg> ok
22:12:49 <barrett1> There's also a security guide, so it might be that the AZ best practice belongs there
22:12:49 <steveg> #topic use cases
22:13:00 <steveg> #topic use cases - service chaining
22:13:18 <steveg> ybabenko took an action to provide a service chaining use case for us
22:13:24 <steveg> #link https://etherpad.openstack.org/p/kKIqu2ipN6
22:13:32 <steveg> this is currently recorded in the above etherpad
22:14:26 <ijw> sorry, connection issue
22:14:47 <steveg> let me circle back to use cases in a second though, i wanted to skip ahead to check up on current design/impl items while ijw is still available
22:14:56 <steveg> #topic design and implementation
22:15:11 <steveg> ijw, had a couple of specs approved of note just before the holiday season
22:15:18 <steveg> #link https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks
22:15:24 <steveg> #link https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement
22:15:51 <steveg> the question i wanted to pose is whether there is any implementation to review at this point in time
22:16:00 <ijw> Not yet.
22:16:08 <ijw> It'll get done in stages and it probably won't be me doing all of it, but our lot should take care of it
22:16:22 <dneary> vkmc, I guess I as early...
22:16:41 <ijw> I'll try and get a first bit up in the next week or so (particularly if I can find someone who actually understands Neutron DB migrations, cos that's changed quite a bit since the last time I workd with it)
22:16:48 <steveg> #info VLAN trunking and MTU advertisement/selection specs approved - implementation starting up atm
22:17:06 <steveg> ijw, no problem - thanks for the update
22:17:31 <steveg> the other item in the etherpad i wanted to highlight again was port mirroring...
22:17:33 <ijw> Was thinking, in both cases, that I'd do DB, then API, then default behaviour (since they both have fallback behaviour for unsupported plugins) and then the hard bit in ML2
22:17:41 <steveg> #link https://blueprints.launchpad.net/neutron/+spec/port-mirroring
22:17:46 <steveg> #link https://review.openstack.org/#/c/96149/
22:18:06 <steveg> it's unclear to me how much concern there is within the group about the above spec, it's been on our list for a fair while
22:18:18 <steveg> but there has been a lot of back and forth on the spec review about this
22:18:34 <ijw> Architecturally I'm not a fan of the approach that the guys chose, but that aside, they basically put that spec up far too close to the review deadline and it unfortunately got canned.
22:18:39 <steveg> ultimately trending towards debate over whether port mirroring belongs in core neutron or as an external service
22:18:43 <steveg> yeah agree
22:18:46 <ijw> Now, the proposal is that it gets implemented in Stackforge - but.
22:18:49 <steveg> i think the naming also set it up for this outcome
22:19:13 <steveg> (im referring to it as port mirroring but the proposal is actually tap-as-a-service)
22:19:40 <SridharRamaswamy> ijw: question - "hard bit in ML2" == the ovs magic to setup the trunk ports ?
22:19:40 <ijw> That's kind of fine from the perspective of the API it needs, but, even with an OVS implementation, you'd need to do *something* to the OVS driver to support port mirroring, and that's not easily done without changing the Neutron code to add a feature.  Kyle seems to think that's OK, I'm not sure it would actually be accepted if we tried it
22:20:08 <steveg> #info port mirroring/tap-as-a-service spec not approved for kilo, questions about implementation outstanding and whether functionality belongs in neutron core or as an external advanced service project
22:20:19 <ijw> SridharRamaswamy: VLANs?  Read the spec, it doesn't affect behaviour, just reports it.  You have to determine if all your drivers support VLAN trunking (OVS doesn't - use Linuxbridge instead)
22:20:39 <steveg> right
22:21:02 <SridharRamaswamy> ijw: yeah, for vlan-trunk. i'll check back on the trunk support in LB. thanks
22:21:04 <ijw> The spec leaves the door open to modifying the OVS driver to support trunking but doesn't actually make that change - because it's hard and of questionable value when LB just works
22:22:00 <ijw> steveg: I'd say port mirroring is probably not on the cards for Kilo even as an extended service, but on the other hand it might be worth our time to investigate what we would actually need to change to make it possible
22:22:12 <steveg> yeah
22:22:20 <steveg> i think im more interested in that side of it
22:22:31 <steveg> "ok it's an extended service, what does that actually mean practically"
22:22:42 <steveg> as you point out GBP team are no doubt hitting some of these issues first
22:22:47 <ijw> A different sort of vif-plug might be all we'd need (attach a second interface to the same port and get a mirrored versino of the traffic, e.g.) so that an self-contained service could be used with it
22:23:41 * ijw prefers the idea of services as independent processes with independent HTTP endpoints, which is not the current Neutron thinking with regards to the existing advanced services at the moment
22:23:54 <ijw> But in this instance it might be possible with some minimal changes to core
22:25:06 <steveg> let's pick this up when it comes around again
22:25:22 <ijw> Can we also touch on cloud-edge stuff for a moment
22:25:23 <ijw> ?
22:25:28 <steveg> sure
22:25:47 <steveg> then i want to loop back to use cases and the action item i didn't complete
22:25:49 <steveg> ;)
22:26:07 <ijw> Just a quick report on two fronts - firstly, the MPLS and edge networking proposals both stalled, so if they happen they'll be in stackforge and there's no sign of that for either right now
22:26:52 <steveg> #info  MPLS and edge networking proposals both stalled, so if they happen they'll be in stackforge and there's no sign of that for either right now
22:26:54 <ijw> And secondly, there's now an L2Gateway team - their definition of L2 gateway is a programmable virtual-network-to-outside gateway, probably initially for VLANs only - and that's meeting on Mondays, there's another one next week
22:27:14 <steveg> #info recently formed L2Gateway team - definition of L2 gateway is a programmable virtual-network-to-outside gateway, probably initially for VLANs only - and that's meeting on Mondays, there's another one next week
22:27:27 <steveg> #link https://wiki.openstack.org/wiki/Meetings/L2Gateway
22:27:46 <steveg> including an API spec proposal by the looks
22:28:14 <ijw> I would argue that the second is another sub-case of the first, personally, and we should take a co-ordinated approach.  The L2GW guys just want something that works and have a moderate-to-large API tailored very specifically to their mental model of devices doing the gatewaying.  It may be possible to resolve the two but they're sceptical of doing anything that gets in the path of a straightforward implementation, which is fair
22:28:14 <ijw> in its way
22:28:54 <ijw> Plan is to put down the use cases on the wiki for L2 gateways of all types so that we can at least say what we are addressing and what we are not addressing with an initial release
22:29:24 <ijw> ... all done on that now, use case away ;)
22:29:44 <SridharRamaswamy> ijw: fyi, hanif is the process of creating a stackforge project for mpls-vpn
22:30:16 <steveg> #info need to consolidate use cases for L2 gateways of all types so that at least which are/aren't being addressed can be stated
22:30:32 <SridharRamaswamy> ^is in the process of^
22:30:39 <steveg> #info mpls-vpn stackforge project in the process of being created
22:30:52 <ijw> SridharRamaswamy: cheers
22:31:01 <steveg> ok
22:31:04 <steveg> #topic use cases
22:31:13 <ijw> SridharRamaswamy: as a service plugin or an independent process?
22:31:29 <steveg> so the action item, which i did not complete, was to email out to kick off discussion about picking a use case to do a more in depth review of
22:31:36 <steveg> we have a couple to choose from at the moment
22:31:38 <SridharRamaswamy> ijw: i believe they are leaning towards service plugin
22:31:50 <SridharRamaswamy> again it is early in the discussion
22:32:05 <SridharRamaswamy> some of these are discussed in the vpnaas weekly irc
22:32:16 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#VPN_Instantiation
22:32:25 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Session_Border_Controller
22:32:36 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Session_Border_Controller
22:32:43 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Virtual_IMS_Core
22:32:49 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Access_to_physical_network_resources
22:32:55 <steveg> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Security_Segregation_.28Placement_Zones.29
22:33:05 <steveg> and the two drafts referred to earlier
22:33:35 <steveg> i propose to send out a brief survey monkey to the list and we select one to review at next week's meeting in detail
22:33:47 <steveg> and try and drag out some requirements based on it
22:34:51 <steveg> i will take silence as yes steve take that action item
22:35:04 <steveg> #action steveg to send out a brief survey monkey to the list and we select one to review at next week's meeting in detail
22:35:09 <steveg> #topic ops summit
22:35:21 <steveg> #link https://etherpad.openstack.org/p/PHL-ops-meetup
22:35:29 <steveg> #undo
22:35:30 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x3d6ab90>
22:35:31 <steveg> #undo
22:35:32 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3d2ead0>
22:35:39 <steveg> #topic ops midcycle meetup
22:35:42 <steveg> #link https://etherpad.openstack.org/p/PHL-ops-meetup
22:36:06 <amitry> +2
22:36:07 <steveg> i wanted to highlight that comcast are hosting the operators midcycle meetup in philadelphia
22:36:13 <steveg> on march 9-10
22:36:26 <steveg> if there is interest from the group i would like to have a f2f session there
22:36:43 <amitry> I think that would be great
22:36:52 <steveg> for those not familiar this is an opportunity for openstack operators in general to get together and discuss their needs, use of openstack, share solutions etc
22:36:59 <cloudon> +1
22:37:01 <amitry> I already know several telco/sp that ate attending
22:37:04 <steveg> so as well as a potential telco session
22:37:12 <steveg> there are many others that would also likely be of interest
22:37:28 <steveg> i would suggest reviewing the etherpad i linked above to get a feel for potential topics
22:37:33 <margaret__> I think a F2F would be great
22:37:58 <steveg> fifieldt_ from the foundation is currently setting things up, i would expect to see more details about it via the operators list in the near future
22:38:34 <amitry> I am coordinating with fifieldt_ , I will mention it as well
22:39:06 <steveg> for anyone not aware this is the signup for the mailing list i am referring to
22:39:08 <steveg> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
22:39:21 <steveg> yeah, i think it's a great opportunity
22:39:43 <steveg> we should also think about framing how we would like to make use of that time
22:39:59 <steveg> to me it would seem beneficial to again pick some use cases to drill down on
22:40:21 <steveg> and also have some time split off to discuss what's working/what isn't and take a general checkpoint on how people feel about the group and the way it works
22:42:29 <steveg> any thoughts as to the above?
22:42:55 <margaret__> use cases and how this group is working are good F2F topics
22:43:23 <margaret__> But how many of the folks who participate in this are attending? - if only like 5%...
22:43:23 <amitry> maybe add outreach? getting the right groups involved as well
22:44:01 <steveg> #info Opportunity for F2F at operators mid-cycle meetup - potential topics are use cases, how the group is/isn't working, outreach
22:44:11 <steveg> #info Need to determine how many Telco WG participants are attending
22:44:24 <steveg> margaret__, agreed - and i dont have a clear picture on that
22:46:19 <steveg> any ideas as to how to ascertain other than a broad email asking how many are planning to attend, or would plan to attend if there was a telco session?
22:46:49 <margaret__> Is there a way to take a survey using survey monkey on attendance and send this to the mailing list?
22:46:55 <cloudon> is attendance restricted to operators?
22:47:10 <amitry> I can cross reference the signup lists and the telcowg
22:47:46 <amitry> of course that will only show those who have signed up so far
22:47:56 <amitry> cloudon: no
22:48:33 <steveg> amitry, is signup actually open atm?
22:48:59 <amitry> I don't think tom sent it out yet, should go live this week
22:49:42 <amitry> we have a few details to sort out
22:49:56 <steveg> yeah i think it was still pending
22:50:07 <steveg> expect to see an eventbrite link or other instructions on the M/L
22:50:16 <amitry> correct
22:50:27 <steveg> i think cross referencing them is as accurate a read of who is actually going to show up as we will get
22:50:40 <amitry> ok, I will take that action item and can update here
22:50:41 <steveg> can highlight to the group via email though
22:50:48 <amitry> definitely
22:51:03 <steveg> #action amitry to cross reference ops mid-cycle signups with telco wg participants to determine crossover
22:51:05 <steveg> thanks for that
22:51:14 <steveg> #topic other discussion
22:51:26 <steveg> did anyone have anything else they wanted to bring up?
22:52:11 <steveg> barrett1, it isn't reflected in the wiki but i believe you are holding an ecosystem and collateral meeting tomorrow?
22:52:19 * steveg may have his wires crossed, checking calendar
22:52:49 <steveg> indeed
22:53:21 <steveg> #info Ecosystem and Collateral Meeting 12 PM US EST / 9 AM US PST January 8th - Access: (888) 875-9370, Bridge: 3; PC: 7053780
22:53:39 <steveg> did anyone have anything else they wish to raise today?
22:54:00 <amitry> nothing else from, thanks steveg
22:54:04 <amitry> I have to drop
22:54:05 <margaret__> silence mean no..
22:54:10 <steveg> i also have to run :)
22:54:15 <margaret__> by
22:54:18 <margaret__> bye
22:54:21 <steveg> ok thanks all for your time and participation
22:54:26 <steveg> #endmeeting