15:12:58 <Swami> #startmeeting Distributed_virtual_router
15:12:59 <openstack> Meeting started Wed Dec  4 15:12:58 2013 UTC and is due to finish in 60 minutes.  The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:13:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:13:03 <openstack> The meeting name has been set to 'distributed_virtual_router'
15:13:32 <RobinWang> I've just replied your email
15:13:41 <Swami> #topic Distributed Virtual Router East-West Discussion
15:14:09 <RobinWang> I agree with choosing existing OVS infrastructure as our first step, to accelerate this feature
15:14:32 <Swami> Robin: For East West Distributed Router we are planning to move away from the Kernel Module
15:14:52 <Swami> #agreed
15:15:47 <RobinWang> I read previous meeting minutes and logs, glad to see that we moved forward far beyond just optimizing East-West Traffic
15:16:08 <Swami> Robin:Your prototype that you did for running the performance test includes the OVS infrastructure only is it right?
15:16:26 <RobinWang> yes, that's right
15:16:43 <Swami> Yes we wanted to consider both options and so we went forward investigating those options
15:16:45 <RobinWang> we leveraging ovs, and didn't add extra ovs br
15:17:12 <RobinWang> just
15:18:26 <RobinWang> Swami, r u still on line? I saw a quit information
15:18:54 <Swami> hi
15:19:05 <Swami> Robinwang; still there, I got disconnected
15:19:08 <RobinWang> hi
15:19:18 <RobinWang> I saw the info :)
15:19:45 <Swami> So my question was that, for the prototype that you did, do you have any WIP code that can publish
15:20:33 <RobinWang> sure
15:21:17 <RobinWang> the code is based on Grizzly, just a draft
15:21:27 <RobinWang> the mechanism is very simple
15:21:29 <Swami> That's ok,
15:21:43 <Swami> we can go through the code and then refactor the code for the Havana
15:21:55 <Swami> Also if we need to make any minor changes we can do that
15:22:41 <RobinWang> sure, but I think we might need some non-trivial changes on it
15:23:01 <RobinWang> however, the mechanism is the same
15:23:17 <Swami> yes, that's fine, I can review the code and then we can make changes if need
15:24:24 <RobinWang> as you pictured in spec doc, there should be a brain to store East-West routing info
15:24:39 <Swami> Also can you capture your design notes in the google doc or on the Wiki page so that we can add more content to it
15:24:58 <RobinWang> to make the POC simple, we didn't put it into l3-agent or some other places
15:25:16 <Swami> Yes, right now we were thinking of extending the L3 plugin to be the brain
15:25:35 <RobinWang> those info is maintained in ovs plugin
15:26:10 <RobinWang> I think we should figure out where is appropriate to put those data and implementing the logic
15:26:41 <Swami> Yes you are right, those are L2 parameters, but still we wanted to push it to the L3 plugin and store it
15:27:07 <RobinWang> #agree
15:27:13 <Swami> Yes, what you mentioned is also right, that we need to figure out what would be the right place to add those data.
15:28:08 <RobinWang> so for the 4 use cases, which one will we address first
15:28:38 <Swami> We are planning to address East-West first, North-South next and then the services
15:29:00 <RobinWang> cool
15:29:03 <Swami> Because as soon as we talk about the north south then we also need to include the services in it.
15:29:48 <Swami> But what I am also trying to do is, design for both East-West and North-South and then if the North-South is a low hanging fruit, then implement that as well
15:30:01 <RobinWang> for East-West, it is pretty straight forward, we just need to inject flow entry into ovs, to identify those traffic and then manipulate headers to achiieve one-hop thing
15:30:40 <Swami> Yes, you are right
15:30:50 <RobinWang> for North-South, how does it work?
15:31:41 <Swami> Robin: are you asking for the services how it would work.
15:32:35 <RobinWang> no, not the co-work between North-South routing and other services(LB/FW/VPN)
15:32:54 <RobinWang> what I wonder is, how we process North-South traffic in DVR
15:33:22 <RobinWang> the work flow as I mentioned for East-West above
15:33:34 <Swami> Yes, I have uploaded a picture in the "North-South" google doc regarding the design of the North South
15:34:17 <Swami> We were planning to add an additional "External Gateway router" to the tenant's router to do the job. The SNAT will happen on the EG
15:35:22 <RobinWang> I found the pic
15:35:32 <Swami> #link https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit
15:35:55 <RobinWang> could you explain how it works
15:38:43 <Swami> This would be the same model that we are planning to use for the East west as well, but without the additional EG. We may or may not have the additional bridge, but in discussion right now.
15:41:08 <RobinWang> I also see Edouard's review "local ARP responder"
15:41:14 <Swami> When a tenant is trying to add an external gateway to the router, we will be adding or creating the EG and then the connection between the IR and EG is established with an virtual eth pair. The EG will have an internal private address space in the 169.x.x.x range. Each tenant will have an EG in the compute node
15:41:24 <RobinWang> is this related to North-South DVR
15:42:14 <Swami> Yes Edouard already has a local ARP responder on the OVS, we can utilize it or else we can also add a rule in the OVS to do the arp functionality
15:43:42 <RobinWang> " Each tenant will have an EG in the compute node", does it mean that on each compute node, there's at least one EG?
15:44:23 <Swami> Yes, you are right.
15:45:05 <RobinWang> what about the mac of those EG?
15:45:51 <Swami> Yes, it will also have a unique mac
15:48:01 <RobinWang> since they have the same mac, when a North-South traffic comes from the outside world, how to guarantee those packet go to the correct EG on a specific compute node?
15:49:04 <Swami> Robin:No I did mention that they will have unique mac and unique floating IP on the compute node
15:49:32 <RobinWang> sorry :)
15:49:57 <RobinWang> I mis-understood it
15:50:38 <RobinWang> with unique mac and FIP, it should work well
15:50:46 <Swami> ok, I will add more details to that doc
15:51:46 <Swami> also I am refining the plugin and agent architecture and once it is solid I will update the doc, meanwhile for this week, can you push the code that you have done on the "OVS plugin", I need to take a look at it or else update your doc or wiki with the required information
15:52:25 <RobinWang> OK
15:53:05 <Swami> #action Swami will update the North South doc with more details on the plugin/agent architecture
15:53:31 <Swami> #action Robin will push the WIP code for review by the subteam
15:54:04 <Swami> Robin does this timeslot works good for you
15:54:17 <RobinWang> yes
15:54:58 <Swami> ok, then if you have any questions or concerns, please feel free to send me an email and we can discuss those items in the IRC meeting.
15:55:14 <RobinWang> Sure :)
15:55:38 <Swami> once you upload the wip code send me an email, and I can go and review it
15:56:39 <Swami> ok, thanks for attending the meeting. We will meet next week.
15:56:45 <RobinWang> OK, doc may come faster than refining and merging code :)
15:56:47 <Swami> any other questions
15:56:56 <RobinWang> See you
15:57:05 <Swami> Yes, we can do it together so don't worry we can speed up the process
15:57:26 <Swami> ok, bye
15:57:29 <Swami> #endmeeting