16:04:14 <pc_m> #startmeeting vpnaas
16:04:15 <openstack> Meeting started Tue Jun  9 16:04:14 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:04:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:19 <openstack> The meeting name has been set to 'vpnaas'
16:04:58 <pc_m> #topic Announcements
16:05:50 <pc_m> There is a change to merge the Fedora strongswan into strongswan driver. See #link https://review.openstack.org/#/c/189611/
16:05:59 <pc_m> No other announcements.
16:06:12 <pc_m> #topic bugs
16:06:43 <pc_m> Please look at the open reviews #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-vpnaas,n,z and provide feedback to committers.
16:07:13 <pc_m> Any bugs that warrant discussion right now, or can we skip that this week?
16:07:49 <sridhar_ram> pc_am: For me Scenario test is an important one
16:08:14 <sridhar_ram> pc_m: will review that for sure
16:08:51 <pc_m> sridhar_ram: please do. I haven't looked at it in a while, but I think it is failing tests just recently (#link https://review.openstack.org/159746)
16:09:25 <pc_m> not sure what changed (as same patch set).
16:09:50 <pc_m> If anyone has any ideas, let Nikolay know.
16:10:15 <pc_m> #topic Multiple Subnets
16:10:42 <pc_m> RFE was submitted. Waiting for Drivers Team to review and see if BP is needed.
16:10:53 <pc_m> One question for the group...
16:11:11 <pc_m> Should we require that the local subnets all have the same IP version?
16:11:42 <pc_m> OK, two questions... Should we require that local and peer subnets have the same IP version?
16:12:01 <pc_m> Currently, there is no restriction.
16:12:19 <sridhar_ram> pc_m: I think so. Mixing versions is an unchartered territory IMO
16:12:32 <pc_m> sridhar_ram: That's what I was thinking.
16:12:57 <ajmiller> Unless someone can thing of a valid reason we would want to allow different versions, I think we should restrict them to be the same.
16:13:16 <pc_m> #info Will validate that subnets (local and peer) are of the same IP version for IPSec connections
16:13:17 <ajmiller> Restrictions can be relaxed in the future if appropraite...
16:13:29 <pc_m> #topic Certificates
16:13:31 <john_a_joyce> pc_m: so if you had a dual stack network you would create two tunnels?
16:13:39 <pc_m> #undo
16:13:40 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x965f590>
16:14:30 <pc_m> john_a_joyce: For now yeah. Is that OK?
16:14:56 <john_a_joyce> pc_m: I guess it is ok for now if it keeps things simpler
16:15:31 <john_a_joyce> pc_m: if the restriction will be difficult or impossible to remove later we should think harder about whether it is really needed
16:15:45 <pc_m> john_a_joyce: Well, two approaches... validate and reject if mixed types, or leave it and some implementation may not work right.
16:16:00 <pc_m> thoughts?
16:16:27 <john_a_joyce> pc_m:  I am ok rejecting provided it isn't encoded in the API in anyway
16:16:40 <john_a_joyce> pc_m: we want this to work first
16:16:48 <pc_m> john_a_joyce: It would be part of validation.
16:17:07 <pc_m> not part of API at all.
16:17:50 <john_a_joyce> pc_m: probably that is good then reject for now if mixed.  You can always create a second tunnel for the Ipv6 subnets.
16:18:18 <sridhar_ram> john_a_joyce: +1
16:18:25 <pc_m> We could lift it, once we test dual stack (if ever :)
16:19:11 <john_a_joyce> pc_m: I hope we test dual-stack early - you saw the number v6 presos at the summit
16:19:29 <pc_m> Let's employ the restriction. We can always remove it later, and have a work-around for dual stack.
16:19:39 <john_a_joyce> pc_m: ignore that I now understand what you meant
16:20:17 <pc_m> john_a_joyce: It is true though, there has been little IPv6 testing at all, let alone dual-stack.
16:20:28 <pc_m> Something that is needed across the board.
16:21:02 <pc_m> Any volunteers to write IPv6 tests? :)
16:21:03 <ajmiller> pc_m agreed, the general state of IPv6 testing leaves a lot to be desired.
16:21:31 <pc_m> #topic Certificates
16:21:47 <pc_m> I did a RFE and am waiting for Drivers Team review.
16:21:56 <pc_m> Been researching it a bit.
16:22:26 <pc_m> Does anyone know what certificate types should be supported? any besides X.509?
16:22:26 <sridhar_ram> pc_am: link for the RFE ?
16:22:52 * pc_m lacking in knowledge of all the authentication methods for VPN.
16:23:19 <pc_m> #ilnk https://bugs.launchpad.net/neutron/+bug/1459427
16:23:20 <openstack> Launchpad bug 1459427 in neutron "VPNaaS: Certificate support for IPSec" [Undecided,New]
16:23:45 <pc_m> Here's the multiple subnet one https://bugs.launchpad.net/neutron/+bug/1459423
16:23:47 <openstack> Launchpad bug 1459423 in neutron "VPNaaS: Allow multiple local subnets for IPSec" [Undecided,Confirmed]
16:23:54 <sridhar_ram> pc_m: thanks!
16:24:05 <john_a_joyce> pc_m: I may be able to help with the IPv6 tests - so a soft volunteer for now
16:24:26 <pc_m> #action john_a_joyce able to help some with IPv6 tests
16:24:32 <pc_m> thanks john_a_joyce
16:25:04 <pc_m> If anyone has experience with the certificate stuff, please let me know... could use some help there.
16:25:33 <ajmiller> pc_m regarding certificate support, a place to start might be to compare with neutron-lbaas, which at least has a starting point for SSL/TLS certs using Barbican:
16:25:37 <ajmiller> #link https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
16:25:58 <pc_m> Also, in the future we should probably consider moving the auth info out of the connection object and into another table, so that it can be used by other VPN types.
16:26:23 <pc_m> ajmiller: Yeah, I've been looking at what they have. Seems like TLS X.509 certs
16:26:36 <ajmiller> yes
16:27:06 <pc_m> Just didn't know if there were other certificate types we should handle
16:27:18 * pc_m heck, not even sure what ones exist :)
16:27:22 <ajmiller> I don't know either
16:27:50 <pc_m> #action pc_m post to ML asking about certificate support for VPN
16:28:16 <pc_m> Will ask on ML to see. Please chime in, if you have ideas.
16:28:26 <pc_m> #topic DM VPN
16:28:41 <pc_m> Please look at sridhar_ram's review
16:29:01 <pc_m> https://review.openstack.org/#/c/181563/
16:29:06 <sridhar_ram> pc_m: network-id is the only outstanding item
16:29:22 <sridhar_ram> if you and yanping can sign off on that .. I think we are good (IMO)
16:30:21 <yanping> Have you looked Open NHRP? How it defines NHRP domain?
16:30:28 <pc_m> I was wondering if tunnel-key can be used for network-id, or if we should have both fields in the database.
16:30:52 <sridhar_ram> yanping: there is no attr simlar to network-id required for OpenNHRP
16:31:00 <sridhar_ram> pc_m: that is perfectly valid usage
16:31:18 <pc_m> sridhar_ram: to combine them?
16:31:32 <sridhar_ram> pc_m: as I mentioned in the review.. many Cisco dmvpn examples use the same value for both network-id and tunnel  key
16:31:40 <pc_m> yanping: Would that work for you?
16:31:44 <yanping> I am not sure about that.
16:32:14 <sridhar_ram> yanping: I provided a link to Cisco doc.. where all the examples use the same value
16:32:26 <pc_m> #action yanping to see if network-id can use tunnel-key  field, or if separate fields are needed
16:32:37 <pc_m> yanping: Made an action item for you :)
16:32:49 <yanping> I’ll take a look and confirm.
16:33:00 <pc_m> yanping: super. then we can close this out.
16:33:38 <pc_m> Anything else on DM VPN? Please check out the spec.
16:33:39 <sridhar_ram> pc_m: is there any deadline to have this approved, like L1 ?
16:33:49 <pc_m> No. No more deadlines.
16:34:01 <sridhar_ram> pc_m: this being not a RFE is fine ?
16:34:08 <pc_m> If it is done in time, it goes in.
16:34:37 <sridhar_ram> pc_m: that's what I thought, wanted to confirm
16:34:40 <pc_m> sridhar_ram: yes. RFE will be used after L-1. I just did it for mine, as they were new.
16:34:49 <sridhar_ram> pc_m: sure
16:35:06 <pc_m> #topic API convergence - BGP VPN
16:35:40 <pc_m> OK, so I think the goal here is to explore whether or not there is some commonality in BGP VPN and VPNaaS that can be converged.
16:36:08 <pc_m> We've got about 20 mins. What are our objectives for today?
16:36:19 <matrohon> pc_m : I submitted the use case in https://etherpad.openstack.org/p/vpn-flavors
16:36:27 <pc_m> matrohon: Thanks!
16:36:31 <matrohon> as other did
16:36:37 <pc_m> Yeah I wanted to mention that.
16:37:01 <pc_m> Feel free to add your thoughts, comments, questions to that etherpad.
16:37:41 <pc_m> Do we want to try to discuss where there are possible commonalities?
16:37:47 <pc_m> john_a_joyce: matrohon?
16:38:01 <john_a_joyce> There is at least some consensus that there is overlap between the use cases
16:38:12 <john_a_joyce> certainly not complete overlap
16:38:51 <john_a_joyce> i thought we seemed to be converging that there two aspects - the networking details of what is to be connected
16:39:08 <john_a_joyce> and then details on how the "pipe" is setup to connect them
16:40:07 <matrohon> the only  overlap I see for the end user/tenant : he can attach some object to the VPN, but cannot create the VPN
16:40:09 <sridhar_ram> john_a_joyce: yeah, in the "interconnect" from tenant network to PE router seems like a common capability
16:40:11 <john_a_joyce> the current VPNaaS APi seems to have a decent split - the IPSEC tunnel details
16:40:27 <john_a_joyce> and then the subnets
16:42:03 <pc_m> so commonality is the "what is connected"?
16:42:15 <matrohon> we could have the same split with bgpvpn connection, replacing the IPSEC tunnel details, with "the BGPVN tunnel details"
16:42:44 <john_a_joyce> matrohon: that is along the lines of what I was thinking as well
16:43:12 <sridhar_ram> matrohon: yeah, creating a particular PE VPN flavor (BGP in this case) is one basket
16:43:25 <sridhar_ram> *could be in one basket
16:43:48 <sridhar_ram> now the id returned by that 'create' need to 'attached' to neutron network
16:43:48 <john_a_joyce> srihar_ram: +1
16:44:09 <sridhar_ram> that attachment shd be done in some common way ...
16:44:25 <sridhar_ram> as other PE VPN types would need the exact same thing
16:44:34 <ajmiller> +1
16:44:46 <john_a_joyce> srihar_ram: exactly my thoughts as well
16:45:32 <matrohon> I'm afraid I'm the only one who doesn't understand clearly previaous sentences :(
16:45:42 <sridhar_ram> matrohon: it will be nice of you can rework BGP VPN along these lines and help to define a common 'interconnect' part that will be awesom
16:45:47 <pc_m> matrohon: I'm digesting them too.
16:46:21 <pc_m> So one part is the details of the tunnel itself. Do we all agree that it is VPN type specific?
16:46:39 <angela-s_> yes, VPN specific
16:46:47 * pc_m trying to agree on the simple stuff
16:46:56 <john_a_joyce> I think it is really splitting it in two:  1: the mechanics of how I connect these elements (networks in this case)
16:46:57 * pc_m :)
16:47:04 <sridhar_ram> pc_m: agree !
16:47:23 <john_a_joyce> 2: which elements (e.g. networks) the tenant is dealing with
16:47:31 <ajmiller> matrohon I agree with the principle, and think it can be possible, but am by no means fully understanding whether it can actually be done...
16:47:47 <matrohon> pc_m : agree too
16:48:14 <sridhar_ram> pc_m: matrohon: the key difference we are reiterating is the IPSec, and perhaps DMVPN, are directly implemented in the network node .. so the interconnection to neutron network is implicit..
16:48:49 <sridhar_ram> whereas the PE router based VPN is originated off another box outside OpenStack
16:49:12 <sridhar_ram> the bridge from network-node to this other box need to be codified
16:49:28 <matrohon> sridhar_ram : here, I do not agree : with the bagpipe current implementation, each compute node is seen as a PE
16:49:29 <pc_m> john_a_joyce: Do you mean the "what is connected" is split into two?
16:49:45 <john_a_joyce> pc_m: no
16:50:13 <matrohon> sridhar_ram : this is the scope of edge vpn I think
16:50:45 <john_a_joyce> pc_m: same thought as you leave the details of the tunnel separate
16:51:27 <sridhar_ram> matrohon: frankly I don't care the actual vpn type - bgp / edge / something else
16:52:21 <sridhar_ram> matrohon: with bagpipe being in each compute .. how does the network-node connected to these bagpipe in each compute ?
16:52:33 <matrohon> sridhar_ram : +1 :) but I meant that this is the main diff between edge vpn proposal and the bgpvpn one;
16:52:40 * sridhar_ram need to understand the bgpvpn driver impl
16:53:57 <john_a_joyce> matrohon: I did not understand your last statement
16:54:17 * pc_m still a bit lost.
16:54:25 <matrohon> sridhar_ram : it's implem details :) but shortly, as soon as you want to speak to an address learn by bgp, traffic is sent directly to the learn NH, from the compute node
16:55:26 <sridhar_ram> matrohon: NH stands for ?
16:55:34 <matrohon> next hop
16:56:06 <sridhar_ram> NH is the PE router ?
16:56:28 <matrohon> I feel we really need to write down some diagram about the ref implem (bagpipe) details :)
16:56:37 <john_a_joyce> matrohon:  I think maybe I am starting to understand the challenge
16:56:39 <pc_m> matrohon: Yes please!
16:56:48 <sridhar_ram> matrohon: Yeah, we need a diagram, we need a diagram, we need a diagram!
16:57:02 <john_a_joyce> most of the other proposals need to specifically get the tunnel/connection details from the user
16:57:04 <matrohon> #action : matrohon to write some diagram of the bagpipe bgpvpn implementation
16:57:22 <pc_m> matrohon: Awesome!
16:57:25 <john_a_joyce> where bagpipe implicitly knows how to send the pack to the NH
16:57:47 <matrohon> john_a_joyce : +1
16:57:58 <sridhar_ram> I was trying hard to get all dumb questions out .. but failed ;-)
16:58:15 <john_a_joyce> so you only need to know which networks get inter-connected not how the plumbing will interconnect them
16:58:26 <matrohon> john_a_joyce : +1000
16:58:36 <pc_m> We've about out of time. Can folks add content to the etherpad.  I think I understand that one part is the details of the connection, but I don't yet grasp the other part.
16:58:43 <matrohon> this is why the API is so simple
16:59:13 <john_a_joyce> ok - but i still think we can have common ground as the 1 part you need is also needed by all the other csaes as well
16:59:18 <matrohon> bgp will handle control plane details for iinterconnection
16:59:43 <john_a_joyce> let me think about it a bit more and maybe put something in the etherpad
17:00:04 <pc_m> Please plop down your understanding/questions/notes on the etherpad. We've got to close out.
17:00:07 <pc_m> #endmeeting