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