17:07:27 <tbachman> #startmeeting gbp_arch
17:07:27 <odl_meetbot> Meeting started Fri Aug 15 17:07:27 2014 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:07:27 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:07:27 <odl_meetbot> The meeting name has been set to 'gbp_arch'
17:08:58 <tbachman> #topic agenda
17:09:46 <Youcef> #info https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=model/src/main/yang;h=abe368fdf09fc912b00625a76bddba9a03229f62;hb=218ea63128db2a9d2d1d8e10693a0ebcbe090860
17:10:24 <tbachman> I think there was a updated one that Paul sent
17:11:07 <tbachman> #undo
17:11:07 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x24a3410>
17:11:23 <tbachman> #link https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=sfc-model/src/main/yang;h=ad40d0c9861ddb7ce058c0a2379204c7f3293881;hb=218ea63128db2a9d2d1d8e10693a0ebcbe090860 <= link to SFC yang models
17:12:10 <tbachman> #info agenda item: SFC Discussion
17:12:21 <tbachman> #topic SFC Discussion
17:12:33 <Youcef> tbachman: thanks
17:12:36 <tbachman> :)
17:13:08 <tbachman> #info mickey_spiegel says that the chain is a list of types, rather than a service function
17:13:26 <tbachman> #info sanjay says that a service node may have multiple service functions
17:16:24 <Youcef> #info mickey_spiegel asks if service function chain is a list of service functions or service function types
17:16:58 <tbachman> #info sanjay says from the intent point of view he thinks its complete, but for the rendering point of view, it is not
17:19:54 <tbachman> #info mickey_spiegel sees Paul Quinn’s work is an another alternative within ODL to service chaining (i.e. alternative to what dvorkinista created in previous meetings)
17:22:18 <Youcef> #info mickey_spiegel asks why is a service function path not referring to the service function chain from which it was constructed.
17:23:29 <tbachman> Youcef: thanks for helping here :)
17:23:47 <Youcef> #info SanjayK says that the renderer takes a chain and builds a path from the available instances for each service function type.
17:23:59 <Youcef> happy to tbachman :)
17:24:50 <tbachman> #info tbachman notes that the model that sanjay and mickey_spiegel were looking at is an older one (see newer one in meeting minutes above)
17:25:03 <tbachman> #info mickey_spiegel says we probably need to talk w/Paul Quinn some more about this
17:25:48 <Youcef> mickey_spiegel asks whether for group-policy service chain intent, we should go with the model that Mike Dvorkin outlined before or follow the model that the SFC project is building
17:26:01 <tbachman> #info mickey_spiegel asks whether for group-policy service chain intent, we should go with the model that Mike Dvorkin outlined before or follow the model that the SFC project is building
17:27:06 <tbachman> #info readams says that GBP has to do all the connectivity for the elements of the chain. The SFC project can tell us about pieces of the chain
17:27:24 <tbachman> #info mickey_spiegel says the big issue is getting in and out of the chain
17:27:49 <tbachman> #info readams says if the SFC project is trying to program OF rules outside of GBP then this won’t work
17:28:23 <tbachman> #info sanjay says that the SFC and GBP can agree on intent, but how to render it into NSH chaining or OpenFlow
17:28:44 <Youcef> #info Rob Adams says that for example, GBP is injecting rules into a switch and SFC is also injecting rules in the same switch, and they may be conflicting and creates problems
17:29:01 <tbachman> #info readams says that there’s a lot of work related to orchestration and confiuration of the services themselves, and how you configure a generic firewall, etc. But the SFC crew isn’t working on this
17:29:40 <tbachman> #info readams notes that you can go in and manually configure the devices, but that doesn’t solve the problem.
17:31:47 <tbachman> #info mickey_spiegel says that the header has everything that’s needed to forward it
17:32:19 <tbachman> #info sanjay says that the header provides a service path id (context) and tells you where you are in the chain
17:32:42 <Youcef> #info SFC is not tied to NSH headers. It also supports LISP and is open to other mechanisms
17:32:55 <tbachman> #info readams asks if a geneve tunnel could be used
17:34:31 <tbachman> #info mickey_spiegel says we need to be more generic than this
17:36:38 <tbachman> #info mickey_spiegel says that this model is much more of a chain and path model, and that dvorkinista’s model is more of a graph model
17:37:12 <Youcef> #SanjayK says a service path is an instance of the intent
17:37:20 <tbachman> #info sanjay says that a path to him is an instance of intent, regardless of how they’re organized.
17:38:20 <Youcef> #info mickey_spiegel says that the "service graph" model of GBP is different from the path model in SFC.
17:39:35 <tbachman> #info readams a path is a graph, but a graph may not necesarrily be a path
17:39:43 <tbachman> #info and therefore the graph is more flexible
17:39:55 <tbachman> #info mickey_spiegel says it’s worth asking if we need that flexibility
17:41:13 <tbachman> #info readams asks what the SFC group is trying to do with their project in ODL (prototype)?
17:41:34 <tbachman> #info Youcef says they are building a prototype using a vSwitch with NSH and OpenFlow rules to create the service chain
17:41:46 <tbachman> #info they are using OVSDB for managing the vSwitch
17:41:57 <tbachman> #info Youcef says there are extensions in Open vSwitch to support NSH
17:44:29 <tbachman> #info readams says that the yang model seems specific to NSH
17:44:40 <tbachman> #info mickey_spiegel says that’s something we should bring up with paul
17:44:48 <tbachman> #info readams says this isn’t some sort of intent model
17:45:03 <tbachman> #info mickey_spiegel says he’s not sure about that — that may be what paul was thinking
17:45:30 <tbachman> #info Youcef  says this is also a mechanism for supporting metadata and service chaining — this isn’t the only model, but they’re open to other things
17:45:47 <tbachman> #info mickey_spiegel says that they need to do another model than just NSH to prove that this is actually intent
17:48:07 <tbachman> #topic Flow Use Case
17:48:41 <tbachman> #info We were looking into introducing a concept of session to the model for the UC use case
17:52:02 <tbachman> #info readams says he’d prefer holding off working on the model until someone comes to GBP ready to do an implementation for their use case
17:52:48 <tbachman> #info sanjay says what about a non-open-source implementation
17:53:06 <tbachman> #info readams agrees that’s a valid trigger for evolving the model
17:55:23 <tbachman> #info sanjay asks if the application needs to understand the policy model, or will there be a front-end that would provide an API for applications
17:55:55 <tbachman> #info readams says you wouldn’t be modifying contracts dynamically for that. You’d create a concept outside of that in an operational store
17:56:49 <tbachman> #info sanjay says that in the operational store, you’ll still need to create things like flows, filters for the flows, action for the flows, etc.
17:57:13 <tbachman> #info readams says it’s more like you’ll have all the actions and things defined in the contract, and you’re just instantiating that particular subject with respect to specific sessions
17:57:31 <tbachman> #info you wouldn’t be creating dynamic subjects or clauses
17:57:43 <tbachman> #info sanjay says it’s not clear how you would handle the dynamic flows
17:58:00 <tbachman> #info readams says that the simplest case, you have a classifier that says reference the following set of sessions
17:58:18 <tbachman> #info that normally wouldn’t do anything, but once one of those sessions is created, that classifier would now match against it
17:58:51 <tbachman> #info mickey_spiegel says that we have all these labels — there’s a question whether those as they exist are enough to get a sesion through the clauses to get a subject or whether we need something in addition
17:58:55 <tbachman> #info readams says that they’re not
17:59:45 <tbachman> #info readams says that the membership of EPs in the EPGs is very dynamic
18:00:05 <tbachman> #info This same concept can be extended to classifiers
18:00:10 <tbachman> #info sanjay asks where this is residing
18:00:29 <tbachman> #info readams says there could be a separate session registry, or the EP registry could be extended to support this
18:00:58 <tbachman> #info sanjay says that actions may need dynamic programming
18:01:10 <tbachman> #info readams why you would need dynamic programming
18:01:24 <tbachman> #info sanjay says an example is a redirect action, a counting action….
18:01:35 <tbachman> #info mickey_spiegel asks if the intent is specific to a single session?
18:03:39 <tbachman> #info readams says that some of this can be done with conditions
18:11:43 <tbachman> #info readams says the rule would be something like sesson group UCS, and the action would be allow
18:12:22 <tbachman> #info The subject has the rule in it,
18:12:28 <tbachman> #info the classifier is session group UCS
18:13:18 <tbachman> #info The clause pulls in a subject, and a subject has a list of rules in it.
18:13:47 <tbachman> #info uchau says that one way we could apply this is to set it up so that they’re types assigned, like all VOIP sessions, and the action is voice QoS
18:13:58 <tbachman> #info readams says the action could also be as simple as “allow"
18:14:28 <tbachman> #info mickey_spiegel says that navigating a clause and getting to particular subject is a function of EPG membership, requirements, capabilities, etc.
18:16:39 <tbachman> #info mickey_spiegel says that if you’re only going navigate your clauses one way, you only need one subject
18:19:00 <tbachman> #info a session group could be created, which is analagous to an endpoint group
18:19:22 <tbachman> #info the session group would be two endpoints that are referenced by their EP identifiers, with additinoal classifiers
18:19:33 <tbachman> #info (e.g. like a service classifier)
18:21:00 <tbachman> #info sanjay asks whether there is one session group or multiple?
18:21:14 <tbachman> #info readams says session groups can be named (Session group “X”)
18:22:25 <tbachman> #info readams says that the user would set up all the rules in advance
18:22:34 <tbachman> #info and the set of session groups that exist
18:22:46 <tbachman> #info the application would be configured to dynaically put sessions into session groups
18:23:26 <Youcef> #info sanjay asks if there is a concept of "action group" similar to session groups
18:23:57 <tbachman> #info readams says that it starts making things look like huge ACL lists, which is getting away from the goals of GBP
18:24:16 <Youcef> mickey_spiegel says let's try not to solve the issue of grouping actions until we have some use cases
18:24:26 <tbachman> #info : mickey_spiegel says let's try not to solve the issue of grouping actions until we have some use cases\
18:25:31 <Youcef> #info sanjay asks if I need to know if the EPGs that the endpoints belong to, when I'm programming session groups
18:26:00 <Youcef> #info readams says that session groups should be developed independent of specific endpoints
18:29:10 <Youcef> #info readams says that session groups could be stored in the Endpoint Registry (EPR) or we could have a separate session registry.
18:30:12 <tbachman> Youcef: thanks again for your help! :)_
18:30:59 <Youcef> glad to. Still trying not to make too many mistakes ;)
18:31:17 <tbachman> doing great!
18:34:26 <Youcef> #info readams says that realizing contracts for communication within an EPG are spotty in GBP, but there is an option to allow communication between endpoints within the same EPG.
18:38:50 <tbachman> #endmeeting