20:03:58 <tbachman> #startmeeting gbp_usecase
20:03:58 <odl_meetbot> Meeting started Mon Jul 14 20:03:58 2014 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:03:58 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:58 <odl_meetbot> The meeting name has been set to 'gbp_usecase'
20:04:06 <tbachman> #topic service insertion
20:05:02 <tbachman> mickey_spiegel: : https://plus.google.com/hangouts/_/calendar/YmFjaG1hbkBub2lyb25ldHdvcmtzLmNvbQ.o51d97i6bthoj48k5cgdkplj2k
20:05:14 <tbachman> (for use case meeting, if you’re interested)
20:05:20 <tbachman> uchau: : https://plus.google.com/hangouts/_/calendar/YmFjaG1hbkBub2lyb25ldHdvcmtzLmNvbQ.o51d97i6bthoj48k5cgdkplj2k
20:05:27 <dvorkinista> ALL: we're on hangouts
20:05:28 <tbachman> (for use case meeting, if you’re interested)
20:06:46 <tbachman> #info picking up conversation from last meeting
20:07:06 <tbachman> #info dlenrow had come up with a way of using EPGs to represent virtual functions
20:08:45 <tbachman> #info dvorkinista draws example on white board
20:09:00 <tbachman> #info starting with contract and a subject, with a bunch of actions, one of which is redirect
20:09:26 <tbachman> #info the chain has a set of logical functions that connect to each other
20:09:44 <tbachman> #info on each side of the chain there are two terminals, an In, and an Out
20:10:09 <tbachman> #info whoever consumes the contract implicitly gets connected to the terminals
20:10:15 <tbachman> The logical function is just like an object
20:10:21 <tbachman> #info The logical function is just like an object
20:10:29 <tbachman> #info it can be enforced like an EPG, but it doesn’t have to
20:10:50 <tbachman> #info If you look at various L4-7 enforcement in the Hypervisor where there is no redirection, you can do this in the dataplane
20:11:07 <tbachman> #info This way you can do firewalling and load balancing in a very straightforward way
20:11:28 <tbachman> #info This allows us to be very architectually independent
20:11:52 <tbachman> #info dlenrow asks if a redirect is a clause?
20:11:58 <tbachman> #info dvorkinista says this is an action
20:12:06 <tbachman> #info uchau asks how we represent the chain
20:12:24 <tbachman> #info dvorkinista says lets not talk about that yet, but it may be a model tweak
20:13:03 <tbachman> #info dlenrow says that we are the network policy service to the extent that anything visible to the network needs to be managed by the control plane, which is in our domain
20:13:21 <tbachman> #info dlenrow says that these functions are provided in the hypervisor, which makes them transparent
20:14:21 <tbachman> sorry folks, had to take a call
20:14:22 <tbachman> am back
20:15:42 <tbachman> #info dvorkinista says that you still need to describe these functions, and the goal is to describe the functions without caring where they’re are implemented or how they’re implemented.
20:16:28 <tbachman> #info dlenrow feels that the policy layer needs to specify that a particular EPG needs to go through a particular service chain, so there could potentially be 100’s of this service function across the network
20:16:43 <tbachman> #info but you don’t care about any of that - the policy is to just make it go through the service chain
20:17:23 <tbachman> #info dlenrow says that its up to the SDN controller to decide where to send it to.
20:17:32 <tbachman> #info dvorkinista agrees
20:18:02 <tbachman> #info dvorkinista doesn’t want to think in terms of addresses, b/c it only works for L3 services
20:18:24 <tbachman> #info dvorkinista says we should assume that it can be physical funciton, virtual function, or implemented in a hypervisor within a virtual switch
20:18:53 <tbachman> #info the idea is express the reqiurement in a way that doesn’t dictate an implementation detail.
20:19:30 <tbachman> #info readams1 notes that at one point we asked if we should do a special model of the service chain using L2 services, but model L3 services using  the EP concept.
20:19:52 <tbachman> #info dvorkinista says what happens if you implement a load balancer in the hypervisor
20:20:01 <tbachman> #info dvorkinista is worried about overloading concepts
20:20:35 <tbachman> #info readams1 says you could say there are L2 services that are transparent, and L3 services that are definied as a service chain, and infrastructure can dictate some of this.
20:21:14 <tbachman> #info readams1 says that for L2 services, they are “bump-in-the-wire” services
20:21:46 <tbachman> #info In L3 services, the EP itself will have as its next hop as the destination of the service
20:22:07 <tbachman> #info dlenrow says that you don’t change default gateways — a redirect is an exception to the rules, nto a reconfiguration of the rules
20:22:46 <tbachman> #info dvorkinista says that with SLB, gateways, FW’s w/NAT, from the standpoint of the consumer, you’re talking to that specific function
20:23:05 <tbachman> #info dvorkinista draws a group1 and a group2, along with a load balancer
20:23:13 <tbachman> #info the load balancer has a VIP
20:23:27 <tbachman> #info group1 treats the load balancer as the IP address that it talks to
20:23:38 <tbachman> #info it’s kind of like an EP sitting in its dedicated group
20:24:01 <tbachman> #info dlenrow says that if you’re a tenant, you’d be completely unaware of the elements in the service chain
20:24:26 <tbachman> #info something further up the heirarchy is the one that handles adding the function transparently
20:24:35 <tbachman> #info dvorkinista says that typically those services are transparent
20:25:28 <tbachman> #info mickey_spiegel says that there are 3 cases
20:25:51 <tbachman> #info transparent where destIP/destMAC are the destination
20:26:00 <tbachman> #info a case where destIP is destination but destMAC isn’t
20:26:07 <tbachman> #info and case where destIP is the service
20:26:35 <tbachman> #info dvorkinista says there are a lot of devices out there that make this challenging, but we can separate them into these 3 categories
20:27:45 <tbachman> #info mickey_spiegel says that we also need to be careful with load balancers, the source address may be the original L3 address, but in other cases, it may be a much different address
20:28:10 <tbachman> #info dvorkinista says lets separate two use cases
20:28:26 <tbachman> #info one use case is where user knows which function he wants to subject his traffic two
20:28:38 <tbachman> #info and the other where a service provider wants to do this transparently
20:28:59 <tbachman> #info mickey_spiegel would like it to be the infrastructure policies to control this
20:32:21 <sanjayagrawal> hi
20:32:42 <sanjayagrawal> please send me the webex ID of the ongoing GBP meeting
20:33:07 <tbachman> sanjayagrawal: I don’t think we have it at the moment — we’re going to have to create a new one
20:33:09 <tbachman> stay tuned
20:33:26 <readams> https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.uolfotg4sa666uvf4iefogm44k
20:33:34 <tbachman> I think we’re at 10
20:34:56 <tbachman> #info dlenrow says there are two different things
20:35:11 <tbachman> #info case where theree’s a server load balancer that a tenant is aware of
20:35:25 <tbachman> #info dlenrow claims that none of that has nothing to do with service chaining
20:35:36 <tbachman> #info dlenrow and that the service chain is invisible to the tenant
20:35:47 <tbachman> #info dvorkinista says what if he wants to have his own firewall
20:35:59 <tbachman> #info and explicitly wants to define a chain that works a particular way
20:36:14 <tbachman> #info dlenrow looks at service chaining as a provider service
20:36:20 <tbachman> #info dvorkinista says that there are two cases
20:36:42 <tbachman> #info dlenrow says both cases have merit, but only one of them is NFV (i.e. which service providers care about)
20:36:54 <tbachman> #info dlenrow feels that service chaining is something very specific
20:38:44 <tbachman> #info dvorkinista says we can call the other case service insertion instead of service function chaining
20:39:27 <tbachman> #info The service provider case can remain service function chaining/NFV
20:41:11 <tbachman> #info readams provides an example of an AWS load balancer, where the user can allocate and manage the load balancer
20:41:30 <tbachman> #info alagalah says that one is explicit and the other is implicit
20:41:50 <tbachman> #info dlenrow says we should solve these two use cases separately
20:42:12 <tbachman> #info dvorkinista thinks we can still describe them in the exact same way (similar syntax and semantics)
20:42:25 <tbachman> #info and therefore can rely on a very similar model to achieve both of them
20:44:14 <tbachman> #info mickey_spiegel want says that the datacenter explicit use case is a very important one
20:46:38 <tbachman> #info dvorkinista says lets think about this and reconvene in Friday’s arch meeting
20:47:11 <tbachman> #info dlenrow would like to push on
20:47:20 <tbachman> #info dvorkinista unfortunately has another call in 15 minutes
20:47:46 <tbachman> #info dlenrow would like to see a specific proposal that we can execute against
20:47:55 <tbachman> #info dvorkinista asks the format of such a proposal
20:48:24 <tbachman> #info dlenrow asks if this is complete
20:48:34 <tbachman> #info dvorkinista feels it isn’t, but that it’s one we can add to
20:48:50 <tbachman> #info readams says that we need someone to come up with a strawman proposal to talk aruond
20:49:20 <tbachman> #action dvorkinista will draw up a strawman proposal
20:49:55 <tbachman> #action dlenrow will come up with a small handful of service chain examples to walk through based on the strawman to see how well it works
20:51:58 <tbachman> #action alagalah to set up webexs for the meetings
20:52:02 <tbachman> #endmeeting