15:08:01 <Swami> #startmeeting Distributed Virtual Router
15:08:02 <openstack> Meeting started Wed Dec 11 15:08:01 2013 UTC and is due to finish in 60 minutes.  The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:08:07 <openstack> The meeting name has been set to 'distributed_virtual_router'
15:09:31 <Swami> hi Robin I got your email regarding your questions I will try to answer it and send you a reply by today
15:10:17 <Swami> #topic L2-L3 data sync
15:11:56 <Swami> Robin I did go through your WIP code, that suggests that we need to add flows in the ml2-ovs file, but my concern was to do that activity from the L3-agent. Mean that it should originate from the L3 Agent when a VM port is being added to the routed network
15:13:35 <Swami> Robin: you did mention in your email that we need a brain to store the data and push the data to all agents. I think in my view, it should be part of the L3-Plugin extension.
15:16:11 <Swami> So the plan would be when an L2 event occurs, that is when a port is added to a VM, L2 agent or the ML2-L2 drivers will then communicate the information to L3 agent residing in that node. The L3 agent should take necessary action on the data and also communicate the data to the plugin. The plugin should intern be pushing or syncing the data with other L3 agents that have been registered.
15:17:08 <Swami> I have updated the google doc, with information on what data need to be stored in the L3-plugin extensions.
15:18:17 <Swami> May be if you can spend some time how we can push the L2 data to L3 that would be great. Meanwhile I will also take a look at it.
15:18:28 <Swami> James Clark are you there.
15:19:12 <Swami> May be it might be too late for James to join the meeting.
15:20:09 <Swami> #topic L3 Support for Distributed versus the Edge
15:21:21 <Swami> I sent out an email couple of days back asking the community what would be right option from an API perspective to distinguish between a distributed router and an edge or centralized router.
15:21:46 <Swami> I was planning to use the "distributed" argument that is already in the router API.
15:23:06 <Swami> But I got some feedback on that, since L3 Plugin is also a service now, the community thinks that it should also behave like any other plugins to distinguish. So the community recommendation is to use the "provider" flag to distinguish the Routers.
15:24:04 <Swami> Some people also feel that why do we need to distinguish between a centralized router and distributed router. It is just implementation specific. Configuration wise it should be always a router.
15:24:46 <Swami> So we may have to close the loop on this issue.
15:25:47 <Swami> #topic North-South Proposal
15:26:00 <hemanthravi> Is the idea to use an option in  the config file for the plugin  implementing  the  L3 ext as opposed to specifying it in the API
15:26:19 <Swami> Hi hemanthravi
15:26:33 <hemanthravi> hi
15:27:39 <Swami> We were planning initially to use both the options. We will have config.ini file for the L3 agent configuring that local L3 agent as Distributed L3 Agent and also can use the API flag to configure the router as distributed
15:28:37 <Swami> But this was with the idea of having a mixed environment where you have both the centralized router and distributed router.
15:29:18 <Swami> But there may be some complications to it.
15:30:57 <Swami> So for the North-South proposal2 in the google doc, we do have the EG added to the router inbetween the External network and the routers.
15:31:37 <Swami> In order to add the EG, the tenant need to run an API or cli command to configure the EG and attach it to the external net.
15:32:08 <Swami> But it is slightly different than the current approach.
15:33:20 <Swami> So when we set a gateway to the router, today we only provide a external net id to the router, but in this proposal we might have to pass the EG id instead of the external net id.
15:33:32 <Swami> Each EG will be associated with an External net id.
15:34:31 <Swami> So we were planning to add two new API to address this issue. "distributed-router-gateway-set", and "distributed-router-gateway-create".
15:34:46 <hemanthravi> swami: will go through this in  the gdoc and comment if any
15:35:05 <Swami> hemathravi:thanks
15:35:22 <Swami> I will also update the google doc with the CLI command proposal.
15:36:46 <Swami> hemanthravi: sorry for ending the monday meeting quick. I need to run to another internal meeting, that's the reason
15:37:27 <hemanthravi> swami: will catch up later
15:37:44 <Swami> ok thanks
15:38:40 <Swami> Also the "distributed-router-gateway-set" command will accept a "list" or routers, Because there may be multiple routers associated with a single EG.
15:40:47 <Swami> Sylvain had a proposal for the north-south, as Edge L3 and centralized L3, I was not sure how he was planning to distinguish between the two. I will have  a chat with him and update it.
15:42:59 <Swami> Now I do have some concerns towards the new API, will that be acceptable by the community or their expectation might be not to change anything from the current API perspective for the routers.
15:44:11 <Swami> If anyone else have any ideas, please send me your comments.
15:45:06 <hemanthravi> If you go the config.ini option, will the APIs/cmds be the same as the current router
15:46:06 <Swami> hemanthravi: Even if we go with the config.ini option, the current proposal to split the EG from the router will create some new commands.
15:47:39 <Swami> Meaning we need to include the two new commands shown above, or else modify one existing command for the "router-gateway-set" to accept "EGs" as argument and also modify it to accept a list of routers.
15:50:02 <Swami> #topic services
15:50:21 <Swami> The last topic would be the services.
15:50:58 <Swami> we may have to consider our design to accomodate services. Certain services are distributable but certain services need to be centralized.
15:52:27 <Swami> We may have to configure routers as service router and non service routers.
15:52:40 <Swami> Service routers only should handle the services.
15:52:57 <Swami> Still more discussion need to happen in this area.
15:53:18 <Swami> #topic open discussion
15:54:29 <hemanthravi> swami: should the distributed nature of the service be left to the service api/impl
15:54:32 <Swami> I will keep investigating the options and will also talk to sylvain about his proposal and priorities. He mentioned that he already discussed with Mark McClain about the roadmap and priorities
15:54:41 <hemanthravi> similar to how the router is being distributed
15:55:17 <Swami> The problem there is a tenant will not want to distribute the VPN feature. Since it is a singleton function
15:56:31 <Swami> Yes it is possible that we can deligate the service work to the service team, but since it is currently tightly tied to the L3 agent, it should be addressed, If the service framework has the service insertion and service chaining framework nail down, then we can concentrate just on the L3.
15:57:24 <Swami> Ok, I think we are at the last minute.
15:57:56 <Swami> Thanks for attending the meeting. See you all next Monday. If you have any questions please feel free to shoot me an email.
15:58:07 <Swami> bye
15:58:10 <Swami> #endmeeting