17:00:04 <cathy__> #startmeeting service_chaining
17:00:04 <openstack> Meeting started Thu Jul 14 17:00:04 2016 UTC and is due to finish in 60 minutes.  The chair is cathy__. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:05 <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:14 <cathy__> hi everyone
17:00:35 <igordcard> hi
17:01:21 <pcarver> hi
17:01:37 <fsunaval> hi
17:02:01 <doonhammer> hi all
17:02:10 <cathy__> Ok, let's start
17:02:12 <scsnow_> hi
17:02:19 <cathy__> #topic Move to using OpenStack Client (OSC)
17:02:32 <LouisF> hi
17:02:41 <mohankumar__> Hi
17:02:46 <cathy__> mohankumar__: I know you are working on this. how is it going?
17:03:04 <yamahata> hello
17:03:33 <mohankumar__> Working on code. Will submit WIP patch soon
17:04:12 <cathy__> mohankumar__: cool, thanks.
17:04:34 <cathy__> #topic Remove the agent_opts for encap which comes from the config
17:05:41 <cathy__> georgewang: This is an action item from last week's meeting. I have created a bug for this.
17:06:27 <LouisF> https://bugs.launchpad.net/networking-sfc/+bug/1602890
17:06:27 <openstack> Launchpad bug 1602890 in networking-sfc "remove the agent_opts for encap which comes from the config" [High,In progress]
17:06:54 <scsnow_> it's trivial fix, I can take it
17:07:08 <cathy__> scsnow_: cool, thanks.
17:07:38 <cathy__> #topic Add port-pair-group param
17:08:06 <s3wong> hello
17:08:10 <cathy__> georgewang: I know you are working on this. When do you think you can upload the patch?
17:08:23 <cathy__> s3wong: hi, you are late:-)
17:08:34 <s3wong> cathy__: yes... late... sorry
17:09:34 <georgewang> i think it should be one or two weeks later.
17:09:44 <cathy__> georgewang: OK, thanks
17:09:50 <cathy__> #topic Tempest Test suite
17:10:15 <cathy__> georgewang: I know you are working on this. How is this going?
17:11:19 <georgewang> I have almost written both api and scenario tests in my local repo. Will make it cover more scenarios
17:11:36 <cathy__> georgewang: OK, thanks.
17:11:42 <cathy__> #topic Rename openvswitch-agent to avoid naming conflict with neutron
17:12:18 <cathy__> #link https://review.openstack.org/334398
17:13:42 <fsunaval> the issue is that SfcOvsAgent is a child class of neutronovsagent
17:13:51 <cathy__> fsunaval: would you like to describe the issue if we rename our OVS agent to see whether others have some good idea how to solve it?
17:14:33 <fsunaval> we currently create /usr/local/bin/neutron-openvswitch-agent
17:15:14 <fsunaval> however, the redhat package management system has issues with that. they want neutron-openvswitch-agent (for pure neutron) and something else for sfc (say neutron-openvswitch-sfc-agent)
17:15:38 <fsunaval> there does'nt seem to be an easy fix to this for now...
17:16:28 <fsunaval> unless we decouple neutronovsagent  from SfcOvsAgent and then use the L2 flow extension manager so that SFC can program into the bridges directly..
17:17:02 <fsunaval> open to any / all other ideas.
17:17:09 <cathy__> s3wong: pcarver yamahata any good idea how to solve this?
17:17:37 <pcarver> sorry, got pulled away. Looking back at IRC now.
17:17:46 <cathy__> mohankumar__: scsnow_ igordcard doonhammer ?
17:18:44 <doonhammer> cathy: sorry no ideas here
17:19:33 <pcarver> cathy: Sorry, no obvious idea from me either
17:19:42 <scsnow_> how this resolved in another neutron projects?
17:19:52 <scsnow_> I think many projects have their own agents
17:20:00 <fsunaval> lbaas and fwaas have their own agents.
17:20:55 <fsunaval> so, in a way, the redhat folks are right. sfc should have its own agent instead of going as the neutron agent with sfc changes.
17:21:36 <fsunaval> anyway, I can continue looking into it ... if anyone has ideas please send email.
17:21:51 <cathy__> scsnow_: fsunaval If SFC has its own agent, does it mean SFC agent needs to duplicate codes of some of the Neutron agent?
17:22:18 <fsunaval> there will be some code duplication but should'nt be much...
17:23:30 <cathy__> fsunaval: If I remember correctly, originally SFC has its own agent and there are a lot of code duplication, we got comments on that and thus changed it to current way
17:23:47 <scsnow_> fsunaval, so I want to have lbaas and fwaas I have to run 3 different agents, right?
17:24:09 <fsunaval> scsnow_: yes...
17:24:46 <fsunaval> cathy__: hopefully with the l2 flow extension manager there should be much less ...
17:25:20 <cathy__> fsunaval: So you mean we will write our own agent which only programs SFC specific tables into the bridge while all others are done by Neutron agent, right?
17:25:48 <fsunaval> cathy__: yes, that is the idea..
17:26:34 <cathy__> fsunaval: rewrite this will be a lot of work. Thanks for looking into this!
17:26:59 <fsunaval> cathy__: I will give update next week on what I find...
17:27:38 <cathy__> fsunaval: thanks.
17:28:03 <cathy__> #topic NSH encap work
17:28:12 <cathy__> igordcard: how is it going?
17:28:34 <igordcard> almost starting, the SFP management work is taking a long time :(
17:28:43 <cathy__> ok
17:28:51 <igordcard> port-chain-create works, but I'm still working on the rest
17:29:18 <igordcard> NSH support will be much quicker to implement than tthis refactoring
17:29:54 <cathy__> igordcard: I just like to make sure on the data path, we will keep the SFF Proxy functionality to support Service Function that does not understand the NSH encap. Is this what you have in mind?
17:30:10 <igordcard> cathy__: yes
17:31:14 <igordcard> cathy__: if a port-pair doesn't specify correlation nsh, it will automatically proxy - is this okay?
17:31:42 <cathy__> igordcard: cool. thanks. Also the new OVS patch for NSH has been completed and is being reviewed in OVS. You can incorporate with that new patch in your testing since that patch is what is being pushed into OVS
17:31:59 <cathy__> igordcard: No
17:32:09 <cathy__> igordcard: what we mean by Proxy is
17:33:10 <cathy__> igordcard: The API specifies an encap mechanism "NSH" or "MPLS" or other, but the switch has to strip off the SFC encap header before forwarding the pkg to the SF.
17:33:44 <cathy__> igordcard: We can not assume that all SF is NSH SFC header aware.
17:34:17 <igordcard> cathy__: so we can use port-pair's service_function_parameters to decide whether to proxy a specific SF right?
17:34:22 <cathy__> In the other direction, when the switch receives the packet from the SF, it needs to do reclassification and adds back the NSH header.
17:34:44 <doonhammer> lgordcard: +1 definitely not - especially if they are hardware based
17:34:47 <cathy__> We already implemented this Proxy functionality for mpls encap.
17:34:55 <cathy__> igordcard: yes
17:35:11 <cathy__> igordcard: that is why there is a SF parameter in the API
17:35:46 <igordcard> doonhammer: +1 or definitely not?
17:36:32 <doonhammer> agree that SF cannot understand all the various encap and transports
17:36:48 <doonhammer> becomes a support nightmare
17:36:58 <igordcard> cathy__: okay my plan was to use that sf parameters to decide whether to proxy or not a specific SF
17:37:16 <cathy__> igordcard: good
17:37:38 <igordcard> cathy__: doonhammer: alright then
17:38:02 <cathy__> doonhammer: Yes, I agree that it will take a long time to have all SF become NSH aware. So SF Proxy functionality will be there for a long time:-0
17:39:46 <doonhammer> cathy: It is not just NSH but it is also the NSH encap transport - I do not see any convergence on that
17:40:10 <igordcard> cathy__: yes, but at the same time networking-sfc can help accelerate NSH support/development in SFs by making it easy to deploy the chains
17:40:48 <cathy__> doonhammer: never mind about the NSH transport, since the OVS tunnel bridge will always strip that off
17:41:17 <cathy__> doonhammer: I assume you are talking about the VXLAN or GRE or other transport for NSH?
17:41:29 <doonhammer> cathy: yes
17:42:23 <cathy__> igordcard: yes, but that depends on the SF appliance companies. Usually it is not easy to have them change. I talked to F5 long time back and got that feeling.
17:43:29 <cathy__> doonhammer: If there is a correlation mechanism between the OVS and the SF for the chain-ID, then the OVS does not need to do reclassification which is expensive.
17:43:57 <doonhammer> cathy: part of the issue is the ASICs we all use in the hardware platforms - more encap means more bits
17:45:16 <doonhammer> cathy: if the classifier is the OVS switch it is easy - if there deeper classification everyone has to agree on the type of classification and taxonomy
17:45:35 <cathy__> doonhammer: do you think SF can create multiple virtual interfaces with each virtual interface mapping to a chain? The virtual interface is not a real interface, but is just for identify different chain packets coming to the SF?
17:46:26 <doonhammer> cathy: yes that is what we do today
17:46:50 <doonhammer> cathy: we do that for multi-tenacy
17:47:03 <cathy__> doonhammer: I am referring to how we can simply the SF Proxy mechanism. Instead of reclassification, if there is a correlation mechanism between the OVS and the SF for the chains, then reclassification is not needed
17:47:39 <cathy__> doonhammer: cool !
17:47:53 <cathy__> doonhammer: yes, I remember you mentioned this in the OVS alias
17:48:18 <doonhammer> cathy: I owe a response to that thread
17:49:05 <cathy__> doonhammer: So if all these chains belong to the same tenant, there is no issue. But if these chains belong to different tenants, does the VM allow multiple interfaces associated with different tenants?
17:49:25 <cathy__> AFAIK, a VM can only associate with one tenant? How did you solve this?
17:49:30 <doonhammer> cathy: the issue with the classification is if one of the SF modifies the flows e.g. flow compression or video encoding etc.
17:50:00 <cathy__> doonhammer: yes, exactly
17:50:39 <cathy__> doonhammer: reclassification has multiple downsides
17:51:29 <cathy__> doonhammer: that is the Nova restriction for VM.
17:51:30 <doonhammer> cathy: a vm can have multiple tenants each with a pair of virtual interfaces , a port-pair. Then each tenant gets a unique port-pair but there is a limit to the number of interfaces - but it is fungible as it is just software
17:52:27 <cathy__> doonhammer: interesting. AFAIK, Farhad did a test and found out that a VM can only take one interface. Farhad?
17:52:57 <cathy__> I mean a VM can take multiple interfaces but these interfaces need to belong to one tenant
17:53:12 <fsunaval> cathy__: VM can take any number of interfaces from the same tenant...
17:53:38 <doonhammer> ah so might be a Nova limitation - I need to look at that
17:53:40 <fsunaval> nova does not allow a VM to attach a neutron-port created in another tenant.
17:53:56 <fsunaval> doonhammer: is your multi-tenant FW supported in Openstack or NSX ?
17:54:02 <doonhammer> NSX
17:54:10 <fsunaval> yes... not in Openstack.
17:54:30 <cathy__> doonhammer: I see. So your VM is not OpenStack Nova created
17:54:56 <cathy__> doonhammer: could you try a VM in OpenStack to see if it works?
17:55:05 <doonhammer> made the bad assumption it would work in OS once we had OVN-SFC working :-(
17:55:27 <doonhammer> cathy: now on my list of todos
17:55:45 <cathy__> doonhammer: great, Thanks! We really like to hear back from you!
17:56:30 <cathy__> Cool. we are running out of time.
17:56:40 <doonhammer> cathy: yes want to clean up the multi-tenant issue with regXboi too
17:56:56 <cathy__> if any of you have any topic you would like to discuss, feel free to post it on the wiki meeting page.
17:57:18 <cathy__> doonhammer: sure.
17:57:23 <cathy__> doonhammer: thanks!
17:57:58 <cathy__> Ok, that's all for today's meeting. Will talk to you next week.
17:58:02 <scsnow_> bye
17:58:03 <LouisF> bye
17:58:04 <cathy__> bye now
17:58:07 <doonhammer> bye
17:58:09 <mohankumar__> Bye
17:58:10 <fsunaval> bye all!!!
17:58:30 <cathy__> #endmeeting