22:05:05 <Swami> #startmeeting Distributed Virtual Router
22:05:06 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:05:09 <openstack> The meeting name has been set to 'distributed_virtual_router'
22:05:20 <Swami> hi all
22:05:47 <safchain> Hi Swami
22:05:54 <Swami> Hi safchain
22:06:20 <Swami> Back in US after hectic travel
22:06:55 <Swami> #topic Announcement
22:12:41 <Swami> hi
22:12:53 <Swami> I got dropped
22:13:38 <Swami> #topic Plugin versus Extension
22:14:21 <Swami> I would like to discuss the options of Plugin versus an Extension for the DVR
22:14:48 <Swami> safchain do you have any input
22:15:05 <safchain> do you mean service plugin like l3 ?
22:15:21 <Swami> safchain: yes
22:15:49 <safchain> So the question is, extend the l3 or add a new service plugin
22:16:01 <Swami> safchain: yes
22:18:15 <safchain> 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 <safchain> Swami, what is your thoughts ?
22:18:56 <Swami> Yes, that is my opinion too, adding an extension would be simpler than creating a new service plugin.
22:19:41 <safchain> do you have any plan to submit any part of your code from your poc ?
22:20:15 <safchain> especially the kernel module ?
22:20:32 <Swami> 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 <Swami> 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 <Swami> 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 <safchain> ok, could you add something about this solution to the gdoc
22:24:40 <Makdaam> hi, I'm here by accident, but I'd like to find out more about DVR
22:24:53 <Makdaam> is there any documentation beyond the blueprint?
22:25:32 <safchain> Swami, I would like to understand the usage of the new bridge
22:25:34 <Swami> Makdaam: Yes we are trying to add more to the documentation that we have out there as blueprint.
22:26:21 <Swami> 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 <Swami> 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 <safchain> Swami, we also worked on the north-south design
22:28:34 <Swami> 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 <lifeless> I would have expected a br-ex and connect to that, same as a network node
22:29:10 <Swami> safchain: If you have any picture for your design can you also share with our google doc.
22:29:27 <safchain> here is the design, maybe we could combine yours with ours
22:29:37 <Swami> #link https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit
22:30:26 <safchain> https://docs.google.com/drawings/d/1GGwbLa72n8c2T3SBApKK7uJ6WLTSRa7erTI_3QNj5Bg/edit
22:30:34 <Swami> lifeless: Yes we are considering br-ex for the north-south as well.
22:32:00 <Swami> safchain: Do you have any write up on your diagram
22:32:17 <Swami> If not we can arrange for a meeting to discuss your design and our design
22:32:36 <SpamapS> lifeless: bug about new networks: https://bugs.launchpad.net/neutron/+bug/1254555
22:32:38 <uvirtbot> 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 <safchain> Swami, it seems I'm not able to modify your gdoc
22:32:50 <mlavalle> 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 <lifeless> SpamapS: Etoolate :)
22:33:28 <safchain> could you check permission, I would like to add a link to our design
22:34:08 <Swami> safchain: I have changed the privilege for anyone to edit the document
22:34:16 <safchain> Swami, thx
22:34:26 <Swami> safchain: so please go ahead and add your thoughts or ideas.
22:34:44 <SpamapS> oh that was the previous meeting sorry. ;)
22:34:55 <safchain> Just added a link
22:35:12 <Swami> safchain: Thanks for the link
22:36:16 <Swami> 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 <safchain> 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 <Swami> So in your design, does each compute node have a different floating IP or the same floating IP
22:37:47 <safchain> Swami, just ping me tomorrow same time this meeting
22:38:05 <safchain> different floating ip
22:38:20 <Swami> safchain: Ok I will ping you tomorrow
22:38:27 <safchain> Swami, great
22:39:35 <Swami> 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 <safchain> 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 <safchain> but it's not sure for the new agent, still in design
22:42:18 <Swami> 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 <safchain> Swami, no, maybe just extending the l3 agent would be enough
22:44:03 <Swami> safchain, yes we were also debating on a new agent versus extending the L3 Agent.
22:44:22 <safchain> And we have to take care of this blueprint https://blueprints.launchpad.net/neutron/+spec/l3-agent-consolidation
22:45:12 <Swami> Yes that makes sense
22:45:23 <safchain> I add the link to the gdoc
22:46:46 <Swami> safchain: Thanks
22:47:27 <Swami> safchain: In your vrouter approach are you planning to add any OVS rules to direct the packet flows?
22:48:33 <safchain> no
22:49:42 <safchain> Swami, just ebtables rules
22:50:35 <safchain> probably with the help of this patch which will help to implement an arp response for the l2 population with OVS
22:51:00 <safchain> https://review.openstack.org/#/c/49227/
22:52:50 <Swami> 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 <safchain> yes, correct
22:54:11 <Swami> 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 <safchain> an unique mac with this design
22:56:08 <Swami> 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 <safchain> 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 <Swami> safchain: Thanks for the information, I will ping you tomorrow same time and we can go over our proposals.
22:59:17 <safchain> Swami, yes that will be nice
22:59:26 <Swami> I will also update the google doc with our proposal for our discussion.
22:59:39 <safchain> ok thanks
23:01:00 <Swami> Ok, this week  I will not be having the Wednesday meeting, but from Next week, I will have both meetings.
23:01:16 <Swami> Thank you all
23:01:28 <safchain> Thank you Swami
23:01:30 <Swami> #endmeeting