15:07:41 #startmeeting bgpvpn 15:07:42 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:07:45 The meeting name has been set to 'bgpvpn' 15:08:21 we have few design topics today, that I'd like to discuss 15:08:46 topic : service plugins vs service providers 15:08:49 #topic : service plugins vs service providers 15:10:08 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 Launchpad bug 1485515 in bgpvpn "multiple service drivers can't coexist" [Undecided,New] 15:10:14 oh. Almost missed 15:10:23 svinota : hi 15:10:29 matrohon, hi 15:10:59 this would mean that each backend would implement its own plugin and the extension it supports 15:11:02 matrohon: I saw that you sent an email on that bug, but haven't read it yet 15:11:53 Actually, I'm not sure if mixing service provider for the bgpvpn plugin make sense, and answers any use case 15:12:30 hi, I am not an usual member of this meeting though. 15:13:03 for service provider, I have two questions. 15:13:05 What would be the consequences for API users: Can they discover extension support? 15:13:11 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 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 re horizon impl, it is service by service, so it is not a big matter. 15:14:20 janscheurich : there would be no consequences, API would be the same, be the cloud provider couldn't mix several backends 15:14:36 amotoki : ok thanks for the clarification 15:15:13 amotoki : I saw that the flavor framework has merged in neutron recently 15:15:30 amotoki : is there a related work in progress in horizon? 15:15:33 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 matrohon: yes. it can be consumed by various services 15:15:52 pcarver : +1 15:16:10 In the ML3 discussion we talked about leveraging the flavor framework to essentially have "flavors of routers" 15:16:20 amotoki : do you have any links? 15:16:38 marcusvrn_: link about what? 15:17:06 amotoki : about horizon implementation for the flavor framework? 15:17:42 ah.. got it. regaring horizon implementation, it will be service by service. 15:17:47 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 But it's more challenging to imagine a scenario with some L3 on Contrail and other L3 on ODL 15:18:44 pcarver : and others on Nuage, exactly... 15:18:56 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 so it means we can just discuss flavor framework support only from API perspective. 15:19:32 matrohon: Right, just listing some names for concreteness but not limiting discussion to those examples 15:20:36 pcarver: if some setvice plugin cannot coexist with other plugin/driver, they can choose a service plugin rather than a driver. 15:20:41 amotoki : ok I see. the admin can't match service provider to service plugin through horizon? 15:20:53 amotoki : ok I see. the admin can't match service provider to service flavors through horizon? 15:21:26 matrohon: what I am talking is just about user API 15:21:42 amotoki : that's exactly the state of my thoughs currently 15:21:49 we can have more GUI for admin to map privider to flavor. 15:22:09 amotoki : but it's not implemented currently? 15:22:28 matrohon: we have no impl now 15:22:38 amotoki : ok thanks 15:24:25 so i'm not sure we could conclude about service plugin vs service providers... 15:24:51 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 I lean toward the service plugin implementation for its simplicity 15:25:45 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 But will a service plugin approach make it harder for BGPVPN to become part of core Neutron at some point? 15:26:56 amotoki: good question 15:27:12 amotoki : we could have a plugin taht implement both IPSec plugin interface and bgpvpn plugin interface 15:27:55 amotoki, pc_m : and that supports both extensions 15:27:57 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 matrohon: that is one choice. another choice is to have a dedicate plugin per VPN type. 15:29:20 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 matrohon: driver or plugin? 15:30:18 * pc_m wondering if we are all using the same terminology 15:30:35 at now the only interaction point is "vpnservice". I am not sure we should stick one service plugin. 15:30:54 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 I think service plugins for ipsec and bgpvpn can coexist. I am just talking about possibilities. 15:32:03 I think we can list bgpvpn service plugin and ipsec service plugin. 15:32:34 let's take the bagpipe implementation : it could coexist with a router that run strongswan for instance 15:32:43 amotoki: is the plugin tied to a specific API (extension)? 15:33:13 pc_m: yes, though it is one choice. 15:33:30 amotoki: What's the other choice 15:33:36 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 so I am afraid we can have a single service plugin or not. 15:34:37 the other choice is one service plugin for all (or two now) VPN types. 15:35:29 amotoki: In that case, some APIs dispatch to one service driver and other APIs to the other service driver? 15:36:10 with a combined plugin, there isn't a way to enable only one type, right? 15:36:11 pc_m: is "that case" "one service plugin ..."? 15:36:25 amotoki: yes 15:36:45 honestly I don't have a good picture on a single plugin for all vpn types. 15:37:14 this could be achivable by loading extension from service drivers 15:37:47 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 pc_m : make sense... 15:38:30 this leads me to the other topic I'd like to discuss ... :) 15:38:33 matrohon: does it mean that supported extensions are determiend by loaded drivers? 15:38:52 I imagine some of us (like me), don't have a strong handle on how BGPVPN works either. 15:39:13 I wonder if we need a flow chart showing decision points. 15:39:35 I'm a little unclear on what decisions would be made via API vs config vs within the code 15:39:52 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 As an API request comes in it needs to flow through plugin/driver/extension in some deterministic way 15:40:48 I submitted this kind of idea on the last review : https://review.openstack.org/#/c/177740/ 15:41:22 amotoki : we would mimic the ML2 extension manager 15:41:41 matrohon: I see. 15:42:59 I would like to move the "what" can be associated to a vpn in dedicated extensions 15:43:06 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 so I am not confident a single plugin is a better choice at now. 15:43:57 matrohon: agree to moving "what" 15:44:10 moving to "what" 15:44:27 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 amotoki either I hope :) 15:45:50 janscheurich: matrohon: it is same as what in my mind. 15:46:25 matrohon: go ahead, please 15:46:30 pc_m : don't you think this model could be used in the context of https://review.openstack.org/#/c/191944/ 15:46:41 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 matrohon: I'm still struggling with understanding how BGPVPN works. 15:48:20 pc_m :) 15:48:51 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 pc_m : just think about a third party VPN with end users able to attach resources to it 15:48:56 in the hopes it can be reused. 15:49:46 pc_m : in the IPSec context it's always subnet 15:50:11 matrohon: That helps. 15:50:16 while in bgpvpn we might want to attach network, router or even ports, depending on the backend 15:50:49 matrohon: Depending on the networking use case 15:51:06 janscheurich : +1 15:51:18 Not all BGPVPN backends may support all types of attachment 15:51:19 matrohon: So does a backend, like bagpipe manage the resource that gets connected to the BGPVPN? 15:52:03 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 pc_m : it manages the resource by adding learned router to the router namespace in the router attachment example 15:53:51 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 janscheurich : +1 15:55:26 thanks. helping me understand it better 15:55:26 does anyone think that it's a bad idea to move the *-association to dedicated extension 15:56:09 matrohon: could you elaborate more? 15:56:53 matrohon: It may make the API documentation more difficult to read if it is split into too many extensions. 15:57:12 amotoki : I mean some backends (bgpvpn drivers or plugins) will support the bgpvpn extension a,d the network-association extension 15:57:34 amotoki : while others will support the bgpvpn extension a,d the router-association extension 15:57:43 matrohon: ah.. I got it to some extent. 15:57:47 One big problem with Neutron API already today. Difficult to get the big picture 15:57:58 amotoki : which means that the end user can only attach routers 15:59:04 i think we gain in flexibility 15:59:06 but... 15:59:21 neutron is not able to manage action extensions today 15:59:45 as actions described in the spec (associate-network...) 15:59:49 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 it is just my feeling from this meeting. 16:00:09 amotoki : yep, ping me if needed 16:00:28 so neutron is only able to manage resources extension 16:01:12 which means taht we should get back to the sub-resources proposal in the spec, instead of action proposal... 16:01:31 time to wrap up? 16:01:39 let's have one week to think about that 16:01:40 thanks 16:01:46 #endmeeting