17:00:51 <LouisF> #startmeeting service_chaining
17:00:52 <openstack> Meeting started Thu May 26 17:00:51 2016 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:53 <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:07 <LouisF> hello all
17:01:10 <pcarver> hi
17:01:12 <mohankumar> HI
17:01:28 <iyamahat> hello
17:01:58 <LouisF> i'd like to start by going over action items from last meeting
17:02:17 <LouisF> #topic action item  status
17:02:44 <LouisF> update of use cases to the wiki
17:02:58 <LouisF> i see that Igor has added a use case
17:03:24 <LouisF> hi John
17:03:33 <doonhammer> Hi Louis
17:03:56 <LouisF> doonhammer: any success on adding your use case to the wiki?
17:04:42 <LouisF> pcarver: will you be able to add a use case to the wiki?
17:05:03 <LouisF> s3wong: hi
17:05:20 <s3wong> LouisF: hello
17:05:29 <doonhammer> LouisF: Ubuntu said it is a bug in Openstack - opened case at support.openstack.org
17:05:40 <LouisF> s3wong: going over adding use cases to wiki
17:05:49 <pcarver> LouisF: I asked about use cases but I haven't been able to find any yet. I don't actually work with the VNFs, so I only have the abstract feature requirements, not concrete use cases for specific VNFs.
17:05:51 <s3wong> LouisF: I see, AI from last week
17:05:55 <LouisF> doonhammer: ok thanks
17:06:22 <LouisF> pcarver: ok thanks
17:06:54 <doonhammer> LouisF: I have them done - perhaps someone else can post them until I can fix my wiki access problem
17:07:38 <LouisF> I can post them it you send them to me
17:07:52 <doonhammer> LouisF: Will do
17:07:57 <LouisF> doonhammer: thx
17:08:04 <LouisF> next item I see is the flow classifier priority
17:08:26 <LouisF> mohankumar: i see there have been reviews
17:08:34 <mohankumar> LouisF :  I got little busy on other works
17:08:38 <LouisF> of your patch
17:08:56 <LouisF> mohankumar: what is the patch?
17:09:13 <mohankumar> LouisF: i ve raised WIP progress patch , may be update and open it for review
17:09:26 <LouisF> mohankumar: ok thanks
17:09:44 <LouisF> pavel was also going to help with that
17:09:58 <mohankumar> LouisF : yes
17:10:16 <LouisF> is he on the channel?
17:11:00 <LouisF> ok moving on
17:11:09 <mohankumar> LouisF:  By next week the patche will be in goos shape
17:11:14 <mohankumar> *good shape
17:11:27 <LouisF> mohankumar: great will review then
17:12:30 <LouisF> regarding the path id generation  - that work is under way
17:13:12 <LouisF> ok lets move on to agenda items we missed from last meeting
17:13:38 <LouisF> #topic SF insertion type/mode
17:14:00 <LouisF> we started discussing last week
17:16:03 <LouisF> we need to distinguish behavior of bump-in-the wire vs l2 insertion
17:16:17 <doonhammer> LouisF: A question I had was who needs to be aware of the VNF mode , I think the SFF and/or the SFProxy. They need to have the awareness ?
17:17:06 <LouisF> doonhammer: agree the SFF or SF proxy
17:18:35 <LouisF> i think this can be handled by attaching a parameter to the VNF (SF) and using a service_function_parameters attribute
17:19:05 <LouisF> like 'insert-mode=bitw' for example
17:19:15 <doonhammer> LouisF: So if we agree on that then we need to decide what needs to be done to support the various modes yes?
17:19:32 <doonhammer> LouisF: Agree on mode
17:19:34 <s3wong> LouisF: do you considered what we do today bump-in-the-wire or L2?
17:20:10 <LouisF> s3wong: you mean in our sfc ovs driver?
17:20:11 <s3wong> LouisF: we are Neutron port based, so the VNFs all have Neutron port in some Neutron network
17:20:19 <s3wong> LouisF: yes
17:21:09 <LouisF> s3wong: currently the ovs driver uses l2 mode
17:21:27 <s3wong> LouisF: but OTOH, we set flow in higher precedent table such that the flow got forwarded to VNF via tunnel, so no need to enforce all SFs in SFC to be in same Neutron network
17:21:38 <doonhammer> s3wong: bitw is fairly easy as it a passthrough, L2 and L3 get complicated as the VNF and SFF need to have an understanding
17:23:15 <s3wong> doonhammer: sure --- I just tried to picture if we switch to a different mode, how would the backend implementation (such as OVS) be different...
17:23:25 <LouisF> doonhammer: how the backend driver actually handles this is really implementation
17:23:51 <doonhammer> LouisF: by backend driver you mean ovs or ovs/ovn?
17:23:55 <LouisF> we need to pass a hint to the driver as to the VNF behavior
17:23:59 <LouisF> doonhammer: yes
17:24:15 <LouisF> doonhammer: or some other driver
17:25:17 <s3wong> LouisF: sure, on API side it is just adding a parameter and pass it straight to driver
17:25:24 <doonhammer> LouisF: Just thinking of how I would go about configuring a service chain implementation - especially at scale - how to comunicate all the info
17:25:36 <s3wong> LouisF: but at least you and I have to worry about the reference implementation :-)
17:25:48 <LouisF> s3wong: agree
17:26:29 <doonhammer> s3wong: LOL
17:27:17 <s3wong> LouisF: also, for L3, there is a RFE on L3 agent extension:   https://bugs.launchpad.net/neutron/+bug/1580239
17:27:19 <openstack> Launchpad bug 1580239 in neutron "[RFE] Add agent extension framework for L3 agent" [Wishlist,In progress] - Assigned to Nate Johnston (nate-johnston)
17:27:41 <LouisF> if we pass 'insert-mode' to the driver is can then do the right thing
17:28:24 <doonhammer> LouisF: Yes that is the first step
17:28:33 * njohnston lurks
17:29:09 <LouisF> doonhammer: if we have agreement we can move forward with that
17:30:00 <doonhammer> LouisF +1
17:30:10 <LouisF> others?
17:30:18 <s3wong> +1
17:30:35 <LouisF> ok I will open a bug for this
17:30:35 <pcarver> +1
17:30:44 <doonhammer> LouisF: it will be a port-pair parameter or port-pair-group
17:31:22 <mohankumar> +1
17:31:24 <s3wong> doonhammer: presumably port-pair-group --- the entire group should have the same insertion mode, I would imagine
17:31:43 <LouisF> probably better on the PPG as I don't see a case for a mix of bitw/l2/l3 devices
17:32:01 <doonhammer> LouisF +1
17:32:37 <LouisF> ok that meeans adding this to the PPG parameters
17:32:45 <doonhammer> Not sure if it is possible be but would be nice to enforce the same VNF in a group
17:32:59 <LouisF> doonhammer: +1
17:33:03 <doonhammer> but probably too much
17:33:34 <LouisF> need add PPG parameter - but that has been discussed before
17:34:31 <LouisF> #action Louis to add bud to add PPG parameter to specify insert-mode behavior for all PPs in a PPG
17:34:36 <LouisF> bug
17:34:38 <doonhammer> LouisF: may also need some info for load-balancing there too
17:34:55 <LouisF> doonhammer: agree
17:36:01 <LouisF> ok moving on
17:36:43 <LouisF> that next item is adding 'nsh' encap to the chain parameter
17:37:05 <s3wong> LouisF: long email thread on that on openstack-dev...
17:37:15 <LouisF> #topic nsh encap specification in chain-parameter
17:37:21 <LouisF> s3wong: yes
17:37:25 <mohankumar> LouisF ,  yes
17:38:40 <LouisF> from the api perspective this is simple - today the encap is mpls and we can easily add nsh
17:39:04 <LouisF> the issue is the reference implementation
17:39:11 <doonhammer> Was Kyle not correct when he pointed Uri to the OVS mailing list
17:39:32 <LouisF> doonhammer: agree
17:40:18 <doonhammer> Until there is some agreement there not much we can do apart from try and push - use cases and requirements?
17:40:32 <doonhammer> not sure how else to push?
17:40:44 <LouisF> Kyle was definitely said the openstack CI did not want patches
17:40:55 <s3wong> LouisF: so Uri basically just wants us to define NSH parameters at our API level?
17:41:44 <doonhammer> I have OVN working without NSH - I am not sure moving NSF into networking-sfc or networking-ovn is the right approach
17:42:11 <doonhammer> there is a new carrier service-chaining IETF RFC that is BGP focused
17:42:34 <LouisF> s3wong: I think Uri just wants nsh encap to be added to networking-sfc
17:42:52 <s3wong> doonhammer: and I am sure in near future some other people would raise us not having support for BGP based SFC to be slowing down the industry...
17:42:56 <doonhammer> if networking-sfc is a good abstraction it should support different approaches
17:43:09 <doonhammer> s3wong: LOL
17:43:20 <LouisF> networking-sfc is an abstract API it does not deal with dataplane implementation
17:43:27 <LouisF> doonhammer: +1
17:43:37 <doonhammer> LouisF +1
17:43:58 <s3wong> LouisF: our reference can't support it at this point...
17:44:26 <igordcard> if you are goijg to support nsh, it would be preferable to allow nsh to do what it was intended to
17:44:44 <doonhammer> So I am with Kyle and we support what ever the drivers support
17:45:04 <LouisF> s3wong: we can add nsh to the ovs driver but depends on the nsh supported by ovs
17:45:12 <mohankumar> We having ONOS  +openstack reference implemention with OVS NSH , ONOS community supporting NSH
17:45:34 <LouisF> right now we use mpls encap as a proxy for nsh
17:45:58 <s3wong> LouisF: we can add NSH encap as optional parameters, one which would be implemented by ODL backend (once that is ready)... and the reference would return 'not implemented' exception --- doesn't look too clean though...
17:46:20 <s3wong> mohankumar: so ONOS also uses a forked version of OVS?
17:46:34 <mohankumar> s3wong , yes
17:46:55 <doonhammer> In real production deployments the encap is going to be different - e.g. carrier versus data center so we need to be agnostic
17:46:59 <LouisF> s3wong: are there other cases in neutron where some drivers do not provide complete functionality for an api?
17:47:19 <LouisF> doonhammer: +1
17:47:51 <s3wong> LouisF: for reference? Can't think of any. Because normally adding support in reference implementation is part of the job of extending APIs
17:48:46 <LouisF> s3wong: so the reference implementation always supports all options offered by the api?
17:49:45 <s3wong> LouisF: I believe so... can't think of any exception from top of my head...
17:50:22 <pcarver> It would be good if the reference implementation could support everything, but the problem is that it means that you have to bypass OpenStack for anything that's only supported by some backends.
17:50:50 <s3wong> LouisF: and it is a good rule of thumb anyway, as it is difficult for user to try out new APIs but the default keeps returning 'not implemented' exception
17:51:12 <LouisF> s3wong: ok if that is the case the ovs driver needs to support nsh
17:51:29 <pcarver> It's a high bar for the reference implementation to have a superset of all possible features, so what's more likely is that we would lack an API for some things that multiple SDN controllers each have their own API for
17:51:32 <s3wong> LouisF: correct... unfortunately...
17:51:33 <LouisF> the ovs driver is our reference implematation
17:52:33 <s3wong> LouisF: for analogy --- for a long time, OVS has no conntrack, and therefore security group's reference is iptables on Linux bridge hooking up with OVS
17:53:14 <LouisF> s3wong: good case in point
17:53:42 <s3wong> LouisF: our problem is we need to have the same network driver as core driver for SFC to work, so even using a non-core supported fork of OVS is not acceptable
17:54:13 <LouisF> s3wong: +1
17:54:28 <LouisF> ok we will monitor the email exhange between Kyle, Armando and Uri to see there is any compromise/resolution
17:54:35 <doonhammer> Perhaps framing it as what use cases we can support with each driver - and then ask the driver team for support in solving the other issues?
17:55:01 <doonhammer> helps to make it more specific
17:55:57 <LouisF> doonhammer: i think the ref implementation should support most if not all use cases
17:56:32 <doonhammer> LouisF: Agree but we are between a rock and a driver place :-)
17:57:30 <LouisF> doonhammer: lets see what is decided
17:57:56 <LouisF> ok i don't want to start a new topic
17:58:12 <igordcard> I can't resolve the question about nsh in the API vs. ref arch, but I don't mind doing a PoC of NSH via networking-sfc (with the latest yi yang's patch) demonstrating how SFC Encapsulation can be achieved (which requires changes to the API)
17:58:16 <s3wong> doonhammer: yeah... as cores. TBH, we are willing to entertain adding this if the community feels very strongly about it --- I mean, ODL and ONOS are both OSS projects anyway; but we are Neutron stadium, and we are subjected to be governed by Neutron driver team also
17:59:20 <LouisF> igordcard: nsh can be supported by simply adding 'correlation-nsh' in the chain-parameters
17:59:33 <igordcard> LouisF: please see my use case at the wiki
17:59:43 <LouisF> igordcard: ok
18:00:09 <LouisF> ok thats it folks
18:00:14 <LouisF> bye
18:00:19 <s3wong> thanks, guys!
18:00:19 <mohankumar> bye
18:00:20 <igordcard> bye
18:00:21 <s3wong> bye
18:00:22 <pcarver> bye
18:00:22 <LouisF> #endmeeting