17:00:54 <LouisF> #startmeeting service_chaining
17:00:57 <openstack> Meeting started Thu Mar  9 17:00:54 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:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:01 <openstack> The meeting name has been set to 'service_chaining'
17:01:16 <pcarver> hi
17:01:23 <vks1> hi
17:01:28 <igordcard> hi pcarver LouisF vks1
17:01:34 <LouisF> hi all
17:01:47 <doonhammer> Hi
17:01:51 <igordcard> hi doonhammer
17:02:02 <vks1> hi igordcard
17:02:09 <LouisF> #topic agenda
17:02:12 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.283.2F9.2F2017.29
17:02:56 <LouisF> #topic release compliance
17:03:11 <LouisF> CLI in python-neutronclient https://review.openstack.org/#/c/409759/
17:03:40 <LouisF> still in review with comments
17:03:56 <LouisF> mohan may call in later
17:04:16 <LouisF> API reference https://review.openstack.org/#/c/389385 https://review.openstack.org/#/c/411409/
17:04:28 <LouisF> pcarver: thanks for the new patch
17:05:33 <LouisF> all please review
17:05:40 <igordcard> pcarver: very very close, just 2 tiny comments to fix
17:05:56 <pcarver> igordcard: sure, I just need to fit it in between meetings
17:06:01 <igordcard> or descriptions
17:06:40 <LouisF> lets shoot to get this done by eow
17:07:03 <pcarver> one question though, if mpls is the only valid value, why even have the parameter?
17:07:23 <pcarver> I thought we allowed None
17:07:32 <igordcard> pcarver: to focus only on the future... it will support nsh too
17:07:43 <pcarver> ok
17:08:03 <LouisF> in pike?
17:08:04 <LouisF> will support nsh soon
17:08:16 <igordcard> LouisF: I'm aiming at Pike yes
17:09:00 <LouisF> #topic stable/ocata
17:09:37 <LouisF> pulled stable/ocata so master branch work is for pike release
17:09:48 <vks1> sry got disconnecte
17:10:02 <LouisF> #topic pike work
17:10:27 <LouisF> several items: Tap/bitw SF, SFC graph, NSH dataplane, OVN driver
17:11:10 <LouisF> igordcard: how is sfc graph progressing?
17:11:45 <igordcard> LouisF: I have temporarily switched to other work but am now getting back to sfc graphs
17:11:59 <igordcard> I'm aiming at pike-1 for sfc graphs and pike-3 for nsh
17:12:11 <igordcard> and if I may, just a heads-up regarding the Pike cycle and networking-sfc:
17:12:21 <igordcard> #link https://review.openstack.org/#/c/437699/
17:12:44 <igordcard> #link https://releases.openstack.org/pike/schedule.html
17:12:57 <vks1> igordcard, thats gud :)
17:13:30 <LouisF> yes need to keep pike milestones in mind
17:14:45 <LouisF> doonhammer: what is status of sfc work in OVN?
17:15:43 <doonhammer> Going to submit another patch set to ovs/ovn next week - got detoured by some other work issues
17:16:04 <doonhammer> just need to do some more polish and documentation
17:16:33 <LouisF> doonhammer: you had a question about the ovn matching?
17:16:47 <doonhammer> once ovs/ovn approves it we can add the networking-ovn layer
17:16:54 <LouisF> is the ovn classifier to be used?
17:17:16 <LouisF> doonhammer: yes
17:17:35 <doonhammer> I think I have an approach - yes the ovn classifier can be used optionally
17:18:03 <LouisF> will that be in the next patch?
17:18:48 <igordcard> does using the ovn classifier change the way we use networking-sfc's API in any way?
17:19:19 <doonhammer> hopefully a complete solution - but I will still need to add test cases - I have standalone tests but not integrated into the ovs/ovn framework - that will be the hardest task for me
17:19:19 <LouisF> igordcard: should not
17:19:26 <doonhammer> I do not think so
17:19:43 <doonhammer> I tried to make sure it did not
17:20:03 <LouisF> i favor the ovn classifier as is very rich in matching conditions
17:20:54 <doonhammer> it works well when you have uni-directional flows but can break in bi-direction flows - e.g. matching on port number etc.
17:22:07 <LouisF> doonhammer: ok
17:22:19 <LouisF> will look at the patch
17:23:02 <doonhammer> thanks
17:23:09 <igordcard> doonhammer: where is the nsfc-side patch?
17:23:20 <igordcard> doonhammer: or even neutron-side
17:24:44 <doonhammer> igordcard: not there yet - I have an old version in my git repo https://github.com/doonhammer/networking-ovn
17:25:01 <doonhammer> but it uses an old version of ovs/ovn patch
17:25:23 <igordcard> doonhammer: thank you
17:25:46 <LouisF> #topic insertion-mode
17:26:35 <LouisF> from discussion in previous meeting need for tap to a passive SF
17:27:18 <LouisF> added tap sfc spec https://review.openstack.org/#/c/442195
17:28:09 <LouisF> this adds an insertion-mode field to port-pair-group-parameters
17:29:45 <LouisF> if insertion-mode = tap then data-plane will duplicate packet: send one copy to ingress port of SF and other copy to ingress port of next downstream SF
17:30:08 <igordcard> hmm now that I think about it.. there should be a default value (different from "tap")
17:30:20 <LouisF> insertion-mode is applied to all SFs (port-pairs) in ppg
17:30:56 <LouisF> vks1: welcome back - discussing sf tap in port-chain
17:31:08 <LouisF> igordcard: such as?
17:31:12 <vks1> LouisF, bad network
17:31:42 <LouisF> vks1: discussing tap sfc spec https://review.openstack.org/#/c/442195
17:31:46 <igordcard> LouisF: probably "l3"
17:31:59 <vks1> LouisF, ok
17:32:02 <igordcard> LouisF: I'm leaving the same comment there now, and we can continue
17:32:12 <LouisF> igordcard: yes that can be default
17:33:15 <LouisF> vks1: did you add the "vikash" comments?
17:33:49 <vks1> LouisF, are we considering possibility of SF to be placed in different network of src and dest ?
17:34:40 <LouisF> vks1: do mean different subnets?
17:35:11 <vks1> LouisF, yeah more suitably different network
17:35:45 <LouisF> vks1: currently do not support cross-subnet steering
17:36:25 <igordcard> vks1: I thought you were vikash, are you not?
17:38:11 <vks1> LouisF, yeah thats true, but in term of deployment TAPs are placed on different nw than src & dest. we can discuss after we finish what we have now
17:38:22 <vks1> igordcard, yeah i am vikash :)
17:38:51 <Guest21337> LouisF, how about copying all packets going into a port - ingress traffic ? In such a case LSP in FC will be * (ANY)
17:39:12 <LouisF> vks1: you had comment on L55
17:39:24 <vks1> LouisF, yeah
17:40:19 <LouisF> vks1: do you mean that Port Chains can be made of TAP-insertion-mode PPGs only?
17:40:38 <vks1> LouisF, i guess igordcard also felt the same
17:40:58 <LouisF> right - the answer is yes
17:41:22 <vks1> LouisF, then thats fine
17:41:49 <LouisF> vks1: ok i will add text to clarify
17:42:00 <vks1> LouisF, thats fine
17:42:23 <vks1> LouisF, i thought we could have extended the scope of BP
17:42:32 <vks1> igordcard, what do u say ?
17:42:53 <igordcard> vks1: what is the scope in that context?
17:43:03 <LouisF> vks1: i would like to bound the scope of this bp
17:43:13 <LouisF> and not mix functionality
17:43:22 <vks1> LouisF, i was feeling so :)
17:44:04 <LouisF> vks1: what other functionality are you considering?
17:44:11 <vks1> igordcard, to address other insertion mode also like L2
17:44:36 <vks1> LouisF, and keep open the scope for hetrogenous chain
17:44:37 <LouisF> vks1: ok we can create a separate bp to address that
17:44:51 <vks1> LouisF, OK that would be fine
17:45:23 <LouisF> vks1: we can add another bp to address l2 insertion-mode
17:46:13 <vks1> igordcard, do you see any further addition in existing BP ?
17:46:43 <igordcard> vks1: right it's the same scope I had in mind... but I realized it's better to go type by type, better-sized blocks of effort
17:46:52 <LouisF> vks1: regarding l2 insertion-mode: what is the behavior of the l2 SF?
17:47:16 <vks1> igordcard, it would act as forwarder
17:47:38 <igordcard> the L2 insertion mode would also be a great addition, you could easily spin a VM with promiscuous interfaces and OVS inside
17:47:38 <vks1> cand can be dropped transparently anywhere in network
17:47:44 <LouisF> igordcard: agree - make review and merging easier
17:47:55 <vks1> igordcard, yeah :)
17:48:09 <vks1> LouisF, can we start on TAP ?
17:48:41 <vks1> igordcard, LouisF we will keep talking on this L2 mode also
17:49:18 <vks1> igordcard, as i also feel going type by type would be fine
17:49:29 <LouisF> vks1: agree let get tap work started and discuss l2 work
17:49:46 <igordcard> vks1 LouisF, I'd say file LP rfe again?
17:50:06 <LouisF> igordcard: that is fine
17:50:21 <vks1> vks1, yeah that should be fine
17:50:59 <vks1> igordcard, sorry i missed *LP ??
17:51:15 <igordcard> vks1: sorry LaunchPad
17:51:23 <igordcard> vks1: Launcha
17:51:29 <igordcard> Launchpad*
17:51:36 <vks1> igordcard, ok
17:51:56 <LouisF> ok i will update the patch
17:52:44 <LouisF> #topic other items
17:52:45 <vks1> igordcard, do you want any change in existing RFE except our comments getting addressed ??
17:53:21 <igordcard> vks1: nope, it looks pretty good to me besides the comments
17:53:30 <vks1> igordcard, :)
17:54:06 <igordcard> vks1: maybe only clarify that the spec is both about 1) bringing insertion types and 2) supporting the "tap" insertion type and maybe the 3) default insertion type
17:54:28 <vks1> igordcard, yeah i agree
17:54:30 <LouisF> igordcard: will add that
17:54:35 <igordcard> then the next spec will solely be about supporting the "l2" insertion type
17:54:42 <LouisF> igordcard: yes
17:54:43 <vks1> igordcard, yeah
17:55:43 <LouisF> thanks all on the ocata work
17:56:05 <igordcard> #link https://docs.openstack.org/releasenotes/networking-sfc/ocata.html
17:56:44 <LouisF> igordcard: thanks
17:56:57 <vks1> igordcard, are we doing backporting or not ?
17:57:05 <vks1> at least bugs ?
17:57:14 <vks1> sry bugfixes ?
17:57:49 <igordcard> vks1: those bugfixes are almost like small features so I don't expect so.. LouisF?
17:58:11 <LouisF> not unless that are critical
17:58:17 <vks1> ok
17:59:51 <LouisF> bye all
17:59:59 <LouisF> #endmeeting