17:00:22 <cathy_> #startmeeting service_chaining
17:00:23 <openstack> Meeting started Thu Jun  2 17:00:22 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:27 <openstack> The meeting name has been set to 'service_chaining'
17:00:32 <cathy_> Hi everyone
17:00:34 <scsnow> hi
17:00:34 <mohankumar> Hi cathy
17:00:37 <iyamahat> hello
17:00:38 <igordcard> hi cathy_
17:00:40 <doonhammer> Hi Cathy
17:00:40 <georgewang> hi
17:00:47 <regXboi> o/
17:01:07 <cathy_> Let's start with topic #1 listed in the meeting page
17:01:14 <cathy_> #topic Action status
17:01:47 <cathy_> 1. use case status
17:01:52 <LouisF> hi
17:01:57 <pcarver> hi
17:02:32 <cathy_> pcarver: How is it going? Could you write a use case for this feature?
17:02:49 <doonhammer> cathy: LouisF helped by posting my use cases - I still cannot get access to tehg wiki - I have raised a case with support.openstack.org - is that the right place?
17:03:15 <cathy_> doonhammer: ok, thanks.
17:03:25 <cathy_> LouisF: have you posted the use case?
17:03:25 <pcarver> I haven't received any actual use cases from the teams that actually use our cloud. I can provide info on what features we have been asked for, but I don't have use cases for the features.
17:03:35 <igordcard> doonhammer: can you log-in successfully?
17:03:37 <LouisF> cathy_: yes
17:03:40 <regXboi> doonhammer: going to s.o.o should do the trick
17:04:03 <cathy_> LouisF: cool, could you post the link here?
17:04:21 <LouisF> https://wiki.openstack.org/wiki/Neutron/ServiceChainUseCases
17:05:00 <cathy_> pcarver: Sure, please provide features. If you can try to get one or two usage scenarios for those features, that will be great
17:05:17 <doonhammer> LouisF: I had some hyperlinks in the references - problem did not come through with the mail - I can send them to you
17:05:42 <cathy_> pcarver: you are one of the best person to provide the usage scenarios:-)
17:06:35 <fsunaval> Hi
17:06:41 <LouisF> doonhammer: ok thanks send them and I will add them
17:07:07 <pcarver> cathy_: unfortunately I don't actually use our cloud. I coordinate with a bunch of other teams that use it so I'm dependent on them to supply what details they will on what they need. Sometimes they have a tendency to only say what they want without providing details on how they'll use it when they get it.
17:07:08 <fsunaval> doonhammer:  I will send you the use case I mentioned.
17:07:15 <doonhammer> LouisF: thanks
17:07:27 <cathy_> igordcard: I know there is a use case spec in IETF. Could you "translate" them into detail usage scenarios and post them on the wiki link?
17:07:31 <cathy_> fsunaval: hi
17:07:43 <LouisF> fsunaval: you can add it to the wiki
17:07:54 <LouisF> fsunaval: at https://wiki.openstack.org/wiki/Neutron/ServiceChainUseCases
17:08:02 <fsunaval> LouisF: Ok. Will do.
17:08:44 <cathy_> pcarver: Understand. If you can push them to give more details, that will be helpful. Could you continue working on getting details on your use cases?
17:08:55 <cathy_> fsunaval: thanks!
17:08:58 <pcarver> cathy_: yes, I'll keep asking
17:09:05 <igordcard> cathy_: I'll see what I can do - I also have a concrete example of the use case I've posted at the wiki already, so I'll start with that one
17:09:05 <cathy_> pcarver: thanks!
17:09:25 <cathy_> igordcard: great. Thanks!
17:09:57 <s3wong> hello
17:10:03 <cathy_> From all those use cases, we can analyze the missing pieces to satisfy the requirements.
17:10:06 <cathy_> s3wong: hi
17:11:49 <cathy_> #action pcarver will post the required features on the wiki and will continue working on the usage scenarios
17:11:51 <doonhammer> cathy: I would image we could write simple REST applications that use the networking-sfc to match the use cases/examples?
17:12:46 <cathy_> #action igordcard will try to "translate" the IETF use cases into detail usage scenarios and post them on the wiki link
17:12:56 <cathy_> #action fsunaval will post a use case
17:13:35 <cathy_> doonhammer: Yes
17:13:35 <igordcard> #action igordcard will expand SFC Encapsulation/branching use case based on a concrete example
17:14:52 <cathy_> doonhammer: or you can use the Horizon GUI
17:15:03 <cathy_> #topic FC priority status
17:15:18 <cathy_> mohankumar: you are working on this, right?
17:15:22 <mohankumar> cathy, completed code changes and have to add/cover required UT testcases, Maybe tmrw will push and open code for review
17:15:34 <doonhammer> cathy: networking-sfc has horizon support now ?
17:16:06 <scsnow> mohankumar, did you implement support in ovs driver?
17:16:20 <mohankumar> @pavel, i've done some code changes in ovs agent as well , please check and feel free to append patch on top
17:16:24 <cathy_> mohankumar: Cool. Thank you very much for your great contribution to this project!
17:16:51 <mohankumar> thanks cathy_
17:16:51 <cathy_> doonhammer: yes, mohankumar designed and implemented that
17:17:12 <doonhammer> mohankumar: way cool
17:18:08 <igordcard> cathy_: doonhammer: are you talking about horizon too, or only fc priority?
17:18:59 <doonhammer> igordcard: horizon
17:19:15 <igordcard> doonhammer: okay
17:19:19 <cathy_> igordcard: we are talking about FC priority. And provide info to doonhammer that networking-sfc already has Horizon support
17:19:27 <igordcard> cathy_: where?
17:19:38 <mohankumar> doonhammer: yes , i ve developed horizon code  ,  but the current code having some dependency with horizon main code tree
17:19:53 <cathy_> mohankumar: could you provide the link?
17:20:18 <igordcard> cathy_: mohankumar : I see a work-in-progress patch, but I don't see horizon code in tree yet..
17:20:23 <mohankumar> https://review.openstack.org/#/c/258430/
17:20:40 <scsnow> can someone clarify what is sf_paremeters in port pairs? I see, that currently it supports correlation parameter, but it's not handled in ovs driver.
17:21:20 <scsnow> this parameter is not described in spec either
17:21:36 <cathy_> scsnow: it should have been described in the API spec.
17:22:22 <cathy_> scsnow: this param allows the specification of SF associated attributes
17:22:42 <igordcard> scsnow: perhaps to describe attributes about individual functions, like if one is notn sfc-aware
17:22:54 <igordcard> is this a correct interpretation cathy_ ?
17:23:02 <mohankumar> igordcard ,  this code still need some changes to implement  sfc as plugin
17:23:18 <cathy_> For example, the user can specify whether a SF is sfc-encap-aware or not
17:23:29 <cathy_> igordcard: yes
17:24:10 <LouisF> scsnow: sf-parameters are intended to allow various parameters be attached to a SF
17:24:21 <igordcard> mohankumar: alright, I'm interested in trying it when it's ready, I'll follow the updates
17:24:27 <cathy_> another example is to specify the weight of a SF when there are multiple functional-like SFs in a group
17:24:48 <scsnow> cathy_, LouisF, igordcard thanks
17:25:53 <cathy_> currently we only has definition of whether a SF is SFC-aware or not. In the future we can add the "weight" and more other attributes to support richer SFC features
17:26:41 <cathy_> let's go to next status item
17:26:44 <cathy_> Move the Path ID generation
17:26:57 <cathy_> Anyone working on this?
17:27:04 <LouisF> cathy_: I have added a bug for this
17:27:06 <s3wong> cathy_: doing #topic?
17:27:07 <igordcard> my question too, if not I can volunteer
17:27:08 <georgewang> I can contribute to the work of path id generation
17:27:36 <LouisF> https://bugs.launchpad.net/networking-sfc/+bug/1588460
17:27:36 <openstack> Launchpad bug 1588460 in networking-sfc "Move path-id generation from ovs driver to plugin" [Undecided,New] - Assigned to Louis Fourie (lfourie)
17:27:40 <igordcard> we can coordinate then georgewang
17:27:42 <cathy_> s3wong: this is an item under the "action status" topic":-)
17:27:53 <cathy_> igordcard: georgewang thanks
17:28:06 <s3wong> cathy_: but current topic is "FC priority status" :-)
17:28:16 <cathy_> s3wong: good point
17:28:28 <cathy_> Sorry I mistype that.
17:28:36 <cathy_> Let me use "topic" then
17:28:43 <cathy_> #topic Move the Path ID generation
17:28:59 <cathy_> #link https://bugs.launchpad.net/networking-sfc/+bug/1588460
17:28:59 <openstack> Launchpad bug 1588460 in networking-sfc "Move path-id generation from ovs driver to plugin" [Undecided,New] - Assigned to Louis Fourie (lfourie)
17:29:32 <cathy_> #action georgewang and igordcard will coordinate to implement this
17:29:50 <cathy_> #topic OVN driver for networking-sfc spec and implementation
17:30:12 <cathy_> LouisF: are you working on this?
17:30:30 <LouisF> cathy_: fsunaval and I are working on it
17:30:41 <cathy_> LouisF: great. Thanks
17:30:46 <LouisF> regXboi: you also right?
17:30:48 <doonhammer> cathy: I am working with regXboi and team to get a set of patches in
17:31:01 <LouisF> and doonhammer
17:31:10 <cathy_> #action LouisF and fsunaval will work on the OVN driver spec for supporting networking-sfc
17:31:12 <doonhammer> we have patches coming for networking-sfc/ovn and ovs/ovn
17:31:22 <regXboi> ack to doonhammer's comments - we're trying to get the first wave of WIP/RFC patches in asap
17:31:43 <cathy_> #action LouisF and fsunaval and doonhammer will work on the OVN driver spec for supporting networking-sfc
17:31:44 <s3wong> cathy_
17:32:07 <LouisF> doonhammer: regXboi does this support the port-pair-group?
17:32:15 <doonhammer> cathy: once doonhammer has wiki access :-(
17:32:20 <s3wong> cathy_: didn't know LouisF and fsunaval are working on this also...
17:32:25 <cathy_> doonhammer: regXboi great progress!
17:32:27 <regXboi> it may not initially, but it will
17:32:35 <cathy_> doonhammer: regXboi thanks
17:32:46 <doonhammer> LouisF: yes I have the full networking-sfc interface into ovs/ovn
17:32:59 <doonhammer> LouisF: almost
17:33:09 <LouisF> regXboi: doonhammer can send you the nb-schema we have for port-chains
17:33:31 <s3wong> doonhammer: there are changes to OVN / OVS community, right?
17:33:34 <regXboi> LouisF: I've seen it, and short of the flow classifier, it's reasonable
17:33:40 <regXboi> s3wong: yes, there will be
17:33:48 <LouisF> including port-chain, port-pair-group and port-pairs
17:34:07 <fsunaval> doonhammer: how is load-balancing handled currently in OVN driver ?
17:34:10 <regXboi> s3wong: changes to ovnnb schema/ovn-northd/ovnsb schema/ovn controller
17:34:12 <LouisF> OVN ACLs would serve as flow-classifier
17:34:25 <regXboi> LouisF: that's where I'm going
17:34:30 <doonhammer> s3wong: yes changes to ovn-nb.ovsschema, ovn_northd.c and ovn-nbctl.c
17:34:40 <regXboi> fsunaval: the select group action in open vswitch
17:34:47 <LouisF> with an action that references a named port-chain
17:35:01 <regXboi> that's the intent for load balancing
17:35:23 <doonhammer> LouisF:regXboi: flow-classifier and load-balacning are the area that need most work
17:35:23 <LouisF> regXboi: yes the ppg would be implemented as an ovs group table
17:36:04 <LouisF> regXboi: with each bucket being a port-pair in the PPG
17:36:12 <regXboi> LouisF: ack
17:36:32 <LouisF> that is the way it is currently implemated in the ovs driver and works ok
17:38:41 <cathy_> doonhammer: regXboi it will be great to have a consistent mechanism of adding/modifying the OVS group table and flow table between the OVS driver path and the OVN path
17:39:13 <regXboi> cathy_: I don't think that is possible
17:39:33 <regXboi> the ML2 driver and the OVN approach have distinctly different views of what OVS table does what
17:39:55 <LouisF> regXboi: agree but the use of the ovs group can be similar
17:40:08 <doonhammer> cathy: not sure it is desirable as the logical model of OVN provides location independance of VNFs
17:40:21 <fsunaval> regXboi:  Also, we need to make sure that the design allows for SFC encapsulation (NSH or whatever). Simply changing the logical DI is not enough.
17:40:28 <regXboi> LouisF: depends on your definition of "similar" :)
17:40:48 <LouisF> to use the ovs group with buckets
17:41:03 <regXboi> LouisF: that, I agree with :)
17:41:52 <regXboi> fsunaval: in my mind, if the design works without encapsulation, then adding it should be relatively simple (famous last words)
17:43:28 <igordcard> regXboi: yes, at the dataplane level yes, the bottleneck then lies in the user-exposed API - unless to encapsulate for the sake of encapsulating
17:43:28 <LouisF> regXboi: sfc encap is needed to deal with the case where dpi classifers are used
17:43:47 <scsnow> Is someone working on adding NSH support in ovs driver?
17:43:59 <igordcard> LouisF: a good example, I agree
17:44:03 <cathy_> scsnow: that is our next topic:-)
17:44:29 <s3wong> scsnow: the better question is: is anyone having any success on adding support of NSH into OVS in general :-)
17:44:34 <regXboi> LouisF: that becomes (in my mind) an add-on to the basic flows
17:44:50 <scsnow> s3wong, yes, I have some problems with patched 2.5.90 =)
17:45:13 <igordcard> scsnow: was waiting for the next topic, but yes I've started in a local branch
17:45:13 <cathy_> scsnow: what do you mean problems?
17:45:40 <cathy_> scsnow: not working?
17:45:46 <cathy_> OK, let's go to the next topic
17:45:49 <LouisF> regXboi: we should look at that
17:45:54 <scsnow> It does not pass packets. having:
17:45:56 <scsnow> Jun  1 14:31:45 localhost ovs-vswitchd: ovs|00019|odp_util(handler4)|ERR|attribute tcp_flags has length 4 but should have length 2
17:45:59 <regXboi> LouisF: look at what?
17:46:04 <s3wong> scsnow: problem as in not working (doesn't exist) at all?  :-)
17:46:06 <LouisF> sfc encap
17:46:11 <igordcard> scsnow: are you using yi's april patches?
17:46:29 <regXboi> LouisF: getting the basic stuff working without sfc encap is my first goal
17:46:31 <scsnow> I use patches from https://github.com/yyang13/ovs_nsh_patches
17:46:38 <LouisF> regXboi: ok
17:46:54 <igordcard> scsnow: yep those
17:47:13 <mohankumar> scsnow , our ONOS development team  used it and they able to make it work
17:47:20 <cathy_> igordcard: scsnow two topic threads are being discussed here. let's hold on the discussion on Yi' NSH patch to next topic:-)
17:47:29 <scsnow> cathy_, ok
17:47:34 <igordcard> scsnow: I have compiled that OVS but haven't actually made packets flow through yet, I'll try it an come back to you
17:47:44 <igordcard> and*
17:47:55 <s3wong> cathy_: agreed
17:48:08 <s3wong> LouisF, regXboi: anything else to discuss for OVN SFC driver?
17:48:30 <LouisF> regXboi: are you working in a repo?
17:48:32 <regXboi> s3wong: no - just trying to get patches out ...
17:48:49 <regXboi> LouisF: no - I'm trying to get the patches submitted to r.o.o and patchworks
17:48:50 <cathy_> regXboi: I think Louis's point is that if you take encap into consideration, the place to set the next hop could be changed. You may want to set the next hop in the ingress place, not the egress place
17:49:04 <cathy_> regXboi: we can take this detail discussion off line via emails
17:49:14 <regXboi> cathy_: that becomes an addition flow rule, that's all
17:49:25 <LouisF> cathy_: ok
17:49:26 <regXboi> so the base stuff goes in, and that goes in as a new flow rule
17:49:43 <regXboi> but I agree that the ML is a good place...
17:49:46 <s3wong> I think they are working with doonhammer's private repo --- which hopefully can instead be a patch posted on gerrit against networking-sfc soon
17:50:03 <doonhammer> s3wong: that is the plan
17:50:12 <cathy_> doonhammer: cool.
17:50:18 <cathy_> can we go to next topic?
17:50:29 <LouisF> +1
17:50:31 <regXboi> s3wong: *that* is my goal
17:51:01 <s3wong> doonhammer, regXboi: cool
17:51:48 <cathy_> #action doonhammer regXboi will post a patch in gerrit against networking-sfc after it is baked complete enough
17:52:08 <cathy_> #topic add PPG parameter to specify insert-mode behavior for all PPs in a PPG
17:52:34 <cathy_> This is about the L2/L3 mode doonhammer raised before
17:52:45 <cathy_> who would like to work on this item?
17:53:14 <LouisF> i have added a bug for that https://bugs.launchpad.net/networking-sfc/+bug/1588463
17:53:14 <openstack> Launchpad bug 1588463 in networking-sfc "Add port-pair-group parameter" [Undecided,New] - Assigned to Louis Fourie (lfourie)
17:53:18 <scsnow> cathy_, is this just an api change or it should be supported in ovs driver as well?
17:53:28 <cathy_> #link https://bugs.launchpad.net/networking-sfc/+bug/1588463
17:53:35 <s3wong> cathy_: how do we do L3 insertion in OVS driver?
17:53:47 <LouisF> scsnow: it would be a api change
17:53:54 <cathy_> scsnow: it should be supported in the OVS driver
17:54:05 <fsunaval> s3wong: we change the MAC DA.
17:54:20 <cathy_> LouisF: this bug is for APi change, but we should have codes in OVS driver too
17:54:29 <LouisF> doonhammer: you have the use case for bitw SFs?
17:54:55 <LouisF> cathy_: i can add that to the bug
17:54:58 <cathy_> I will create another bug for the OVS driver, OVS agent change
17:55:04 <LouisF> cathy_: ok
17:55:07 <scsnow> I can do an API change
17:55:13 <LouisF> scsnow: ok
17:55:16 <doonhammer> LouisF: Yes manly for east-west/micro-segmentation
17:55:29 <s3wong> fsunaval: so do we (OVS driver for SFC) serve as a virtual router also?
17:56:11 <cathy_> #action scsnow will do the API change for bug 1588463. Thanks!
17:56:11 <openstack> bug 1588463 in networking-sfc "Add port-pair-group parameter" [Undecided,New] https://launchpad.net/bugs/1588463 - Assigned to Louis Fourie (lfourie)
17:56:33 <scsnow> For ovs driver change I would need some more initial description
17:56:38 <doonhammer> LouisF: For a lot of VNFs not having to participate in networking directly makes scaling and management significantly easier
17:56:42 <fsunaval> s3wong: Currently, we only support the case where the VNF is a L3 function. For this, the OVS flow rule changes the MAC DA to match that of the VNF.
17:56:52 <LouisF> doonhammer: agree
17:57:18 <cathy_> scsnow: Louis and I will add more description to that bug on the OVS driver change
17:57:38 <fsunaval> The VNF then does its stuff and sends the packet with the MAC SA changed to itself. doonhammer's case is tricky to implement in OVS. The VNF forwards the same packet without modification.
17:57:58 <scsnow> cathy_, after that I'll let you know whether I'm able to handle driver part
17:58:42 <cathy_> scsnow: OK, I will create another bug for the driver and agent part.
17:59:00 <cathy_> fsunaval: could I assign the driver and agent bug to you?
17:59:42 <fsunaval> cathy_: Yes, you can. We will need to discuss thoroughly how to implement the agent though.
17:59:48 <s3wong> fsunaval, scsnow, cathy_, LouisF: still can't quite picture it... when kanzhe and I proposed service insertion back in Juno cycle, the 'router' insertion is closest to this, but the service needs to be integrated into router
18:00:19 <cathy_> sorry we are running out of time
18:00:41 <LouisF> bye
18:00:44 <scsnow> do we have team channel in irc?
18:00:46 <mohankumar> bye
18:00:47 <igordcard> cya
18:00:49 <cathy_> Let's continue the discussion next week.
18:00:52 <LouisF> scsnow: no
18:01:02 <doonhammer> bye
18:01:02 <igordcard> a channel would be nice
18:01:04 <fsunaval> s3wong: let us discuss over email.
18:01:04 <s3wong> bye
18:01:04 <cathy_> scsnow: no. shoot emails:-)
18:01:09 <s3wong> fsunaval: sure
18:01:13 <LouisF> scsnow: lets add one
18:01:13 <scsnow> ok, bye then
18:01:18 <cathy_> bye for now
18:01:20 <fsunaval> bye
18:01:23 <cathy_> #endmeeting