14:00:13 #startmeeting telcowg 14:00:14 Meeting started Wed Mar 25 14:00:13 2015 UTC and is due to finish in 60 minutes. The chair is sgordon. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:17 The meeting name has been set to 'telcowg' 14:00:19 #link https://etherpad.openstack.org/p/nfv-meeting-agenda 14:00:25 #topic roll call 14:00:29 hi all 14:00:37 who is around for the telco working group meeting? 14:01:10 hi 14:01:25 hi 14:01:40 hi 14:01:43 hi 14:02:06 hi 14:02:06 #topic AIs from last week 14:02:23 hi 14:02:26 i dont see dcw around so will carry their action item over 14:02:32 #action dcw to draft SIP load-balancing use-case for wiki/etherpad initially, will need assistance with git submission 14:02:43 #info sgordon was to email list asking to divide up other existing use cases for git submission 14:02:46 so that didnt happen 14:03:04 the three i believe we need to convert from wiki/etherpad to RST are: 14:03:05 VPN Instantiation 14:03:05 Session Border Controller 14:03:05 Access to physical network resources 14:03:23 i can take access to physical network resources to convert 14:03:30 any other volunteers? 14:03:41 we need an wiki2rst tool :) 14:03:42 I can do SBC, but maybe not for next week 14:03:45 i can help to transfer a usecase from wiki to gerrit 14:03:50 #action sgordon to convert "access to physical network resources" to RST 14:03:56 I'm volunteering for the VPN Instantiation :) 14:04:03 i can take one 14:04:10 #action cloudon to convert SBC to RST 14:04:14 but someone need to tell me process:) 14:04:20 #action matrohon to convert VPN Instantiation 14:04:25 that covers the three i had 14:04:33 i suspect we have a couple of others linked in etherpads 14:04:37 so let me get back to you on that vks 14:04:39 :) 14:04:46 I already ported the session border controller I guess 14:04:50 ok after meeting of t fine with u 14:05:03 just needs to be refresehs with the new structrue 14:05:04 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Work_In_Progress 14:05:08 mkoderer, +1 14:05:11 thanks for that 14:05:16 "access to physical network resources" could also be done by the author. i already contacted him 14:05:23 DaSchab, ah cool 14:05:26 :) 14:05:47 #info Author of access to physical network resources use case can also be converted by the author 14:06:11 ...if not i will take care of it 14:06:16 so on that WIP page there were a couple of others in various states 14:06:26 Service Chaining, Orchestration, all the fun ones 14:06:27 sgordon, i remember a telco orchestration use use case 14:06:35 ;) 14:06:42 vks: yep this is not yet done :) 14:06:43 service chaining is an important one 14:06:54 ok will take 14:07:04 as there was already some interest on the dev list on revisiting this in the neutron design summit 14:07:09 sgordon: we will do service chaining hopefully today :) 14:07:09 as we head into Liberty 14:07:20 having concrete use cases will help guide that discussion 14:07:40 #action mkoderer and/or vks to convert service chaining use case to RST 14:07:58 perhaps mkoderer can do the initial conversion and then vks can help with comments/updates? 14:08:07 since i know mkoderer is familiar with the process already 14:08:07 hi 14:08:12 sgordon, fine 14:08:21 ok 14:08:24 ybabenko: will do it .. I am just the teacher :) 14:08:26 thanks all for the help with that 14:08:31 many hands make light work and all that 14:08:40 we will cordinate later :) 14:08:48 #topic use case reviews 14:08:50 https://review.openstack.org/#/q/status:open+project:stackforge/telcowg-usecases,n,z 14:08:50 hi, we plan to place the draft today or tomorrow on gerrit 14:09:08 still some updates on the vIMS and security segregation reviews 14:09:10 #link https://review.openstack.org/#/q/status:open+project:stackforge/telcowg-usecases,n,z 14:09:13 reviews welcome! 14:09:36 we need more reviewers! 14:09:43 for anyone not sure how to review i put some notes together here: 14:09:45 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Reviewing_Use_Cases 14:09:53 need some guinea pigs to see what i missed :) 14:09:55 I'll get my reviews in today 14:10:12 excellent 14:10:19 if you have any questions to the process just contact me or sgordon 14:10:24 +1 14:10:28 Sure thing 14:10:39 between us and aveiga there is someone to ask in #openstack-nfv most of the time 14:11:06 #info contact aveiga, sgordon, or mkoderer in #openstack-nfv if you are having issues submitting/reviewing use cases 14:11:18 #topic use case template 14:11:25 there were some minor updates to the template this week 14:11:30 mainly some syntax examples 14:11:48 i also have to add a user stories/personas section per the discussion at the mid-cycle 14:12:00 #action sgordon to add user stories/personas section to the template 14:12:21 sgordon: what is it about? 14:12:41 so the suggestion was we need to actually define the user 14:12:55 or more accurately probably the users or actors that are relevant 14:13:00 as there may be multiple 14:13:30 sgordon: ok do we have to change the existing use cases for that? 14:14:14 mkoderer, my personal opinion is it's not mandatory 14:14:15 mkoderer: let me know if you want to understand the VPN use case since i wrote it :-) 14:14:22 IMHO this can be optional? or we have a "general" definition for personas 14:14:24 but would be nice 14:14:46 that is i dont think we can retrospectively say "your use case sucks because it doesnt include this thing we hadn't thought of" 14:14:47 :) 14:14:58 margaret__: can you provide us your comment on SFC use-case? 14:15:07 margaret__ : I took the action to translate the VPN use case in RST 14:15:11 Sure I need to look at it 14:15:23 margaret__: that would be helpful :) 14:15:30 margaret__ : you surely can help me :) 14:15:38 matrohon: let me know if you want to have a call to talk about the VPN use case 14:16:04 my email is mchiosi@att.com 14:16:23 margaret__ : thanks, I'll email you 14:17:40 fwiw at margaret__'s prompting i had also put the template forward in the opnfv group 14:17:48 to try and ensure we're speaking the same language 14:18:09 the same template would ease up sharing alot 14:18:32 I think folks are fine with using the same template 14:18:34 indeed 14:18:47 i think everyone is pretty onboard with at least trying to use the same format 14:18:59 sgordon, +1 14:18:59 concerning VPN use cases, what do you think about trying to sum up work in progress in openstack, in the RST? 14:19:06 We are all tired of re-inventing the wheel :-) 14:19:07 thread here for those interested: 14:19:08 #link http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-March/thread.html#1525 14:19:34 matrohon, i think we have a section for that 14:19:40 matrohon: we have a "gap analysis" section for it 14:20:03 under "Affected By" 14:20:08 sgordon : great! 14:20:17 "If you are aware of any work in progress that will affect this use case, 14:20:18 please list it here. Include links to a spec or blueprint or bug report 14:20:18 where applicable." 14:20:31 so you can put in the use case both what's already in progress 14:20:35 and what's outstanding as a gap 14:20:44 ok, I've to get more familiar with the template :) 14:21:11 ok so back to topic :) 14:21:26 the final topic *I* had was the other meeting time 14:21:30 #topic meeting time 14:21:57 due to low attendance i want to move it somewhat earlier without going back to completely ignoring west coast US... 14:22:04 the gap im looking at atm is 1900 UTC - 3 PM EDT, Midday PST, 8 PM CET 14:22:13 (again, for the other time slot) 14:22:44 i will send a mail on this though since people who can only make the other slot - if they exist - will not be in this session in all likelihood 14:22:57 #action sgordon propose 1900 UTC - 3 PM EDT, Midday PST, 8 PM CET for other meeting time slot 14:23:17 thats a bad time for people from asia, i guess 14:23:25 yeah 14:23:27 sgordon, 1800UTC 14:23:34 DaSchab, correct 14:23:52 so idea is to stick to two different alternating slots? 14:23:56 vks, suggesting 1800 UTC instead of 1900 UTC? 14:24:05 mkoderer, that is an open question as well 14:24:22 i would be open to consolidating on just one but if we do that it probably has to be later than this slot 14:24:35 sgordon, for asia region 1900 UTC will be bit late 14:24:56 I personally like this slot :) 14:25:03 do we have currently people from asia working in the telcowg? 14:25:07 yeah this slot typically works better for me too 14:25:10 so im biased 14:25:10 mkoderer : me too :) 14:25:21 the maint thing is that with the the 2200 UTC slot we have now 14:25:28 it's basically me or anthony talking to ourselves 14:25:32 low to no attendance 14:25:34 mkoderer, +1 14:25:48 We may get more folks if we move the slot from asia. But to be fair there are alot of other projects they are engaged in fighting for the same time slots :-) 14:26:02 yes indeed 14:26:25 even from an openstack perspective there is a fair glut of meetings (even with four meeting rooms) at the ideal times 14:26:27 For OPNFV we have alot of asia - china mobile, huawei, ZTE, docomo, south korea 14:26:36 19 UTC works for me much better then 22 UTC... so +1 for it 14:26:52 let me take it to the list 14:26:53 +1 to 19 UTC 14:26:56 i think there are two proposals here 14:27:03 either a) move the alternate to 1900 UTC 14:27:10 or b) consolidate on this time slot 14:27:46 #action sgordon to post meeting timeslot proposal to list - either (a) move alternate meeting to 1900 UTC or (b) consolidate on the earlier time slot 14:27:51 #topic other business 14:28:10 so, does anyone have something else they would like to raise? 14:28:23 sorry i was a little late in joining the meeting today 14:28:30 i submitted a use-case - what’s next? 14:28:33 i apologize my attention is somewhat split today as im dealing with another meeting 14:28:36 dcw, excellent 14:28:41 dcw, do you have a link 14:28:51 dcw: thanks for that 14:28:54 https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases 14:29:21 ahh SIP Load-Balancer-as-a-Service 14:29:22 dcw: MNO/MVNO Use Case? 14:29:30 yes, SIP LBaas 14:29:31 #info dcw added SIP Load-Balancer-as-a-Service to wiki page 14:29:33 ah ok 14:30:00 #link https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#SIP_Load-Balancing-as-a-Service 14:31:04 dcw, so do you want some assistance converting that to RST format? 14:31:13 i believe this was what we discussed last week 14:31:33 i ca have a go - just wanted some early feedback if i was on the right track 14:31:54 in terms of the content and style 14:32:08 dcw: the review process works well for early feedback too 14:32:20 LB should start getting absorbed into the NFV platform and not a separate entity 14:32:39 In fact maybe the SDN controller should perform this... 14:32:44 dcw, it looks good on face value - as part of the review we can further tease out gaps 14:33:06 okay, i’ll try my hand at a git submission 14:33:46 dcw: if you have any issue with that contact us on #openstack-nfv 14:33:49 #action dcw will work on converting to RST In git 14:33:55 +1 again feel free to ask if you need help 14:34:12 What is the process on reviewing submissions? just update the etherpad? 14:34:29 margaret__: git 14:34:31 margaret__: it's the usual openstack review process 14:34:36 https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Reviewing_Use_Cases 14:34:55 like i said, looking for guinea pigs to see what steps i missed if any 14:35:04 margaret__: the etherpads and wiki entries are outdatet when we have started the review process 14:35:44 sgordon: I guess it would be a good idea to remove them 14:36:02 yeah with a pointer to the review entry 14:36:03 ok 14:36:28 agreed, it confusing to have three versions 14:36:38 #info once you have moved a use case to git, update the etherpad/wiki with the link (replacing the content) 14:37:01 we also need to publish the rst/html use cases somewhere 14:37:11 I need to talk to openstack infra about it 14:37:27 specs.openstack.org would be a quick solution 14:37:53 yeah 14:37:58 agree 14:37:59 but "specs" is a bit misleading 14:38:07 right 14:38:20 we could also talk to other user groups... may they want define use cases too 14:38:26 do you know if the api working group publishes somewhere? 14:38:27 like enterprise group etc.. 14:38:35 they are the main group using a similar process today 14:38:46 yes i actually put forward the template in WTE 14:39:13 jaypipes_: ^ any clue? 14:39:37 I think the api group doesn't have any use cases to publish? 14:39:50 not totally sure :) 14:39:50 not exactly 14:40:20 ok .. I will talk to jay later and ask him :) 14:40:28 I wonder what is the next step for those specs? should a patch, that partially implements a Telco spec, have a link to the spec in the commit msg? 14:40:30 they have their own repo 14:40:35 i thought they were publishing from it 14:40:45 mkoderer: not entirely sure... will get back to you on that (I always just go look at the formatted RST docs on github...) 14:40:54 matrohon, so in theory the use cases we build here 14:41:04 are ultimately to be used as the use case justification for a design spec 14:41:13 that is the idea anyway 14:41:46 sgordon : fine, seems reasonable 14:41:51 hopefully what we are creating is more detailed/accurate use cases to facilitate this 14:42:08 jaypipes_: thx for that 14:42:50 sgordon: matrohon: I guess we need at least one use case that goes trough the process and optimize it then 14:43:12 +! 14:43:15 +1 even 14:43:22 mkoderer: let us take security zones? 14:43:50 ybabenko: for me this use case is simple enought to test it :) 14:43:53 in the end this will be mandatory req for any ISP 14:44:30 how are we defining "take" here 14:44:38 since i believe the use case is up for review 14:44:39 :) 14:44:50 #link https://review.openstack.org/#/c/163399/ 14:44:57 sgordon: what do you mean by take? 14:45:07 im actually asking you 14:45:28 from my point of view in terms of actually teasing it out from here the more the merrier 14:45:35 sgordon: the idea to foucs on that review since it's a quite simple one 14:45:42 ok i agree with that 14:46:00 i think this one is very generally easy to understand for people without a telco background too 14:46:31 sgordon: I see ... we should pick a use-case which is common for majority of folks here (ISP, NSP, etc). 14:47:15 agree 14:47:47 any other topic? 14:48:20 appreciate all the discussion today folks 14:48:36 and also the many who volunteered for AIs! 14:48:41 :) 14:48:46 #endmeeting