22:05:05 #startmeeting Distributed Virtual Router 22:05:06 Meeting started Mon Nov 25 22:05:05 2013 UTC and is due to finish in 60 minutes. The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:05:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:05:09 The meeting name has been set to 'distributed_virtual_router' 22:05:20 hi all 22:05:47 Hi Swami 22:05:54 Hi safchain 22:06:20 Back in US after hectic travel 22:06:55 #topic Announcement 22:12:41 hi 22:12:53 I got dropped 22:13:38 #topic Plugin versus Extension 22:14:21 I would like to discuss the options of Plugin versus an Extension for the DVR 22:14:48 safchain do you have any input 22:15:05 do you mean service plugin like l3 ? 22:15:21 safchain: yes 22:15:49 So the question is, extend the l3 or add a new service plugin 22:16:01 safchain: yes 22:18:15 maybe a extension, since it is not really a new service it is more an optimization, but not sure I have to think about it 22:18:41 Swami, what is your thoughts ? 22:18:56 Yes, that is my opinion too, adding an extension would be simpler than creating a new service plugin. 22:19:41 do you have any plan to submit any part of your code from your poc ? 22:20:15 especially the kernel module ? 22:20:32 Just to give you an update, we are trying to do some change to our design with respect to the kernel module 22:21:21 Since it would be a time consuming process to push the kernel module upstream, we are now looking at other alternatives to solve the DVR problem. 22:22:22 The approach that we are looking into is using the OVS and adding an additional bridge inbetween the br-int and br-tun. 22:24:28 ok, could you add something about this solution to the gdoc 22:24:40 hi, I'm here by accident, but I'd like to find out more about DVR 22:24:53 is there any documentation beyond the blueprint? 22:25:32 Swami, I would like to understand the usage of the new bridge 22:25:34 Makdaam: Yes we are trying to add more to the documentation that we have out there as blueprint. 22:26:21 safchain: Yes I will update the Google doc, that we have created for the north-south dvr discussion and then probably we can go over the design in our next meeting 22:27:17 The idea here is add a bridge "dvr-br" inbetween the br-int and br-tun. Use the existing L3 namespace implementation to add routers to the compute Node. 22:28:24 Swami, we also worked on the north-south design 22:28:34 Router interfaces will connect to the new bridge "dvr-br" and not to the "br-int". Then we apply the rules in the OVS to direct packet to the Router. 22:29:02 I would have expected a br-ex and connect to that, same as a network node 22:29:10 safchain: If you have any picture for your design can you also share with our google doc. 22:29:27 here is the design, maybe we could combine yours with ours 22:29:37 #link https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit 22:30:26 https://docs.google.com/drawings/d/1GGwbLa72n8c2T3SBApKK7uJ6WLTSRa7erTI_3QNj5Bg/edit 22:30:34 lifeless: Yes we are considering br-ex for the north-south as well. 22:32:00 safchain: Do you have any write up on your diagram 22:32:17 If not we can arrange for a meeting to discuss your design and our design 22:32:36 lifeless: bug about new networks: https://bugs.launchpad.net/neutron/+bug/1254555 22:32:38 Launchpad bug 1254555 in neutron "tenant does not see network that is routable from tenant-visible network until neutron-server is restarted" [High,In progress] 22:32:39 Swami, it seems I'm not able to modify your gdoc 22:32:50 salv-orlando: you are right, the tempest option controls the size of the tenantt network and you were talking about the public net 22:33:02 SpamapS: Etoolate :) 22:33:28 could you check permission, I would like to add a link to our design 22:34:08 safchain: I have changed the privilege for anyone to edit the document 22:34:16 Swami, thx 22:34:26 safchain: so please go ahead and add your thoughts or ideas. 22:34:44 oh that was the previous meeting sorry. ;) 22:34:55 Just added a link 22:35:12 safchain: Thanks for the link 22:36:16 safchain: What would be the best time for me to talk to you regarding your north-south design and we can share our ideas. 22:36:51 Swami, the idea here is to combine the l3 ha BP and to bring a vrouter to each compute when a floating-ip is added 22:37:44 So in your design, does each compute node have a different floating IP or the same floating IP 22:37:47 Swami, just ping me tomorrow same time this meeting 22:38:05 different floating ip 22:38:20 safchain: Ok I will ping you tomorrow 22:38:27 Swami, great 22:39:35 safchain: In this case are you planning to modify L3 Agent ( In other words are you planning to extend the L3 Agent ) 22:40:50 Swami, for the HA VRRP BP, we are planning to extend the l3 agent, and for the l3 at compute, we are planning to add a new agent 22:41:32 but it's not sure for the new agent, still in design 22:42:18 safchain: you mentioned that you are planning to add a new agent for compute node L3, can't just extend the L3 agent. Is there any specific reason or issue for creating a new agent. 22:43:12 Swami, no, maybe just extending the l3 agent would be enough 22:44:03 safchain, yes we were also debating on a new agent versus extending the L3 Agent. 22:44:22 And we have to take care of this blueprint https://blueprints.launchpad.net/neutron/+spec/l3-agent-consolidation 22:45:12 Yes that makes sense 22:45:23 I add the link to the gdoc 22:46:46 safchain: Thanks 22:47:27 safchain: In your vrouter approach are you planning to add any OVS rules to direct the packet flows? 22:48:33 no 22:49:42 Swami, just ebtables rules 22:50:35 probably with the help of this patch which will help to implement an arp response for the l2 population with OVS 22:51:00 https://review.openstack.org/#/c/49227/ 22:52:50 So in this patch, the OVS bridge acts as an arp responder and you are utilizing in your vrouter implement to prevent the arp from getting out of the compute node. 22:53:10 yes, correct 22:54:11 In this case for the vrouters in the compute node, are you having a unique MAC or having same MAC on all the compute node instances 22:55:02 an unique mac with this design 22:56:08 When you assign a unique mac for the router port is it assigned from the default MAC pool or do you have separate MAC pool just for this purpose. 22:57:57 Swami, I think we need to work a little bit more on this design, so I don't have all the details right now 22:58:48 safchain: Thanks for the information, I will ping you tomorrow same time and we can go over our proposals. 22:59:17 Swami, yes that will be nice 22:59:26 I will also update the google doc with our proposal for our discussion. 22:59:39 ok thanks 23:01:00 Ok, this week I will not be having the Wednesday meeting, but from Next week, I will have both meetings. 23:01:16 Thank you all 23:01:28 Thank you Swami 23:01:30 #endmeeting