15:07:41 <matrohon> #startmeeting bgpvpn
15:07:42 <openstack> Meeting started Tue Aug 18 15:07:41 2015 UTC and is due to finish in 60 minutes.  The chair is matrohon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07:45 <openstack> The meeting name has been set to 'bgpvpn'
15:08:21 <matrohon> we have few design topics today, that I'd like to discuss
15:08:46 <matrohon> topic : service plugins vs service providers
15:08:49 <matrohon> #topic : service plugins vs service providers
15:10:08 <matrohon> as mentioned in https://bugs.launchpad.net/bgpvpn/+bug/1485515, I considered moving back from the service provider framework to the service plugin framework
15:10:08 <openstack> Launchpad bug 1485515 in bgpvpn "multiple service drivers can't coexist" [Undecided,New]
15:10:14 <svinota> oh. Almost missed
15:10:23 <matrohon> svinota : hi
15:10:29 <svinota> matrohon, hi
15:10:59 <matrohon> this would mean that each backend would implement its own plugin and the extension it supports
15:11:02 <pcarver> matrohon: I saw that you sent an email on that bug, but haven't read it yet
15:11:53 <matrohon> Actually, I'm not sure if mixing service provider for the bgpvpn plugin make sense, and answers any use case
15:12:30 <amotoki> hi, I am not an usual member of this meeting though.
15:13:03 <amotoki> for service provider, I have two questions.
15:13:05 <janscheurich> What would be the consequences for API users: Can they discover extension support?
15:13:11 <pcarver> Ok, skimmed through it quickly and first impression is that this relates to some of the ML3 discussion we had a while back
15:13:17 <matrohon> I discussed with pc_m and dougwig earlier and dougwig encourage us to keep using the service provider framework since horizon is aware of the framework
15:14:09 <amotoki> re horizon impl, it is service by service, so it is not a big matter.
15:14:20 <matrohon> janscheurich : there would be no consequences, API would be the same, be the cloud provider couldn't mix several backends
15:14:36 <matrohon> amotoki : ok thanks for the clarification
15:15:13 <matrohon> amotoki : I saw that the flavor framework has merged in neutron recently
15:15:30 <matrohon> amotoki : is there a related work in progress in horizon?
15:15:33 <pcarver> In principle we dislike the idea of having an entire cloud locked in to a single vendor, but in practice it seems very difficult to picture exactly how multiple L3 service providers could coexist. Defining the boundaries is the challenge.
15:15:51 <amotoki> matrohon: yes. it can be consumed by various services
15:15:52 <matrohon> pcarver : +1
15:16:10 <pcarver> In the ML3 discussion we talked about leveraging the flavor framework to essentially have "flavors of routers"
15:16:20 <matrohon> amotoki : do you have any links?
15:16:38 <amotoki> marcusvrn_: link about what?
15:17:06 <matrohon> amotoki : about horizon implementation for the flavor framework?
15:17:42 <amotoki> ah.. got it. regaring horizon implementation, it will be service by service.
15:17:47 <pcarver> I can certainly imagine wanting to have freedom to implement some L3 on Cisco Nexus and other L3 on Juniper MX (perhaps with a shared VXLAN L2 interconnecting them)
15:18:09 <pcarver> But it's more challenging to imagine a scenario with some L3 on Contrail and other L3 on ODL
15:18:44 <matrohon> pcarver : and others on Nuage, exactly...
15:18:56 <amotoki> horizon panel for each service will just have a "flavor " instead of "provider" in LBaaS v1 now. there is no progress AFAIK
15:19:29 <amotoki> so it means we can just discuss flavor framework support only from API perspective.
15:19:32 <pcarver> matrohon: Right, just listing some names for concreteness but not limiting discussion to those examples
15:20:36 <amotoki> pcarver: if some setvice plugin cannot coexist with other plugin/driver, they can choose a service plugin rather than a driver.
15:20:41 <matrohon> amotoki : ok I see. the admin can't match service provider to service plugin through horizon?
15:20:53 <matrohon> amotoki : ok I see. the admin can't match service provider to service flavors through horizon?
15:21:26 <amotoki> matrohon: what I am talking is just about user API
15:21:42 <matrohon> amotoki : that's exactly the state of my thoughs currently
15:21:49 <amotoki> we can have more GUI for admin to map privider to flavor.
15:22:09 <matrohon> amotoki : but it's not implemented currently?
15:22:28 <amotoki> matrohon: we have no impl now
15:22:38 <matrohon> amotoki : ok thanks
15:24:25 <matrohon> so i'm not sure we could conclude about service plugin vs service providers...
15:24:51 <amotoki> regarding VPNaas and service provider, i have a question: VPNaaS APi is different per VPN type (e.g., IPsec/ BGPVPN), so I wonder we should have service provider per VPN type, or per VPN as a whole.
15:24:52 <matrohon> I lean toward the service plugin implementation for its simplicity
15:25:45 <amotoki> IMHO we can have service provider for IPsec VPN, but I wonder how we can achieve service provider for a whole VPNaaS.
15:26:01 <janscheurich> But will a service plugin approach make it harder for BGPVPN to become part of core Neutron at some point?
15:26:56 <pc_m> amotoki: good question
15:27:12 <matrohon> amotoki : we could have a plugin taht implement both IPSec plugin interface and bgpvpn plugin interface
15:27:55 <matrohon> amotoki, pc_m : and that supports both extensions
15:27:57 <pc_m> I've been trying to define API for the "what" gets connected, with a separate (existing)API (for IPSec) for the how to connect.
15:28:05 <amotoki> matrohon: that is one choice. another choice is to have a dedicate plugin per VPN type.
15:29:20 <matrohon> amotoki, pc_m : we currently have two service type, but what I mean is that the service driver could be the same and implement both interfaces
15:29:52 <pc_m> matrohon: driver or plugin?
15:30:18 * pc_m wondering if we are all using the same terminology
15:30:35 <amotoki> at now the only interaction point is "vpnservice". I am not sure we should stick one service plugin.
15:30:54 <matrohon> pc_m : it depends on our decision, but it could be a plugin for the bgpvpn service type and a driver for ipsec service type
15:31:06 <amotoki> I think service plugins for ipsec and bgpvpn can coexist. I am just talking about possibilities.
15:32:03 <amotoki> I think we can list bgpvpn service plugin and ipsec service plugin.
15:32:34 <matrohon> let's take the bagpipe implementation : it could coexist with a router that run strongswan for instance
15:32:43 <pc_m> amotoki: is the plugin tied to a specific API (extension)?
15:33:13 <amotoki> pc_m: yes, though it is one choice.
15:33:30 <pc_m> amotoki: What's the other choice
15:33:36 <amotoki> in the past discussion, VPN parameters depends on a type much.
15:33:41 * pc_m trying to find out how they interrelate
15:33:54 <amotoki> so I am afraid we can have a single service plugin or not.
15:34:37 <amotoki> the other choice is one service plugin for all (or two now) VPN types.
15:35:29 <pc_m> amotoki: In that case, some APIs dispatch to one service driver and other APIs to the other service driver?
15:36:10 <pc_m> with a combined plugin, there isn't a way to enable only one type, right?
15:36:11 <amotoki> pc_m: is "that case" "one service plugin ..."?
15:36:25 <pc_m> amotoki: yes
15:36:45 <amotoki> honestly I don't have a good picture on a single plugin for all vpn types.
15:37:14 <matrohon> this could be achivable by loading extension from service drivers
15:37:47 <pc_m> matrohon: It may be useful to create a write-up on the various options, the implications, and maybe a recommendation...for community review.
15:38:08 <matrohon> pc_m : make sense...
15:38:30 <matrohon> this leads me to the other topic I'd like to discuss ... :)
15:38:33 <amotoki> matrohon: does it mean that supported extensions are determiend by loaded drivers?
15:38:52 <pc_m> I imagine some of us (like me), don't have a strong handle on how BGPVPN works either.
15:39:13 <pcarver> I wonder if we need a flow chart showing decision points.
15:39:35 <pcarver> I'm a little unclear on what decisions would be made via API vs config vs within the code
15:39:52 <matrohon> amotoki : If we keep on using a single plugin, having extensions loaded by service drivers make sens since some option won't be supported by some backends
15:40:30 <pcarver> As an API request comes in it needs to flow through plugin/driver/extension in some deterministic way
15:40:48 <matrohon> I submitted this kind of idea on the last review : https://review.openstack.org/#/c/177740/
15:41:22 <matrohon> amotoki : we would mimic the ML2 extension manager
15:41:41 <amotoki> matrohon: I see.
15:42:59 <matrohon> I would like to move the "what" can be associated to a vpn in dedicated extensions
15:43:06 <amotoki> but I am not sure it speeds up us. integration tends to take time and there are big differences across VPN services
15:43:34 <amotoki> so I am not confident a single plugin is a better choice at now.
15:43:57 <amotoki> matrohon: agree to moving "what"
15:44:10 <amotoki> moving to "what"
15:44:27 <janscheurich> I think we are discussing different things. I believe matrohon is talking about what to associate with a BGPVPN object: network, router, etc
15:45:26 <matrohon> amotoki either I hope :)
15:45:50 <amotoki> janscheurich: matrohon: it is same as what in my mind.
15:46:25 <amotoki> matrohon: go ahead, please
15:46:30 <matrohon> pc_m : don't you think this model could be used in the context of https://review.openstack.org/#/c/191944/
15:46:41 <pc_m> I've been trying to design something to detail the "what" with https://review.openstack.org/#/c/191944/
15:46:59 * pc_m messages crossed.
15:47:59 <pc_m> matrohon: I'm still struggling with understanding how BGPVPN works.
15:48:20 <matrohon> pc_m :)
15:48:51 <pc_m> matrohon: For IPSec we need to support multiple local subnets. Rather than just adding it to the existing API, I wanted to separate out the "what gets connected"
15:48:56 <matrohon> pc_m : just think about a third party VPN with end users able to attach resources to it
15:48:56 <pc_m> in the hopes it can be reused.
15:49:46 <matrohon> pc_m : in the IPSec context it's always subnet
15:50:11 <pc_m> matrohon: That helps.
15:50:16 <matrohon> while in bgpvpn we might want to attach network, router or even ports, depending on the backend
15:50:49 <janscheurich> matrohon: Depending on the networking use case
15:51:06 <matrohon> janscheurich : +1
15:51:18 <janscheurich> Not all BGPVPN backends may support all types of attachment
15:51:19 <pc_m> matrohon: So does a backend, like bagpipe manage the resource that gets connected to the BGPVPN?
15:52:03 <matrohon> that's the reason why I think that we should leverage the extension framework to be able to scan what the backend support for attachment
15:53:06 <matrohon> pc_m : it manages the resource by adding learned router to the router namespace in the router attachment example
15:53:51 <janscheurich> pc_m: I wouldn't say it manages the attached resources. It provides VPN connectivity between the attached local resources and the remote resources (in the BGPVPN case dynamically learned)
15:54:02 <matrohon> janscheurich : +1
15:55:26 <pc_m> thanks. helping me understand it better
15:55:26 <matrohon> does anyone think that it's a bad idea to move the *-association to dedicated extension
15:56:09 <amotoki> matrohon: could you elaborate more?
15:56:53 <janscheurich> matrohon: It may make the API documentation more difficult to read if it is split into too many extensions.
15:57:12 <matrohon> amotoki : I mean some backends (bgpvpn drivers or plugins) will support the bgpvpn extension a,d the network-association extension
15:57:34 <matrohon> amotoki : while others will support the bgpvpn extension a,d the router-association extension
15:57:43 <amotoki> matrohon: ah.. I got it to some extent.
15:57:47 <janscheurich> One big problem with Neutron API already today. Difficult to get the big picture
15:57:58 <matrohon> amotoki : which means that the end user can only attach routers
15:59:04 <matrohon> i think we gain in flexibility
15:59:06 <matrohon> but...
15:59:21 <matrohon> neutron is not able to manage action extensions today
15:59:45 <matrohon> as actions described in the spec (associate-network...)
15:59:49 <amotoki> hmm... I think i understand the context, but there are many contexts. it seems better to me to start bgpvpn service plugin and then discuss an integrated vpn plugin.
16:00:07 <amotoki> it is just my feeling from this meeting.
16:00:09 <matrohon> amotoki : yep, ping me if needed
16:00:28 <matrohon> so neutron is only able to manage resources extension
16:01:12 <matrohon> which means taht we should get back to the sub-resources proposal in the spec, instead of action proposal...
16:01:31 <adrian_otto> time to wrap up?
16:01:39 <matrohon> let's have one week to think about that
16:01:40 <matrohon> thanks
16:01:46 <matrohon> #endmeeting