22:00:21 #startmeeting telcowg 22:00:22 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:25 The meeting name has been set to 'telcowg' 22:00:29 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup 22:00:34 #link https://etherpad.openstack.org/p/nfv-meeting-agenda 22:00:39 #topic roll call 22:00:50 o/ 22:00:50 who's around for the telco working group meeting? 22:01:01 hi cloudon, ijw, amitry 22:01:03 hi 22:01:09 hola 22:02:02 ok 22:02:07 #topic action items from last meeting 22:02:24 #info DaSchab was aiming to get an initial use case draft on wiki by end of next week 22:02:31 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Security_Segregation_.28Placement_Zones.29 22:03:03 the above use case regarding security segregation/placement zones was recently added to the wiki for review 22:03:56 #info rprakash was adding Mobile Network use case for GTP tunneling and will bring it next week 22:04:18 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 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 Well, more accurately, the idea of dedicated hosts is 22:05:07 right 22:05:34 i have not had a chance to review it specifically 22:05:42 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 but are we saying this is more broadly in scope for say win the enterprise? 22:05:56 (I'm skimming here so please tell me if I've misunderstood) 22:06:02 as am i :) 22:06:23 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 daschab is not here as i believe the other timeslot is when he is usually able to attend 22:06:45 (b) zones in different security domains on the network - probably something we should consider making recommendations about (in my instance, against) 22:06:46 yeah, i think it still makes sense to record the telco use cases for such to ensure they are catered to 22:07:31 So if we do stuff that's best-practice related I wonder where we put it? 22:07:50 barrett1, ^^ ? 22:07:59 yeah 22:08:23 i mean broadly the only current deliverable would arguably be the ops guide 22:08:29 DaSchab isn't around to discuss his side, I take it? 22:08:33 yeah 22:08:41 pretty sure he is EU based 22:08:42 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 could be wrong though 22:08:47 Best Practice info could get added into the OpenStack Ops Guide 22:09:04 cloudon kinda - more of a question is why you wouldn't just use multiple clouds 22:09:21 cloudon: I don't think AZs work because he's saying 'compute, network and storage are all divided' 22:09:37 ... and if they are then the only commonailty is actually keystone 22:09:41 Possibly glance 22:10:00 yup, fair points 22:11:50 #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 #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 ok 22:12:49 There's also a security guide, so it might be that the AZ best practice belongs there 22:12:49 #topic use cases 22:13:00 #topic use cases - service chaining 22:13:18 ybabenko took an action to provide a service chaining use case for us 22:13:24 #link https://etherpad.openstack.org/p/kKIqu2ipN6 22:13:32 this is currently recorded in the above etherpad 22:14:26 sorry, connection issue 22:14:47 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 #topic design and implementation 22:15:11 ijw, had a couple of specs approved of note just before the holiday season 22:15:18 #link https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks 22:15:24 #link https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement 22:15:51 the question i wanted to pose is whether there is any implementation to review at this point in time 22:16:00 Not yet. 22:16:08 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 vkmc, I guess I as early... 22:16:41 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 #info VLAN trunking and MTU advertisement/selection specs approved - implementation starting up atm 22:17:06 ijw, no problem - thanks for the update 22:17:31 the other item in the etherpad i wanted to highlight again was port mirroring... 22:17:33 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 #link https://blueprints.launchpad.net/neutron/+spec/port-mirroring 22:17:46 #link https://review.openstack.org/#/c/96149/ 22:18:06 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 but there has been a lot of back and forth on the spec review about this 22:18:34 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 ultimately trending towards debate over whether port mirroring belongs in core neutron or as an external service 22:18:43 yeah agree 22:18:46 Now, the proposal is that it gets implemented in Stackforge - but. 22:18:49 i think the naming also set it up for this outcome 22:19:13 (im referring to it as port mirroring but the proposal is actually tap-as-a-service) 22:19:40 ijw: question - "hard bit in ML2" == the ovs magic to setup the trunk ports ? 22:19:40 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 #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 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 right 22:21:02 ijw: yeah, for vlan-trunk. i'll check back on the trunk support in LB. thanks 22:21:04 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 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 yeah 22:22:20 i think im more interested in that side of it 22:22:31 "ok it's an extended service, what does that actually mean practically" 22:22:42 as you point out GBP team are no doubt hitting some of these issues first 22:22:47 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 But in this instance it might be possible with some minimal changes to core 22:25:06 let's pick this up when it comes around again 22:25:22 Can we also touch on cloud-edge stuff for a moment 22:25:23 ? 22:25:28 sure 22:25:47 then i want to loop back to use cases and the action item i didn't complete 22:25:49 ;) 22:26:07 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 #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 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 #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 #link https://wiki.openstack.org/wiki/Meetings/L2Gateway 22:27:46 including an API spec proposal by the looks 22:28:14 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 in its way 22:28:54 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 ... all done on that now, use case away ;) 22:29:44 ijw: fyi, hanif is the process of creating a stackforge project for mpls-vpn 22:30:16 #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 ^is in the process of^ 22:30:39 #info mpls-vpn stackforge project in the process of being created 22:30:52 SridharRamaswamy: cheers 22:31:01 ok 22:31:04 #topic use cases 22:31:13 SridharRamaswamy: as a service plugin or an independent process? 22:31:29 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 we have a couple to choose from at the moment 22:31:38 ijw: i believe they are leaning towards service plugin 22:31:50 again it is early in the discussion 22:32:05 some of these are discussed in the vpnaas weekly irc 22:32:16 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#VPN_Instantiation 22:32:25 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Session_Border_Controller 22:32:36 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Session_Border_Controller 22:32:43 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Virtual_IMS_Core 22:32:49 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Access_to_physical_network_resources 22:32:55 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Security_Segregation_.28Placement_Zones.29 22:33:05 and the two drafts referred to earlier 22:33:35 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 and try and drag out some requirements based on it 22:34:51 i will take silence as yes steve take that action item 22:35:04 #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 #topic ops summit 22:35:21 #link https://etherpad.openstack.org/p/PHL-ops-meetup 22:35:29 #undo 22:35:30 Removing item from minutes: 22:35:31 #undo 22:35:32 Removing item from minutes: 22:35:39 #topic ops midcycle meetup 22:35:42 #link https://etherpad.openstack.org/p/PHL-ops-meetup 22:36:06 +2 22:36:07 i wanted to highlight that comcast are hosting the operators midcycle meetup in philadelphia 22:36:13 on march 9-10 22:36:26 if there is interest from the group i would like to have a f2f session there 22:36:43 I think that would be great 22:36:52 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 +1 22:37:01 I already know several telco/sp that ate attending 22:37:04 so as well as a potential telco session 22:37:12 there are many others that would also likely be of interest 22:37:28 i would suggest reviewing the etherpad i linked above to get a feel for potential topics 22:37:33 I think a F2F would be great 22:37:58 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 I am coordinating with fifieldt_ , I will mention it as well 22:39:06 for anyone not aware this is the signup for the mailing list i am referring to 22:39:08 #link http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 22:39:21 yeah, i think it's a great opportunity 22:39:43 we should also think about framing how we would like to make use of that time 22:39:59 to me it would seem beneficial to again pick some use cases to drill down on 22:40:21 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 any thoughts as to the above? 22:42:55 use cases and how this group is working are good F2F topics 22:43:23 But how many of the folks who participate in this are attending? - if only like 5%... 22:43:23 maybe add outreach? getting the right groups involved as well 22:44:01 #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 #info Need to determine how many Telco WG participants are attending 22:44:24 margaret__, agreed - and i dont have a clear picture on that 22:46:19 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 Is there a way to take a survey using survey monkey on attendance and send this to the mailing list? 22:46:55 is attendance restricted to operators? 22:47:10 I can cross reference the signup lists and the telcowg 22:47:46 of course that will only show those who have signed up so far 22:47:56 cloudon: no 22:48:33 amitry, is signup actually open atm? 22:48:59 I don't think tom sent it out yet, should go live this week 22:49:42 we have a few details to sort out 22:49:56 yeah i think it was still pending 22:50:07 expect to see an eventbrite link or other instructions on the M/L 22:50:16 correct 22:50:27 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 ok, I will take that action item and can update here 22:50:41 can highlight to the group via email though 22:50:48 definitely 22:51:03 #action amitry to cross reference ops mid-cycle signups with telco wg participants to determine crossover 22:51:05 thanks for that 22:51:14 #topic other discussion 22:51:26 did anyone have anything else they wanted to bring up? 22:52:11 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 indeed 22:53:21 #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 did anyone have anything else they wish to raise today? 22:54:00 nothing else from, thanks steveg 22:54:04 I have to drop 22:54:05 silence mean no.. 22:54:10 i also have to run :) 22:54:15 by 22:54:18 bye 22:54:21 ok thanks all for your time and participation 22:54:26 #endmeeting