22:03:36 <nati_ueno> #startmeeting OpenStack Networking (VPN)
22:03:37 <openstack> Meeting started Thu May 16 22:03:36 2013 UTC.  The chair is nati_ueno. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:03:40 <openstack> The meeting name has been set to 'openstack_networking__vpn_'
22:04:38 <nati_ueno> This is today's agenda https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.gc2779960_400
22:05:16 <nati_ueno> it looks like Satin is not yet
22:05:37 <nati_ueno> so let's start reviewing from Driver archtecture https://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHIw_G1Dy5aQ/edit
22:05:45 <Swami> ok
22:05:48 <nati_ueno> #topic ipsec driver archtecture
22:06:31 <nati_ueno> So do you have comment's for this bp?
22:06:41 <sthakkar> hi folks sorry running a few min late
22:07:25 <Swami> nachi: I don't see any issues with your design, I think it follows the existing LBaaS model
22:07:44 <nati_ueno> sthakkar: noop :) we are discussing Driver archtecture https://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHIw_G1Dy5aQ/edit
22:07:55 <nati_ueno> markmcclain: do you have comments on this?
22:08:07 <nati_ueno> sthakkar: This is today's agenda This is today's agenda https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.gc2779960_400
22:08:20 <markmcclain> sorry this is first time I've had a chance to look at it
22:08:33 <markmcclain> I'll a bit of time to digest it :)
22:08:40 <nati_ueno> markmcclain: gotcha
22:08:47 <pcm__> nati_ueno:  just some Qs (to give Mark tiem to look :)
22:08:55 <nati_ueno> pcm__: OK please
22:09:09 <pcm__> on the create, the driver gets the host that the router is running on.
22:09:17 <nati_ueno> pcm__: yes
22:09:43 <nati_ueno> pcm__: https://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHIw_G1Dy5aQ/edit#slide=id.gc2bc6c2e_024
22:09:48 <pcm__> Then checks the port is created. Is this the port on the network side of the router, vs VM side?
22:10:12 <nati_ueno> pcm__: router side
22:10:29 <pcm__> if not created, what happens?
22:10:57 <nati_ueno> pcm__: set status of the VPNService error state
22:11:04 <pcm__> ok.
22:12:15 <Swami> nachi: In your slide 3 you mentioned that create vpn service calls the IPsecVPNDriver, in my opinion, only if there is a connection associated with the VPNService we need to call the Driver, otherwise we don't need to call the driver.
22:12:54 <nati_ueno> Swami: ah no. We will call agent when connection associated
22:14:15 <nati_ueno> OK anyway i'll start implementation on next week or next next week.
22:14:21 <Swami> Nachi: In your slide 3 there are two drivers one "IPSecVPNDriver" before the agent and another driver "StrongSwan Driver". - why do we need two drivers.
22:14:23 <nati_ueno> so please give me your feedbacks
22:14:35 <markmcclain> yeah.. I was going to ask the same time
22:14:37 <markmcclain> *thing
22:14:53 <nati_ueno> Swami: IPSecVPNDriver is server side driver
22:14:54 <markmcclain> the StrongSwan driver should be subclass of IPSecDriver
22:15:18 <nati_ueno> StrongSwan Driver is agent side driver
22:15:26 <nati_ueno> so API is different
22:15:31 <pcm__> On the dwg on page 2, both drivers are in the agent block?
22:16:04 <nati_ueno> pcm__: page2 is wrong. sorry I updated it
22:16:46 <nati_ueno> so may be in future IPSecDriver will call another implementation of agent side driver
22:16:49 <pcm__> just trying to understand the mapping of the block diagram to the items in the ladder diagram (and where the RPC boundary is - sorry not yet familiar with LBaaS and others)
22:16:59 <Swami> Instead of calling it as IPseDriver just name it as IPsecCallback functions
22:17:49 <nati_ueno> Swami: We will add another VPN's driver here. SSLDriver, MPLSDriver. so "driver" illustrates what's we wanna do
22:18:08 <nati_ueno> Swami: callback sound
22:18:15 <nati_ueno> 's not plugablle
22:18:29 <Swami> ok
22:19:17 <nati_ueno> May be I should call StrongSwanDriver as StrongSwanDeviceDriver
22:19:49 <Swami> that works
22:19:53 <markmcclain> yeah I think that seems reasonable
22:19:55 <nati_ueno> gotcha
22:20:36 <nati_ueno> OK anyway i'll start implementation on next week or next next week, so please keep review it :)
22:20:56 <nati_ueno> I wanna also have quick discussion of https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.p
22:21:02 <nati_ueno> so how we create agent
22:21:07 <nati_ueno> vpn-agent
22:21:19 <nati_ueno> I believe current proposal is https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.gc2c671fc_035
22:21:30 <nati_ueno> However https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.gc2c671fc_089 looks more good for me
22:21:34 <markmcclain> do we need a separate agent or should this service be colocated with the l3 namespace?
22:21:55 <nati_ueno> the service should be colocated with the l3 namespace
22:22:02 <nati_ueno> for first implementation
22:22:17 <markmcclain> right.. so it's a subclass of the l3_agent?
22:23:08 <nati_ueno> markmcclain: it is under the discussion. May be two different process will manage one namespace such as Option3 in the google doc
22:23:43 <markmcclain> having two processes manage the namespace will introduce different race conditions
22:23:54 <nati_ueno> markmcclain: yes. I agree
22:24:07 <nati_ueno> so I prefer Option2-2 in the google doc
22:25:04 <Swami> Are other services following the same model
22:25:17 <markmcclain> Swami: no
22:25:28 <nati_ueno> Swami: yes. let's keep discussion on the mailing list about this service agent one
22:25:29 <markmcclain> FWaaS will be implemented in L3 agent
22:25:40 <Swami> do we need to align with other services
22:25:59 <markmcclain> yes.. but that alignment will happen in H2
22:26:23 <markmcclain> that's why think we should go option 1 for now
22:26:27 <nati_ueno> I'm start discussion with Sumit also
22:26:35 <nati_ueno> FWaaS looks https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.gc2c671fc_022
22:26:49 <markmcclain> nati_ueno: it's actually more than just a discussion with Sumit
22:27:01 <nati_ueno> markmcclain: ah discussion means in the mailing list
22:27:31 <markmcclain> yeah.. but I don't want to bog either team down discussing option2 yet
22:27:54 <markmcclain> because it introduces complexities that can really hamper progress
22:28:02 <markmcclain> remember we need to start simple and get things working end to end
22:28:24 <markmcclain> if we do thing right we can move the logic in option to support services in option 2 later
22:28:38 <nati_ueno> markmcclain: I got your point. so we start implement directory in the l3-agent?
22:28:51 <markmcclain> that's my preference
22:29:01 <markmcclain> gives us a chance to validate api and driver interface
22:29:08 <nati_ueno> Ok so how about implement vpn also in the l3-agent?
22:29:24 <nati_ueno> If vpn-agent will touch the router namespace, we should do it in the l3-agent
22:29:38 <markmcclain> yeah.. a subclass of the l3 agent should work to start out
22:29:49 <markmcclain> we can clean things up later in the cycle
22:29:55 <nati_ueno> markmcclain: +1
22:29:56 <Swami> that makes sense
22:30:55 <nati_ueno> OK next topic is
22:30:58 <pcm__> markmcclain: You mentions FWaaS doing option 1? How far are they (as in, is there something I can look at)?
22:30:59 <nati_ueno> #topic local_subnet vs local_cidr
22:31:25 <nati_ueno> pcm__: They just started, so IMO there is no code yet
22:31:47 <markmcclain> pcm__: they're not too far in yet
22:31:50 <pcm__> nati_ueno: Is LBaaS there?
22:32:00 <nati_ueno> pcm__: not yet
22:32:04 <markmcclain> LBaaS uses a 1 arm model
22:32:04 <pcm__> (just looking for reference material)
22:32:09 <markmcclain> so it's not routed yet
22:32:47 <nati_ueno> OK let's continue discussion of local_subnet vs local_cidr
22:33:01 <nati_ueno> In previous meeting, we discussed local_subnet vs local_cidr
22:33:17 <nati_ueno> also we should use "cidr" value or "Subnet ID"
22:33:25 <markmcclain> so I've been thinking about this :)
22:33:42 <nati_ueno> markmcclain: Thanks. so do you have update?
22:33:44 <sthakkar> so basically do we integrate with the ipam system or use explicit values
22:33:52 <nati_ueno> sthakkar: exactly
22:34:01 <sthakkar> what would happen if we support both?
22:34:10 <nati_ueno> sthakkar: That's one option
22:34:12 <markmcclain> sthakkar: it's messy
22:34:18 <sthakkar> true
22:34:30 <sthakkar> but im worried if we integrate with ipam we lose a few folks in the shuffle
22:34:48 <Swami> we should stick on to the cidr for now
22:34:50 <markmcclain> sthakkar: we don't necessarily have to integrate with IPAM
22:34:56 <nati_ueno> so we need to satisfy  Usecase1 sub-area of cidr Usecase2 aggregation
22:35:06 <markmcclain> but the cidrs on the local end should be defined in one place
22:35:19 <markmcclain> nati_ueno: the problem with say using a /27 of /24
22:35:25 <markmcclain> is how is traffic routed?
22:35:46 <nati_ueno> in the remote side
22:36:09 <nati_ueno> so let's say 10.0.0.0/27 is routed to the OpenStack side
22:36:09 <markmcclain> not the remote side
22:36:12 <markmcclain> on the local side
22:36:42 <nati_ueno> This is local subnets which is sent to the remote side.
22:36:50 <nati_ueno> so it is not used in the local side
22:37:15 <markmcclain> right but that introduces routing issues
22:37:46 <nati_ueno> markmcclain: which kind of routing issue?
22:38:27 <markmcclain> so if declare a smaller subnet on the local end
22:38:49 <markmcclain> there will be instances where a guest will think the address is local
22:38:56 <markmcclain> so won't forward the packet the gateway
22:39:35 <nati_ueno> you mean remote side?
22:40:18 <markmcclain> I thought the local cidrs could be smaller than the local subnet
22:42:03 <nati_ueno> I wrote diagram https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.gc2779960_410
22:42:12 <nati_ueno> let's use this slide as whiteboard
22:44:22 <markmcclain> what slide #?
22:44:28 <nati_ueno> page 3
22:45:02 <nati_ueno> This is what is in my mental model
22:45:27 <nati_ueno> And I suppose it works
22:45:47 <Swami> This should work
22:46:56 <markmcclain> I not sure I under why you'd export a /30 to the remote end
22:47:33 <markmcclain> how does the remote talk to something that within the /24
22:47:54 <markmcclain> what happens if the there's a guest that has an address that shares the net address of the /30?
22:47:56 <nati_ueno> remote can talk only within /30
22:48:20 <nati_ueno> this is intent of the usecase
22:49:00 <markmcclain> but that use case is different from VPC
22:49:00 <pcm__> so tenant may want to provide VPN only for some clients?
22:49:10 <markmcclain> or even if you're following say a vyatta instance locally
22:49:55 <nati_ueno> pcm__: yes
22:50:12 <nati_ueno> I added application on the VM
22:50:28 <markmcclain> it seems if someone wants to provide VPN only they can create a subnet special for the client
22:50:54 <pcm__> markmcclain: Does VPC  just do whole subnet?
22:51:06 <markmcclain> yes
22:51:18 <Swami> VPC does not provide an option for the local side but it only requests prefixes for the remote side
22:51:43 <nati_ueno> Swami: so which local side subnet will be advatized?
22:51:59 <nati_ueno> Swami: ah this is not bgp, so we need manual configuration for remote side?
22:52:05 <Swami> Yes
22:52:32 <nati_ueno> so why we need local_cidr for first implementation if it has no bgp
22:52:51 <nati_ueno> ?
22:53:57 <nati_ueno> Swami: any thought?
22:54:51 <markmcclain> sthakkar or pcm__ too?
22:54:54 <Swami> I thought we can just live it as it is for now.
22:55:20 <pcm__> markmcclain: got nothing here :)
22:55:45 <markmcclain> if we drop the field right now we won't have to write validation code
22:55:54 <nati_ueno> markmcclain: I agree
22:56:01 <markmcclain> if we need it later on.. migrations are fairly easy to implement
22:56:02 <sthakkar> I think looking through most systems
22:56:07 <sthakkar> its the full subnet
22:56:31 <Swami> so in this case we will fetch the full subnet from the subnet id and just drop the local_cidr field
22:56:47 <nati_ueno> +1 for first step
22:56:58 <Swami> +1 agreed
22:57:06 <nati_ueno> And let's keep discussion for this until we start implement bgp mode
22:57:29 <nati_ueno> however we should agree on peer_cidr or peer_subnet
22:57:37 <markmcclain> +1 for first step
22:57:44 <markmcclain> peer_cidr
22:57:50 <nati_ueno> so subnet on peer is out of management of quantum ipam
22:57:55 <markmcclain> the subnet term is too overload within Quantum
22:58:04 <nati_ueno> ok I should say
22:58:11 <nati_ueno> so cidr on peer is out of management of quantum ipam
22:58:27 <nati_ueno> so we should use cidr value for peer_cidr
22:58:38 <Swami> +1 for peer_cidr
22:58:39 <markmcclain> yeah.. otherwise we'd have to add the notion of remote networks and subnets to Quantum
22:58:58 <sthakkar> i think qin's comparison was primarily for standardization with other devices as _subnets or _networks
22:58:58 <nati_ueno> +1 for peer_cidr
22:58:59 <markmcclain> that is another discussion for another time :)
22:59:12 <sthakkar> but we could potentially go for _ipsubnets as well
22:59:27 <sthakkar> im okay whichever way for this name, users will figure it out
23:00:03 <sthakkar> ok lets leave it as cidrs then for now
23:00:14 <nati_ueno> ok so let's keep peer_cidr
23:00:37 <Swami> +1
23:00:40 <markmcclain> remember the first version is somewhat experiment
23:00:49 <pcm__> and can be > 1?
23:00:53 <markmcclain> if the feedback comes back that we need remote_subnets we can change it
23:01:05 <nati_ueno> ok
23:01:12 <nati_ueno> so it looks 1 hour goes
23:01:25 <nati_ueno> When we discuss next time?
23:01:46 <nati_ueno> we should move over the other discussion in next time or mailing list.
23:02:03 <nati_ueno> Next monday 5PM (PST) ?
23:02:20 <pcm__> OK for me.
23:02:21 <sthakkar> lets start discussing over the mailer
23:02:30 <sthakkar> im fine for 5pm monday
23:02:33 <Swami> works for me.
23:02:37 <sthakkar> if we need another session
23:02:40 <markmcclain> yeah.. I good for 5pm
23:02:57 <markmcclain> we do have a good direction, so it might make sense to skip a week and let some work be done
23:03:07 <nati_ueno> OK so next time is 5/21 5pm PST
23:03:13 <markmcclain> the dev process might raise some ?s that we can kick around
23:03:23 <sthakkar> yea im fine with that too
23:03:28 <Swami> You mentioned Monday - it is 5/20
23:03:29 <nati_ueno> markmcclain: I'm start feeling too
23:03:30 <sthakkar> go mailer only for the next 7-10 days
23:03:38 <sthakkar> and if there are a ton of open questions during dev
23:03:42 <sthakkar> we schedule a follow up
23:03:53 <nati_ueno> OK so let's continue discussion on the Swami's review requirement or mine
23:04:18 <nati_ueno> I feel We are making good progress :)
23:04:26 <Swami> nachi: Our next meeting is on Monday or tuesday
23:04:26 <nati_ueno> #endmeeting