22:10:42 #startmeeting Networking VPNaaS 22:10:43 Meeting started Mon Oct 7 22:10:42 2013 UTC and is due to finish in 60 minutes. The chair is nati_ueno. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:10:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:10:46 hi all 22:10:46 The meeting name has been set to 'networking_vpnaas' 22:10:53 hi 22:11:21 Swami: pcm__: hi! 22:11:45 #topic Summit session 22:11:54 I have created a ehterpad page https://etherpad.openstack.org/NeutronVPNaaSIceHouse 22:12:19 In previous neutron weekly meeting, we agreed not to use "lecture" style discussion 22:12:29 Yes opening the page 22:12:37 so I would like to use this etherpad on the summit 22:12:59 Also, I would like to start discussion on the etherpad about milestone of VPN on Icehouse 22:13:09 Yes that would work out 22:13:33 Swami: Thanks 22:14:13 Ok 22:14:33 #topic Protocol Support 22:15:02 It looks like SSL-VPN, MPLS/BGP are proposed with bp 22:15:23 Yes 22:15:28 "IPSec Certificate authentication support" <-- who's added this one? 22:15:40 I added it Nachi to the list 22:15:51 Swami: Thanks. could you link the bp? 22:16:01 Just to make sure that we don't miss anything left out 22:16:10 Thansk 22:17:56 IPSec + I2TP, GRE are candidates, but it looks like it lacks bps 22:17:56 I don't have the detailed write up for the IPsec certificate authentication support, but since the SSL VPN already handles the certificate table, we can re-use the same for discussions 22:18:13 Swami: yes. we can use same tables 22:18:35 Nachi: Thanks 22:18:36 folks, btw, where are you storing certs for the service? 22:18:48 enikanorov: I think keystone is applicable 22:18:56 enikanorov: it has certificate api 22:19:01 is it planned or current solution? 22:19:19 Nachi: There was also another blueprint targeted for storing the SSL certs for Loadbalancer sSL offload 22:19:23 enikanorov: I think it has.. but i'm not confident. I should investigate 22:19:37 Swami: Thanks. could you add it on the etherpad 22:19:53 nati_ueno: I see, thanks. I'm asking because there are talks about adding ssl to lbaas, which will also need certs management 22:19:55 Sure 22:20:02 certificate resource would be not limited on vpnaas 22:20:29 so, let's write some proposal at first, then discussion on the mailing list before the summit 22:20:48 sounds good 22:21:24 Is there anyone to take this resource design? 22:22:42 OK let's find the people later 22:22:54 :) 22:23:08 Do you have any other items for Protocol Support? 22:23:37 I don't think there is anything more, the etherpad list covers all 22:23:43 ok. 22:23:52 Swami: so you will raise hand for ssl-vpn? 22:24:42 Yes I would raise hand for both ssl-vpn and mpls/bgp, both are required, but I thought we can do baby steps 22:25:31 Swami: Ok sure. i'm still working on mpls stuff. so let's discuss detailed API in next meeting 22:25:48 nachi: appreciate it 22:25:55 I think Ian Wells has a L2VPN session submitted. 22:26:14 pcm__: yes. he wrote some note on the etherpad 22:26:21 pcm__: is he around? 22:26:38 I mentioned the session, but don't think he's on IRC 22:26:45 I'll ping him 22:26:50 pcm__: Thanks 22:27:07 pcm__: he says ", I'm not bringing an implementation along", so may be we can separate session 22:27:21 pcm__: his topic looks like more general terms 22:27:34 gotcha 22:27:43 #topic Service 22:27:54 I think there is there workitems 22:28:14 (1) Service Type Framework (2) Service Insertion (3) Service agent 22:28:45 (1) has a patch, and i expect it will be merged in early I 22:28:58 (2) and (3) is under the discussion 22:29:10 nati_ueno: are you aware of service chaining proposal? 22:29:14 or discussion? 22:29:20 o/ 22:29:34 Nachi: Do you also need to consider the service chaining or will service insertion be part of the service chaining 22:29:42 enikanorov: yes 22:29:55 I should add it on the list :P 22:30:05 nati_ueno: it also has an idea of introducing new entity 22:30:09 "service instance" 22:30:17 which is used for a few things 22:30:29 enikanorov: is that Sumit's proposal, or is this another one? 22:30:33 enikanorov: am in the process of revising the proposal from the last summit on service insertion/chaining 22:30:35 bind resource to a backend, bind resource to a provider, etc 22:30:46 yeah, basically it is his proposal 22:31:00 SumitNaiksatam: hi :) 22:31:09 hi :-) 22:31:27 so may be we should discuss service related topic in the service session if we have 22:31:36 enikanorov: any link to the proposal? 22:31:40 SumitNaiksatam: so you are proposing a session too? 22:31:45 pcm__: not yet 22:31:49 Sumit's got one on service chaining already 22:32:01 (independent of VPNs) 22:32:03 * pcm__ just trying to wrap my head around all this 22:32:08 ijw: that's right 22:32:34 I need a word with people here about service chaining, too - but in general it's an independent topic to VPNs and I would set it aside for now 22:32:50 ok 22:33:11 SumitNaiksatam: How about have a irc meeting about service related stuff? 22:33:32 nati_ueno: +1 22:33:59 nati_ueno: sure 22:34:04 SumitNaiksatam: Thanks! 22:34:07 #topic misc 22:34:22 nachi: please add me in those meeting related to service chaining discussion 22:34:27 I would like to add (1) Multiple local subnet support (2) Routing configration support on VPNService 22:34:51 Swami: sure. I believe Sumit will send invitation on the openstack-dev 22:35:00 do you have any other related bps? 22:35:02 nachi: thanks 22:35:52 ok it looks nothing 22:35:57 nati_ueno: whatever you're proposing for VPNs ought to apply exactly the same as any provider network, shouldn't it? 22:36:17 s/as/to/ 22:36:36 ijw: Ah, I didn't have a thought about that. but may be true 22:36:52 ijw: (1) is for vpn service resources. 22:36:58 ijw: but (2) is may be related 22:37:31 Yeah, I was thinking more in terms of 'if there's an API for this already can we re-use it' but I guess that for L3VPNs it's done differently to networks 22:38:04 ijw: no vpnservice is not only for l3. we will remove router_id. 22:38:16 ijw: router_id will be deal with service insertion stuff 22:38:47 however we should discuss this with a concrete API proposal. 22:39:03 so let's discuss the detail in the next meeting. I'll write some proposal 22:39:06 nati_ueno: this is a good point, glad you brought it up 22:39:06 I don't think you can just remove router_id and make a VPN l2 22:39:15 (if that's what you're saying) 22:39:36 ijw: removing router id is probably not enough 22:39:54 however, router id probably does not belong the way it is modeled now 22:40:08 SumitNaiksatam: yes 22:40:09 do you agree? 22:40:14 k 22:40:25 ijw: may be, you are right. let's discuss on the proposal in next meeting 22:40:35 ijw: are you going to propose l2vpn in the icehouse? 22:42:31 I've got the proposal in, yes. I might present an API for the basic concept but I didn't want to get into specific VPN types so much as the differences between L2 and L3 and how you would want to attach them. 22:43:03 ijw: so do you have some impl also in icehouse 22:43:28 I was hoping to have a general discussion and hear opinions rather than say 'we should do it exactly like this', if that's all right with people. I don't have an API implementation right now, no. 22:44:07 ijw: yeah, one issue is no one is going to add impl for l2vpn in icehouse, IFIK 22:44:32 ijw: if we have no plan to impl it, it isn't makes sence to add API for that in this release 22:44:49 We would like to implement it, I think 22:45:05 ijw: We == your team? 22:45:51 Probably not my specific team, just someone in the wider company - but I'd like to take details and recommendations back to them rather than have them come up with an extension in the absence of any feedback. 22:46:30 ijw: Ok let's ask is there anyone to take l2vpn impl in icehouse in mailing list 22:46:46 I can probably persuade Kyle to mind it 22:46:54 ijw: cool 22:47:02 ok next topic 22:47:05 #topic Vendor driver support 22:47:13 I find there is NSX bp for vpnaas 22:47:23 pcm__: IMO, you will going to add cisco support also 22:47:57 yes, will be... in early investigations right now. Will need to do a BP 22:48:16 pcm__: Thanks. please link you bp when you write it 22:48:24 will do. 22:48:28 any other vender driver proposals on this? 22:49:08 OK let's keep asking in the mailing list 22:49:26 #topic open discussion 22:49:28 I was curious on how we handle vendor diff in API 22:49:34 do you have some discussion items? 22:49:57 e.g. if a vendor supports diff attribute values. 22:49:58 Normally vendor diff come in through their plugin 22:50:20 pcm__: if the attriubutes differents, we can add vendor-specific extensions 22:50:24 Guess I'm wondering how it is reflect in API 22:51:31 For example, say you support more authentication methods. How does the API reflect that? 22:51:48 pcm__: That's sounds not vendor-specific 22:52:04 pcm__: we should extend our vpn API for the more authentication methods 22:52:45 Just an example. Could go the other way, like not supporting some of the attribute values. 22:53:40 The new attribute is really vendor specific, we can write extension for it 22:53:48 we can extend vpnservice resource 22:54:30 pcm__: ok let's keep discussion on this 22:54:39 #topic next meeting time 22:55:05 is that OK for you with same time. After the Next neutron core meeting 22:55:22 it's a pity it's too late 22:55:27 This timeslot works for me. 22:55:31 i'm not a regular visitor at this time 22:55:46 but a feel lbaas and vpn has come common points to discuss 22:55:56 normally OK. Though I'm not avail. next two Mon. 22:56:00 enikanorov: Ah ok. so let's schedule another time. 22:56:20 nati_ueno: nope, i don't think my time zone is suitable for you guys 22:56:23 enikanorov: pcm__: could you add some candidates on the etherpad 22:56:34 ok 22:56:43 so I'd prefer to participate in ML threads if you initiate some 22:56:53 OK I'll send summary for the mailing list 22:56:58 Time is fine for me, just conflicts the next two weeks. 22:56:59 I am ok with any time slot, other than early morning PDT 22:57:05 enikanorov: yes. let's keep discussion on the mailing list 22:57:22 OK Thanks guys!! 22:57:25 #endmeeting