20:09:10 <tbachman> #startmeeting gbp_requirements
20:09:10 <odl_meetbot> Meeting started Mon Aug 25 20:09:10 2014 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:09:10 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:09:10 <odl_meetbot> The meeting name has been set to 'gbp_requirements'
20:15:22 <tbachman> #topic agenda
20:15:44 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2014-August/000441.html email describing agenda for today’s meeting
20:17:50 <tbachman> #info mickey_spiegel asks what SFC goals are in terms of GBP
20:18:09 <tbachman> #info paulq says that the intent of SFC is to provide an infrastructure to chain basic services together
20:18:26 <tbachman> #info There’s no tie-ing to a broader policy
20:18:49 <tbachman> #info It’s an exercise in plumbing and stitching together the chain
20:19:53 <tbachman> #Info mickey_spiegel says that the notion of EPGs, contracts, etc. are pure policy stuff. When that drives an action that involves a bunch of services that you want to direct traffic to, there’s a question whether the GBP group has a notion of chaining of it’s own.
20:20:17 <tbachman> #info dvorkinista says that this should be in GBP, that in turn uses the API of the service chaining to configure whatever needs to be configured
20:20:45 <tbachman> #info paulq says his assumption is that if a user/operator is using this infrastructure, that the SFC would provide an API to satisfy the intent expressed in GBP
20:22:40 <tbachman> #info paulq says it’s a question of who instantiates the classifier. THe current implementation is NSH-centric, but there could be other implementations
20:23:08 <tbachman> #info mickey_spiegel asks how we can keep an OF renderer and SFC from colliding at the flow tables
20:23:55 <tbachman> #info paulq says that the risk of conflict occurs at the classifiers. At the classifier edge, GBP should control the policy entirely
20:25:01 <tbachman> #info SFC programs rules around NSH values.
20:25:52 <tbachman> #info mickey_spiegel says that people sometimes stitch functions using VXLANs.
20:26:21 <tbachman> #info There’s a question of who allocates the VNI value
20:26:37 <tbachman> #info dvorkinista says it would be good to have a VNI authority
20:26:50 <tbachman> #info It’s either that or segment the namespace
20:28:28 <tbachman> #info paulq says the tenant namespace for topology doesn’t require non-conflict mapping
20:34:16 <tbachman> #info paulq says he’d like to see GBP reflect things to SFC
20:34:22 <tbachman> #info For example, indicate what groups are talking
20:34:29 <tbachman> #info So that this can be carried in the NSH
20:34:47 <tbachman> #info This would map to the source class and destination class
20:35:18 <tbachman> #info If you carry the tenant information in the VXLAN, how do you get this to the service?
20:35:37 <tbachman> #info This can be handled in NSH, independent of the VXLAN
20:37:05 <tbachman> #info paulq says that when you blur the forwarding and the contextual, it gets very difficult
20:37:28 <tbachman> #info you end up overloading, which leads either to incredible complexity, or loss of granularity
20:37:50 <tbachman> #info For example, when you have tenant coke with 400 service chains, you don’t want to map these to VLANs
20:38:08 <tbachman> #info paulq asks what a GBP intent request to SFC looks like
20:38:32 <tbachman> #info dvorkinista says we’d send a list (ordered collection)
20:38:52 <tbachman> #info like “we need a firewall”, with qualifiers (e.g. “big” vs. “little”)
20:39:09 <tbachman> #info in some cases, we’d need to support graphs, but in the first cut, this may not be required
20:39:24 <tbachman> #info paulq says that we can take that, then return either an error condition or return the chain
20:39:35 <tbachman> #info mickey_spiegel says there are a few things we need to tackle
20:39:40 <tbachman> #info one is graph vs. chain
20:40:04 <tbachman> #info beyond that, there’s the question of the services themselves, and the things that tie them together (e.g. “connector”)
20:40:47 <tbachman> #info dvorkinista says that the ordered list is probably sufficient
20:41:43 <tbachman> #info mickey_spiegel says services do many different things today, and not all are modeled as bumps-in-the-wire
20:42:02 <tbachman> #info There’s some indirection needed to decouple the problem, but what that is may restrict what you can do with the service chains
20:42:19 <tbachman> #info dvorkinista says that’s where NSH is really good, as it provides all the context needed
20:42:59 <tbachman> #info paulq says there are 2 ways to derive context: 1) interface, 2) Network Locator
20:43:19 <tbachman> #info where interfaces are port interfaces, VLANs, etc
20:44:50 <tbachman> #info where the mapping to interfaes occurs inside NSH
20:46:29 <tbachman> #info mickey_spiegel asks if there are proprietary ways to stitch things together, does it fit under the NSH model
20:46:55 <tbachman> #info paulq says that there only NSH and implementation version provided by Ericsson
20:47:20 <tbachman> #info if others have a mechanism they want to bear, he encourages them to join the SFC project
20:47:56 <tbachman> #info dvorkinista asks when using OF, are they doing VNID stitching?
20:48:09 <tbachman> #info (OF implementation is being done by Ericsson)
20:49:24 <tbachman> #info mickey_spiegel asks if we go in this direction, and it’s more of a chain model, how do we capture the intent and feed it to SFC, given that the existing model is a graph
20:50:02 <tbachman> #info dvorkinista says we can still think of them in GBP in terms of graphs, but provide a chain
20:50:27 <tbachman> #info paulq says that SFCs original thinking was with graphs, but the current implementation is a chain.
20:51:09 <tbachman> #info paulq asks how the intent would look different if we were doing graphs
20:52:43 <tbachman> #info sanjay says there’s a classification, a chain with a series of elements, where a chain is intent, and path is an expression of that intent
20:52:59 <tbachman> #info if a graph is bunch of chains, then there has to be classification at each service element
20:53:58 <tbachman> #info paulq says that SFC supports the concept of N classification events to support the policy
20:54:42 <tbachman> #info mickey_spiegel asks if it’s clear where those classifiers would fit
20:54:54 <tbachman> #info paulq says they’re not in the yang model now
20:55:11 <tbachman> #info conceptually it’s a logical element. In reality, it sits with a service function
20:56:08 <tbachman> #info mickey_spiegel says that if the service has multiple terminals, then the service itself drives things
20:57:10 <tbachman> #info ATM is making a comeback :)
21:02:14 <tbachman> #info sanjay asks what is a service function forwarder
21:02:30 <tbachman> #info paulq says architecturally SFC differentiates between the forwarding functionality and the service itself
21:02:34 <tbachman> #info this is a logical separation
21:02:50 <tbachman> #info this allows the concept of forwarding to not impose on the service function
21:03:15 <tbachman> #info The role is to take in an overlay packet, remove the encap, examine NHS, deliver to service function, et.
21:03:42 <tbachman> #info paulq says asking a service to do forwarding is typically a problem
21:03:51 <tbachman> #info OVS can be an SFF
21:04:13 <tbachman> #info This gives you a level of functionality that you don’t have to push to the edge.
21:04:25 <tbachman> #info mickey_spiegel asks if the service chain is just a chain of types
21:04:34 <tbachman> #info paulq says the chain is types, the path is instances
21:04:52 <tbachman> #info mickey_spiegel says that before you provision a service you have to instantiate a chain
21:05:25 <tbachman> #info when you instantiate a chain, you create a path for the chain. There’s also a concept of a service function in multiple paths
21:05:32 <tbachman> #info mickey_spiegel asks if there’s a way to achieve this today
21:06:08 <tbachman> #info paulq says they currently don’t spin up the services since they don’t have a link to the VMM
21:06:23 <tbachman> #info This has to wait until this gets hooked into the orchestration system
21:06:51 <tbachman> #info (there’s nothing to discover service functions)
21:07:51 <tbachman> #info there’s no mechanism today to know whether a network supports a DPI, FW, LB, etc.
21:08:10 <tbachman> #info currently there’s a config file that says where the services exist in the network
21:08:36 <tbachman> #info mickey_spiegel asks if you want to specify a service function, how is that done
21:08:49 <tbachman> #info paulq says that you just pick from a list
21:08:55 <tbachman> #info (as provided by the config file)
21:10:46 <tbachman> #info paulq says he’d welcome folks to look into the model and provide feedback
21:15:22 <tbachman> #info paulq says there aren’t constraints yet, but those will be added eventually
21:17:22 <tbachman> #info sanjay asks what the fail mode is
21:17:46 <tbachman> #info paulq says it’s used to indicate whether you can re-route around it or whether the chain is invalid
21:18:56 <tbachman> #info paulq says they’re adding redundant pairs as well
21:19:10 <tbachman> #info mickey_spiegel asks if redundant pairs are under a single service function
21:19:28 <tbachman> #info dvorkinista asks if this is used in an anycast way
21:19:38 <tbachman> #info paul says you can go around it or use anycast
21:22:21 <tbachman> #info paulq will check with Reinaldo Penno to see if he can join Friday’s meeting
21:22:45 <tbachman> #info paulq says he has UML figures that he can email
21:24:10 <tbachman> #endmeeting