05:30:10 #startmeeting taas 05:30:11 Meeting started Wed Jul 13 05:30:10 2016 UTC and is due to finish in 60 minutes. The chair is anil_rao. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:30:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:30:14 The meeting name has been set to 'taas' 05:30:35 hi 05:30:42 Hi 05:30:44 hi 05:31:15 #topic Finalize and submit Barcelona Summit Presentation proposal 05:31:54 hi 05:32:02 Hi 05:32:15 reedip: hi 05:32:50 reedip: thank you for your modification to abstract 05:32:57 soichi,reedip: I just saw your suggested modifications to the abstract 05:33:22 hi 05:33:23 soichi: it was minor 05:33:29 hi yamamot__ 05:33:35 one thing to keep in mind is that we have a 1000 character limit. The one I sent out yesterday was alerady at 995 chars. 05:33:57 I'll reword it some more tomorrow and incorporate the changes from both of you. 05:34:46 Hi yamamot__ 05:34:55 anil_rao: my proposal is minor modification, so you can ignore it 05:35:41 soichi: I think I can include it because it is a nice point. I'll just changes the words a little bit to make it all fit in 1000 chars. :-) 05:35:55 thank you 05:36:29 we need to ansewer two questions: 05:36:42 Yes, let's discuss this a bit. 05:36:43 lemme try and reword it 05:36:57 1) What is the problem or use case you're addressing in this session? 05:37:16 Reedip, I have it done mostly. so I'll make final adjustments just before submitting tomorrow morning. :-) 05:37:24 Umm, okay :) 05:37:45 soichi: We will elaborate that section by listing the following items. 05:38:12 anil_rao: I have shared the speaker details on the email (JFYI) 05:38:12 1. The plugin/agent/driver architecture which allows platform specific and vendor extension to be implemented. 05:38:28 reedip: Thanks you. :-) 05:38:58 2. The need for isolation between production and mirrored traffic in the underlay network and some techniques to address this. 05:39:16 3. Performance analysis and lessons learnt from it. Steps to improve performance going forward. 05:39:36 Any other thoughts? 05:41:00 It looks fine for me. 05:41:26 We should keep it light enough. Going to omuch into technicality can overload the users and operators in the audience 05:42:04 so I think we can keep the information limited the ones specified above 05:42:17 reedip: sounds good. 05:43:19 For the section on what attendees expect to learn, I was thinking about the following: 05:44:00 1. Discover that the TaaS architecture lends itself to multiple backend solutions to meet different needs. 05:44:52 2. Several service providers had indicated an interest in having a completely separate data path for monitored traffic. So now they can learn about how this may be achieved. 05:45:17 Others can also learn why separating the production and mirrored traffic can be beneficial for them. 05:45:49 3. The performance analysis is long overdue. We have been asked about TaaS performance during both our previous presentations. 05:46:13 are we going to provide a demo this time? oor a prersentation 05:46:45 vnyyad: I think we can skip a demo but provide real data from performance experiments. 05:46:57 ok. 05:47:01 what do you think? 05:47:13 anil_rao: agree 05:47:27 sounds good for me 05:47:43 anil_rao: sounds good 05:47:49 yes i guess going into more tech detaill of the solution to get more people develop back ends might be good 05:48:34 vnyyad: Yes will have a section on the plugin/agent/driver architecture showing how it facilitates writing vendor/platform specific backends. 05:48:48 that will be great 05:49:20 +1 05:50:03 Well, let's hope we get picked. :-) 05:50:15 sure 05:50:19 In the interest of full disclosure, we from Ericsson in partner with a customer have also submitted a tech talk on applying TaaS to monitor in Telco NFV 05:50:46 it sounds great! 05:50:50 but its purely application of taas as a solution 05:51:04 its in the telco track 05:51:17 vnyyd: We are submitting in the Network section so having a TaaS presentation in the Telco section is great! 05:51:34 yes.... that would be great! 05:52:00 we will have more representation one on the technical siide and the other on application of it 05:52:12 i think it is very noce to have a actical use case 05:52:22 noce -> nice 05:52:25 +1 05:53:26 soichi,kaz: Do you want to discuss the perf results you had posted a few weeks back? 05:54:27 excuse me, we can not have a time for prepearaton, so we would like to discuss next week. 05:54:49 kaz: Sure, no problem. We can cover that topic next week. 05:55:03 thank you. 05:56:06 i guess we should also bring up the agenda of separating data path for Taas in the comming metings as well 05:56:56 sure 05:57:47 currently, Kaz is working to implement by using flow based tunneling 05:57:47 thanks! 05:58:01 that is good 05:58:32 does that involve any tunneling protocol like GRE or VxLAN 05:59:04 VXLAN 05:59:16 ok thanks Kaz 05:59:47 so i guess the idea is to setup tunnels out of band to the existing overlay tunnels 06:01:23 i'm not sure, we will explain our design in next week IRC 06:01:28 anil: sorry for hijacking the discussion, please continue the agenda as proposed 06:01:43 soichi: sure... thanks 06:02:22 vnyyad: Our remaining agenda for today is Open Discussion so this is appropriate 06:02:30 #topic Open Discussion 06:03:47 We will also be working on a TaaS driver for VLAN based neutron network 06:04:25 so i guess a separate tunnel based datapath would be good to have for that as well 06:04:51 vnyyad: Yes. 06:07:30 We need to consider TaaS requirements from two angles: 06:07:48 1. Using the existing tunnels or separate tunnels for the overlay 06:08:18 2. Using existing interfaces or separate interfaces (and possibly a separate switching fabric) for the underly. 06:08:31 anil_rao: +1 06:08:35 +1 06:08:44 i guess flexibility to have both is the best 06:08:52 +1 06:08:57 +1 06:09:04 In some cases, it might be shared at one level but isolated at the other. In some cases it might be shared in both or even isolated in both. 06:11:05 +1 06:13:05 I have another topic. 06:13:12 Sure. 06:13:15 I think we need to examine the bug(?) report: 06:13:23 #link: http://lists.openstack.org/pipermail/openstack-dev/2016-July/098606.html 06:14:36 soichi: I am not sure if this happens when both VMs are on the same host. I know we have a problem when using a single-node setup and trying to reach a VM from outside the host. 06:15:16 soichi,kaz: I wanted to ask you this. Since your perf tests are done on a single node setup and you are passing traffic between two VMs on the same host you have it working correctly. 06:18:10 we modified a flow of TapFlow to disable "dl_vlan=..." 06:18:37 kaz: Thanks! 06:18:47 Let me look into this problem. 06:19:05 okay, thank you. 06:19:13 thanks 06:19:50 FYI, we are using the vlan check here because we didn't want to assume that mac address are unique across virtual networks that may be sharing a host. 06:20:47 thank you for your information 06:21:01 anil: +1 06:21:30 I'll check this out and if there is a problem try to get it fixed. 06:22:51 we will report if we find something new 06:23:16 soichi: Thanks 06:23:26 thanks 06:26:13 i have no more topic. 06:26:54 Look forward to next week's meeting to discuss perf and separate data-path for TaaS 06:27:03 sure 06:29:18 #endmeeting