17:32:05 #startmeeting Networking Advanced Services 17:32:05 Meeting started Wed Jun 11 17:32:05 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:32:08 The meeting name has been set to 'networking_advanced_services' 17:32:13 #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices 17:33:05 for the last couple of weeks we have started to track the priority blueprints in this meeting 17:33:15 #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:33:37 before we get into each blueprint, anything anyone wants to bring up at outset? 17:34:25 i am little concerned that our specs are still in review at the end of Juno 1 17:34:25 SumitNaiksatam: why back to work so early :-) ? 17:34:31 s3wong: ha :-) 17:34:42 i will get back to real work soon 17:34:52 this is just a break ;-) 17:35:03 Last week few were approved I thought 17:35:06 lets discuss the review logistics in the open discussion 17:35:20 pgpus: not sure which ones you are referring ot 17:35:24 *to 17:35:57 enikanorov: there? 17:36:03 Mot sure me too but of the 5 we had 2 or 3 were in approved state 17:36:31 pgpus: only the general Juno plan is approved 17:36:31 pgpus: I think only SumitNaiksatam 's umbrella bp was approved 17:36:37 s3wong: yeah 17:36:39 hi 17:36:46 enikanorov: doesnt seem to be on 17:36:48 Hi 17:37:00 but Kanzhe is popped in at the right time :-) 17:37:07 #topic Service base definition and Insertion 17:37:10 Welcome back, SumitNaiksatam 17:37:11 good :-) 17:37:19 Kanzhe: thanks :-) 17:37:20 Ok I don't see any of the 5 approved, may be was referring to some other Blue prints 17:37:21 #link https://review.openstack.org/#/c/93128 17:37:28 pgpus: ok 17:37:45 Kanzhe: there were a few pending comments on the blueprint 17:37:51 pgpus: this one is approved #link https://review.openstack.org/#/c/92200 17:38:05 Kanzhe: are there any issues that you would want to bring up for discussion here? 17:38:18 SumitNaiksatam: yeah, I saw that you -1 it 17:38:19 SumitNaiksatam: Yes, I will address the comments later today. 17:38:21 Kanzhe: or you can take care of the review comments? 17:38:28 s3wong: yeah i did 17:39:03 s3wong: i can work with you guys though, i will try not be the bottleneck :-) 17:39:17 Kanzhe: s3wong: I also reviewed today - have some minor clarifications 17:39:21 SumitNaiksatam: sure, good 17:39:30 SridarK: yes, I too noticed you have -1 it :-) 17:39:35 SridarK: thanks. 17:39:36 so i would like to poll the other reviewers who have assigned themselves 17:39:54 I had seen some blue print using protocol:port being used of service insertion with firewall as opposed to L2/L3 insertion we were looking at, so are there multiple blue prints to this topic?\ 17:40:10 pgpus: link? 17:40:17 s3wong: overall looks good nothing negative here (no pun intended) 17:40:46 SridarK: it's OK :-) . We will address your concerns 17:40:55 I will send u later as it was on a diff system so later that 17:41:00 LouisF: are you there? 17:41:07 yes 17:41:15 dont see regxboi marios here 17:41:27 LouisF: you signed up to review, have you reviewed? 17:41:35 will do so 17:41:50 i am looking at the list at the top of: 17:41:54 #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:42:06 yes i am commited to review 17:42:18 LouisF: thanks, hopefully soon :-) 17:42:21 Kanzhe will update soon, so we would love for everyone to review once the latest one is posted 17:42:30 LouisF: we are already missing our first milestone 17:42:39 is ivar here? 17:42:51 probably not 17:43:01 ok so i went through the assigned reviewers 17:43:15 i dont want to start pinging the cores until we have consensus in the team here 17:43:28 anyone has major issues with this spec? 17:43:43 or its just that we havent reviewed it carefully? 17:43:56 SumitNaiksatam: I am going to San Antonio next week to work with LBaaS team for them to conform to this as they revamp their APIs 17:44:06 s3wong: nice 17:44:12 So hopefully our own team has reached a consensus by then :-) 17:44:23 s3wong: absolutely 17:44:45 s3wong: SumitNaiksatam It would be great to put an internal target for review feedbacks. 17:45:05 Kanzhe: our target to get this approved was today 17:45:18 Kanzhe: great idea. LouisF, SridarK? 17:45:19 Kanzhe: or if not approved at least to understand why it is not a being approved 17:45:22 SumitNaiksatam: great! :-) 17:45:33 will review today 17:45:40 Kanzhe: unfortuntaley we dont yet have enough reviews even within the sub-team here 17:45:51 s3wong: yes agree 17:45:55 is kevinbenton here? 17:46:22 yes 17:46:31 SumitNaiksatam: agreed. I broadcasted a plea on the mailing list, but was silently ignore. 17:46:43 Kanzhe: mailing list will not help 17:46:48 I will review by Friday. 17:46:58 we have to work within our team here first 17:47:09 banix: thanks, i was just going to put you on the spot ;-) 17:47:11 I will review the BP too. 17:47:19 kevinbenton: you have volunteered to review 17:47:26 kevinbenton: are you happy with this spec? 17:47:30 gduan: thanks 17:47:39 Is trhere anything that needs to be updated to design https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit?pli=1# 17:47:42 cgoncalves: you also signed up, any comments? 17:47:47 Kanzhe: update by tonight then :-) ? 17:48:06 s3wong: yes. 17:48:23 kevinbenton: i know you are part of the design team, but i would like to see a +1 if you dont have any issues :-) 17:48:25 SumitNaiksatam: I haven’t looked at the latest one, I will review the next upload 17:48:31 kevinbenton: ok thanks 17:48:35 SumitNaiksatam: sure, will do 17:48:39 pgpus: dont look at that document 17:48:41 pgpus: I don't see any design change yet. 17:48:52 pgpus: #link https://review.openstack.org/#/c/93128 17:49:13 pgpus: yeah, please ignore the document, and focus on the gerrit spec reivew 17:49:56 #action LouisF kevinbenton gduan banix cgoncalves regxboi marios ivar to review https://review.openstack.org/#/c/93128 by end of week 17:49:56 ok thanks 17:50:13 hemanthravi: can you review as well? 17:51:08 Kanzhe s3wong: i would request you to please return the review favor with the other blueprints 17:51:24 SumitNaiksatam: yes travelling this week will do it by mon 17:51:30 Kanzhe s3wong: i know you guys are terribly busy, but review begets review ;-) 17:51:47 SumitNaiksatam: absolutely. Ready to review the other four bps for the team 17:51:47 hemanthravi: thanks, can you please add yourself to the reviewers (or I can do that ;-)) 17:52:01 SumitNaiksatam: as owner of that ^ google doc, should one (you?) add a warning message to it saying that doc is deprecated and pointing to the right URL (blueprint URL)? 17:52:05 SumitNaiksatam: which one? 17:52:16 SumitNaiksatam: this for 93128 right? 17:52:20 cgoncalves: good suggestion, i will do it, my bad 17:52:28 hemanthravi: correct 17:52:35 Kanzhe: all the others 17:52:39 SumitNaiksatam: i'll do that 17:52:45 Kanzhe: all the other four below ours #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:52:55 Kanzhe: at least the flavors, traffic steering and chaining 17:53:01 enikanorov: there? 17:53:06 I will review the blueprints too, service chaining specifically 17:53:13 SumitNaiksatam: Kanzhe yes. Will do it by the weekend. 17:53:18 Kanzhe: Oh, and flavor also... 17:53:27 Cathy_: nice, thanks much in advance 17:53:53 Cathy_: if you feel comfortable please add yourself to the reviewers list: https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:54:02 sure, will do 17:54:03 Cathy_: that way I can hound you ;-P 17:54:36 ok it doesnt seem enikanorov is still not around 17:54:44 #topic Traffic steering 17:54:52 #link https://review.openstack.org/#/c/92477 17:55:06 cgoncalves: are you planning a new patch? 17:55:47 SumitNaiksatam: we'd like first to get input from banix et al. on Joao's last comments 17:56:05 cgoncalves: ok please go ahead, we can have the discussion now and resolve it if possible 17:56:08 banix: ? 17:56:21 cgoncalves: will do by end of day (night) today 17:56:30 banix: thanks 17:56:38 SumitNaiksatam: sorry, i'm late 17:56:55 SumitNaiksatam: now we can go to flavor! 17:56:55 i'll give an update when you give me a timeslot 17:57:08 all: note that I've submitted three patches for reviewing but marked as WIP 17:57:11 #link https://review.openstack.org/#/q/topic:bp/traffic-steering-abstraction,n,z 17:57:12 enikanorov: no worries, we can do flavors next, people are getting restless without the customary start with flavors discussion ;-P 17:57:24 :) 17:57:25 cgoncalves: nice 17:57:36 cgoncalves: OK - still need to review your spec; sorry for the delay 17:57:38 marked as WIP because BP has not yet been approved 17:58:09 cgoncalves: thats the righ approach, very much appreciate the process you are following 17:58:17 more codebase will follow once more reviewing is given 17:58:30 cgoncalves: which other reviewer do you want to check with? 17:58:49 *reviewers 17:59:05 SumitNaiksatam: I'm not sure it's the best approach to follow, though, but I will follow a similar codebase as ML2 and GP. how does that sound to you all? 17:59:16 I can provided I get some help on Gerrit from one of you? 17:59:18 cgoncalves: yeah good 17:59:26 pgpus: nice, much appreciated 17:59:44 is Youcef_ here? 17:59:44 SumitNaiksatam: Ryan Moats as he brought some comments too 17:59:57 OK I will review the 3 of the listed one and work with cgoncalves 18:00:03 cgoncalves: yes, but i dont see ryan here today 18:00:07 pgpus: thanks! 18:00:27 Youcef_ had comments on both this and the insertion bp 18:00:34 *good comments 18:00:37 cgoncalves: ryan is out the rest of the week but let me go through your comments 18:00:40 SumitNaiksatam: yes. better take this discussion to gerrit 18:00:44 i will hound him :-) 18:00:51 cgoncalves: ok 18:01:05 banix: thanks ;) 18:01:12 anyone else want to bring up an technical issue with the traffic steering blueprint? 18:01:17 cgoncalves: np 18:01:19 *any 18:01:37 I think there may be some other folks interested in this BP 18:01:47 not sure, though, if any of them are here 18:01:56 cgoncalves: outside of this subteam? 18:02:18 cgoncalves: the NFV folks, perhaps? 18:02:22 s3wong: yes. NFV team 18:02:39 s3wong: https://wiki.openstack.org/wiki/Meetings/NFV 18:02:51 s3wong: search for "steering", for instance 18:03:03 #action banix pgpus regxboi Kanzhe s3wong kevinbenton hemanthravi LouisF to review https://review.openstack.org/#/c/92477 and provide feedback by end of week 18:03:07 cgoncalves: yeah 18:03:14 cgoncalves: did you attend the NFV meeting? 18:03:26 cgoncalves: you may want to add your bp on the wiki page here #link https://wiki.openstack.org/wiki/Meetings/NFV 18:03:29 or anyone else? 18:03:35 SumitNaiksatam: liking these action items already :) 18:03:35 SumitNaiksatam: I have 18:03:42 I also just got a contact from someone else not in these teams asking for more details 18:03:47 SumitNaiksatam: sounds like a good way of tracking 18:03:49 * SumitNaiksatam hides for cover :-P 18:03:49 SumitNaiksatam: I did 18:04:04 s3wong: it is listed there. check the bottom of second table 18:04:06 cgoncalves: ok good 18:04:08 cgoncalves: that's good. Ask them to join as reviewers :-) 18:04:16 s3wong: nice one 18:04:38 banix: i am happy being the bad guy here 18:04:45 s3wong: sure! 18:04:45 cgoncalves: got it, didn't scroll all down enough. Sorry 18:05:18 cgoncalves: we will have a quick NFV update later, perhaps you can do that 18:05:22 ok flavors 18:05:30 #topic Flavors 18:05:32 SumitNaiksatam: no i think this is a good way of tracking things; when one have an action item you pay more attention; we all want to do the reviews but things get pushed around wrt priority; so i like the approach 18:05:49 banix: exactly 18:05:53 SumitNaiksatam: later this meeting or? 18:05:58 #link https://review.openstack.org/#/c/90070 18:06:06 cgoncalves: yes later in the agenda 18:06:10 enikanorov: ? 18:06:17 here 18:06:22 ok 18:06:29 enikanorov: is there another patch coming? 18:06:40 SumitNaiksatam: you mean spec? 18:06:46 enikanorov: yeah 18:07:02 yes, i think the only remaining question is about tags format 18:07:06 enikanorov: i meant patch set, sorry 18:07:28 my understanding was that with many different requirements it might be more flexible to hae it in a form of string 18:07:34 enikanorov: so who is blocking that? 18:07:55 there was a couple of questions along the way about that 18:08:05 some asked if we need additional model for Tag 18:08:06 enikanorov: ok 18:08:15 and add Tags one by one to Flavor 18:08:24 but I think it's too complex to be usable 18:08:33 enikanorov: i made the comment about there being more structure 18:08:45 nati_ueno: there? 18:08:50 but technically, what kind of structure it could be? 18:09:18 enikanorov: Does the spec define how "supported capabilities" are inputed? 18:09:27 enikanorov: i was just thinking something more than a one single flat string for all the tags and valures 18:09:31 *values 18:09:45 SumitNaiksatam: so what is that 'something'? 18:09:47 enikanorov: i will not block this 18:10:00 enikanorov: something similar to the dict that i was suggesting in the comments 18:10:08 Diff services have diff capability so how do we structure flavor, more likely string format with key values should be Ok 18:10:11 garyduan: "cap_name:cap_value,cap_name2:cap_value2" 18:10:52 That spound perfect provided we know service instace can use them with correct interpretation 18:10:59 enikanorov: what I mean is there is a predefined set of allowed tags that driver can use 18:11:18 garyduan: my earlier suggesting was along similar lines 18:11:31 garyduan: I would be glad if someone could help me with defining that 18:11:53 enikanorov: is there a possibility that two different drivers can have the same capability name and be using them in different ways? 18:11:57 although i'm not sure it shoul be necessarily in flavor API implementation 18:12:27 SumitNaiksatam: that should be avoided. Capabilites are user facing so they create expectations 18:12:34 OK unfortunately unlike nova flavor we do not have fixed mem storage like common absractions fully similar across services 18:12:43 expectations of consistency 18:12:48 pgpus: yes that is the issue 18:13:02 since user doesn't know what implementation he gets, it should be consistent across drivers 18:13:09 enikanorov: but without being prescriptive, it is difficult to be consistent 18:13:22 enikanorov: what these tags are can be figured out later for each services 18:13:24 SumitNaiksatam: please explain? 18:13:28 enikanorov: so who ensures the consistency? 18:13:47 enikanorov: but where to define them. Are they hard-coded in Neutron? 18:13:48 Atleast service_type is common across all falvors 18:13:49 I think deployers/cloud admins should ensure it 18:14:20 enikanorov: but the deployers are different from the entities who develop the drivers 18:14:34 enikanorov: and we are saying that the drivers express their capabilities 18:14:47 If Provider has a different concept from same service_type they should be able to override the service_type\ 18:14:55 yes, they're different. Those who maintain service should ensure that certain feature works similarly in all drivers 18:15:18 also, driver authors should be verbose in defining capabilities supported by their driver 18:15:18 I think what Sumit means is 18:15:32 Operator A may want to have tag X, Y, Z 18:15:44 and B wants tag S, T, W 18:16:20 as vendor driver, which tag set should it expose? 18:16:45 the tag names should be hardcoded unless it's vendor-specific 18:16:55 enikanorov: so essentially, you seem to be saying that at the time of reviewing a driver, we as reviewers should ensure consistency? 18:17:09 * driver code 18:17:19 Every Service_Type should have atleast two or three standard attributes like for for firewall igress, egress and l2 or l3 should be minmum just for exaple sake 18:17:23 enikanorov: so should the hardcoded tag names be part of the spec/API/DB? 18:17:45 yes, I think every driver should implement some feature X such that user would have same experience with it 18:17:45 s3wong: my question too. 18:17:50 So tags S=A has A,B,C ... anything after that 18:17:57 and we as reviewers should ensure that 18:18:06 Service-B has, A,B,C.. anything after that 18:18:13 enikanorov: in that case, can i suggest an evolutionary approach 18:18:20 both S-A & S-B being two implementations of FW 18:18:37 SumitNaiksatam: please explain? 18:18:48 enikanorov: how about we define a module where we note these capability names as they are populated by drivers? 18:18:59 same with LB that may have S-A A,B,C,D ... and any more 18:19:02 SumitNaiksatam: yes, that will work for us 18:19:09 enikanorov: since the problem now seems to be to able to identify these tags at the outset 18:19:13 and S-B A,B.C,D and any thing more 18:19:37 but for a give Service A,B,C or A,BC,D must be common minimum 18:19:40 enikanorov: every new tag name should be added to this capabilites module (like a common constants module) 18:19:58 SumitNaiksatam: yes, something like that 18:20:23 SumitNaiksatam: enikanorov: OK - that makes sense, separate framework from service-type-specific attributes 18:20:24 enikanorov: that way we have the tag (names) all defined in one place, which evolve over time, but we ensure that at least people are aware of what is being used 18:20:42 SumitNaiksatam: agree 18:20:48 SumitNaiksatam: these are hardcoded "common tags or specific to service types" tag, right? 18:20:52 enikanorov: we should also ensure that these tag names are documented when they are populated 18:20:53 OK that looks good so you define a set of constant which are part of standards for that specifc service and rest are optional 18:21:02 pgpus: yes 18:21:13 SumitNaiksatam: ok 18:21:27 enikanorov: to help us maintain consistency 18:21:29 agree 18:21:35 SumitNaiksatam: enikanorov so there is a review process to get a new tag added ? 18:21:35 I am ok with that, that will work 18:21:38 Hi! 18:21:41 #action enikanorov to add notes on tags consistency to blueprint spec 18:21:57 SridarK: common sense? :) 18:22:02 SridarK: that would be part of the review for the driver, enikanorov right? 18:22:10 SumitNaiksatam: sure 18:22:13 nati_ueno: hi, wanted to put you on the spot :-) 18:22:21 SumitNaiksatam: Show time! 18:22:26 nati_ueno: did you get a chance to look at the flavors spec? 18:22:27 enikanorov: SumitNaiksatam yes that will help excess proliferation. 18:22:34 SridarK: I would imagine who ever add their service's flavor support would have to define tags and have them reviewed 18:22:37 nati_ueno: #link https://review.openstack.org/#/c/90070 18:22:52 SumitNaiksatam: I didn't read the latest yet. please let me have a look 18:23:02 s3wong: yes a sort of IANA allocation will keep things sane 18:23:13 nati_ueno: thanks, this is blocker for lots of services’ stuff 18:23:25 SridarK: nice analogy :-) 18:23:27 SridarK: in here we have Neutron core-dev to serve the role :-) 18:23:34 let nati_ueno put another -1 so i could resolve his comments as well :) 18:23:49 :-) 18:24:06 nati_ueno: enikanorov is challenging you to put a +2 i think :-) 18:24:07 So with regards to implementation that is under way, I'd like to put everything that is not yet fully decided - out of the patch 18:24:20 so it only will consist of API and db part (+UTs of course) 18:24:27 enikanorov: he he that challenge is accepted 18:24:30 SumitNaiksatam: eventually, yes :) 18:24:32 enikanorov: makes sense 18:25:05 enikanorov: have we identified people who will work on each service? 18:25:35 SumitNaiksatam: no, i don't think so. garyduan for fwaas, ... ? 18:25:53 SumitNaiksatam: enikanorov himself for LBaaS? That is, once the dust is settled there :-) 18:25:54 i'll gladly help with integration 18:26:04 it's a bit early to say about lbaas 18:26:08 #agreed nati_ueno accepts enikanorov challenge to +2 flavors patch https://review.openstack.org/#/c/90070 18:26:10 after the code sprint - may be! 18:26:10 enikanorov: please also explain in the spec how vendor should expose "specific to vendor" tags 18:26:20 enikanorov: anything not hardcoded? 18:26:35 garyduan: are you doing fwaas? 18:26:36 enikanorov: so optimistic :-) 18:26:39 yes 18:26:43 garyduan: nice 18:26:49 garyduan: vendor exposes to admin, admin decides wether to put those caps into flavors 18:26:54 nati_ueno: what about vpnaas? 18:27:20 enikanorov: ok. 18:27:45 SumitNaiksatam: I think there is nothing special for vpnaas 18:27:51 nati_ueno: ok 18:27:52 accoding to the flavor part 18:28:11 I feel there is more and more vendor paramters in the vpnaas, but it is another issue 18:28:32 may be we should bind flavor and such extended parater for validation .. 18:28:32 ok as a team can we agree to resolve all issues with the flavors spec by next week; i would like to see a bunch of +1s by that time 18:28:47 and i would like to see some +1s to my comment now ;-P 18:29:00 SumitNaiksatam: I’ll be sure to review that one 18:29:00 SumitNaiksatam: +1 18:29:08 rkukura: thanks! 18:29:28 SumitNaiksatam: +1 18:29:34 SumitNaiksatam: +1 18:29:38 +1 18:29:41 +1 18:29:42 sounds good 18:29:45 +1! 18:30:16 SumitNaiksatam: time's up for the meeting, BTW 18:30:26 #action rkukura s3wong SridarK garyduan Kanzhe vinay_yadhav banix nati_ueno SumitNaiksatam to review flavors patch and resolve issues before next weeks meeting 18:30:35 SumitNaiksatam: +1 (just because I'm scare of being haunted by you) 18:30:35 s3wong: yes we are running a little behind 18:30:40 cgoncalves: ha 18:30:47 cgoncalves: you managed to escpat 18:31:00 few more minutes if people are willing to stay 18:31:08 * cgoncalves does the chicken dance 18:31:13 cgoncalves: ha 18:31:16 sumit: TaaS 18:31:17 Sumit Thanks will follow with cg 18:31:21 vinay_yadhav: yes 18:31:37 #topic Tap Service 18:31:40 SumitNaiksatam: let's skip updates on NFV and serviceVM for this week then 18:31:43 we have resolved some comment from previous patch and have got some +1 18:31:56 #link https://review.openstack.org/#/c/96149/ 18:32:01 s3wong: yes 18:32:02 vinay_yadhav: thanks for initiating the spec 18:32:23 vinay_yadhav: nice 18:32:25 vinay_yadhav: have you considered to support one-arm type of service as well 18:32:28 vinay_yadhav: nice work, i do see +1s 18:32:32 We would like to see more reviews so that we can get the spec accepted 18:32:45 vinay_yadhav: sorry, i did not get a chance to review the latest 18:32:45 vinay_yadhav: besides mirroring 18:32:57 vinay_yadhav: any blockers at this point? 18:33:15 garyduan: not as of yet 18:33:21 i dont see any 18:33:56 vinay_yadhav: I will review your spec this weekend. 18:34:03 Kanzhe: thanks 18:34:06 Kanzhe: Thanks 18:34:23 #action SumitNaiksatam Kanzhe garyduan to review https://review.openstack.org/#/c/96149/ 18:34:42 cool thanx 18:34:50 Thanks 18:35:00 vinay_yadhav: I will add comments on the spec 18:35:08 i dont see mandeep, so i will skip service chaining, please respond to the review: https://review.openstack.org/#/c/93524 18:35:18 garyduan: thanx 18:35:19 vinay_yadhav: I will review as well (actually I already added myself as reviewer anyway) 18:35:26 #topic Open Discussion 18:35:37 s3wong: sure 18:35:49 anythin anyone wants to bring up? 18:36:14 i am really hoping that we can get consensus within the team to +1 the specs by next week 18:36:15 SumitNaiksatam: I think jmsoares has something 18:36:25 we can accordingly go to the core reviewers 18:36:31 jmsoares: sure, please go ahead 18:36:43 * SumitNaiksatam appreciates everyone staying longer 18:36:58 about the NFV meeting: apart from logistic stuff, the discussion was focused on 1) Gap analysis (functional), 2) NFV use-cases, and 3) Workload analysis (performance). 18:37:03 * SumitNaiksatam and thanks fwaas team for always being patient 18:37:18 jmsoares: great, thanks for that update 18:37:19 1) What ETSI NFV is defining that doesn't (currently) align with OpenStack. Some members that are in ETSI will try to bring some of the most relevant (to OpenStack) draft documents public. 18:37:28 2) Do a gap analysis focused on NFV use-cases. 18:37:31 jmsoares: any action items for us? 18:37:39 this is all I remember :) 18:37:57 jmsoares: sure, any immediate action items for us? 18:38:00 not really. 18:38:03 SumitNaiksatam: currently some NFV team people (including me) will map NFV requirements to the list of BPs 18:38:05 SumitNaiksatam: no worries 18:38:06 jmsoares: ok 18:38:14 SumitNaiksatam: I will make sure our BPs get prominently featured :-) 18:38:23 s3wong: great, thanks :-) 18:38:31