17:02:44 <ajo_> #startmeeting network-common-flow-classifier
17:02:44 <openstack> Meeting started Tue May 17 17:02:44 2016 UTC and is due to finish in 60 minutes.  The chair is ajo_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:49 <openstack> The meeting name has been set to 'network_common_flow_classifier'
17:02:50 <ajo_> #addchair cathy__
17:02:58 <ajo_> how do you add a chair? :)
17:02:59 <cathy__> ajo_: thanks
17:03:08 <ajo_> #help
17:03:15 <igordcard> .. ? #chair
17:03:23 <ajo_> #chair cathy__
17:03:23 <openstack> Current chairs: ajo_ cathy__
17:03:24 <s3wong> #chair
17:03:27 <ajo_> thanks
17:03:48 <ajo_> cathy__, please chair, I just wanted to take the blame ;)
17:05:01 <cathy__> First I am not thinking running weekly meetings for this feature or creating another stadium for this feature
17:05:07 <cathy__> because
17:05:51 <ajo_> well, IMHO it's something that has to live into the core, to be leveraged by any interested plugin
17:06:06 <cathy__> ajo_: agree
17:06:08 <davidsha> +1
17:06:10 <jlibosva> +1
17:06:11 <ajo_> so, no separate stadium project, I believe that was ihrachys opinion too
17:06:15 <igordcard> +1
17:06:17 <s3wong> +1
17:06:39 <cathy__> I am thinking that we create a bug for the core and a spec for the core and code for the core:-)
17:06:40 <pcarver> +1
17:07:07 <ajo_> cathy__, on the other hand, I believe that may be another weekly/biweekly meeting for a while could be beneficial to run for timelaps
17:07:23 <ajo_> but, that requires finding a good timeslot
17:07:53 <cathy__> ajo_: finding a good time slot and an available channel is the challenge
17:07:58 <ajo_> since all openstack-meeting channels are full for the timeslot we agreed during the summit.
17:08:09 <cathy__> OK let me see if I can find a time slot for biweekly meetings
17:08:13 <amuller> can't you just create a new channel?
17:08:16 <jlibosva> can't we just create another channel?
17:08:30 <amuller> jlibosva: you owe me icecream now I think
17:08:32 <cathy__> amuller: do you know how to create a new channel?
17:08:37 <ajo_> amuller, I raised that once, they told me... it was a bad idea, because that reduces the chances of people being able to join all meetings
17:08:49 <ajo_> amuller, but may be it's time we ask again for it, we have many projects now
17:08:49 <amuller> ajo_: huh? =p
17:08:54 <davidsha> just #join and the channel name, it creates it if it doesn't exist
17:09:06 <ajo_> oh, really?
17:09:06 <s3wong> cathy__: create channel is easy, just do a /join on a channel that doesn't exist on friend
17:09:08 <jlibosva> davidsha: we need the openstack bot there
17:09:10 <amuller> davidsha: I think cathy__ was talking about something supported by infra so it has a bot and it logs the contents
17:09:15 <ajo_> but, we need the meetbot
17:09:27 <s3wong> cathy__: but you have to do the follow-on work to put in openstackgerrit and other bots
17:09:34 <davidsha> jlibosva, amuller: ack
17:09:37 <cathy__> davidsha: cool, so easy?
17:10:08 <davidsha> cathy__: to have a channel yes, to have the openstack bot that will keep logs etc no.
17:10:37 <s3wong> s/friend/freenode
17:10:41 <ajo_> let's try finding a spot for the meeting, and if we fail, let's raise the thing again in openstack-dev
17:10:54 <ajo_> IMHO, it's time to expand the openstack-meeting channel family
17:11:29 <jlibosva> makes sense to me, number of projects grows so channels should grow too
17:11:38 <ajo_> exactly
17:12:03 <ajo_> #action cathy__ look for available slots for a bi-weekly meeting (ajo will look too)
17:12:18 <yamamoto> which timezones people here are in?
17:12:26 <davidsha> <--GMT
17:12:35 <yamamoto> <-- JST (UTC+9)
17:12:37 <igordcard> UTC0/+1 here
17:12:40 <ajo_> me: CEST (UTC+2)
17:12:42 <jlibosva> UTC+2
17:12:50 <davidsha> We have people far sides of the planet, from west coast to japan I believe
17:13:12 <ajo_> yamoto, it's super late for you ':]
17:13:23 <pcarver> EDT/EST UTC-4/5
17:13:27 <ajo_> yamamoto, sorry
17:13:27 * yamamoto halfly sleeping
17:13:32 <ajo_> ':D
17:14:18 <ajo_> oh, we lost cathy__
17:14:50 <ajo_> ok, let's consider that when looking for a  meeting time: nothing will satisfy everyone :/
17:15:05 <ajo_> cathy_, which TZ are you on, we lost you after that question
17:15:10 <cathy_> hi ajo_
17:15:16 <jlibosva> I think she's on west coast
17:15:25 <cathy_> sorry about my bad connection
17:15:29 <davidsha> Ya, it's 9:00AM there I believe
17:15:35 <cathy_> yes
17:15:46 <ajo_> ok, so another count for the stats
17:16:21 <ajo_> so, let's try to find several spots for biweekly, and then we vote on the ML, does that sound reasonable?
17:16:29 <jlibosva> I have a suggestion to find two time slots - one west coast convenient, one far east convenient, and agree on which time it will be via email depending on what's needed to be discussed
17:16:29 <davidsha> +1
17:16:55 * jlibosva feels like repeating others today :)
17:17:21 <ajo_> or we all cry, and stick to email. :)
17:17:22 <cathy_> jlibosva: are you suggesting having two meetings, one for east coast and another fro west coast?
17:17:46 <davidsha> cathy_: I think he means every second meeting.
17:17:48 <jlibosva> cathy_: not regularly though, depending on topic - but might cause difficulties :)
17:18:26 <igordcard> east of the world right? not coast?
17:18:35 <davidsha> igordcard: yup
17:18:38 <ajo_> lol :) yes please
17:18:48 <ajo_> world exist beyond the west and east coast :D
17:18:57 <amuller> ajo_: blasphemy
17:19:03 <ajo_> amuller, lol :)
17:19:29 <jlibosva> yeah, by far east I basically meant yamamoto :)
17:19:31 <cathy_> It could cause difficulty, a better way is via email.
17:19:41 <cathy_> jlibosva: :-)
17:19:47 <ajo_> ok, so can we move on to another topic, and discuss that on the ML?, yes, the alternative (if not right slot found) is email.
17:19:56 <ajo_> emails tend to be slow
17:20:09 <ajo_> cathy_, 20m, shall we move to another topic?
17:20:59 <yamamoto> +1 move on
17:21:03 <davidsha> +1
17:21:25 <ajo_> please note, that related to this (l2-feature-interoperability in OVS) I have put this into review:
17:21:27 <ajo_> #link https://review.openstack.org/#/c/314106/
17:21:39 <ajo_> it's still WIP, but feedback is greatly appreciated
17:22:06 <ajo_> specially from the SFC experts, to make sure that SFC could fit into it ( pcarver / cathy_ )
17:22:40 <ajo_> I suspect cathy_ fell off again ;)
17:22:43 <ajo_> -----
17:22:43 <pcarver> ajo_: I'll take a look at it
17:22:49 <ajo_> thanks pcarver
17:23:22 <cathy__> sorry don't know why my internet connection is so bad today.
17:23:26 <ajo_> cathy_, I was asking folks to review https://review.openstack.org/#/c/314106/ (related effort to make lots of features compatible in OF)
17:23:35 <pcarver> I think the next step on flow classifier is to make a list of matching parameters beyond what SFC currently has
17:23:42 <openstackgerrit> Ryan Tidwell proposed openstack/neutron: Compute IPAvailabilityRanges in memory during IP allocation  https://review.openstack.org/292207
17:23:51 <igordcard> pcarver: +1
17:24:01 <pcarver> One that's going to require some thought is "direction"
17:24:17 <ajo_> pcarver, that's not necessarily part of a flow classifier IMHO
17:24:18 <cathy__> pcarver: we already have an initial comparison.
17:24:32 <ajo_> it can be part of SG, but not part of a flow
17:24:33 <igordcard> ajo_: my thought too
17:24:45 <ajo_> for example, in the context of QoS, we couldn't use a FC with direction
17:24:53 <ajo_> since that's already given by the QoS rule itself
17:24:54 <cathy__> ajo_: I agree with you. I think we'd better keep SG separate from FC
17:25:29 <cathy__> how about we go through the topics listed in the wiki page since one of the topic is the comparison table
17:25:35 <ajo_> SG-rule could be modeled as <sg-group, direction, flow-classifier> eventually...
17:26:02 <ajo_> but that, if we wanted to modify how security groups are internally designed, to optimize how we code neutron
17:26:11 <igordcard> the way I see, common classifier should focus on supporting the classifications themselves, not how you use them (e.g. taking into account directionality)
17:26:13 <ajo_> cathy__, link to wiki?
17:26:21 <ajo_> igordcard: +1
17:26:39 <jlibosva> https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier
17:26:45 <jlibosva> ajo_: ^^
17:26:50 <cathy__> https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier
17:26:56 <ajo_> #link https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier
17:27:01 <ajo_> thanks jlibosva , cathy__
17:27:16 <cathy__> #topic Develop this as a bug fix in Neutron or separate stadium project
17:27:36 <ajo_> ok, we already agreed on that,
17:27:40 <cathy__> I think we already have consensus here. we will develop this as a bug fix with a spec for approval, right?
17:27:41 <ajo_> this is an RFE over neutron-core,
17:27:53 <ajo_> we need to convince the drivers that this is the right thing
17:28:28 <cathy__> #agreed develop FC as a RFE over neutron-core
17:28:39 <ajo_> cathy__, we have to follow the standard process -> RFE, and once approved we can create a spec (or we can create the spec, but no blueprint until it's approved, that's done by drivers)
17:29:10 <cathy__> by drivers you mean neutron-driver team?
17:29:15 <ajo_> correct
17:29:19 <yamamoto> who's going to file rfe?
17:29:20 <cathy__> sure
17:29:20 <davidsha> cathy__: It will need to be updated to make it a common classifier but would this do? https://bugs.launchpad.net/neutron/+bug/1527671
17:29:21 <openstack> Launchpad bug 1527671 in neutron "[RFE] traffic classification in Neutron QoS" [Wishlist,Incomplete]
17:29:29 <cathy__> I will file the rfe
17:29:38 <ajo_> davidsha, no, we should not reuse that one,
17:29:43 <yamamoto> cathy__: thank you
17:29:45 <ajo_> davidsha, that one would be dependent on the new one
17:29:49 <cathy__> davidsha: that is the second topic in the wiki
17:29:59 <cathy__> #topic Use existing QoS bug https://bugs.launchpad.net/neutron/+bug/1527671 or creating a new one
17:30:05 <ajo_> cathy__, nope please
17:30:10 <ajo_> it should be a different one
17:30:13 <davidsha> ajo_: ack
17:30:20 <cathy__> ajo_: +1
17:30:22 <ajo_> this one talks about implementing it for QoS (once classifiers are available)
17:30:28 <igordcard> +1 different RFE, since the existing is scoped to QoS
17:30:29 <cathy__> ajo_: agree
17:30:34 <ajo_> thanks :)
17:30:41 <cathy__> so I will submit a new one
17:30:47 <ajo_> thank you cathy__
17:30:59 <ajo_> #action cathy__ submit a new RFE for traffic classifiers in neutron-core
17:31:06 <ajo_> #undo
17:31:06 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0xa7dfb50>
17:31:16 <ajo_> #action cathy__ submit a new RFE for flow classifiers in neutron-core
17:31:18 <cathy__> #action Cathy submit a new RFE for traffic classifiers in neutron-core
17:31:20 <ajo_> I stick to old names, sorry :D
17:31:27 <cathy__> ajo_: np
17:31:28 <ajo_> lol, ok :)
17:31:31 <cathy__> now next topic
17:31:45 <cathy__> #topic Discussion on the comparison table
17:32:39 <ajo_> it looks like sfc flow classifiers are a superset of security groups, with only the difference of direction
17:32:40 <cathy__> the wiki page has the comparison table. But we have agreed to keep SG separate. So what we need to take a look at is the common FC column
17:32:57 <igordcard> CC?
17:33:08 <ajo_> l7 parameters is fuzzy
17:33:18 <ajo_> I would avoid that until that's clearly defined,
17:33:37 <cathy__> ajo_: we need to explicitly expand and define the L7 param
17:33:43 <ajo_> one thing that is generally not accepted, is a dictionary with "any fields"
17:34:05 <igordcard> the CC column has some good examples of classification fields, I'm just a bit uneasy about the l7 params and the src/dst logical ports
17:34:17 <ajo_> cathy__, then we will need to find a way to model that (beyond a dictionary) l7_parameters looks like a dictionary
17:34:50 <igordcard> the former because it's open ended, as ajo_ is saying, and the latter ones because they aren't really classifying traffic, but rather scoping where it can come from
17:34:53 <cathy__> igordcard: l7param is a placeholder for defining in parameters such as subscriber ID, URL etc.
17:35:30 <ajo_> cathy__, those will need to be added later to the model, when they are defined
17:36:02 <ajo_> cathy__, you can try that fight, but it will not work. Setting "bags of things" as API parameters, or as part of a DB model, is generally a no-go from drivers
17:36:10 <cathy__> igordcard: src/dst logical port means neutron port which allow the user to specify a traffic flow based on src neutron port and dst neutron port
17:36:26 <igordcard> can I have your thoughts on something like this for a CC classification: type and definition, e.g.: type: tcp; definition: {src_port: 80; dst_port: 80}
17:36:29 <ajo_> igordcard, I don't see the issue on dst/src port
17:37:00 <ajo_> on a given packet, dst & src port will always be present
17:37:05 <ajo_> (udp / tcp)
17:37:06 <cathy__> ajo_: do we want to define some L2 param explicitly now to show how other l7 param can be defined in the future?
17:37:43 <cathy__> I mean L7, not l2
17:37:47 <igordcard> cathy__: ajo_ , to me src/dst/port looks a bit like the direction, something not really about the traffic itself and probably not relevant to many projects
17:37:51 <ajo_> cathy__, we define lots of them, or am I missing something ? Inner vlan, Outer vlan, etc...
17:38:32 <ajo_> igordcard, you can just filter on "dst" port on your project
17:38:33 <sc68cal> why do inner and outer vlans need to be parameters
17:38:43 <cathy__> ajo_: by L7, what we mean here is param in the app layer such as subscriber ID, URL, not vlan.
17:39:03 <ajo_> cathy__, sorry, you said "L2" above ^ :) that's why I was talking of vlan :)
17:39:04 <igordcard> the message I sent to cathy__ and ajo_ is about the neutron ports, we can discuss that one after
17:39:17 <sc68cal> like why are we baking QinQ directly into a REST API
17:39:24 <cathy__> ajo_: sorry, I mean L7
17:39:29 <ajo_> cathy__, you could provide some l7 example may be, yes
17:39:47 <ajo_> cathy__, from the QoS point of view, those would probably be unsupported.
17:39:50 <igordcard> the other one is about having the ability to specify in the classifier, what protocol we want and then what fields we want to match for that protocol
17:40:01 <cathy__> ajo_: OK, lee me modify the L7 part and update the wiki
17:40:08 <igordcard> instead of a fixed list of fields that we can match, some about IP, others about neutron ports, others about L7, etc
17:40:26 <cathy__> ajo_: it is OK not to support them since they are not mandatory
17:41:06 <ajo_> cathy__, how does SFC plan to handle L7 ?
17:41:34 <ajo_> can that be inspected by regular openflow rules?
17:41:41 <cathy__> ajo_: good question. Let me think about how to reply
17:42:21 <ajo_> cathy__, but if that's still TBD, I'd say, let's go in baby steps, tackle what makes sense now, and expand later (as long as the long-term plan is clear)
17:42:36 <cathy__> to classify flow up to L7 granularity level, I think we need a DPI device to look into the l7 fields
17:42:46 <cathy__> ajo_: agree
17:42:56 <igordcard> ajo_: but keeping in mind that it's harder to change something like this later on
17:43:20 <cathy__> in the spec we should touch the long term plan and future extension.
17:43:21 <ajo_> igordcard, yes, that's true
17:43:25 <ajo_> yes
17:43:31 <ajo_> that should be clear and thought
17:43:47 <yamamoto> dpi==deep packet inspection?
17:44:10 <ajo_> yamamoto, that's what I suspected... :)
17:44:15 <cathy__> igordcard: do you mean we should have a place holder for L7 otherwise it is hard to add it later on?
17:44:20 <cathy__> yamamoto: yes
17:44:39 <ajo_> igordcard, not necessarily a placeholder, but a plan.
17:44:59 <igordcard> cathy__: well, it would be nice to get the CC (api), or at least its basic foundation, right
17:45:00 <ajo_> thought on how will we extend to L7, and how will features integrate to that
17:45:11 <ajo_> since some of them may not support such a thing as L7 support
17:46:01 <igordcard> type: l7; def: {app-id: "ID"; subscriber-id: "SID"} or something like that?
17:46:07 <irenab> I guess it should be possible to query the backend what flow classifier can be supported
17:46:39 <ajo_> irenab, or the backend can refuse to take a flow classifier if it's not being supported
17:46:44 <cathy__> igordcard: +1
17:46:46 <ajo_> by the specific backend
17:46:52 <igordcard> or, type: h264; def: {resolution: "1080p"}
17:47:10 <irenab> ajo_: yes, depends what kind of user experinece this will provide
17:47:24 <ajo_> irenab, but that would also mean that updating the FC should check with the backend,
17:47:29 <ajo_> or... that updates should not be allowed
17:47:35 <igordcard> and for well known non-l7 params, something like: type: ethernet; def: {src_addr: "00:00:00:00:00:00"; (and others if needed)}
17:47:44 <irenab> ajo_: the later is easier :-)
17:47:57 <ajo_> irenab, we know that pain (QoS, yes...)
17:48:31 <ajo_> but I guess that's the sort of detail we can talk about on the spec/rfe
17:49:30 <ajo_> sadly, I have to disconnect, please go on, cathy__ please make sure you #endmeeting once finished
17:49:36 <ajo_> #chair yamamoto
17:49:37 <openstack> Current chairs: ajo_ cathy__ yamamoto
17:49:40 <ajo_> #chair jlibosva
17:49:41 <openstack> Current chairs: ajo_ cathy__ jlibosva yamamoto
17:49:42 <ajo_> for just in case
17:50:00 <ajo_> so we don't leave a hanging meeting in the channel
17:50:05 <jlibosva> ack
17:51:08 <cathy_> hi
17:51:22 <jlibosva> cathy_: ajo_ had to disconnect
17:51:29 <yamamoto> i guess we've already mostly done
17:52:07 <igordcard> bye ajo_ if you're still around
17:52:10 <cathy_> jlibosva: yamamoto could you let me know what I missed due to disconnection?
17:52:34 <yamamoto> cathy_: which is the last message you saw?
17:52:37 <igordcard> cathy_: you can always look back at the meeting, during the meeting, here: http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.log.txt
17:53:03 <jlibosva> cathy_: basically that we can discuss details in the rfe
17:54:05 <cathy_> Ok, sounds good.
17:54:33 <openstackgerrit> Ilya Chukhnakov proposed openstack/neutron: Call ext_manager.delete_port on port removal  https://review.openstack.org/317655
17:55:13 <cathy_> Thanks everyone. Let's communicate via emails if needed. I will work on the bug and the spec.
17:55:32 <cathy_> that might take some time :-)
17:55:43 <cathy_> I will end the meeting now
17:55:46 <davidsha> Thanks
17:55:48 <jlibosva> thanks!
17:55:49 <yamamoto> thank you
17:55:50 <jlibosva> bye
17:55:52 <igordcard> cathy_: yes we can then discuss more details and what path to take in the final classification structure
17:55:55 <igordcard> bye bye
17:56:03 <s3wong> bye
17:56:05 <davidsha> good morning and good night where appropriate!
17:56:06 <s3wong> thanks
17:56:07 <irenab> bye
17:56:14 <cathy_> igordcard: sure. I like your suggestion on the L7 param
17:56:28 <cathy_> #endmeeting
17:56:41 <jlibosva> #endmeeting