16:02:09 #startmeeting vpnaas 16:02:10 Meeting started Tue Jun 16 16:02:09 2015 UTC and is due to finish in 60 minutes. The chair is pc_m. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:14 The meeting name has been set to 'vpnaas' 16:02:41 The agenda is on the Wiki: https://wiki.openstack.org/wiki/Meetings/VPNaaS 16:02:50 Lot's to cover today... 16:02:59 #announcements 16:03:13 Neutron Mid-cycle is next week. 16:03:54 I'll be travelling and won't be able to run meeting. Anyone want to run the meeting, or do we want to skip a week? 16:04:19 pc_m: I can run the mtg if there an Agenda 16:05:01 sridhar_ram: Thanks! We can fill out agenda items for you. 16:05:13 pc_m: sure 16:05:22 Anyone have any other announcements w.r.t. VPNaaS? 16:05:39 #action sridhar_ram will chair meeting next week (6/23) 16:06:14 #topic Multiple local subnets 16:06:40 I've made up Dev Ref pages for this feature and it is out for review #link https://review.openstack.org/#/c/191944/2 16:07:06 Please look at this, which has some design ideas for the multiple local subnet. 16:07:57 Of big importance, is a proposal to break the connection API into two, one for the IPSec connection details (as is currently), and one for the endpoint pairs. 16:08:33 The latter is intended to separate the "what" gets connected from the "how" to connect. The goal here is that we could use this for other VPN types. 16:09:00 Would like to see community opinion on this ASAP, so we can start on it. 16:09:09 pc_m: I like the proposal although have not added the comment yet 16:09:30 john_a_joyce: cool. Looking forward to feedback. 16:09:52 Would like to see if this could be used for BGP VPN too. 16:09:58 pc_m: will add it to my review queue.. overall agree w/ the approach 16:11:03 sridhar_ram: Thanks. mhanif, matrohon, and other BGP and edge VPN folks check it out! 16:11:19 #topic certificates 16:11:23 pc_m : I'll do, thanks 16:11:34 matrohon: Thanks! 16:11:53 I did the action item and posted a ML question on certificates. No response yet. :( 16:12:31 This one too, I'm proposing breaking out an API for auth credentials, so that it can be used by other VPN flavors. 16:13:25 So, instead of the connection specifying a PSK or UUID of a certificate, it would specify an auth credential UUID, and that credential would have all the info. Could share it by multiple connections too. 16:13:37 pc_m: do we have a liason or point of contact in Barbican who can help to consult on this ? 16:14:01 Only have a bug on this, no dev ref yet. https://bugs.launchpad.net/neutron/+bug/1459427 16:14:02 Launchpad bug 1459427 in neutron "VPNaaS: Certificate support for IPSec" [Undecided,Triaged] 16:14:35 sridhar_ram: I've talked to Brandon and Doug. I think there is a person named Phil as well to contact. 16:14:43 pc_m I am interested in the certificate question but am woefully behind on email. 16:15:51 There was a summit talk on Barbican users, and LBaaS team spoke of what they did. 16:16:11 pc_m That would be Phil Toohill (ptoohill in IRC). He did much of the LBaaS barbican integration. 16:16:11 I suspect that, out of the gate, we'll do X.509 certificates. 16:16:21 ajmiller: Thanks 16:17:16 Summit link... https://www.youtube.com/watch?v=ihsQJL-tFxI&t=8m42s 16:17:46 #link https://www.youtube.com/watch?v=ihsQJL-tFxI&t=8m42s 16:17:57 ^^that will post the link in the meeting minutes. 16:18:26 Essentially one creates the certificate and container in Barbican and then can use it in VPN. 16:18:36 ajmiller: Thanks. I forgot the link 16:19:09 Anyone interested in working on the certificate stuff, let me know. 16:19:40 * pc_m working on, leading, helping, etc... 16:19:58 #topic DM VPN 16:20:28 There was an action item for yanping on network-id being able to use tunnel-key. yanping? 16:20:36 Is that resolved (I think so)? 16:20:51 correct. Think it is solved in the spec review 16:21:05 resolved 16:21:15 pc_m: yanping: yeah, we took care of it in the spec 16:21:34 Everyone please help review https://review.openstack.org/#/c/181563/ 16:21:43 sridhar_ram: anything else on DM VPN? 16:22:18 sridhar_ram: Similar to certificate, I'd like to invite folks interested to participate in the implementation 16:23:12 pc_m: nothing else from the spec point of view 16:23:18 sridhar_ram: okey dokey 16:23:21 #topic BGP/MPLS and Edge VPN. 16:23:57 There were a few action items from last week. matrohon did you get a chance to do a drawing for bagpipe? 16:24:39 I did not make any progress on the drawing, sorry, but I still have that in my todo list! 16:24:56 matrohon: super. looking forward to it. 16:25:57 I'll open the floor to continuation on discussion on this. I'd be interested in hearing about whether we can separate out the what and how for VPN and use it for different flavors of VPN. 16:26:42 The endpoint pair proposal is one thought on that. I'd like to hear others and see if there is some commonality there. 16:26:51 Folks, at a high level, for L2/L3 VPNs we have two distinct functionalities to address 16:27:25 One is provisioning of a VPN and other is to bind a Neutron network to it. Agreed? 16:27:48 agreed 16:28:26 In that sense, should we try to combine our efforts to address them in a manner which resolves all use cases 16:29:19 I think pc_m proposal in https://review.openstack.org/#/c/191944/2 might be a start along those lines 16:29:23 mhanif: Can you add that to the etherpad #link https://etherpad.openstack.org/p/vpn-flavors 16:29:26 it breaks it up in two 16:29:29 I see the provisioning as an admin task while binding task could be handed over to the tenant as well 16:29:35 mhanif: at your leisure. 16:29:55 I believe as you were thinking although in that case it is IPSEC for the tunnel 16:30:06 pc_m: I have added to the vpn-flavors. Will make it more clear there 16:30:24 mhanif: thanks! good to know the use cases. 16:31:09 mhanif: Take a look at https://review.openstack.org/#/c/191944/2/doc/source/devref/multiple-local-subnets.rst, option B. 16:31:47 pc_m: Sure will do. 16:31:59 mhanif: I'm hoping it may be massaged to work for your binding case. 16:31:59 Hence, I would like to propose that we have generic APIs to address what I just described 16:32:27 do you see the Edge vpn API as a way to provision and the BGPVPN API a way to bind networks? 16:32:34 APIs which are not limited to one type of VPN or any one of Neutron network 16:33:01 matrohon: Edge VPN API spec addresses both 16:33:29 I need to separate them out and make them two spec 16:33:45 mhanif : ok, make sense 16:33:53 The other spec will be inline with what BGP VPN spec talks about 16:35:32 pc_m: The binding spec will again be addressing all varieties of networks 16:35:39 cool - so it seems like we pretty much have a consensus on the functional split 16:35:57 we just need to hammer out the details so all the use cases can be hit 16:36:10 matrohon: mhanif: Let me know if you think the vpn-endpoint-pair API could handle the binding. 16:36:19 +1 for split it this way 16:36:38 john-a-joyce: agreed 16:37:01 +1 16:37:50 pc_m : your current proposal attach vpn services to a router 16:38:08 I was trying to adapt the vpn-endpoint-pair for the binding and the ipsec-site-connection for IPSec provisioning. 16:39:15 matrohon: only because that was the original approach. Trying to modify that, in a backward compatible way (hopefully). 16:39:54 The vpn-endpoint-pair API would allow routers, networks, cidrs, vlan, route-targets, etc. as endpoints. 16:41:37 * sridhar_ram makes a note to read endpoint-pair spec w/ all VPNs in mind 16:42:32 pc_m : I'm not sure it is useful; I don't really see how endpoitns pair match bgp vpns 16:42:32 pc_m: sridhar_ram: Edge VPN calls it an attachment circuit in its spec 16:43:05 mhanif: I see 16:44:40 mhanif: Would that make sense for naming with IPSec or other VPN types? I was trying to pick something generic. Would like to hear suggestions in the review comments. 16:45:20 matrohon: Could we create an endpoint pair, with the peer being route targets (imported)? 16:45:32 The VPN construct becomes the provider/keeper of the circuit/endpoint. 16:46:30 pc_m: Sure. Will review the spec and provide comments 16:46:47 pc_m : I have to think about it; 16:47:33 pc_m : I feel that API would result in a complex matrix with type supported by only few of connection types 16:48:09 Connection type can be abstracted out as a UUID 16:48:12 I think the goals in the review are.... A) is it better to try to split out the what from the how, as part of the multiple local subnet work, B) would that work for other VPN types, and C) do we have a reasonable naming and capabilities with it. 16:48:22 matrohon: I guess that is the tradeoff we have to decide 16:49:42 pc_m: agree, striking the right abstraction to accommodate different "type" of VPN is the goal 16:49:43 do we want a more common API and the connection types would support all the cases 16:49:57 or have APIs for each different type of connection 16:50:57 matrohon: mhanif: pc_am: can we abstract current implicit assumption that VPN is associated with neutron-router 16:51:00 john-a-joyce: good summary 16:52:22 sridhar_ram : may be by putting the router in the local type? 16:52:32 instead associate with a generic "vpn-target" 16:53:21 neutron-router-id being one of the target or PE-router-id where the "vpn" got created 16:54:20 matrohon: the local type would be cidr for IPSec to indicate the near end subnet(s). 16:55:06 pc_m : I see 16:55:07 sridhar_ram: The router where VPN is created may not have been abstracted out in Neutron 16:55:20 mhanif : +1 16:55:38 matrohon: For IPSec you'd have local and peer subnets describing the what. 16:56:29 Also, the router is at a little higher level, as it applies to all connections for the service. 16:56:46 * sridhar_ram is back 16:56:53 Do we need the vpn-service API for IPSec as a container for the connections (and specify the router)? 16:58:25 In any case, we're about out of time. Please comment on the review, which although is for multiple local subnets, is trying to do so in a manner that is looking ahead, if possible. If not, we can do option A, but I'd like to try to do more (and not have to churn on the API later). 16:58:54 Thanks for the great discussion on this! 16:59:00 pc_m : not sure to understand : you mean moving the router_id in ipsec-site-connection-create 16:59:03 ok thanks 16:59:43 matrohon: no, was thinking to keep it on the vpn-service API and use that as a container for connections (which it sort of is today) for IPSec. 16:59:55 matrohon: Lt's continue on neutron IRC... 17:00:12 #endmeeting