17:01:24 <LouisF> #startmeeting service_chaining
17:01:24 <openstack> Meeting started Thu Jun 16 17:01:24 2016 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:27 <openstack> The meeting name has been set to 'service_chaining'
17:01:36 <LouisF> hello all
17:01:41 <mohankumar> Hi
17:01:41 <doonhammer> Hi Louis
17:01:43 <igordcard> hello
17:02:04 <LouisF> cathy cannot make it today
17:02:05 <pcarver> hi
17:02:13 <fsunaval> hi
17:02:47 <LouisF> #topic action status
17:03:20 <LouisF> flow classifier priority progress
17:03:24 <igordcard> LouisF: is the agenda exactly the same as last meeting?
17:03:43 <LouisF> igordcard: yes
17:04:03 <mohankumar> LouisF , pavel need to add  agent support
17:04:32 <LouisF> mohankumar: thanks it pavel  on the call?
17:04:41 <LouisF> is
17:04:50 <mohankumar> LouisF , can't find him
17:05:04 <LouisF> i have not seen a patch set for that work
17:05:45 <mohankumar> LouisF , let me discuss with pavel and update on this progress
17:05:52 <LouisF> mohankumar:  thx
17:06:03 <LouisF> ok, path id generation
17:06:26 <igordcard> LouisF: nothing yet, I'm working on it together with the nsh correlation support
17:06:37 <LouisF> i think igor and george wang were working on this
17:06:54 <LouisF> igordcard: ok thx
17:07:16 <LouisF> doonhammer: ovn driver work?
17:07:20 <s3wong> hello
17:08:04 <doonhammer> LouisF: Need to submit WIF patches - I got a lot of help from Na Zhu this this week
17:08:34 <LouisF> doonhammer: looks like good progress is being made
17:08:58 <doonhammer> I think we will need to iterate on the ovs/ovn schema some more and it would help to have some more eyes on it and try and implemetn some use cases
17:09:18 <LouisF> doonhammer: ok
17:10:38 <LouisF> PPG parameter for insert-mode
17:11:07 <LouisF> pavel was going to start work on this
17:12:04 <LouisF> ok moving on
17:12:19 <LouisF> nsh encap work
17:12:46 <LouisF> pavel was looking at that also
17:13:11 <igordcard> LouisF: yes,I've been in contact with him
17:13:42 <LouisF> igordcard: what is the status regarding transport encap?
17:13:53 <igordcard> we've agreed I'll continue the work for now
17:14:26 <LouisF> igordcard: ok thanks
17:14:57 <igordcard> still in the beginning, api and docs ave been updated but not much more so far
17:15:21 <igordcard> api,as in correlation=nsh
17:15:29 <LouisF> igordcard: do you have links
17:15:35 <igordcard> no, not yet
17:15:37 <LouisF> igordcard: yes
17:15:53 <igordcard> actually I've pushed a part to my github
17:16:01 <igordcard> branch ietf
17:16:13 <LouisF> igordcard: ok
17:16:37 <LouisF> igordcard: please share when they are ready
17:16:48 <igordcard> in the end this will be 3 patches to gerrit: nsh correlation; path id generation at the plugin; full sfc encappsulation in the api
17:17:06 <igordcard> LouisF: sure
17:17:16 <LouisF> igordcard: great
17:17:48 <LouisF> ok on  to functional test work
17:18:00 <LouisF> there  is a patch https://review.openstack.org/#/c/321870/
17:18:10 <LouisF> needs review
17:19:39 <LouisF> there is also this patch https://review.openstack.org/#/c/324135/
17:19:50 <LouisF> need another +2 to proceed
17:20:17 <LouisF> from a member of the infra team
17:21:34 <LouisF> ok moving on
17:21:51 <LouisF> #topic driver capability discovery
17:22:22 <LouisF> i posted the patch https://review.openstack.org/#/c/317635
17:23:33 <LouisF> there have been many comments on this
17:24:12 <mohankumar> LouisF ,yes
17:24:24 <LouisF> generally the view is that it should get input from other projects
17:24:50 <LouisF> pcarver: what is your view on how to proceed?
17:26:19 <pcarver> I still think it's going to be necessary but I understand there are some concerns.
17:26:48 <pcarver> It might help if we agreed on a policy on when/how to add new capabilities
17:27:09 <pcarver> We don't want to fragment by having a lot of features that are each implemented only by one driver
17:27:27 <LouisF> pcarver: agree on that
17:27:41 <pcarver> but I don't know if it's reasonable to say that a feature can't be added to the API unless the L2 agent based OvS driver can do it
17:28:05 <pcarver> There will likely be things that are difficult to support without an active SDN controller
17:28:43 <pcarver> And I'm not sure if the current "reference" implementation is going to be able to be a superset of all the SFC capabilities of all SDN controllers
17:29:08 <LouisF> how is that handled in other projects?
17:29:17 <pcarver> I'm not sure it really has been
17:29:26 <pcarver> The anti-example is networking-bgpvpn
17:29:51 <pcarver> Contrail supports a network VPN attachment and Nuage supports a router VPN attachment
17:30:12 <fsunaval> How about we also define a baseline of capabilities that all drivers must support.. E.g. L3 service function, SFC in same network, etc.
17:30:15 <LouisF> pcarver: what about the reference implementation?
17:30:19 <pcarver> If you try to create the opposite type of attachment that your SDN backend supports you get a not implemented exception
17:30:49 <pcarver> fsunaval: A baseline makes sense
17:31:15 <pcarver> but as we add features there's likely to be a first driver to support it before others
17:31:27 <LouisF> fsunaval: +1
17:31:58 <pcarver> So we probably need some sort of planning guideline that in order to add a new feature we need a reasonable expectation that at least N drivers will support it. I'm not sure what number N should be.
17:32:20 <LouisF> pcarver: so does bgpvpn have a reference implemantation that supports all features?
17:32:24 <pcarver> It would be nice if the reference implementation could support everything, but that seems like a high bar to set
17:32:59 <pcarver> bgpvpn does have a reference implementation but I don't remember whether it supports both attachment types
17:34:19 <LouisF> pcarver: it would be worthwhile finding that out
17:34:57 <igordcard> too many features (big baseline) just can't live together if there are so many possible heterogeneous backends, so either one or the other in order to have a consistent, predictable API
17:35:21 <igordcard> they can't live together with the many possible backends, I mean
17:36:31 <igordcard> it's simply something where we will never tick all of the 3 columns in the trade-offs, unless sudenly by magic ovs, ovn, onos, odl, and others become very similar
17:37:03 <LouisF> I think openstack process mandates that there is a reference implementation support all features
17:37:31 <LouisF> to be able to test all features
17:39:08 <LouisF> i will check on this
17:39:31 <LouisF> #action Louis to check on reference implementation
17:39:39 <igordcard> LouisF: I don't know if it's mandated, but it is expected that if an API is live, its operations will not fail due to backend-disparity reasons
17:40:24 <igordcard> and will yield the same effect/(intent?)
17:40:44 <igordcard> LouisF: nice, thanks
17:40:44 <LouisF> igordcard: does "expected" mean we can document an exception?
17:41:47 <igordcard> LouisF: like calling method X with Y parameter will always give Z exception? or does the exception depend on the backend?
17:42:22 <LouisF> #topic dynamic chain update without service interruption
17:42:36 <LouisF> we had some discussion on this last week
17:44:16 <LouisF> i think depends on the implementation on the backend driver
17:44:41 <doonhammer> LouisF: I think it depends on the definition of interruption - if a flow is in process through a chain and a new chain is inserted what happens to the in-process flows?
17:45:43 <LouisF> the addtion of a new chain must have no impact on traffic on any  existing chains
17:46:29 <LouisF> what I am refering to is where a new PPG is inserted into an existing port-chain
17:47:04 <LouisF> using a port-chain-update to add/remove a PPG
17:47:30 <doonhammer> LouisF: so existing flows still follow old paths, new flows go through new path ?
17:47:41 <igordcard> I tested this recently and saw that all flows of the port-chain get deleted, and new ones are created
17:48:05 <mohankumar> yes , i too noticed the same
17:48:17 <LouisF> doonhammer: yes
17:48:18 <igordcard> and it takes something like 1 second in a simple 1-node deployment, so I suppose some packets will be dropped during that time
17:49:17 <igordcard> haven't checked if the old datapath flows stay there until the new flows are installed, though
17:49:39 <LouisF> igordcard: correct the current design removes the current list of PPGs and then adds the new list
17:50:02 <LouisF> this of course can be improved on
17:50:52 <LouisF> by stitching in only the new PPG at the correct point
17:51:47 <mohankumar> LouisF , still new folw rules has to populate , to forward traffic to new SF
17:51:53 <fsunaval> LouisF/doonhammer: I am not sure we want existing flows to follow old path. After all the whole purpose of inserting/deleting a new VNF might be to avoid that in the first place.
17:51:54 <igordcard> LouisF: and modifying the previous hop
17:52:11 <LouisF> igordcard: correct
17:53:15 <LouisF> fsunaval: the flows will be steered to the new PPG from the upstream PPG
17:53:24 <doonhammer> fsunaval: might depend on the use case - if I insert a video compression VNF the stream will be corrupted. If I insert an inspection VNF everything should work fine yes?
17:56:13 <LouisF> doonhammer: it really depends on the implementation
17:56:58 <igordcard> state/context can be copied from one vnf to the other, but that is out of scope in networking-sfc
17:57:34 <doonhammer> igordcard: yes depends on the low level networking driver
17:57:35 <LouisF> if done carefully it in when a ovs rule in installed/removed at the upstream to steer to the new PPG
17:58:25 <LouisF> but that is not how the current driver design works
17:59:21 <LouisF> other backends eg ONOS, ODL may have different approaches
18:00:00 <LouisF> interested parties are welcome to add enhanced functionality
18:00:15 <LouisF> ok all for today
18:00:17 <LouisF> bye all
18:00:24 <fsunaval> Thanks LouisF. Bye all.
18:00:25 <mohankumar> bye
18:00:27 <igordcard> bye
18:00:29 <LouisF> #endmeeting