17:02:18 <LouisF> #startmeeting service_chaining
17:02:23 <openstack> Meeting started Thu Mar 16 17:02:18 2017 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:28 <openstack> The meeting name has been set to 'service_chaining'
17:02:56 <LouisF> hi all
17:03:00 <igordcard> hi LouisF
17:03:05 <vks1> hi all
17:03:09 <igordcard> hi vks1
17:03:19 <LouisF> agenda for today https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.283.2F16.2F2017.29
17:03:27 <LouisF> igordcard: hi
17:03:33 <LouisF> vks1: hi
17:03:42 <bcafarel> hello
17:03:48 <LouisF> bcafarel: hi
17:03:52 <vks1> LouisF, igordcard : hi
17:04:24 <igordcard> hi bcafarel
17:04:42 <LouisF> #topic CLI work
17:04:56 <LouisF> CLI in python-neutronclient https://review.openstack.org/#/c/409759/
17:05:23 <LouisF> mohan is not on call
17:05:48 <LouisF> still some comments to address
17:05:55 <LouisF> doonhammer: hi
17:06:13 <doonhammer> HI: LouisF
17:06:15 <LouisF> i will contact him
17:06:32 <LouisF> #topic API reference
17:07:08 <LouisF> pcarver: we are getting close to getting this merged
17:07:34 <bcafarel> nice
17:08:39 <LouisF> ok
17:08:56 <LouisF> #topic Pike work
17:09:19 <LouisF> SFC tap spec merged
17:09:42 <vks1> LouisF: I have started working on implementation
17:09:43 <LouisF> vks1: are you working on a patch for the API, etc?
17:09:53 <vks1> LouisF: yeah
17:09:58 <LouisF> vks1: great
17:10:23 <igordcard> vks1: you had asked whether WIP patches were common in networking-sfc?
17:10:24 <LouisF> vks1: when will you have the first patch ready?
17:11:13 <vks1> LouisF, LouisF: soon , I was talking to igordcard to submit WIP patch
17:11:56 <bcafarel> WIP patches++
17:11:58 <LouisF> you mean with -1 workflow
17:12:05 <vks1> LouisF: yeah
17:12:36 <LouisF> vks1: that is fine, lets others see design
17:13:10 <vks1> LouisF: yeah that's the idea. Also I will discuss with you for OVS driver changes
17:13:21 <LouisF> vks1: ok
17:14:04 <LouisF> moving on
17:14:18 <LouisF> #topic SFC graph
17:14:26 <LouisF> igordcard: what is the status
17:14:32 <igordcard> no updates
17:14:42 <igordcard> will post updated patches before pike-1 for sure
17:15:04 <LouisF> igordcard: thanks
17:15:33 <LouisF> and the NSH dataplane will follow?
17:15:44 <igordcard> LouisF: yes
17:15:51 <LouisF> igordcard: thanks
17:16:00 <igordcard> likely the nsh patch will support sfc graph
17:16:09 <LouisF> #topic OVN driver
17:16:11 <igordcard> I mean, it will include sfc graph compatibility
17:16:50 <LouisF> doonhammer: i see you pushed the sfc patch for ovn to ovs
17:17:14 <doonhammer> Sent patch into OVS/OVN mailing list - got detailed feedback for mickeys
17:17:21 <LouisF> and mickey had a comment
17:17:31 <LouisF> doonhammer: yeah
17:17:40 <doonhammer> so will go through his comments and work with him to resolve
17:17:52 <LouisF> doonhammer: ok
17:18:04 <doonhammer> any comments from others would be welcome
17:18:12 <LouisF> doonhammer: i will review
17:18:31 <doonhammer> trying to get all comments at once and make a push to get it in
17:18:44 <LouisF> doonhammer: ok
17:19:28 <LouisF> #topic other Pike work
17:21:21 <LouisF> vks1: you suggested adding l2/l3 insertion mode
17:22:30 <vks1> LouisF: yeah I feel that the use case will be grt for SFC
17:22:58 <LouisF> can you outline the expected behavior?
17:23:32 <vks1> LouisF: Yeah will send out an email, and we will discuss. L3 is very much what we have now.
17:23:41 <vks1> igordcard: coments ?
17:24:08 <igordcard> vks1: I'm concerned with correlation conflicts.. but an email thread is a better place to discuss
17:24:21 <LouisF> vks1: ok we can discuss on email
17:24:35 <vks1> LouisF: igordcard: ok
17:24:46 <igordcard> vks1: see, except for tap insertion mode, the others only make sense for port pairs without correlation support
17:25:41 <LouisF> igordcard: what do mean by "without correlation support"?
17:25:43 <igordcard> #action igordcard to propose peaceful coexistence between correlation and insertion mode
17:26:21 <vks1> igordcard: aggree , probably discussion will bring out concerns
17:26:50 <igordcard> LouisF: example, with correlation NSH, then NSH essentially becomes your insertion mode
17:27:41 <LouisF> igordcard: agree - the sf support nsh
17:27:44 <vks1> igordcard: so will you initiate a discussion and we will follow or it will be other way around ?
17:28:26 <LouisF> so insertion-mode is only relevent in the case where sf does not support nsh
17:28:34 <igordcard> vks1: feel free to initiate.. I think the ML is a good place to have it
17:28:49 <igordcard> LouisF: yes and no... you may still want tap SFs
17:29:05 <LouisF> igordcard: afree
17:29:11 <LouisF> agree
17:29:22 <igordcard> LouisF: perhaps tap shouldn't be an insertion mode value, but a boolean param
17:29:31 <vks1> igordcard: we can think on supporting both
17:30:03 <vks1> igordcard: enterprise DC's has a big use case with these devices
17:30:20 <LouisF> igordcard: yes, we can certainly do that
17:30:39 <vks1> LouisF: ??
17:31:20 <LouisF> vks1: as igor suggested have a tap boolean
17:31:38 <vks1> igordcard: will you start discussion on ML with the peaceful coexistence
17:31:58 <igordcard> vks1: i
17:32:01 <igordcard> vks1: I can
17:32:07 <vks1> igordcard: that would be grt
17:32:19 <LouisF> vks1: to tap can be applied for nsh-ware sf and non-nsh-aware sf
17:32:47 <LouisF> to -> so
17:33:48 <vks1> LouisF: If the TAP is NSH aware it won't be a problem
17:34:27 <igordcard> vks1: the problem here is that other insertion modes conflict with the correlation attribute
17:34:27 <LouisF> vks1: agree - tap should work for nsh-aware sf
17:35:16 <igordcard> vks1: so maybe decoupling tap from the insertion modes field would be clearer in the API and we wouldn't have to manually validate so many combinations
17:35:45 <LouisF> igordcard: +1
17:35:47 <vks1> igordcard: even that should be fine
17:36:24 <vks1> igordcard: but then are you suggesting we won't be needing insertion mode
17:36:29 <igordcard> vks1: if we just say that insertion modes are only valid for sfc-proxied (non nsh aware) vms, then we would have to make an exception for tap - as an example of a specific combination that wouldn't work and so would require validation
17:36:32 <vks1> igordcard: ?
17:37:26 <igordcard> vks1: I'm assuming insertion mode will include l2, l3, tap and maybe others
17:37:54 <LouisF> vks1: suggest we remove tap from insertion-mode and simply have a separate field: tap-enabled
17:38:59 <igordcard> vks1: is tap commonly referred to as an insertion modes for functions, the same way l2 and l3 are? like, are they usually in the same bucket of insertion modes?
17:39:26 <vks1> igordcard: yeah
17:40:08 <igordcard> vks1: because their nature looks very different to me, where l2/l3 are about how you attach, in line, a function, tap goes outside the line
17:40:18 <LouisF> igordcard: its clearer if tap is separate from insertion-mode as you suggest
17:40:23 <LouisF> igordcard: +1
17:40:41 <vks1> igordcard: yeah the deployment is different
17:41:03 <igordcard> vks1: okay so it might not help with communicating the message to humans.. but trade-offs...
17:41:35 <vks1> igordcard: so I think both you and Louis are in opinion to keep TAP out of bucket, lets start with that
17:42:36 <vks1> igordcard: and once the discussion evolve with your email, we can change if needed
17:42:48 <vks1> igordcard: LouisF: agreee ??
17:42:54 <LouisF> +1
17:43:01 <igordcard> LouisF: so should insertion mode be renamed to something like proxy mode? given that the *mode will not be important if port pairs support correlation
17:43:22 <LouisF> #agreed use tap-enabled and not insertion-mode
17:43:49 <igordcard> vks1 LouisF : I'll kick off the email by presenting the 2-3 possibilities, their pros and cons, and we'll continue from there ok?
17:43:50 <vks1> igordcard: are you talking for L2/L3 devices ?
17:44:25 <igordcard> vks1: yes for l2/l3
17:44:31 <LouisF> vks1: insertion-mode/proxy-mode can be  used for l2/l3
17:44:35 <vks1> igordcard: LouisF: I will remove insertion mode as of now for TAP
17:44:54 <vks1> and will use tap-enabled as suggested
17:45:00 <LouisF> vks1: ok great
17:45:33 <igordcard> #action igordcard to send email about possible directions regarding insertion modes
17:45:48 <igordcard> vks1: alright
17:46:14 <LouisF> ok
17:46:25 <igordcard> LouisF: we should amend the spec right?
17:46:36 <LouisF> igordcard: yes definitely
17:47:07 <LouisF> i will post a patch for that
17:48:07 <LouisF> good discussion - any other ideas for pike work?
17:48:33 <igordcard> LouisF: allow port pairs to be reused by port pair groups
17:49:03 <igordcard> LouisF: of course, if they support nsh
17:49:25 <LouisF> igordcard: the problem is that breaks load balancing in a port-pair-group
17:49:35 <vks1> LouisF: we should think to remove cross-subnet limitation
17:50:11 <LouisF> vks1: yes that is worthwhile
17:50:27 <igordcard> LouisF: with the nsp/nsi context you can load balance
17:51:05 <LouisF> igordcard: unclear what you mean?
17:51:43 <igordcard> LouisF: essentially, given a nsp/nsi pair you can load balance across the port pairs of the next group
17:52:12 <igordcard> LouisF: some of those port pairs might belong to another group, but that other group will not clash in anyway with the first one because you'd be looking at different nsp/nsis
17:53:10 <igordcard> *might belong to another group too
17:53:59 <LouisF> igordcard: can you send an email on the proposal
17:54:11 <igordcard> LouisF: yeah
17:54:39 <LouisF> igordcard: sounds good let me look it over
17:55:39 <LouisF> one thought is putting a classifier into a VM
17:56:20 <igordcard> LouisF: +1 I have something like that in my vision for sfc
17:56:24 <LouisF> this may tie-in with the common classifier work
17:56:42 <igordcard> LouisF: it would be interesting to see a DPI classifier in a VM
17:56:50 <LouisF> igordcard: +1
17:56:50 <vks1> LouisF: +1
17:56:56 <vks1> +1
17:57:06 <LouisF> violent agreement here
17:57:18 <igordcard> ahah :p
17:57:27 <bcafarel> let me add some +1 then :)
17:57:34 <vks1> ok I disagree on one of the part :P
17:57:53 <LouisF> ok we can discuss later thanks all
17:58:17 <igordcard> thanks all, bye
17:58:24 <LouisF> bye all
17:58:29 <bcafarel> bye
17:58:32 <vks1> bye
17:58:36 <LouisF> #endmeeting