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