17:00:01 <cathy_> #startmeeting service_chaining
17:00:02 <openstack> Meeting started Thu Jul  9 17:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:06 <openstack> The meeting name has been set to 'service_chaining'
17:00:22 <cathy_> hi everyone
17:00:38 <Vikram_> cathy_:hi
17:00:39 <Swami> cathy_: hi
17:00:45 <Mohankumar_> Hi !
17:00:47 <bouthors> cathy_:hi
17:00:55 <LouisF> hi
17:01:01 <Brian__> hi
17:01:28 <pcarver> hi
17:01:31 <cathy_> #topic SFC spec, https://review.openstack.org/#/c/192933/8/doc/source/api.rst
17:01:38 <amotoki> hi
17:02:17 <cathy_> any questions you would like to discuss?
17:02:22 <cathy_> on the spec?
17:02:41 <cathy_> amotoki: hi, glad that you join the meeting
17:02:58 <s3wong> hello
17:03:24 <numan> hi
17:04:03 <cathy_> let's discuss the parameter which is now changed to ChainParameter object
17:04:22 <bouthors> cathy_: can we discuss how to make the classifier parameters more general, as per the email I sent to the list ?
17:04:23 <s3wong> cathy_: we are still in patch set 8
17:04:47 <s3wong> cathy_: so there hasn't been update based on the various comments from armax
17:05:08 <cathy_> s3wong: I am going to upload a new one soon
17:05:21 <s3wong> cathy_: OK
17:05:30 <cathy_> I have posted replies but will post a new version soon
17:05:33 <armax> s3wong, cathy_: yes I am looking forward to it
17:05:49 <cathy_> bouthors: Yes, we can discuss that
17:05:53 <armax> I’ll review it to make sure we captured all the main points of our latest discussions
17:05:59 <cathy_> armax: OK
17:06:51 <bouthors> cathy_: ok
17:06:54 <cathy_> For the Chain parameter object, Louis thinks there should be a link from the service chain object to this separate chainparam object.
17:07:26 <cathy_> OK with everyone?
17:07:28 <s3wong> cathy_: extension?
17:07:59 <LouisF> s3wong: what do you mean by extension?
17:08:06 <cathy_> s3wong: yes, the parameter will be modeled as an extension of the SFC object and there will be a separate API to create that chainparam object
17:08:51 <s3wong> LouisF: the parameter blob would not really be part of the API, but rather an extension
17:09:05 <cathy_> This is based on suggestion from Armando to create a separate chainparam object to specify the encap mechanism and failurepolicy
17:09:17 <LouisF> armando you proposed a separate chain parameter extension - seems a good idea
17:09:17 <bouthors> cathy_: so in the cli we will have to provide a name or a uuid for the chainparm object
17:09:33 <LouisF> bouthors: yes
17:09:55 <cathy_> For this phase, the encap mechansim in the chainparam will be "none"
17:10:24 <s3wong> cathy_: +1
17:10:54 <cathy_> which means we will not support the NSH for now which is suggested by Armando and Paul since OVS has not officially support NSH yet
17:10:54 <bouthors> cathy_: why do we call it "encap mechanism" instead of "chaining mechanism"?
17:11:27 <Swami> cathy_: this is to get rid of the dependency in the OVS.
17:11:45 <cathy_> bouthors: I am open to the naming.
17:12:08 <cathy_> Swami: yes, kindof
17:12:16 <Swami> cathy_: thanks
17:12:18 <LouisF> we will add the chainparam it the next version of the doc so please review
17:12:31 <LouisF> it -> to
17:12:42 <s3wong> Swami: this is more to simplify stuff to ensure we have everything we need in OVS such that we can make progress in Liberty
17:12:56 <cathy_> for naming, which one we should use?  everyone?
17:12:59 <Swami> s3wong: understood
17:13:19 <cathy_> encap or chaining mechanism?
17:13:42 <pcarver> chaining mechanism sounds more general. I think that could be good.
17:13:53 <s3wong> cathy_: do we expect it to do more than specifying encap mechanism?
17:14:02 <bouthors> cathy_, there could be multiple ways to encapsulate in NSH for example.
17:14:04 <LouisF> encap-mech seems fine to me
17:14:07 <amotoki> is it about packet format? or is it more than it?
17:14:35 <cathy_> amotoki: it is about packet format
17:14:37 <pcarver> we've done some service chaining research based on MAC re-writing that doesn't use any encapsulation
17:14:53 <cathy_> pcarver: that means the mechanism is none
17:14:57 <amotoki> if it is about packet format, "encap" sounds better to me. we will think more than the format by "chaining mechanism"
17:15:33 <LouisF> dolson have a well defined way using vlan-id to steer
17:15:48 <cathy_> it is about packet format and how to correlate a packet with a chain
17:16:04 <LouisF> how about correlation-mech
17:17:11 <LouisF> i'm open to any reasonable as long as its meaning is well undestood
17:17:36 <cathy_> The mechanism could be NSH-type1, NSH-type2, VLAN, Virtual EthernetPort, etc. For this phase, it will be none. We can discuss in later phase which one to support
17:18:06 <bouthors> but then you could has NHS for data center, and NSH for Gi-LAN
17:18:27 <cathy_> bouthors: that is counted as one mechanism
17:18:41 <cathy_> it does not matter which scenario it is used.
17:19:04 <cathy_> SO how about we call it "correlation mechanism"? Any "no" to this naming?
17:19:15 <LouisF> +1
17:19:26 <bouthors> +1
17:19:31 <Vikram_> +1
17:19:31 <pcarver> +1
17:20:01 <cathy_> #agreed We will use "correlation mechanism"
17:20:22 <Mohankumar_> +1
17:20:22 <Swami> +1
17:21:04 <cathy_> In the chain object, we will have ref to the chainparam object and have a separate API to create the chainparm. Any objection on this?
17:21:23 <cathy_> Let's vote:-)
17:21:26 <LouisF> +1
17:21:30 <bouthors> +1
17:21:55 <Vikram_> +1
17:22:19 <pcarver> +1
17:22:36 <Brian__> +1
17:22:38 <Mohankumar_> +1
17:22:39 <cathy_> #agree In the chain object, we will have ref to the chainparam object and have a separate API to create the chainparm
17:22:43 <Swami> no objection
17:22:50 <cathy_> Swami: :-)
17:23:27 <cathy_> now let's discuss format of the ChainParam?
17:24:15 <cathy_> Sorry what I mean is the parameter attribute format of the flow classifier
17:24:23 <cathy_> 1. A single parameter attribute (dict of name-value pairs for the classifier fields) as shown here.  2. Individual attributes for the classifier fields.
17:24:41 <cathy_> Which option we should go for? everyone?
17:25:07 <LouisF> bouthors: you have proposed a general way of encoding the classifier parameters including L7 parameters
17:25:09 <cathy_> 1. as shown in the spec? or 2?
17:25:38 <cathy_> bouthors: what's your input?
17:25:38 <bouthors> we should push for a mechanism allowing for some extensions.
17:25:49 <cathy_> bouthors: agree
17:26:07 <bouthors> my proposal is a have a dictionnary of fields
17:26:16 <LouisF> bouthors: do you have link to your  doc?
17:26:31 <cathy_> bouthors: OK, how about others' opinion?
17:26:32 <bouthors> and then the chainparm can contain a list of pairs fieldname, fieldvalue
17:26:46 <LouisF> #link https://docs.google.com/document/d/1NkDwbAkPEfe-JuO37P5ZJ3wMH3LFpKCZBoB82hsb-t8/edit
17:26:53 <bouthors> I gave an example in the mailing list.
17:27:18 <bouthors> LouisF, thx
17:27:40 <LouisF> what we have today is dict of name-value pairs
17:28:27 <LouisF> armax: you mentioned that dict result in a lot of complexity in the coding and db
17:28:42 <armax> LouisF: ues
17:28:43 <s3wong> LouisF: wow... that is complicated...
17:29:06 <LouisF> s3wong: is there a better way to handle extensibility?
17:29:21 <bouthors> For example, ODL wants a way to do chaining between GBP groups of different tenants. We will not be able to define such a chain.
17:29:40 <armax> LouisF: let’s take this offlne, I don’t think we’ll be able to wrap this up here
17:29:51 <s3wong> so how many APIs we have to go through before we can specify something like "all traffic with destination port 80"
17:30:45 <s3wong> LouisF: I do think we need to strike a balance between extensibility and usability --- particularly during phase one
17:30:46 <LouisF> s3wong: we need to have an api that is reasonably straight-foward and yet allows for extensibility
17:30:56 <bouthors> The idea is that the dictionary are preconfigured. so in practise we don't change the number of APIs
17:31:30 <bouthors> The idea is that the dictionary are preconfigured. so in practise we don't change the number of APIs used
17:31:41 <cathy_> armax: I think we need to reach consensus so that we can update the spec based on consensus. Louis has listed two options. ANy other option? Let's discuss the cons and pros of each one and pick one.
17:32:25 <cathy_> s3wong: what is your suggestion? 1 or 2 or another way?
17:32:42 <LouisF> having individual attributes for the more common classifiers fields eg protocol, src/dest port, ip-prefixies make sense
17:33:49 <s3wong> cathy_: even with dictionary of fields, the fields need to be specified, right?
17:33:59 <cathy_> Individual attributes means we do not group the flow descriptors.
17:34:05 <cathy_> s3wong: yes
17:34:21 <LouisF> then additional fields can be handled by a more extensible format
17:34:37 <LouisF> s3wong: yes
17:34:51 <armax> cathy_: let me go over LouisF’s comments on the spec
17:35:07 <cathy_> dictionary means we group the flow descriptors into a "parameter" field.
17:36:01 <LouisF> armax: my comment: The parameter attribute was introduced to allow for extensibility. Two options here:  1. A single parameter attribute (dict of name-value pairs for the classifier fields) as shown here.  2. Individual attributes for the classifier fields.  Defer to experts on REST API design for best approach for extensibility, readability, and simplest design.
17:36:05 <cathy_> armax: OK. let us know your pick when you are done.
17:36:44 <bouthors> I woud rather choose option 2
17:37:03 <Vikram_> I vote for 2.
17:37:32 <LouisF> +1 for 2
17:37:54 <cathy_> s3wong: ?
17:37:57 <armax> cathy_: at first glance it looks like 2 would be the way to go
17:38:07 <cathy_> AFAIK, Armando likes 2 too
17:38:29 <cathy_> armax: cool. So looks most people likes 2
17:38:33 <armax> cathy_: well I dislkike the dict approach
17:38:36 <s3wong> cathy_: sure, option 2 would be better than parsing a dictionary either at API level or driver
17:39:26 <cathy_> #agree the flow descriptors in Flow Classifier will go for Individual attributes for the classifier fields.
17:39:35 <Swami> :q!
17:39:43 <cathy_> Cool!
17:40:06 * s3wong thinks Swami is using vi commands on his IRC client
17:40:12 <cathy_> Any more questions on the spec that anyone would like to discuss?
17:40:20 <LouisF> will update next version with option 2
17:40:22 <Swami> s3wong: sorry wrong context
17:40:38 <s3wong> Swami:   :-)
17:40:49 <LouisF> Swami: understood
17:41:40 <cathy_> pcarver: do you have more comments? we can discuss here. otherwise we will update based on all the comments and consensus. We need to get the spec merged as soon as possible which is the team's desire.
17:42:33 <LouisF> will update with the CLI commands
17:42:52 <LouisF> per your suggestion armando
17:43:17 <cathy_> Do we need to post REST API (JSON) examples in the spec?
17:43:56 <Vikram_> +q
17:43:58 <Vikram_> +1
17:44:06 <Vikram_> It will be good..
17:44:20 <LouisF> i think the tables are sufficient
17:44:25 <pcarver> cathy_: no I don't have a strong opinion on this point
17:44:27 <Mohankumar_> Vikram agree
17:44:32 <amotoki> JSON example would help us understand. I think we can skip CLI example.
17:44:44 <cathy_> pcarver: OK, thanks.
17:44:51 <Vikram_> cathy_:atleast resource name becomes clear and CLI will not have last time surprises
17:45:04 <Swami> you can just add a wiki to show how the rest api works or looks.
17:45:44 <cathy_> So we will post a few JSON examples for illustrative purpose.
17:45:57 <Vikram_> +1
17:46:17 <cathy_> #agree the next version will post a few JSON examples for illustrative purpose
17:46:44 <bouthors> Why do we need to have exclusivity between neutron_port and using other individual ones in ChainingParms?
17:48:38 <LouisF> bouthors: is a neutron port is specified that woul include MAC address, IP address, etc
17:48:48 <cathy_> Each chain can have multiple classifiers. If the user wants multiple flows to go through a chain, he cna specify multiple classifiers with one using neutron port and others using IP address etc. params.
17:49:02 <cathy_> It is more clean to not mix them in one classifier.
17:49:32 <bouthors> But we cannot say "trafic from this port, aimed at this dest"
17:49:42 <cathy_> Neutron port itself already includes IP address etc.
17:50:36 <cathy_> I think I added a reply int the spec that we will add source neutorn port and destination neutron port.
17:51:05 <LouisF> bouthors: yes, good point
17:51:44 <cathy_> bouthors: could you be more specific about your point?
17:52:09 <cathy_> we have 8 minutes left
17:52:24 <LouisF> so you mean from, say, neutron-port=X, tcp-port=80
17:53:04 <bouthors> we can take it on the mailing list,  I was thinkg neutron-port-src=W, des=x.y.x.z.t/24
17:53:30 <cathy_> your case is covered already
17:53:53 <cathy_> sorry not covered
17:54:07 <bouthors> ok
17:54:26 <cathy_> Ok, I think we probably should lift the restriction to allow more flexible specificaiton of the flow descriptors
17:55:26 <LouisF> bouthors: agree we need to support that, but what if it both src-neutorn-port=X (which has an IP address) and src-ip=10.1.1.1 are specified?
17:55:32 <cathy_> I think we should remove the restriction. Any different opinions on this?
17:55:58 <LouisF> need to set precedence rules for the validation
17:56:03 <s3wong> cathy_: what is the restriction?
17:56:38 <Vikram_> LouisF: what do you mean precedence?
17:56:56 <LouisF> s3wong: see line 221
17:57:03 <bouthors> The parameters given must not contract themselves. For ex port-max < port -min , but also Louis example
17:57:19 <Vikram_> you mean follow some order for classification?
17:57:55 <LouisF> Vikram_:  no, see my comment above:  at if it both src-neutorn-port=X (which has an IP address) and src-ip=10.1.1.1 are specified?
17:58:06 <cathy_> Vikram_: Louis means the code internally needs to do some validation as bouthors mentioned.
17:58:33 <Vikram_> cathy_, LouisF: understood
17:58:49 <LouisF> will update spec on this
17:59:00 <cathy_> #agreed remove the restriction about Neutron port and other flow descriptors.
17:59:20 <s3wong> one minute
17:59:24 <cathy_> #agreed remove the restriction about combination of Neutron port and other flow descriptors.
17:59:30 <Vikram_> left :-)
17:59:43 <amotoki> do we have any meeting agenda wiki page?
17:59:43 <cathy_> great discussion.time is up. thanks everyone. bye now
17:59:53 <bouthors> bye
17:59:55 <amotoki> i would like to see pointers before meeitngs.
18:00:03 <Vikram_> bye
18:00:05 <s3wong> bye
18:00:05 <Swami> bye
18:00:05 <cathy_> amotoki: we will set it up
18:00:13 <cathy_> But we have meeting logs
18:00:16 <pcarver> bye
18:00:21 <cathy_> #endmeeting