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