17:01:11 <LouisF> #startmeeting service_chaining
17:01:12 <openstack> Meeting started Thu Mar 30 17:01:11 2017 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:16 <openstack> The meeting name has been set to 'service_chaining'
17:01:19 <LouisF> hi all
17:01:33 <LouisF> doonhammer: hi John
17:01:43 <doonhammer> Hi Louis
17:01:51 <bcafarel> hello
17:01:58 <pcarver> hi
17:02:01 <vks1> hi
17:02:21 <LouisF> #topic agenda
17:02:23 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.283.2F30.2F2017.29
17:02:44 <LouisF> anything to  add to this?
17:03:00 <igordcard> hi all
17:03:51 <pcarver> I think there are some current gate problems aren't there?
17:03:52 <LouisF> igordcard: hi
17:04:11 <pcarver> I haven't had time to really understand what's going on but seemed to be a few issues
17:04:11 <bcafarel> pcarver: I was going to suggest the same thing :)
17:04:13 <LouisF> pcarver: some neutron issue
17:04:44 <bcafarel> there was one fix that landed in neutron (so we are good)
17:04:48 <pcarver> I saw a few changes from tmorin on sfc and I wasn't sure if that was related to unbreaking
17:04:58 <LouisF> https://bugs.launchpad.net/networking-sfc/+bug/1676656
17:04:58 <openstack> Launchpad bug 1676656 in networking-sfc "Extensions unit tests failing after neutron change" [Undecided,In progress] - Assigned to Bernard Cafarelli (bcafarel)
17:05:15 <bcafarel> that's the one
17:05:24 <bcafarel> fixed in neutron so we can mark it as fixed for us too I guess
17:05:24 <igordcard> right
17:05:24 <LouisF> bcafarel: yes
17:05:49 <bcafarel> pcarver: the one fix we really need is https://review.openstack.org/#/c/450463/
17:06:18 <bcafarel> the others are enhancements to move code to ovs_lib
17:07:06 <LouisF> bcafarel: ok wf+1
17:07:43 <bcafarel> that should get us back on track :)
17:07:55 <LouisF> ok
17:08:05 <LouisF> #topic CLI in python-neutronclient
17:08:18 <LouisF> https://review.openstack.org/#/c/409759/
17:09:29 <LouisF> hope we can get this merged
17:09:52 <LouisF> #topic API reference
17:10:20 <LouisF> pcarver: what is status?
17:11:01 <pcarver> LouisF: Armando wanted API ref to wait on def
17:11:21 <LouisF> pcarver: ok
17:11:23 <pcarver> I think def is probably in good shape but need someone to take a good look at what I deleted
17:11:40 <igordcard> def looked alright to me
17:11:47 <pcarver> The RESOURCE_ATTRIBUTE_MAP supports a "default" key which wasn't used in some cases
17:12:18 <LouisF> def looks ok
17:12:20 <pcarver> instead there was a "validator" key that called various functions that didn't seem to do more than replace None with defaults
17:12:51 <pcarver> so I removed those and just put the appropriate constants into the R_A_M as the values of the related "default" keys
17:13:08 <pcarver> I don't really understand why functions were defined in the first place
17:13:22 <pcarver> unless the "default" keys weren't available originally
17:13:56 <pcarver> Unless I've missed something, and just populating values for the "default" key doesn't get the job done
17:15:17 <LouisF> all please review
17:15:44 <LouisF> #topic Pike work
17:16:37 <LouisF> igordcard: how is SFC graph work?
17:17:07 <igordcard> LouisF: I updated the api patch
17:17:11 <igordcard> working on the rest
17:17:19 <LouisF> igordcard: thanks
17:17:20 <igordcard> slowly, loads of other things going on at the moment
17:17:42 <LouisF> igordcard: yes indeed
17:18:00 <igordcard> I'm not going to the summit btw
17:18:19 <LouisF> igordcard: ok
17:18:48 <LouisF> #topic Tap SF
17:19:36 <LouisF> vks1: you posted https://review.openstack.org/#/c/411409/
17:19:48 <vks1> LouisF: yeah
17:20:11 <LouisF> there some comments
17:20:18 <vks1> there are few things need discussion
17:20:27 <LouisF> vks1: go ahead
17:20:58 <vks1> if the port-pair-group have multiple TAP, then will the traffic be loadbalanced
17:21:01 <vks1> ?
17:22:37 <LouisF> vks1: yes
17:25:12 <vks1> there was a comment for consecutive TAP, since passive TAP doesn't forward packet, how it can be realized ?
17:27:26 <LouisF> vks1: by consecutive tap do you mean that a port chain has two hops that have a tap?
17:28:06 <vks1> LouisF: yeah that's what I have kept the restriction
17:28:21 <vks1> that two consecutive hops can't be TAP
17:29:00 <LouisF> vks1: i say that can be the case
17:29:44 <LouisF> for example hop1 can be a traffic monitoring SF and hop2 can be a IDS SF
17:29:52 <LouisF> both are passive
17:30:53 <vks1> LouisF: usually this is basically like deploying both devices in parallle
17:30:58 <vks1> *parallel
17:31:11 <LouisF> at hop1 (PPG1) the packets are duplicated: one pkt is sent to SF, other pkt is forwarded on to hop2
17:31:45 <vks1> LouisF: yeah that's pretty much parallel deployment
17:32:15 <vks1> LouisF: for now lets keep restriction and after I have things working will relax
17:32:29 <LouisF> the PPG scaling allows multiple SF of the _same_ type to be included (for example, all SFs in PPG must IDS)
17:33:01 <LouisF> vks1: not sure what you mean by relax?
17:33:21 <LouisF> the PPG scaling has a very specific purpose
17:33:40 <vks1> LouisF: I mean allow consecutive TAP , ok
17:33:48 <LouisF> the PPG LB will distribute traffic to SFs of the _same_ type
17:34:21 <LouisF> vks1: ok that should be a supported use case as I mentioned
17:34:33 <vks1> LouisF: there is a problem I see in forwarding packet to TAP SF when both TAP and dest./next hop are on different compute
17:34:47 <pcarver> Another way to say it is that for a single packet it will go to exactly one PP in each PPG
17:35:01 <LouisF> pcarver: +1
17:35:19 <LouisF> vks1: that should not be a problem
17:35:34 <LouisF> vks1: that is handled currently
17:35:47 <vks1> is it how ?
17:36:12 <LouisF> the tap SF can be on one compute node and the next hop SF can be on another node
17:36:56 <LouisF> the ovs driver design does that non-tap case
17:37:10 <LouisF> the tap must be able to support that also
17:38:18 <LouisF> the duplicated packet can be handled as if it "appears" to arrive from the egress port of the tap SF
17:38:28 <vks1> SFC doesn't configure br-tun flows , non-tap case works because MACs get re-written
17:38:49 <LouisF> then all the SFC fowarding logic is used
17:39:31 <vks1> br-tun will not forward to TAP SF compute , instead it will forward to original dest.
17:41:54 <LouisF> vks1: when br-int receives a packet from egress port of SF current behavior is to forward to next SF on same node or another node
17:42:07 <vks1> LouisF: should we discuss this after meeting ?
17:42:17 <LouisF> vks1: ok
17:43:00 <LouisF> this can be done by doing a resubmit
17:43:24 <LouisF> ok moving on
17:43:33 <LouisF> #topic OVN driver
17:44:05 <LouisF> doonhammer: i see there was comment on the sfc for ovn patch
17:45:22 <doonhammer> yes I sent some back to Mickeys - think we are narrowing it down
17:45:31 <LouisF> doonhammer: great
17:45:48 <doonhammer> more comments/ideas welcoem of course
17:46:00 <LouisF> ok i will look at it
17:48:24 <LouisF> #topic other items
17:49:51 <LouisF> i have a meeting at 11 so will end now
17:50:03 <LouisF> bye all
17:50:10 <bcafarel> just a quick mention of recent patches by tmorin, if all these go in, we should be able to use the standard OVSCookieBridge without any sfc-specific code, have a look
17:50:14 <bcafarel> and bye :)
17:50:22 <LouisF> bcafarel: ok
17:50:34 <LouisF> #endmeeting