16:03:26 <pc_m> #startmeeting vpnaas 16:03:27 <openstack> Meeting started Tue May 12 16:03:26 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:31 <openstack> The meeting name has been set to 'vpnaas' 16:03:46 <pc_m> #topic Announcements 16:04:28 <pc_m> During the summit, we should try to all (those attending of course) get together during the Friday sessions 16:05:12 <pc_m> Agenda for today is to discuss DM VPN, bugs/reviews, and multiple local subnets. 16:05:26 <pc_m> Any other important announcements? 16:05:35 <sridhar_ram> pc_m: qq .. any particular slot within Friday ? 16:05:51 <matrohon> an initial implementation for BGPVPN is available 16:06:07 <matrohon> with the Bagpipe BGP speaker 16:06:13 <pc_m> sridhar_ram: I think there is a block of time for people to break out into groups, so we can probably just try to hook up. 16:06:24 <pc_m> matrohon: cool! 16:06:47 <pc_m> matrohon: Is there a wiki page for BGP VPN with links to the spec, stackforge repo, etc? 16:07:04 <matrohon> sridhar_ram, pc_m : I picked one slot to discuss about BGPVPN 16:07:04 <ajmiller> pc_m is there a vpn IRC channel we could use at the summit to communicate? 16:07:19 <matrohon> pc_m : no.... only readme in the code :) 16:07:50 <pc_m> ajmiller: No specific VPN IRC, but we can use Neutron IRC. 16:08:00 <matrohon> pc_m : I'll try to register a dedicated wiki page for BGPVPN 16:08:11 <ajmiller> pc_m, cool. 16:08:11 <pc_m> matrohon: Could you add some links to a page? 16:08:47 <pc_m> matrohon: Yeah, people ask and then I have a hard time finding specs on BGP VPN. Would be nice to have a page and link from VPN page. 16:08:53 <sridhar_ram> pc_m: matrohon: it will be better to pick a specific slot for general VPN (perhaps broaden the scope of BGPVPN slot) and shoot to congregate 16:09:21 <pc_m> #action matrohon to create BGP VPN wiki page with info. 16:09:58 <matrohon> best links I have for the moment : https://github.com/stackforge/networking-bgpvpn 16:10:25 <matrohon> https://github.com/stackforge/networking-bgpvpn/blob/master/README-bagpipe.rst 16:10:27 <pc_m> sridhar_ram: Do you know if there are slots on Friday? 16:10:48 <pc_m> matrohon: nice, that and BP spec, and stackforge link would be good, 16:10:51 <hareeshp> Is friday the only possible day? I was wondering if it is possible to have it earlier 16:11:08 <matrohon> and of course the spec under review in neutron : https://review.openstack.org/#/c/177740/ 16:11:19 <sridhar_ram> pc_m: not sure 16:11:41 <pc_m> hareeshp: There are specific sessions allocated each day to specific topics. No chance of adding anything now. 16:12:06 <pc_m> Friday is going to be like Paris, where people just break into groups of interest at tables and discuss. 16:12:31 <matrohon> sridhar_ram : make sense to have a more general session about VPNs on friday 16:12:45 <hareeshp> pc_m: ok, thanks 16:13:19 <sridhar_ram> matrohon: great.. can you share the details / time slot ? 16:13:37 <matrohon> pc_m : at Paris we already had session followed by every one on friday led by ijw 16:13:44 <hareeshp> pc_m: I was thinking may be having an informal one around one of the breaks, rather than waiting for the last day 16:13:53 <pc_m> we can also put something on the VPN meeting page w.r.t. time/place we want to get together. 16:14:11 <matrohon> it was on friday afternoon, but unfortunatelly nothing came up from this session 16:14:33 <xgerman> or we can aim for a breakfast meeting or something like that 16:14:40 <pc_m> hareeshp: may be possible depending on peoples' schedule. 16:15:11 <sridhar_ram> pc_m: +1, how about for an early afternoon meeting ? 16:15:19 <pc_m> matrohon: There were groups broken out on Friday for L3, adv. svcs, etc. I think we can just self organize at a table. 16:15:35 <pc_m> sridhar_ram: Before Friday? 16:15:42 <sridhar_ram> I meant on Friday 16:16:28 <pc_m> sridhar_ram: I don't have the schedule handy so I don't know Friday's details. 16:17:28 <sridhar_ram> okay .. so current plan is to hang out in the neutron area and breakout for VPNaaS. 16:17:45 <sridhar_ram> pc_m: if you happen find a granular time .. let us know 16:18:19 <pc_m> sridhar_ram: OK. Will try to get ahold of schedule and post on our meeting page, some time choices... 16:18:38 <sridhar_ram> pc_m: sounds good 16:18:49 <ajmiller> pc_m This review needs +2 https://review.openstack.org/#/c/182370/ 16:18:52 <ajmiller> #link https://review.openstack.org/#/c/182370/ 16:19:01 <pc_m> #action pc_m Identify timeslots/place friday for VPN team to meet. 16:19:07 <pc_m> ajmiller: hang on will get there... 16:19:16 <ajmiller> ok 16:19:27 <pc_m> Done with announcements? 16:19:46 <pc_m> #topic bugs/reviews 16:20:00 <ajmiller> Sorry for getting ahead of myself ;) 16:20:27 <pc_m> Please look at the list of bugs for any you can take ownership of... https://bugs.launchpad.net/neutron/+bugs?field.searchtext=vpnaas&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter 16:20:27 <pc_m> =&field.omit_dupes=on&field.has_patch=&field.has_no_package=&orderby=status&start=0 16:20:39 <matrohon> sorry I can't find the etherpad dedicated to friday working group :( 16:20:43 <pc_m> Trying again: https://goo.gl/XNtnLX 16:21:16 <pc_m> Also, look at the open reviews and please help out: https://review.openstack.org/#/q/status:open+project:openstack/neutron-vpnaas,n,z 16:21:42 <pc_m> For me, I can use reviewers on https://review.openstack.org/#/c/168115 16:22:02 <pc_m> Also, Nikolav has the scenario test out #link https://review.openstack.org/#/c/159746 16:23:05 <pc_m> ajmiller: thanks for the tox coverage fix. We'll review. Since it doesn't have a bug with a tag of vpnaas, just feel free to add people as reviewers (otherwise we won't see it) 16:23:24 <xgerman> So we can’t just tell you here ;-) 16:23:29 <ajmiller> pc_m ok 16:23:40 <pc_m> xgerman: yeah :) 16:24:03 <matrohon> pc_m, sridhar_ram : I finally found the etherpad for friday sessions : https://etherpad.openstack.org/p/YVR-neutron-contributor-meetup 16:24:07 <pc_m> I know it is painful as there are limited cores to review 16:24:15 <pc_m> matrohon: thanks. 16:25:00 <pc_m> matrohon: IIRC last time, they broke out into groups with people at tables, based on interest. 16:25:15 <sridhar_ram> matrohon: thanks, there is also this kitchen sink etherpad #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics 16:25:21 <xgerman> well, in LBaaS case suddenly our name came up and w had to go to the main table 16:25:24 <matrohon> pc_m : taht what happened on friday mornig at paris 16:26:05 <xgerman> Friday is a big hectic so if we can meet any other day might be better 16:26:13 <sridhar_ram> I see there are some VPN topics in that etherpad as well 16:26:45 <pc_m> FYI, marun fixed a problem with tests not getting run. However, there is breakage in the tests right now. Another change in Neutron for forbidding contextlib.nested usage. I'm trying to get a fix in today for that. 16:26:56 <pc_m> xgerman: I'm open to suggestions... 16:27:44 <pc_m> Any other bugs of interest we need to discuss here 16:27:52 <xgerman> breakfast might be good — or we can meet during lunch... 16:27:53 * pc_m time check 1/2 way 16:28:30 <xgerman> also there is often sessions we can skip and just grab a table somewhere 16:28:49 <xgerman> but we should announce whatever time we choose on the ML 16:29:49 <sridhar_ram> xgerman: i still believe we shd meet on friday where most of the neutron heads swarming.. perhaps we will entice more folks in the room to join this sub-team ;-) 16:29:50 <pc_m> xgerman: Let's push this to Open Discussion, as we still have big items to cover, and can always discuss on ML later 16:29:57 <xgerman> +1 16:30:12 <sridhar_ram> pc_m: agree, will hold back ;-) 16:30:12 <pc_m> Any other important bugs? 16:30:40 <pc_m> ok. moving along... 16:30:47 <pc_m> #topic DM VPN 16:30:52 <pc_m> sridhar_ram: all yours... 16:30:57 <sridhar_ram> pc_m: 16:31:13 <sridhar_ram> few pointers first.. 16:31:39 <sridhar_ram> the spec for DMVPN is available at #link https://review.openstack.org/#/c/181563 16:31:57 <sridhar_ram> a wiki page #link https://wiki.openstack.org/wiki/Neutron/VPNaaS/DMVPN 16:33:13 <sridhar_ram> the basic premise: when there are multiple sites to connect .. site-to-site goes too complex to setup and operate 16:33:33 <sridhar_ram> hence a multipoint VPN that comes up dyanmically 16:34:06 <matrohon> make sense 16:34:19 <sridhar_ram> it uses a Hub and Spoke model where every remote site connects to Hub 16:34:33 <pc_m> Please look at the BP spec and comment, so sridhar_ram can address your questions. 16:34:41 <matrohon> in your description you say : facilitates automatic spoke-to-spoke connection that comes up dynamically 16:34:59 <matrohon> does it mean that you can get rid of the hub? 16:35:19 <sridhar_ram> matrohon: no. Hub acts as a central "registrar" of sort 16:35:47 <sridhar_ram> it is the one the share the public endpoints of spokes to have them connect between them directly 16:35:56 <pc_m> sridhar_ram: so once spoke is created, it communicates with hub. How does it know another spoke wants to form a connection? 16:36:29 <hareeshp> or in other words the traffic does not need to flow through the hub, right? 16:36:58 <sridhar_ram> pc_m: NHRP protocol will share the neighbor information 16:37:12 <sridhar_ram> hareeshp: Exactly 16:37:44 <pc_m> sridhar_ram: it may be good to describe a use case/scenario of the interaction for say a spoke to hub and then spoke to spoke connection establishment. 16:37:54 <pc_m> sridhar_ram: Ladder diagram or something... 16:38:03 <sridhar_ram> hareeshp: there is a mode of operation where traffic could flow through the Hub .. direct spoke to spoke connection make more sense 16:38:29 <matrohon> does a dynamic learning framework is mandatory for DMVPN? 16:38:34 <sridhar_ram> pc_m: yes sure, this is something i plan to add to the spec 16:39:03 <sridhar_ram> matrohon: yes, that is the main value / premise of the DMVPN 16:39:08 <pc_m> sridhar_ram: thanks. would be good to have an example of what steps happen for some of the scenarios. 16:40:05 <matrohon> sridhar_ram : I feel like depending on the bgp implementtion in neutron will slow down your implementation 16:40:42 <sridhar_ram> matrohon: currently i'm not calling out a dependency on BGP for exactly the same reason :) 16:40:52 <pc_m> sridhar_ram: :) 16:41:22 <matrohon> sridhar_ram : do you already have some proof of concept? 16:41:47 <sridhar_ram> yes, we have a small PoC working using mGRE 16:41:55 <pc_m> sridhar_ram: nice 16:42:09 <sridhar_ram> plan is to give a try with ipsec 16:42:09 <hareeshp> sridhar_ram: cool 16:42:50 <matrohon> sridhar_ram : great! what bgp speaker are you using? :) 16:43:26 <sridhar_ram> No bgp yet. For now we are just punching in static router to avoid BGP dependency. 16:43:42 <sridhar_ram> However I was thinking of using bird for the bgp needs! 16:43:58 <hareeshp> sridhar_ram: Are you dependent on something else to land in neutron for this? 16:44:00 <sridhar_ram> s/static router/static routes/ 16:44:27 <matrohon> sridhar_ram : fine! bagpipe is based on exabgp, it's in python :) 16:44:33 <sridhar_ram> the main component in opennhrp ... the opensource implementation of NHRP protocol 16:44:36 <hareeshp> sridhar_ram: or is it merely the API extention alone? 16:45:54 <sridhar_ram> The critical component, IMO, to land this on neutron is to find the main distros to package OpenNHRP 16:46:25 <sridhar_ram> it is currently available in sourceforge (yeah!) 16:46:39 <pc_m> sridhar_ram: Or you may need to caveat it and say it is supported by distro a,b,c only 16:47:25 <sridhar_ram> not sure about the precedent of having to pull in a dependency outside like sourceforge 16:47:29 <pc_m> Any other questions for sridhar_ram since we have him on the hot seat? :) 16:47:46 <sridhar_ram> pc_m: sure, will caveat that in the spec 16:47:49 * pc_m we've got about 10 mins left and one more topic 16:47:59 <sridhar_ram> pc_m: thats it from me 16:48:07 <pc_m> sridhar_ram: thanks! 16:48:14 <sridhar_ram> looking for folks to participate and help out! 16:48:32 <pc_m> yes, anyone interested, let sridhar_ram know! 16:48:48 <pc_m> #topic Multiple local subnets 16:49:12 <pc_m> This was talked about a while back, of having more than one local private subnet in a VPN connection. 16:49:22 <pc_m> The three main questions are: 16:49:39 <pc_m> 1) Does openswan, libreswan, and strongswan support this? 16:49:54 <pc_m> 2) Does the IP version of each subnet need to be the same? 16:50:18 <pc_m> 3) Does it make sense to extend the VPNaaS implementation to support multiple local subnets? 16:50:42 <pc_m> I think anilvenkata has done some investigating... anilvenkata? 16:50:50 <anilvenkata> thanks pc_m 16:51:00 <anilvenkata> my observtions 16:51:00 <anilvenkata> openswan/libreswan supports multiple local CIDR in single connection. 16:51:00 <anilvenkata> strongswan supports the same for IKEv2. Strongswan uses Cisco Unity extension plugin to support this with IKEv1 16:51:00 <anilvenkata> for details http://paste.openstack.org/show/220855/ 16:51:57 <anilvenkata> these are all observations for question 1 i.e Does openswan, libreswan, and strongswan support this? 16:52:11 <pc_m> anilvenkata: Do you know the implications of the unity extension? Is it available in the standard strongswan package? 16:52:29 <pc_m> anilvenkata: Or is it something additional needed? 16:52:37 * pc_m not sure what it is... 16:52:38 <anilvenkata> pc_m: no I didn't look into it 16:53:09 <pc_m> anilvenkata: Just curious 16:53:17 <xgerman> also curious 16:53:40 <anilvenkata> i will look into it 16:54:17 <anilvenkata> if that is not possible for IKEv1, then can we have diffent connection for another subnet? 16:54:23 <pc_m> #action anilvenkata to look into implications of Cisco Unity extension plugin for IKEv1 strongswan 16:54:52 <pc_m> anilvenkata: Well, that's what we have today, AFAIK. 16:55:24 <anilvenkata> pc_m, I still doubt current implementation supports multiple local subnets 16:56:13 <pc_m> anilvenkata: I guess that was the intent, was to create multiple connections , one for each subnet. Do you think that may not work? 16:56:35 <anilvenkata> how can this be done with existing api? 16:57:12 <anilvenkata> In existing api, subnet can be provided at only one place i.e vpn-service-create, which accepts only one subnet 16:57:41 <matrohon> having ikev2 mandatory for this feature is not acceptable? 16:57:43 <pc_m> anilvenkata: Ah, good point... may be an issue 16:58:17 <sridhar_ram> folks - is there a spec planned for this effort ? 16:58:19 <matrohon> we may export each subnet behind the router which hosts the ipsec connection? 16:58:50 <anilvenkata> i think we have to change both vpn-service-create and ipsec-site-connection-create api 16:59:07 <anilvenkata> IMO, vpn-service-create should accept only router 16:59:33 <anilvenkata> ipsec-site-connection-create should accept local sunets and peer cidrs, which user wanted 16:59:58 <pc_m> sridhar_ram: no. There have been people asking a few times on whether multiple subnets can be supported. So more of a discussion to see if it could be done and whether it should be 17:00:08 <pc_m> anilvenkata: agree. 17:00:19 <pc_m> Ouch we ran out of time... 17:00:36 <sridhar_ram> anilvenkata: looking at #link https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection 17:00:44 <sridhar_ram> looks this is supported 17:00:47 <pc_m> Let's continue on IRC/ML for this and summit get together.. 17:00:48 <anilvenkata> for local subnets, we can do validations i.e local subnets given by user belongs to vpn-service router or not 17:01:17 <pc_m> need to end the meeting folks... let's move to neutron. 17:01:21 <sridhar_ram> quote .. "Since 5.1.1...multiple addresses, ranges and subnets can be separated by commas." 17:01:22 <pc_m> #endmeeting