17:31:59 #startmeeting Networking Advanced Services 17:32:00 Meeting started Wed May 21 17:31:59 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:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:32:03 The meeting name has been set to 'networking_advanced_services' 17:32:18 vinay_yadhav: welcome! 17:32:23 hi 17:32:24 thanx! 17:32:28 #topic Atlanta summit recap 17:32:35 #link https://etherpad.openstack.org/p/juno-advanced-services 17:32:52 vinay_yadhav is working on network tap / port mirroring, and kanzhe and I asked him to join us here 17:32:56 we had long discussions during the summit, and most of you were part of that 17:33:12 SumitNaiksatam: agenda link? 17:33:14 s3wong: yes, sure, vinay_yadhav mentioned that to me, we interacted at the summit as well 17:33:38 #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices 17:34:03 Hi 17:34:14 the summit session time was on the shorter side, to go through the design in detail 17:34:16 sballe: hi 17:34:31 any after thoughts from the summit? 17:35:07 if not, lets get into the specifics 17:35:14 #topic Juno planning and feature tracking 17:35:28 #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:35:57 i made a first cut with links to the blueprints that have been posted in gerrit so far 17:36:30 this is not to say that what we intend to discuss in this forum is only limited to what is currently in the table 17:36:35 just a starting point 17:37:00 my proposal is that we populate the items in that table, and start tracking them in this meeting (based on prirority) 17:37:03 thoughts? 17:37:08 SumitNaiksatam: thank you for creating that page. it will definitely help all of us keep track of most if not all BPs 17:37:17 cgoncalves: sure 17:37:19 SumitNaiksatam: +1 17:37:24 kanzhe: ok 17:37:37 i have volunteered names for owners ;-) 17:38:04 SumitNaiksatam: :-) 17:38:14 but if anyone wants to take up items which are not being looked at, please feel free to do so and add 17:38:15 SumitNaiksatam: what will be the prioritization criteria? 17:38:28 cgoncalves: good question 17:39:04 cgoncalves: to a large extent we need to align balance the priorities of Neutron as a whole, with what we do here 17:39:27 cgoncalves: so the things which have direct dependencies, should obviously higher priority 17:39:49 we need to eventually discuss this with the PTL and the core team 17:39:54 SumitNaiksatam: agreed 17:40:19 for now, my suggestion is that, lets populate the table with the items, and when you think you can achieve these 17:40:28 we can take it from there 17:40:50 sound okay to everyone? 17:40:57 +1 17:41:02 +1 17:41:06 +1 17:41:10 ok 17:41:12 SumitNaiksatam: how about the spec approval? is anyone looking to push those forward? 17:41:26 s3wong: good question, we have to do that as a team :-) 17:41:30 s3wong: I was going to ask the same question. 17:42:00 core reviewer cycles are limited, so this going to be tough 17:42:12 but +1s do matter 17:42:26 SumitNaiksatam: kanzhe: I am OK with starting to code, but it would be difficult if some core dev keeps on requesting changes 17:42:27 I’d like to see several +1’s on each spec from subteam members before we start recruiting core reviewers 17:42:40 so as a team lets start getting comments out (we dont have to wait for the cores) 17:42:41 * cgoncalves senses a '+1 specs review trading' 17:42:48 This team should converge on the spec first. +1 from all members would be a good indication. 17:42:53 cgoncalves: by all means 17:42:55 rkukura: +1 17:42:57 * mandeep cgoncalves ;-) 17:42:58 The order seems ok to me as enetered for now flvaor, insertion, steering and chaninig 17:43:25 s3wong: yes lets get the spec approved before any major coding, you can definitely do a quick PoC to validate 17:43:35 may be chaining and traffic steering can be paralle 17:43:37 pgpus: ok, thanks for that feedback 17:43:43 pgpus: agree 17:44:10 pgpus: well, we may not need steering for chaining; so will change the order at the end 17:44:23 pgpus: yes 17:44:31 thats should be fine 17:44:41 pgpus: The objective was to keep chaining as independent as possible so that it can provided by different technologies (using service ports + steering or existing services) 17:44:49 so let me ask, what other “topics” from the ones that are mentioned in the table are on our immediate radar? 17:45:28 service sharing by users belonging to a tenant 17:45:39 SumitNaiksatam: you mean, other topics in addition to what is on the wiki? 17:45:57 s3wong: yes, in addition to what is noted in: https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:46:00 No sure if sharing is there may be i need to look little deper into that 17:46:05 SumitNaiksatam: NA means Not Applicable as in we are not going to do it? 17:46:32 banix: probably bad choice of words :-) 17:46:43 banix: will change that to Juno 17:46:54 pgpus: are you planning a blueprint for this? 17:47:28 ok in, general, let me propose that for topics to appear in the above table, you need to have a gerrit spec submitted, does that sound reasonable? 17:47:35 SumitNaiksatam: yes got a bit confusng, thanks. 17:47:48 SumitNaiksatam: +1 17:47:57 agreed 17:47:59 ok 17:48:03 ok good 17:48:21 OK after reviewing of all BPs I will see if I need to add a new BP if its required as service offerred by a Service Provider must be shared among many users belonging to that tenant 17:48:34 pgpus: ok 17:48:55 at this point we have a lot on our plates, so we cannot go too much beyond what we currently have 17:49:16 the resource contention is on the reviewer time (not so much on the developer effort) 17:49:35 OK but is it's just adding a flag or two to share with minimum code I don't see that a big deal 17:49:49 SumitNaiksatam: +1 i hope we can get Flavors and Service Insertion at least 17:49:54 pgpus: sure, i was not commenting on your suggestion, i was just making a general statement 17:49:58 SumitNaiksatam: +1, getting too ambitious here now, it seems :-) 17:50:17 SridarK s3wong agree (i tempted to say, show me the code ;-)) 17:50:23 :-) 17:50:27 Sure falvor is easier once we compare wth nova flavors and add what we ned from our resources and pools 17:50:33 SridarK: that would be great accomplishment by Juno already 17:50:56 ok, so starting today, we will track based on the table :-) 17:51:19 the table might have more items in the coming weeks, and we will evaluate accordingly 17:51:26 ok 17:51:36 everyone okay? 17:51:40 +1 17:51:40 ok 17:51:43 +1 17:51:45 +1 17:51:47 +1 17:51:50 ok 17:51:52 +1 17:51:56 +1 17:52:01 ok cool 17:52:03 moving on 17:52:08 into specifics 17:52:20 #topic Neutron Advanced Services' Common Framework gerrit spec 17:52:30 so this is just FYI, most of you already know 17:52:38 #link https://review.openstack.org/#/c/92200 17:52:45 was approved during the last week 17:53:06 i guess the a concrete development coming out of the summit :-) 17:53:42 #topic: Neutron Flavor Framework 17:54:06 #link https://review.openstack.org/#/c/90070 17:54:11 i dont think eugene is here 17:54:19 we discussed this again at the summit 17:54:37 i think the consensus was that most of what is currently in the spec is good 17:54:48 for the tenant facing API 17:54:52 everyone agree? 17:55:14 +1 17:55:17 although there are a few -1s on the review (i think eugene will address those when gets off the road) 17:55:19 +1 17:55:45 SumitNaiksatam: also we want to keep the scheduling of the backend fairly simple for the first pass 17:55:56 SridarK: yeah coming to that 17:56:23 i was going to say that there was some objection on using the service type framework for the backend 17:56:31 i did not quite understand what the push back was 17:56:39 Some concern on this becoming too complex - perhaps for the right reasons but it will be good to phase out the implementation 17:56:49 SridarK: ok 17:56:56 SumitNaiksatam: Yes - i think a lot of us were on the same page on that 17:57:06 SumitNaiksatam: really? most of the complains I heard was how to properly standardize a basic set of tags? 17:57:08 SridarK: we already have the framework, and i guess people understand it 17:57:31 SumitNaiksatam: yes i hope we can push for that 17:58:03 s3wong: in the summit session i heard some differing opinion from mark mcclain on the provider side of things (in the context of STF) 17:58:15 although that was the only differing opinion i heard 17:58:41 perhaps eugene can better explain next week 17:58:48 sure 17:58:57 meanwhile, does everyone agree that this is highest priority? 17:59:04 mark seems to support it for sure 17:59:08 i mean flavors framework 17:59:41 if so, please comment on the review, so that we can move this forward 17:59:53 +1 18:00:02 we need to start knocking off these gerrit specs 18:00:10 SumitNaiksatam: yes, ServiceBase class has a field for flavor, so I hope to see it done soon also 18:00:14 as a team effort 18:00:35 ok next topic 18:00:50 I see flavor being shared and similar should be available for instances of service ..shared - boolean - whether the flavor is visible to all tenants 116 18:00:50 18:01:16 pgpus: ok, perhaps you can add that comment to the review 18:01:26 ok will do 18:01:45 pgpus: the issue with sharing is that, its difficult to nail down the semantics on the datapath 18:01:55 pgpus: its probably different across services 18:02:10 pgpus: we faced this debate at the time we were introducing fwaas 18:02:37 but i agree that most vendors want to see some notion of this (opinios differ though on what they actually want) 18:02:44 Agreed and that shared must be limited to with tenant data users and not to admin to see all what I mean and will look into that 18:02:55 #topic: Service base definition and Insertion 18:03:12 #link https://review.openstack.org/#/c/93128 18:03:20 kanzhe, s3wong: ? 18:03:34 quick summary of summit discussion? 18:03:45 SumitNaiksatam: yes. The spec is up for review. 18:03:54 We presented it at the design summit, and there was no objection :-) 18:04:11 kanzhe s3wong: okay :-) 18:04:16 s3wong: and not much nodding either :) 18:04:30 At the summit, I didn't hear any major objection. 18:04:32 OK let me review and give feedback in next meeting for service insertion (if its still open for review) 18:04:32 We have also had a Neutron pod discussion - some guys from F5 were questioning on external port, but it was clarified 18:05:02 s3wong: yes that was addressed, and we will be meeting rick again 18:05:08 We also had discussion with HP (DVR guys), FWaaS team, and ServiceVM subteam. There is some level of consensus here 18:05:16 that said the external port is not the main thing in the proposal 18:05:22 so lets not get distracted by that 18:05:24 so we are cautiously optimistic :-) 18:05:35 s3wong: yes, good 18:05:40 How does everyone here feel about the proposal? 18:06:02 Not much feedback on the spec yet. 18:06:06 i had some questions earlier, which kanzhe, you seem to have answered, but i havent had a chance to circle back 18:06:44 kanzhe: i think this is good - i am trying to fit this into our use case as well and will add comments to the review 18:06:46 Not clear to me is it Blueprint review or Code review as I see some pathchens in it , may be I am new need to do some homework on this 18:07:01 SumitNaiksatam: ok. SridarK : thx. 18:07:05 kanzhe: sorry about that. I will review it this week 18:07:22 pgpus: our specs are also now reviewed in gerrit 18:07:26 pgpus: not code, just the definitions 18:07:55 ok sometimes, no objection is passive agreement :-) 18:07:57 cgoncalves: That would be great. 18:08:12 OK I see Blueprint steps and will give feedback comments on it if Ok to dos o 18:08:19 pgpus: thanks 18:08:23 next topic 18:08:38 #topic traffic steering 18:08:46 \o/ 18:08:53 #link https://review.openstack.org/#/c/92477 18:09:13 cgoncalves: normally i would have asked you to give an update, but i guess we owe you an update as well :-) 18:09:21 cgoncalves: since you were not able to make it to the summit 18:09:44 anyone wants to summarize the disccusion we had in the neutron pod on this? 18:09:53 SumitNaiksatam: ah! maybe you've already summed it up yesterday? 18:10:12 cgoncalves: yes i did, but i want others to provide their opinion as well 18:10:27 SumitNaiksatam: sure, I would really appreciate that 18:10:27 SumitNaiksatam: cgoncalves: so the summary conclusion is that community is asking if traffic steering and service chaining should be the same thing 18:10:57 You mean on traffic ssteering absraction? 18:11:14 s3wong: traffic steering would accomplish the same use case as service chaining at the end 18:11:40 s3wong: not the same thing I guess, one is an enabler of the other. 18:11:42 s3wong: service chaining is focused on neutron adv services whereas traffic steering on port chaining 18:12:06 i.e., traffic steering as it is defined in the bp today seems to be a special case of service chaining (I am just reflecting on what the community came about :-) ) 18:12:36 OK i subscribed to it and will reveiw the traffic steering too 18:13:29 cgoncalves: jmsoares: you guys may want to clarify the differences, or see if the spec can combine with service chaining one 18:13:35 So this week I should have my hands full with reviewing atleast 3 of 4 topivcs 18:13:49 s3wong: right. I guess that we started the BP with the "service chaining" in mind and as an ultimate goal. With time it evolved to be something more generic and, let's say, low level 18:13:55 s3wong: the traffic steering BP was originally created to propose a different approach from the at the time original service chaining where you would create chains based on services and thus only supporting the existing services 18:14:10 pgpus: thanks 18:14:29 cgoncalves: jmsoares: I know :-) but we need further clarification for community to see it as such 18:14:42 s3wong: ah, gotcha 18:14:47 cgoncalves jmsoares: to extend what s3wong was saying, people were asking if we can create the notion of a “generic services” wrapper that can be used in teh service chain 18:14:56 s3wong: agree :) the spec needs to reflect that and currently is not that clear 18:15:00 Traffic steering needs to be dynamic as flow maps change so not sure if we can mix it up with service shaning which may be static 18:15:20 such that traffic steering need not have to be directly exposed to the user 18:15:59 in general people dont want to see two different ways of achieving service chains 18:16:36 let me rephrase, two different ways of exposing service chains to the user 18:16:44 and they prefer the higher level abstraction 18:17:16 this does not change a whole lot in terms of what we are already saying, or is in the spec 18:17:25 SumitNaiksatam: how high level is that abstraction? 18:17:47 Not sure as service policy may require the srveice to be veiwed in different way, however abstractions must hide it, so may be we are same page 18:17:54 jmsoares: something similar to what is being discussed in: https://review.openstack.org/#/c/93524 18:18:59 however, that said, the general abstraction would need to capture the case where the service is on a VM, and neutron does not expose that service abstraction 18:19:24 so for now, lets focus in the review that has been submitted for this 18:19:46 i guess its a matter of considering whether the port chain API is tenant facing or just admin 18:20:09 SumitNaiksatam: ok, but that would be just a matter of whether exposing an API or not right? if so, we can create the core base and propose a user API too. either the API would be accepted or not that would be a thing not to worry much about 18:20:27 Are this related to ServiceVM which is a sepoerate BP? 18:20:29 cgoncalves: yeah, i think we said the same thing :-) 18:20:48 pgpus: Service VM is a whole beast in itself 18:20:59 pgpus: we will leverage that 18:21:12 SumitNaiksatam: yes :-) 18:21:17 pgpus: and most likely drive some requirements from this discussion 18:21:28 SumitNaiksatam: How would we in the high level abstraction perform a chaining sequence dependent on the type of traffic? 18:21:33 OK I see, so let me just stick to the 4 topics and put my comments on them before next meeting to catchup with group 18:21:45 s3wong has been attending teh service VM meetings, and will try to sync up, others can participate as well 18:22:00 SumitNaiksatam: maybe is not how, but whether if it would be possible 18:22:08 SumitNaiksatam: sure - the next meeting will resume on June 2nd, for anyone interested 18:22:21 jmsoares: good question, but the expectation is that there is some context to the chain 18:22:58 jmsoares: which will allow specifying the traffic classification (internally, not necessarily exposed to the user) 18:23:03 You mean Monday June2 or or Wed june 4? 18:23:24 ok since we are running low on time (as usual) 18:23:32 pgpus: ServiceVM meetings is on Tues 5:00 UTC 18:23:48 so June 1st (sorry) 18:23:52 i will skip the service chainig blueprint, since i saw mandeep drop off, but will try to get an update from him 18:24:05 SumitNaiksatam: but if that's done internally, Neutron must known "why" the chain is there 18:24:06 #topic Tap as a Service spec 18:24:07 Sumit - thanks for all your info 18:24:33 jmsoares: lets continue discussion offline (sorry :-)) 18:24:43 vinay_yadhav: quick summary? 18:24:49 SumitNaiksatam: sure, no prob :) 18:25:01 i have mailed the initial version of the spec on the mailing list 18:25:16 vinay_yahav: you have five minutes :-) 18:25:16 vinay_yadhav: is this in gerrit? 18:25:33 the blueprint intended to make it an extension, but in the spec we propose it as a service 18:25:42 vinay_yadhav: ok 18:25:46 as per the discussion we had in the summit 18:25:53 sumit: not yet 18:25:59 i will put it in tomorrow 18:26:02 vinay_yadhav: ok, great 18:26:06 or tonight 18:26:12 vinay_yadhav: you may want to put it on gerrit - and forget about the initial bp, it is irrelevant now since it was never on gerrit 18:26:13 and perhaps you can add to the table so that we can track 18:26:26 vinay_yadhav: thanks for the update 18:26:28 s3wong: ok sure 18:26:37 #topic NFV discussions 18:27:06 this subteam has started work 18:27:23 and there are points of intersection with what we are trying to achieve here 18:27:32 so we need to collaborate 18:27:44 NFV meeting will be every Wed starting June 2nd at 1700 UTC, I believe 18:27:47 i believe mestery will be participating in those meetings 18:27:50 s3wong: yes 18:28:00 SumitNaiksatam: Yes, it's on my calendar and I plan to attend. 18:28:17 or June 4th (again, what's up with my June 2nd typo)... 18:28:29 day/time may change after the first meeting 18:28:33 mestery: thanks 18:28:36 #link https://wiki.openstack.org/wiki/Meetings/NFV 18:28:39 1400 UTC 18:28:47 see above ^^^ for details 18:29:03 and #link https://etherpad.openstack.org/p/juno-nfv-bof for summit discussion recap 18:29:13 #topic Open Discussion 18:29:20 got it wrong, because I remember it is 7am PDT, sorry guys 18:29:47 anyone wants to bring up anything that we did not cover? 18:29:58 it was great meeting everyone at Atlanta 18:30:10 hope everyone had a pleasant flight back 18:30:24 no thanks 18:30:46 looks like we will actually wrap on time today! 18:30:50 thats a first 18:30:51 right on time! 18:31:02 not make the fwaas folks wait for a change 18:31:07 alright thanks everyone 18:31:10 until next week 18:31:15 #endmeeting