17:31:41 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:31:42 <openstack> Meeting started Wed Jun 18 17:31:41 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:46 <openstack> The meeting name has been set to 'networking_advanced_services'
17:31:49 <rkukura> hi
17:31:56 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices
17:32:09 <cathy_> hi
17:32:27 <SumitNaiksatam> to put things into perspective, here is the Neutron Juno project plan (as proposed by the PTL earlier)
17:32:27 <regXboi> I'm pretty sure I've reviewed all the BPs
17:32:38 <SumitNaiksatam> #info Neutron Juno Project Plan: https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
17:32:55 <SumitNaiksatam> we need to prioritize accordingly
17:33:12 <SumitNaiksatam> i think we are on track, but just wanted to put it out there
17:33:22 <SumitNaiksatam> #topic Action item review
17:33:31 <regXboi> we are tracking to -2 right?
17:33:42 <SumitNaiksatam> regXboi: yes absolutely
17:33:46 <SumitNaiksatam> -2 and -3
17:33:51 <regXboi> thx
17:34:21 <s3wong> regXboi: service insertion seems to be J-3
17:34:26 <SumitNaiksatam> all of us had the homework assignment to vote up or down on the prioritized features: #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan
17:34:53 <SumitNaiksatam> s3wong: it needs to land much sooner to be reviewed in time for J-3
17:35:01 <s3wong> SumitNaiksatam: absolutely
17:35:22 <SumitNaiksatam> thanks to all who reviewed
17:36:02 <SumitNaiksatam> any general comment that anyone wants to make regarding the reviews (before we get into the specifics)?
17:36:05 <s3wong> SumitNaiksatam: flavor just uploaded a new spec, thus negating all our hard-earned +/- 1s
17:36:13 <SumitNaiksatam> s3wong: ha
17:36:26 <SumitNaiksatam> s3wong: please give enikanorov credit he is working hard
17:36:30 <enikanorov> i'll give an update shortly
17:37:05 <SumitNaiksatam> the other AI from last meeting was by enikanorov to himself to put some specific updates in the spec, and i believe he has done that
17:37:11 <SumitNaiksatam> so with that lets dive in
17:37:11 <s3wong> flavor is targeted for the LBaaS mid-cycle, so everyone suddenly commented on flavor framework :-)
17:37:26 <SumitNaiksatam> #topic Flavors
17:37:38 <SumitNaiksatam> #link https://review.openstack.org/#/c/90070
17:37:41 <enikanorov> yes, we all love those people jumping in to the last cab of the train :)
17:37:56 <SumitNaiksatam> enikanorov: go ahead with your update
17:38:02 <enikanorov> so, there was several major updates
17:38:05 <SumitNaiksatam> enikanorov: i noticed you just uploaded another patch
17:38:21 <enikanorov> yes, so let me describe updates from the last week's version
17:38:29 <enikanorov> 1. REST API
17:38:40 <enikanorov> tags have their separate resource
17:39:03 <enikanorov> that might be harder to use from CLI perspective, but will allow some flexibility later
17:39:13 <enikanorov> such as updating tags
17:39:39 <enikanorov> also it allowed to add attitional attribute to a tag within a flavor: visibility
17:39:57 <enikanorov> so admin can create tag invisible to a user
17:40:33 <enikanorov> this way admin can create mapping between flavors and drivers that support same set of capabilities
17:40:50 <enikanorov> so, for example "VendorName" tag may be invisible withing the flavor
17:41:21 <enikanorov> so Gold and Silver flavors will show exactly same capabilities to a user, but internally they map to different providers
17:41:37 <enikanorov> how do you like the idea?
17:41:40 <garyduan> enikanorov: how the admin created flavor bind to a vendor driver?
17:42:06 <enikanorov> the idea is that driver may extend its capabilities from configuration
17:42:23 <enikanorov> and that can be usd to create such artifical mapping
17:43:14 <enikanorov> more questions on this idea?
17:43:29 <s3wong> enikanorov: do tenants get to query the list of capabilities from a Flavor?
17:44:03 <enikanorov> they may do 'list-flavors' and 'show-flavor', latter will give everything that is visible
17:44:10 <enikanorov> all flavor tags and their values
17:44:12 <garyduan> enikanorov: I understand that we have discussed this many times, but I have a question
17:44:20 <enikanorov> garyduan: shoot
17:44:26 <cathy_> Are the additional attributes used for helping selecting the driver in the case that multiple drivers support the user's flavor request?
17:44:27 <garyduan> enikanorov: In real world, would the operator create flavors purely based on capabilities that vendors expose
17:45:05 <LouisF> enikanorov: can a tenant create a flavor?
17:45:06 <enikanorov> garyduan: hmm, i don't know. I'd like to give ability that will suit different needs.
17:45:10 <enikanorov> LouisF: no
17:45:20 <garyduan> enikanorov: or, what vendors expose are just informational for the admin
17:45:30 <enikanorov> cathy_: that might be. that's up to admin
17:45:52 <enikanorov> garyduan: right, what vendors expose is for admin
17:45:53 <garyduan> enikanorov: admin creates flavor directly mapped to the vendor, but doesn't have to expose the vendor name
17:46:13 <enikanorov> garyduan: yes, it is possible to do so, if it is needed.
17:46:25 <s3wong> enikanorov: garyduan: the reason I asked the above question is, if there are tags that aren't visible to user (or even if it is visible), vendor can add vendor-tag, and operator can simply map vendor tag to a Flavor
17:46:42 <pcm_> enikanorov: As expressed in spec, I'm wondering how we handle large number of capabilities, like VPN has.
17:46:45 <enikanorov> s3wong: yes, that's the example i've given
17:46:45 <s3wong> garyduan: thus giving an elegant way for direct mapping of a Flavor to a vendor
17:46:53 <garyduan> enikanorov: I know this is a subset of current proposal
17:47:21 <enikanorov> pcm_: we need to think about it. that might be some 'tag suggestion' from the driver...
17:47:26 <garyduan> what I am not clear is the still the binding part
17:47:32 <enikanorov> i'd put it out from initial implementation
17:47:59 <enikanorov> garyduan: binding is flavor_id in the resource + as in provider framework
17:48:19 <LouisF> enikanorov: can we rename tag to capability?
17:48:25 <cathy_> Thanks for your reply. I am not sure what is meant by "up to Admin". I was thinking the Flavor framework internal algorithm will automatically select the best driver based on some configured priority criteria in the case that multiple drivers satisfy the user's flavor request. Could you clarify
17:48:33 <garyduan> I mean the tag created by the admin, how to bind it to a driver
17:48:42 <cathy_> how the "Admin" selection works?
17:48:55 <SumitNaiksatam> ok lets have a little more order to the conversation
17:49:00 <SumitNaiksatam> i think enikanorov is getting slammed here
17:49:05 <s3wong> LouisF: why? wouldn't "tag" be better if we want to use tag for more than just driver capability in the future?
17:49:16 * pcm_ SumitNaiksatam +1
17:49:23 <SumitNaiksatam> so let me first ask, the questions that are being asked here, have they been added to the review?
17:49:32 <enikanorov> LouisF: hmm, i know that may create confusion. i think tag is what admin or user work with, and capability is what driver/backend supports
17:49:41 <SumitNaiksatam> enikanorov: one sec
17:49:48 <enikanorov> these are the same notion in different 'places'
17:50:05 <SumitNaiksatam> asking again, have the questions being asked here posted in the review
17:50:22 <SumitNaiksatam> i can understand that some of the changes came in late, so people probably have not had a chance to review those
17:50:23 <s3wong> SumitNaiksatam: enikanorov: the only comment I have was that instead of adding flavor_id attribute to each service instance, it is already in the ServiceBase, so no need to do that
17:50:44 <garyduan> For my question, not yet.
17:50:56 <SumitNaiksatam> garyduan: cathy_ LouisF pcm_: your questions?
17:50:57 <enikanorov> s3wong: i'm not sure, but i think it still needed in the service instance resource
17:51:01 <SumitNaiksatam> garyduan: ok
17:51:06 <enikanorov> unless you're redefining whole extension framework
17:51:08 <LouisF> wil post
17:51:13 <pcm_> SumitNaiksatam: mine was voiced in the review.
17:51:16 <s3wong> enikanorov: SumitNaiksatam: however, I do understand flavor is going to land before service insertion, so perhaps you want it for initial implementation
17:51:36 <enikanorov> SumitNaiksatam: I've also added the section about how to organize tags
17:51:39 <cathy_> not quite.
17:51:44 <SumitNaiksatam> pcm_: ok, in that case enikanorov do you think you have answered all the previous questions?
17:51:51 <enikanorov> will copy it here as well: http://paste.openstack.org/show/84407/
17:51:55 <cathy_> will post
17:52:01 <SumitNaiksatam> just want to make sure that some of the questions are not lost when new patch sets are posted
17:52:15 <SumitNaiksatam> otherwise we end up discussing the same thing and are not making progress here
17:52:27 <SumitNaiksatam> i really wanted that we would get closure on the spec today
17:52:28 <garyduan> I will post to the spec review.
17:52:42 <SumitNaiksatam> however, it seems that people have more questions at this stage
17:52:42 <enikanorov> SumitNaiksatam: +10^10^10
17:53:14 <SumitNaiksatam> enikanorov: we are all trying our best and understand the frustration an your end too
17:53:17 <enikanorov> *more people have more questions :)
17:53:18 <SumitNaiksatam> is Stephen Balukoff	here?
17:53:26 <SumitNaiksatam> i dont know his IRC handle
17:53:26 <enikanorov> 1 sec
17:53:30 <SumitNaiksatam> enikanorov: do you?
17:53:44 <s3wong> SumitNaiksatam: he is in #openstack-lbaas
17:53:51 <enikanorov> yes, i've invited him
17:53:59 <SumitNaiksatam> enikanorov: thats great
17:54:02 <enikanorov> hehe
17:54:30 <SumitNaiksatam> he seemed to be representing the operator view, and i think we should definitely factor that opinion
17:54:32 <s3wong> SumitNaiksatam: sbalukoff
17:54:42 <SumitNaiksatam> we also need to be pragmatic
17:54:56 <s3wong> SumitNaiksatam: I also asked him to join at #openstack-lbaas
17:55:04 <SumitNaiksatam> in terms of what making a start here, versus trying to land everything and not getting anything
17:55:07 <pgpus> I believe no two service will have same capability ever, so simple baseclass with tag extesions for back end capability i s good enough for first cut, the only question is who dwfines tags admin  or service tenenant and that can be sorted out
17:55:08 <SumitNaiksatam> s3wong: thanks
17:55:24 <SumitNaiksatam> pgpus: ok
17:55:28 <sbalukoff> Hi folks!
17:55:34 <s3wong> SumitNaiksatam: there he is. Welcome sbalukoff!!!
17:55:43 <SumitNaiksatam> i also had a suggestion that the tags can be namespaced, so that we can avoid ambiguity and overlaps
17:55:43 <enikanorov> pgpus: no classes for tags for science sake!
17:55:52 <s3wong> SumitNaiksatam: you have question for sbalukoff?
17:55:54 <SumitNaiksatam> sbalukoff: welcome
17:56:08 <enikanorov> SumitNaiksatam: see the pseudocode example. does it answers your concerns?
17:56:20 <SumitNaiksatam> sbalukoff: we are tracking the flavors spec
17:56:27 <sbalukoff> Excellent!
17:56:33 <SumitNaiksatam> enikanorov: my apologies i did not get a chance to read the latest version
17:56:36 <sbalukoff> I'm very opinionated. Sorry!
17:56:41 <enikanorov> SumitNaiksatam:  http://paste.openstack.org/show/84407/
17:56:44 <SumitNaiksatam> sbalukoff: we noticed that you had some comments
17:56:51 <sbalukoff> Indeed. :)
17:56:56 <SumitNaiksatam> and we want to make sure that those are heard/addressed
17:56:58 <enikanorov> that's specifically for the tags organization
17:57:05 <SumitNaiksatam> enikanorov: ok
17:57:11 <sbalukoff> We are here at the neutron-lbaas hackathon in Texas and were about to discuss Flavors as well.
17:57:42 <SumitNaiksatam> sbalukoff: we discuss this on a weekly basis, and enikanorov has been diliegently on this spec for a few months now
17:57:43 <sbalukoff> What time does this meeting end? Are we going to be OK on time?
17:57:57 <SumitNaiksatam> we really need to make progress with at least getting the first iteration in
17:58:08 <sbalukoff> Aah. Ok.
17:58:18 <SumitNaiksatam> sbalukoff: are your concerns addressed in the lates patch set posted by enikanorov?
17:58:19 <s3wong> sbalukoff: it ends at 1:30pm central time
17:58:23 <sbalukoff> Well, let's make sure we aren't going to be shooting ourselves in the foot. :)
17:58:35 <SumitNaiksatam> sbalukoff: most definitely
17:58:39 <s3wong> i.e., in 30 minutes
17:58:51 <sbalukoff> SumitNaiksatam: Actually, my concerns are not addressed by that. I just got done responding to the BP. XD
17:59:00 <enikanorov> sbalukoff: regarding the matching. WHole purpose of the framework was to get rid of 1:1 matching and make it flaxible
17:59:03 <SumitNaiksatam> sbalukoff: ah ok
17:59:06 <enikanorov> and depentend on capabilities
17:59:11 <Kanzhe> enykeev: I posted a suggestion in the review to separate capability into two, user-facing capabilities, driver capabilities. Provider can manage the mapping between the two.
17:59:33 <sbalukoff> enikanorov: I think I'm starting to understand that, but then how do you propose to provide a way for vendors to expose unique advanced features?
17:59:36 <Kanzhe> s/enykeev/enikavorov
17:59:53 <enikanorov> sbalukoff: just like non-unique ones
18:00:21 <enikanorov> sbalukoff: it's actually up to the admin to expose this to user
18:00:24 <sbalukoff> Ok, I get that non-unique ones. Tags make a lot of sense for that.
18:00:25 <SumitNaiksatam> so we are 30 mins into the meeting discussing this one topic
18:00:45 <sbalukoff> Could vendors, say, provide unique tags that apply to features they only can provide?
18:00:46 <SumitNaiksatam> should we call a separate one off meeting to address any residual concerns?
18:00:58 <SumitNaiksatam> enikanorov: what do you think?
18:01:12 <enikanorov> sbalukoff: absolutely. they can
18:01:12 <s3wong> SumitNaiksatam: enikanorov: I am attending the LBaaS mid-cycle as well. If there is any strong objection to flavor or new ideas, I will let you guys know
18:01:18 <sbalukoff> enikanorov: I agree that the admin/operator needs to have final say in what is exposed to the user.
18:01:36 <sbalukoff> But Vendors need to have a way to expose their functionality to admins/operators so that they can decide whether to expose this to users.
18:01:43 <enikanorov> SumitNaiksatam: please +2 minutes :)
18:01:56 <enikanorov> sbalukoff: and they can do that
18:02:01 <SumitNaiksatam> folks i am happy to spend to the whole hour on this topic if we have a gaurantee to have consensus at the end of the hour :-P
18:02:17 <sbalukoff> enikanorov: That's great then! Could you update your BP with an example as to how this is done?
18:02:35 <LouisF> +1
18:02:47 <enikanorov> sbalukoff: yes. it actually  has a pseudocode example of that, i;ll update that example wth vendor-specific tags
18:02:50 <s3wong> SumitNaiksatam: unlikely as the LBaaS folks and markmcclain will be talking about flavor later in the day
18:02:54 <sbalukoff> SumitNaiksatam: I can only guarantee that I will argue honestly and without the intent to obstruct. I'd like to see us get this defined and done, too!
18:02:54 <enikanorov> (or 'capabilities')
18:03:29 <SumitNaiksatam> s3wong: i dont understand why there need to be different sets of discussion
18:03:37 <sbalukoff> enikanorov: As long as the vendor interface isn't terrible, then I think I'm OK with flavors as you have described it in the BP.
18:03:44 <SumitNaiksatam> s3wong: i would have expected markmcclain and the rest of the lbaas team to have participated here
18:03:54 <enikanorov> sbalukoff: great to hear!
18:03:57 <s3wong> SumitNaiksatam: more of a face to face thing, and markmcclain is in a separate meeting at the moment
18:04:00 <pcm_> would it make sense to identify a few cases/scenarios, and show examples in the spec to aide in understanding?
18:04:00 <sbalukoff> SumitNaiksatam: We can ask them to join if you'd like.
18:04:08 <sbalukoff> They're sitting across the room from me.
18:04:28 <enikanorov> ok, lets discuss flavors after he meeting
18:04:32 <enikanorov> *the
18:04:33 <sbalukoff> pcm_: Yes, it would.
18:04:53 <SumitNaiksatam> enikanorov sbalukoff: so it seems that we have some high level consensus
18:04:53 <pcm_> sbalukoff: seems like we have a few, and that may help answer questions.
18:04:55 <s3wong> enikanorov: sure. hopefully you will still be awake on the #openstack-lbaas channel by then :-)
18:05:15 <SumitNaiksatam> enikanorov: so you will be putting a new patch set?
18:05:18 <sbalukoff> We've been doing a lot of hand-waving in other discussions, shuffling off difficult configuration or edge cases to this magical "flavors" framework. So knowing that it can actually deliver most of the features we want is a good idea!
18:05:35 <enikanorov> SumitNaiksatam: yes, with a bit more details
18:05:42 <SumitNaiksatam> enikanorov: sweet
18:05:55 <pcm_> enikanorov: great work btw.
18:06:00 <SumitNaiksatam> so lets set some milestones for this
18:06:03 <enikanorov> thanks, folks
18:06:12 <SumitNaiksatam> flavor framework is targeted for J-2
18:06:18 <SumitNaiksatam> and we dont have the spec approved yet
18:06:38 <SumitNaiksatam> i am not saying that we need to approve the spec because we have set the milestone
18:06:57 <SumitNaiksatam> but we should try if we can to meet the milestones
18:06:58 <sbalukoff> So again, the asshole in me must point out that you have "tentative" agreement from me. :)  So please be descriptive in your examples, enikanorov! :D
18:07:38 <enikanorov> hope to get +1 from your better part, sbalukoff! :)
18:08:13 <pcm_> SumitNaiksatam: Could we summarize the cases/scenarios here, so enikanorov has info on what to add to the spec as examples?
18:08:14 <garyduan> enikanorov: I posted my question to the review.
18:08:37 <enikanorov> pcm_: let's put it offline, i think meeting needs to go further
18:08:58 <pcm_> k
18:09:01 <SridarK> enikanorov: we should target the basic framework and keep bells and whistles for later patches
18:09:01 <SumitNaiksatam> enikanorov: i dont mind using up another 5 mins
18:09:33 <SumitNaiksatam> enikanorov: can you quickly summarize at a high level what you will be addressing?
18:10:07 <enikanorov> SumitNaiksatam: first of all it is API, DB, common module having a data structures for tag names and possible values, so developers could extend them
18:10:08 <s3wong> more lbaas folks joining :-)
18:10:10 <pgpus> service has both producer and consumer and a venor or supplier who define the capabilities, thus as long all three get their basisc minum framework we are ok
18:10:28 <enikanorov> so actually things like matching/selection is left for integration phase
18:10:37 <pgpus> So flavor needs to cater to all three views
18:10:40 <enikanorov> as well as extending drivers with additional capabilities
18:11:02 <enikanorov> although i think to include dummy plugin with drivers into the unit tests as an example
18:12:12 <pgpus> OK is abuilder of this we support moduler drivers and or filetrs to provie the base capability in Flavor and extend them through tags
18:13:06 <pgpus> So let you folks work backchannel with Sumit, shall we move to next topic?
18:13:10 <SumitNaiksatam> enikanorov: anything more?
18:13:16 <enikanorov> SumitNaiksatam: nope
18:13:23 <enikanorov> thanks for the additional time!
18:13:48 <SumitNaiksatam> so the rest of the team feels comfortable with these items being addressed? (a +1 will help here)
18:13:57 <pgpus> sure
18:14:28 <SumitNaiksatam> ok, no objections at least
18:14:37 <SumitNaiksatam> enikanorov: thanks much on this
18:14:52 <SumitNaiksatam> enikanorov: perhaps we can also schedule an irc meeting while the lbaas folks are meeting f2f
18:14:57 <SumitNaiksatam> perhaps tomorrow?
18:15:06 <enikanorov> i would not mind.
18:15:10 <SumitNaiksatam> s3wong sbalukoff: what do you guys think?
18:15:19 <s3wong> SumitNaiksatam: sure, we will still be in this meeting tomorrow
18:15:22 <banix> enikanorov: are you at the f2f?
18:15:25 <SumitNaiksatam> you can channelize your feedback from your discussion today
18:15:28 <enikanorov> banix: no
18:15:28 <pcm_> +1
18:15:37 <s3wong> banix: no enikanorov isn't (the meeting is in Texas)
18:15:55 <SumitNaiksatam> enikanorov: so lets set a time for tomorrow, and send it out to the -dev mailer
18:15:56 <banix> yes lets move this forward
18:16:02 <SumitNaiksatam> mestery: ^^^
18:16:16 <enikanorov> SumitNaiksatam: we may do it at lbaas meeting may be?
18:16:17 <sbalukoff> No objections from me just yet.
18:16:21 <s3wong> SumitNaiksatam: he just stepped out of the room (and away from his computer) for the moment
18:16:23 <SumitNaiksatam> mestery: proposing an IRC for flavors discussion tomorrow with you guys
18:16:28 <SumitNaiksatam> s3wong: ok
18:16:30 <enikanorov> sbalukoff: s3wong what do you think?
18:16:37 <SumitNaiksatam> enikanorov: sure
18:16:40 <SumitNaiksatam> enikanorov: your call
18:16:41 <banix> s3wong: what are you doing there ;)
18:16:49 <s3wong> enikanorov: sure
18:16:54 <banix> s3wong: just kidding
18:16:57 <s3wong> banix: that would have been my next update :-)
18:16:59 <SumitNaiksatam> thanks all for the participation and patience on this
18:17:03 <enikanorov> i'm for keeping flavor discussion at lbaas meeting, 14-00 utc Thursday
18:17:08 <s3wong> banix: but enikanorov took all the time :P
18:17:14 <SumitNaiksatam> since we have used up majority of the meeting
18:17:45 <SumitNaiksatam> and are not going to be able to cover all the items, let me check what is it that you would like to be discussed in the remaining time?
18:17:50 <banix> and we needed 55 minutes for the steering :)
18:17:58 <s3wong> banix: probably more
18:17:59 <SumitNaiksatam> should we bring up the service insertion discussion next?
18:18:04 <banix> can we finalize the steering proposal?
18:18:04 <SumitNaiksatam> banix: :-)
18:18:12 <s3wong> banix: I haven't even fully read all the options proposed by cgoncalves yet
18:18:13 <cgoncalves> banix: the steering drama :-)
18:18:21 <pgpus> yes is carlos there/
18:18:27 <cgoncalves> pgpus: guilty!
18:18:28 <SumitNaiksatam> banix: sure
18:18:28 <banix> cgoncalves: it’s all good :)
18:18:41 <SumitNaiksatam> #topic Traffic steering
18:18:47 <SumitNaiksatam> #link https://review.openstack.org/#/c/92477
18:19:36 <SumitNaiksatam> banix: go ahead
18:19:37 <cgoncalves> sorry, let me ask this: is Prakash here? I don't know his nick
18:19:55 <banix> cgoncalves: pls go ahead
18:19:55 <SumitNaiksatam> pgpus: ^^^
18:20:02 <s3wong> SumitNaiksatam: pgpus?
18:20:14 <s3wong> cgoncalves: pgpus?
18:20:26 <cgoncalves> I sent a couple of hours ago an email to (hopefully) all of you
18:20:29 <pgpus> Yes my thinking was for the option D with forwarding graph we need to add actions
18:20:41 <cgoncalves> pgpus: ah, that's you :-)
18:21:01 <cgoncalves> in case someone hasn't received the email let me know so that I can also forward to you
18:21:05 <SumitNaiksatam> banix: you are in favor of option D as well?
18:21:18 <cgoncalves> #link https://docs.google.com/document/d/10Z7DjLTTDRDoh8VbLuLL8LtIU0Vw6a5jr_arYPD_Fpc
18:21:24 <pgpus> seperate out default action and others like reverse, mirror, proxy, redirect what ever that akes sense for use cases
18:21:35 <banix> I was thinking something simpler would work
18:21:52 <s3wong> SumitNaiksatam: banix: sounds like banix is still in flavor of option A (in his email reply)?
18:21:56 <SumitNaiksatam> banix: ok
18:22:08 * regXboi wakes up
18:22:08 <SumitNaiksatam> banix: my bad, misread your email
18:22:08 <banix> Essentially saying option A where ports is a reference to a graph would work fine and
18:22:17 <SumitNaiksatam> regXboi: yes, you have a -1 too
18:22:20 <cgoncalves> personally I'm in favor of option D (note that pgpus has overwritten some parts though), but also option C as the simpliest case to implement now
18:22:25 <banix> probably we can put a restriction right now for the graph if that helps
18:22:39 <cgoncalves> banix: option C would be the linear chain you were referring to
18:22:43 <pgpus> The simpler ones a and b or c will be too constrained to allow different service graphs
18:22:43 <banix> i may have missed the points for adding 1-to-many and others
18:23:29 <banix> pgpus: saying we use a generic representation of a graph; so this will be very general
18:23:40 <regXboi> unfortunately, I'm not going to have a chance to review this until this evening :(
18:23:48 <cathy_> I have a concern on the steering API. It provides a API for specifying the service chain. GBP also provides an API for specifying the service chain. Should we have two sets of API for this? Wouldn't this cause confusion to Admin or user? Or has this been sorted out in the latest update?
18:23:58 <SumitNaiksatam> cathy_: yes, you have a -1 too
18:24:07 <banix> regXboi: reviews done at night are the best reviews
18:24:09 <pgpus> That one too many for linkis  in chain (port1,Port2) with actions to apply on them and can be split into (prot1,port2)-action plus port(1,Port3) Action types normalizuing bintables
18:24:14 <cgoncalves> banix: the 1-to-many/many-to-1 could be ignore for now. the default would be 1-to-many as are all other options
18:24:18 <SumitNaiksatam> cathy_: GP does not provide for service chain
18:24:27 <SumitNaiksatam> cathy_: GP uses service chain
18:24:52 <cgoncalves> SumitNaiksatam: exactly
18:24:56 <cathy_> Yes, it uses service chain. But there are some overlapping on service chain specification
18:25:06 <s3wong> cathy_: SumitNaiksatam: yes, GBP could be an implementation of service chain
18:25:21 <SumitNaiksatam> cathy_: correct that is a different spec, and which can potentially use the traffic steering capability
18:25:39 <banix> couldn’t we use the list of lists where each list is a source and one or more destination in a directed graph? wouldn’t that be the most general?
18:25:45 <cgoncalves> pgpus: I still have to go through your suggestions. you introduced even more ideas so... :)
18:25:49 <SumitNaiksatam> cathy_: i believe you are referring to: #link https://review.openstack.org/#/c/93524
18:25:52 <cathy_> I Yes, my understanding is same as s3wong
18:26:03 <s3wong> cathy_: SumitNaiksatam: cgoncalves: but I do want to say that GBP is unlikely going to use traffic steering
18:26:31 <SumitNaiksatam> s3wong: i would not quite say that GP is an implementation of a service chain
18:26:39 <SumitNaiksatam> s3wong:  it uses service chain
18:26:54 <SumitNaiksatam> ok back to the topic of this steering blueprint
18:26:56 <s3wong> SumitNaiksatam: it could be an implementation of the Service Chain framework/APIs
18:27:04 <pgpus> ok i will let cgoncalves absorb and then update the specs
18:27:05 <banix> SumitNaiksatam: +1 s3wong: not quite
18:27:05 <regXboi> so... I'm still worried about this case
18:27:09 <cgoncalves> s3wong: I'd not be against not using traffic steering. I think although both works could have some relation, it is not explicit
18:27:16 <regXboi> [[p1, p2, p3], [p2, p4], [p3, p4]]
18:27:25 <SumitNaiksatam> s3wong: again not quite
18:27:29 <SumitNaiksatam> banix: yeah
18:27:37 <s3wong> banix: it uses service chains on 'redirect'
18:27:49 <SumitNaiksatam> cgoncalves: are you planning another update?
18:27:54 <SumitNaiksatam> to the spec?
18:28:02 <cathy_> "redirect chain-ID" to specify a service chain
18:28:04 <pgpus> we call it steering but its conceptually similar, function is more important than name I would say
18:28:08 <s3wong> banix: but if we wrap services into a EPG, then the provider-consumer relationship effectively gives us a service chain
18:28:08 <SumitNaiksatam> i guess you need to know from us as to which option to go with
18:28:18 <cgoncalves> SumitNaiksatam: not until we get a consensus on what would be the new approach
18:28:25 <SumitNaiksatam> cgoncalves: ok
18:28:41 <cgoncalves> SumitNaiksatam: that was why I created that doc to present our views and get yours too
18:28:43 <SumitNaiksatam> #action for all, please respond to cgoncalves thread by end of tomorrow
18:28:52 <s3wong> SumitNaiksatam: sure
18:28:55 <cathy_> then there is a need for definition of the "chain" which I think the "traffic steering" API can provide. I have given a suggestion on how to provide that in my comment
18:28:57 <regXboi> cgoncalves: I'm still stuck on the above case, and none of these options appear to nicely cover it
18:28:59 <LouisF> cgoncalves: there was discussion on a unfied classifier that incorperates the GBP classifier and the TS classifier?
18:29:02 <banix> s3wong: we’ll talk more
18:29:16 <SumitNaiksatam> #action cgoncalves to post a new patch set for review by friday (once he gets enough responses), will close the option choice on emails
18:29:24 <cgoncalves> LouisF: not yet. we could discuss that later?
18:29:32 <LouisF> k
18:29:37 <SumitNaiksatam> regXboi: you wanted to make a pointe earlier?
18:29:42 <s3wong> banix: sure :-) GBP as chain won't happen in Juno anyway :-)
18:29:50 <cgoncalves> regXboi: sorry, what's your concerns on [[p1, p2, p3], [p2, p4], [p3, p4]]
18:30:07 <regXboi> cgoncalves: how to avoid two copies of the packet at p1 appearing at p4
18:31:00 <cgoncalves> regXboi: packets at p4 could differ
18:31:03 <pgpus> well that is loop avoidance in graph and we can consider that options later
18:31:08 <cgoncalves> regXboi: but can also be the same, yes
18:31:22 <banix> regXboi: that’s up to the function in p2 and p3 i wpould think
18:31:34 <SumitNaiksatam> regXboi: any chance that you can put this comment on the spec?
18:31:37 <regXboi> banix: that I am uncomfortable with
18:31:43 <regXboi> SumitNaiksatam: already there
18:31:51 <SumitNaiksatam> regXboi: ah good, sorry i did not notice
18:31:54 <cgoncalves> regXboi: I'm afraid I don't know how to answer that question precisely as of now
18:31:58 <regXboi> worse, in the case of multi-armed things, the graph won't help
18:32:10 <regXboi> which is also on the comment chain
18:32:10 <cgoncalves> banix: that too, or to the admin to configure it properly
18:32:35 <SumitNaiksatam> cgoncalves: you can probably take this offline with regXboi
18:32:38 <cgoncalves> "it's always user's fault!" :)
18:32:44 <cgoncalves> SumitNaiksatam: sure
18:32:44 <SumitNaiksatam> sorry folks we are over time
18:32:45 <banix> so traffic steering says traffic coming out of p2 with specified classifier needs to be forwarded to p4....
18:32:53 <banix> s3wong: Going to the vicotry parade for Spurs?
18:33:04 <s3wong> banix: I think it is happening right now
18:33:11 <s3wong> banix: in downtown
18:33:14 <SumitNaiksatam> again my apologies to all others whose agenda item did not come up for discussion
18:33:14 <cgoncalves> banix: yes
18:33:19 <vinay_yadhav> 2 mins for taas :)
18:33:20 <s3wong> banix: but I am stuck in Rackspace office :-)
18:33:20 <pgpus> Any way actions like forwarding, reversing, mirroring, redirecting can have constraints to the actions to get over this
18:33:37 <SumitNaiksatam> vinay_yadhav: i am afraid the fwaas folks are not going to like it
18:33:45 <vinay_yadhav> cool :)
18:33:48 <s3wong> vinay_yadhav: do you have something you want to update?
18:33:54 <cgoncalves> SumitNaiksatam: we probably should extend adv service meetings time or break it into multi meetings, no?
18:34:00 <SumitNaiksatam> lets go -dev for the pending discussions
18:34:11 <vinay_yadhav> the review comments from marios will be answered
18:34:12 <SumitNaiksatam> cgoncalves: this was discussed before
18:34:18 <SumitNaiksatam> cgoncalves: lets bring it up next time
18:34:31 <cgoncalves> pgpus: I will get a better looking at your proposal and discuss it with you. thanks
18:34:36 <SumitNaiksatam> #action discuss meeting length options in next meeting
18:34:36 <cgoncalves> SumitNaiksatam: sure
18:34:36 <banix> -dev means mailing list?
18:34:43 <SumitNaiksatam> banix: yeah
18:34:48 <banix> sounds good
18:34:53 <SumitNaiksatam> alright thanks all for joining
18:35:00 <SumitNaiksatam> please please review the specs
18:35:06 <SumitNaiksatam> #endmeeting