19:59:20 <alagalah> #startmeeting Requirements and Arch carry over 19:59:20 <odl_meetbot> Meeting started Mon Jul 28 19:59:20 2014 UTC. The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html. 19:59:20 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:59:20 <odl_meetbot> The meeting name has been set to 'requirements_and_arch_carry_over' 19:59:28 <alagalah> #chair tbachman dconde 19:59:28 <odl_meetbot> Current chairs: alagalah dconde tbachman 20:00:24 <alagalah> #topic dvorkin to present SFC model 20:01:09 <dconde> The WebEx link is https://cisco.webex.com/ciscosales/j.php?MTID=m98f331fdbf75117ff8046a55ed272913 20:02:49 <alagalah> #topic Discuss proposed model for SFC and traffic steering intent: detailed syntax and semantics including "connector" or "interface" definition 20:06:33 <alagalah> dlenrow: Can you join ?" 20:06:46 <alagalah> mickey_spiegel: Can you? 20:06:53 <mickey_spiegel> WebEx link? 20:06:57 <alagalah> hold 1 20:07:19 <alagalah> https://cisco.webex.com/ciscosales/j.php?MTID=m98f331fdbf75117ff8046a55ed272913 20:07:31 <alagalah> #info https://cisco.webex.com/ciscosales/j.php?MTID=m98f331fdbf75117ff8046a55ed272913 20:07:58 <tbachman> #link https://cisco.webex.com/ciscosales/j.php?MTID=m98f331fdbf75117ff8046a55ed272913 20:08:05 <alagalah> tbachman: better :) 20:08:09 <tbachman> :) 20:08:14 <tbachman> (tho i didn’t provide a context) 20:09:19 <alagalah> #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:REQUIREMENTS 20:09:44 <alagalah> #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:REQUIREMENTS#Agenda 20:11:35 <tbachman> #info mickey_spiegel asks if we change address (e.g. destination address changes from VIP to different server), is this supported? 20:12:22 <tbachman> #info dvorkinista says under the hood, it will look like a change of contract, but the goal should be to keep the original contract 20:12:43 <tbachman> #info mickey_spiegel says from an enforcement point of view, address is all we have to on 20:13:00 <tbachman> #info dvorkinista says that certain things can be done in an implicit fashion 20:13:22 <tbachman> #info the external interfaces that deal with these things should be self-consistent with the model that’s been defined, rather than the model that’s implicit 20:14:20 <tbachman> #info mickey_spiegel is concerned about restrictions from a user’s perspective when provisioning 20:14:36 <tbachman> #info mickey_spiegel says that 2 groups of servers behind the same VIP, do that have to be in the same EPG? 20:15:10 <tbachman> #info dvorkinista says they can be in different ones 20:15:25 <tbachman> #info dvorkinista says there are two ways to do this 20:15:42 <tbachman> #info do we want to treat things that involve address transformation as an EPG? 20:15:59 <tbachman> #info if we do this, then we’re saying that this behavior is not simulatable within the hypervisor 20:16:15 <tbachman> #info We end up making things more concrete than they have to be 20:16:38 <tbachman> #info mickey_spiegel says that the LB in the hypervisor is for East-West, with distributed implementation of the LB 20:17:23 <tbachman> #info says the problem in hiding some of this, if there’s anything before the LB, you only have the VIP to go on 20:17:47 <tbachman> #info dvorkinista says we can entertain a notion of a concept as treating a LB as it’s own EPG with a specific contract 20:18:26 <tbachman> #info once you start doing direct server return, you start violating the intent of the EPG 20:19:09 <tbachman> #info mickey_spiegel is concerned that there are certain configurations that are unachievable 20:19:31 <tbachman> #info 2 groups of servers, A and B, and they’re behind the same VIP, and have from the outside-in one or more services before the LB 20:22:11 <tbachman> #info dvorkinista invents the twinky service 20:23:18 <tbachman> #info dvorkinista says you can use two different chains that get realized on the same set of devices 20:23:22 <tbachman> #info or you can rely on labels 20:23:39 <tbachman> #info depending on what roles are used (consumer or provider) 20:23:51 <tbachman> #info mickey_spiegel says that with 2 different VIPs, you can easily distinguish this 20:24:04 <tbachman> #info mickey_spiegel maintains that this still is a problem with a single VIP 20:24:49 <tbachman> #info dvorkinista says that with a single VIP, we can’t do this w/o knowledge of the LB 20:25:02 <tbachman> #info mickey_spiegel says he’s just trying to say that this configuration shouldn’t be allowed 20:25:17 <tbachman> #info mickey_spiegel asks if the user has input on what the VIP is? 20:25:34 <tbachman> #info dvorkinista says the user has the ability to provide this input 20:26:24 <tbachman> #info mickey_spiegel says if the customer’s directly saying what the VIP is, then we get into trouble 20:26:34 <tbachman> #info but if they provide a pool of VIPs, it’s not a problem 20:26:44 <tbachman> #info dvorkinista agrees this should not be hard-coded into the intent 20:26:48 <tbachman> #info but it has to come from somewhere 20:27:01 <tbachman> #info it can be added into some EPR field 20:27:16 <tbachman> #info there can be multiple ways 20:27:27 <tbachman> #info mickey_spiegel says whether it’s one-to-one vs. many-to-one is the real issue 20:27:50 <tbachman> #info dvorkinista says that there is another orchestration system that configured the guts of the LB 20:29:02 <tbachman> #info dvorkinista says we can say a VIP is popualated in an EPR by an act of magic 20:29:21 <tbachman> #info mickey_spiegel asks what makes the association of the VIP and the chain? 20:29:33 <tbachman> #info dvorkinista says that it’s only in the rendering time when those things come into scope 20:29:46 <tbachman> #info when the chain gets rendered, this information becomes available 20:29:57 <tbachman> #info using continuous evaluation 20:30:15 <tbachman> #info mickey_spiegel says we have to know whether these two chains are using the same chain or not so we can add restrictions to their content 20:31:29 <tbachman> #info dvorkinista says we can have something in the LB like “VIP desire” 20:31:42 <tbachman> #info mickey_spiegel asks if this is related to the connector concept 20:31:53 <tbachman> #info dvorkinista says that it’s like a special kind of connector 20:32:47 <tbachman> #info mickey_spiegel says that anything that has any form of NAT is a problem scenario 20:33:38 <tbachman> #info dvorkinista says this is represented in the IP desire 20:33:48 <tbachman> #info Sanjay asks if this is working in both directions 20:33:53 <tbachman> #info dvorkinista says he doesn’t know yet 20:34:17 <tbachman> #info mickey_spiegel says that in the middle of a chain, it’s not an issue. 20:35:59 <tbachman> #info There is a question of the return from the LB 20:36:09 <tbachman> #info is there a separate sub-connector for the VIP Desire 20:36:13 <tbachman> #info or a separate connector 20:37:16 <tbachman> #info dvorkinista draws a diagram with the in/out connectors as sub-elements of VIP Desire 20:37:54 <tbachman> #info mickey_spiegel says that in our previous discussions, we wanted to allow many-to-one, but there are some special cases 20:41:43 <tbachman> #info mickey_spiegel says that many to one in to the service we definitely want 20:41:58 <tbachman> #info mickey_spiegel and sanjay say that many-to-one out of a service is questionable 20:42:05 <tbachman> #info mickey_spiegel is fine with allowing it 20:43:09 <tbachman> #info dvorkinista says that this is important, b/c we may be limiting things — like awareness of how many groups are providing the contract 20:43:28 <tbachman> #info mickey_spiegel says as an example, if you add P3, you don’t have to change the configuration. 20:43:49 <mickey_spiegel> #info SLB configuration 20:44:10 <tbachman> mickey_spiegel: thx :) 20:45:15 <tbachman> #info dvorkinista points out that you can think of the terminal as a completely different pool 20:46:17 <tbachman> #info mickey_spiegel says that on the left of the SLB, if you’re in the same desire group, and you’re going from right to left, there’s no way to distinguish 20:46:36 <tbachman> #info dvorkinista says unless you have an understanding of what’s going on in the appliance 20:47:00 <tbachman> #info mickey_spiegel says there’s a question of whether the appliance puts anything in the dataplane that can be used 20:50:09 <tbachman> #info mickey_spiegel says that on the left of the SLB, if you’re in the same desire group, and you’re going from right to left, there’s no way to distinguish whether it came from pool 1 or pool 2 20:50:31 <tbachman> #info mickey_spiegel says this is only a problem if they’re providing different contracts 20:59:49 <tbachman> #info dvorkinista says that the single VIP is the problem 21:01:37 <tbachman> #info in the diagram that dvorkinista drew, CONTR1 and CONTR2 are contracts consumed by ePG C1 21:01:56 <tbachman> #info and CONTR1 is provided by EPGs P1 and P22 21:02:04 <tbachman> #info and CONTR2 is provided by EPG P2 21:03:58 <tbachman> #info mickey_spiegel asks if inheritance can be used in a way where it’s applied on the left side of the chain but not the right 21:04:06 <tbachman> #info dvorkinista says let’s not go there just yet 21:04:20 <tbachman> #info dvorkinista says that the direct return creates problems 21:08:29 <tbachman> #info dvorkinista proposes that we don’t support graph, we only support a chain 21:08:40 <tbachman> #info which means we only have one terminal out of the chain, not two 21:09:03 <tbachman> #info mickey_spiegel says chain or graph doesn’t matter, it only matters if p1 and p2 are the same 21:09:15 <tbachman> #info if you add that restriction, then none of this comes up. 21:09:25 <tbachman> #info mickey_spiegel proposes any contract gets its own VIP 21:09:37 <tbachman> #info dvorkinista says this is a fair restriction 21:10:34 <tbachman> #info sanjay asks how multiple VIPs helps 21:10:54 <tbachman> #info mickey_spiegel says the destination address tells you the VIP, regardless of which side of the SLB you’re on 21:11:15 <tbachman> #info mickey_spiegel says that we need to think about whether there are cases where people need the same VIP 21:13:51 <tbachman> #info dvorkinista says it would be nice to validate these assumptions with the service chaining folks 21:14:24 <tbachman> #action dvorkinista and mickey_spiegel to talk with the service chaining folks 21:14:36 <tbachman> #topic connectors 21:14:47 <tbachman> #info dvorkinista drew connectors as into the function 21:15:26 <tbachman> #info mickey_spiegel says that we want connectors out of the function as well 21:15:49 <tbachman> #info dvorkinista draws function with a terminal 21:15:55 <tbachman> #info where terminal has an in and out 21:16:17 <tbachman> #info and a function can have multiple terminals 21:16:27 <tbachman> #info and they can be on the inputs and outputs 21:16:35 <tbachman> #info mickey_spiegel is fine with this 21:17:37 <tbachman> #info mickey_spiegel asks that regardless of whether these terminals represent VLANs, interfaces, etc. — that’s part of the abstraction 21:17:44 <tbachman> #info dvorkinista says that yes, this is part of the abstraction 21:18:06 <tbachman> #info sanjay says that depending on the function, you will have one or more terminals 21:18:38 <tbachman> #info but that there is a terminal per mapping (e.g. one is a VXLAN tunnel, one is VLANs) 21:18:45 <tbachman> #info dvorkinista says that won’t be in the intent 21:18:59 <tbachman> #info and that architecture-specific constraints shouldn’t be called out in the intent 21:19:12 <tbachman> #info mickey_spiegel says that what the terminal maps to is rendering 21:19:34 <tbachman> #info or enforcement 21:20:00 <tbachman> #info mickey_spiegel notes we have an API freeze in a week 21:20:04 <tbachman> #info is this for post-helium 21:20:05 <tbachman> ? 21:20:12 <tbachman> #info dvorkinista says yes, this is post-helium 21:20:41 <tbachman> #info sanjay asks whether flow-based exceptions will be covered, or will this be post-helium 21:21:00 <tbachman> #info dvorkinista says that helium is just proof of concept, so let’s do it after helium 21:21:24 <tbachman> #endmeeting