00:06:56 #startmeeting openstack_networking_vpn 00:06:57 Meeting started Tue May 14 00:06:56 2013 UTC. The chair is nati_ueno. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:06:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:07:00 The meeting name has been set to 'openstack_networking_vpn' 00:07:14 #topic local_subnet vs local_cidr 00:07:42 so one minor point on api discussion is local_subnet vs local_cidr 00:08:10 openstack networking guys tend to +1 for local_cidr because subnet is already used in more general meanings 00:08:47 vpn guys tend to +1 for local_subnet because it is familiar with existing configrations 00:09:42 markmcclain: how do you think? 00:10:08 my preference is for local_cidrs 00:10:20 me too 00:10:22 I know it is different from other implementations 00:10:32 I am ok with local_cidrs 00:10:40 pcm_ : how do you think? 00:11:28 nati_ueno: no real preference. StrongSwan seems to use left and right for local/remote. Not sure if that muddies it more. 00:11:44 pcm_: gotcha 00:11:46 with subnet 00:11:56 leftsubnet rightsubnet 00:12:20 it is driver specific so it looks no problem 00:12:45 But as far we document in the help string, we can map it in the implementation 00:13:02 OK so let's go with local_cidr but may be we should discuss this again when Qin@VMware join the meeting. 00:13:07 OK next topic 00:13:11 the one question I do have to local subnets 00:13:29 there should be a 1:1 for the cidr list and a tenants subnet correct? 00:13:43 Yes 00:14:08 so would it make more sense to accept a list of subnet ids? 00:14:16 No we should support small area of the subnet 00:14:23 or aggregate of the subnets 00:14:36 Yes that was our proposal, peer_cidrs and local_cidrs will be a list of cidrs 00:14:54 let's say if Subnet cidr is 10.0.0.0/24, we can also specify 10.0.0.0/31 on vpn 00:15:16 Swami: right 00:15:36 markmcclain: is this makes sence? 00:15:36 Yes 00:15:44 nati_ueno: I don't understand that use case 00:16:06 markmcclain: so sometimes, we want to expose only limited ips for vpn side 00:16:31 or aggregate many tiny subnets for performance reason 00:16:49 aggregating a list of existing cidrs is easy 00:17:29 yes we can aggregate and provide a single cidr that will accept all the subnets in the tenants network 00:18:16 so let's numbering the usecase 1) sub area of subnet 2) aggregate multiple subnets 00:18:46 markmcclain: 1) don't make sense for you? and 2) makes sense for you 00:18:49 ? 00:19:05 yeah 00:19:28 Automating #2 reduces the chance of errors 00:19:46 OK for 1). may I ask why it doesn't make sense? 00:21:19 how we Automating #2 ? 00:22:50 have to think a bit more 00:23:05 markmcclain: gotcha. 00:23:06 but it just seems odd that we're requiring a tenant to enter data 00:23:29 multiple times 00:24:06 markmcclain: I agree for that point. may be client can accept subnet_id and translate it to the cidr 00:24:42 in that case can we document and say enter the aggregate cidr for the peer and local subnets 00:25:09 nati_ueno: that approach supports the case of making local_cidrs a list of subnet_ids 00:26:17 markmcclain: we should think about cli namings 00:26:46 markmcclain: but my intension is specifying subnet_id in local_cidrs on CLI 00:27:11 or may be we can hire local_subnet and accept both of subnet_id and cidrs 00:27:13 Swami: a vpnserviceconnection has a 1:1 with a VPNConneciton 00:27:36 the VPNService can only have 1 subnet, so we'd be agg'ing only 1 subnet 00:28:19 nati_ueno: specifying a cidr on the CLI is ambigous 00:28:19 Yes that is true 00:28:51 a tenant can create two networks with the same cidr 00:28:59 which subnet would you match? 00:29:22 markmcclain: it don't matter, because we connect vpn to the router 00:29:34 markmcclain: And we can't plug overwrapping subnets for one router 00:29:50 right but for referential integrity.. we need to know which subnet they want associated 00:30:04 otherwise the logic in the router becomes more complex 00:30:26 what's referential integrity? 00:30:55 at the db layer how the models relate to each other 00:31:23 so some usecase requires different range of subnet's cidr. 00:31:32 so we can't mapping it 1to1 00:32:02 I agree if we chooose subnet_id 00:32:16 when the subnet deleted, we can also update vpn config automatically 00:32:19 it is clean 00:32:35 however it limits the scope 00:35:22 And also even if VPNService can only have 1 subnet, the associated router will be nexthops for multiple local subnets (cidrs) 00:35:53 so using cidrs is simple way to support usecases ( #1 #2) 00:37:22 they'll work because the data is denormalized… but long term this might cause more problems 00:37:53 we move forward with cidrs for now, but might make sense to revisit this 00:41:56 markmcclain: Thanks. Could you target the bp above? 00:42:17 nati_ueno: done 00:42:21 markmcclain: Thanks! 00:42:24 ok next. check default value for lifetime value (Swami) 00:42:31 Swami: did you checked this one? 00:42:42 nachi: updated the document for the default Kilobytes. 00:42:48 Swami: Thanks! 00:43:02 Implement Data Model (Swami will push code to the gerrit) 00:43:12 Swami: May I ask when you can push? 00:43:26 nachi: Yes I have to do some clean up and once done, I will push it to the gerrit for review 00:43:40 Swami: in this week or next week? 00:43:59 Nachi: By the end of this week, it should be in gerrit, but it may not have the unit-tests covered. 00:44:13 Swami: it is OK for now because it is WIP 00:44:21 got it. 00:44:32 so 5/20 is OK? 00:44:49 Yes let us target for 5/20. 00:44:53 Swami: Thanks! 00:45:00 Implement Driver (Nachi & PCM ) 00:45:11 pcm_: do you have any progress? 00:45:55 Just looked at StrongSwan docs. See they have example for net2net, psk. Assuming that is what we want to do first off right? 00:46:19 They have example net http://www.strongswan.org/uml/testresults/ikev2/net2net-psk/ 00:46:24 I pcm if you need any pointers to Strongswan or sample configuration, let me know and I can provide it. 00:46:49 Swami: Can always use more info. Feel free to email me info. 00:46:50 Look for IKEv1 examples for the first test case 00:46:56 sure. 00:47:00 Swami: Thanks! 00:47:07 I was going to try to set this up in VBOX. 00:47:25 OK let's target driver for 5/31 since this one depends CRUD model 00:47:25 Have four VMs, trying to figure out how to do the I/Fs. 00:47:48 pcm_: gotcha 00:47:59 pcm_: 5/31 is OK for you also? 00:48:14 nachi_ueno: Let me know if it makes sense to do a sample in VBOX for config. 00:48:33 pcm_: it sounds make sence 00:49:09 nachi_ueno: Not sure, as I don't know how much there is to do (never have done a driver for OS). Will defer to your assesment. 00:49:45 pcm_: gotcha. if strongswan works, it is not difficult to write driver. it just RPC & and conf generation 00:49:46 Do we have a spec interface for the driver? 00:50:05 markmcclain: not yet. I'll propose it 00:50:49 OK next 00:51:41 CLI (python-quantum client) work (Swami will push code to the gerrit) 00:51:41 Swami: this is 5/20 also? 00:51:41 agreed!! 00:51:41 Swami: Thanks!! 00:51:41 Write openstack network api document wiki (Sachin) <-- let's ask this next time 00:51:41 Devstack support 00:51:41 Any task takers? 00:51:55 ok I'll take this for now 00:52:20 nati_ueno: it's hard to write devstack support until 00:52:27 I can ask if someone on our team wants to help, if you'd like. 00:52:40 there are rudimenatry steps to install the needed components 00:52:53 markmcclain: yeah, I agree. It will be may be late July 00:52:58 pcm_: thanks! 00:53:23 OK if anyone interested in Horizon and Tempest, please let me know 00:53:30 for LBaaS we kept a wiki with the installation instructions and then the devstack support became an afternoon project 00:53:59 markmcclain: That's nice idea 00:54:14 markmcclain: Let's have installation instructions for VPN 00:54:27 it also helps the reviewers test 00:54:33 markmcclain: gotcha 00:54:50 markmcclain: I'll link the wiki when I submit strong swan driver 00:54:57 sounds good 00:55:10 OK any other topics? 00:56:16 nati_ueno: Offline maybe we can talk about VBOX emulation of the test setup I have. 00:56:59 pcm_: Gotcha. Are you in Bay Area? if so F2F is more efficient for this kind of task :) 00:57:21 nati_ueno: Nope. East Coast :( 00:57:34 Boston area 00:57:50 OK let's talk on online. my skype is nati.ueno same for google+ 00:58:06 Next meeting is 5/16 Thursday at 5pm (PST) ( VMWare guy will join) 00:58:10 Can do a phone call or WebEx possibly. 00:58:18 oh ok. 00:58:20 pcm_: yes 00:58:26 ok 00:58:31 pcm_: webex & phone call is OK too 00:58:38 markmcclain: the time is OK for you? 00:59:02 I'm a maybe for Thurs (it conflicts with the Atlanta OpenStack Meetup) 00:59:19 if the wifi is good.. I'll do both 00:59:28 What's the time of Atlanta OpenStack Meetup> 00:59:29 ? 00:59:37 May be we can change the time 01:00:14 the meetup is 7pm eastern 01:00:35 Ok let's schedule in the mail 01:00:55 Thank for your joining meeting! 01:00:58 #endmeeting