17:00:13 <cathy_> #startmeeting service_chaining
17:00:18 <openstack> Meeting started Thu Mar 31 17:00:13 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:23 <openstack> The meeting name has been set to 'service_chaining'
17:00:33 <cathy_> hi s3wong
17:00:36 <pcarver> Hello
17:00:40 <cathy_> hi pcarver
17:00:45 <s3wong> hello
17:01:02 <raofei> Hello
17:01:06 <sridhar_ram> o/
17:01:12 <cathy_> hi raofei  sridhar_ram
17:01:22 <vishnoianil> pcarver, s3wong cathy_ hi everyone
17:01:30 <LouisF> hi
17:01:32 <cathy_> hi vishnoianil
17:01:37 <cathy_> hi everyone
17:01:40 <s3wong> vishnoianil: hi
17:01:46 <cathy_> let's start
17:02:05 <cathy_> #topic ODL SFC Driver to networking-sfc
17:02:43 <cathy_> vishnoianil: From last meeting log, I see that you have interest in working on an ODL driver to networking-sfc, right?
17:02:43 <vishnoianil> cathy_, i am currently working the blue print for the ODL SFC driver, planning to push it by this week
17:02:52 <cathy_> vishnoianil: great
17:03:11 <vishnoianil> cathy_, i discuss it with tim and also to isaku,
17:03:29 <vishnoianil> cathy_, i heard that Yi from Intel is also interested in it, so will sync up with him as well
17:03:57 <s3wong> vishnoianil: is yamahata involved with ODL SFC also?
17:04:21 <vishnoianil> he is networking-odl PTL
17:04:33 <s3wong> vishnoianil: I know he is in general the lead for ODL <-> Neutron integration at the ODL community, but not sure if he is involved specifically with ODL SFC
17:04:40 <cathy_> Good. Yi Yang already sent me email discussing on this. It will be good to sync up with him.
17:04:55 <vishnoianil> s3wong, nope, he is not
17:05:10 <raofei> How much difference between ODL north API and networking-sfc:)
17:05:43 <vishnoianil> raofei, that's the exercise tim and me are doing
17:06:10 <vishnoianil> raofei, if we find some support on the difference from networking-sfc, we will bring up for the discussion
17:06:38 <raofei> ok, so the adapter workload is not too much, right?
17:06:40 <raofei> :)
17:06:45 <vikram> Sorry to be late
17:06:45 <cathy_> raofei: In IETF, there are 3 levels of SFC API abstraction, SFC, SFP, RSP. You can think of networking-sfc as the SFP abstraction level API and ODL level as the RSP abstraction level API. Tacker as the highest abstraction level SFC API
17:06:54 <cathy_> vikram: np
17:07:10 <raofei> OK
17:07:26 <s3wong> vishnoianil, raofei: I believe ODL SFC has a different concept on SFC --- SFC for them is template / staging of the chain
17:07:44 <cathy_> The ODL driver to networking-sfc should do the mapping.
17:07:49 * s3wong sees that cathy_ already pointed that out above... :-)
17:08:44 <vishnoianil> s3wong, odl sfc is quite a bit complex then the api we have in networking-sfc
17:08:55 <cathy_> vishnoianil: we are looking forward to the BP for ODL driver:-)
17:09:14 <s3wong> vishnoianil: ODL SFC is doing a lot more than just port chaining
17:09:24 <vishnoianil> so as far as networking-sfc api can be transalated to sfc yang models, things should be fine
17:09:27 <raofei> yes, I think so.  The forwarding solution is different, but they can use the same abstract API.
17:09:55 <cathy_> vishnoianil: ODL SFC has two types of APIs. What is really implemented in ODL is the RSP API and the ODL driver can just map networking SFC API to the ODL RSP API
17:10:15 <vishnoianil> cathy_, s3wong probably we will have some hitch on things where odl-sfc needs more details and networking-sfc don't provide that through existing api
17:10:18 <s3wong> vishnoianil: the SFP portion (as cathy_ alluded to) of ODL SFC should be fully supported by networking-sfc APIs today
17:11:06 <cathy_> If there is any extension needed and those extensions are generic to all controllers (ODL, ONOS etc.), then sure we can add them
17:11:12 <vishnoianil> s3wong, yes i hope so, but devil is in details, so hopefully we won't get any big road block :)
17:11:22 <vishnoianil> cathy_, that's great!
17:12:08 <vishnoianil> cathy_, will push BP sometime this week.
17:12:20 <cathy_> vishnoianil: great, thanks.
17:12:24 <vishnoianil> and then let us jump on the implementation, we will have better feedback loop
17:12:31 <vishnoianil> on the real detals
17:12:31 <sridhar_ram> cathy_: I'd also argue of one controller supports a feature that other doesn't we still need to consider accommodating that
17:12:44 <vishnoianil> cathy_, thanks networking-sfc team for all your support
17:12:44 <sridhar_ram> s/of/if/
17:12:53 <vikram> vishnoianil: please consider current onos implementation as well
17:13:25 <cathy_> sridhar_ram: agree
17:13:35 <vishnoianil> vikram, sure, i will
17:13:45 <vikram> Thanks
17:14:02 <cathy_> what I mean is that we will not add an extension to just accommodate a specific controller implementation
17:14:23 <cathy_> If it is for a enhancement feature, sure we will support it
17:14:44 <sridhar_ram> cathy_: hopefully we should've such a need .. in general I notice ODL SFC has iterated over few years now and has wealth of features
17:14:54 * sridhar_ram argh..
17:14:55 <cathy_> vishnoianil: you are welcome!
17:15:35 <cathy_> sridhar_ram: sure
17:15:46 <sridhar_ram> cathy_: thanks!
17:15:54 <cathy_> let's go to next topic?
17:16:32 <cathy_> #action vishnoianil will push BP sometime this week.
17:16:47 <cathy_> #topic Networking-sfc driver to Tacker
17:17:05 <LouisF> we have the spec in review https://review.openstack.org/#/c/290771/
17:17:27 <cathy_> LouisF: Yes, I see that. Thanks!
17:17:39 <cathy_> Is Tim online?
17:18:22 <LouisF> Tim has added some comments and we are working through them
17:19:00 <cathy_> LouisF: yes, I already replied to all his comments and I think we have reached consensus.
17:19:07 <sridhar_ram> cathy_: I believe Tim couldn't make it to this call due to a conflict
17:19:12 <s3wong> cathy_: trozet is sort of inactive at #tacker
17:19:51 <cathy_> sridhar_ram: OK, thanks for the info
17:20:02 <LouisF> s3wong: he posted comments on the review recenetly
17:20:16 <sridhar_ram> s3wong: not really.. he is quite active pushing updates to both vnffg plugin and reviewing n-sfc driver in tacker
17:20:35 <cathy_> s3wong: could you clarify what you mean by that? I see that he has been addressing comments and replying to comments
17:20:42 <LouisF> sridhar_ram: i agree Tim has been working hard
17:21:07 <s3wong> LouisF: I saw that cathy_ has addressed some of trozet's comments
17:21:12 <LouisF> sridhar_ram: see https://review.openstack.org/#/c/290771/
17:21:51 <s3wong> sridhar_ram: no, what I meant is trozet at this moment isn't active on #tacker, although he is on #tacker
17:22:10 <sridhar_ram> LouisF: I've been following that, looks it is shaping up well.. now that Tacker mitaka release is out, I'll have more time to participate in this discussion
17:22:34 <sridhar_ram> s3wong: ah, I see...
17:22:54 <LouisF> sridhar_ram: I think networking-sfc can accomodate most of what Tim comments
17:23:40 <sridhar_ram> LouisF: that's good.. my understanding was, we need to passthru' "service_type" and possibly few other metadata
17:23:52 <LouisF> sridhar_ram: yes
17:23:59 <cathy_> From the latest round of comments to n-sfc driver, the only action item is that Tim will check with Brady and see if we can make the VNF type param in ODL API optional since we both think it is not mandatory required and used.
17:24:34 <cathy_> VNF type = service_type
17:25:23 <sridhar_ram> cathy_: Agree, it will be nice if ODL doesn't care about the type
17:26:17 <cathy_> yes, after we hear back from Tim, we can probably get the spec approved and move to implementation.
17:26:37 <cathy_> sridhar_ram: will you or Tim or s3wong help with some of the implementation?
17:26:55 <s3wong> cathy_: I can help, either on Tacker or networking-sfc :-)
17:27:42 <sridhar_ram> s3wong: thanks!
17:28:02 <cathy_> s3wong: great.
17:28:32 <cathy_> sridhar_ram: we can work on the n-sfc driver side and s3wong can work on the tacker coding side.
17:28:55 <s3wong> cathy_: I can even work on the networking-sfc side :-)
17:29:13 <cathy_> s3wong: great, thanks!
17:29:44 <cathy_> move on to next topic?
17:29:53 <sridhar_ram> cathy_: here is my understanding on the ownership...
17:30:04 <sridhar_ram> trozet: owns Tacker VNFFG plugin side
17:30:33 <cathy_> sridhar_ram: sounds good
17:30:55 <sridhar_ram> For Tacker networking-sfc driver - s3wong and LouisF ?
17:31:36 <LouisF> sridhar_ram: we can work on that once the spec is approved
17:31:47 <sridhar_ram> LouisF: sounds good .. thanks!
17:31:57 <cathy_> sridhar_ram: so trozet owns and will do coding on the Tacker VNFFG plugin side, s3wong and LouisF will do the coding on the n-sfc driver side once the spec is approved and merged
17:32:17 <sridhar_ram> cathy_: sounds like a plan ! lock it now :)
17:32:23 <cathy_> #agreed trozet owns and will do coding on the Tacker VNFFG plugin side, s3wong and LouisF will do the coding on the n-sfc driver side once the spec is approved and merged
17:33:10 <cathy_> we are assigning trozet work without him being present here:-)
17:33:29 <cathy_> #topic “Symmetric” parameter in the chain_param and let the underlying driver handle creating a reverse chain
17:34:02 <cathy_> vishnoianil: this extension comes from discussion with YiYang for ODL support
17:34:28 <cathy_> I think it is reasonable to support symmetric chain
17:34:44 <cathy_> so we need a parameter in the API for specifying that
17:35:17 <vishnoianil> cathy_, okay
17:35:23 <cathy_> when this parameter is specified, n-sfc will pass it to the controller and the controller will handle creating a reverse chain.
17:35:34 <cathy_> make sense to everyone?
17:35:53 <s3wong> cathy_: +1 --- it should be driver's work
17:36:05 <LouisF> cathy_: that would be the best approach
17:36:40 <vishnoianil> cathy_, make sense to me
17:37:48 <cathy_> pcarver: raofei Ok with you?
17:38:00 <raofei> there are many kind of chaining for different scenario. Symmetric is one of them.
17:38:01 <pcarver> cathy_: Sure
17:38:16 <cathy_> It seems vikram and mohan keep being disconnected
17:38:30 <fsunaval> Cathy, yes, the symmetric parameter makes sense.
17:38:56 <LouisF> we can add that to the chain parameter
17:39:14 <raofei> so I think it's necessary that this parameter is not only indicate the symmetric
17:39:17 <cathy_> #agreed we will add "symmetric" in the chain_param and n-sfc will pass it to the driver and let the underlying driver handle creating a reverse chain
17:39:23 <raofei> ok
17:41:32 <cathy_> raofei: we can have other chain_param extensions too. we can add them later when there is a requirement coming up. But if you have any thought now , please speak up
17:42:00 <raofei> It's better to make this parameter user-defined, but not only indicate 'symmetric'
17:42:58 <cathy_> raofei: could you clarify what you mean by "user-defined" and what else to indicate?
17:44:27 <raofei> I mean we don't define a API attribute for one scenario. try to make it extensionable.
17:45:00 <raofei> All of you are same meaning, right?
17:45:02 <raofei> :)
17:46:03 <raofei> go on please
17:46:12 <cathy_> Not sure what you mean. Maybe we can discuss off line. OK with you?
17:46:19 <raofei> OK
17:46:56 <cathy_> #topic “SFC path-ID” parameter in the chain_param for supporting the wireless Gi-Lan scenario
17:47:18 <cathy_> This requirement comes from the wireless Gi-LAN user
17:48:39 <cathy_> In the Gi-LAN scenario, the classifier is done on a separate entity called PCEF which is out of the control domain of OpenStack but the SF chain itself is under the control of openstack n-sfc
17:49:48 <raofei> Do we need to change the API for this scenario?
17:49:51 <trozet> im back in case anyone has a question for me ( I know we switched topics)
17:49:54 <cathy_> So in order to co-ordinate the chain path ID in the data plane (the classifier will add the chain path ID in the packet and the vSwitch will forward the packet based on this path ID),
17:49:56 <LouisF> see the IETF draft on PCEP extensions https://datatracker.ietf.org/doc/draft-wu-pce-traffic-steering-sfc/
17:50:27 <cathy_> a centralized Mano component will generate the chain path ID and pass it down to both PCEF and n-sfc.
17:51:26 <cathy_> So our n-sfc API needs to have a place for upper layer Mano-like component to pass this information
17:51:43 <cathy_> trozet: welcome back.
17:52:13 <trozet> cathy_: thanks :) sorry I missed the first half
17:52:48 <cathy_> we can add this path ID in the chain_param since this path ID is associated with a chain and is a unique identifier of the chain in the data plane
17:52:59 <cathy_> make sense to everyone?
17:53:15 <trozet> cathy_: i think that may even be useful for ODL implementation as well
17:53:56 <raofei> make sense to me
17:55:03 <cathy_> trozet: we discussed the status of the n-sfc driver to Tacker and the VNFFG Plugin. I think we resolved most items in n-sfc driver patch and the only left item is that you will check with Brady and see if we can make the VNF type param in ODL API optional since we both think it is not mandatory required and used.
17:55:25 <trozet> cathy_: yeah will do that and get back to you
17:55:37 <LouisF> cathy_: seems like a good solution
17:56:40 <cathy_> trozet: thanks. Also you may want to check the logs of this meeting. There is some work assignment for you (design and coding of the VNFFG Plugin piece) :-)
17:57:18 <trozet> cathy_: sounds good.  I already have that here: https://review.openstack.org/#/c/286802/
17:57:50 <trozet> cathy_: need to rebase it and add unit tests, then add other functionality thats missing
17:58:04 <trozet> I'll add you and Lous as reviewers
17:58:09 <trozet> Louis*
17:58:16 <cathy_> trozet: sounds good. thanks
17:58:50 <LouisF> trozet: is that the sfcc_id?
17:59:20 <trozet> LouisF: sfcc_id is classifier ID
18:00:03 <LouisF> trozet: what attribute in the patch is the path id?
18:00:37 <trozet> LouisF: It's not, in the POC ODL creates it automatically, but it would be good to have the ability to specify one
18:00:47 <LouisF> trozet:  ok
18:01:03 <trozet> LouisF: you can add that as a comment if you want to the spec
18:01:08 <cathy_> trozet: looks like you agree with adding the ID in the API.
18:01:14 <LouisF> trozet: will review
18:01:29 <trozet> cathy_: yeah
18:02:00 <fsunaval> I am fine with adding the chain id in the API param
18:02:04 <cathy_> #agreed add the path ID in the API chain_param
18:02:12 <LouisF> bye
18:02:18 <cathy_> time is up. Let's continue our discussion next time.
18:02:21 <s3wong> bye
18:02:21 <cathy_> bye everyone
18:02:33 <cathy_> #endmeeting