17:00:30 <LouisF> #startmeeting service_chaining
17:00:30 <openstack> Meeting started Thu Mar 23 17:00:30 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:34 <openstack> The meeting name has been set to 'service_chaining'
17:00:38 <LouisF> hi all
17:00:48 <bcafarel> hello
17:00:54 <songole> Hi
17:00:55 <pcarver> hi
17:00:56 <LouisF> #agenda
17:01:00 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.283.2F23.2F2017.29
17:01:00 <vks1> hi all
17:01:55 <LouisF> #topic CLI
17:01:58 <LouisF> CLI in python-neutronclient https://review.openstack.org/#/c/409759/
17:02:46 <LouisF> Mohan has posted an new patch
17:03:09 <LouisF> please review
17:03:34 <LouisF> i think we are close to getting this merged
17:04:08 <LouisF> #topic API reference
17:04:11 <LouisF> API reference https://review.openstack.org/#/c/389385 https://review.openstack.org/#/c/411409/
17:04:22 <bcafarel> yes, I'll test it again too tomorrow to confirm all commands work fine (from someone else), that was requested in the review
17:04:31 <LouisF> bcafarel: thanks
17:05:02 <pcarver> I think the API reference is about done, but Armando's last comment was that he doesn't want to merge it until the API definition is done too. I think I'm getting close to having the API definition done.
17:05:15 <pcarver> Or at least a patch set that passes tox
17:05:21 <LouisF> pcarver: great, thanks
17:05:44 <pcarver> I'm leaving out the exceptions
17:05:54 <LouisF> pcarver: ok
17:06:29 <LouisF> #topic Pike work
17:06:29 * igordcard says hi
17:07:05 <LouisF> #topic SF tap
17:07:51 <LouisF> had discussion last week to use "tap-enabled" instead of "insertion-mode"
17:08:04 <vks1> LouisF: I have changed it
17:08:12 <LouisF> i will post patch to update the spec
17:08:16 <LouisF> vks1: ok
17:08:50 <vks1> LouisF: Its a pretty much WIP. I have few questions will send out an email
17:09:29 <LouisF> vks1: we can discuss now it you like
17:09:59 <vks1> LouisF: ok like I have decoupled the TAP enablement from the default mode
17:10:35 <vks1> but then I see classifier builder to be changed for TAP support
17:10:56 <vks1> as of the nature of the deployment
17:12:03 <vks1> LouisF: also I want to first enable TAP at the end of chains
17:12:09 <LouisF> vks1: are you talking about the adding "tap-enabled" to the API?
17:12:17 <vks1> that is done
17:12:40 <vks1> I have moved forward to change the ovs driver
17:12:55 <LouisF> vks1: ok
17:13:24 <vks1> and I was talking about changes I am doing in ovs driver
17:13:45 <LouisF> how are you planning to change the ovs driver to do the  tap operation?
17:14:39 <vks1> LouisF: probably I will send across the patch to get comment
17:14:57 <LouisF> vks1: ok will wait for patch
17:15:04 <vks1> that will make discussion easier
17:15:07 <vks1> yeah
17:15:46 <LouisF> can you do at leat two patches: one for api/db changes and another of ovs work
17:15:51 <LouisF> least
17:16:05 <vks1> ok will do that
17:16:48 <LouisF> vks1: thanks
17:17:12 <LouisF> vks1: you sent an email about an "active" tap - what do you mean by that?
17:18:02 <vks1> LouisF: "active" means in deployment it should be inline
17:18:21 <LouisF> vks1: explain?
17:19:58 <LouisF> you also mentioned about "other modes of deployment" - can you clarify?
17:20:31 <vks1> LouisF: yeah like "standalone atp"
17:21:02 <vks1> LouisF: few use case can be found at taas links
17:21:15 <vks1> I will reply to mail chain with the link
17:21:23 <LouisF> vks1: can you post link?
17:21:29 <vks1> yeah sure
17:21:56 <vks1> will do that, will be god for discussion
17:22:07 <igordcard> vks1: in active taps you say they forward traffic back to networking devices... does that mean traffic will get duplicated towards the end of the chain?
17:22:13 <LouisF> vks1: i want make sure that the use cases are investigated
17:22:39 <igordcard> links are welcome
17:22:56 <LouisF> duplicated traffic is a no no
17:23:13 <vks1> LouisF: yeah will only do if everyone agress on that
17:24:00 <LouisF> vks1: i am still inclear on the meaning of an "active tap"
17:24:07 <LouisF> unclear
17:24:51 <vks1> LouisF: https://www.gigamon.com/sites/default/files/resources/whitepaper/wp-understanding-network-taps-the-first-step-to-visibility-3164.pdf
17:25:13 <igordcard> vks1: thanks
17:25:17 <vks1> igordcard: :)
17:25:34 <vks1> igordcard: this will open too many use cases for us
17:25:38 <vks1> :;)
17:28:06 <LouisF> vks1: the normal behavior of a SF is to process a payload and then forward it on to the next downsteam SF towards the destination
17:28:53 <igordcard> in this regard I was also thinking about whether sfc graphs (now service graphs) could be expanded to allow mirroring branches too
17:28:56 <LouisF> vks1: and so it is essentially already performing the "active tap" behavior - right?
17:29:00 <igordcard> instead of just conditional branches
17:29:22 <igordcard> then tap would be incorporated there
17:30:16 <LouisF> igordcard: you are referring to branching which is different from the tap operation
17:30:30 <vks1> LouisF: in some sense
17:31:03 <igordcard> LouisF: non-conditional branching... so the whole branch would be your tap (if your branch had a single function, that would be your tap device)
17:31:05 <vks1> igordcard: explanation please ?
17:32:01 <igordcard> vks1: it's essentially the same but modelled differently in the API, and you could have more functions after your first tap function... if wanted
17:32:31 <LouisF> igordcard: the tap operation is simply to replicate packets and send them to a passive
17:32:58 <LouisF> SF which acts as a black hole
17:34:11 <LouisF> igordcard: branching is having the SF steer the packet flow to a sub-chain
17:34:12 <igordcard> LouisF: the black hole claim is important... whatever gets implemented should then guarantee that even if the tap function returns traffic that it is discarded by the switch
17:34:54 <LouisF> igordcard: agree any packets send from the egress port of the SF are ignored
17:35:51 <igordcard> I agree it's best to not conflate the servuce graph with the taps, at least for the time being..
17:36:04 <LouisF> having duplicate packets in the network is a recipe for disaster
17:36:12 <LouisF> igordcard: +1000
17:36:17 <igordcard> yeah
17:37:09 <LouisF> i think we should move ahead with the "passive tap" as defined in the BP and spec
17:37:36 <vks1> LouisF: I agree , I see now issues with passive only
17:37:58 <vks1> active can open lot of new issues
17:38:01 <LouisF> vks1: such as?
17:38:28 <LouisF> vks1: what issues do you have with passive tap?
17:39:01 <vks1> LouisF: that's was I was referring to earlier , TAP  becoming the special case
17:39:09 <vks1> for implementation
17:40:00 <LouisF> vks1: ok probably best to post the patch for ovs changes to do the tap
17:40:12 <LouisF> vks1: we can review and comment
17:40:13 <vks1> yeah
17:40:22 <vks1> will do that at earliest
17:40:46 <LouisF> #topic SF graph
17:41:01 <LouisF> igordcard: how is sfc graph work?
17:42:47 <igordcard> was finishing some other technical work this week and still going slow with the graph
17:42:56 <LouisF> igordcard: ok
17:43:02 <igordcard> expect new patchsets in 2 weeks or so
17:44:26 <LouisF> i want to ask you about the sharing of PPs between PP groups when using NSH encap
17:44:44 <LouisF> igordcard: ok thanks on the patch update
17:45:13 <LouisF> can you elaborate on your ideas
17:45:19 <vks1> LouisF: why the restriction ?
17:46:32 <LouisF> vks1: the PP group defines how the load balancing is done to the PP in the group
17:46:39 <igordcard> vks1: matching on the flow classifier unambiguously
17:46:42 <igordcard> too
17:46:59 <igordcard> LouisF: so if packets are encapd in nsh
17:47:32 <igordcard> you don't have to look at the classification to decide what the next group is
17:47:46 <igordcard> you just look at nsp/nsi (spi/si)
17:47:54 <LouisF> the LB for a PP group knows which SF have been allocated traffic
17:48:33 <igordcard> so the action of load balacing across pps of a ppg will still exist and work just fine
17:49:00 <igordcard> it's just that a particular PP may now be the object of load balacing in another group too
17:49:04 <LouisF> so the LB for the group has to have exclusive ownership of the SFs in the group to do the LB operation properly
17:50:05 <igordcard> today without pp correlation there is a tight coupling between the result of load balacing and the mac address of the selected ingress port of the port pair
17:50:06 <LouisF> igordcard: it is not related to selecting the next hop
17:50:56 <igordcard> ut when you have nsh you don't have to wait to know which was the selected PP
17:51:15 <igordcard> s/ut/but
17:53:11 <LouisF> igordcard: with nsh there may be several SFs in a group that all receive the packets with same nsp value
17:53:12 <igordcard> #link https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L408
17:54:22 <LouisF> igordcard: agree the dest mac is used to steer the packets to the correct next hop SF
17:54:42 <LouisF> in the current implementation
17:55:38 <igordcard> it's just that it doesn't matter how many ppgs is a pp member of, when you're only looking at the nsh header for matching next hops
17:56:30 <LouisF> but with NSH, the LB can add a metadata tag to steer the packet to one of the downstream SFs in the PPG
17:57:18 <igordcard> how would the tag look like?
17:57:41 <igordcard> is it needed when there is nsp+nsi already in the packet?
17:58:37 <igordcard> I'll send a new email, about this subject, it's easier to do it in multi-line
17:59:00 <igordcard> and I have a quick question, is the team expecting to go to boston?
17:59:10 <LouisF> nsp+nsi does not allow selection of one of several downstream SF at a specific hop (nsi) in a specific chain (nsp)
17:59:22 <igordcard> we could some brainstorming there on future work
17:59:36 <LouisF> igordcard: yes
17:59:55 <igordcard> nsp+nsi influences the selection that is executed by the sff (ovs basically) given what it knows about the infrastructure
18:00:06 <LouisF> its a wrap bye  all
18:00:06 <igordcard> and deployed sfcs
18:00:30 <LouisF> igordcard: email me
18:00:38 <igordcard> LouisF: already
18:00:41 <igordcard> alright*
18:00:43 <LouisF> #endmeeting