16:05:38 <pc_m> #startmeeting vpnaas
16:05:39 <openstack> Meeting started Tue Jun  2 16:05:38 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:05:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:44 <openstack> The meeting name has been set to 'vpnaas'
16:06:09 <pc_m> Agenda is on the wiki: https://wiki.openstack.org/wiki/Meetings/VPNaaS
16:06:21 <pc_m> #topic announcements
16:06:49 <pc_m> Looks like Liberty 1 is 6/22-26, Liberty 2 7/27-31
16:07:11 <ajmiller> Wow, that's coming right up..
16:07:37 <pc_m> As usual, please look at the bugs and reviews for vpn (see the wiki for links).
16:08:03 <pc_m> I won't cover them today, we can discuss in open discussion, as time allows.
16:08:14 <pc_m> #topic BGP/MPLS and Edge VPN
16:09:06 <pc_m> So the question here is whether either/both of these can/should be combined into the general VPN (IPSec) w.r.t. how the user will use these.
16:09:25 <tmorin> pc_m: good summary
16:09:37 <pc_m> Should we try to make a unified API that can cover each of these? Does it make sense?
16:09:49 <vikram> pc_m:+1
16:09:54 <angela-s> pc_m +1
16:09:55 <john_a_joyce> I believe it would make sense
16:10:09 <dhruvdhody> pc_m:+1
16:10:20 <tmorin> the issue I see is that, while we could come up with common APi object...
16:10:29 <tmorin> ... the workflows will be totally different
16:10:34 <john_a_joyce> at least there are common elements to the two API proposals and with the current VPNaaS
16:10:39 <vikram> IMHO we should have a unified API but need to check how realistic it could be
16:10:40 <pc_m> So, I'll open the floor to let people discuss their thoughts...
16:10:59 <tmorin> this leads me to believe that a unified API may not necessarily add value
16:11:00 <sridhar_ram> pc_m: +1 for unified API, among class of VPNs
16:11:04 <tmorin> and might even increase confusion
16:11:14 <ajmiller> pc_m: As part of this it would be great to gather some use cases, that might help guide whether it makes sense for a unified API, or separate APIs
16:11:21 <pc_m> tmorin: Can you elaborate??
16:11:41 <pc_m> ajmiller: +1000 I myself am shaky on the understanding of each.
16:11:43 <tmorin> yes
16:11:54 <sridhar_ram> if IPSec is a L3 VPN that connects tenant networks to different remote networks.. it would make sense to unify
16:11:57 <john_a_joyce> IMO - there are two distinct elements of the APIs - the signaling of the routes and the details of the connection
16:12:01 <tmorin> in the use case and workflow in the BGP VPN API that we propose, the tenant is not independent, he cannot build the VPN himself
16:12:16 <sridhar_ram> but for L2 VPN .. we need one unified API for L2 VPN, IMO
16:12:17 <tmorin> he depends on the provider and cloud operator to first create this VPN
16:12:34 <tmorin> this is completely different from IPSec, or SSL, VPNs
16:12:42 <john_a_joyce> tmorin: so your API is more geared to how to signal the routes?
16:12:45 <sridhar_ram> john_a_joyce: +1
16:12:49 <tmorin> the acronyms are the same, but the model behing is very different
16:12:52 <angela-s> tmorin: that is the same for edge vpn, it is not a tenant role
16:13:00 <sridhar_ram> that is how dmvpn data model is emerging as well
16:13:24 <tmorin> john_a_joyce: not really, our API allows to describe to which BGP VPN a tenant network is connected
16:13:36 <pcarver> At the risk of broadening the topic even further, I just created an RFE for ML3, modular layer 3 similar in concept to ML2. It seems to me that BGP and IPSec/SSL VPNs have a close tie in to the concept of routers.
16:14:05 <tmorin> our API does not dictate how the routes are signalled
16:14:18 <tmorin> which component does this is determined by the driver/backend architecture
16:14:24 <john_a_joyce> tmorin: sure and you don't get into too much detail on how the connection/tunnel is created
16:14:38 <tmorin> indeed
16:15:02 <john_a_joyce> tmorin:  but you are indicating the routing relationship i.e. VPN - to network
16:15:07 <tmorin> yes
16:15:35 <john_a_joyce> tmorin: so that is what I really like about your API - it is simple at that level
16:15:37 <tmorin> setting up so-called "tunnels" is most often not even done at all
16:15:50 <tmorin> yes, this is the goal
16:16:19 <tmorin> if other things (e.g. BGP peerings) need to be automated, we think this is a different issue to be handled with another component
16:16:27 <tmorin> may or may not even by in openstack
16:16:33 <john_a_joyce> tmorin:  but when you get in the semantics of the connection itself then it merges with the other work edge, VPNaaS and maybe dmvpn
16:16:52 <tmorin> it may, but as I said, the workflow may or may not converge
16:17:01 <sridhar_ram> tmorin: could creating the "tunnel" (or the equivalent) and pushing the routes could be separated ?
16:17:04 <tmorin> I don't think they do for IPSec
16:17:23 <tmorin> sridhar_ram: yes
16:17:23 <john_a_joyce> sridhar_ram: that is exactly what I was thinking
16:17:39 <tmorin> sridhar_ram: sometimes you don't even have a tunnel in the implementation, so yes, for sure
16:17:42 <john_a_joyce> IMO that gives a path to convergence
16:18:09 <sridhar_ram> tmorin: I see. Still we need something to model the VPN construct
16:18:37 <sridhar_ram> tmorin: Here is my worry .. we might end up with an explosion of tons of APIs for each and every VPN type
16:18:50 <john_a_joyce> that would be bad
16:18:52 <pc_m> sridhar_ram: +1
16:19:00 <tmorin> tons I don't know
16:19:11 <vikram> from the user view this is not good
16:19:19 <tmorin> and if the workflow behind is stronly distinct, having more than one makes sense
16:19:19 <angela-s> sridhar_ram: +1
16:19:22 <vikram> having separate api for diff usecase
16:19:29 <sridhar_ram> Can the tunnel creation part atleast for these PE based VPNs be extraploated to something common ?
16:19:52 <pcarver> isn't the most important thing from the user's perspective the networks and routers in Neutron/OpenStack that they want to add connectivity too? The mechanism is secondary.
16:19:55 <tmorin> vikram: no, i believe it makes sense to have different APIs if the use case and workflows are different enough
16:20:21 <john_a_joyce> tmorin:
16:20:28 <pcarver> BGP MPLS vs IPSec/SSL are just the details of how to connect
16:20:30 <tmorin> sridhar_ram: again, with BGP VPN, we don't need to instantiate tunnel objects at all
16:20:35 <tmorin> nothing to converge here
16:20:41 <john_a_joyce> tmorin: we should look at the high level what is common
16:20:58 <sridhar_ram> pcarver: Associating the VPN use are creating to tenant networks is understood.. IPSec has a working model and it works well IMO
16:21:01 <tmorin> three letters :)
16:21:03 <john_a_joyce> i think we are agreeing the tunnel part is likely not common
16:21:27 <tmorin> john_a_joyce:  three letters may be the only thing in common  (V,P,N)
16:21:34 <john_a_joyce> but the association or networks/routes to VPNs can probably be made common
16:21:50 <sridhar_ram> tmorin: But there shd be some representation of the "entity" that you want neutron network to talk to ..
16:21:56 <pcarver> sridhar_ram: That's good. My point is that it should work consistently. If it works well for IPSec then we should see if it can work the same way for MPLS.
16:22:23 <tmorin> sridhar_ram: well, it does not necessarily belong to this API
16:22:42 <tmorin> sridhar_ram: it can be config driver, or an admin-only API if you want to API-drive it
16:22:52 <tmorin> config-driven sorry
16:23:04 <sridhar_ram> tmorin: in IPSec site-connection IMO represents the what is entity being created and how routes are pushed
16:23:05 <tmorin> john_a_joyce: yes, possibly
16:23:43 <tmorin> the current model for IPSec (associating to routers) does not work well for l2 BGP VPNs (E-VPN)
16:24:11 <sridhar_ram> tmorin: thats exactly where some of need to be educated :)'
16:24:35 <sridhar_ram> *some of us
16:24:40 <vikram> Hi All, I think we are off track.. The discussion was about converging edge-vpn and BGPVPN API's. What's the conclusion on this?
16:25:04 <tmorin> sridhar_ram: well, quite simply: if you extend an Ethernet network through a bgpvpn, you don't want to go through an IP stack
16:25:39 <john_a_joyce> i think the majority think we need to try harder to converge
16:25:42 <sridhar_ram> tmorin: the admin vs tenant API restriction is well taken ... it can be factored in the API permission
16:25:49 <john_a_joyce> trying to find the common parts
16:25:55 <pcarver> tmorin: I don't think it's just some letters in common. I think that the most basic aspect from a tenant view point is that I've got some networks here and some networks there and I want to connect them. Ideally the only difference in the "how" is what data elements I need to supply in order to state "which network do I want to connect to"
16:26:12 <sridhar_ram> pcarver: +1
16:26:20 <john_a_joyce> pcarver: +1
16:26:22 <pc_m> pcarver: +1
16:26:22 <angela-s> pcarver: +1
16:26:33 <vikram> pcarever: +1
16:26:38 <tmorin> pcarver: well, how the vpn network is created is not always done the same, hence different workflows
16:26:57 <sridhar_ram> tmorin: then should we work on a common L2 VPN framework first
16:27:11 <pcarver> tmorin: no disagreement on that. But I don't think that's important to the tenant.
16:27:11 <sridhar_ram> and then factor in different L2 VPN instantiations off that ?
16:27:37 <tmorin> having converged API object but a different workflow will *not* be user friendly
16:27:40 <john_a_joyce> tmorin: do you mean the details on the transport and signalling protocols?
16:27:44 <pcarver> The tenant wants to know what identifiers do I need to supply to uniquily specify what network.
16:27:51 <pcarver> Not how the plubming works
16:28:03 <tmorin> sridhar_ram: i think this part of the discussion is true for both l2vpn and l3vpn
16:28:21 <john_a_joyce> what seems common to me is that you are conveying which networks are inter-connected in all the proposals
16:28:40 <tmorin> pcarver: for ipsec VPNs, the tenants needs to know about the plumbing to configure its endpoints
16:28:51 <tmorin> john_a_joyce: yes
16:29:11 <tmorin> john_a_joyce: that could also be expressed through a generic poliy framework by the way
16:29:42 <matrohon> the only components that converge seem to be a VPN dummy object, its type and object we can associate to it (depending on the type) no?
16:30:09 <tmorin> pcarver: for ipsec, the tenant creates and configures the plumbing -- that's a major difference
16:31:37 <sridhar_ram> Having a class of VPN created by Admin and used by Tenant can be abstracted
16:31:54 <pcarver> tmorin: It's been a while since I configured VPNs on Cisco routers (and that's the last place I dealt with IPSec) but even then pretty much all I wanted to know was what 3-4 bits of data did I need to plug into the router config to connect to my peer.
16:32:23 <pc_m> could the vpn be characterized by its endpoints and the "type" of connection?
16:32:38 <tmorin> pcarver: yes, indeed, this is the plumbing part that has to be at the hand of the tenant
16:32:43 <pc_m> then for each type, we have API for the details?
16:33:42 <pc_m> For IPSec one specifies the peer IP, peer CIDRs (of remote subnets), and then IPSec features via IKE/IPSec policies
16:33:49 <pcarver> tmorin: I don't think I'm disagreeing with you much. Just trying to frame the "user story"
16:34:10 <pcarver> The tenant will certainly need to supply different data elements for IPSec vs MPLS
16:34:25 <tmorin> I fear the common part will boil down to very trivial things
16:34:30 <tmorin> hence my skepticism
16:34:49 <pc_m> tmorin: Can the endpoints be specified as part of the common part?
16:34:50 <tmorin> at least for what is common bw bgp vpns and ipsec vpns
16:35:01 <tmorin> maybe more convergence can exist for dmvpn
16:35:02 <sridhar_ram> pc_m: IPSec is can put IKE/IPSec/remote-IP in one bucket and put { local tenant networks, remote CIDRs } .. thats a even clear mental model
16:35:11 <pcarver> but in either case their desired workflow really centers around determining the minimal set of required data elements to designate the near and far networks
16:35:20 <tmorin> i'd be happy to hear more on the workflow proposed around dmvpn
16:35:24 <sridhar_ram> If we can come up with something similar for other VPN types..
16:35:31 <tmorin> pc_m: which endpoints ?
16:35:54 <sridhar_ram> tmorin: sure, we will go into dmvpn shortly..
16:35:56 <john_a_joyce> sridhar_ram:  thats exactly the mental model I have as well
16:36:18 <tmorin> pcarver: yes, but this is the last step of the workflow, the vpn creation step differs highly (between ipsec and bgp provider vpns)
16:36:56 <pc_m> tmorin: Like for IPsec, it's the peer and local IP (or maybe the peer and local subnets?)
16:38:25 <sridhar_ram> tmorin: then, atleast among the VPNs created in PE routers we need one model
16:38:27 <tmorin> pc_m: you mean BGP peer ?
16:39:14 <vikram> pc_m: For BGPVPN yes we need to specify bgp  peer ip
16:39:23 <tmorin> sridhar_ram: this is a possibility, but not knowing enough on DMVPN, i don't know yet
16:39:42 <tmorin> vikram: I don't believe so, or at least not in the same API
16:39:46 <pc_m> thinking out loud... is there a way to specify the two  networks being connected up, and then specify the connection details separately, based on the type of VPN?
16:40:01 <tmorin> vikram: the BGP peer is not setup per VPN
16:40:38 <tmorin> vikram: different bgp speakers may also use different ones
16:40:48 <vikram> tmorin: but we need to specify the end-points between which we need to have a VPN connection right?
16:40:59 <tmorin> vikram: if you want to automate this, you can do it with another API, or static, or part of server automation tooling
16:41:14 <tmorin> vikram: what do you mean by endpoints ,
16:41:16 <tmorin> ?
16:41:36 <sridhar_ram> tmorin: DMVPN is created on tenant routers for tenant networks .. it kinda a extenstion of IPSec (instead of site to site it is multi-site)
16:41:45 <vikram> tmorin: 2 sites which user want to connect
16:41:51 <tmorin> pc_m: yes, there could be, but what about the value if the workflows end up so different
16:42:29 <sridhar_ram> tmorin: bringing in BGP speaker differences in API discussion doesn't make sense
16:42:42 <tmorin> vikram: the sites which the user want to connect are not the BGP peers, there may be more than 2, and its ok if there are not known by the API, they will learned via BGP routes
16:42:50 <pc_m> tmorin: I guess it gets back to (for me) understanding the various use cases for each type of VPN.
16:43:05 * pc_m which I sorely lack understanding of
16:43:24 <tmorin> sridhar_ram: does the tenant have to configure routers to connect (non Openstack) physical sites, or is it at the hand of its provider ?
16:44:03 <sridhar_ram> tmorin: there is no non-openstack interaction involved for DMVPN..
16:44:09 <vikram> tmorin: got it
16:44:24 <john_a_joyce> tmorin: if by workflow you mean the backend implementation then I don't follow the argument since that will be very different anyway
16:44:25 <ajmiller> pc_m tmorin: That gets to the heart of it:  We need a common understanding of the various use cases, how tenants and operators configure them.  Who does what, and how.
16:44:34 <sridhar_ram> tmorin: if needed you can connect multiple openstack tenant routers in a DMVPN mesh
16:44:40 <vikram> tmorin: actually i meant sites to be connected..
16:44:43 <sridhar_ram> no PE router involved
16:44:48 <tmorin> sridhar_ram: DMVPN can be used outside any Openstack, right ??
16:45:10 <john_a_joyce> there might be reference implementations in tree and some out and of course many that rely on a controller to render the network
16:45:19 <tmorin> john_a_joyce: no, I essentially means: who creates and controls the parameters for the VPN
16:45:36 <sridhar_ram> tmorin: yes, other remote sites could be non-openstack sites -- imagine a Cisco branch site
16:46:47 <john_a_joyce> tmorin: I am missing the point a bit then - the parameters of the VPN should be in the API
16:46:58 <tmorin> sridhar_ram: ok, but you can also want to connect an existing "WAN" DMVPN to some Openstack VM/network, right ?
16:47:09 <sridhar_ram> john_a_joyce: that in-built control-plane vs sdn controller option is same like any other neutron driver
16:47:42 <tmorin> john_a_joyce: yes, but in the ipsec case controlled by the tenant, and in the bgp vpn case controlled by the admin
16:47:56 <sridhar_ram> tmorin: that existing "WAN" DMVPN node is not under the administrative preview of OpenStack
16:47:57 <tmorin> sridhar_ram: +1
16:48:56 <tmorin> sridhar_ram: ok, for BGP VPNs we want the ability to interconnect with existing WAN BGP VPNs, and need to bring this into view of Neutron
16:48:57 <john_a_joyce> but if it is simply an issue or roles that is preventing convergence then that is easily handled
16:49:41 <sridhar_ram> tmorin: I understand that unique nature and its different compared to neutron-router based VPN (IPSec, DMVPN)
16:49:55 * pc_m time check 10 mins
16:50:28 <tmorin> john_a_joyce: can be handled, but workflows will be so different that I'm challenging that converging (ipsec and bgp vpns) will bring  much value (and might even increase confusion)
16:50:39 <sridhar_ram> tmorin: we should think hard to model that interconnection of existing WAN VPN (i'm intentionally skipping BGP) to neutron networks
16:51:03 <tmorin> sridhar_ram: ok, good to know that our understanding is that DMVPN would be closer to IPSec that bgpvpn
16:51:03 <sridhar_ram> tmorin: BGP should be just one type
16:51:28 <john_a_joyce> pc_m: I think we might need a specific proposal to further this discussion
16:51:33 <tmorin> sridhar_ram: not sure I follow you
16:51:54 <sridhar_ram> if we can model BGP related constucts to similar to IKE (which is IPSec specific) ..
16:52:36 <sridhar_ram> and have a generic "interconnect" API for vpn-id to neutron network id mapping
16:52:55 <sridhar_ram> that later will be same for many differnent WAN / PE Router based VPNs
16:52:56 <sridhar_ram> ?
16:53:12 <pc_m> folk, we're starting to run shy of time here... let's focus on what we should do forward going to try to close on this (if possible :)
16:53:13 <john_a_joyce> Sridhar_ram: +1
16:53:20 <pc_m> sridhar_ram: +1
16:53:27 <pc_m> So...
16:53:41 <pc_m> I've created an etherpad, so we can place our thoughts...
16:53:53 <pc_m> #info https://etherpad.openstack.org/p/vpn-flavors
16:53:53 <vikram> pc_m:+1
16:53:59 <sridhar_ram> pc_m: good idea
16:54:23 <pc_m> Can someone volunteer to plop down use cases for each of the VPN types?
16:54:46 <pc_m> (not one person, but several people for each flavor of VPN)
16:54:56 <sridhar_ram> I can pitch in for neutron-router based VPN
16:55:04 <vikram> Edge VPN i can take up
16:55:09 <pc_m> sridhar_ram: thanks
16:55:10 <tmorin> sridhar_ram: this is doable, but I fear that the difference in the first steps of the workflows would create confusion
16:55:13 <pc_m> vikram: nice
16:55:27 <pc_m> I think it'll help our shared understanding...
16:55:43 <pcarver> I'll schedule some time with one of our MPLS gurus and try to consolidate his thoughts into input for the Etherpad
16:55:45 <tmorin> yes, that was a useful discussion
16:55:50 <tmorin> thanks pc_m for hosting it
16:56:03 <john_a_joyce> thanks pc_m
16:56:07 <sridhar_ram> pc_m: pcarver: thanks!
16:56:07 <tmorin> pcarver: +1
16:56:28 <sridhar_ram> i'm learning here as well.. !
16:56:34 <tmorin> will contribute based on what we already have written in our current spec
16:56:35 <ajmiller> It would also be great if people could add pointers for useful background information, like wiki pages, RFCs, etc....
16:56:45 <ajmiller> I'll contribute to the extent I can.
16:56:49 <pc_m> yes thanks everyone. Let's keep this going and see if we can come up with a proposal to share
16:56:49 <tmorin> there are rfc pointers in our spec
16:56:56 <tmorin> 4364 and 7432 mostly
16:57:03 <ajmiller> tmorin cool
16:57:06 <vikram> ajmiller: sure
16:57:07 <tmorin> makes good fireplace reading ;)
16:57:09 <pc_m> ajmiller: pcarver thanks!
16:57:22 <tmorin> bye folfs
16:57:24 <tmorin> folks
16:57:25 <pc_m> I have been having trouble sleeping at night...
16:57:26 <ajmiller> bye
16:57:26 <dhruvdhody> bye
16:57:26 <john_a_joyce> bye
16:57:30 <pc_m> thanks everyone!
16:57:31 <sridhar_ram> tmorin: RFC are always good for bedtime !
16:57:33 <pc_m> #endmeeting