17:32:57 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:32:58 <openstack> Meeting started Wed Apr 23 17:32:57 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:33:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:33:02 <openstack> The meeting name has been set to 'networking_advanced_services'
17:34:02 <SumitNaiksatam> #info the advanced services common requirements session is accepted for the summit #link http://summit.openstack.org/cfp/details/19
17:34:43 <SumitNaiksatam> we have our task cut out in terms of prioritzing what we want to discuss in that slot
17:34:50 <SumitNaiksatam> lets bring that up again in the open discussion
17:35:05 <SumitNaiksatam> #topic Flavors Framework
17:35:13 <SumitNaiksatam> our standing agenda item
17:35:27 <SumitNaiksatam> enikanorov_: any plans to submit the blueprint spec?
17:35:44 <enikanorov_> SumitNaiksatam: working on it right now.
17:35:52 <SumitNaiksatam> enikanorov_: great
17:36:05 <SumitNaiksatam> btw, the current PoC patch: #link https://review.openstack.org/#/c/83055
17:36:07 <enikanorov_> not really. it seems that i hate the new process! :)
17:36:24 <SumitNaiksatam> enikanorov_: ouch! :-)
17:36:42 <SumitNaiksatam> unfortunately undo will not work on that!
17:36:49 <enikanorov_> so, on the patch and on the FW in general
17:36:54 <SumitNaiksatam> enikanorov_: yes please
17:37:01 <enikanorov_> i heard many complaints about the term 'flavor'
17:37:11 <enikanorov_> so let's may be discuss the name again?
17:37:21 <enikanorov_> i don't remember we have finalized this
17:37:28 <s3wong> enikanorov_: really? I thought flavor was favored due to its name being in tune with Nova
17:37:29 <enikanorov_> or we can leave it to ML
17:37:34 <enikanorov_> i've started the thread
17:37:35 <SumitNaiksatam> enikanorov_: no we havent
17:37:40 <SumitNaiksatam> enikanorov_: sure
17:37:58 <SumitNaiksatam> enikanorov_: i thought the main change over the STF was the name :-P
17:37:59 <enikanorov_> s3wong: nope... actually didn't head of a positive feedback on the name
17:38:06 <enikanorov_> haha
17:38:08 <SumitNaiksatam> STF -> flavor
17:38:12 <SumitNaiksatam> kidding! :-)
17:38:30 <SumitNaiksatam> enikanorov_: you obviously deserve more credit than that
17:38:34 <banix> can we reuse service type or it will be confusing
17:38:45 <enikanorov_> yep, it's confusing
17:38:53 <s3wong> banix: well, the flavor object contains service type, so a bit confusing
17:39:11 <banix> and rename service type :)
17:39:12 <enikanorov_> i don't have strong opinion on name though
17:39:13 <SumitNaiksatam> enikanorov_: what are the current candidates for the name?
17:39:17 <banix> noy really
17:39:38 <enikanorov_> per ML there is a suggestion to actually split the resource name into service-specific resource names
17:39:47 <enikanorov_> like FirewallType, LoadbalancerType
17:39:48 <enikanorov_> etc
17:40:00 <enikanorov_> it somewhat makes sense to me
17:40:05 <SumitNaiksatam> enikanorov_: hmmm
17:40:15 <SumitNaiksatam> enikanorov_: what would you call the framework, though
17:40:17 <SumitNaiksatam> ?
17:40:26 <enikanorov_> but I'd prefer single name and single resource
17:40:32 <SumitNaiksatam> enikanorov_: agree
17:40:55 <enikanorov_> framework is mostly around scheduling, capability matching, etc...
17:40:55 <SumitNaiksatam> folks, banix: if you have thoughts, perhaps a good idea to send to the ML
17:41:13 <enikanorov_> internally we may have one model exposed through different resources
17:41:23 <SumitNaiksatam> enikanorov_: ok
17:41:30 <banix> enikanorov_: which is good
17:41:45 <SumitNaiksatam> enikanorov_: regarding the PoC patch
17:41:58 <SumitNaiksatam> i noticed that nachi put some comments
17:42:12 <SumitNaiksatam> enikanorov_: i dont think there is anything major suggested there
17:42:13 <enikanorov_> yeah, but those are code style nits
17:42:17 <enikanorov_> yep
17:42:22 <SumitNaiksatam> yeah, mostly cosmetics
17:42:49 <SumitNaiksatam> enikanorov_: i guess not as many people are looking at the patch, they expect the BP spec first
17:42:56 <SumitNaiksatam> *expect to see
17:43:06 <enikanorov_> i guess so. plan to push it tomorrow
17:43:16 <SumitNaiksatam> enikanorov_: nice
17:43:31 <SumitNaiksatam> any more questions for enikanorov_?
17:44:10 <SumitNaiksatam> #topic Service context with Service Interfaces
17:44:21 <SumitNaiksatam> #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit
17:44:24 <SumitNaiksatam> Kanzhe: there?
17:44:33 <Kanzhe> SumitNaiksatam: yes
17:45:04 <SumitNaiksatam> so there was some discussion on this through the week
17:45:09 <SumitNaiksatam> people have provided comments
17:45:31 <SumitNaiksatam> the above is an evolution over the original bp spec
17:45:42 <SumitNaiksatam> Kanzhe: you want to summarize the discussions till this point?
17:46:23 <Kanzhe> There have been some feedbacks on the difficulties in using the current serviceContext API.
17:46:40 <banix> SumitNaiksatam: which original bp?
17:46:59 <SumitNaiksatam> banix: #link https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit
17:47:07 <banix> SumitNaiksatam: thanks
17:47:35 <SumitNaiksatam> Kanzhe: go ahead
17:47:43 <Kanzhe> An alternative API was proposed, and defines a provider workflow and tenant workflow.
17:48:13 <Kanzhe> On the provider side, ServiceContext is a list of serviceInterface.
17:49:08 <Kanzhe> When a provider makes a service available, it defines a list of available serviceInterfaces, which may capture the physical location, mac address, etc.
17:49:38 <Kanzhe> Then tenant uses the XaaS API to create a logic service.
17:50:11 <SumitNaiksatam> Kanzhe: serviceInterface is per the definition in your document, but not a resource, right?
17:50:27 <Kanzhe> We will introduce add/delete interface API for tenant to define the serviceContext for the logic services.
17:50:47 <Kanzhe> It will be a resource.
17:50:59 <banix> isnt it already a resource in the doc?
17:51:00 <Kanzhe> and has UUID.
17:51:23 <jsoares> Kanzhe: do you consider that a serviceInterface can be created by regular OpenStack tenant?
17:52:10 <Kanzhe> jsoares: whoever is responsible to stand up the actual service instance defines the serviceInterface.
17:52:19 <SumitNaiksatam> Kanzhe: hmmm…if its a purely provider artifact, perhaps not required to make this a resource
17:52:49 <SumitNaiksatam> Kanzhe: the tenant only needs to see the port side of this interface
17:53:06 <Kanzhe> My understanding of provider is admin user that creates serviceInterface.
17:54:02 <Kanzhe> SumitNaiksatam: yes, serviceInterface is a resource not visible to tenant. If that makes sense.
17:54:09 <SumitNaiksatam> Kanzhe: my questions is that whether that orchestration happens internal to the provider implementation
17:54:22 <SumitNaiksatam> *question
17:54:48 <jsoares> Kanzhe: but the admin user "owns" OpenStack right? What if, a tenant wants to introduce himself a function that he owns?
17:55:07 <SumitNaiksatam> btw, to put this in context for anyone not following this discussion - we are discussing the insertion of a single service
17:55:41 <SumitNaiksatam> jsoares: how would that function be configured?
17:55:44 <Kanzhe> SumitNaiksatam: Don't quite understand the question.
17:56:00 <s3wong> SumitNaiksatam: the admin user would still need to get a handle of the serviceInterface (add/delete, plug), so it needs to be a resource, right?
17:56:27 <SumitNaiksatam> Kanzhe: by “that” i meant creation of the service interface (but you answered my question, I think)
17:56:47 <jsoares> SumitNaiksatam: that function would be configured by the tenant itself, which could be an external system
17:56:49 <SumitNaiksatam> s3wong: isnt that an implementation detail?
17:57:13 <SumitNaiksatam> jsoares: good, as far as OpenStack is concerned, its just a VM, right?
17:57:46 <s3wong> SumitNaiksatam: but the admin user would still need to GET/POST on that interface, right?
17:57:57 <SumitNaiksatam> s3wong: to do what?
17:58:05 <jsoares> SumitNaiksatam: right! just a VM, but we have seen that the notion of "port" is not enough for Service Function, therefore it would need something like a Service Interface
17:58:43 <s3wong> SumitNaiksatam: add, delete, connect/plug?
17:59:18 <SumitNaiksatam> s3wong: can those operations can be performed on the service resource?
18:00:02 <s3wong> SumitNaiksatam: yeah, I see what you are saying
18:00:07 <Kanzhe> jsoares: Tenant should only consume Neutron port. There are discussion to extend the Neutron port to support L1 interfaces.
18:01:03 <SumitNaiksatam> jsoares: yeah, to add to what Kanzhe said, we are thinking if the service interface part can be hidden inside the implementation, the tenant only sees the port counterpart of that service interface
18:01:34 <SumitNaiksatam> i dont think this is in the document yet
18:01:44 <jsoares> Kanzhe: but then, a Neutron port would evolve and be able to be what we are referring as Service Interface? I mean, it can be just L1, L1+L2, L1+L2+L3?
18:01:54 <SumitNaiksatam> perhaps might make things a little clearer with a diagram in the document
18:02:24 <s3wong> jsoares: exactly. I believe that came up with our discussion earlier. We need to evolve neutron port
18:02:37 <Kanzhe> jsoares: yes. SumitNaiksatam : I finally see where you question is from?
18:03:15 <jsoares> s3wong, Kanzhe: then it's clear for me now!
18:04:34 <SumitNaiksatam> Kanzhe: plans to update the document?
18:04:43 <Kanzhe> SumitNaiksatam: However, provider needs to be able to define serviceInterfaces (add/delete). If SI is not a resource, how are the config tracked?
18:05:09 <SumitNaiksatam> Kanzhe: can it not be just internal objects?
18:06:23 <Kanzhe> SumitNaiksatam: I am thinking there needs to be a DB table for serviceInterface, hence a resource.
18:06:44 <SumitNaiksatam> Kanzhe: DB table yes, but that does not necessarily translate to a resource
18:07:23 <SumitNaiksatam> ok, Kanzhe perhaps updating the document will help others to come up to speed with the discussion
18:07:30 <s3wong> SumitNaiksatam: so it is just a list of things attached to a Service resource
18:07:31 <Kanzhe> SumitNaiksatam: Ok, DB table is what I meant.
18:07:43 <SumitNaiksatam> Kanzhe: i guessed as much :-)
18:08:02 <SumitNaiksatam> s3wong: kind of
18:08:14 <SumitNaiksatam> s3wong:  as long as the provider can make sense of it
18:08:26 <s3wong> SumitNaiksatam: cool
18:08:31 <SumitNaiksatam> s3wong: but then its the provider’s implementation, so it should be possible
18:08:45 <SumitNaiksatam> Kanzhe: i believe there was also a suggestion to define a southbound interface
18:09:17 <Kanzhe> SumitNaiksatam: Yes, we just covered the provider workflow.
18:09:39 <SumitNaiksatam> Kanzhe: perhaps we can add to the document
18:09:42 <Kanzhe> There is a tenant workflow, where tenant can instantiate a logic resource.
18:09:57 <Kanzhe> SumitNaiksatam: yes, I will update the doc.
18:09:59 <s3wong> SumitNaiksatam: I think the SB interfaces are for a generic service plugin to send API calls to service drivers
18:10:03 <SumitNaiksatam> Kanzhe: thanks
18:10:11 <SumitNaiksatam> s3wong: yes
18:10:31 <SumitNaiksatam> s3wong: its more than the just the provider workflow
18:10:37 <Kanzhe> Once the logic service is created, user can add an interface to the service.
18:10:46 <SumitNaiksatam> lets wait for Kanzhe’s update to the document
18:11:18 <Kanzhe> The tenant workflow mirros well with the existing router interface workflow.
18:11:29 <SumitNaiksatam> Kanzhe: ok
18:11:33 <SumitNaiksatam> ok moving on
18:11:41 <SumitNaiksatam> #topic Port Chaining Proposal
18:11:43 <s3wong> Kanzhe: agreed. It is a clean model
18:11:52 <SumitNaiksatam> #link https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit
18:12:05 <SumitNaiksatam> cgoncalves jsoares: there?
18:12:12 <cgoncalves> SumitNaiksatam: we are :)
18:12:31 <SumitNaiksatam> cgoncalves: thanks for updating the proposal
18:12:52 <SumitNaiksatam> cgoncalves: nicely documented, including the use cases
18:12:53 <cgoncalves> since last meeting we had 1,5 days of public holidays so not much of work on this :)
18:13:00 <SumitNaiksatam> cgoncalves: no worries
18:13:02 <cgoncalves> SumitNaiksatam: thanks
18:13:46 <cgoncalves> I've already start writting some API and DB code but it's still early to share
18:13:52 <SumitNaiksatam> cgoncalves: so as we discussed before, i think we can potentially leverage this work as a traffic steering building block
18:14:03 <SumitNaiksatam> what do others think about this?
18:14:09 <cgoncalves> hoping that way we can gather more input from the community
18:14:41 <jsoares> as a side note, we have also been looking how to enforce this via ODL (OpenDaylight)...we've been doing some tests
18:14:46 <s3wong> SumitNaiksatam: agreed. there are enough overlaps that we should merge the two efforts - unify the way we will do traffic steering
18:14:51 <SumitNaiksatam> jsoares: nice
18:14:58 <cgoncalves> SumitNaiksatam: it sounds good! :)
18:15:26 <SumitNaiksatam> s3wong: i am thinking that there are three pieces that we are dealing with here
18:15:36 <jsoares> SumitNaiksatam: agree with the steering building block.
18:15:42 <SumitNaiksatam> (1) service insertion (the part we just discussed with Kanzhe’s proposal)
18:16:15 <SumitNaiksatam> (2) trafffic steering (including classifier) as being discussed in cgoncalves and jsoares’ proposal
18:16:42 <SumitNaiksatam> (3) service chain (which includes addressing neutron services)
18:17:05 <SumitNaiksatam> (3) would rely on (1) and (2)
18:17:40 <Kanzhe> SumitNaiksatam: yes, agreed.
18:18:09 <s3wong> SumitNaiksatam: in that case, both (2) and (3) should depend on (1)
18:18:28 <cgoncalves> SumitNaiksatam: our proposal addresses (2) traffic chaining as a dependency for (3) service chain which is our ultimate goal
18:19:05 <Kanzhe> 3 leverages 2, which leverages 1.
18:19:05 <jsoares> SumitNaiksatam: but do you see (2) exposed like the proposal presents it now? I mean, something like "Traffic Steering Chain"
18:19:36 <s3wong> Kanzhe: so we are all relying on you to get (1)'s proposal out :-)
18:19:44 <banix> jsoares: should not be exposed in my opinion
18:19:54 <SumitNaiksatam> jsoares: we need to think through, but it does seem like it is a candidate for a lower level traffic steering API
18:20:23 <banix> where would t be used beyond service chains?
18:20:41 <Kanzhe> s3wong: end of the day, it is a team effort to the serviceChaining holy grail. :-)
18:20:42 <SumitNaiksatam> banix: i agree that it would be very difficult to consume for the tenant to consume
18:20:47 <s3wong> jsoares: traffic steering framework should be lower level in that you are creating classifers/rules to move traffic flow off of its natural flow
18:20:51 <SumitNaiksatam> difficult -> complex
18:21:12 <s3wong> jsoares: but service chain would be a composition of tenant addressable neutron service objects
18:21:25 <SumitNaiksatam> s3wong: agree
18:21:47 <jsoares> SumitNaiksatam, s3wong: That would suit Neutron services, but what if the tenant itself want to build a Service Function Chain himself?
18:22:06 <SumitNaiksatam> banix s3wong: i think where jsoares is coming from is to be able to make service VMs to be part of the chain
18:22:15 <jsoares> with its own Functions, or other functions that are not within Neutron today
18:22:28 <SumitNaiksatam> jsoares: yes, i get that, see ^^^ :-)
18:22:32 <Kanzhe> s3wong: we will need a generic service object for other services that not yet defined in Neutron.
18:22:44 <s3wong> jsoares: it sounds like for BYOS, we need to have a service object able to reference to a VM
18:22:46 <SumitNaiksatam> Kanzhe: good point
18:22:53 <jsoares> SumitNaiksatam: Yes, we highlight that in the introduction of our proposal
18:23:02 <SumitNaiksatam> s3wong: BYOS, nice!! :-)
18:23:09 <banix> SumitNaiksatam: shouldnt that be through the "service in VM" work?
18:23:10 <s3wong> Kanzhe: absolutely
18:23:10 <SumitNaiksatam> s3wong: copyright it! :-)
18:23:32 <s3wong> banix: service VM is now being moved out of Neutron
18:23:51 <banix> s3wong: i know but there should be something higher level
18:24:14 <s3wong> banix: we can have generic service object able to point to a VM designated by a tenant
18:24:19 <SumitNaiksatam> cgoncalves jsoares: i see in your document that you had plans to update it
18:24:39 <SumitNaiksatam> cgoncalves jsoares: we will need to normalize on some of the terminology
18:24:49 <SumitNaiksatam> endpoints in being used int he GP proposal
18:24:50 <s3wong> banix: but lifecycle management of the service in VM should not be Neutron's job
18:25:06 <banix> s3wong: that's great and desirable but the question is how that gets done and through what APIs ....
18:25:07 <jsoares> SumitNaiksatam: sure!
18:25:10 <SumitNaiksatam> also, i would propose a traffic sterring terminlogy, rather than chain
18:25:28 <cgoncalves> SumitNaiksatam: gp_endpoint, sf_endpoint; gp_classifier, sf_classifier :) kidding
18:25:33 <s3wong> banix: the service VM effort is still going :-) just not a Neutron project
18:25:35 <SumitNaiksatam> s3wong banix: lets have the service VM discussion next week
18:25:47 <SumitNaiksatam> cgoncalves: :-)
18:26:10 <SumitNaiksatam> #topic Certificate Management
18:26:16 <SumitNaiksatam> Swami: there?
18:26:23 <Swami> yes
18:26:29 <Swami> I am here.
18:26:42 <SumitNaiksatam> the issue is that there is a requirement across services to be able to deal with certificates
18:26:50 <SumitNaiksatam> and we dont have a way to do that today
18:26:54 <SumitNaiksatam> Swami: over to you
18:27:07 <Swami> There was some concerns and discussions about storing the certificates for the services in neutron.
18:27:27 <Swami> Both Lbaas and VPNaaS had an issue with the Icehouse.
18:27:27 <SumitNaiksatam> Swami: is there a ML thread on this?
18:27:55 <Swami> My question is, does this Advanced Services team need to own this as part of addressing the advanced services.
18:28:21 <SumitNaiksatam> Swami: okay, lets first bring this up with the PTL
18:28:51 <SumitNaiksatam> lets get initial thoughts, and we can accordingly start discussing this (either here, or as a separate thread)
18:28:52 <Swami> SumitNaiksatam: Recently the ssl VPN work and the Lbaas ssl offload work was stopped, since there was no infrastructure to support secure certificates.
18:29:16 <Swami> SumitNaiksatam: Yes that makes sense.
18:29:20 <SumitNaiksatam> #action SumitNaiksatam Swami to follow up with PTL regarding certificate management
18:29:23 <SumitNaiksatam> Swami: thanks
18:29:40 <SumitNaiksatam> #Atlanta Summit Discussion
18:29:49 <enikanorov_> there is some progress with barbican which has incubated
18:30:03 <SumitNaiksatam> #topic Atlanta Summit Discussion
18:30:17 <SumitNaiksatam> enikanorov_: thanks, we can check that
18:30:46 <SumitNaiksatam> at this point, i have collected the following prirorities from the previous discussion:
18:31:02 <SumitNaiksatam> * flavors framework
18:31:03 <SumitNaiksatam> * base service definition
18:31:04 <SumitNaiksatam> * service insertion framework
18:31:05 <SumitNaiksatam> * service chaining framework
18:31:06 <SumitNaiksatam> * certificate management
18:31:12 <SumitNaiksatam> this is just a laundry list
18:31:26 <s3wong> SumitNaiksatam: that is very ambitious for one 40 minutes session
18:31:29 <SumitNaiksatam> putting it out there early so that we can think through
18:31:35 <SumitNaiksatam> s3wong: i know
18:31:46 <SumitNaiksatam> if we converge on some topics, we can knock them off this list
18:32:12 <SumitNaiksatam> also, we have made it clear to the PTL that a shared 40 min slot is pretty short time for this discussions
18:32:30 <SumitNaiksatam> what we can do is, if there is enough interest, have follow up break up sessions
18:32:48 <SumitNaiksatam> or even prior to this session
18:33:03 <SumitNaiksatam> i believe our session will be on thursday
18:33:24 <SumitNaiksatam> any thoughts/comments on this or in general?
18:33:42 <banix> SumitNaiksatam , others: are ypou planning on having specs for review?
18:33:51 <SumitNaiksatam> banix: yes definitely
18:34:04 <SumitNaiksatam> banix: so we need to have some basic level of convergence on the design
18:34:22 <SumitNaiksatam> banix: based on that we can go to the neutron core team/PTL and request prioritization
18:34:31 <s3wong> SumitNaiksatam: we definitely need to work on getting base service object definition nailed down
18:34:33 <SumitNaiksatam> banix: and accordingly out the specs in
18:34:44 <SumitNaiksatam> s3wong: definitely agree
18:34:53 <banix> s3wong: agree
18:34:59 <SridarK> SumitNaiksatam: should we also outline the impacts to the current reference implementations
18:35:46 <SumitNaiksatam> SridarK: yes, that will be a part of the feasibility discussion when choosing a particular approach
18:36:05 <SridarK> ok got it
18:36:22 <SumitNaiksatam> SridarK: i agree, changes to the base service definition might need changes to existing service implementations
18:36:34 <SumitNaiksatam> ok folks, we are over time
18:36:40 <SumitNaiksatam> any parting thoughts/comments?
18:37:18 <SumitNaiksatam> alright thanks all!
18:37:24 <SumitNaiksatam> see you next week
18:37:25 <s3wong> thanks!
18:37:25 <banix> bye
18:37:25 <SumitNaiksatam> bye
18:37:31 <SumitNaiksatam> #endmeeting