20:02:46 <alagalah> #startmeeting  Usecase discussion
20:02:46 <odl_meetbot> Meeting started Mon Jul 21 20:02:46 2014 UTC.  The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:02:46 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:46 <odl_meetbot> The meeting name has been set to 'usecase_discussion'
20:02:53 <alagalah> #chair dconde
20:02:53 <odl_meetbot> Current chairs: alagalah dconde
20:03:05 <alagalah> #chair dlenrow
20:03:05 <odl_meetbot> Current chairs: alagalah dconde dlenrow
20:03:45 <alagalah> #topic Traffic steering use cases
20:08:27 <alagalah> #info dvorkin shares code showing the service chain of consumer and provider
20:08:42 <tbachman> alagalah: can you chair me?
20:08:59 <alagalah> #chair tbachman
20:08:59 <odl_meetbot> Current chairs: alagalah dconde dlenrow tbachman
20:09:10 <alagalah> tbachman: you taking over minutes?
20:09:14 <tbachman> ack
20:09:52 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2014-July/000367.html example of sketch of service chaining
20:10:06 <tbachman> #info mickey_spiegel asks why we need to distinguish between provider connection and service connection
20:10:21 <tbachman> #info dvorkinista says that there are some cases where there are more than a single input
20:10:28 <tbachman> #info mickey_spiegel asks for an example of input
20:10:36 <tbachman> #info dvorkinista says input is a consumer and output is a provider
20:10:55 <tbachman> #info depending on the differen consumer, they can be processed differently
20:11:04 <tbachman> #info consumer is the beginniing of the chain
20:11:56 <tbachman> #info sanjay asks to see an example
20:12:06 <tbachman> #info dvorkinista goes over example provided in the email
20:12:36 <tbachman> #info the consumer-connector is basically a terminator
20:13:17 <tbachman> #info the chain is expressed in terms of coming towards the provider
20:13:27 <tbachman> all our policies are expressed from the provider’s perspective
20:14:06 <tbachman> #info mickey_spiegel asks if it’s bi-directional, why do you need a provider-connector?
20:14:47 <tbachman> #info dvorkinista says the last stage of the chain is the one that’s facing the provider.
20:16:25 <tbachman> #info the first stage of the chain faces the consumer and the last stage of the chain is the one facing the provider
20:16:38 <tbachman> #info mickey_spiegel asks why we need two in statements at each hop to support this
20:16:46 <tbachman> #info dvorkinista says these are needed for direct return
20:19:27 <tbachman> #info mickey_spiegel asks how you can figure out direction
20:19:57 <tbachman> #info dvorkinista says the only way you can figure out direction is through configuration of a logical function, which currently isn’t being done
20:21:24 <tbachman> #info the chain itself as a function is bi-directional
20:21:32 <tbachman> #info but within the chain, there is flexibility
20:21:46 <tbachman> #info mickey_spiegel asks if we want to do more than forward and backward
20:21:55 <tbachman> #info dvorkinista says you can have more if you want
20:23:16 <tbachman> #info mickey_spiegel says that the way the direction works right now, it’s kind of confusing
20:23:38 <tbachman> #info dvorkinista says that for this time around, we’re not talking about configuration
20:24:26 <tbachman> #info mickey_spiegel  asks what “in prov-side” means
20:24:46 <tbachman> #info dvorkinista says he’s trying to keep it at a logical level. Think of it as a logical uni-directional construct
20:25:24 <tbachman> #info clarification requested on line 71 (next cons-conn cons)
20:25:40 <tbachman> #info dvorkinista says it can talk to the load balancer or talk to the consumer connector
20:25:59 <tbachman> #info where the “cons” is just a name
20:26:50 <tbachman> #info says that this is not configuring the firewall, but configuring the direction within the network
20:27:00 <tbachman> #info it just says “go back to the consumer"
20:28:00 <tbachman> #info dvorkinista re-emphasizes this is not configuration, but just plumbing
20:28:53 <hemanthravi> can the in and next lines be specified as a pair?
20:30:17 <hemanthravi> audio is intermittent
20:30:44 <alagalah> hemanthravi: apologies
20:30:45 <tbachman> #info mickey_spiegel says right now there are two next statements. How do we know which one to use
20:31:04 <tbachman> #info dvorkinista says that’s just configuration of the function
20:31:58 <tbachman> #info hemanth, sanjay, and mickey_spiegel all prefer “back” to use of next
20:32:22 <tbachman> #info dvorkinista says you can use that if you prefer, as it  makes no difference to the renderer
20:33:33 <tbachman> #info mickey_spiegel asks if coupling of in and next the way to answer the question of which one to use?
20:34:33 <tbachman> #info dvorkinista  modifies to have two seperate cases, scoped by the side it came in on
20:34:47 <tbachman> #info “in consumer-side => next cool-slb/cons-side"
20:34:59 <tbachman> #info “in prov-side => next cons-conn cons"
20:35:44 <tbachman> #info sanjay says that cases where there are multiple interfaces that it can go out on, you can have multiple next statements
20:36:05 <hemanthravi> is multiple next required for a graph fw -> ids and fw -> slb too?
20:36:31 <hemanthravi> graph instead of a linear chain
20:38:02 <tbachman> #info dvorkinista provides an l3 example
20:41:03 <tbachman> #info mickey_spiegel asks how you can have multiple nexts on one interface
20:41:13 <tbachman> #info dvorkinista says that each next is an interface
20:46:17 <tbachman> #info mickey_spiegel says we need something as a handle — sometimes its interface, sometimes its next
20:46:31 <tbachman> #info dvorkinista says he’s already identified two types of interfaces — input and output
20:47:02 <tbachman> #info sanjay asks whether the next selection should be part of the intent
20:47:50 <tbachman> #info dvorkinista says there is no way to express this here, b/c we’re not configuring the firewall itself.
20:48:20 <tbachman> #info This language is just for specifying the plumbing
20:48:50 <tbachman> #info mickey_spiegel says that when a packet comes out from the service, we need to express the next thing/function to use
20:49:00 <tbachman> #info and that something has to come from the packet
20:49:08 <dlenrow> #info We're kind of trapped in details. What I get so far is the proposal is that the entire service chain be built so that it can be inserted betweeen EPGs like other contracts. We are arguing about how to build the service chain data  structures, but should maybe first ask if this does a good job of solving the problem, as opposed to e.g. make the virtual
20:49:08 <dlenrow> functions EPGs and create a (possibly not produce/consumer) new concept to enable steering packets to members of these EPGs
20:49:10 <tbachman> #info mickey_spiegel asks if we can use one abstraction for that.
20:49:52 <alagalah> dlenrow: I take your point
20:50:40 <tbachman> #info dvorkinista emphasizes we’re talking about the plumbing aspects of the service chain
20:50:47 <tbachman> #info and next we’d talk about the configuration
20:50:55 <tbachman> #info this discussion is focused on just the plumbing
20:52:35 <dlenrow> #info seems like this is not abstract enough. Surely theres a high level concept of a chain that can allow us to build them declaratively without such a complex, redundant description of how each VF ties bidirectionally to the others. If we model these as Endpoints (things that can be reached over the network) building chain gets really simple
20:53:59 <tbachman> #info dvorkinsta says that there are two use cases here
20:54:10 <tbachman> #info one is where there is an explicitly desired SFC
20:54:19 <tbachman> #info the second is the provider SFC that’s inserted transparently
20:54:32 <tbachman> #info dvorkinista says lets first discuss the former use case
20:56:02 <tbachman> #info tbachman notes that dvorkinista is pretty good at ASCII art ;)
21:01:47 <tbachman> #info mickey_spiegel asks if there’s a difference between a function connector and logical interface
21:02:04 <tbachman> #info dvorkinista says that interfaces are symantically overloaded and mean something
21:02:42 <tbachman> #info The connector here identifies the input into a function
21:02:54 <tbachman> #info That’s how you get in to the function, and therefore the chain
21:04:07 <tbachman> #info mickey_spiegel asks if line inputs and connectors are 1-to-1
21:04:21 <tbachman> #info dvorkinista says no — you can have others
21:04:40 <tbachman> #info dvorkinista draws an example of multiple lines to a single connector
21:07:06 <tbachman> #info dlenrow asks if a load balancer is different enough worth treating differently
21:08:27 <tbachman> #info dvorkinista notes that lines come out of the function, not the connectors
21:08:33 <tbachman> #info the lines go in to a connector
21:08:49 <tbachman> #info mickey_spiegel says that connector is just an abstraction and giving a name to it.
21:13:16 <tbachman> #info sanjay asks if we can have input and output connectors, each having an input, an output, or bi-dir
21:13:36 <tbachman> #info dvorkinista asks what happens when you try to specify next
21:14:52 <tbachman> #info mickey_spiegel says it comes down to “what is a connector"
21:15:43 <tbachman> #info dvorkinista then draws up a model with a single connector, with multiple next statements underneath it
21:16:09 <tbachman> #info mickey_spiegel says he wants connectors with next’s that specify what they connect to
21:16:49 <tbachman> #info mickey_spiegel says this way is an abstraction around x
21:16:58 <tbachman> #info dvorkinista says in this case, connector doesn’t do anything
21:17:18 <tbachman> #info mickey_spiegel says it gives you a point where you can do something once you get to the discussion on configuration
21:17:40 <tbachman> #info sanjay says that connectors are vertices and nexts are links
21:20:42 <tbachman> #info mickey_spiegel asks if there is some operational model that maps connectors to somting
21:23:48 <dlenrow> #info How do we use this.  Assume there is a good way to describe the service chain. (suspend syntax argument for now). What does it look like to add SC1 between Sales EPG  and the Internet EPG and add SC2 between finance EPG and special server EPG?
21:24:23 <tbachman> #info mickey_spiegel says if you look at the openstack model, there’s the same question of the port
21:24:44 <tbachman> #info sanjay says that it’s about context — each connector provides a context
21:25:21 <alagalah> tbachman: I have an IT/WPR call in a few minutes
21:25:28 <tbachman> alagalah: ack
21:26:10 <tbachman> #info dlenrow says that it’s worth taking a step back at this point
21:26:50 <tbachman> #info dvorkinista says there’s a fundamental question of do we want an interface ,and what we want to call it.
21:27:19 <tbachman> #info dlenrow says independent of that, ther’es the question of what it looks like when you bring in EPGs and specific instances of virtual functions into the picture
21:27:52 <tbachman> #info mickey_spiegel says that this is  a good point, b/c you get into this by associating to groups
21:28:24 <tbachman> #info dvorkinista says we shouldn’t confuse how things behave on the wire vs. what the traffic is subjected to
21:28:54 <tbachman> #info (i.e. what kinds of things can communicate and how they communicate vs. what operations are perfomed on the traffic)
21:30:52 <tbachman> #info dvorkinista says that the next/prev provides a context, and the rest of it is the configuration of the appliance
21:39:53 <tbachman> #info dvorkinista says you can treat an SLB as something that has its own contract, but its implicit
21:41:36 <tbachman> #info mickey_spiegel says this kind of seems like you’re hopping contracts
21:41:42 <tbachman> #info dvorkinista says that this is correct
21:44:33 <tbachman> #action dvorkinista will look into providing the slides
21:45:01 <tbachman> #info we’ll think about the connector description and how that’s used
21:45:37 <tbachman> #action dvorkinista wil send the slides to sanjay, who will upload them to the wiki
21:46:10 <tbachman> #action mickey_spiegel will put syntax of the  SFC with the connector definition and the behavior of a LB with VIPs and contracts applied onto Friday’s agenda
21:46:54 <tbachman> #endmeeting