17:00:05 <LouisF> #startmeeting service_chaining 17:00:10 <openstack> Meeting started Thu May 25 17:00:05 2017 UTC and is due to finish in 60 minutes. The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:14 <openstack> The meeting name has been set to 'service_chaining' 17:00:21 <LouisF> hi all 17:00:24 <mohankumar> Hi 17:00:38 <vks1> hello 17:00:45 <LouisF> mohankumar: hi 17:00:48 <LouisF> vks1: hi 17:00:58 <LouisF> #topic agenda 17:01:04 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.285.2F25.2F2017.29 17:01:27 <LouisF> #topic CLI in python-neutronclient 17:01:44 <LouisF> https://review.openstack.org/#/c/409759/ 17:01:55 <LouisF> mohankumar: what is current status? 17:02:04 <mohankumar> LouisF , Sorry for the delay in patch update. Working on UT . Will update soon. 17:02:15 <LouisF> mohankumar: ok thanks 17:02:39 <LouisF> #topic API reference 17:03:14 <LouisF> pcarver: work in progress? 17:04:19 <LouisF> doonhammer: hi 17:04:28 <doonhammer> Hi LouisF 17:04:43 <LouisF> #topic Pike work 17:05:34 <LouisF> #topic Tap SF 17:05:35 <LouisF> https://review.openstack.org/#/c/449954/ 17:05:55 <LouisF> vks1: what is status? 17:07:04 <vks1> LouisF: I think its for review , the nly pending thing from my side is to add couple of UTs in OVS agent side 17:08:14 <vks1> need to get reviewed 17:08:31 <LouisF> vks1: can you explain the ConsecutiveTAPPPGNotSupported? 17:08:45 <LouisF> why is this a restriction? 17:09:08 <vks1> the problem is there is single source and multiple destination 17:09:41 <vks1> which has real big problem of classifying traffic 17:11:27 <vks1> think about the case where we have multiple TAP on the same compute as src node and others at different compute. There is problem in classification to send same packet to these many TAPs with same packet attribute 17:11:30 <LouisF> the current classifier for portchains handles that - why is it different if the PPG has tap enabled? 17:12:41 <vks1> TAP differs from default SF insertion because TAP recieves original pkt against the rewritten dest mac in case of default insertion 17:14:02 <vks1> in default the destination mac always points to destination SF bt that's not the case with TAP , pkt reaching to TAP SF has address of original/intended destination 17:15:53 <LouisF> vks1: in the normal case the dest mac points to the mac of the SF ingress port - right? 17:16:00 <vks1> yeah 17:16:21 <vks1> but in TAP case it wn't be 17:16:28 <vks1> *won't 17:16:30 <LouisF> so it should be the same for a tap SF 17:16:39 <LouisF> why not? 17:17:30 <vks1> that's the behavior of TAP , it recieves a copy of pkt coming/going in/out from a port 17:17:49 <LouisF> right 17:18:50 <vks1> if we send the pkt by re-writing dest mac of TAP , then he dest mac related policy won't be enforced 17:18:55 <LouisF> the dest mac of a packet must be the mac of the ingress port of the tap SF 17:19:19 <vks1> No 17:19:33 <LouisF> what do you mean by "dest mac related policy"? 17:20:27 <vks1> so TAP are deployed to monitor traffic where certain security policies are defined to analyze / send alarm and many other action 17:21:06 <vks1> there are policies which operator say if src ip is 'X' and dest mac is 'Z' , send a trigger 17:21:34 <vks1> now if you overwrite the dest MAC these sort of policies can't be enforced 17:22:04 <vks1> In nutshell , TAP devices recieves copy of traffic which are never intended to reach to them 17:22:41 <LouisF> vks1: ok what are saying is that the dest mac of the packet sent by the source VM must be delivered to the tap SF 17:22:52 <vks1> yeah 17:22:55 <vks1> exactly 17:23:18 <LouisF> so that is dest mac matching can work correctly 17:23:26 <LouisF> is -> its 17:24:28 <vks1> how ? source will never send dest_mac == TAP's ingress MAC 17:24:48 <vks1> it will be another default mode SF or destination port 17:25:27 <LouisF> the current implementation of the OVS agent uses the dest mac to steer port chain packets from one SF to the next 17:25:56 <vks1> yeah so , I have defined separately for TAP devices 17:26:14 <LouisF> the original dest mac from the source VM is overwritten at each hop in the port chains 17:26:21 <vks1> https://review.openstack.org/#/c/465057/6 17:27:16 <vks1> LouisF: please review this. 17:27:27 <vks1> That's a working patch 17:28:35 <LouisF> so how does pkt steering from one SF to the next work in yr design? 17:29:30 <vks1> there is no change in the way pkts are steered for default SF (tap_enabled=False). They work as it is 17:30:23 <LouisF> if you have a chain: SF1, SF2, tap SF, ..., how is original dest mac from source VM delivered to tap SF? 17:30:24 <vks1> only if operator insert TAP SF anywhere in chain, it recieves all the traffic copied from the source 17:31:33 <vks1> in this case the pkt coming out from SF2 will be received by TAP SF without original mac getting re-written in Group table 17:32:23 <vks1> while the normal traffic if it is another SF (rewriiting pf dest mac) and if it is normal port will go as it is 17:33:11 <vks1> its like you tap the pkts from egress of SF2 before reaching to group table 17:34:32 <LouisF> vks1: but the packets from SF2 will already have their dest mac overwritten 17:35:09 <vks1> you mean to say in OVS or from the SF ?? 17:36:01 <LouisF> to steer pkts from SF1 egress port to SF2 ingress port the OVS driver will set dest mac of packets to mac of SF2 ingress port 17:36:06 <pcarver> LouisF: just got back from a meeting, reading IRC scrollback now 17:36:18 <LouisF> pcarver: welcome 17:37:12 <vks1> once operator deploy TAP after SF2 , the intention is to monitor traffic of the segment between Egress port of SF2 and ingress port of next SF/dest port 17:37:50 <LouisF> vks1: agree 17:38:36 <vks1> there cannot be a deployment possible between L3 devices which monitors the entire packet path, atmost it could be of a segment in network 17:38:37 <LouisF> so you want to deliver the dest mac of the packet from SF2 egress port to the tap SF 17:39:19 <vks1> I want whatever coming out from egress port should be delivered as it is to TAP SF 17:39:32 <LouisF> vks1: ok got it 17:40:38 <LouisF> so does you design duplicate the packet after the ovs driver receives it from the egress port of SF2? 17:40:58 <LouisF> and send it to the ingress port of the tap SF? 17:41:04 <vks1> yes 17:42:34 <LouisF> back to my original question: why can't you have SF1, SF2, tap SF3, tap SF4, SF5, ....? 17:44:04 <vks1> the problem as I mentioned was I did not see a uniform solution to achieve this 17:44:37 <LouisF> vks1: can you elaborate? 17:46:13 <vks1> 'n' TAP SF means 'n' classifications required , in TAP case its only 'src_mac' of egress SF port 17:46:41 <vks1> which means we will 1:n mapping between port and TAP SFs 17:47:03 <vks1> Also I have kept it open for future work 17:47:36 <vks1> Any suggestions are welcome, I will try to implement on that line 17:48:27 <LouisF> ok, the case of two consecutive tap SFs is not really that useful 17:48:28 <vks1> also as I mentioned , because of these limiatations even TAAS doesn't support this 17:49:14 <LouisF> but this use case should be ok: SF1, tap SF2, SF3, tap SF4, SF5,...... 17:49:33 <vks1> yeah this case is perfectly fine and have no issue 17:49:54 <LouisF> ok, i think that is reasonable 17:51:05 <LouisF> thanks for providing that use idea of being able to deliver the dest mac from the egress port of a SF to the tap SF 17:51:15 <LouisF> use -> useful 17:51:44 <vks1> please review the patches , I have kept the changes isolated so that it doesn't mix with the default path 17:51:52 <LouisF> vks1: ok will do 17:52:47 <LouisF> all please review the patch https://review.openstack.org/#/c/465057/ 17:53:50 <LouisF> ok, any items to discuss before end of meeting? 17:54:05 <LouisF> #topic other items 17:55:21 <LouisF> ok thanks all 17:55:32 <pcarver> On the API def it looks like I have to add one for flowclassifier as well 17:55:46 <pcarver> I had somehow overlooked that 17:55:59 <LouisF> pcarver: ok thanks 17:56:16 <pcarver> and I've gone ahead and copied the exceptions into neutron-lib (though not pushed a new patch set yet) 17:56:30 <LouisF> pcarver: good 17:57:04 <pcarver> It's still failing tox pretty badly so I've really got to find a large enough block of time between meetings to figure it all out. 17:57:20 <LouisF> pcarver: thanks for your help 17:57:48 <vks1> pcarver: let me know if I can help there 17:58:39 <pcarver> vks1: I'll let you know, but mostly the issue is I have trouble getting a big enough contiguous block of time to dig into it before having to switch tasks 17:58:57 <vks1> ok 18:00:14 <LouisF> ok thanks all 18:00:16 <LouisF> bye 18:00:22 <LouisF> #endmeeting