17:00:28 <LouisF> #startmeeting service_chaining
17:00:29 <openstack> Meeting started Thu Jul 13 17:00:28 2017 UTC and is due to finish in 60 minutes.  The chair is LouisF. 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:38 <pcarver> hi
17:00:38 <LouisF> hi all
17:00:44 <vks1> hi all
17:01:03 <bcafarel> hello
17:01:08 <LouisF> #topic agenda
17:01:32 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
17:02:25 <igordcard> hi all
17:02:26 <LouisF> #topic CLI in python-neutronclient
17:02:32 <LouisF> igordcard: hi
17:02:49 <LouisF> https://review.openstack.org/#/c/409759/
17:03:29 <LouisF> mohan has updated  - please review this
17:03:52 <igordcard> done, lgtm
17:04:15 <LouisF> yeah i'd like this to be wrapped up
17:04:38 <bcafarel> we are probably really close now (I hope)
17:04:38 <LouisF> #topic API reference
17:04:44 <LouisF> bcafarel: yes
17:04:58 <pcarver> I think I've finally made some progress on the API definition.
17:05:05 <LouisF> pcarver: great
17:05:09 <pcarver> I think I was trying to migrate too much before.
17:06:03 <pcarver> I've reduced the amount of code that I'm moving from networking-sfc to neutron-lib and now have a new patch set up that passed tox locally. I haven't check to see if it passed the gate tests yet.
17:06:30 <LouisF> pcarver: thanks
17:07:01 <LouisF> #topic Tap SFC
17:07:14 <LouisF> vks1: what is status?
17:07:40 <vks1> LouisF: I am working on the comment given by igordcard
17:07:45 <vks1> on OVS driver side
17:08:11 <vks1> was consumed in some other task this week most of time
17:09:07 <LouisF> vks1: ok, what is status regarding  the CLI syntax?
17:09:36 <vks1> LouisF: will submit both the patch at same time
17:09:46 <LouisF> vks1: ok thanks
17:09:56 <LouisF> #topic SFC graph
17:10:05 <LouisF> igordcard: what is status?
17:10:31 <igordcard> it is finished and it's up for review
17:10:52 <igordcard> does not include OSC support yet (someone else is working on that and it might be 1 week more or so) or Heat
17:11:09 <igordcard> though I have a smaller patch with only the old neutron client so the reviewers can test
17:11:27 <LouisF> igordcard: ok, I had a question on the flow classifiers for the port chains that are included in an sfc graph
17:11:54 <LouisF> igordcard: what is the intended behavior?
17:12:03 <igordcard> LouisF: yes I have been forgetting to check some of the reviews as I've been pulled in too many directions this week
17:12:07 <igordcard> will address asap
17:12:31 <igordcard> but basically LSP/LDP are ignored when chains are part of a graph (except the initial chain)
17:12:41 <igordcard> all other classifications will still be looked up by OVS
17:13:10 <LouisF> how does the fc of source pc work with fc of dest pc?
17:13:29 <igordcard> also, for queens I will need to submit a patch that calls the full flow classifier conflict check (instead of the basic flow classifier conflict check) for chains in a graph
17:13:37 <LouisF> how about the N-tuple values?
17:13:40 <igordcard> otherwise it limits the classifications that can be used in the graph
17:14:19 <igordcard> let's consider that src chain has FC:UDP and dst chain has FC:TCP
17:15:00 <igordcard> traffic will enter dst chain if and only if it is TCP traffic and it came from src chain
17:15:03 <LouisF> so what is behavior?
17:15:52 <igordcard> it knows it came from src chain because a set of flows will be resolved in OVS that map the SPI/SI of the last hop of src chain, to the UDP flow classification that leads to the first hop of dst chain
17:16:30 <LouisF> so if the fc of source pc is UDP then only UDP traffic will egress the source pc - right , no TCP traffic
17:16:54 <igordcard> no necessarily, as functions are free to changing traffic classification due to SFC Encapsulation
17:17:47 <LouisF> igordcard: i don't understand that
17:17:52 <igordcard> if the user has not created a branch to catch non-TCP traffic at the end of the src chain, the traffic should be dropped
17:18:06 <igordcard> if indeed it is not TCP
17:18:27 <igordcard> LouisF: what part exactly does it become less clear?
17:20:37 <LouisF> if source pc1 has a classifier that matches UDP traffic then only UDP traffic will enter pc1 and egress pc1 - there will be no TCP traffic in pc1
17:21:27 <LouisF> so if dest pc2 with fc=TCP is appended to pc1 there will be no TCP traffic to enter pc2
17:21:28 <igordcard> LouisF: oh, egress means "getting into" the chain, right?
17:22:11 <LouisF> igordcard: no, "egress" means leaving pc1
17:22:20 <igordcard> LouisF: ok so I understood correctly
17:23:01 <igordcard> so regarding "then only UDP traffic will enter pc1 and egress pc1"
17:23:16 <LouisF> igordcard: yes
17:23:23 <igordcard> this is where I comment "not necessarily"
17:23:35 <igordcard> necessarily UDP traffic enters pc1
17:23:43 <igordcard> but what comes out can be something else
17:23:53 <igordcard> for the same reason you are submitting the proxy correlation map
17:23:56 <igordcard> non-transparent SFs
17:24:57 <igordcard> and by the way, the combination of proxy correlation map (or exclusive PPGs) with service graphs is excellent
17:25:37 <LouisF> igordcard: ok, you are saying that a SF in pc1 can modify the N-tuple to the traffic egresses from pc1 with a TCP instead of UDP
17:26:23 <LouisF> igordcard: ok, got it - agree it would be a good combination
17:26:28 <igordcard> LouisF: hypothetically... it's a rather stupid example, but yes
17:28:19 <LouisF> ok so the flow classifier values of each dest pc in a SFC graph can take into consideration possible N-tuple changes by SFs in the src pc
17:29:17 <LouisF> igordcard: is would be good to add text to cover some of these scenarios
17:29:37 <LouisF> doonhammer: hi john
17:29:49 <doonhammer> Hi LouisF
17:29:49 <igordcard> LouisF: yes, it can maybe be described as something like "statically-defined dynamic service function chaining"
17:30:38 <igordcard> LouisF: OK I'll look at improving the docs... feel free to leave small hints as comments and I'll expand on each of them
17:31:04 <LouisF> igordcard: one or two examples of SFC graph showing the FC values for src and dest PCs
17:31:05 <igordcard> LouisF: regarding NSH support, I'm resuming the patch now
17:31:28 <igordcard> LouisF: ok
17:31:37 <LouisF> igordcard: ok i will post an example
17:32:17 <LouisF> #OVN work
17:32:25 <LouisF> #topic OVN work
17:32:39 <LouisF> doonhammer: what is current  status?
17:33:10 <doonhammer> LouisF: no change swamped on internal tasks
17:33:18 <LouisF> doonhammer: ok, thanks
17:33:38 <LouisF> #topic proxy correlation patch
17:33:49 <LouisF> https://review.openstack.org/#/c/481840/
17:34:22 <LouisF> i want to clarify this behavior
17:34:24 * igordcard is reading pcarver's comment now
17:35:11 <pcarver> I don't have a strong preference for what's right or wrong, I was just commenting on how I read the proposal
17:36:07 <LouisF> the intention here  is for a PPG (which is currently used as a LB  group) to be used for mapping of SF instances (of the same SF type)
17:36:41 <LouisF> to different port chains thereby avoiding the need to re-classify
17:37:41 <LouisF> it a PPG is used for this proxy port correlation it will _not_ be used for LB
17:38:03 <pcarver> LouisF: yes, that's my interpretation
17:38:07 <igordcard> LouisF: and that third point is exactly where I don't agree
17:38:08 <LouisF> my last comment on the patch is incorrect - sorry for confusion
17:38:25 <igordcard> LouisF: up until now a Port Pair Group was a very clear, single-purpose resource
17:38:29 <pcarver> that if the SF alters the port tuple then the PPG has to support multiple chains with each chain using only one PP from each PPG
17:38:51 <LouisF> pcarver: correct
17:39:00 <pcarver> I don't know if that's right or wrong, but it's what the spec says as far as I can tell
17:39:00 <igordcard> LouisF: just group a bunch of service function instances and load balance across them, or use some other selection policy that doesn't even exist yet but might in the future
17:39:13 <LouisF> igordcard: correct - that has been the purpose of the PPG
17:39:58 <igordcard> LouisF: creating a proxy correlation map but still calling it PPG essentially destroys the definition of a PPG
17:39:59 <LouisF> igordcard: what i am proposing is the this group of PPs be used for a different purpose
17:40:45 <igordcard> LouisF: right.. and what I proposed todau is to simply allow PPGs to be marked as exclusive (to 1 PC) or not
17:40:54 <LouisF> if a PPG is marked as proxy-port-correlation = true then it has a different behavior
17:41:19 <igordcard> LouisF: because that gives you the same benefits in terms of SFC-proxying, and changes exactly nothing in the meaning of PPG
17:42:28 <igordcard> and the impl is much simpler
17:43:32 <igordcard> question, how do you tackle load balangin + proxy map at the same hop of the chain when using a proxy map correlation PPG?
17:43:38 <igordcard> balancing*
17:43:46 <LouisF> igordcard: but that means each chain must have a separate exclusive PPG
17:45:22 <igordcard> LouisF: well only at the hops where full proxying is required
17:45:23 <LouisF> igordcard: if a PPG is configured for proxy-port-correlation it would not support LB
17:47:37 <igordcard> LouisF: a drawback that should be documented if the proxy map route is followed
17:48:12 <LouisF> igordcard: i will add that text
17:48:48 <igordcard> I really like having the ability to to 1:1 full proxying, but I strongly support doing it in the most consistent way in terms of the API, the abstractions, and the features that are already supported in networking-sfc (LB)
17:48:50 <LouisF> however, the use of an exclusive mechanism also has benefits
17:50:34 <LouisF> suggest we adopt both methods
17:50:43 <igordcard> of course, my proposal also has its drawbacks, as you said: now the same PPG cannot be reused (for the hops that would require full proxying)
17:53:00 <igordcard> not sure I can support the proxy map correlation, but let's continue on the spec then
17:53:12 <igordcard> LouisF: also have to read the referenced draft
17:53:49 <LouisF> igordcard: we can continue in  the review
17:55:30 <LouisF> i will add text stating that the PPG can be used for LB or proxy-port-correlation but not both
17:56:07 <LouisF> good discussion
17:56:19 <LouisF> ok, all i have for now
17:56:26 <LouisF> bye all
17:56:38 <igordcard> bye all
17:56:57 <LouisF> #endmeeting