17:07:27 #startmeeting gbp_arch 17:07:27 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:07:27 The meeting name has been set to 'gbp_arch' 17:08:58 #topic agenda 17:09:46 #info https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=model/src/main/yang;h=abe368fdf09fc912b00625a76bddba9a03229f62;hb=218ea63128db2a9d2d1d8e10693a0ebcbe090860 17:10:24 I think there was a updated one that Paul sent 17:11:07 #undo 17:11:07 Removing item from minutes: 17:11:23 #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 #info agenda item: SFC Discussion 17:12:21 #topic SFC Discussion 17:12:33 tbachman: thanks 17:12:36 :) 17:13:08 #info mickey_spiegel says that the chain is a list of types, rather than a service function 17:13:26 #info sanjay says that a service node may have multiple service functions 17:16:24 #info mickey_spiegel asks if service function chain is a list of service functions or service function types 17:16:58 #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 #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 #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 Youcef: thanks for helping here :) 17:23:47 #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 happy to tbachman :) 17:24:50 #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 #info mickey_spiegel says we probably need to talk w/Paul Quinn some more about this 17:25:48 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 #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 #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 #info mickey_spiegel says the big issue is getting in and out of the chain 17:27:49 #info readams says if the SFC project is trying to program OF rules outside of GBP then this won’t work 17:28:23 #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 #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 #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 #info readams notes that you can go in and manually configure the devices, but that doesn’t solve the problem. 17:31:47 #info mickey_spiegel says that the header has everything that’s needed to forward it 17:32:19 #info sanjay says that the header provides a service path id (context) and tells you where you are in the chain 17:32:42 #info SFC is not tied to NSH headers. It also supports LISP and is open to other mechanisms 17:32:55 #info readams asks if a geneve tunnel could be used 17:34:31 #info mickey_spiegel says we need to be more generic than this 17:36:38 #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 #SanjayK says a service path is an instance of the intent 17:37:20 #info sanjay says that a path to him is an instance of intent, regardless of how they’re organized. 17:38:20 #info mickey_spiegel says that the "service graph" model of GBP is different from the path model in SFC. 17:39:35 #info readams a path is a graph, but a graph may not necesarrily be a path 17:39:43 #info and therefore the graph is more flexible 17:39:55 #info mickey_spiegel says it’s worth asking if we need that flexibility 17:41:13 #info readams asks what the SFC group is trying to do with their project in ODL (prototype)? 17:41:34 #info Youcef says they are building a prototype using a vSwitch with NSH and OpenFlow rules to create the service chain 17:41:46 #info they are using OVSDB for managing the vSwitch 17:41:57 #info Youcef says there are extensions in Open vSwitch to support NSH 17:44:29 #info readams says that the yang model seems specific to NSH 17:44:40 #info mickey_spiegel says that’s something we should bring up with paul 17:44:48 #info readams says this isn’t some sort of intent model 17:45:03 #info mickey_spiegel says he’s not sure about that — that may be what paul was thinking 17:45:30 #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 #info mickey_spiegel says that they need to do another model than just NSH to prove that this is actually intent 17:48:07 #topic Flow Use Case 17:48:41 #info We were looking into introducing a concept of session to the model for the UC use case 17:52:02 #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 #info sanjay says what about a non-open-source implementation 17:53:06 #info readams agrees that’s a valid trigger for evolving the model 17:55:23 #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 #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 #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 #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 #info you wouldn’t be creating dynamic subjects or clauses 17:57:43 #info sanjay says it’s not clear how you would handle the dynamic flows 17:58:00 #info readams says that the simplest case, you have a classifier that says reference the following set of sessions 17:58:18 #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 #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 #info readams says that they’re not 17:59:45 #info readams says that the membership of EPs in the EPGs is very dynamic 18:00:05 #info This same concept can be extended to classifiers 18:00:10 #info sanjay asks where this is residing 18:00:29 #info readams says there could be a separate session registry, or the EP registry could be extended to support this 18:00:58 #info sanjay says that actions may need dynamic programming 18:01:10 #info readams why you would need dynamic programming 18:01:24 #info sanjay says an example is a redirect action, a counting action…. 18:01:35 #info mickey_spiegel asks if the intent is specific to a single session? 18:03:39 #info readams says that some of this can be done with conditions 18:11:43 #info readams says the rule would be something like sesson group UCS, and the action would be allow 18:12:22 #info The subject has the rule in it, 18:12:28 #info the classifier is session group UCS 18:13:18 #info The clause pulls in a subject, and a subject has a list of rules in it. 18:13:47 #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 #info readams says the action could also be as simple as “allow" 18:14:28 #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 #info mickey_spiegel says that if you’re only going navigate your clauses one way, you only need one subject 18:19:00 #info a session group could be created, which is analagous to an endpoint group 18:19:22 #info the session group would be two endpoints that are referenced by their EP identifiers, with additinoal classifiers 18:19:33 #info (e.g. like a service classifier) 18:21:00 #info sanjay asks whether there is one session group or multiple? 18:21:14 #info readams says session groups can be named (Session group “X”) 18:22:25 #info readams says that the user would set up all the rules in advance 18:22:34 #info and the set of session groups that exist 18:22:46 #info the application would be configured to dynaically put sessions into session groups 18:23:26 #info sanjay asks if there is a concept of "action group" similar to session groups 18:23:57 #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 mickey_spiegel says let's try not to solve the issue of grouping actions until we have some use cases 18:24:26 #info : mickey_spiegel says let's try not to solve the issue of grouping actions until we have some use cases\ 18:25:31 #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 #info readams says that session groups should be developed independent of specific endpoints 18:29:10 #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 Youcef: thanks again for your help! :)_ 18:30:59 glad to. Still trying not to make too many mistakes ;) 18:31:17 doing great! 18:34:26 #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 #endmeeting