17:00:28 <cathy_> #startmeeting service_chaining
17:00:29 <openstack> Meeting started Thu Jul 16 17:00:28 2015 UTC and is due to finish in 60 minutes.  The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:32 <openstack> The meeting name has been set to 'service_chaining'
17:00:33 <s3wong> hello
17:00:35 <cathy_> hi everyone
17:00:37 <Vikram> hi
17:00:40 <LouisF> hi
17:01:22 <Mohankumar_> Hi all
17:02:04 <cathy_> #topic •	Spec status update
17:02:06 <Swami> hi everyone
17:02:35 <cathy_> so the spec is ready for merge.
17:03:06 <cathy_> of course after the merge, we can still modify it if needed
17:03:13 <Mohankumar_> yes it looks good to go ..
17:03:26 <s3wong> cathy_: sc68cal just gave a -1... :-)
17:03:27 <cathy_> Mohankumar_: yes:-)
17:04:16 <amotoki> hi
17:04:24 <cathy_> s3wong: I will take a look and address the comments. But that will not impact the merge.
17:04:33 <cathy_> amotoki: hi, thanks for joinging
17:04:34 <s3wong> cathy_: sure
17:05:21 <sc68cal> i'm here
17:05:56 <cathy_> #topic •	SFC CLI client and Horizon Client dependency on base Neutron CLI and Horizon code
17:06:20 <cathy_> Mohankumar_: would you like to explain the issue you faced?
17:06:30 <s3wong> sc68cal: you gave a -1 on the networking-sfc API spec, and cathy_ will address it... that's all :-)
17:06:32 <cathy_> sc68cal: hi
17:07:02 <cathy_> sc68cal: yes, I will address it
17:07:06 <Mohankumar_> cathy_ , we can't do UT in networking-SFC stackforge directory as many dependency files are misssing .
17:07:43 <cathy_> Mohankumar_: why stackforge? we are on OpenStack repo.
17:07:49 <Vikram> sc68cal: i don't see any cross dependencies... even the spec itself says that..
17:08:07 <Mohankumar_> cathy_ i  mean networking-sfc
17:08:22 <Mohankumar_> repo
17:08:27 <cathy_> Mohankumar_: ok
17:09:09 <cathy_> so you mean the CLI client codes have dependency on the base Neutron CLI codes?
17:09:42 <Vikram> cathy_: +1
17:09:50 <cathy_> amotoki: Do you have any suggestion how to resolve this?
17:09:55 <Mohankumar_> cathy_ yes
17:09:56 <LouisF> sc68cal: just posted response to your comment
17:10:14 <amotoki> cathy_: i haven't caught up with the context....
17:10:35 <Vikram> cathy_: for running UT there is already a framework developed in the master branch..
17:11:54 <cathy_> My understanding of the issue is that The Python Neutron client code for SFC can not link properly to the base neutron Client codes. Maybe Vikram or Mohankumar_ can clarify more on this?
17:12:09 <Vikram> amotoki: the question here is how to run the UT for the new developed cli code..
17:12:31 <Mohankumar_> vikram +1
17:12:36 <Vikram> amotoki: as discussed before we used the extension method for writing the test
17:12:56 <cathy_> give me 2 minutes since I need to move to another conf room.
17:13:03 <amotoki> Vikram: i think it dpends on what code we have. we can talk it in reviews more efficiently
17:13:06 <Vikram> the question here is how to write the unit test for this..
17:13:41 <fitoduarte> .
17:13:43 <amotoki> Vikram: ah... I can join the review later. let me share the link
17:13:44 <Vikram> amotoki: ok,, will take it offline then!
17:14:20 <Vikram> amotoki: we have done a part of it
17:14:38 <Vikram> it will be better if you can review and suggest us the way
17:15:03 <Vikram> https://review.openstack.org/#/c/200065/
17:15:17 <cathy_> #action take the discussion of "	SFC CLI client and Horizon Client dependency" offline and amotoki will review the codes and give guidance
17:15:49 <cathy_> #topic •	OVS Driver and OVS support for classifier and SFF
17:15:52 <amotoki> i am not sure about Horizon dependency but I can help from both perspective.
17:16:26 <cathy_> amotoki: Thanks so much!!!
17:16:30 <Vikram> amotoki: thanks!
17:16:53 <amotoki> btw, SFF?
17:16:54 <cathy_> For the OVS support, if we decide to go for no SFC header with chain ID, then the OVS has to build a forwarding table based on 5-tuple or n-tuple for flow identification.
17:17:16 <cathy_> amotoki: service function forwarder, the vSwitch
17:17:32 <amotoki> got it. many abbrevs
17:17:43 <cathy_> Sorry that I am using the terminology of IETF SFC
17:17:57 <cathy_> amotoki: yes:-) It is confusing
17:18:20 <cathy_> Everyone, what's your take and input?
17:18:24 <s3wong> cathy_: and without full support of NSH in OVS, I believe that injecting flow entry on every hop within the chain is the only way to go
17:18:35 <s3wong> * injection OF flow entry...
17:19:08 <LouisF> need to decide on mods to the OVS agent to handle the flow tables
17:19:52 <LouisF> s3wong: agree
17:19:55 <cathy_> s3wong: without NSH, we also need the OVS driver to inject/program flow entries into OVS from every hop. The difference is that the OVS table index is different
17:20:04 <amotoki> s3wong: agree to some extent, but how does it bother SFC without NSH?
17:20:50 <cathy_> amotoki: it does not bother. The difference is that with chain ID, the table in OVS will be much simpler and smaller
17:21:22 <amotoki> yes. with NSH we can simplify flow tables.
17:21:26 <s3wong> amotoki: with NSH and more specifically chain ID, one only needs to inject simpler flow entries to hops
17:21:31 <cathy_> and the forwarding operation in OVS will be much efficient since the index is a single chain-ID instead of checking 5-tupe or 7-tuple
17:21:50 <amotoki> totally agree.
17:22:03 <s3wong> amotoki: but correct, we still need to inject flow entry every hop, so control plane perspective is pretty much the same
17:22:13 <cathy_> or in the future 11-tuple for more granular flow treatment
17:23:14 <cathy_> Also control plane will need to map every hop to the n-tuple instead of a single ID index
17:23:26 <LouisF> s3wong: do you see changes to the OVS Integration bridge?
17:23:54 <LouisF> s3wong: to handle the new port chain flows?
17:23:59 <cathy_> Actually as far as I know, people are working OVS to add support of chain-ID.
17:24:37 <LouisF> cathy_: you mean NSH extensions to OVS?
17:24:44 <cathy_> So maybe our reference implementation should be using chain-ID to really make the SFC performance acceptable
17:24:46 <s3wong> LouisF: changes to the communication between Neutron server and OVS agents? probably no change there
17:25:38 <amotoki> we can improve the efficiency by OVS support, but from the control plane perspective it does affect anything as ref impl.
17:25:45 <cathy_> LouisF: you can say that, but not exactly
17:26:04 <LouisF> s3wong: agree, just the flow tables processing on the OVS bridge
17:26:13 <cathy_> amotoki: you mean it DOES NOT affect anything?
17:26:30 <cathy_> It affects the OVS driver implementation
17:26:33 <s3wong> LouisF: that would be what I expect --- but of course things may change once we implement it :-)
17:26:41 <amotoki> cathy_: I mean the communication between neutron-server and angets
17:26:48 <LouisF> s3wong: agree
17:27:30 <cathy_> amotoki: it will affects since the messages between the OVS drive and the OVS agent will be different.
17:28:17 <amotoki> cathy_: so I said it affects performance or efficiency. perhaps we are in the same page.
17:28:39 <s3wong> cathy_: the message content changes. But what amotoki and I meant was the efficiency in terms of control plane (# of Neutron server -> OVS agent messages) is not affected
17:28:43 <cathy_> One is to push a chain header (the chain-ID) into the packet and then program the OVS table with ID as the index. The other does not push any header ans use n-tuple as index of the table
17:29:10 <amotoki> s3wong: right
17:29:20 <s3wong> cathy_: but certainly DATA PLANE efficiency will be drastically improved via NSH/chain-ID support
17:30:02 <cathy_> minor difference on the efficiency on control plane, I think, but I need to think about it more to be sure.
17:30:12 <cathy_> s3wong: yes
17:30:44 <cathy_> we need to reach consensus so that we can choose which implemenation to go.
17:32:12 <s3wong> cathy_: I thought we established that we will do the full-flow entry programming in OVS for Liberty (as OVS support isn't there yet)?
17:32:22 <s3wong> cathy_: so what is the other option of implementation?
17:32:31 <LouisF> s3wong: agree
17:32:45 <cathy_> other option is to support chain-ID.
17:33:16 <LouisF> cathy_: but then we have a dependency on NSH support in OVS
17:33:21 <cathy_> OK, then let's do the no-ChainID impelementation with the performance limitation in mind
17:33:25 <amotoki> I think the bottom line is that we have a referement impl support and we can go more.
17:33:34 <s3wong> cathy_: meaning that we will have someone in this team contributing to ovs-dev?  :-)
17:33:39 <cathy_> amotoki: agree.
17:33:44 <LouisF> cathy_: this is just a reference implementation
17:34:03 <amotoki> we can accpet an impl with a bit less performace.
17:34:09 <LouisF> amotoki: agree
17:34:18 <cathy_> #agreed The OVS driver and agent implementation will be no NSH since OVS does not support it yet
17:34:33 <amotoki> the ref impl will have more performacne once OVS supports us.
17:35:28 <s3wong> cathy_: chain ID also has implication on the API (w.r.t. the parameters field), right?
17:36:45 <LouisF> s3wong: the correlation field in chain-parameters will be = none
17:37:27 <cathy_> s3wong: I don;t think so. User can choose which option to go in the API and that parameter is optional.
17:37:43 <s3wong> LouisF: for now. But once OVS supports NSH / chain-ID, and we decide to adopt it, then users of the API would need to fill up the parameters, right?
17:38:01 <LouisF> s3wong: yes
17:38:40 <LouisF> s3wong: the corrlation field in chain-parameters could be set = nsh
17:38:50 <cathy_> Some status update. Now that the spec is merged, I am working on the system design as suggested by amotoki and will have it ready for review next week. Louis and I are also working on the OVS driver design document
17:39:40 <LouisF> feel free to suggestion ideas
17:39:49 <amotoki> sorry I couldn't take enough to review the API, but it is would be grate if the API provides full funtionality
17:40:08 <s3wong> cathy_, LouisF: I would also like to jump into the OVS driver design and implementation
17:40:18 <LouisF> s3wong: great!
17:40:26 <cathy_> amotoki: the API provides full functionality for supporting the SFC for the first release and options for future extension
17:40:51 <amotoki> NSH can help us bring more performacne and efficiency
17:41:00 <cathy_> s3wong: great. Thanks! let's work together on that
17:41:25 <amotoki> let me check soon early next week.
17:41:39 <cathy_> amotoki: Thanks
17:42:09 <cathy_> any other topic for the meeting discussion? We are efficient and still have 18 minutes left.
17:42:25 <s3wong> cathy_, LouisF: cool
17:42:58 <s3wong> cathy_: once we get into coding, the meeting should be morphed into more a status update moving forward :-)
17:43:10 <cathy_> s3wong: yes:-)
17:43:57 <cathy_> Given our time constraint, we need to move forward with the coding much faster to catch the Liberty release
17:43:58 <amotoki> btw, do we have a wiki page to collect our efforts?
17:44:10 <cathy_> amotoki: yes let me post the link
17:44:19 <amotoki> cathy_: nice
17:44:45 <cathy_> #link https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining
17:45:03 <cathy_> any other topic you folks like to discuss?
17:45:03 <s3wong> cathy_: agreed, we are a little over two weeks away from end of L-2
17:46:17 <cathy_> amotoki: could you guide us on what integration testing we need to do for getting into the L release? Any other gating or requirements we need to plan to get them done?
17:46:18 <amotoki> s3wong: we are not so tightly constrainted by the release cycle. networking-sfc repo has a freedom
17:47:06 <s3wong> amotoki: true... but as a team we want to hit at least a demo-able implementation by M-Summit
17:47:24 <s3wong> amotoki: this time around, the Liberty Release and M-Summit is only TWO weeks apart
17:47:27 <amotoki> cathy_: it depends on us. We are not strictly required to have integarated gating at this moment.
17:47:32 <cathy_> s3wong: agree. Let's work hard on it
17:47:58 <amotoki> we can first complete our first round and then explore better testing.
17:48:26 <amotoki> of course we can start testing along with implementation, but we have limited resources.
17:49:09 <amotoki> I think we can focus on features for LIberty and Mitaka summit
17:49:44 <s3wong> amotoki: agreed
17:49:47 <amotoki> cathy_: what do you think?
17:49:52 <cathy_> amotoki: Could you point us to the OpenStack integration gating and required testing link if we would like to satisfy those gating?
17:50:11 <cathy_> amotoki: agree.
17:50:34 <amotoki> cathy_: functional testing is now being moved to in-tree
17:51:05 <cathy_> As s3wong said we would like to have some good codes for demo ready for the Liberty summit to feel good about ourselves:-)
17:51:15 <amotoki> so most things are up to us, the community. can we believe we have enough tesitng? we can ask ourselves.
17:52:06 <LouisF> amotoki: what do you mean by "in-tree"?
17:52:21 <cathy_> amotoki: Ok. thanks. I still would like to make the testing very comprehensive and strict. Let's work on that part later
17:52:26 <amotoki> if we have a good coverage to some extent, we can say SFC is a good and mature project :-)
17:53:03 <amotoki> LouisF: under "big tent" content, we no longer have all functioanal and scenaro tesitng in tempest.
17:53:21 <cathy_> amotoki: sure, that should be the way this project is delivered
17:53:25 <s3wong> LouisF: not Tempest, I suppose that is what amotoki meant?
17:53:43 <amotoki> s3wong: LouisF: correct.
17:54:03 <amotoki> tempest decided not to have all tests in their repository in Vancouver.
17:54:19 <cathy_> amotoki: you mean we should check in our funcitonal testing codes into our project repo, right?
17:55:06 <amotoki> cathy_: what i want to say is that we need to have funcational testing in our repo gradually.
17:55:21 <cathy_> amotoki: OK
17:55:49 <amotoki> tempest team can help us but they feel they don't scale.
17:56:21 <cathy_> amotoki: Ok, i see
17:56:36 <amotoki> we need to share our knowledge as a whole neutron stadium. I am learning too.
17:56:38 <cathy_> So it seems no more "topic" for this meeting. Then let's end this meeting and go to work on the code design/implementation. OK?
17:57:00 <cathy_> amotoki: Is there a link for that knowledge sharing?
17:57:00 <s3wong> cathy_: +1
17:57:19 <Vikram> +1
17:57:26 <cathy_> amotoki: Could you keep us in the loop on that? Thanks.
17:57:27 <Swami> cathy_: I think we should still have weekly meeting to go over the status, blocking issues etc.,
17:57:28 <amotoki> cathy_: i have no exact link ..
17:57:43 <cathy_> Swami: sure we will continue the IRC meeting
17:57:49 <amotoki> cathy_: it is a bit late, but i try to join the effort !
17:58:02 <cathy_> amotoki: we need you !
17:58:14 <LouisF> +1
17:58:34 <cathy_> OK, thanks everyone! talk to you in next meeting.
17:58:39 <s3wong> Swami: yeah, I don't think we are suggesting stopping the weekly meeting :-)
17:58:48 <Swami> s3wong: thanks.
17:58:56 <LouisF> bye
17:59:02 <amotoki> the meeitng is a great time to share the progress
17:59:03 <Vikram> bye
17:59:03 <cathy_> bye now
17:59:11 <Mohankumar__> bye
17:59:16 <s3wong> Thanks all!
17:59:18 <amotoki> night
17:59:19 <cathy_> amotoki: yes, agree
17:59:21 <cathy_> bye
17:59:30 <cathy_> #endmeeting