15:01:08 #startmeeting distributed_virtual_router 15:01:09 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:13 The meeting name has been set to 'distributed_virtual_router' 15:01:25 Hi Folks, 15:01:42 hope everyone enjoyed the summit 15:01:46 Swami: hi 15:02:19 viveknarasimhan: hi 15:02:47 #topic Agenda 15:03:00 mrsmith: hi 15:03:07 betsy: hi 15:03:10 asomya: hi 15:03:11 hi 15:03:23 DVR Progress Update 15:03:24 hello 15:03:39 #topic DVR Progress Update 15:03:58 Swami: hi 15:04:06 Last week we were all in the summit and did not make any progress forward 15:04:43 We are currently working on fixing a bulk of unit test issues that we are facing with the L3-plugin 15:04:59 Swami: all? :) 15:05:24 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 good progress was made by some on the icehouse-ga merge 15:05:51 #topic DVR Extension for L3 15:06:43 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 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 That way we don't need to maintain this attribute going forward. 15:08:50 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 Hope this is not an issue for any of the members here. 15:10:15 #topic L3 Update 15:10:20 mrsmith: any updates 15:10:48 just that we got basic E/W functionality working on icehouse-ga 15:11:00 n/s needs more refactoring (again) 15:11:19 and as you say, we have a "debt" of unit tests failures that we need to refactor/fix 15:11:48 mrsmith: Thanks for the update 15:12:16 #topic L2 Agent 15:12:27 viveknarasimhan: do you have any updates 15:12:40 hyes 15:12:49 i posted the next patch set for L2 side upstream 15:12:57 after addressing review comments 15:13:09 there are still a few pep8 issues given by tox which i am working on 15:13:22 also i posted fix for l2-pop bug which got review approvals 15:13:28 but vendor CI tests are failing 15:13:49 i need help from community on what will it take to merge that fix: https://review.openstack.org/#/c/93624/ 15:14:08 that fix is mandatory for basic l2-pop (and so for dvr as well) 15:14:48 viveknarasimhan: It has been already reviewed. 15:15:00 yes 15:15:11 It should not be an issue to merge this fix into the Juno branch. 15:15:12 core reviewer Edgar gave +2 15:16:13 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 ok i will do 15:16:52 i sent two mails to maru newby, but didn't get response 15:17:00 sent a message to him on IRC as well. 15:17:20 viveknarasimhan: Everyone might be settling down after the summit, so wait for another couple of days. 15:17:59 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 viveknarasimhan: thanks for the update. 15:18:19 #topic Services and DVR 15:18:37 ok thanks 15:18:45 Folks there were a couple of questions that came up in the Neutron design session for the DVR regarding the Services 15:19:15 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 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 #topic DVR and LoadBalancer 15:21:07 I don't think today Loadbalancer service will be impacted by the DVR. 15:21:40 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 #topic DVR and Firewall as a Service 15:22:37 There was some concerns that was raised about the FWaaS and its statefull behavior. 15:24:45 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 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 Swami, I’m here 15:25:37 yisun: hi 15:25:39 one second 15:25:54 when we route the packet in DVR, the source router routes teh packet 15:26:01 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 so the fwaas rules must have hit both sides 15:26:42 though each direction is routed on different machines, teh routers on the machines are the same 15:26:47 and will hold the same fwaas rules 15:26:54 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 ok 15:28:16 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 I was thinking to force traffic to FW before traffic hits the DVR 15:28:58 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 One option is to look at the blueprint that implements security rules in OVS 15:29:17 yisun: yes that's what I mentioned. 15:29:57 Similar to security rules, FW can also include a bridge 15:29:57 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 rajeev, won't performance be an issue 15:31:56 with introduction of bridges for fwaas on dvr? 15:31:57 The security rules BP folks analysis was no performance impact 15:32:11 Rajeev: That solves a different problem. It doesn’t address the split state issue. 15:32:20 the security rules BP folks said they don't have numbers yet 15:32:29 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 carl: thanks 15:33:23 Rejeev, that could be complicated when we start to introuduce zone 15:33:51 Zone is basically a groupd of ports on the router 15:34:15 Yisun: ports on the same subnet? 15:34:20 If we create a bridge outside, then we will not be able find right info to apply zone 15:35:18 Rajeev, you mean that we can apply zone on subnet directly? 15:35:19 Yisun: will need to understand a bit more about zones, 15:35:44 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 Yisun: can you put together a doc or a wiki for different approaches to solve the state issue with the DVR 15:36:51 We can discuss it in the upcoming meetings. 15:37:07 Swami, I don’t think I have thought this through yet, may need more time 15:37:33 Yisun: feel free to get in touch 15:37:36 yisun: Ok, take your time, this is not required immediately but eventually we need to address this issue. 15:37:48 rajeev 15:37:49 yi 15:37:50 Swami, yes 15:37:56 ok. 15:38:01 Vivek, ya 15:38:06 since br-int use of DVR today knows 15:38:14 if packet is routed or switched, 15:38:28 we can havea the rule redirect traffic to firewall if we detect traffic routed by dvr 15:38:42 on both sides (ie., on both ends) 15:39:02 Vivek, yes, that is what I meant by “force” traffic to FW 15:39:14 Then dvr should be aware of the FWaaS in all these cases. 15:39:16 yes, we can force that 15:39:16 Based on the source MAC I gues 15:39:26 we need to havea fwaasondvr driver 15:39:36 separate, that will be configured in fwaas section .. 15:39:51 in neutron config 15:40:16 viveknarasimhan: we need to think through all the scenarios. 15:40:18 what i put over here is service chaining 15:40:32 dvr routes packets, we detect them, chain such trafic to fwaas.. 15:40:32 Vivek, correct 15:40:35 yes 15:40:46 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 fwaas looks to the traffic and then figures out to drop /forward back to br-int 15:41:07 can also filter on ip addresses 15:41:18 we can filter on l2 header, l3 header 15:41:23 l4 headers as well 15:41:27 with OVS 2.1 in plac 15:41:32 vivek and rejeev, let me take this to fwaas team andd discuss about if we should put subnet to zone 15:41:40 thanks yi 15:42:08 sounds good 15:42:14 #action Yisun to take the FWaaS recommendations to the FWaaS team to work with the DVR 15:42:39 #topic VPNaaS and DVR 15:42:56 We had a discussion with Nachi on the VPNaaS and its impact on the DVR 15:44:24 Swami: what is the issue there ? 15:44:27 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 Since we already have the SNAT service running on the Service Node, this should be accomplished in the Service Node. 15:46:13 does the VPN allow multiple internal subnets to outside connectivity? 15:46:16 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 yes it does. 15:47:03 So all the subnets attached to a router have access to VPN'ed network ? 15:47:18 Yes 15:47:54 #topic Tempest scenario tests 15:48:07 Swami: I thought one could only specify one subnet on near end> 15:48:09 it should be then not too difficult to get VPN 15:48:49 Is there a doc one can point to on VPN? 15:49:08 pcm_: Nachi mentioned that it can support more than one 15:49:12 Swami: I thought multiple subnets can be specified for the peer end of the connection. 15:49:24 but not the local end. 15:50:10 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 I don't see any difference in there. 15:50:51 Swami: OK 15:50:54 So on the near end it is one subnet only ? 15:51:25 The reason for that is that on the "left side" it only accepts one "IP address" for the local ip 15:51:42 But you can still have multiple subnets that you can provide access to from the far end. 15:51:56 Rajeev: When you configure the tunnel, you specify the far end public IP and peer-cidrs. 15:52:12 pcm_: sure 15:52:26 Each of the peer-cidrs is a subnet by itself. 15:52:58 Either left or right we have a list of "peer-cidrs' or subnets that we will be supporting. 15:53:46 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 Rajeev: Swami: I may be wrong, but I thought it was one to many selection. 15:55:36 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 rajeev: your question is valid and I will confirm it. 15:56:53 Swami: I mean I thought that you can go from one subnet on this cloud to 1+ subnets on another cloud. 15:57:25 Did not think you could go from >1 subnet on this cloud to 1+ on the other cloud. 15:58:12 pcm_; rajeev: yes I can confirm it in the next meeting. 15:58:49 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 Swami: it can be simpler solution then 15:59:39 rajeev: thanks. 15:59:52 We are at the end of the hour right now. 15:59:56 Swami _pcm: thanks for looking into it. 15:59:59 Sorry the services topic took long. 16:00:20 I also wanted to have some discussion on the Tempest and scenario testing but next week we can take it up. 16:00:28 Swami: time for ML2 meeting 16:00:51 Thanks all 16:00:55 #endmeeting