17:00:52 <LouisF> #startmeeting service_chaining
17:00:53 <openstack> Meeting started Thu Jun  1 17:00:52 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:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:56 <openstack> The meeting name has been set to 'service_chaining'
17:01:05 <LouisF> #topic agenda
17:01:17 <vks1> hi all
17:01:20 <bcafarel> hello
17:01:50 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.286.2F1.2F2017.29
17:01:52 <LouisF> hi all
17:01:52 <igordcard> hi all
17:02:04 <LouisF> doonhammer: hi
17:02:05 <pcarver> hi
17:02:48 <doonhammer> Hi LouisF and all
17:03:31 <LouisF> #topic CLI in python-neutronclient
17:03:41 <LouisF> https://review.openstack.org/#/c/409759/
17:04:02 <LouisF> Mohan has updated the patch
17:04:16 <LouisF> maybe he will join later
17:04:23 <pcarver> looks like a whole lot of red from Jenkins
17:04:31 <LouisF> pcarver: yes
17:04:54 <LouisF> #topic API reference
17:05:10 <LouisF> pcarver: how is progress?
17:05:36 <bcafarel> pcarver: yes, latest setuptools release was broken, it was hell in gates (should be working again now)
17:06:15 <pcarver> LouisF: I feel like I may be digging a deep hole. I'm spreading stuff throughout constants, exceptions, validators and I'm not sure if I'm making more of a mess than I should.
17:07:07 <pcarver> It's all nicely encapsulated in the networking-sfc repo, but moving it to neutron-lib the process of splitting it up is a mess.
17:07:12 <LouisF> pcarver: how does this compare with bgpvpn?
17:07:58 <pcarver> more complicated because of the use of exceptions in the custom validators and the use of exceptions in the validators and SFC specific constants in both validators and exceptions.
17:08:05 <pcarver> bgpvpn didn't have that
17:08:37 <pcarver> I think there was one validator in bgpvpn and it was fairly straightforward to generalize it so that it wasn't bgpvpn specific
17:08:49 <LouisF> does it make sense to leave that in sfc?
17:08:57 <pcarver> so I added that one validator and then made minor changes to use the general version rather than specific
17:09:36 <pcarver> Originally I was trying to leave the SFC specific stuff in networking-sfc, but we can't create an import loop.
17:09:49 <pcarver> It's not reasonable for neutron-lib to import from networking-sfc
17:09:57 <LouisF> pcarver: right
17:10:27 <bcafarel> yes, pretty sure the neutron-lib folks would not agree (with reason)
17:10:28 <pcarver> so I either need to remove SFC specific stuff from validators and exceptions, or not use them in the API def, or else move them into neutron-lib
17:10:45 <LouisF> maybe armando and neutron-lib folks can help?
17:10:52 <pcarver> at this point I've shifted towards moving it all into neutron-lib, but that's where I feel like I'm making a mess
17:11:40 <pcarver> I'm going to push another broken patch set soon and ask for suggestions on it
17:11:56 <LouisF> pcarver: ok
17:12:25 <LouisF> pcarver: thanks
17:12:32 <pcarver> at the moment I'm trying to decide whether to rename the validators to be sfc specific while moving them into neutron_lib
17:13:08 <LouisF> can they be  used by other components?
17:14:04 <pcarver> I need to go through each one. Something like normalize_string may have a standard validator that's close enough, but normalize_l7parameters seems SFC specific
17:14:27 <LouisF> pcarver: yes
17:14:40 <pcarver> normalize_l7parameters uses an SFC constant SUPPORTED_L7_PARAMETERS in the code of the validator
17:15:17 <LouisF> pcarver: probably should have an sfc specific name
17:15:36 <pcarver> I may be able to figure out if I can get the same result using an existing standard validator, but I need to think through the logic of the current code first
17:16:10 <LouisF> pcarver: ok, thanks
17:16:19 <pcarver> but normalize_l7parameters also raises an SFC specific exception on error
17:16:37 <pcarver> so I'm not sure if I can do that with a generic validator
17:17:22 <pcarver> The bgpvpn API def didn't have validators and exceptions so entangled with the resource attribute map
17:18:12 <LouisF> i would contact neutron-lib for suggestions
17:18:44 <LouisF> #topic Pike work
17:18:47 <pcarver> will do. I'm going to do a bit more moving code around and then push the patch set
17:19:24 <LouisF> pcarver: ok
17:19:41 <LouisF> #topic SFC graph
17:19:48 <LouisF> igordcard: what is status?
17:20:46 <igordcard> working ferociously on some last fixes for the ovs agent and driver
17:21:05 <LouisF> igordcard: ok sounds good
17:21:13 <igordcard> I've already addressed the comments in api/db locally, will submit the 3 together, likely tomorrow
17:21:24 <LouisF> igordcard: thanks
17:22:07 <LouisF> #topic Tap SF
17:22:15 <bcafarel> igordcard: the ovs driver one is good for review too? (current one is still marked WIP)
17:22:22 <bcafarel> I'll add it to my review list
17:22:22 <igordcard> bcafarel: no no
17:22:57 <bcafarel> ok :)
17:23:31 <LouisF> vks1: what is status?
17:23:35 <vks1> there were few review comments which I addressed, need to add few more UTs
17:24:18 <LouisF> vks1: can you update the spec to describe how the tap works
17:24:41 <vks1> yeah I wanted to talk about that
17:24:50 <LouisF> specifically how the new tables are used
17:24:57 <LouisF> vks1: go ahead
17:25:01 <vks1> should I update the existing spec only ?
17:25:31 <vks1> that's what you also suggested
17:25:32 <LouisF> vks1: add comments where they help in the code also
17:26:04 <vks1> LouisF: yeah I have added few based on the comments I got
17:26:20 <LouisF> TAP_CLASSIFIER_TABLE and TAP_TUNNEL_OUTPUT_TABLE
17:26:21 <vks1> I will again look and add necessary comments
17:26:59 <LouisF> what flows are added to steer packets to the tap tables
17:27:29 <LouisF> and the use of REG0
17:28:28 <vks1> sorry is that question or I have to add in spec ? :)
17:28:56 <LouisF> can you explain briefly now
17:29:07 <vks1> REG0 is used to store actual eth_dst
17:29:33 <igordcard> hmm I'm also using reg0 in the service graphs
17:29:49 <igordcard> I can use a different one, no problem
17:29:55 <LouisF> you mean the eth_dst received from the egress port of the previous SF?
17:30:16 <vks1> yes
17:30:28 <vks1> igordcard: thanks
17:30:54 <vks1> igordcard: if for you there are too many changes lemme know I can change in TAP code
17:31:05 <vks1> TAP is using REG0 & REG1
17:31:26 <LouisF> need to document this usage in the driver so we avoid conflict
17:31:41 <igordcard> LouisF: yep
17:31:53 <vks1> I will  add this
17:32:43 <LouisF> vks1: can you add text that covers life of a packet through a SFC with a tap SF
17:33:10 <LouisF> look at some ovn descriptions which do this
17:33:41 <LouisF> add that description to the tap spec
17:34:08 <vks1> LouisF: np, OK I will do that. If you can point to any specific doc, it will be grt
17:35:08 <LouisF> vks1: https://review.openstack.org/#/c/449754/
17:35:24 <LouisF> vks1: https://review.openstack.org/#/c/442195/
17:36:13 <doonhammer> vks1: If is any help I just posted a Day in the Life of SFC onto ovs-dev
17:36:38 <LouisF> vks1: add description of the br-int and br-tun tables
17:36:39 <doonhammer> vks1: feel free to rip and replace
17:37:01 <LouisF> doonhammer: thanks they have very good descriptions
17:37:10 <igordcard> doonhammer: will check
17:37:14 <vks1> doonhammer: thanks I will look into that
17:37:28 <doonhammer> comments/suggestions welcome
17:37:32 <vks1> LouisF: sure will add
17:38:33 <LouisF> vks1: thanks  - that will help in reviewing the code
17:38:43 <LouisF> #topic OVN work
17:39:04 <LouisF> doonhammer: i will review the day in the life
17:40:14 <bcafarel> ^ https://mail.openvswitch.org/pipermail/ovs-dev/2017-May/332948.html for the interested
17:40:24 <doonhammer> LouisF: Ben is waiting for next patch - Mickeys patch to extend the table is in and I am getting some help from bcafarel:
17:40:34 <LouisF> https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/333309.html
17:40:57 <igordcard> LouisF: doonhammer: will try too, I haven't spent any time yet to figure out if there's a potential clash between the graphs and how the ovn support evolves
17:41:21 <LouisF> doonhammer: making progress
17:42:32 <LouisF> doonhammer: thanks
17:42:39 <doonhammer> lgordcard: If we can think of it in layers sfc is intended to be for simple cases and minimal infrastructure (linear chains) as we add more features we need more infrastructure support and interaction between VNFs and infrastructure - more complex but more power
17:44:06 <igordcard> doonhammer: yes.. but the setup of graphs at the forwarding layer doesn't require additional interaction (it requires, however, a form of sfc encapsulation)
17:44:07 <LouisF> #topic other items
17:44:39 <LouisF> i have a question about gluon
17:44:43 <igordcard> doonhammer: for ietf service graphs, I mean
17:44:53 <LouisF> pcarver: you have been close to this
17:45:03 <pcarver> LouisF: yes
17:45:15 <doonhammer> lgordcard: the encapsulation needs to be recognized by vnf or needs a proxy ?
17:46:15 <LouisF> doonhammer: there may be nsh-aware vnfs and nsh-unaware vnf
17:46:31 <doonhammer> LouisF: yup that is my thought
17:46:54 <LouisF> i expect over time vnfs will evolve to being nsh-ware
17:46:57 <LouisF> aware
17:47:33 <LouisF> pcarver: back to gluon - it has the concept of port-binding
17:47:37 <doonhammer> LouisF: yes my SFC work - allows them to get started without any NSH awareness
17:47:48 <LouisF> doonhammer: right
17:48:08 <doonhammer> LouisF: igordcard: But limited functionality
17:48:16 <igordcard> doonhammer: yes, but you don't have to configure the SFs, depends on what wants to be achieved or if the SF's policy can change
17:48:35 <pcarver> LouisF: yes, the original idea of Gluon was that each port would be owned by exactly one SDN controller and that Gluon would look up which one on a port by port basis for any port related API calls
17:48:43 <LouisF> pcarver: do you see problems with integration of sfc with gluon using port-binding?
17:49:32 <igordcard> doonhammer: I'll get back to the encapsulation after gluon
17:49:49 <doonhammer> igordcard: :-)
17:50:09 <LouisF> sorry to run conversation in parallel
17:50:29 <pcarver> LouisF: There are two parts to it, one service chaining across multiple SDN controllers, two hierarchical port binding, if a single port really needs multiple SDN controllers to handle it (e.g. vSwitch and ToR manipulation)
17:51:02 <pcarver> The Proton piece is really more relevant than the Gluon piece.
17:51:20 <LouisF> pcarver: ok the proton part
17:51:24 <pcarver> Proton is the part of the Gluon project that corresponds approximately to Neutron service plugins
17:51:33 <LouisF> pcarver: right
17:52:15 <LouisF> so would it be possible to integrate sfc with the proton plugin?
17:52:40 <pcarver> So really it comes down to a question of whether the Proton idea, specifically generating "protons" from YAML descriptions using an automated code generator (called "particle generator" to stick with the meme) is faster and easier than writing Neutron service plugins
17:53:18 <pcarver> An example SFC API has been written as a YAML file to be used as a "proton", but it looks nothing like the networking-sfc API
17:53:27 <pcarver> It focusses on different goals really.
17:53:27 <igordcard> LouisF: pcarver: with 2 neutron deployments I can see that being possible easily... but having the same neutron deployment simultaneously using gluon and non-bypassed neutron seems a bit complicated
17:54:16 <igordcard> ref from pcarver: https://review.openstack.org/#/c/461310/1/gluon/models/ietf-sfc/api.yaml
17:54:26 <pcarver> igordcard: Yes, I'm hoping that we will be able to converge the efforts and incorporate much of the Gluon project's ideas into Neutron
17:54:45 <pcarver> igordcard: yep, that's it
17:55:28 <LouisF> pcarver: thanks - getting a sense of what the direction is
17:55:28 <pcarver> but if you look at that YAML file it doesn't look much like networking-sfc's idea of an API
17:55:53 <pcarver> and I think networking-sfc's API is probably more comprehensible to an end user (but maybe that's just my perspective)
17:56:02 <igordcard> looks a bit like a simplified ODL SFC API
17:56:25 <LouisF> igordcard: yes
17:56:30 <pcarver> The Proton YAML is focussed on ensuring that multiple SDN controllers can interoperate, I think
17:57:01 <pcarver> It was merged in a hurry in order to enable a demo for the Boston summit, and hasn't been revisisted since
17:57:25 <LouisF> pcarver: ok thanks
17:58:23 <LouisF> ok lets revisit the ovn/sf graph discussion in the next meeting
17:58:48 <LouisF> thanks all
17:58:52 <LouisF> bye
17:58:53 <igordcard> thank you
17:58:55 <igordcard> bye
17:59:01 <bcafarel> bye
17:59:03 <davidsha> Hey, sorry to but in, I've put up a rebase of the Flow manager spec and was wondering would people be able to have a look at it: https://review.openstack.org/#/c/320439/
17:59:05 <doonhammer> bye
17:59:35 <igordcard> davidsha: :)
17:59:46 <LouisF> davidsha: ok
17:59:48 <bcafarel> davidsha: it's on my toreview list, hope I find some time soon for it
17:59:50 <LouisF> #endmeeting