15:33:16 <SumitNaiksatam> #startmeeting Networking Advanced Services
15:33:17 <openstack> Meeting started Tue Oct 29 15:33:16 2013 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:33:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:33:21 <openstack> The meeting name has been set to 'networking_advanced_services'
15:33:28 <nati_ueno> hi!
15:33:29 <SumitNaiksatam> thanks all for joining, hope everyone is excited about meeting in HK :-)
15:33:42 <SumitNaiksatam> hi nati_ueno, perfect time, we were waiting for you :-)
15:34:00 <SumitNaiksatam> thanks for the folks on PDT, since this is early for you
15:34:35 <SumitNaiksatam> we went for this time slot to accommodate young's request, but he doesn't join the meetings
15:34:56 <SumitNaiksatam> so may be we can switch to a different time for any future meetings (post summit)
15:35:08 <greg_r> works for me
15:35:28 <SumitNaiksatam> thanks greg_r, yeah for me as well ;-)
15:35:30 <SumitNaiksatam> #topic service insertion and chaining
15:35:32 <amotoki> hi
15:35:34 <nati_ueno> SumitNaiksatam: oops sorry. I'm little bit late :)
15:35:37 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
15:35:51 <SumitNaiksatam> hi amotoki, thanks for joining
15:35:56 <SumitNaiksatam> nati_ueno: we are just getting started
15:36:08 <SumitNaiksatam> #info: #link http://icehousedesignsummit.sched.org/event/7f9b9c47d02789e67885ca81d9d42a3f
15:36:24 <SumitNaiksatam> per action item in the last meeting, i have added the CLI-based workflow to the design document
15:36:32 <SumitNaiksatam> this does not include any changes which Eugene's proposal on extensible APIs may introduce
15:36:41 <SumitNaiksatam> but we can keep that aside for now
15:37:06 <SumitNaiksatam> we made changes to the design based on the feedback from the face-2-face meeting
15:37:34 <SumitNaiksatam> we removed the "insertion mode" from the context as well as the device_provider table
15:37:49 <SumitNaiksatam> also, only insetion_context needs to be provided, not insertion mode
15:37:54 <SumitNaiksatam> when creating service
15:38:11 <SumitNaiksatam> the claim is that the provider can infer the insertion mode based on the context
15:38:21 <SumitNaiksatam> i believe this was what most people were suggesting
15:38:30 <SumitNaiksatam> anyone got a chance to take a look?
15:38:43 <SumitNaiksatam> discussed this with a few folks offline
15:39:35 <SumitNaiksatam> i know there have been lots of blueprints and designs to look at in the past few days :-)
15:39:51 <SumitNaiksatam> apart from the ones that you are probably working on as well in preparation for the summit
15:40:29 <SumitNaiksatam> so assuming we make progress on this current design during the summit, i wanted to bring up the discussion of how we are going to implement at least one chain
15:41:10 <SumitNaiksatam> based on the face-2-face discussion, the thinking was that we will first implement FWaaS-VPN chain
15:41:46 <SumitNaiksatam> based on the reference implementation, that is
15:41:59 <SumitNaiksatam> thoughts?
15:42:47 <SridarK> i think this is good - we just want to make sure there are no corner cases
15:43:01 <SumitNaiksatam> SridarK: ok, any that you can think of?
15:43:01 <SridarK> we can do some more work offline to make sure
15:43:09 <SumitNaiksatam> SridarK: okay
15:43:41 <amotoki> it seems a good start point.
15:43:45 <SumitNaiksatam> so given that our reference implementation for both services is in the L3 context, we were thinking that the service chain can be driven via the L3 service plugin
15:43:51 <SumitNaiksatam> amotoki: ok
15:43:53 <amotoki> Do we need to define service-chain-provider per combination of service providers?
15:43:56 <nati_ueno> I'm ok with current design. we should start prototyping
15:44:15 <SumitNaiksatam> amotoki: that is the current suggestion (we could have default provider)
15:44:33 <SumitNaiksatam> i meant default provider for chain
15:44:37 <SumitNaiksatam> nati_ueno: ok
15:45:01 <SumitNaiksatam> nati_ueno: any specific thoughts on prototyping?
15:45:20 <nati_ueno> so we should have a list of small bps
15:45:29 <nati_ueno> then let's finish one by one
15:45:34 <nati_ueno> Do we have the list now?
15:45:34 <SumitNaiksatam> nati_ueno: yeah sure
15:45:52 <SumitNaiksatam> nati_ueno: no, but i was going to wait for the summit discussion
15:45:59 <SumitNaiksatam> may be not required to wait
15:46:12 <SumitNaiksatam> lets discuss offline and get a list ready
15:46:13 <nati_ueno> yeah, may be it won't be merged before the summit
15:46:27 <nati_ueno> but concrete code will help a concrete discussion
15:46:43 <SumitNaiksatam> #action SumitNaiksatam and nati_ueno to decide on the list of blueprints
15:46:56 <nati_ueno> SumitNaiksatam: Which one should be the first target?
15:47:00 <SumitNaiksatam> nati_ueno: i doubt how far we will get with the code before the summit itself
15:47:16 <SumitNaiksatam> nati_ueno: which one, as in?
15:47:44 <SumitNaiksatam> i think we should target the refactoring on the individual service insertion first
15:47:50 <SumitNaiksatam> if that is what you meant
15:48:07 <nati_ueno> I agree
15:48:21 <SumitNaiksatam> once we are done with that, we can look at the chain
15:48:31 <SumitNaiksatam> nati_ueno: ok
15:48:56 <nati_ueno> SumitNaiksatam: how about to have crud for service insersion context?
15:49:10 <SumitNaiksatam> so for individual insertion we need to introduce the insertion_context, and that should be a non-disruptive change
15:49:16 <SumitNaiksatam> nati_ueno: yeah you read my mind :-)
15:49:23 <nati_ueno> SumitNaiksatam: ha ha you too
15:49:39 <SumitNaiksatam> meanwhile we can check with lbaas as well
15:49:54 <nati_ueno> yes it is also service implementation independent
15:50:01 <nati_ueno> since we have only 1 hour in the summit
15:50:07 <SumitNaiksatam> since they plan to implement LBaaS logical instance just like FWaas and VPNaaS
15:50:17 <nati_ueno> may be discussing this insertion context is enough at the summit
15:50:19 <SumitNaiksatam> nati_ueno: yeah
15:50:54 <SumitNaiksatam> nati_ueno: i think we can lay out the general plan
15:51:02 <SumitNaiksatam> and how we want to go about it in steps
15:51:11 <SumitNaiksatam> first independent service insertion, then chains
15:51:18 <SumitNaiksatam> depending on how much time we have
15:51:20 <nati_ueno> OK let's me write it if there is no existing code
15:51:42 <nati_ueno> SumitNaiksatam: if you wanna write it, it is Ok too
15:51:58 <SumitNaiksatam> #action SumitNaiksatam nati_ueno to hash out the list of blueprints for insertion_context and chains
15:52:06 <SumitNaiksatam> nati_ueno: yeah we can collaborate
15:52:19 <SumitNaiksatam> others also welcome to join
15:52:42 <nati_ueno> SumitNaiksatam: sure. I'll send you the wip.
15:53:00 <SumitNaiksatam> nati_ueno: thanks
15:53:20 <greg_r> just a note,  useful to have an over-arching blueprint?
15:53:30 <nati_ueno> +1
15:53:37 <greg_r> One that shows the workflow for services end to end
15:53:39 <SumitNaiksatam> greg_r: yes
15:53:56 <SumitNaiksatam> greg_r: that is the current insertion and chaining blueprint
15:54:21 <SumitNaiksatam> we can add the workflow for reference implementation
15:54:32 <SumitNaiksatam> that way it helps to have all the information in one place
15:54:39 <SumitNaiksatam> i mean on the google doc
15:54:57 <greg_r> that would be good
15:54:58 <SumitNaiksatam> each individual blueprint can have more details and its own spec
15:55:19 <SumitNaiksatam> for the implementation of the chain (which is second step) i was thinking that we can leverage the L3 service plugin footprint
15:55:27 <SumitNaiksatam> bmelande: thoughts?
15:55:53 <SumitNaiksatam> just wanted to plant the seed
15:55:54 <bmelande> SumitNaiksatam: yes it might be possible
15:56:08 <SumitNaiksatam> bmelande: we can discuss later
15:56:19 <bmelande> SumitNaiksatam: Did you mean to do that through a separate l3 servicep lugin
15:56:19 <bmelande> ?
15:56:28 <SumitNaiksatam> bmelande: not separate
15:56:43 <SumitNaiksatam> bmelande: there should be only one reference implementation, right?
15:56:59 <bmelande> Yes, sorry, you're right.
15:57:01 <SumitNaiksatam> i mean for the L3 service plugin
15:57:11 <SumitNaiksatam> ok
15:57:18 <SumitNaiksatam> should we move to the next topic
15:57:20 <SumitNaiksatam> ?
15:57:34 <SumitNaiksatam> #topic common L3 agent framework
15:57:41 <SumitNaiksatam> #link https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.p
15:57:52 <SumitNaiksatam> nati_ueno: are we still doing Option2-2, is there a blueprint?
15:58:10 <SumitNaiksatam> i noticed that we are not discussing this during the summit?
15:58:12 <nati_ueno> SumitNaiksatam: not yet
15:58:23 <SumitNaiksatam> do we plan to do this in Icehouse?
15:59:03 <nati_ueno> SumitNaiksatam: I'll register it
15:59:18 <SumitNaiksatam> nati_ueno: ok, so for Icehouse?
15:59:43 <bmelande> nati_ueno: do you have any thoughts on expanding the agent to configure other than reference implemenation namespaces?
15:59:57 <bmelande> nati_ueno: Like remote devices or VMs?
16:01:09 <yamahata> +1 for service VMs
16:01:47 <SumitNaiksatam> i wanted to bring up reference implementation in the context of the service VM discussion
16:02:15 <SridarK> nati_ueno: i can help any ways we will need to refactor fwaas agent
16:02:31 <SumitNaiksatam> bmelande: so you mean changes to the L3 agent for generic VMs/devices?
16:02:41 <SridarK> nati_ueno: or other things - we can talk at the summit
16:03:09 <bmelande> SumitNaiksatam: Yes, I dont think that would be that difficult adbn couyld be made backward compatible
16:03:19 <bmelande> Sorry for my spelling...
16:03:47 <SumitNaiksatam> bmelande: ok, but that would require defining an interface between L3 agent and driver?
16:04:09 <SumitNaiksatam> where the driver would handle the specifics of, say VM, or remote device
16:04:12 <bmelande> SumitNaiksatam: Yes, something like that
16:04:21 <SumitNaiksatam> bmelande: ok makes sense to me
16:04:41 <SumitNaiksatam> i would tend to think that this is slightly separate from the L3 agent refactoring work
16:04:50 <bmelande> I got half a slot on Fridag
16:05:00 <yamahata> May I ask what 'remove device' means? device on compute node or other?
16:05:01 <SumitNaiksatam> sure
16:05:05 <bmelande> Friday at summit. Was hoping to bring that up then
16:05:14 <SumitNaiksatam> bmelande: great
16:05:26 <SumitNaiksatam> yamahata: i believe remote device is the actual router
16:05:30 <bmelande> yamahata: Service VM or hardware device
16:05:37 <SumitNaiksatam> physical router in this case
16:05:45 <yamahata> Got it, thanks
16:05:49 <amotoki> regarding service VM, do we need to support point-to-point link between VMs?
16:06:08 <SumitNaiksatam> amotoki: our next topic is service VMs
16:06:20 <SumitNaiksatam> can you hold on to that question for a min
16:06:31 <amotoki> please go ahead.
16:06:33 <nati_ueno> yeah. it is too implementation specific topic.
16:06:33 <nati_ueno> yes I think so
16:06:33 <nati_ueno> it is needed to write service chaining prototype
16:06:34 <nati_ueno> Sorry I should go now
16:06:34 <nati_ueno> TL!
16:06:48 <SumitNaiksatam> nati_ueno: thanks
16:07:19 <SumitNaiksatam> bmelande: my understanding is that the L3 agent refactoring is that it targets allowing different L3 services via the same agent
16:07:32 <SumitNaiksatam> ok lets move on
16:07:36 <SumitNaiksatam> #topic Service VMs - Mechanism
16:07:40 <SumitNaiksatam> greg_r: there
16:07:46 <greg_r> yes
16:07:50 <SumitNaiksatam> you want to take amotoki's question?
16:08:01 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
16:08:06 <SumitNaiksatam> #info #link http://icehousedesignsummit.sched.org/event/1deb4de716730ca7cecf0c3b968bc592
16:08:21 <greg_r> ok,  there is currently nothing specified specifically for point to point links between vms
16:08:41 <SumitNaiksatam> amotoki: any specific use case you had in mind?
16:08:50 <SumitNaiksatam> amotoki: HA or something like that?
16:09:17 <amotoki> what in my mind is an transparent appliance.
16:09:31 <greg_r> the current use cases in the BP dont cover that
16:09:48 <amotoki> got it. it is just an example. it is similar to BITW.
16:10:05 <SumitNaiksatam> amotoki: ok, you want to chain multiple VMs?
16:10:26 <amotoki> SumitNaiksatam: right. it is one of what i think
16:10:31 <SumitNaiksatam> amotoki: ok
16:11:09 <SumitNaiksatam> greg_r: i believe you made progress on the taxonomy as well ;-)
16:11:13 <amotoki> it can be one of the fundamentals to support service chaining. we can discuss it as a separate topic.
16:11:38 <SumitNaiksatam> amotoki: yeah, currently we leave it to the provider of the chain to figure that out
16:11:44 <greg_r> yes,  several updates to the spec
16:11:47 <SumitNaiksatam> amotoki: but good point
16:12:03 <bmelande> amotoki: Is p2p a necessity for chaining?
16:12:16 <bmelande> amotoki: Could it not be done using neutron networks?
16:12:24 <greg_r> it seems like a performance optimization?
16:12:33 <amotoki> bmelande: it is not a requirement I think.
16:12:47 <SumitNaiksatam> bmelande: agree, not a requirement
16:13:22 <SumitNaiksatam> bmelande: not the most common way of doing it
16:13:32 <SumitNaiksatam> bmelande: in my observation that is
16:13:47 <bmelande> SumitNaiksatam: which, P2p or using Neutron network?
16:14:13 <SumitNaiksatam> bmelande: Neutron network is the common way
16:14:26 <amotoki> agree
16:14:40 <SumitNaiksatam> greg_r: Mike T does not seem to be here
16:15:03 <SumitNaiksatam> greg_r: anything related to his input that you wanted to bring up?
16:15:04 <greg_r> ok,  Mike T did contribute to the latest version
16:15:19 <greg_r> we covered his changes and merged into the spec
16:15:25 <SumitNaiksatam> greg_r: ok great
16:15:34 <greg_r> we tentatively decided to leave out some of the use cases he proposed
16:15:50 <SumitNaiksatam> I would imagine he is in agreement?
16:15:55 <greg_r> and we left in the use cases that we thought would be acheivable for first cut
16:16:01 <SumitNaiksatam> which ones did we leave out?
16:16:05 <greg_r> he is in agreement
16:16:11 <SumitNaiksatam> ok
16:16:28 <greg_r> we left in the cases where only one tenant is supported
16:16:43 <SumitNaiksatam> greg_r: ok that makes sense to me
16:16:51 <SumitNaiksatam> at least thats a good starting point
16:17:19 <SumitNaiksatam> so that brings up the question of reference implementation
16:17:39 <SumitNaiksatam> greg_r: what is the plan on reference implementation?
16:17:45 <SumitNaiksatam> for service VM
16:17:56 <greg_r> reference implementation,  we do not have a specific target for that
16:18:03 <SumitNaiksatam> greg_r: ok
16:18:08 <SumitNaiksatam> we have a number of options
16:18:33 <bmelande> SumitNaiksatam, greg_r: we can contribute to a refernce implementation
16:18:40 <yamahata> I'm willing to help reference implementation
16:18:44 <SumitNaiksatam> but I would imagine that we would need a reference implementation to make progress in terms of getting the patches in
16:18:49 <SumitNaiksatam> yamahata: great, thanks
16:18:59 <SumitNaiksatam> perhaps this is a longer topic
16:19:13 <SumitNaiksatam> maybe we can huddle during the summit and come up with a plan
16:19:36 <greg_r> Agreed:  we can have an e-mail exchange before?
16:19:47 <SumitNaiksatam> #action SumitNaiksatam greg_r yamahata to discussion candidate reference implementation for service VMs
16:19:51 <SumitNaiksatam> greg_r: agree
16:20:00 <bmelande> SumitNaiksatam, greg_r: one thing that the document does not talk so much about yet is the plugging part of the VM framework
16:20:00 <SumitNaiksatam> anything else on service VMs
16:20:21 <SumitNaiksatam> bmelande:by  plugging you mean, how it is consumed?
16:20:38 <greg_r> bmelande: yes, what is needed?
16:20:39 <bmelande> SumitNaiksatam, greg_r: I'm also willing to help with reference implementation
16:20:48 <SumitNaiksatam> bmelande: great, thanks!
16:20:53 <greg_r> bmelande:  great!
16:20:55 <SumitNaiksatam> bmelande: you earlier question?
16:21:20 <bmelande> I mean, service instance can be dynamically added/removed from networks
16:21:29 <bmelande> Like, router-interface-add/delete
16:21:41 <SumitNaiksatam> #action SumitNaiksatam greg_r yamahata bmelande to discussion candidate reference implementation for service VMs
16:21:47 <SumitNaiksatam> bmelande: ah, good point
16:21:54 <bmelande> This would imply that the service VM needs to be plugged into and off networks
16:22:24 <greg_r> bmelande:  got it
16:22:32 <SumitNaiksatam> bmelande: right
16:22:43 <SumitNaiksatam> i think we should have APIs for that
16:22:47 <bmelande> We should discuss that further as we go along
16:23:10 <SumitNaiksatam> i believe we haven't fleshed out the APIs for the library yet
16:23:17 <SumitNaiksatam> the -> this
16:23:18 <bmelande> SumitNaiksatam: Yes, right
16:23:51 <greg_r> True,  actually yamahata has started that, but i am behind. :)
16:24:10 <SumitNaiksatam> #action greg_r bmelande yamahata to discuss service VM library APIs
16:24:20 <SumitNaiksatam> anything more on this topic?
16:24:42 <amotoki> Let me follow my question.
16:24:48 <SumitNaiksatam> amotoki: sure
16:24:48 <amotoki> The difference between p2p and neutron network is: (1) support of multicast or broadcast and (2) L2 learning is not needed.
16:24:49 <amotoki> it is a separate topic.
16:25:09 <greg_r> amotoki:  noted
16:25:12 <SumitNaiksatam> amotoki: agree
16:25:36 <SumitNaiksatam> amotoki: with P2P link its pretty much a physical wire between the two VMs
16:25:50 <amotoki> SumitNaiksatam: right.
16:25:54 <SumitNaiksatam> amotoki: so its probably easier to achieve chaining in that case
16:26:08 <SumitNaiksatam> amotoki: don't have to worry about steering traffic
16:26:33 <amotoki> it is a good information to a provider.
16:26:46 <SumitNaiksatam> amotoki: good point
16:27:08 <SumitNaiksatam> #topic Service VMs - Policy
16:27:15 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt
16:27:22 <SumitNaiksatam> #info #link http://icehousedesignsummit.sched.org/event/782186bf7a0ad388ef823bd0b5cd2b0e
16:27:29 <SumitNaiksatam> Geoff A is not here
16:27:35 <SumitNaiksatam> at least i don't see him
16:27:42 <SumitNaiksatam> I believe he is busy preparing :-)
16:27:53 <SumitNaiksatam> #topic Extensible API: deal with growing services
16:28:05 <SumitNaiksatam> #info #link http://icehousedesignsummit.sched.org/event/7ed1b0286b3d5aefd23bb9a69d3faba3
16:28:16 <SumitNaiksatam> i did not get a pong back from here either
16:28:27 <SumitNaiksatam> not sure if there is anything to discuss before the summit
16:28:40 <SumitNaiksatam> #topic Open Discussion
16:28:58 <SumitNaiksatam> any parting thoughts before we unite at the summit again? ;-)
16:29:32 <yamahata> Maybe slightly off topic, can we have vlan-VM unconference?
16:29:39 <greg_r> happy travels
16:30:06 <greg_r> yamahata:  good point
16:30:11 <bmelande> yamahata: what do you mean by vlan-VM?
16:30:18 <bmelande> yamahata: vlan trunks to the VM?
16:30:43 <yamahata> bmelande, right.
16:30:53 <SumitNaiksatam> yamahata: perhaps include in the service VM bp as well
16:30:54 <bmelande> yamahata: +1
16:31:17 <SumitNaiksatam> yamahata: we were having this discussion in the context of fwaas as well
16:31:26 <SumitNaiksatam> yamahata: lets take offline
16:31:32 <SumitNaiksatam> anything else?
16:31:33 <SridarK> SumitNaiksatam: Can we continue with regular mtg post summit as well - helps keep things moving
16:31:34 <bmelande> SumitNaiksatam: Kyle has a blueprint for vlan trunks
16:31:54 <SumitNaiksatam> SridarK: sure, i think Nachi had the same suggestion
16:32:11 <SumitNaiksatam> SridarK: lets discuss during the summit, and we can come up with a good time for everyone
16:32:15 <SridarK> great thanks
16:32:21 <SumitNaiksatam> we can decide the frequency of the meetings
16:32:32 <SumitNaiksatam> bmelande: yes, we did ping kyle
16:32:50 <SumitNaiksatam> bmelande: however its a little short on what we need
16:32:53 <yamahata> https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api
16:32:54 <SumitNaiksatam> will add you to the thread
16:33:03 <yamahata> https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
16:33:05 <bmelande> SumitNaiksatam: We use vlan trunk capability in n1kv plugin together with service VM. It is very useful
16:33:29 <SumitNaiksatam> bmelande: yes definitely, i am aware :-)
16:33:41 <SumitNaiksatam> yamahata: thanks
16:33:54 <SumitNaiksatam> alright, folks we are little past our 60 mins
16:33:58 <SumitNaiksatam> see you all at the summit
16:34:09 <greg_r> ok thanks
16:34:11 <SumitNaiksatam> thanks for joning today
16:34:18 <SumitNaiksatam> bye for now
16:34:24 <amotoki> see you all at HK.
16:34:26 <SumitNaiksatam> discussions on mailing list and emails
16:34:32 <bmelande> Bye, bye. Next HK.
16:34:46 <SumitNaiksatam> #endmeeting