22:01:00 <Swami> #startmeeting Distributed-Virtual-Router
22:01:01 <openstack> Meeting started Mon Oct 28 22:01:00 2013 UTC and is due to finish in 60 minutes.  The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:04 <openstack> The meeting name has been set to 'distributed_virtual_router'
22:01:16 <Swami> Hi all
22:01:20 <safchain> Hi
22:01:21 <geoffarnold> Hi
22:01:30 <jamiec> Hi
22:01:36 <carl_baldwin> Hi
22:01:38 <Swami> This is the session to discuss the Distributed Virtual Router
22:01:51 <jayahn> HI
22:01:58 <Swami> #link https://etherpad.openstack.org/p/Distributed-Virtual-Router
22:02:22 <Swami> Link to the Etherpad discussion page
22:03:08 <Swami> Is Robin Wang around
22:04:10 <Swami> Folks the plan here is to review the blueprints and to plan for the Hong Kong summit sessions
22:04:48 <nextone92> Hi guys!
22:04:54 <Swami> Does anyone have any questions
22:06:33 <Swami> #announcements This will be an ongoing discussion that will continue even after the summit
22:06:36 <EmilienM> Swami: do you  have some code ?
22:06:52 <EmilienM> I mean, basic code to show something at the summit ?
22:06:53 <nextone92> Based on the document, the primary reason for introducing the extension is too define a communication path between the brain and the dvr instances
22:07:12 <nextone92> is that a correct understanding?
22:07:45 <Swami> EmilienM: I don't think we need to submit any code for the summit
22:08:03 <geoffarnold> Not needed, but useful
22:08:07 <EmilienM> Swami: not submit, but a short demo of your thoughts i would mean
22:08:14 <geoffarnold> Demo is often good clarification
22:08:27 <Swami> In the summit we will discuss our ideas and proposals and then get the approval from the openstack community and prioritize the acitivities
22:08:31 <EmilienM> for example, we worked on VRRP features here, and we come with some basic code to accelerate design session
22:08:42 <EmilienM> Swami: make sense
22:09:52 <Swami> nextone92: Yes the primary reason for an extension is to get the data that we need to populate the brain. The brain will in turn populate the dvr instances through the Agent.
22:10:41 <geoffarnold> I'd really like to see more details on the use cases, especially those involving compliance and heterogeneous configurations
22:10:44 <EmilienM> so you want an agent
22:11:23 <Swami> geoffarnold: Thanks, yes we need more details on the use cases, and we will update the blueprint with the use case details.
22:11:32 <nextone92> what data do you need that's not part of routing data already, is it the which compute node hosts which vm?
22:12:06 <Swami> geoffarnold: The first release should target on the intra-tenant routing options.
22:12:43 <geoffarnold> I agree that intra-tenant is the sweet spot. Interoperation at the edge is where it gets tricky ;-)
22:13:09 <EmilienM> maybe something like "l3-population" ?
22:13:11 <Swami> nextone92: Yes that is one data such as the host to vm relationship, the other data that we need is to identify the VNI to the internal vlan assignment.
22:13:36 <geoffarnold> That's why nailing down the use cases (what's in and out of scope) is so critical
22:13:46 <ericloo> hi, i agreed with geoffarnold. we need to consider interoperating with edge is in the user case discussion.
22:13:57 <geoffarnold> And how it's expressed (both in API and operational policy)
22:14:01 <Swami> geoffarnold: yes, that is the reason for this discussion
22:14:09 <geoffarnold> Excellent
22:14:28 <nextone92> since not every vm interconnect uses vlan, will this be generic enough to work with vxlan or gre?
22:14:44 <Swami> Please feel free to add your input to the Etherpad that is created for the Distributed Virtual Router.
22:14:45 <geoffarnold> If you can pre-populate the ether pad with use case diagrams ahead of time, that will help
22:15:14 <Swami> How many of us will be there in Hong Kong next week.
22:15:23 <EmilienM> o/
22:15:28 <geoffarnold> Moi
22:15:39 <Swami> I will be there.
22:15:53 <nextone92> I will be there, soaking in all the info :)
22:15:54 <Swami> #action Swami: Add use cases to the Etherpad
22:15:54 * carl_baldwin will be there
22:15:57 <safchain> I'll be there
22:16:20 * haleyb as well
22:16:48 <jamiec> will be
22:17:06 <Swami> Currently the DVR session is scheduled for Friday November 8th at 11.a.m, but it is subjectable to change.
22:17:29 <Swami> The DVR discussion is going to be strictly "Etherpad" only. No slidedecks.
22:17:31 <ericloo> i will be there
22:17:38 <Rajeev> How long is the session ?
22:17:51 <Swami> Each session is around 50minutes
22:17:52 <nextone92> cool!
22:18:17 <rkukura> I'm not really involved in this yet, but am wondering if integrating it via the ML2 plugin makes sense?
22:18:21 <geoffarnold> Anyone planning any unconference activities in this space?
22:18:26 <safchain> We worked on a mechanism driver (l2population) which populates fdb entries to l2 agent, maybe it could be extended for that purpose
22:18:27 <jayahn> will be
22:18:32 <andrewkong> just for talking about use cases that not enough time
22:19:05 <geoffarnold> That's why I'd like an unconference on use cases ahead of the session if possible
22:19:16 <andrewkong> cool
22:19:25 <Swami> rkukura: Yes there are more L2 dependencies with the local routing so it will have some hooks into the L2 plugin.(ML2)
22:19:27 <jamiec> geoff: good idea
22:19:29 <EmilienM> safchain: that would totally make sense
22:19:30 <ericloo> i am ok with unconference to discuss
22:19:31 <Rajeev> safchain: does the mechanism driver have any datamodel extensions  too ?
22:19:35 <jayahn> unconference seems good idea
22:20:15 <Swami> geoffarnold: Thanks for bringing it up, yes before our session we need to plan for an unconference session so that we are well prepared on what we are planning to propose
22:20:24 <safchain> Rajeev, no datamodel extension, it only uses ml2 plugin
22:20:35 <Swami> #agreed Unconference
22:21:01 <rkukura> Would like to attend your session, but mestery and I will be doing a summit session on ML2 at the same time
22:21:09 <geoffarnold> Maybe finalize details at the Monday beer session that Mark is organizing
22:21:36 <geoffarnold> Flag that conflict to Mark. He's juggling
22:21:38 <Swami> rkukura: Yes I have already informed Mark mcClain about the conflict, since I have a conflict with a general session.
22:21:57 <Swami> So it would be changed
22:22:22 <Swami> I will let everyone know about the session timing once it is changed.
22:22:32 <rkukura> thanks
22:22:57 <nextone92> could you send a mailing list update when you finalize the time
22:23:07 <nextone92> thanks!
22:23:42 <Swami> #action Swami: Will let everyone know about the DVR timeslot
22:24:49 <Swami> DVR Plugin versus L3 Extension for DVR, which one do you guys perfer
22:25:33 <ericloo> i prefer DVR plugin
22:25:40 <Swami> geoffarnold: Sorry I will be missing the beer session since I will land late Monday evening in hong kong.
22:26:32 <geoffarnold> Plugin may be too high a level for complex configurations. This is starting to look like LBaaS pattern, with plugin/drivers
22:26:48 <andrewkong> i prefer l3 extention
22:26:51 <Swami> ericloo: So you mean that you would like to have a separate DVR plugin apart from the existing L3 Plugin.
22:27:19 <ericloo> yes, i prefer this way.
22:27:21 <geoffarnold> We need to bring in mastery et al to discuss L3 refactoring
22:27:24 <jamiec> swami: if you're asking about re-use of existing L3 - then that would be preferable if design allows
22:28:15 <geoffarnold> Trouble with reuse of existing L3 is that you wind up with stacked interceptors (as in DNRM prototype) which people hate
22:28:22 <geoffarnold> Clean refactoring is better
22:29:02 <Swami> geoffarnold: Extensions are quick to implement on top of the current L3-Plugin. But the agent need to be a different than the L3 agent.
22:29:19 <safchain> Maybe it is the time to refactor the existing l3 to have mechanism drivers like in the ml2
22:29:52 <Rajeev> geoffarnold, does either model make it easier to make brain aware of router events such as interface add ?
22:30:29 <geoffarnold> Yes
22:30:40 <geoffarnold> But that's not useful without more detail ;-)
22:31:06 <geoffarnold> That's why I come back to the use cases
22:31:52 <Swami> For simplicity the DVR will just do the local routing and this should be the target use case of our first release.
22:31:53 <geoffarnold> Apologies: I have to step away for a while.
22:32:46 <Swami> Any services associated with L3, such as LBaaS, VPN, External Net should be done at the Network Node.
22:34:08 <ericloo> makes sense
22:34:23 <Swami> Do everyone agree on the initial use case and assumptions
22:34:46 <nextone92> it's a good start!
22:34:58 <carl_baldwin> As the initial use case, yes.
22:35:03 <safchain> safchain, agree with the initial use case
22:35:27 <ericloo> Swami, one question, does security group rules on DVR as well?
22:36:02 <ericloo> sorry i meant DVR need to be aware of security group rules.
22:36:36 <Swami> Yes security group rules should still be supported at the DVR level. But definitely we are not targetting to support the FWaaS at the DVR.
22:36:46 <haleyb> Swami: i'd like to see External Net on the DVR as well... eventually
22:37:44 <Swami> haleyb: Yes we need to identify the use case for the External Net on the DVR
22:37:45 <ericloo> yes, haleyb's suggestion makes sense to me, it should be in the usercase.
22:38:31 <carl_baldwin> Security groups handled at the instance port, not l3.  Right?
22:38:36 <Swami> haleyb: Can you brief the use case that you are talking about have the External Net on the DVR
22:38:55 <haleyb> the simple example is that i have more tenants than bandwidth through a network node
22:39:30 <haleyb> it gets back to the old nova multi_host
22:39:47 <Swami> haleyb: This is like Network Node load sharing.
22:40:09 <jamiec> haleyb: that's pretty much our original use case as well
22:40:41 <jamiec> no network node at all
22:40:45 <haleyb> north-south in your drawing, in addition to east-west
22:41:11 <carl_baldwin> Ext-net at Dvr could reduce network hops and latency.
22:41:38 <carl_baldwin> But, I agree that intra-tenant is a good starting point.
22:41:52 <haleyb> agree
22:42:33 <ericloo> i think there is case that DVR need to interoperate with External Net router? maybe not in the first phase.
22:43:03 <Swami> Yes good suggestions, we can definitely take a look at what might take to have the Ext-net at the DVR level.
22:43:35 <Swami> My worry is if we have the Ext-net at the DVR, then the other services may also be at the DVR.
22:44:41 <safchain> the current l3 is a SPOF, I think the HA should alse be addressed in the case of ext-net at the dvr
22:44:57 <haleyb> As long as this initial change doesn't preclude that in the future i'm fine (the ext-net)
22:45:09 <ericloo> what other services? FW?
22:45:39 <Swami> #agreed For the first release let us just focus on the intra-tenant routing by the DVR
22:47:16 <Swami> #topic DVR scheduler
22:47:42 <Swami> Do we need a DVR agent scheduler similar to the L3 Agent scheduler
22:49:00 <ericloo> Swami, do u mean the brain scheduler? :)
22:49:12 <EmilienM> Swami: no, current implementation use Random only. We are working on a "Least Routers" scheduler which aims to schedule a router where a L3 hosts the least router number
22:49:30 <EmilienM> my patch is in progress
22:50:24 <carl_baldwin> Dvr should be scheduled on same host as port I think.
22:50:24 <Rajeev> The DVR agent would be present in each node so could be treated similar to L-2 agent as far as having a scheduler is concerned ?
22:50:28 <Swami> ericloo: yes
22:51:26 <safchain> I don't think we need a scheduler, we need to notify all the dvr agent, and let dvr do their job
22:51:54 <Swami> safchain: Thanks
22:51:57 <EmilienM> safchain: +1
22:51:59 <andrewkong> that's one way
22:52:28 <Swami> carl_baldwin: Yes the dvr should be scheduled on the host
22:52:39 <ericloo> from security perspective, i prefer to have a scheduler.
22:52:48 <EmilienM> safchain: 'all', does it scales ?
22:52:58 <EmilienM> just wondering
22:53:15 <andrewkong> @ericloo can you be more specific over your worries
22:54:01 <safchain> Swami, I'll add to the etherpad the blueprint link about l2population since the dvr design could be similar to the dvr design, agree ?
22:54:44 <safchain> I mean, regarding to the rpc calls
22:55:01 <Swami> nextone92: Sorry I missed your message, yes our dvr design should address vlans, vxlan and gre
22:55:03 <Rajeev> ericloo: can you please expand on how security is influenced by having scheduler?
22:55:27 <Swami> safchain: yes go ahead and add your blueprint.
22:56:16 <Swami> #topic OVS or LinuxBridge
22:56:55 <andrewkong> from the scale-out perspective, if one scheduler make every rpc call by the filter or algorithm, it will be performance bottleneck.
22:57:30 <Swami> For the first release we are planning to go with just the OVS support, does anyone have any concerns or preference of one over the other
22:58:38 <andrewkong> i prefer OVS and linuxbridge support at the same time :D
22:59:34 <Swami> andrewkong: why do you think you need both OVS and Linuxbridge at the same time, can't it be separated and added in the next release
23:00:21 <andrewkong> maybe i'm kind of selfish, i'm linux-bridge for our cloud ^^
23:00:30 <carl_baldwin> How much code can be common and how much needs to be plugin specific?
23:01:06 <EmilienM> l2-population work on both, i don't understand why for L3 we have to make a choice
23:01:36 <andrewkong> i think it's related with l2 layers DB
23:01:41 <Swami> carl_baldwin: Basically the hooks that we are planning to add for the DVR dataplane module will vary open using either Linux-bridge or OVS.
23:02:59 <Swami> EmilienM: This is basically we will be touching some OVS rules for packet forwarding and recieving.
23:03:26 <Swami> Folks I think we are out of time here.
23:03:48 <andrewkong> Really? common.. ^^
23:03:59 <Rajeev> Swami, thanks for organizing this meeting.
23:04:24 <safchain> Swami, yes thanks for the meeting
23:04:32 <Swami> Before I close the session, for persons who are visiting Hong Kong we need to discuss this in more detail before the summit session and I will send an update on time and day.
23:04:51 <Swami> Please feel free to add your inputs into the Etherpad and we will discuss the Etherpad in the session.
23:04:53 <EmilienM> Swami: let us know on the ML
23:04:56 <andrewkong> thank you for all.
23:04:59 <Swami> Thanks everyone for participating
23:05:26 <Swami> Next week there will not be a meeting at this time, but we can continue on the following week, week of Nov 11th.
23:05:35 <Swami> #endmeeting