16:03:28 <pc_m> #startmeeting vpnaas
16:03:29 <openstack> Meeting started Tue Jul  7 16:03:28 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:03:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:33 <openstack> The meeting name has been set to 'vpnaas'
16:03:49 <pc_m> #topic Announcements
16:04:18 <pc_m> I don't have any specific announcements. Anyone else have any?
16:05:25 <pc_m> #topic local tunnel IP
16:05:49 <pc_m> I've been coding. Hope to have something up in a day or two.
16:06:22 <sridhar_ram> pc_m: just reading up this bug
16:06:42 <pc_m> Blocked a bit currently because of two nested issues. One is that the migration chain was broken, so I did a commit to fix that. #link https://review.openstack.org/#/c/199082/
16:07:32 <pc_m> To make it worse, all VPN commits are failing py27, due to a recent neutron commit. I found the offending bug and will ping Armando as soon as I can for help.
16:07:58 <pc_m> #topic Multiple Local Subnets
16:08:01 <sridhar_ram> a basic question. so far, atleast for ipsec, there is no extruded address. what is the motivation for this local tunnel IP ?
16:08:06 <pc_m> #undo
16:08:07 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x90c6a50>
16:09:37 <pc_m> sridhar_ram: If you have a VPN appliance, separate software, hardware, VPN in a VPN, anything where the VPN connection is NOT going from the router, then you run into a problem, because the code currently assumes the router's GW IP will be used.
16:10:23 <sridhar_ram> okay, is this handled as a bug or a RFE enhancement ?
16:10:33 <pc_m> sridhar_ram: In addition, if the IP is not in the router, you may not have a way to know what the IP is, so provisioning on the other end is hard (as they don't know the peer IP)
16:10:57 <pc_m> sridhar_ram: bug. I asked Kyle if an RFE was needed and he said to do as a bug.
16:11:26 <sridhar_ram> okay
16:12:24 <sridhar_ram> my concern is local tunnel IP is typically indended for extruded local addr (10.1.1.x)
16:12:27 <pc_m> BTW: I do see another bug, which I'll do as a follow up fix. Currently, you can create an IPSec connection and specify a peer IP that is IPv6, but may not have an IPv6 address on the router. It won't fail, but it won't work ether.
16:12:35 <sridhar_ram> like in OpenVPN
16:12:55 <sridhar_ram> or GRE
16:13:29 <pc_m> sridhar_ram: Not sure what that is, but the intent is to indicate the IP address for this end of the tunnel (as opposed to the 'peer IP'
16:13:33 <pc_m> )
16:13:42 <pc_m> sridhar_ram: Do you have an issue with the naming?
16:13:57 <pc_m> sridhar_ram: If so, do you have a better suggestion for the naming?
16:14:02 <sridhar_ram> perhaps this is a terminology, but it will confuse folks who handle vpn
16:14:36 <sridhar_ram> public tunnel IP
16:14:37 <pc_m> Today we have peer IP for the public facing IP on the far end, and peer CIDR(s) for the private far end subnets.
16:14:45 <sridhar_ram> that's what it is ..
16:15:05 <sridhar_ram> it used to be implicit, now you are taking it as an input
16:15:17 <pc_m> sridhar_ram: But I want to distingush that it is for the local and not peer end.
16:15:36 <pc_m> sridhar_ram: It is not an input. The user does not specify it.
16:15:59 <pc_m> sridhar_ram: It is determined by the service driver (so that different drivers can override).
16:16:20 <sridhar_ram> but it gets added to service table ?
16:16:32 <pc_m> sridhar_ram: Correct and is read-only
16:17:10 <sridhar_ram> okay. will read up more. we can also take it up further in the code review.
16:17:37 <pc_m> sridhar_ram: OK.
16:17:52 <pc_m> #topic Multiple Local Subnets
16:18:29 <pc_m> I replied to the comments. Please look at the RFE #link https://review.openstack.org/#/c/191944
16:18:56 <pc_m> I'll push another version, once I hear from some of the cores, and will roll up all the comments.
16:19:06 <sridhar_ram> sure, will do.
16:19:39 <sridhar_ram> again, are you considering this for post v3 ?
16:19:54 <pc_m> sridhar_ram: Regarding the naming... I was calling it endpoint-pairs, not to mean that there are only two locations involved, but to indicate that there is a set of 1+ local subnets and 1+ peer subnets.
16:20:20 <pc_m> We can call it endpoints, if that is clearer.
16:20:36 <sridhar_ram> that is better
16:20:43 <pc_m> I'm intending on implementing this ASAP, as soon as the RFE is approved.
16:20:45 <sridhar_ram> it is bit generic
16:20:55 <pc_m> I'd like to get it in for Liberty.
16:21:41 <pc_m> sridhar_ram: Thanks for reviewing!
16:21:51 <sridhar_ram> sure. one last question..
16:21:56 <pc_m> shoot
16:22:06 * pc_m or awe shoot :)
16:22:08 <sridhar_ram> what is the impact of existing device-drivers due to this addtion?
16:22:28 * sridhar_ram thinks this is more a review question!
16:23:54 <pc_m> sridhar_ram: good question. The drives would want to (possibly) be able to handle the multiple subnets that will be available.
16:24:35 <pc_m> I think for the Cisco implementation, there may be no change needed to support.
16:25:12 <pc_m> Not sure about others. For reference implementation it is a trivial change to add all the subnets to the leftside config item.
16:25:42 <sridhar_ram> (1) I'm assuming this is an optional step in vpn creation
16:26:10 <pc_m> yes, you can specify 1+ local subnets
16:26:17 <sridhar_ram> (2) if (1) is true, we shd try to preserve the dict flowing in the rpc so that existing drivers don't get affected
16:27:03 <pc_m> agreed, as a reviewer, you can make sure that I implement it as a new field for additional local subnets :)
16:28:17 <pc_m> I can add something to that affect to the RFE.
16:29:01 <pc_m> any other Qs on this one?
16:29:07 <sridhar_ram> nope
16:29:15 <pc_m> #topic Bugs
16:29:57 <pc_m> Please take a look at the open bugs and reviews (see the list on our wiki #link https://wiki.openstack.org/wiki/Meetings/VPNaaS)
16:30:59 <pc_m> Of note is one that came in yesterday, about VPN not working with an HA Router. I don't think anyone ever did anything to support that. Will likely be looking for an RFE and someone willing to implement support for this.
16:31:28 <pc_m> https://bugs.launchpad.net/neutron/+bug/1471940
16:31:28 <openstack> Launchpad bug 1471940 in neutron "VPNaaS Ipsec does not correctly determine master L3 HA Router" [Undecided,New] - Assigned to venkata anil (anil-venkata)
16:32:08 <pc_m> Anyone have any bugs of interest to discuss?
16:32:16 <pc_m> or reviews?
16:32:31 <sridhar_ram> yeah, I remember this coming up in DMVPN review ...
16:32:47 <sridhar_ram> good to know the state of VPN w/ HA router
16:33:12 <pc_m> FYI, the fix to migration head #link https://review.openstack.org/199082 mentioned previously.
16:34:02 <pc_m> #topic BGPVPN and Edge VPN
16:34:39 <pc_m> Not sure where we are on this...  could use some feedback on the multiple local subnet RFE that adds the endpoints API.
16:35:36 <pc_m> Does anyone have further discussion on this, or do we table it for a while, until the other VPN flavors progress further?
16:35:47 <mhanif> pc_m: I will look in to the RFE and provide any feedback on it.
16:36:08 <pc_m> mhanif: Thanks!
16:36:40 <pc_m> I'd like to get closure on that to move forward, but also would like to see if it can be useful for other VPN flavors.
16:37:02 <mhanif> pc_m:  Sure.  Got it.
16:37:28 <pc_m> Anything more on htis?
16:37:30 <pc_m> this?
16:37:51 <mhanif> Nothing from my side
16:38:03 <pc_m> #Open Discussion
16:38:25 <pc_m> Anyone have anything they want to discuss?
16:38:53 <sridhar_ram> none from me
16:39:16 <pc_m> Will close now, then. Thanks for joining in!
16:39:23 <pc_m> #endmeeting