17:34:30 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:34:32 <openstack> Meeting started Wed Apr 16 17:34:30 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:34:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:34:33 <banix> SumitNaiksatam: hi
17:34:36 <openstack> The meeting name has been set to 'networking_advanced_services'
17:35:06 <SumitNaiksatam> #info the new blueprint review process is in effect for neutron
17:35:29 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-dev/2014-April/032806.html
17:35:55 <SumitNaiksatam> so if your bleuprint is not already in approved state, you will need to go through this process for approval
17:36:09 <SumitNaiksatam> i know this is already stale news to some ;-)
17:36:52 <SumitNaiksatam> so our standing item for this meeting:
17:36:54 <SumitNaiksatam> #topic Flavors Framework
17:37:09 <SumitNaiksatam> #link https://review.openstack.org/#/c/83055
17:37:22 <enikanorov_> yeah, so far no major updates
17:37:33 <SumitNaiksatam> enikanorov_ also sent out an email a couple of days back on this: #link http://lists.openstack.org/pipermail/openstack-dev/2014-April/032792.html
17:37:34 <enikanorov_> i'd love to try to apply the idea to some service
17:37:41 <enikanorov_> but i'm really blocked with that
17:38:05 <SumitNaiksatam> enikanorov_: you could have tried on FWaaS, but it does not have STF
17:38:20 <enikanorov_> what i'm interested in is the STF being integrated in fwaas or vpnaas
17:38:25 <SumitNaiksatam> enikanorov_: otherwise FWaaS is good candidate since it has some vendor drivers as well
17:38:56 <enikanorov_> SumitNaiksatam: i may try to rebase on that patch...
17:39:07 <SumitNaiksatam> okay back to the email which enikanorov_ sent, essentially it proposes keeping the existing service provider framework for the backend
17:39:16 <SumitNaiksatam> enikanorov_: ok sure
17:39:30 <enikanorov_> on STF: yes, but not expose it to API
17:39:46 <SumitNaiksatam> enikanorov_: yes
17:40:01 <SumitNaiksatam> so any thoughts from the folks here on the provider part?
17:40:16 <SumitNaiksatam> in case you got a chance to read through what enikanorov_ is proposing
17:40:54 <enikanorov_> i'm also concerned about the flavor format
17:41:04 <SumitNaiksatam> enikanorov_: sure, had some discussions on that
17:41:13 <enikanorov_> right now it is a list of k,v pairs
17:41:19 <enikanorov_> which is not exactly tags
17:41:32 <enikanorov_> but i think that may simplify builind UI around that
17:41:34 <SumitNaiksatam> enikanorov_: i think k,v is good
17:41:49 <enikanorov_> raw tags might be confusing
17:42:15 <SumitNaiksatam> enikanorov_: but there are at least three sets of these k,v
17:42:17 <hemanthravi> enikanorov_: tags would be known k?
17:42:30 <SumitNaiksatam> enikanorov_: those that are common to the neutron services’ framework
17:42:31 <enikanorov_> SumitNaiksatam: why three sets?
17:42:43 <SumitNaiksatam> enikanorov_: (2) those that are common to a service type
17:42:45 <enikanorov_> hemanthravi: not necessarily
17:43:15 <enikanorov_> i think the part of the solution is vendor drivers exporting those pairs to the plugin
17:43:19 <SumitNaiksatam> enikanorov_: and (3) those that differentiate between different service instances of the same service type
17:43:40 <enikanorov_> ah, i see
17:43:46 <enikanorov_> yes, seems so
17:43:57 <SumitNaiksatam> enikanorov_: i would think that the vendor specific would fall into the third category
17:44:19 <SumitNaiksatam> enikanorov_: your earlier point about raw tags, i believe, is in the context of the lack of this classification
17:44:37 <enikanorov_> right
17:44:51 <SumitNaiksatam> enikanorov_: for keys, defined in sets 1 and 2, there would be more semantics attached (they would be well defined) hence people would know how to use them
17:45:27 <SumitNaiksatam> that said, finding a common set for (1) and (2) can be a challenging exercise :-)
17:45:56 <enikanorov_> well, it seems to be a problem of setting the defaults
17:46:02 <SumitNaiksatam> enikanorov_: sure
17:46:12 <enikanorov_> i mean that flavors themselves are created by cloud operator
17:46:26 <enikanorov_> so user mostly unaffected
17:46:38 <enikanorov_> and then we can add types of tags as we go
17:46:46 <enikanorov_> i mean add hardcoded types
17:46:52 <enikanorov_> which fall into (1)
17:46:57 <SumitNaiksatam> enikanorov_: ok
17:47:00 <enikanorov_> *(1) and (2)
17:47:26 <SumitNaiksatam> other folks have thoughts on the tags (or k,v as we are referring to them here)?
17:47:43 <SumitNaiksatam> they will essentially define the flavor
17:47:54 <SumitNaiksatam> *flavor choice
17:48:41 <SumitNaiksatam> enikanorov_: so as a next step you said you wanted to take a crack at implementing this on fwaas?
17:48:42 <enikanorov_> so... i'll had to push this design on gerrit then :)
17:49:07 <enikanorov_> yes, I can try, on top of STF for fwaas
17:49:12 <Kanzhe> enikanorov_: SumitNaiksatam Is there a first set of k,v pairs for 1 and 2?
17:49:12 <SumitNaiksatam> enikanorov_: ok great
17:49:49 <hemanthravi> the k,v are also defined by the cloud operator when creating the flavors
17:50:23 <SumitNaiksatam> hemanthravi: yes, the point is that there has to be a base set for which there is common understanding across the project
17:50:28 <enikanorov_> one important part of the whole solution is the scheduling part
17:50:43 <enikanorov_> i hope everyone gets it right
17:50:44 <SumitNaiksatam> Kanzhe: perhaps once enikanorov_ put this bp in gerrit we can comment on what the base set would include
17:50:53 <SumitNaiksatam> enikanorov_: please go ahead
17:51:09 <enikanorov_> so on scheduling: it's a two step process
17:51:22 <s3wong> enikanorov_: is the scheduling part done by individual services?
17:51:29 <enikanorov_> first step matches flavor to a capabilities of the vendor driver
17:51:32 <enikanorov_> s3wong: yes
17:51:58 <enikanorov_> second step is internal, driver does that. it maps flavor to the capabilities of appliances that it manages
17:52:19 <enikanorov_> it can happen that driver doesn't manage appliances, then step #2 is skipped
17:52:23 <SumitNaiksatam> enikanorov_: i believe first step is done in the service plugin?
17:52:31 <enikanorov_> SumitNaiksatam: yes.
17:52:48 <enikanorov_> the result of step #1 is ProviderResourceMapping entry created for the resource
17:52:59 <SumitNaiksatam> enikanorov_: ok
17:53:13 <enikanorov_> the result of step #2 is ApplianceResourceMappign entry
17:53:14 <s3wong> enikanorov_: so vendors have to expose a set of capabilities? Or is it more like ML2 where each driver would come back and tell if it has all the capabilities?
17:53:24 <SumitNaiksatam> enikanorov_: can that entry be updated if the resource has to be moved somewhere else?
17:53:26 <enikanorov_> s3wong: yes
17:53:49 <enikanorov_> SumitNaiksatam: you mean user requests another capabilities?
17:54:00 <enikanorov_> s3wong: first option.
17:54:24 <enikanorov_> SumitNaiksatam: in that case resource can be rescheduled
17:54:29 <SumitNaiksatam> enikanorov_: no user interaction involved, just that the operator might want to move things around/optimize
17:55:05 <enikanorov_> yes, it can be updated, both entries
17:55:11 <SumitNaiksatam> enikanorov_: ok good
17:55:27 <SumitNaiksatam> Kanzhe: did you have any particular keys/tags in mind?
17:55:58 <SumitNaiksatam> we had defined a bunch of them when the initial discussion on STF was going on, and I had put it on the wiki
17:55:59 <enikanorov_> yeah, that would be good if you guys could help me to gather initial set of tags
17:56:14 <SumitNaiksatam> having trouble finding it now, would have to look into the history
17:56:35 <SumitNaiksatam> okay, any more questions for enikanorov_ today?
17:56:58 <Kanzhe> SumitNaiksatam: serviceContext may need a pair to derive insertion type. I will wait for enikanorov_ to put the initial draft.
17:57:11 <SumitNaiksatam> Kanzhe: ok
17:57:21 <SumitNaiksatam> enikanorov_: thanks, we will look forward to your bp in gerrit
17:57:32 <enikanorov_> ok
17:57:45 <SumitNaiksatam> #topic Port Chaining Proposal
17:58:00 <SumitNaiksatam> #link https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit
17:58:06 <SumitNaiksatam> cgoncalves: there?
17:58:11 <cgoncalves> SumitNaiksatam: sure
17:58:16 <SumitNaiksatam> great
17:58:29 <SumitNaiksatam> so there were a couple of excahnges on this over the mailer as well
17:58:33 <cgoncalves> so monday we added an initial proposal for the API and data models
17:58:43 <SumitNaiksatam> cgoncalves: nice job capturing the details in teh document
17:59:05 <cgoncalves> we also brainstormed other data models but that's the one up for discussion now
17:59:12 <cgoncalves> SumitNaiksatam: thanks
17:59:44 <cgoncalves> does anyone have questions regarding the proposal?
17:59:45 <SumitNaiksatam> in general my thinking is that, this is more along the lines of expressing intent for traffic steering
17:59:56 <SumitNaiksatam> between ports that is
18:00:34 <SumitNaiksatam> this probably could be a south side abstraction that the broader service chaining framework can use
18:00:56 <cgoncalves> SumitNaiksatam: it is but as I said on an email yesterday in reply to Kanzhe it can also be extended to traffic steering other than ports by extending the scope of the service function endpoint (SFE)
18:01:08 <cgoncalves> SumitNaiksatam: yup
18:01:40 <SumitNaiksatam> that said, the validation of a “port chain” is kind of a tricky issue
18:02:22 <SumitNaiksatam> i mean the validation for whether the traffic can indeed be steered betweek the given set of ports
18:02:47 <Kanzhe> cgoncalves: Is SFE meant for services that don't have neutron ports?
18:02:49 <cgoncalves> for an initial implementation we should focus only on steering traffic between ports, so L1
18:02:57 <SumitNaiksatam> also, to express this port chaining, you would already need the ports to exist, right?
18:03:15 <jsoares> SumitNaiksatam: the proposal is in fact expressing intent for traffic steering but I guess it is a bit more than that since it gives and e2e perpesctive (path along several ports)
18:03:56 <jsoares> SumitNaiksatam: which makes it closer to a SFC abstraction
18:04:12 <cgoncalves> SumitNaiksatam: yes, you would beed the ports to already exist
18:04:12 <SumitNaiksatam> jsoares: sure, but i am not sure that the port level abstraction is the best way to capture the e2e path
18:04:43 <cgoncalves> Kanzhe: my opinion is that for an initial implementation we should only focus on neutron ports
18:05:01 <SumitNaiksatam> cgoncalves: so that might be a bit of a problem with existing services in neutron
18:05:40 <SumitNaiksatam> jsoares: agreed, but services in neutron are not only services in VMs
18:05:43 <cgoncalves> Kanzhe: but it could later be extended to have a 'type' attribute where it could be extend to L2 or L3 steering rather than only L1 steering (ports)
18:06:22 <s3wong> cgoncalves: interesting. endpoints are identified by ports, chain is associated with flow, then a flow has a list of classifiers. The list of endpoints is ordered?
18:06:40 <jsoares> SumitNaiksatam: yes, but that is also why a SFC is not directly associated to neutron ports, but is associated to SF Endpoints. a SF Endpoint could be associated to something else rather than a neutron port
18:07:41 <cgoncalves> s3wong: the list of endpoints was previously an ordered list, but it's not required as we discussed internally, so that requirement has been dropped
18:08:31 <Kanzhe> cgoncalves: I think the current Neutron ports are all L3 ports, with mac and IP.
18:08:54 <s3wong> cgoncalves: then how is the order of traffic flow through the chain be configured?
18:08:57 <SumitNaiksatam> jsoares: ok, in which case its probably similar to the existing proposal around service chains
18:09:49 <SumitNaiksatam> jsoares: my understanding, where this proposal complements the existing discussion, is to be able to signal intent for the traffic sterring between a set of neutron ports
18:09:51 <jsoares> s3wong: the endpoints don't actually have to be ordered because the traffic steering would be done at each pair of ports (i.e. the same forwarding rule would be applied to all hops in the chain)
18:10:07 <cgoncalves> Kanzhe: that said, you're saying we could not steer traffic based on ports but just mac and IP?
18:10:23 <SumitNaiksatam> jsoares cgoncalves: i am with s3wong  here, i would have expected this to be an ordered list
18:10:45 <banix> the order seem to be implicit
18:11:04 <SumitNaiksatam> banix: based on the flow?
18:11:26 <banix> yes if i understand it correctly
18:11:35 <jsoares> SumitNaiksatam s3wong: maybe we can further clarify this aspect in the proposal. We believe it can be an order list but it does not need to be.
18:11:44 <SumitNaiksatam> jsoares: sure
18:11:56 <cgoncalves> s3wong, SumitNaiksatam: ok, so yesterday we came up with this new list of endpoints structure. instead of being a list of endpoints it should be a list of list of {K,V}+PassiveEndpoints
18:12:01 <s3wong> jsoares: sure
18:12:30 <Kanzhe> cgoncalves: that was my question: is neutron port the right abstraction for traffic steering. Maybe it is, then it needs to be extended. Maybe not.
18:12:31 <cgoncalves> an example of a passive endpoint is the one in use case #4 (MON_01)
18:12:46 <s3wong> cgoncalves: passive endpoint?
18:13:19 <cgoncalves> s3wong: network taps :)
18:13:21 <jsoares> Kanzhe: I think I see your point. E.g. if you have a function that does not have an IP in its interface, the neutron port would say it had...is that it?
18:14:37 <cgoncalves> Kanzhe: I'm not 100% sure, but in principle it should be doable? :)
18:15:10 <jsoares> s3wong: the notion of "passive" or "active" relates if the enpoint is in fact part of the main course of the chain or not. A passive function can be a function that has a promiscuous interface and is just looking into packets and does nothing (e.g. DPI)
18:15:44 <cgoncalves> ^ what jsoares said
18:15:50 <SumitNaiksatam> ok perhaps, jsoares and cgoncalves are planning some more updates to their document
18:15:57 <jsoares> s3wong: Use case #4 has cgoncalves pointed out
18:16:06 <Kanzhe> jsoares: kind of. If a service is a L1 device. Currently, the device is invisible to Neutron since create_port can't be called for such device's interface.
18:16:14 <SumitNaiksatam> in general i am thinking of this as neutron port-chain abstraction
18:16:16 <s3wong> jsoares: OK. Thanks
18:16:47 <SumitNaiksatam> and can be leveraged (at times) by the broader service chaining framework
18:17:02 <SumitNaiksatam> in interest of time lets move to the next topic
18:17:13 <SumitNaiksatam> cgoncalves jsoares: thanks!
18:17:23 <jsoares> Kanzhe: Ah, yes, agree!
18:17:24 <SumitNaiksatam> #topic Service context with Service Interfaces
18:17:43 <cgoncalves> yw
18:17:57 <jsoares> yw
18:18:06 <SumitNaiksatam> so Kanzhe had some more thoughts on our definition of the service_context based on the review comments in the patch: #link https://review.openstack.org/#/c/62599
18:18:24 <Kanzhe> jsoares: cgoncalves I am facing the same issue for service insertion. Neutron port belongs to a Neutron network. It doesn't make much sense to use Neutron port for L1 interface.
18:18:27 <SumitNaiksatam> here’s kanzhe’s document: #link #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit
18:18:36 <SumitNaiksatam> Kanzhe: you want to summarize?
18:19:57 <prasadv_> Kanzhe: can elaborate on not using neutron port for L1?
18:20:00 <Kanzhe> Since L1 device doesn't belong to any network. It probably makes more sense to define another abstraction for such purpose.
18:20:05 <cgoncalves> Kanzhe: we can move this discussion to the mailing list or schedule some time in #openstack-neutron
18:21:07 <s3wong> Kanzhe: L1 is transparent insertion, bump-in-the-wire?
18:21:29 <Kanzhe> prasadv_: L1 is a invisible to L2 or L3 entities.
18:21:38 <prasadv_> s3wong: L1 is bridged insertion
18:21:38 <Kanzhe> s3wong: yes.
18:22:03 <prasadv_> Kanzhe: it is bridged insertion right?
18:23:18 <hemanthravi> kanzhe: the ip/mac are redundant but a neutron port would be functional for L1
18:23:35 <Kanzhe> Thanks, SumitNaiksatam. In the writeup shared by Sumit, I added a new object, serviceInterface. It captures L3, L2, and L1 interfaces. It could also be used for traffic steering.
18:23:42 <Kanzhe> prasadv_: yes.
18:24:03 <prasadv_> shouldnt we separate interfaces from insertion?
18:24:39 <SumitNaiksatam> prasadv_: i believe the thinking is that the service interfaces are required for service insertion
18:24:40 <Kanzhe> prasadv_: why?
18:24:54 <prasadv_> what I mean is a service has ports associated with a service
18:25:01 <Kanzhe> hemanthravi: how?
18:25:09 <SumitNaiksatam> prasadv_: hence specify what those interface types are, and accordingly the service can be inserted
18:25:25 <SumitNaiksatam> prasadv_: the interfaces plug into the ports
18:25:26 <hemanthravi> kanzhe: the L1 service doesn't use these
18:25:36 <prasadv_> and then how the service is inserted determines how traffic flows between the ports of the service
18:25:46 <prasadv_> and also the type of service
18:26:26 <prasadv_> L3 routes between the ports right?
18:26:44 <prasadv_> L1 bridges the traffic between the ports
18:26:54 <SumitNaiksatam> Kanzhe: i think the point where we are tripping over is, will an L1 interface have a correspoding “neutron” port manifestation?
18:26:59 <Kanzhe> prasadv_: service insertion is different from traffic flow, which is traffic steering.
18:27:07 <s3wong> prasadv_: are you advocating just using ports?
18:28:10 <prasadv_> Kanzhe: but the type of service being inserted determines the flow doesnt it?
18:28:50 <SumitNaiksatam> okay i think we need to spend a little more time on Kanzhe’s document, and perhaps some more higher bandhwidth discussions
18:28:52 <s3wong> [2 minutes]
18:28:58 <prasadv_> s3wong: Not sure. Need to think
18:29:02 <SumitNaiksatam> s3wong: yes! :-)
18:29:07 <Kanzhe> SumitNaiksatam: Yes, we can either extend the Neutron port to support L1, L2 interfaces, or a separate object. I haven't wrapped my head around on which one makes more sense.
18:29:15 <SumitNaiksatam> Kanzhe: ok
18:29:19 <SumitNaiksatam> Kanzhe: thanks
18:29:24 <SumitNaiksatam> #topic Open Discussion
18:29:48 <cgoncalves> Kanzhe: yup, that would be then the main issue here to sort out
18:29:57 <SumitNaiksatam> so we havent yet reached out to the Neutron PTL regarding us getting a standing item on the neutron IRC
18:30:15 <SumitNaiksatam> but i believe enikanorov_, nachi, and i are on the same page on this
18:30:17 <jsoares_> Kanzhe, SumitNaiksatam: that was in fact something that we also thought about, neutron port to also reflect L1 aspects
18:30:25 <cgoncalves> 1 hour is proving to be short to discuss all topics. should we arrange another meeting for chaining?
18:30:42 <SumitNaiksatam> cgoncalves: we have had several in the past :-)
18:30:47 <cgoncalves> I mean, as it is still an early topic of discussion
18:30:56 <s3wong> we could just always eat into FWaaS's time :-)
18:30:56 <cgoncalves> SumitNaiksatam: off adv-services meetings?
18:30:57 <Kanzhe> prasadv_: No. I disagree. Insertion type is independent of what flows is steered to the service interface.
18:31:09 <SumitNaiksatam> cgoncalves: service chaining has a long history of discussion :-)
18:31:47 <cgoncalves> SumitNaiksatam: and yet we are still discussing it hehe :)
18:32:02 <SumitNaiksatam> so i think in terms of priority, getting the flavors work done by enikanorov_ is clearly a prirority from an advanced services common requirements perspective
18:32:17 <SumitNaiksatam> i also think the service insertion part need to be sorted out
18:32:22 <Kanzhe> SumitNaiksatam: and service insertion. :-)
18:32:32 <SumitNaiksatam> Kanzhe: yeah, right on cue! :-)
18:32:36 <cgoncalves> SumitNaiksatam: agreed
18:32:55 <SumitNaiksatam> i believe there are aspects related to certificate management that swami had brought up earlier
18:33:00 <s3wong> SumitNaiksatam: some sort of Neutron representation of "service" is also needed for GBP
18:33:12 <SumitNaiksatam> s3wong: very much agree
18:33:25 <SumitNaiksatam> s3wong: in fact that is a precursor to the service insertion
18:33:28 <prasadv_> Kanzhe: I agree what traafic flows from outside is independent of service insertion
18:34:00 <SumitNaiksatam> so good, lets collect the list of items that we need to prioritize and present to the broader neutron community/core team
18:34:20 <banix> SumitNaiksatam: and a timeframe maybe?
18:34:23 <SumitNaiksatam> we have also proposed a design summit session for this
18:34:27 <SumitNaiksatam> banix: absolutely
18:34:39 <SumitNaiksatam> i am not sure if we will get a slot
18:35:09 <SumitNaiksatam> but please, reach out to me or on the mailer as to what items are in your critical path from an advanced services common requirements perspective
18:35:24 <SumitNaiksatam> and we can accordingly prioritize and get reviewer attention for thise
18:35:27 <SumitNaiksatam> those
18:35:38 <SumitNaiksatam> note that we first have to get the blueprints reviewed now!
18:35:54 <SumitNaiksatam> alright, anything more today?
18:36:12 <SumitNaiksatam> dont want to make a habit of going over the time every week!
18:36:53 <SumitNaiksatam> okay thanks everyone for joining, lets keep plugging at this
18:36:59 <SumitNaiksatam> #endmeeting