17:31:58 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:31:59 <openstack> Meeting started Wed Jun 25 17:31:58 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:32:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:32:02 <openstack> The meeting name has been set to 'networking_advanced_services'
17:32:10 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices
17:32:21 <SumitNaiksatam> #topic Action Item followup
17:33:15 <SumitNaiksatam> cgoncalves: you had taken an AI to post a new patch, pending response to your email thread
17:33:25 <SumitNaiksatam> cgoncalves: i guess we can discuss that in your section of the update
17:33:33 <cgoncalves> SumitNaiksatam: that's right
17:33:36 <cgoncalves> ok
17:34:10 <s3wong> cgoncalves: don't be too optimistic, flavor discussion will once again take up 70% of meeting time :-)
17:34:20 <SumitNaiksatam> there was a suggestion last time that we increase the length of this meeting, or figure out how we can give more time to discuss the items which are not able to cover
17:34:29 <enikanorov> i hope we'll manage to fit in 30 mins
17:34:43 <cgoncalves> s3wong: neither you as steering will take 30% :)
17:34:50 <SumitNaiksatam> we have discussed an option to have a longer meeting before, but that was not favorable to some
17:35:05 <SumitNaiksatam> i dont think its feasible to have to meetings in a week, its just too much overhead
17:35:12 <SumitNaiksatam> in terms of getting people together
17:35:14 <s3wong> enikanorov: 50% is certainly an improvement :-)
17:35:26 <enikanorov> s3wong: it's 1/3 i think :)
17:35:51 <SumitNaiksatam> anyone have any thoughts on the meeting lenght logistics?
17:36:19 <mandeep> SumitNaiksatam: It will only get shorter as spend time discussing how much time we have ;-)
17:36:20 <SumitNaiksatam> or we can postpone this discussion to the end of the meeting (assuming we get time for it :-) )
17:36:28 <enikanorov> SumitNaiksatam: could it be that once we're done with discussin glavors it would not require that much time?
17:36:37 <marios_> SumitNaiksatam: i dont attend often as i should but an hour is hard enough to fit in already with everything else... imo
17:36:38 <SumitNaiksatam> mandeep: :-)
17:36:48 <SumitNaiksatam> enikanorov: that is certainly an possibility :-)
17:36:54 <marios_> enikanorov: +1
17:36:57 <SumitNaiksatam> marios_: very true
17:37:08 <marios_> seems we have a specific issue here
17:37:15 <banix> enikanorov: we will discuss flavors for eternity
17:37:24 <SumitNaiksatam> in general we wanted this to be a status meeting, and not a full blown design discussion (which should be had out of band)
17:37:30 <enikanorov> banix: i hope not. markmcclain is here
17:37:32 <cgoncalves> SumitNaiksatam: chaining and steering (and GBP) are quite related and probably worth arranging an extra meeting with the folks involved
17:37:42 <enikanorov> markmcclain: hi
17:37:59 <SumitNaiksatam> but we do try to accomodate some of the design discussion so that we can get a quick resolution while everyone is here
17:38:19 <cgoncalves> SumitNaiksatam: such meetings should be sporadic until we get to a consensus
17:38:20 <SumitNaiksatam> okay, lets table the meeting logistics for now
17:38:26 <SumitNaiksatam> cgoncalves: true
17:38:39 <SumitNaiksatam> #topic Flavors
17:38:42 <enikanorov> ok
17:38:50 <pcm_> Has mark published his proposal for flavors?
17:39:00 <SumitNaiksatam> mestery: there?
17:39:00 <enikanorov> so let me briefly tell you what concerns some folks had on the review
17:39:07 * markmcclain is currently sitting in another meeting
17:39:15 <marios_> enikanorov: did you get any feedback on yr concerns with marks proposal?
17:39:17 <SumitNaiksatam> enikanorov: sure
17:39:18 <mestery> I believe markmcclain is about to publish that now, I've spoken to him recently, hopefully in the next 30 minutes. :)
17:39:24 <enikanorov> markmcclain: i'll try to do a ork for you explaining your proposal :)
17:39:28 <mestery> enikanorov: Please go ahead.
17:39:35 <s3wong> pcm_: I have not seen it, though I was there in person when markmcclain presented his idea in San Antonio last week
17:39:43 <enikanorov> yep, so Mark's proposal in short:
17:40:12 <enikanorov> we introduce a notion of 'driver profile' which is a bunch of configuration of one driver for particular use case
17:40:30 <enikanorov> for instance, non-HA, HA. or l2 insertion, L3 insertion
17:40:44 <enikanorov> then, the flavor is associated with several such profiles
17:40:46 <banix> enikanorov: one profile for each of those?
17:40:51 <enikanorov> no tags, no capabilities
17:41:03 <enikanorov> banix: possibly multiple profiles for the same driver
17:41:19 <SumitNaiksatam> enikanorov: this is kind of vague
17:41:25 <enikanorov> so from user perspective user only sees flavor and it's description
17:41:35 <marios_> enikanorov: so admin creates profile that matches exactly some requirement?
17:41:37 <enikanorov> on the background it is associated with the type of implementation
17:41:45 <banix> operator associates flavors with profiles
17:41:47 <banix> ?
17:41:51 <enikanorov> banix: right
17:41:56 <enikanorov> marios_: yes, i guess so
17:41:59 <enikanorov> so my point is
17:42:14 <marios_> enikanorov: is there ANY comm9n ground or work towards it or does it come down to choosing an approach
17:42:16 <enikanorov> that exactly this usage is supported by the framework I was proposing
17:42:30 <SumitNaiksatam> enikanorov: so on what basis does the user choose?
17:42:37 <marios_> enikanorov: if the latter i suggest interested parties do their research and schedule an hour
17:42:41 <enikanorov> SumitNaiksatam: i guess it is description then
17:42:46 <SumitNaiksatam> enikanorov: the description seems like a very subjective metric
17:42:55 <enikanorov> SumitNaiksatam: i agree
17:43:06 <SumitNaiksatam> enikanorov: this is not how nova flavors are structured
17:43:08 <markmcclain> enikanorov's description is not accurate
17:43:11 <enikanorov> it doesn't solve the problem of feature discovery and doesn't give guarantees
17:43:17 <SumitNaiksatam> enikanorov: just to take an existing example
17:43:19 <enikanorov> markmcclain: ok, sorry
17:43:26 <enikanorov> that's how i understood it
17:43:41 <enikanorov> markmcclain: please correct me
17:44:29 <markmcclain> so flavors are curated by operators
17:44:52 <pcm_> why now get the proposal published and we can read and then have a meeting to discuss all the proposals?
17:44:54 <markmcclain> flavors contain the list of extensions to enable for a service (ie TLS, L7)
17:45:36 <enikanorov> that's not very clear
17:45:40 <markmcclain> pcm_: trying to get it finalized… 10hrs of driving last 48hrs
17:45:48 <enikanorov> are you talking about API extensions?
17:46:06 <pcm_> markmcclain: understood. Just thinking of the best use of everyones time.
17:46:07 <SumitNaiksatam> enikanorov: i agree, thats not very clear to me either
17:46:24 <markmcclain> so wait for the spec to be published
17:46:38 <SumitNaiksatam> markmcclain: do you have a timeline for this?
17:46:45 <markmcclain> I'd provide more detail but I'm sitting in another meeting right now
17:46:55 <SumitNaiksatam> markmcclain: in the neutron IRC meeting, you mentioned it was going to be last monday
17:47:07 <SumitNaiksatam> markmcclain: dont mean to sound pushy, but just trying to get an estimate
17:47:08 <enikanorov> ok, let's then postpone this, i'd really like to have more detailed markmcclain's input
17:47:23 <markmcclain> I did not have connectivity while traveling the last 2 days (was expecting to have it)
17:47:55 <enikanorov> currently i think that what i have proposed is a superset of Mark's proposal
17:48:02 <mandeep> We have had flavors discussion going on for a long time. The plan is to reset that even before we have a proposal to review?
17:48:16 <markmcclain> enikanorov: I wouldn't classify it as a superset
17:48:34 <marios_> +1 mandeep this has been under discussion since summit
17:48:35 <enikanorov> markmcclain: sure, i don't know all the details of yours yet
17:48:53 <marios_> though ftr i havent had chance to check markmcclain proposal
17:49:33 <garyduan> vendor's implemention really rely on the flavor framework to move forward
17:49:45 <SumitNaiksatam> mestery: from a process perspective, is it advisable to have multiple proposals, or to collaborate on one proposal?
17:50:11 <mandeep> garyduan: +1, that is why I am worried about resets based on subjective claims
17:50:38 <mestery> SumitNaiksatam markmcclain: I want to see collaboration here, so we need to converge as a team on one proposal.
17:51:10 <mestery> I was in San Antonio last week with s3wong and others and got to listen to Mark's proposal, which I know others havent' had a chance to digest yet.
17:51:26 <mestery> So perhaps once Mark publishes his we can quickly converge. Sound good?
17:51:34 <pcm_> +1
17:51:54 <SumitNaiksatam> mestery: my undestanding was that enikanorov’s proposal started from markmcclain’s input since, markmcclain had objections with the existing service type framework
17:52:19 <SumitNaiksatam> mestery: both fwaas and vpnaas had patches to support STF in havana
17:52:28 <SumitNaiksatam> mestery: and these were put on hold
17:52:31 <mandeep> mestery: We also need to be careful that the months on discussion/debate that preceded it is not lost
17:52:36 <SumitNaiksatam> mestery: its been a few months since then
17:52:37 <mestery> I think there was some disconnect between enikanorov and markmcclain there, I'm hoping we can quickly converge on those for flavors this week.
17:53:15 <SumitNaiksatam> mestery: so what is your directive to this team on this topic going forward?
17:53:20 <mestery> I think the two approaches are close enough I'm hopeful this can be resolved ASAP.
17:53:39 <mestery> markmcclain: Once you publish your spec, I'll set something up to close on this.
17:53:47 <markmcclain> SumitNaiksatam: so problem is that the current direction does not solve the original problem we set out to solve
17:54:04 <enikanorov> my opinion is that it solves the original problem
17:54:11 <enikanorov> and goes beyond that
17:54:12 <SumitNaiksatam> markmcclain: okay, but i have trouble understanding that
17:54:24 <enikanorov> i can show it on different use cases
17:54:41 <SumitNaiksatam> markmcclain: the majority of the team here seems to think that the current flavors proposal is shaping up well
17:54:45 <mandeep> markmcclain: enikanorov: I am having problem with subjective claims without details. Please provide content/context
17:54:59 <markmcclain> SumitNaiksatam: the current prop fails on operator use cases
17:55:02 <SumitNaiksatam> markmcclain: perhaps we dont need to implement the proposal in its entirety in the first iteration
17:55:16 <enikanorov> markmcclain: is it possible to list those use cases?
17:55:55 <enikanorov> i think some folks from lbaas team just din't read through deep enough to claim that
17:56:33 <markmcclain> enikanorov: I think most folks have read it several times now
17:57:12 <enikanorov> if that were so, their comments would be different, i guess...
17:57:42 <enikanorov> anyway, let's talk when the alternative is published
17:58:12 <mandeep> markmcclain: I just want to understand it with a specific use-case/scenario
17:58:56 <SumitNaiksatam> markmcclain: so once you publish your proposal, will it eventually be folded into enikanorov’s proposal?
17:59:10 <SumitNaiksatam> markmcclain: i am just trying to understand what process we are proposing here
17:59:11 <mandeep> markmcclain: (that is the differences between the two approaches)
17:59:39 <enikanorov> i think right now it would require too much explanations from markmcclain, let's wait for the spec
17:59:45 <banix> i think we can wait for markmcclain proposal and take it from there; I would think we could come up with an agreement quickly once both proposals are at hand.
18:00:06 <mandeep> enikanorov: banix: OK
18:00:23 <mestery> banix: That's my hope as well, and we need flavors in Juno, so I expect a resolution to this that keeps everyone happy and moves Neutron forward.
18:00:38 <s3wong> banix: +1
18:00:48 <LouisF> markmcclain: can we get your proposal today?
18:01:00 <mandeep> enikanorov: banix: I agree that with a proposal, my questions should be addressed
18:01:26 <pgpus> Are we talking of this ? * Service Type - string identifier (LOADBALANCER, FWAAS, L3, VPN, etc)
18:01:26 <pgpus> * Name - name of the flavor
18:01:26 <pgpus> * Tags - string containing a list of (key, value) pairs (tags) that define capabilities.
18:01:43 <SumitNaiksatam> pgpus: that is the existing proposal
18:01:47 <enikanorov> pgpus: it was a bit updated since then, but yes
18:01:56 <pgpus> ok
18:02:01 <banix> SumitNaiksatam: when the proposal is out we may want to have a meeting on Friday perhaps?
18:02:10 <pcm_> +1
18:02:40 <SumitNaiksatam> banix: sure
18:02:43 <pcm_> SumitNaiksatam: Let's get an action item for delivery of the proposal, and an action item to have a meeting to discuss.
18:02:46 <s3wong> banix: are you suggesting that markmcclain should have the proposal written and ready by Thursday?
18:03:03 <pgpus> yes we did discuss tags with key,value with some mandory fields per Service Type
18:03:20 <pcm_> s3wong: Let's get a concrete estimate from markmcclain
18:03:23 <SumitNaiksatam> mestery markmcclain: does that sound like a good plan - have a meeting on friday to discuss the two proposals?
18:03:40 <banix> s3wong: I think mestery said the proposal will be out some time soon today. If that is the case or we have it by tomorrow then we can meet on friday
18:03:42 <pgpus> How is this different from Mark's am I missing something?
18:03:49 <mestery> SumitNaiksatam: +1
18:03:54 <nati_ueno> +1
18:03:57 <enikanorov> pgpus: let's wait for the detailed spec
18:04:03 <pgpus> ok
18:04:25 <nati_ueno> I think we invested plenty time to discuss flavor stuff
18:04:33 <nati_ueno> 2 release cycles, right?
18:04:34 <SumitNaiksatam> last time i proposed that we have a discussion on this markmcclain -1’ed the idea since he was not available
18:04:58 <nati_ueno> We should choose some way
18:04:59 <SumitNaiksatam> hence i am waiting for him to respond, if he is not available perhaps the meeting is pointless?
18:05:03 <enikanorov> nati_ueno: true
18:05:17 <garyduan> nati_ueno: +1
18:05:24 <s3wong> nati_ueno: +1... we definitely should
18:05:30 <SumitNaiksatam> nati_ueno: yes, i think plenty of people share your frustration
18:05:51 <banix> he is perhaps stuck in the other meeting and cannot read the current conversation; I think we will resolve this by this time next week ;)
18:06:18 <s3wong> banix: or resume this discussion next week :-)
18:06:22 <SridarK> nati_ueno: +1 as a vendor, if flavors is going to arrive late J-2 or J-3 we are toast w.r.t getting vendor implementations out
18:06:48 <banix> s3wong: i think we have all interested parties involved; we can get to an agreement in a week
18:06:55 <SumitNaiksatam> banix: absolutely, i dont want to chalk up an action item for him without him even getting to see what it is
18:06:57 <mandeep> mestery: as this is important for all services, can we put a deadline for this discussion/meeting?
18:07:00 <nati_ueno> SridarK: yeah, not only vendor. FWaaS and VPNaaS is still experimental because of flavor
18:07:16 <mestery> I think per SumitNaiksatam we should plan for an IRC meeting on Friday.
18:07:20 <SridarK> nati_ueno: yes absolutely
18:07:27 <nati_ueno> How about have a vote on the Friday meetings?
18:07:36 <nati_ueno> Let's see multiple options
18:07:37 <LouisF> +1
18:07:40 <enikanorov> hehe
18:07:41 <vinay_yadhav> +1
18:07:44 <natarajk> +1
18:07:44 <enikanorov> okay
18:07:46 <garyduan> +1
18:07:46 * mestery notes there is some upcoming dates around Spec Proposal and Spec Approval deadlines for Juno coming out soon ...
18:07:46 <pcm_> +1
18:07:52 <SridarK> +1
18:07:56 <mandeep> but the meeting is not much use unless markmcclain can join. Hence the request for a deadline
18:08:03 <s3wong> nati_ueno: +1. Resolution by Friday, let's not have another 40 minutes discussion on flavor during next week's adv service meeting
18:08:11 <SumitNaiksatam> #action SumitNaiksatam mestery markmcclain enikanorov to convene a meeting on friday june 27th to wrap up flavors blueprint spec
18:08:15 <nati_ueno> mestery: do you like voding idea?
18:08:18 <mestery> nati_ueno: I hope we don't need to vote, and can instead incorporate ideas from the specs together. Consensus is the way forward. :)
18:08:23 <nati_ueno> s/voding/voting/
18:08:42 <pcm_> mestery: +1
18:08:55 <nati_ueno> mestery: yeah, it is best
18:08:58 <pgpus> ok put the meeting time on site and will follow up
18:09:00 <SumitNaiksatam> does the same time as this meeting work for everyone?
18:09:04 <banix> mestery: agree and I think we can get there in short order… why am i so optimistic today :)
18:09:13 <SumitNaiksatam> same time same channel?
18:09:14 <mestery> banix: :)
18:09:14 <mandeep> banix: ;-)
18:09:15 <nati_ueno> mestery: however sometimes we need to go forward in time
18:09:20 <pgpus> ok
18:09:37 <banix> SumitNaiksatam: yes
18:09:39 <pcm_> SumitNaiksatam: time is OK for me.
18:09:39 <s3wong> banix: :-)
18:09:47 <mestery> nati_ueno: Also very relevant. There are many balls in motion here, we all want the same thing, sometimes getting there requires a little sweat and tears. ;)
18:09:48 <nati_ueno> time is ok for me too
18:09:51 <cathy_> same time works for me. should we move on to the next topic and have everyone review the new Flavor proposal offline?
18:09:53 <vinay_yadhav> ok
18:09:54 <mestery> +1 on time
18:09:58 <SridarK> SumitNaiksatam: time works
18:10:17 <mandeep> SumitNaiksatam: that time works for me as well
18:10:31 <nati_ueno> mestery: gotcha.
18:10:45 <s3wong> so time would be 1730 UTC June 27 on #openstack-meeting-3
18:10:49 <pgpus> you mean 11.30 AM PST istead of 10.30 AM PST Friday?
18:11:11 <SumitNaiksatam> #agree meeting to wrap up flavors discussion on Jun 27th Friday 17.30 UTC (10.30 AM PDT) in -meeting-3
18:11:22 <pgpus> ok
18:11:45 <SumitNaiksatam> ok moving on :-)
18:11:47 <mandeep> 10:30 PDT (so it is 11:30 PST ;-)
18:11:58 <SumitNaiksatam> #undo
18:11:59 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x2ff5950>
18:12:10 <banix> mandeep: “same time” is all i can follow
18:12:11 <SumitNaiksatam> #agree meeting to wrap up flavors discussion on Jun 27th Friday 17.30 UTC (10.30 AM PST) in -meeting-3
18:12:27 <SumitNaiksatam> mandeep pgpus: thanks :-)
18:12:39 <SumitNaiksatam> enikanorov: we can move on right?
18:12:44 <enikanorov> sure
18:12:47 <mandeep> banix: I agree - that is much easier
18:12:53 <SumitNaiksatam> enikanorov markmcclain: thanks for the update
18:13:00 <s3wong> cgoncalves: as I predicted, 70% ... actually it is closer to 80% :-)
18:13:06 <SumitNaiksatam> #topic Service base definition and Insertion
18:13:09 <cgoncalves> s3wong: :)
18:13:30 <SumitNaiksatam> s3wong: i hope you think we made progress though :-)
18:13:32 <SumitNaiksatam> #link https://review.openstack.org/#/c/93128
18:14:04 <SumitNaiksatam> so i dont see any -1s on this proposal
18:14:09 <mandeep> s3wong: if you really want to talk numbers it was 73.46 %
18:14:15 <mandeep> s3wong: ;-)
18:14:22 <SumitNaiksatam> Kanzhe s3wong: so are we all in agreement? :-)
18:14:46 <s3wong> SumitNaiksatam: yep, enough +1s (there were more before Kanzhe posted the latest patch) to move forward
18:14:47 <Kanzhe> SumitNaiksatam: So far, I haven't seen any outstanding issues.
18:15:14 <SumitNaiksatam> Kanzhe s3wong: so there are no blockers for you that you need to discuss here?
18:15:34 <Kanzhe> SumitNaiksatam: not at this time.
18:15:46 <SumitNaiksatam> ideally more people from this team should be +1ing this in case they are in agreement, so that it sets up the stage for the cores to step in
18:15:51 <pgpus> This was good old L2, L3 insertion with contect or did it change missed on that?
18:15:55 <s3wong> SumitNaiksatam: nope - and welcome SridarK to join us in making FWaaS work with service insertion framework
18:15:58 <LouisF> Kanzhe: what sort of Horizon work is needed to support service insertion?
18:16:07 <pgpus> context I meant
18:16:10 <SridarK> s3wong: yes absolutely glad to be of help
18:16:12 <marios_> Kanzhe: am i still on for the vpn side?
18:16:19 <SumitNaiksatam> s3wong: yes sure, SridarK: thannks for jumping in
18:16:29 <SridarK> no worries
18:16:30 <marios_> Kanzhe: have started looking at the db models and service base
18:16:31 <Kanzhe> marios_: yes, :-)
18:16:35 <SumitNaiksatam> marios_: yes i was about to bring that up as well
18:16:53 <marios_> Kanzhe: cool thx i will keep following
18:16:53 <banix> SumitNaiksatam: are we aware of any cores outside this group with significant interest?
18:16:56 <SumitNaiksatam> marios_: i noticed your comment as well, thanks much for jumping in
18:17:07 <banix> SumitNaiksatam: i meant wrt service insertion
18:17:22 <Kanzhe> LouisF: We can discuss in detail once the db mode is up for review.
18:17:22 <SumitNaiksatam> banix: i know that mestery nati_ueno markmcclain and rkukura have signed up
18:17:29 <marios_> SumitNaiksatam: great to be of help have been following the various specs from summit
18:17:57 <banix> SumitNaiksatam: what do you mean by  “signed up” sorry
18:18:19 <nati_ueno> I'm OK with this spec. but I have one quick question. Why we don't support insertion type for network?
18:18:35 <SumitNaiksatam> banix: see here #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan
18:18:40 <LouisF> Kanzhe: thx
18:18:53 <SumitNaiksatam> Kanzhe: nati_ueno’s question ^^^
18:19:12 <Kanzhe> nati_ueno: right now the thinking is subnet only. We can extend to network if use case comes up.
18:19:24 <s3wong> nati_ueno: do you see such need?
18:19:34 <Kanzhe> nati_ueno: also to keep the first version simple.
18:19:39 <nati_ueno> I think BGP based vpn network insersion
18:19:55 <nati_ueno> Kanzhe: OK. if so I can work this in another bp
18:20:07 <Kanzhe> nati_ueno: great! thanks.
18:20:09 <banix> SumitNaiksatam: thanks. want to make sure we persuit them and get their views so we know if there are significant disagreements sooner rather that later. that’s all.
18:20:12 <s3wong> nati_ueno: certainly, welcome to do so
18:20:47 <SumitNaiksatam> banix: yes, its a chicken and egg kind of situation
18:21:08 <SumitNaiksatam> banix: cores will probably not review if they dont see enough support from the sub team
18:21:37 <SumitNaiksatam> ok moving on
18:21:46 <Kanzhe> As s3wong pointed out, the spec lost a few +1's after I uploaded the latest version.
18:21:46 <SumitNaiksatam> #topic Traffic steering
18:21:52 <SumitNaiksatam> Kanzhe: sure
18:22:01 <SumitNaiksatam> Kanzhe: hopefully we can get them back :-)
18:22:10 <SumitNaiksatam> cgoncalves: your baby
18:22:24 <SumitNaiksatam> cgoncalves: was the plan to post an updated spec based on input?
18:22:24 <cgoncalves> SumitNaiksatam: poor child
18:22:25 <Kanzhe> SumitNaiksatam: yes. :-)
18:22:56 <cgoncalves> SumitNaiksatam: yes, but in the meantime we exchanged some emails
18:23:09 <cgoncalves> let me summarized my concerns to all
18:23:38 <cathy_> cgoncalves: I have a suggestion on the API so that they do not have duplicate API functionality and is consistent among the two BP. Have you seen my comment?
18:23:39 <cgoncalves> service chain (SC) BP is a high level BP
18:23:56 <cgoncalves> cathy_: here? review.o.o?
18:23:59 <SumitNaiksatam> cgoncalves: that is right
18:24:03 <cathy_> I mean the GBP
18:24:16 <cgoncalves> cathy_: yeah, I read it
18:24:28 <cgoncalves> cathy_: let me just summarize my concerns first, please
18:24:34 <cathy_> ok
18:24:59 <cgoncalves> so... I see some trending on SDN controllers like ODL and OpenContrail on supporting Service Function Chaining (SFC) / SC
18:25:49 <cgoncalves> the way it's going, I'd say for the SC BP implementation it would be much better to interact directly with those controllers as drivers rather than the traffic steering (TS)
18:26:03 <cgoncalves> in that way, SC would not depend on TS
18:26:08 <SumitNaiksatam> cgoncalves: that is one option
18:26:19 <nati_ueno> cgoncalves: +1
18:26:31 <cgoncalves> although, I think there is no plan yet on how to steer traffic to chains
18:26:51 <cgoncalves> same should be valid for the GBP work as they are considering the 'redirect' action to a SC
18:26:55 <SumitNaiksatam> cgoncalves: that said, as i was mentioning on the email thread, i think have precendence of using the controller-less OVS-based reference implementation
18:27:13 <SumitNaiksatam> neutron has, that is
18:27:24 <cgoncalves> SumitNaiksatam: for the SC BP?
18:27:40 <banix> cgoncalves: no in general
18:27:47 <SumitNaiksatam> cgoncalves: for any backend supporting the API
18:27:58 <SumitNaiksatam> cgoncalves: any feature that is
18:27:58 <cgoncalves> banix, SumitNaiksatam: ah, right
18:28:10 <LouisF> cgoncalves: GBP redirect action will steer traffic to SFC
18:28:33 <SumitNaiksatam> LouisF: GBP will only signal that intent
18:28:52 <cgoncalves> LouisF: ok, that's the part I'd like to know better. how does GBP will steer traffic to SFC?
18:29:13 * SumitNaiksatam thinks we need another dedicated meeting for TS bp spec as well!
18:29:29 <cgoncalves> TS could be used by GBP, and any other work, to steer traffic to a SC for instance
18:29:32 <cgoncalves> SumitNaiksatam: :)
18:29:35 <pgpus> SC can define Policies but traffic steering can simply focus on different ways to control flows and so we here provide primitives for use cases may SC is one of the users
18:29:43 * SumitNaiksatam thinks may be we should just have a weeklong Adv Services’ hackathon ;-)
18:29:53 <banix> SumitNaiksatam: :)
18:29:59 * SumitNaiksatam or “mini-summit"
18:30:01 <cathy_> cgoncalves: agree, that TS could be used by GBP, that is why my API proposal
18:30:04 <s3wong> SumitNaiksatam: you are too optimistic - we are far from hacking code yet
18:30:06 <cgoncalves> SumitNaiksatam: yeah! Paris next week? :)
18:30:07 <LouisF> cgoncalves: a match in a GBP policy rule results in redirect action
18:30:26 <SumitNaiksatam> s3wong: i meant mini-summit actually :-)
18:30:37 <SumitNaiksatam> anyway, seems like this is a longer discussion
18:30:39 <cgoncalves> cathy_: exactly, but TS would still add support to traffic classification
18:30:52 <SumitNaiksatam> mainly, cgoncalves LouisF cathy_ you need to reconcile?
18:30:56 <SumitNaiksatam> or is it more folks?
18:31:13 <s3wong> cgoncalves: I actually would agree with that - so once TS is available, GBP's mapping driver can utilize it
18:31:15 <LouisF> cgoncalves: GBP policy rule has a classifier
18:31:35 <cgoncalves> I'd like everyone's opinion on this as it would considereably change the TS BP
18:31:43 <cathy_> cgoncalves: GBP already has classifier specification in its "redirect to chain" API. How do we make sure these two classifiers are consistent.
18:32:13 <SumitNaiksatam> cathy_ LouisF: the GBP classifier is application centric classifier
18:32:15 <cgoncalves> LouisF: I know but TS should not be specific to GBP as other works may rely on and need classification on TS
18:32:18 <banix> cgoncalves: opinion on “this” you wrote; can you specify what “this” is
18:32:20 <SumitNaiksatam> so its L4
18:32:30 <jmsoares> cgoncalves, SumitNaiksatam, cathy_: I also think the TS should be thought beyond the SC functionality. SC needs TS, but TS can possibly enable other things.
18:32:38 <SumitNaiksatam> cgoncalves: i agree with you
18:32:39 <s3wong> cathy_: in that case, the mapping driver would set the TS classifier - which may or may not have anything to do with GBP policy-rule classifier
18:32:45 <cathy_> I am OK with TS having classifier if we can have a way to solve the consistency issue
18:32:50 <pgpus> Agree with Summit traffic steering involves classification of packets or flows how it viwes may differ from SC
18:32:56 <SumitNaiksatam> jmsoares: i agree hence we separated this out
18:33:11 <cgoncalves> banix: instead of TS be used for chaining, it should be the other way. TS steering traffic to chains
18:33:14 * SumitNaiksatam makes a customary apology to the FWaaS folks for eating into their meeting time!
18:33:20 <s3wong> OK guys, 3 minutes overtime already :-)
18:33:22 <cathy_> SumitNaiksatam: the GBP classifier will be pulled into the intent of service chain through "redirect" action
18:33:49 <SumitNaiksatam> cathy_: shall we discuss the GBP specifics in teh GBP meeting tomorrow?
18:33:54 <SumitNaiksatam> cathy_: we will have more time there
18:34:02 <marios_> goodnight all
18:34:09 <cgoncalves> cathy_: we can indeed come up with a compatible/same classifier resource or even share them, but both BPs should have their own classification APIs
18:34:11 <LouisF> SumitNaiksatam: +1
18:34:19 <SumitNaiksatam> cgoncalves jmsoares: unfortunately it does not seem like we can resolve this right now
18:34:21 <jmsoares> SumitNaiksatam: yes, this is only to highlight that TS is by itself a functionality, that by nature I believe it needs the "classifier" entity
18:34:31 * s3wong feels sorry that vinay_yadhav never got a chance to update TapaaS over the last several weeks
18:34:39 <SumitNaiksatam> cgoncalves: any chance you can fire up a -dev thread?
18:34:42 <vinay_yadhav> :)
18:34:50 <cgoncalves> SumitNaiksatam: sure, will do
18:34:59 <banix> cgoncalves: yes thanks
18:35:03 <cathy_> SumitNaiksatam: ok
18:35:15 <anil_rao> A suggestion: Can we proceed through the Specs in round-robin fashion from next week?
18:35:26 <vinay_yadhav> Can we get some time for TaaS next week
18:35:44 <SumitNaiksatam> anil_rao vinay_yadhav: yes sure, and our apologies
18:35:46 <cgoncalves> anil_rao: in order to give everyone a chance to present their work, I agree with you
18:35:51 <s3wong> anil_rao: as in - let's start with TapaaS first next week :-)
18:36:00 <anil_rao> Thanks. :)
18:36:01 <vinay_yadhav> thanx
18:36:11 <marios_> ani
18:36:11 <SumitNaiksatam> we do have to prioritize based on what is higher prirority for Juno though
18:36:32 <SumitNaiksatam> but we will take up TAPaaS next time first
18:36:36 <marios_> s3wong: am always up for tapas ;)
18:36:44 <SumitNaiksatam> marios_: :D
18:36:51 <SumitNaiksatam> #topic open discussion
18:36:52 <anil_rao> :D
18:36:55 <s3wong> SumitNaiksatam: if we indeed can come to a resolution this Friday on flavor, I think next week's meeting will have plenty of time :-)
18:36:56 <SumitNaiksatam> any parting thoughts?
18:37:01 <cgoncalves> marios_: I was also having the exact same thought :D
18:37:04 <SumitNaiksatam> s3wong: absolutely :-)
18:37:13 <cathy_> cgoncalves: agree with your suggestion on same classifier resource and share with them
18:37:25 <LouisF> SumitNaiksatam: time of flavor meeting on Friday?
18:37:29 <SumitNaiksatam> alright 7 minutes over
18:37:47 <SumitNaiksatam> LouisF: 17.30 UTC (10.30 AM pST)
18:37:53 <LouisF> thx
18:37:54 <cgoncalves> cathy_: problem will be coordination as I believe the GBP work is quite advanced when compared to TS at the moment
18:38:05 <SumitNaiksatam> alright thanks everyone!
18:38:07 <cathy_> cgoncalves: agree. as long as no conflict on classfier specification in two APIs, I am fine.
18:38:09 <marios_> o/ night then
18:38:10 <banix> thank you
18:38:13 <anil_rao> Thanks.
18:38:16 <banix> bye everybody
18:38:16 <cgoncalves> thanks
18:38:18 <cgoncalves> cathy_: yes
18:38:19 <vinay_yadhav> bye thanx
18:38:19 <SumitNaiksatam> cgoncalves cathy_: lets continue in the GBP meeting tomorrow
18:38:22 <SumitNaiksatam> bye all!
18:38:25 <SumitNaiksatam> #endmeeting