15:01:08 <Swami> #startmeeting distributed_virtual_router
15:01:09 <openstack> Meeting started Wed May 21 15:01:08 2014 UTC and is due to finish in 60 minutes.  The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:13 <openstack> The meeting name has been set to 'distributed_virtual_router'
15:01:25 <Swami> Hi Folks,
15:01:42 <Swami> hope everyone enjoyed the summit
15:01:46 <carl_baldwin> Swami: hi
15:02:19 <Swami> viveknarasimhan: hi
15:02:47 <Swami> #topic Agenda
15:03:00 <Swami> mrsmith: hi
15:03:07 <Swami> betsy: hi
15:03:10 <Swami> asomya: hi
15:03:11 <viveknarasimhan> hi
15:03:23 <Swami> DVR Progress Update
15:03:24 <asomya> hello
15:03:39 <Swami> #topic DVR Progress Update
15:03:58 <mrsmith> Swami: hi
15:04:06 <Swami> Last week we were all in the summit and did not make any progress forward
15:04:43 <Swami> We are currently working on fixing a bulk of unit test issues that we are facing with the L3-plugin
15:04:59 <mrsmith> Swami: all? :)
15:05:24 <Swami> Since it touches almost all the plugins we are addressing the unit test issues that might eat a lot of out time.
15:05:24 <mrsmith> good progress was made by some on the icehouse-ga merge
15:05:51 <Swami> #topic DVR Extension for L3
15:06:43 <Swami> Based on the summit discussion, I had a chat with Mark McClain and Kyle regarding the DB model design for the DVR
15:07:41 <Swami> Instead of creating a separate attribute extension for the "Distributed" flag in "routers" table, we decided to move the "distributed" flag right into the "routers" table and keep this flag to "false" by default.
15:08:16 <Swami> That way we don't need to maintain this attribute going forward.
15:08:50 <Swami> Based on the above mentioned change I will be refactoring the existing code and will be also addressing the Unit test cases for this.
15:09:16 <Swami> Hope this is not an issue for any of the members here.
15:10:15 <Swami> #topic L3 Update
15:10:20 <Swami> mrsmith: any updates
15:10:48 <mrsmith> just that we got basic E/W functionality working on icehouse-ga
15:11:00 <mrsmith> n/s needs more refactoring (again)
15:11:19 <mrsmith> and as you say, we have a "debt" of unit tests failures that we need to refactor/fix
15:11:48 <Swami> mrsmith: Thanks for the update
15:12:16 <Swami> #topic L2 Agent
15:12:27 <Swami> viveknarasimhan: do you have any updates
15:12:40 <viveknarasimhan> hyes
15:12:49 <viveknarasimhan> i posted the next patch set for L2 side upstream
15:12:57 <viveknarasimhan> after addressing review comments
15:13:09 <viveknarasimhan> there are still a few pep8 issues given by tox which i am working on
15:13:22 <viveknarasimhan> also i posted fix for l2-pop bug which got review approvals
15:13:28 <viveknarasimhan> but vendor CI tests are failing
15:13:49 <viveknarasimhan> i need help from community on what will it take to merge that fix: https://review.openstack.org/#/c/93624/
15:14:08 <viveknarasimhan> that fix is mandatory for basic l2-pop (and so for dvr as well)
15:14:48 <Swami> viveknarasimhan: It has been already reviewed.
15:15:00 <viveknarasimhan> yes
15:15:11 <Swami> It should not be an issue to merge this fix into the Juno branch.
15:15:12 <viveknarasimhan> core reviewer Edgar gave +2
15:16:13 <Swami> Yes vivek, send a mail to Kyle as well and tell him that you are waiting on this patch to be fixed since your work has a dependency.
15:16:42 <viveknarasimhan> ok i will do
15:16:52 <viveknarasimhan> i sent two mails to maru newby, but didn't get response
15:17:00 <viveknarasimhan> sent a message to him on IRC as well.
15:17:20 <Swami> viveknarasimhan: Everyone might be settling down after the summit, so wait for another couple of days.
15:17:59 <Swami> You just need two cores approval, please send a message to Kyle and he will request the respective cores to take a look at it.
15:18:08 <Swami> viveknarasimhan: thanks for the update.
15:18:19 <Swami> #topic Services and DVR
15:18:37 <viveknarasimhan> ok thanks
15:18:45 <Swami> Folks there were a couple of questions that came up in the Neutron design session for the DVR regarding the Services
15:19:15 <Swami> So  I would like to start a regular discussion on the services that would be affected by DVR and how to address those issues.
15:19:57 <Swami> I have requested the respective Services team members to be part of the DVR team, so that they can provide their feedback and also participate in the addressing the issues.
15:20:40 <Swami> #topic DVR and LoadBalancer
15:21:07 <Swami> I don't think today Loadbalancer service will be impacted by the DVR.
15:21:40 <Swami> It should work as expected, but we need to test and validate in a DVR scenario the loadbalancer is working as expected.
15:21:52 <Swami> #topic DVR and Firewall as a Service
15:22:37 <Swami> There was some concerns that was raised about the FWaaS and its statefull behavior.
15:24:45 <Swami> Today when we router intra VM traffic the packet touches the router only on one side and the other side it does not touch the router. Since the FWaaS is applied in the interface ports of the router, there was some concerns raised. So both the teams should come up with a solution to resolve this issue.
15:25:20 <Swami> We have spoken to "Yi' and he mentioned that he would be joining our team meeting to discuss and taking it forward.
15:25:28 <yisun> Swami, I’m here
15:25:37 <Swami> yisun: hi
15:25:39 <viveknarasimhan> one second
15:25:54 <viveknarasimhan> when we route the packet in DVR, the source router routes teh packet
15:26:01 <carl_baldwin> Swami: That is a good and valid concern.  With DVR, each direction of two-way traffic is routed on a different machine.
15:26:04 <viveknarasimhan> so the fwaas rules must have hit both sides
15:26:42 <viveknarasimhan> though each direction is routed on different machines, teh routers on the machines are the same
15:26:47 <viveknarasimhan> and will hold the same fwaas rules
15:26:54 <carl_baldwin> viveknarasimhan: The problem is not just that the rules must hit both sides.  The problem is that the state needed for tracking established connections is not there.
15:27:41 <viveknarasimhan> ok
15:28:16 <viveknarasimhan> since the same router is distributed, the state disperses away onto the 2 routers based on direction of traffc. got it , thanks carl.
15:28:26 <yisun> I was thinking to force traffic to FW before traffic hits the DVR
15:28:58 <Swami> We had this discussion in the summit and Rajeev mentioned probably it would make sense to apply the firewall rules at the port where it is connected to the br-int.
15:29:14 <Rajeev> One option is to look at the blueprint that implements security rules in OVS
15:29:17 <Swami> yisun: yes that's what I mentioned.
15:29:57 <Rajeev> Similar to security rules, FW can also include a bridge
15:29:57 <carl_baldwin> yisun: That is a possible solution but negates the advantages of DVR.  Basically, it is saying that DVR and FWaaS are incompatible.  That might be true for some implementations of FWaaS.
15:31:25 <viveknarasimhan> rajeev, won't performance be an issue
15:31:56 <viveknarasimhan> with introduction of bridges for fwaas on dvr?
15:31:57 <Rajeev> The security rules BP folks analysis was no performance impact
15:32:11 <carl_baldwin> Rajeev: That solves a different problem.  It doesn’t address the split state issue.
15:32:20 <viveknarasimhan> the security rules BP folks said they don't have numbers yet
15:32:29 <viveknarasimhan> that donesn't say there is no performance impact
15:32:46 * carl_baldwin has to take off now.  Sorry about that.  Email or catch him on IRC later.
15:32:58 <Swami> carl: thanks
15:33:23 <yisun> Rejeev, that could be complicated when we start to introuduce zone
15:33:51 <yisun> Zone is basically a groupd of ports on the router
15:34:15 <Rajeev> Yisun: ports on the same subnet?
15:34:20 <yisun> If we create a bridge outside, then we will not be able find right info to apply zone
15:35:18 <yisun> Rajeev, you mean that we can apply zone on subnet directly?
15:35:19 <Rajeev> Yisun: will need to understand a bit more about zones,
15:35:44 <Swami> yisun: Probably for next it we can plan to address the different approaches for the FwaaS and walk through the Use cases and see how it would work that would be good.
15:36:34 <Swami> Yisun: can you put together a doc or a wiki for different approaches to solve the state issue with the DVR
15:36:51 <Swami> We can discuss it in the upcoming meetings.
15:37:07 <yisun> Swami, I don’t think I have thought this through yet, may need more time
15:37:33 <Rajeev> Yisun: feel free to get in touch
15:37:36 <Swami> yisun: Ok, take your time, this is not required immediately but eventually we need to address this issue.
15:37:48 <viveknarasimhan> rajeev
15:37:49 <viveknarasimhan> yi
15:37:50 <yisun> Swami, yes
15:37:56 <Swami> ok.
15:38:01 <yisun> Vivek, ya
15:38:06 <viveknarasimhan> since br-int use of DVR today knows
15:38:14 <viveknarasimhan> if packet is routed or switched,
15:38:28 <viveknarasimhan> we can havea the rule redirect traffic to firewall if we detect traffic routed by dvr
15:38:42 <viveknarasimhan> on both sides (ie., on both ends)
15:39:02 <yisun> Vivek, yes, that is what I meant by “force” traffic to FW
15:39:14 <Swami> Then dvr should be aware of the FWaaS in all these cases.
15:39:16 <viveknarasimhan> yes, we can force that
15:39:16 <yisun> Based on the source MAC I gues
15:39:26 <viveknarasimhan> we need to havea  fwaasondvr driver
15:39:36 <viveknarasimhan> separate, that will be configured in fwaas section ..
15:39:51 <viveknarasimhan> in neutron config
15:40:16 <Swami> viveknarasimhan: we need to think through all the scenarios.
15:40:18 <viveknarasimhan> what i put over here is service chaining
15:40:32 <viveknarasimhan> dvr routes packets, we detect them, chain such trafic to fwaas..
15:40:32 <yisun> Vivek, correct
15:40:35 <Rajeev> yes
15:40:46 <Swami> Ok if you guys have any more thoughts on this, just try to document or put it into the Etherpad and we can discuss in the upcoming meetings.
15:40:50 <viveknarasimhan> fwaas looks to the traffic and then figures out to drop /forward back to br-int
15:41:07 <Rajeev> can also filter on ip addresses
15:41:18 <viveknarasimhan> we can filter on l2 header, l3 header
15:41:23 <viveknarasimhan> l4 headers as well
15:41:27 <viveknarasimhan> with OVS 2.1 in plac
15:41:32 <yisun> vivek and rejeev, let me take this to fwaas team andd discuss about if we should put subnet to zone
15:41:40 <viveknarasimhan> thanks yi
15:42:08 <Rajeev> sounds good
15:42:14 <Swami> #action Yisun to take the FWaaS recommendations to the FWaaS team to work with the DVR
15:42:39 <Swami> #topic VPNaaS and DVR
15:42:56 <Swami> We had a discussion with Nachi on the VPNaaS and its impact on the DVR
15:44:24 <Rajeev> Swami: what is the issue there ?
15:44:27 <Swami> Based on the discussion when a VPNaaS is created and associated with the Router, if the router is DVR, based on the service type, if it is a singleton service, then this service namespace should be only created in the Service Node.
15:45:12 <Swami> Since we already have the SNAT service running on the Service Node, this should be accomplished in the Service Node.
15:46:13 <Rajeev> does the VPN allow multiple internal subnets to outside connectivity?
15:46:16 <Swami> I don't see any major issues other than refactoring the VPNaaS code to check the router type and based on the router type the scheduler should than decide to start the service in the right node.
15:46:23 <Swami> yes it does.
15:47:03 <Rajeev> So all the subnets attached to a router have access to VPN'ed network ?
15:47:18 <Swami> Yes
15:47:54 <Swami> #topic Tempest scenario tests
15:48:07 <pcm_> Swami: I thought one could only specify one subnet on near end>
15:48:09 <Rajeev> it should be then not too difficult to get VPN
15:48:49 <Rajeev> Is there a doc one can point to on VPN?
15:49:08 <Swami> pcm_: Nachi mentioned that it can support more than one
15:49:12 <pcm_> Swami: I thought multiple subnets can be specified for the peer end of the connection.
15:49:24 <pcm_> but not the local end.
15:50:10 <Swami> pcm_: If you specify multiple subnets on the peer end, then it is equivalent to providing the VPN access to multiple subnets
15:50:19 <Swami> I don't see any difference in there.
15:50:51 <pcm_> Swami: OK
15:50:54 <Rajeev> So on the near end it is one subnet only ?
15:51:25 <Swami> The reason for that is that on the "left side" it only accepts one "IP address" for the local ip
15:51:42 <Swami> But you can still have multiple subnets that you can provide access to from the far end.
15:51:56 <pcm_> Rajeev: When you configure the tunnel, you specify the far end public IP and peer-cidrs.
15:52:12 <Rajeev> pcm_: sure
15:52:26 <Swami> Each of the peer-cidrs is a subnet by itself.
15:52:58 <Swami> Either left or right we have a list of "peer-cidrs' or subnets that we will be supporting.
15:53:46 <Rajeev> Swami: understand the peer-cidrs, what I want to know is can I have 3 local subnets talking to peer through the same VPN?
15:54:47 <pcm_> Rajeev: Swami: I may be wrong, but I thought it was one to many selection.
15:55:36 <Swami> pcm_: when you say "one" to many it is from single cloud site you can connect to multiple branches on the other side
15:56:16 <Swami> rajeev: your question is valid and I will confirm it.
15:56:53 <pcm_> Swami: I mean I thought that you can go from one subnet on this cloud to 1+ subnets on another cloud.
15:57:25 <pcm_> Did not think you could go from >1 subnet on this cloud to 1+ on the other cloud.
15:58:12 <Swami> pcm_; rajeev: yes I can confirm it in the next meeting.
15:58:49 <Swami> rajeev: to your point if we only support one subnet on the left, then you don't see any issue with the DVR, am I right.
15:59:26 <Rajeev> Swami: it can be simpler solution then
15:59:39 <Swami> rajeev: thanks.
15:59:52 <Swami> We are at the end of the hour right now.
15:59:56 <Rajeev> Swami _pcm: thanks for looking into it.
15:59:59 <Swami> Sorry the services topic took long.
16:00:20 <Swami> I also wanted to have some discussion on the Tempest and scenario testing but next week we can take it up.
16:00:28 <Sukhdev> Swami: time for ML2 meeting
16:00:51 <Swami> Thanks all
16:00:55 <Swami> #endmeeting