17:04:44 <pcarver> #startmeeting service_chaining
17:04:44 <openstack> Meeting started Thu Mar  2 17:04:44 2017 UTC and is due to finish in 60 minutes.  The chair is pcarver. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:48 <openstack> The meeting name has been set to 'service_chaining'
17:05:03 <pcarver> who's here for SFC?
17:05:22 <igordcard> pcarver: I am
17:05:30 <pcarver> #link https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.283.2F2.2F2017.29
17:06:32 <pcarver> Could be a quiet meeting
17:06:32 <igordcard> pcarver: do you know if cathy or louis are definitely not joining?
17:06:35 <songole> pcarver: this is songole
17:06:43 <pcarver> hi songole
17:07:04 <pcarver> igordcard: I don't know. But we can quickly run down the agenda and cover what we can
17:07:28 <pcarver> first item https://review.openstack.org/#/c/409759/ which has some +1s but no +2s
17:07:50 <songole> pcarver: I have a few qs for open discussion
17:08:16 <pcarver> I haven't reviewed it myself so I will definitely try to, but we're going to need cores from python-neutronclient
17:09:00 <pcarver> songole: sure. We should get there pretty quickly
17:09:16 <pcarver> Moving on to the API reference https://review.openstack.org/#/c/389385
17:09:41 <pcarver> I think it's almost there. Still nitpicking details but it'll eventually merge.
17:10:40 <pcarver> I have a question regarding chain_id
17:10:41 <igordcard> was checking new patchset now
17:11:03 <pcarver> see line 40 of https://review.openstack.org/#/c/389385/15/api-ref/source/v2/sfc-port-chains.inc
17:11:36 <igordcard> yes it's supposed to be known to the user
17:11:53 <igordcard> #link https://github.com/openstack/networking-sfc/blob/master/networking_sfc/extensions/sfc.py#L223
17:12:27 <igordcard> pcarver: it's similar to a Service Path Identifier (IETF)
17:12:29 <pcarver> I've added a description to https://review.openstack.org/#/c/389385/17/api-ref/source/v2/parameters.yaml
17:12:40 <pcarver> line 4867
17:12:51 <pcarver> An integer chain identifier. Not to be confused with the UUID chain ID.
17:13:08 <pcarver> let me know if you have a better description
17:13:21 <pcarver> I didn't really know what to write about it.
17:13:38 <igordcard> pcarver: OK, I'll think about it and write something
17:13:51 <igordcard> pcarver: it will be converted to NSP in the path nodes
17:14:21 <igordcard> pcarver: so "MAX_CHAIN_ID = 65535"
17:14:43 <pcarver> As for the API definition, I'm moving slowly but have been copying changes into my local copy based on other changes happening in the networking-sfc repo.
17:14:55 <pcarver> igordcard: ok, I'll add the max to the description
17:14:59 <igordcard> with NSH it could go up to 16M different IDs
17:17:02 <pcarver> For the API definition I believe the right thing to do is to refactor the "normalize" functions to neutron-lib converters
17:17:14 <pcarver> using either the existing ones or adding new ones if necessary
17:17:46 <pcarver> I don't think functions like normalize_chain_parameters should be added to neutron-lib
17:18:45 <igordcard> pcarver: right... still they would be in neutron-lib, but specifically in the api for sfc file
17:19:17 <pcarver> perhaps, but if it can be done more generically that would be preferable
17:19:38 <pcarver> neutron-lib has an existing structure for specifying and applying both validators and converters
17:20:14 <pcarver> unless the validation simply can't be expressed generically
17:21:08 <pcarver> but I'll work through it and figure out what's best and we can discuss via the review
17:21:24 <igordcard> it would be nice if it could have a method to generate validators and normalizers given a simple dict of possible key/value combinations
17:21:41 <LouisF> hi all
17:21:43 <pcarver> igordcard: I believe there are
17:21:45 <igordcard> hi LouisF
17:21:50 <igordcard> pcarver: great
17:21:53 <pcarver> hi LouisF
17:21:54 <LouisF> thanks  for starting meeting
17:22:22 <pcarver> igordcard: I need to see if I can get the same normalize result using the generic converters, either as-is or with modification
17:22:44 <pcarver> next on the agenda: Ocata release: SFC graph, NSH dataplane, OVN driver
17:23:09 <igordcard> pcarver: cool... including per-key defaults
17:23:10 <pcarver> oh, shoot. I should be setting topics shouldn't I
17:23:18 <pcarver> #topic Ocata release: SFC graph, NSH dataplane, OVN driver
17:23:43 <pcarver> I forgot about the # topic command
17:24:29 <songole> pcarver: is symmetric chain also part of Ocata?
17:24:29 <pcarver> is there anything to discuss with regard to these three items?
17:25:01 <igordcard> yep I symmetric chains are, for ovs at least
17:25:18 <igordcard> regarding Ocata: NSH dataplane had already been delayed to Pike given the OVS dependency
17:25:27 <LouisF> igordcard: ok
17:25:36 <vks1> igordcard, i tested the patch
17:25:39 <igordcard> also, I have re-targeted SFC Graphs to Pike too given the right release schedule
17:25:56 <pcarver> #info NSH dataplane had already been delayed to Pike given the OVS dependency
17:26:03 <igordcard> and finally, MPLS correlation in port-pairs is the big feature ready for Ocata (just waiting for more reviews now)
17:26:28 <songole> igordcard: patch link for mpls?
17:26:34 <pcarver> igordcard: bleeding over into the next topic on the agenda, but didn't we already cut the stable/ocata branch?
17:26:48 <igordcard> #link https://review.openstack.org/#/c/420339/
17:26:54 <LouisF> pcarver: not yet
17:26:54 <songole> thanks
17:27:23 <igordcard> stable/ocata for networking-sfc:
17:27:28 <igordcard> #link https://review.openstack.org/#/c/439200/
17:27:37 <pcarver> #topic stable/ocata branch
17:27:58 <pcarver> do we have a target date?
17:28:15 <pcarver> This was a topic of concern at the PTG
17:28:36 <pcarver> starting with Pike we need to align with rest of the stadium
17:28:59 <pcarver> For Ocata it's as soon as possible, already done would have been better
17:29:33 <LouisF> pcarver: want to pull stable/ocata branch today
17:29:47 <pcarver> LouisF: Great
17:30:17 <pcarver> igordcard: is that an issue for the MPLS patch?
17:30:19 <LouisF> pcarver: will post update to https://review.openstack.org/#/c/439200/
17:30:34 <igordcard> pcarver: well the mpls patch should be merged before the branch is cut
17:30:39 <igordcard> pcarver: it's not a bugfix...
17:31:28 <igordcard> the code has remained unchanged for the past 11 days, only documentation suffered changes
17:31:36 <pcarver> looks like I'm a couple patch sets behind, but I was ok with 19
17:31:46 <LouisF> igordcard: if it merges today i will include it
17:32:14 <pcarver> I'll look at the changes since 19 in about 2 hours. I have a meeting right after we finish this one.
17:32:28 <igordcard> correction, wrong patchset, for the last 7 days
17:32:52 <igordcard> pcarver: thank you!
17:33:43 <pcarver> anything else on stable/ocata topic?
17:34:03 <pcarver> #topic  Bug scrub
17:35:10 <pcarver> sounds no one has anything to say on bugs
17:35:18 <pcarver> #topic Open Discussion
17:35:28 <pcarver> songole: you had some items?
17:35:45 <songole> pcarver: we are starting to come upto speed on neutron-sfc
17:36:10 <pcarver> songole: sorry, could you introduce yourself. I'm not sure whether I know you.
17:36:20 <songole> we have an use case to insert IPS (inline bump in the wire) and IDS service
17:36:21 <pcarver> And who you're including in "we"
17:36:30 <songole> pcarver: sure
17:36:36 <vks1> pcarver, its me also
17:36:50 <vks1> songole, pls go ahead
17:37:22 <songole> vikash and muself work closely at One Convergence. We actively participate in GBP project
17:37:56 <igordcard> songole: any interst in using networking-sfc as SFC backend in GBP?
17:37:57 <songole> muself -> myself
17:38:26 <vks1> pcarver, i had talked to igordcard regarding same
17:38:33 <songole> igordcard: Not yet with GBP. But, we have a neutron usecase for a customer
17:40:09 <songole> Regarding the use case, vks1 tried to insert an IPS device
17:40:14 <igordcard> sorry I have to go right now, cya all, thank you
17:40:21 <vks1> igordcard, one sec
17:40:26 <igordcard> I'll catch up on the meeting log later
17:40:34 <vks1> igordcard, will send u an email
17:40:40 <vks1> igordcard, as aggreed
17:40:54 <vks1> igordcard, ok
17:40:59 <igordcard> vks1: right now destination mac addresses get rewritten, so you don't get proper BITW
17:41:09 <igordcard> vks1: yep
17:41:12 <vks1> igordcard, yeah correct
17:41:35 <songole> igordcard: thanks for clarifying..
17:42:05 <pcarver> So are we considering that a bug?
17:42:13 <pcarver> Or a new use case?
17:42:21 <vks1> pcarver, new use case
17:42:28 <LouisF> pcarver: it would be a new use case
17:42:41 <vks1> igordcard, i was trying to push this for few days
17:43:25 <songole> pcarver, LouisF: how do we go about addressing this use case?
17:43:47 <pcarver> songole: are you planning to develop or just write the use case?
17:43:49 <LouisF> vks1: currently the dest mac is used to steer packets to next hop port-pair
17:44:19 <LouisF> in the ovs driver that is
17:44:27 <vks1> LouisF, yeah but that suits only L3 device
17:44:31 <pcarver> If it's something that someone isn't already working on I think probably we should follow the Neutron process of starting with an RFE bug
17:44:59 <vks1> LouisF, I believe I have discussed this in mailing list with you
17:45:19 <songole> pcarver: ok. I will create one
17:45:58 <songole> regarding IDS use case where pkts need to be copied and sent to the port pair
17:46:00 <LouisF> pcarver: agree this can be handled by indicating that the SF is bitw and mac must not be modified
17:46:38 <songole> is there a provision in the APIs today..
17:46:53 <LouisF> vks1: i presume this applies to src mac and dest mac?
17:47:49 <vks1> LouisF, yeah SFC now rewrite mac as u mentioned but the IPS/IDS use case doesn't require modification
17:48:08 <songole> LouisF: I believe just the dest mac
17:49:30 <LouisF> there was a patch to add a sf-mode field to the port-pair parameter to handle this
17:50:05 <LouisF> i think it was abandoned, but that can be re-used
17:50:17 <vks1> LouisF, can u point me ?
17:50:27 <songole> LouisF: could you provide the link?
17:50:37 <LouisF> vks1: i will check on that
17:50:47 <vks1> LouisF, ok
17:51:04 <LouisF> i think pavel wrote the patch
17:52:18 <songole> LouisF: thanks. Any suggestions for IDS insertion?
17:52:37 <LouisF> songole: elaborate the requirement
17:53:25 <songole> ok. IDS is not an inline device, but is just an out of band inspection device
17:53:42 <songole> It doesn't forward pkts to the next hop
17:54:03 <songole> pkts need to be copied and sent to this SF
17:54:11 <pcarver> songole: that's more of a mirroring than service chaining
17:54:34 <pcarver> I don't know if we've looked at how networking-sfc interacts with networking-taas
17:54:51 <pcarver> Ideally you'd be able to use both simultaneously, but I don't know if that works
17:55:24 <songole> pcarver: ok. is networking-taas part of neutron tent just like neutron-sfc?
17:55:48 <pcarver> songole: I believe so, more or less
17:56:12 <songole> okay. We will explore it further.
17:56:18 <pcarver> I don't follow networking-taas closely and don't remember whether it passed all the requirements for stadium inclusion
17:57:04 <LouisF> songole: this can probably in handled in a similar fashion - a port-pair can be marked as "tap"
17:57:55 <pcarver> LouisF: Do we support packet copy? They need duplication of packets, not just steering
17:58:25 <LouisF> if so, its behavior it to sent packet to
17:59:06 <LouisF> SF ingress port and forward packet on to next hop in port chain
17:59:27 <pcarver> networking-taas is specifically targetted at making copies of packets for tap use, but it looks like it's not a Neutron stadium project from the perspective of policy and governance
17:59:50 <songole> pcarver: thanks for looking
18:00:09 <LouisF> pcarver: i think this can be added as new port-chain feature without much difficulty
18:00:16 <pcarver> It is an OpenStack project and specifically intended to work with Neutron, but doesn't appear to have passed the required criteria to be considered part of "Neutron Stadium"
18:00:37 <pcarver> looks like we're out of time
18:00:49 <LouisF> songole: these two freatures are independent ?
18:01:04 <songole> LouisF: thanks. We can discuss further over email.
18:01:06 <pcarver> I'm going to end meeting. Suggest that songole: create RFE bug and write up the full details of requirement
18:01:07 <vks1> LouisF, we can achieve but we need to extend apis
18:01:09 <songole> LouisF: yes
18:01:22 <LouisF> vks1: yes
18:01:28 <pcarver> #endmeeting