14:02:40 #startmeeting network_common_flow_classifier 14:02:41 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:45 The meeting name has been set to 'network_common_flow_classifier' 14:03:45 Hi 14:04:15 hi davidsha, all 14:04:35 agenda: 14:04:40 https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_22_August_2017 14:04:46 #topic CCF v0 - first wave of code (update) 14:05:33 Myself and Thaynara are working on Unit tests for the Service plugin at the moment. 14:06:25 We're also working on addressing bcafarel comments on the patchset about tenant_id problems. 14:06:51 davidsha: great 14:07:26 https://review.openstack.org/#/c/487182/1/neutron_classifier/db/models.py 14:07:31 right? 14:08:42 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 The Database migration code will be the first to be moved into it's own patch. 14:09:33 good stuff 14:10:06 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 hi everyone, sorry for joining late 14:10:26 hey tmorin, long time no see! 14:10:26 tmorin: welcome, no problem. 14:11:00 igordc: I'm hoping the smaller patches will help make that milestone. 14:11:37 great, tmorin any questions about the state of the code? 14:12:13 I just came to catch up 14:12:27 very well, let's mve on 14:12:35 #topic PTG update 14:12:36 I saw the v0 patch, haven't had time to have a look yet 14:12:54 Thaynara and davidsha will push a new patch soon 14:13:17 so about the PTG... davidsha you're likely not going there either correct? 14:14:30 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 davidsha: right, so neither of us going, so it will be a bit more difficult to engage on brainstorming discussions 14:15:27 tmorin are you going to the PTG? 14:17:09 https://etherpad.openstack.org/p/neutron-queens-ptg 14:17:47 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 igordc: yes, I'll be in Denver 14:18:26 I say we can still do a good deal of the work via the mailing list 14:18:44 I can put it on my list and be there to talk CCF with whoever would like to 14:18:59 the most important part is that the CCF provides the plugging points and supports the protocols/fields that consuming services want 14:19:36 I'll be on vacation but might join the etherpads just to follow and ask questions 14:20:08 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 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 I can take the action of starting this discussion in Denver 14:21:09 we need to identify who of "consuming services" will be there 14:21:28 I wont be there so I will check virtually 14:21:30 tmorin: Thanks. 14:21:39 reedip_: so that would be these three and someone from fwaas ? 14:21:52 all three are from fwaas tmorin 14:22:39 pcarver from SFC was heavily involved back in Atlanta if I remember correctly. 14:22:39 great tmorin thanks 14:23:27 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 and hi reedip_ 14:23:48 hi igordc 14:24:23 reedip_: ok! 14:25:40 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 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 awesome davidsha, that's great 14:28:06 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 davidsha: the dragonflow one was related to fwaas wasn't it? 14:29:30 igordc: I can't recall off the top of my head. 14:30:24 tmorin: you mentioned at the PTG about using BGP resources as classifications to be consumed by SFC or am I mistaken? 14:31:05 davidsha: yes, but the good solution to the target problem may end up being different 14:31:51 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 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 tmorin: as a source bgpvpn it looks OK to be put in a classification 14:33:15 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 tmorin: as a destination, not really 14:34:23 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 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 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 tmorin: the problem is that networking-sfc manages classifying the traffic... and port-chains require classifications 14:37:26 tmorin: this could be done, but look like a workaround from networking-sfc's perspective 14:37:30 looks* 14:37:40 (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 let me just switch topic btw 14:38:00 #topic Open discussion 14:38:08 igordc: ok, perhaps this needs more thinking 14:39:38 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 tmorin: so either bgpvpn or sfc will 14:40:29 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 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 or sfc classification is bypassed and instead executed by bgpvpn (plus instantiating the bgpvpns and consuming from the CCF) 14:41:39 given the delegation mentioned above, the second option would be natural (I think) 14:42:29 the bgpvpn driver then simply needs to push the classified traffic to the ports of the first ingress port-pair 14:42:30 tmorin: and you'd then be able to route the matching packets to the first SF of the port chain right? 14:42:41 exactly 14:42:45 yes :) 14:43:25 I think this is a discussion between bgpvpn and sfc then 14:44:00 and from the conclusions we can know whether bgpvpn classication type is required 14:44:22 that makes sense 14:45:50 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 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 checking 14:46:42 davidsha : yep 14:46:54 but I found that this is only for the iptables implementation 14:47:26 But if we have nftables or any other implementation, then the protocol list might change, isnt it? 14:48:23 reedip_: not sure 14:48:35 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 reedip_: do you know if SCTP is actually used in neutron? 14:49:09 igordc : its in the neutron_lib/constants, right ? 14:49:33 Yup, It's there 14:49:50 reedip_: yes, but I don't see any actual use either there or in /neutron 14:49:56 reedip_: perhaps some stadium project 14:49:59 same goes for DCCP 14:50:19 well : https://github.com/openstack/neutron/blob/7c1e21a3f35e80e176dfc025eb6f4a0024cb137c/neutron/agent/linux/iptables_firewall.py#L643 14:50:42 reedip_: alright indirectly via IPTABLES_PROTOCOL_MAP 14:50:51 yes ... 14:51:31 reedip_: but I still don't see protocol-specific work 14:51:31 So there are 22 in that list of protocols and we have 5 of them in Version 0 14:52:00 reedip_: at least for classification purposes 14:52:08 igordc : I can only find the implementation and usage of the protocols in 5 places 14:52:10 http://codesearch.openstack.org/?q=IPTABLES_PROTOCOL_MAP&i=nope&files=&repos= 14:52:32 seems that it is only used in iptables_firewall.py 14:52:38 reedip_: yep got the same in github 14:52:57 so unless we have a separate agent, iptables will work well with the following 5 protocols 14:53:25 But yes, DCCP and SCTP wont be useful in generic terms 14:53:43 so you can avoid it. Maybe you can keep a list of Necessary protocols and additional protocols 14:53:57 the Necessary Protocols may have TCP, UDP , ICMP ICMPv6 14:54:10 while the additional protocols can be dependent on the consumer of the CCF 14:54:10 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 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 unless someone really wants to contribute those protocols, I'm fine with that 14:55:11 tmorin: but are they compatible with any neutron API extension? 14:55:45 I know that at least SCTP is important for Telco NFV application related to the historic phone system (SS7) 14:55:45 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 tmorin: ohh that :p 14:56:13 igordc: I don't get your question 14:56:18 igordc: :D 14:56:47 now I amm confused 14:56:50 :) 14:56:54 tmorin: in other words, are these protocols actually going to be object of a consumed Classification? 14:57:32 yes, they can: for instance, you could want to open only a given SCTP port range 14:57:50 + reedip_ 14:57:50 we can continue offline, time's about to run out 14:57:50 I'd just like to introduce you to Thaynara , who's been co-authoring the code with David 14:58:08 hi Thaynara 14:58:13 saw the patch 0 version 14:58:15 similarly: direct a given SCPT port range into a chain, apply QoS profiles distinctively depending on SCTP port, etc. 14:58:24 Hi guys 14:58:33 hi ! 14:58:57 tmorin: I understand, do you know of any neutron project doing it? 14:59:29 I am fortunate enough to hear daily discussions about the CCF from these 2 hehe 14:59:32 I haven't checked 14:59:39 FWaaS would be using it soon ... but otherswise not enough consumers 15:00:00 reedip_: hmm OK so some potential there 15:00:04 aright, time's up 15:00:06 bye all! 15:00:09 #endmeeting