15:02:59 #startmeeting distributed_virtual_router 15:03:00 Meeting started Wed Feb 12 15:02:59 2014 UTC and is due to finish in 60 minutes. The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:04 The meeting name has been set to 'distributed_virtual_router' 15:03:07 yes, sorry couldn't get on earlier 15:03:30 jamiec_: its ok, if you joined the meeting at the right time. 15:03:40 ping safchain 15:03:55 ping Robin wong 15:04:11 ping amuller 15:04:17 Swami: I wasn't able to write up my VRRP A/A idea in time, but I was hoping to present it concisely just so people are aware of it when considering DVR 15:04:23 amuller: Hi 15:04:56 amuller: are you going to present today in this meeting. 15:04:59 yes 15:05:21 is it different than the safchain vrrp idea 15:05:37 It's an extension / a second blueprint depending on safchain's blueprint 15:05:45 it relies on his bp 15:06:09 what I am asking is, for the DVR is it different than the safchain blueprint that uses the vrrp 15:06:21 It's different but the ideas are related 15:06:31 And they can solve the same issues 15:06:38 So it's worth considering I think 15:07:05 ok, let me tell you one thing. We have a meeting tomorrow and this would be the dry run to discuss what we are going to present in that meeting to the global audience 15:07:14 Right 15:07:20 I understand I'm coming in late 15:07:30 Yes you are too late. 15:07:49 hi 15:08:12 But what I would suggest is, send us a copy of your blueprint and we can take a look at it. Next week we can have a discussion and see what are the pros and cons and then evaluate. 15:08:18 hemanthravi: hi. 15:08:38 #agenda F2f dry run and update on the blueprint changes. 15:09:15 Swami: I'll do that 15:09:25 #link https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit 15:09:48 Hi folks I would like to go over the blueprint changes with you folks, the link to the document is pasted above. 15:10:35 swami: added some comments to the doc last night, some of them might be due lack of info on my par 15:10:36 t 15:10:37 amuller: yes thanks, that would help. I don't want to de-rail our efforts at this time. 15:12:05 hemanthravi: I will take a look at your comments and then probably answer your comments. 15:12:25 Ok let me discuss the high level changes that had happend in our blueprint. 15:12:41 #info Blueprint change 15:13:06 We have split the routing, floating and SNAT. 15:13:55 The routing functionality will be distributed across the compute Nodes and each router will run in its own namespace in the compute node. 15:14:48 The SNAT functionality for external connectivity will be centralized and be part of the Service Node or the Legacy Network Node. 15:15:52 Swami: just the SNAT? floating still on the compute? 15:16:04 The reason we wanted to split the SNAT functionality and make it centralized is to get rid of the "IP Address consumption" in each and every node for the SNAT and also to provision the singleton services such as "VPN router" in the Service node or Legacy Network node. 15:16:24 jamiec_: Is I am coming there, let me finish the SNAT part. 15:16:29 ok 15:17:48 For FloatingIP we are providing Floating IP at the Compute Node Level, but the FloatingIP will be allocated and provisioned in its own namespace. Each compute node will have "a" flaotingIP namespace that will be shared by all tenants. 15:19:03 So by splitting the "SNAT", floatingiP and routers we are now able to provide "East-West routing" and "North-South" routing without affecting any of our services. 15:19:34 ping safchain 15:19:46 Swami, Hi, sorry to be late 15:19:57 safchain: it is ok. 15:20:46 I was just briefing the change that we did to our blueprint to logically merge with your ideas on splitting the Floatingip and SNAT from the router. 15:21:01 safchain: I am not sure if you had a chance to look at the changes that I did to the doc. 15:21:22 Swami, yes I did 15:21:37 swami: in the current network-node impl, don't snat and floating-ip use the same addr? 15:21:57 in the non dvr case 15:22:37 hemanthravi: Yes, but in our model, the SNAT will consume one IP Address and the Floating IP, where ever it is enabled will be consuming an IP address from the external pool. 15:23:41 In the doc that I updated, you can see there are couple of "Admin" level API changes that we have proposed, and that is purely for legacy L3 migration. 15:24:19 jamiec_: did I answer your question. 15:24:42 Swami, yes only small changes, which is a good thing 15:24:46 Swami: yes, thank you - clear now 15:24:56 makes sense 15:25:41 safchain: We might have to sync up on the "Arp" proxy implementation. 15:26:47 Currently we are not dependent on the OVS arp proxy implementation, but we are preventing arp, and populating arp table from our agent. But if we all wanted to use the "ovs" arp proxy with the ml2-pop we can use it. 15:27:15 Swami, edouard did lot of work around that, arp responder on ovs and work on an ebtables wrapper 15:28:30 Swami, https://review.openstack.org/#/c/49227/ ARP responder on OVS for l2 pop 15:28:31 safchain: Thanks I might have to sync up the edouard on the timeline and delivery for the arp responder on ovs, 15:29:48 safchain: For tomorrow's meeting I would like to have the agenda as a follow up from the "Hong Kong" summit. 15:30:31 Swami, not sure to be able to attend tomorrow, i'll try 15:31:08 I would like to present it, saying that we presented a DVR blueprint for the Icehouse summit with just "East-West", community wanted to address "North-South" as well and aslo don't like the kernel module solution. 15:31:59 So we went back and safchain: had a norht-south solution and we had a east-west solution and we came up with this solution that addresses both north-south and east-west. 15:32:40 safchain: If you could not make it, I will make sure that I will also bring up your doc for discussion with the audience. 15:33:03 Swami, ok thx 15:34:18 #info Tomorrow for the F2F there will be a change in the Conference Room, since more people are attending I booked a bigger room. This room will be "Building 20" Palo Alto HP Office. I will send out the details and directions. 15:36:20 Also the other information about the doc update, we would be using just a single agent which will be a superset and based on the config option the agent will behave either distributed router agent, floatingip agent or the default SNAT agent aka legacy L3 agent. 15:37:55 In the model that has been proposed, services such as "LBaaS" will not have any issue. FWaaS should be implemented in all compute Node routers, since we are doing East-West. This will not be a problem since we are using the same L3 agent and if required we can make changes to fix any issues. 15:39:22 I might have a question for the community to address the "VPN service". There should be a way to identify that specific router so that we can deploy that router in the "Service node/legacy network node". 15:40:18 #action After this meeting if you have any questions please feel free to add your comments to the google doc and I will try to answer the questions. 15:41:03 #acton amuller: Please share your doc with us next week so that we can have a discussion on your suggestion. 15:41:26 #action amuller: Please share your doc with us next week so that we can have a discussion on your suggestion. 15:41:48 Absolutely :) 15:41:49 I have a hard stop at 7.45, so if you have any other questions please let me know. 15:42:50 I have a question 15:42:55 should I ask here, or in the doc itself? 15:43:37 I have very little time here, but go ahead and ask the queston if I cannot answer here I will address it in the document. 15:43:43 ok 15:44:10 I'll write it on the document itself 15:44:16 ok 15:44:19 I actually need time to make the question :) 15:44:24 thanks Swami 15:44:35 thanks guys for taking your time. 15:44:48 thank you Swami 15:44:50 see you all next week. 15:45:02 thanks Swami 15:45:15 bye all 15:45:21 Buhbye 15:45:27 #endmeeting