14:02:40 <igordc> #startmeeting network_common_flow_classifier
14:02:41 <openstack> Meeting started Tue Aug 22 14:02:40 2017 UTC and is due to finish in 60 minutes.  The chair is igordc. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:45 <openstack> The meeting name has been set to 'network_common_flow_classifier'
14:03:45 <davidsha> Hi
14:04:15 <igordc> hi davidsha, all
14:04:35 <igordc> agenda:
14:04:40 <igordc> https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_22_August_2017
14:04:46 <igordc> #topic CCF v0 - first wave of code (update)
14:05:33 <davidsha> Myself and Thaynara are working on Unit tests for the Service plugin at the moment.
14:06:25 <davidsha> We're also working on addressing bcafarel comments on the patchset about tenant_id problems.
14:06:51 <igordc> davidsha: great
14:07:26 <igordc> https://review.openstack.org/#/c/487182/1/neutron_classifier/db/models.py
14:07:31 <igordc> right?
14:08:42 <davidsha> igordc: Thats the one, We're also going to break off some pieces of this patch into other patches to make it more digestible and easier to review.
14:09:15 <davidsha> The Database migration code will be the first to be moved into it's own patch.
14:09:33 <igordc> good stuff
14:10:06 <igordc> davidsha: can we still make it before pike is released? (not that it's too important, but would be a good milestone to sync with)
14:10:15 <tmorin> hi everyone, sorry for joining late
14:10:26 <igordc> hey tmorin, long time no see!
14:10:26 <davidsha> tmorin: welcome, no problem.
14:11:00 <davidsha> igordc: I'm hoping the smaller patches will help make that milestone.
14:11:37 <igordc> great, tmorin any questions about the state of the code?
14:12:13 <tmorin> I just came to catch up
14:12:27 <igordc> very well, let's mve on
14:12:35 <igordc> #topic PTG update
14:12:36 <tmorin> I saw the v0 patch, haven't had time to have a look yet
14:12:54 <igordc> Thaynara and davidsha will push a new patch soon
14:13:17 <igordc> so about the PTG... davidsha you're likely not going there either correct?
14:14:30 <davidsha> igordc: Ya, my travel approval was rejected unfortunately, I'm going to see if there is an appeal, but we're too close now for that to be viable.
14:15:20 <igordc> davidsha: right, so neither of us going, so it will be a bit more difficult to engage on brainstorming discussions
14:15:27 <igordc> tmorin are you going to the PTG?
14:17:09 <igordc> https://etherpad.openstack.org/p/neutron-queens-ptg
14:17:47 <igordc> I had a CCF topic for the PTG, mainly to talk about what v1 has to have and to start/accelerate dev of consuming services
14:17:53 <tmorin> igordc: yes, I'll be in Denver
14:18:26 <igordc> I say we can still do a good deal of the work via the mailing list
14:18:44 <tmorin> I can put it on my list and be there to talk CCF with whoever would like to
14:18:59 <igordc> the most important part is that the CCF provides the plugging points and supports the protocols/fields that consuming services want
14:19:36 <igordc> I'll be on vacation but might join the etherpads just to follow and ask questions
14:20:08 <reedip_> I added FwaaS team, and I think xgerman or SridarK would be discussin the same with you. I will also ping yushiro for this
14:20:23 <davidsha> tmorin: If you could that would be great, as igordc mentioned it's the protocols services need and make sure the plug points work
14:20:52 <tmorin> I can take the action of starting this discussion in Denver
14:21:09 <tmorin> we need to identify who of "consuming services" will be there
14:21:28 <reedip_> I wont be there so I will check virtually
14:21:30 <davidsha> tmorin: Thanks.
14:21:39 <tmorin> reedip_: so that would be these three and someone from fwaas ?
14:21:52 <reedip_> all three are from fwaas tmorin
14:22:39 <davidsha> pcarver from SFC was heavily involved back in Atlanta if I remember correctly.
14:22:39 <igordc> great tmorin thanks
14:23:27 <igordc> davidsha: yes, I don't see his name on the etherpad but he might go, I'll check with him on the sfc meeting
14:23:38 <igordc> and hi reedip_
14:23:48 <reedip_> hi igordc
14:24:23 <tmorin> reedip_: ok!
14:25:40 <igordc> cool if you all can please socialize the ccf, and write down all the missing gaps and proposed directions, that would be awesome... I'll try to check the etherpad and IRC
14:26:54 <davidsha> I have seen the drivers propose the use of CCF for a few RFEs already, so I can try and find the RFE authors and sync with them.
14:27:36 <igordc> awesome davidsha, that's great
14:28:06 <davidsha> One was for Security groups and the other may have been DragonFlow, I'll talk to mlavelle about it and see what they were planning.
14:29:05 <igordc> davidsha: the dragonflow one was related to fwaas wasn't it?
14:29:30 <davidsha> igordc: I can't recall off the top of my head.
14:30:24 <davidsha> tmorin: you mentioned at the PTG about using BGP resources as classifications to be consumed by SFC or am I mistaken?
14:31:05 <tmorin> davidsha: yes, but the good solution to the target problem may end up being different
14:31:51 <tmorin> the problem is : how to specify in some API that we want the traffic from a given BGPVPN and matching a given classifier, to be put into an SFC port chain
14:32:29 <tmorin> having a "source BGPVPN" in the classifier could have been a solution, but we ended up concluding it was not a good one when discussing the CCF spec
14:33:08 <igordc> tmorin: as a source bgpvpn it looks OK to be put in a classification
14:33:15 <tmorin> my current thinking is that the best would be to extend the BGPVPN API to associate a (Common Flow Classifier ID, SFC port-chain ID) tuple to indicate that the traffic from this BGPVPN matching the classifier should go into the chain.
14:33:20 <igordc> tmorin: as a destination, not really
14:34:23 <tmorin> igordc: right for source vs. dest, but we (you, me, ihar) ended up concluding we should add that and rely instead on the consuming service API to combine a CCF with its own resources
14:35:08 <igordc> tmorin: OK so in your current thinking, bgpvpn's users would still use the CCF but no changes in SFC would be needed (only in bgpvpn)
14:36:02 <tmorin> igordc: yes, and only the port-chain and CCF APIs would be used (not the current SFC classifier API, nor an extension of it)
14:36:41 <igordc> tmorin: the problem is that networking-sfc manages classifying the traffic... and port-chains require classifications
14:37:26 <igordc> tmorin: this could be done, but look like a workaround from networking-sfc's perspective
14:37:30 <igordc> looks*
14:37:40 <tmorin> (for ref, the discussion I'm referring to was: https://review.openstack.org/#/c/333993/15/specs/pike/common-classification-framework.rst@319 )
14:37:51 <igordc> let me just switch topic btw
14:38:00 <igordc> #topic Open discussion
14:38:08 <tmorin> igordc: ok, perhaps this needs more thinking
14:39:38 <igordc> tmorin: I have to re-read the flow of arguments, including mine, but one thing is still clear I think: that the CCF doesn't actually classify
14:39:49 <igordc> tmorin: so either bgpvpn or sfc will
14:40:29 <igordc> we then have the 2 options you mentioned today: sfc classifies based on 2+ classification types from the CCF (while bgpvpn only instantiates the bgpvpns)
14:40:40 <tmorin> igordc: yes (to be exact in the case of bgpvpn, we delegate the actual classifiction of packet to BGP VPN routers thanks to BGP FlowSpec VPN routes)
14:41:02 <igordc> or sfc classification is bypassed and instead executed by bgpvpn (plus instantiating the bgpvpns and consuming from the CCF)
14:41:39 <tmorin> given the delegation mentioned above, the second option would be natural (I think)
14:42:29 <tmorin> the bgpvpn driver then simply needs to push the classified traffic to the ports of the first ingress port-pair
14:42:30 <igordc> tmorin: and you'd then be able to route the matching packets to the first SF of the port chain right?
14:42:41 <igordc> exactly
14:42:45 <tmorin> yes :)
14:43:25 <igordc> I think this is a discussion between bgpvpn and sfc then
14:44:00 <igordc> and from the conclusions we can know whether bgpvpn classication type is required
14:44:22 <tmorin> that makes sense
14:45:50 <igordc> your last option also looks better to my own subjective perception, but am just a bit concerned with the scope of networking-sfc then, seeing as the classification-part is bypassed
14:46:24 <davidsha> reedip_: you linked this before I think, this is the list of protocols for security groups correct? https://github.com/openstack/neutron-lib/blob/99d4f1f35f8d915f48bfaa677f690b29bc4b0dbe/neutron_lib/constants.py#L202
14:46:37 <reedip_> checking
14:46:42 <reedip_> davidsha : yep
14:46:54 <reedip_> but I found that this is only for the iptables implementation
14:47:26 <reedip_> But if we have nftables or any other implementation, then the protocol list might change, isnt it?
14:48:23 <igordc> reedip_: not sure
14:48:35 <davidsha> reedip_: Well the backend doesn't really matter to us, it's just supporting the classification definitions that already exist in  Security Groups is what I'm thinking.
14:48:40 <igordc> reedip_: do you know if SCTP is actually used in neutron?
14:49:09 <reedip_> igordc : its in the neutron_lib/constants, right ?
14:49:33 <davidsha> Yup, It's there
14:49:50 <igordc> reedip_: yes, but I don't see any actual use either there or in /neutron
14:49:56 <igordc> reedip_: perhaps some stadium project
14:49:59 <igordc> same goes for DCCP
14:50:19 <reedip_> well : https://github.com/openstack/neutron/blob/7c1e21a3f35e80e176dfc025eb6f4a0024cb137c/neutron/agent/linux/iptables_firewall.py#L643
14:50:42 <igordc> reedip_: alright indirectly via IPTABLES_PROTOCOL_MAP
14:50:51 <reedip_> yes ...
14:51:31 <igordc> reedip_: but I still don't see protocol-specific work
14:51:31 <davidsha> So there are 22 in that list of protocols and we have 5 of them in Version 0
14:52:00 <igordc> reedip_: at least for classification purposes
14:52:08 <reedip_> igordc : I can only find the implementation and usage of the protocols in 5 places
14:52:10 <reedip_> http://codesearch.openstack.org/?q=IPTABLES_PROTOCOL_MAP&i=nope&files=&repos=
14:52:32 <reedip_> seems that it is only used in iptables_firewall.py
14:52:38 <igordc> reedip_: yep got the same in github
14:52:57 <reedip_> so unless we have a separate agent, iptables will work well with the following 5 protocols
14:53:25 <reedip_> But yes, DCCP and SCTP wont be useful in generic terms
14:53:43 <reedip_> so you can avoid it. Maybe you can keep a list of Necessary protocols and additional protocols
14:53:57 <reedip_> the Necessary Protocols may have TCP, UDP , ICMP  ICMPv6
14:54:10 <reedip_> while the additional protocols can be dependent on the consumer of the CCF
14:54:10 <tmorin> igordc: people are using protocols other than UDP or TCP out there, hence protos such as SCTP just need to be supported
14:54:18 <igordc> right, I'd like to have more information about the need of certain protocols before anyone commits to work on their support in the CCF, otherwise we might just be wasting time
14:54:42 <igordc> unless someone really wants to contribute those protocols, I'm fine with that
14:55:11 <igordc> tmorin: but are they compatible with any neutron API extension?
14:55:45 <tmorin> I know that at least SCTP is important for Telco NFV application related to the historic phone system (SS7)
14:55:45 <igordc> tmorin: or do they just have to be compatible with the backends that might be receiving, as an example, SCTP and DCCP traffic from VMs
14:56:10 <igordc> tmorin: ohh that :p
14:56:13 <tmorin> igordc: I don't get your question
14:56:18 <tmorin> igordc:  :D
14:56:47 <reedip_> now I amm confused
14:56:50 <reedip_> :)
14:56:54 <igordc> tmorin: in other words, are these protocols actually going to be object of a consumed Classification?
14:57:32 <tmorin> yes, they can: for instance,  you could want to open only a given SCTP port range
14:57:50 <igordc> + reedip_
14:57:50 <igordc> we can continue offline, time's about to run out
14:57:50 <igordc> I'd just like to introduce you to Thaynara , who's been co-authoring the code with David
14:58:08 <reedip_> hi Thaynara
14:58:13 <reedip_> saw the patch 0 version
14:58:15 <tmorin> similarly: direct a given SCPT port range into a chain, apply QoS profiles distinctively depending on SCTP port, etc.
14:58:24 <Thaynara> Hi guys
14:58:33 <tmorin> hi !
14:58:57 <igordc> tmorin: I understand, do you know of any neutron project doing it?
14:59:29 <igordc> I am fortunate enough to hear daily discussions about the CCF from these 2 hehe
14:59:32 <tmorin> I haven't checked
14:59:39 <reedip_> FWaaS would be using it soon ... but otherswise not enough consumers
15:00:00 <igordc> reedip_: hmm OK so some potential there
15:00:04 <igordc> aright, time's up
15:00:06 <igordc> bye all!
15:00:09 <igordc> #endmeeting