17:00:20 <LouisF> #startmeeting service_chaining
17:00:21 <openstack> Meeting started Thu Apr  6 17:00:20 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:25 <openstack> The meeting name has been set to 'service_chaining'
17:00:33 <LouisF> hi all
17:01:07 <bcafarel> hello
17:01:11 <vks1> hi all
17:01:20 <LouisF> bcafarel: hi
17:01:24 <LouisF> vks1: hi
17:02:44 <vks1> lets start
17:02:52 <LouisF> #topic agenda
17:02:54 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.284.2F6.2F2017.29
17:03:09 <LouisF> doonhammer: hi
17:03:17 <doonhammer> Hi Louis
17:03:27 <bcafarel> 186729
17:03:40 <bcafarel> sorry wrong window
17:04:10 <LouisF> #topic CLI in python-neutronclient
17:04:31 <LouisF> https://review.openstack.org/#/c/409759/
17:04:37 <LouisF> still comments on this
17:05:12 <LouisF> mohan is not on
17:05:26 <LouisF> moving on
17:05:40 <LouisF> #topic SFC reference doc
17:06:06 <LouisF> https://review.openstack.org/#/c/389385 https://review.openstack.org/#/c/411409/
17:06:48 <LouisF> still work to do here
17:07:11 <LouisF> #topic Pike work
17:07:48 <LouisF> Tap SF, SFC graph, OVN driver
17:07:56 <LouisF> #topic Tap SF
17:08:09 <LouisF> vks1: what is status?
17:08:57 <vks1> LouisF: I am doing some manual testing with ovs-flows to achieve TAP
17:09:15 <vks1> LouisF: there was issue with mpls with resubmit action
17:09:29 <LouisF> vks1: have you resolved it?
17:09:59 <vks1> LouisF: I raised that on OVS , meanwhile I have figured a way around to address
17:10:32 <vks1> LouisF: still I see some inconsistency with datapath
17:10:47 <LouisF> vks1: can you elaborate?
17:10:48 <vks1> LouisF: not sure if that's an mpls hazard
17:11:47 <vks1> LouisF: one issue I saw is OVS didn't stripped the MPLS header before sending to SF
17:11:50 <vks1> *packet
17:12:06 <vks1> I needed to restart OVS to fix this
17:12:06 <LouisF> vks1: do have a design for handing the tap in the ovs integration bridge?
17:12:33 <vks1> LouisF: once I am done with my experiments I will send across
17:14:12 <LouisF> there is a pop_mpls action
17:14:37 <vks1> LouisF: yeah
17:15:26 <LouisF> vks1: is that not getting called?
17:16:19 <vks1> LouisF: for the issue , I chkd there where no logs in OVS log files, but once I restarted OVS it was working fine
17:16:56 <vks1> LouisF: Talked to justin, he suggested might be upgrade to compute kernel can fix this
17:16:56 <LouisF> vks1: to do the tap, what changes are you making to the ovs integration bridge?
17:17:34 <LouisF> vks1: not clear on what the problem is?
17:18:11 <vks1> LouisF: I am using a table for TAP, and adding the MPLS label of TAP service and do the rest of processing
17:18:40 <vks1> LouisF: that's true there are inconsistency and hard to debug
17:20:42 <LouisF> how are you using this tap table?
17:21:59 <vks1> LouisF: its almost same like the existing table: 5 , let me complete the experiment, I will send across
17:22:28 <LouisF> vks1: ok thanks
17:22:32 <vks1> LouisF: so I need the float a separate doc for the design ??
17:23:24 <LouisF> vks1: yes we should have a spec the outlines the tap design for ovs
17:23:33 <vks1> LouisF: OK
17:23:45 <LouisF> #topic SFC graph
17:24:23 <LouisF> Igor has posted patch https://review.openstack.org/#/c/388802/
17:24:45 <LouisF> please review this
17:26:45 <LouisF> igordcard: had a question on the exceptions
17:27:13 <LouisF> what is this used for? ServiceGraphLoopDetected
17:28:05 <LouisF> igordcard: is don't see where this gets raised?
17:29:15 <LouisF> looks like Igor is away
17:29:17 <bcafarel> not sure igordcard is around
17:29:39 <LouisF> #topic OVN work
17:29:58 <LouisF> doonhammer: what is status on this?
17:31:20 <doonhammer> I think we have the patch resolved - Mickey and I have agreed on the approach and changes - I will make them and re-submit the patch
17:31:42 <LouisF> doonhammer: ok thanks
17:31:45 <doonhammer> once that is done we can go ahead and implement in networking-ovn and networing -sfc
17:32:34 <LouisF> doonhammer: sounds good
17:32:35 <doonhammer> LouisF: can you take a look at the patch and changes and comment -want to make sure I have not missed anything
17:32:42 <LouisF> doonhammer: will do
17:33:04 <LouisF> #topic other items
17:33:27 <LouisF> https://bugs.launchpad.net/networking-sfc/+bug/1677469
17:33:27 <openstack> Launchpad bug 1677469 in neutron "networking-sfc is breaking tacker CI" [Undecided,New]
17:33:49 <LouisF> bcafarel: i saw you response on this
17:33:52 <bcafarel> LouisF: late update on the ServiceGraphLoopDetected it's used in the next review https://review.openstack.org/#/c/419212/
17:33:59 <vks1> LouisF: I have raised a bg
17:34:01 <vks1> *bug
17:34:22 <bcafarel> LouisF: ack it looks like tacker CI is OK again, so I think tmorin's fix was good for tacker too
17:34:43 <LouisF> bcafarel: thanks
17:34:58 <LouisF> bcafarel: and thanks on the link
17:35:05 <bcafarel> 648566
17:35:13 <vks1> https://bugs.launchpad.net/networking-sfc/+bug/1675796
17:35:13 <openstack> Launchpad bug 1675796 in networking-sfc "reverse flow creation fails for single arm SFs" [Undecided,New]
17:35:19 <bcafarel> ok I need to move that yubikey somewhere else :)
17:35:36 <LouisF> bcafarel: np
17:35:45 <vks1> can we discuss the above bug
17:35:46 <vks1> ?
17:36:40 <LouisF> vks1: go ahead
17:37:18 <LouisF> vks1: you had one port chain and then tried to create another?
17:37:36 <vks1> currently for a single arm SFC we can't build reverse flow
17:37:53 <vks1> LouisF: yeah for reverse flow
17:38:40 <vks1> this is the most basic deployment , I think we need to resolve this
17:39:35 <vks1> according to current implementation, we can have only flow in one direction for single arm SF
17:41:31 <LouisF> vks1: so its blocked on two port chains that use the same PPG?
17:41:49 <vks1> LouisF: that's true
17:42:34 <bcafarel> the reverse path is just fo rthe PPG I suppose? for the full port chain, symmetric works (I think?)
17:42:39 <LouisF> vks1: one portchain is for forward traffic and the other for reverse traffic through the same PPG
17:43:27 <vks1> LouisF: yes
17:43:51 <LouisF> ok i see
17:44:31 <vks1> bcafarel: there will be issue as for same port , we need to make 2 decisions ing/egr
17:45:43 <LouisF> the issue is that for a single arm SF,  ovs agent needs to distinguish forward traffic from reverse traffic
17:46:11 <LouisF> the only way to do that is to match on the n-tuple of the packet
17:46:30 <vks1> LouisF: yeah probably something like that
17:46:59 <LouisF> is a flow classifier has only logical-source-port as in your example the ovs is cannot do that
17:47:11 <LouisF> is -> if
17:48:02 <LouisF> vks1: can you try with a FC that includes the source IP prefix?
17:48:38 <vks1> LouisF: lets discuss this on launchpad, If we know what all can be issues, we can work on solution
17:48:49 <vks1> LouisF: OK will try with prefix
17:49:03 <LouisF> so the FC1 has source IP prefix = IP1 and FC2 has source IP prefix = IP2
17:49:19 <LouisF> vks1: ok will post to launchpad
17:50:04 <vks1> bcafarel: LouisF: doonhammer: please respond with all your thoughts on the launchpad.
17:50:37 <LouisF> vks1: i will update lp
17:50:50 <vks1> LouisF: thanks
17:50:59 <bcafarel> sure thing
17:52:18 <LouisF> any other items to discuss?
17:53:29 <LouisF> ok thanks all
17:53:52 <vks1> thanks all
17:54:18 <bcafarel> thanks, and bye
17:54:58 <LouisF> bye all
17:55:05 <LouisF> #endmeeting