17:00:03 <LouisF> #startmeeting service_chaining
17:00:05 <openstack> Meeting started Thu Apr 20 17:00:03 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:08 <openstack> The meeting name has been set to 'service_chaining'
17:00:12 <LouisF> hi all
17:00:13 <pcarver> hi
17:00:18 <vks1> hi
17:00:38 <doonhammer> Hi all
17:00:59 <bcafarel> hello everybody
17:01:36 <bcafarel> I will have to leave soon, but from the agenda, looks like it's ok and I can catch up with the logs later on
17:01:48 <igordcard> hi all
17:01:52 <LouisF> bcafarel: ok thanks
17:01:57 <LouisF> igordcard: hi
17:02:01 <LouisF> doonhammer: hi
17:02:09 <LouisF> #topic agenda
17:02:11 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.284.2F20.2F2017.29
17:02:49 <LouisF> #topic CLI in python-neutronclient
17:03:11 <LouisF> hope Mohan rejoins
17:03:50 <LouisF> ok back to CLI later
17:04:06 <LouisF> #topic API reference
17:04:17 <LouisF> pcarver: what is current status?
17:06:16 <pcarver> API ref done. Still struggling with API def.
17:06:28 <pcarver> Saw some feedback that I haven't had time to test.
17:06:29 <bcafarel> igordcard: thanks for the updated comment on the API def, better to be quite precise here (None and empty are not the same)
17:07:20 <LouisF> +1
17:07:47 <LouisF> #topic Pike work
17:08:05 <LouisF> #Tap SF
17:08:16 <LouisF> vks1: what is current status?
17:08:21 <vks1> I have an update
17:08:45 <vks1> https://bugs.launchpad.net/networking-sfc/+bug/1684457
17:08:47 <openstack> Launchpad bug 1684457 in networking-sfc "issue with output to multiple VXLAN tunnel" [Undecided,New]
17:09:01 * bcafarel dropping off, see you later all
17:09:34 <vks1> I was thinking , the way I am implementing TAP is bringing issue
17:10:00 <vks1> but I checked this issue/limitation is there with current SFC (with MPLS) also
17:10:20 <vks1> basically OVS has issue with MPLS and tunnel
17:11:28 <LouisF> vks1: what are you seeing exactly?
17:11:39 <vks1> for that only there was Farhads email on OVS discuss https://mail.openvswitch.org/pipermail/ovs-discuss/2016-January/039764.html
17:12:08 <vks1> OVS is dropping packet when tried to output to multiple tunnel port.
17:12:32 <igordcard> vks1: when you say "with mpls" does it have to do with mpls correlation in port-pairs?
17:13:12 <igordcard> vks1: do you have a dump-flows output to show?
17:13:31 <vks1> igordcard: its not only port-correlation but the entire MPLS implementaton in OVS
17:13:44 <vks1> igordcard: I have given dump https://bugs.launchpad.net/networking-sfc/+bug/1684457
17:13:45 <openstack> Launchpad bug 1684457 in networking-sfc "issue with output to multiple VXLAN tunnel" [Undecided,New]
17:13:47 <vks1> here
17:14:11 <vks1> igordcard: also I have pointed the OVS code which is causing problem
17:15:07 <LouisF> vks1: the multi-compute node scenario has been tested: src(compute A) -> SF (compute B) -> dst (compute A)
17:15:16 <LouisF> and it worked ok
17:15:38 <vks1> igordcard: wait I have a mistake in representing scenario
17:16:02 <vks1> there are 3 computes in my scenario
17:16:29 <vks1> and flows in tunell port have output to tunnel port
17:16:31 <LouisF> vks1: can you update the bug report
17:16:47 <vks1> LouisF: I will update the scenario
17:17:18 <vks1> basically this can be easily simulated by working with > 2 compute node
17:17:32 <vks1> the weird thing is it work for sometime
17:17:42 <LouisF> i want to know how your scenario differs from what has been tested
17:17:42 <vks1> and start failing with giving the error
17:18:09 <vks1> I guess the scenario was always tested with < 2 compute nodes
17:18:31 <LouisF> we have done testing with >2 nodes
17:18:32 <vks1> <= 2 compute
17:18:39 <vks1> * my mistake
17:18:56 <vks1> oh does that worked ???
17:19:30 <vks1> I am not sure , as https://mail.openvswitch.org/pipermail/ovs-discuss/2016-January/039764.html issue raised here has not been fixed
17:19:37 <LouisF> ok add the details to the bug and we can re-check
17:19:37 <vks1> in OVS
17:20:05 <vks1> LouisF: so I will add the TAP code with the scenario in which it is working
17:20:11 <vks1> LouisF: will that be OK
17:20:27 <LouisF> vks1: ok
17:20:41 <vks1> LouisF: thanks
17:21:21 <LouisF> vks1: does your tap code work for <= 2 compute nodes?
17:21:31 <vks1> LouisF: yeah
17:21:46 <LouisF> vks1: great
17:23:15 <vks1> LouisF: I haven't finished yet , its pretty much WIP
17:24:10 <LouisF> vks1: ok looking forward to the patch
17:24:33 <LouisF> ok moving on
17:24:38 <LouisF> #topic SFc graph
17:24:53 <LouisF> igordcard: what is status?
17:26:09 <LouisF> mohankumar: what is status of the CLI work?
17:26:21 <igordcard> api+db+ovs set is practically done, but I know I have a few corner cases and additional tests to address
17:26:30 <LouisF> igordcard: ok thanks
17:26:49 <igordcard> I will submit new patxhsets tomorrow
17:26:51 <mohankumar> LouisF , Waiting for akihiro's comment . for the recent patch
17:27:03 <LouisF> mohankumar: ok thanks
17:27:24 <LouisF> igordcard: thanks
17:27:45 <LouisF> #topic OVN work
17:28:05 <doonhammer> working on feedback from Mickeys:
17:28:07 <LouisF> doonhammer: i see comments on the ovn-sfc patch
17:28:17 <doonhammer> think we are getting very close
17:28:24 <doonhammer> hopefully this one will be it
17:28:47 <doonhammer> would still like some feedback from networking-sfc :-)
17:29:09 <LouisF> doonhammer: so you are using a Logical_Port_Chain_Classifier
17:29:19 <LouisF> instead of ACLs
17:30:03 <doonhammer> yes - it made the code much more modular and easier to plug and play
17:30:19 <doonhammer> the acls are hard to remove once they are added
17:30:30 <doonhammer> and did not add a lot
17:30:39 <LouisF> is it possible to match on ip prefix, tcp ports, etc?
17:30:39 <doonhammer> still using hte OVS/OVN match logic though
17:30:50 <doonhammer> yes - I have included match
17:31:34 <LouisF> so the match field has the ACL  syntax?
17:31:39 <doonhammer> correct
17:31:44 <LouisF> great
17:33:10 <LouisF> so you have addressed Mickey's comments?
17:33:34 <doonhammer> working on them - will be done today or tomorrow
17:33:43 <LouisF> doonhammer: ok thanks
17:34:01 <doonhammer> I am just making sure I understand the re-circulating part
17:34:43 <LouisF> doonhammer: yeah - explain it to me when you understand :)
17:35:32 <LouisF> i am looking for someone to do the SFC-OVN driver work
17:37:14 <LouisF> #topic non-transaparent SF support
17:37:31 <LouisF> https://review.openstack.org/#/c/448284/
17:37:46 <LouisF> this ^ is the spec
17:38:35 <LouisF> the ovs implementation is at https://review.openstack.org/#/c/458303/
17:39:17 <LouisF> actually cli, db, etc. also
17:39:23 <LouisF> please review
17:40:02 <LouisF> ok thats all i want to cover
17:40:08 <vks1> LouisF: igordcard I have updated the bug description and let me know if more info is needed
17:40:49 <LouisF> vks1: ok i will discuss with Farhad and investigate further
17:40:57 <LouisF> vks1: thanks
17:41:12 <igordcard> alright
17:41:18 <vks1> LouisF: thanks let me know if  I am missing amything
17:41:51 <LouisF> vks1: thanks
17:41:56 <LouisF> any other topics to discuss?
17:42:09 <LouisF> #topic other items
17:42:34 <igordcard> just a quick reminder
17:43:08 <igordcard> there's a new ovs flow managemebt spec up
17:43:30 <LouisF> igordcard: link?
17:43:46 <igordcard> hasn't been reviewed it, but since networking-sfc will one day use it, it'd be beneficial to take a look at
17:43:51 <igordcard> #link https://review.openstack.org/#/c/320439/
17:44:09 <LouisF> igordcard: thanks will review
17:44:12 <igordcard> s/it/yet
17:44:45 <LouisF> ok thanks all
17:44:49 <LouisF> bye
17:45:08 <igordcard> bye
17:45:13 <LouisF> #endmeeting