17:04:41 <tbachman> #startmeeting gbp_arch
17:04:41 <odl_meetbot> Meeting started Fri Sep  5 17:04:41 2014 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:04:41 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:41 <odl_meetbot> The meeting name has been set to 'gbp_arch'
17:04:47 <tbachman> #topic agenda
17:04:55 <tbachman> SFC Approaches
17:05:08 <tbachman> #topic SFC Discussion
17:05:50 <tbachman> uchau1: do you know if lenrow is around?
17:05:53 <tbachman> for SFC discussion?
17:05:54 <tbachman> : https://cisco.webex.com/ciscosales/j.php?MTID=m8bcdb92198ee8edd9b5cc8e1c2d5709c
17:06:10 <tbachman> #info intent of meeting is to walk through SFC model
17:06:21 <alagalah_> Can all those on webex not talking please mute
17:06:31 <tbachman> #info That will help us deciding what to do in GBP
17:08:07 <tbachman> #info The main model is he service-function.yang
17:08:18 <tbachman> #info There’s a container for all service functions in the network
17:08:23 <uchau1> tbachman: not sure if lenrow is around
17:08:30 <tbachman> #info and a list that holds all the service functions, keyed by service function anme
17:08:55 <tbachman> #info there’s also operational data that the service function code populates based on input from other services (topology, openflow, etc.)
17:09:10 <tbachman> #info There are also RPCs, which are there mostly for completeness
17:09:20 <tbachman> #info as most people use internal APIs or REST interfaces
17:09:57 <tbachman> #info A service function has a name, type (FW, NAT, etc.), management IP address as per IETF, a leaf for NSH-aware capability
17:10:15 <tbachman> #info The service function also has a list of data plane locators
17:10:32 <tbachman> #info This is for how packets can reach the service function (e.g. VLAN ID)
17:11:14 <tbachman> #info mickey_spiegel asks when you have many locators, is it possible that they’re bound in different ways (e.g. in and out), or are they all treated the same
17:11:31 <tbachman> #info rpenno says they don’t make such distinctions.
17:11:46 <tbachman> #info this is how a service function forwarder sends to a function — you send to one of these locators
17:12:37 <tbachman> #info paulq says that once you break from topology, the concept of in/out (service model perspective) goes away
17:13:06 <tbachman> #info The semantic of in/out can be assigned by the policy layer, if desired
17:13:20 <tbachman> #info and it doesn’t matter from a service chaining perspective
17:13:46 <tbachman> #info in/out is used for policy constructs in the firewall, so as long as it can distinguish that packets are coming in and going out it’s fine
17:14:21 <tbachman> #info In other words, you don’t care about the context of the incoming interface (or other distinguisher) isn’t relavent
17:15:10 <tbachman> #info The sf-data-plane-locator is specific to the service function
17:15:52 <tbachman> #info The philosophy behind the model is that they’re very service function chaining specific
17:16:09 <tbachman> #info It presumes there can be more than one administrative domain
17:16:35 <tbachman> #info The service function chain is an ordered list of service function types
17:16:45 <tbachman> #info A type can be a firewall, NAT, proxy, etc.
17:16:55 <tbachman> #info There’s no standardized list for types
17:17:07 <tbachman> #info And users can create their own identities for their own deployment
17:17:19 <tbachman> #info The types can be linked under a service function chain
17:17:59 <tbachman> #info There is also a symmetric property, and ordered-by property
17:18:45 <tbachman> #info The service function chain doesn’t decide which element is going to provide a function (e.g. FW)
17:19:33 <tbachman> #info refer to the recording to see a demonstration of the UI showing the chains
17:19:47 <tbachman> #info The service function forwarder is a switch, router, bridge, etc.
17:20:06 <tbachman> #info The service function forwarder is responsible for sending packets to the service function and getting them back from it
17:20:15 <tbachman> #info It handles the data plane activities
17:21:20 <tbachman> #info There is a list of service function forwarders, keyed by its name
17:21:41 <tbachman> #info There is a classifier attached to the service function forwarder
17:21:57 <tbachman> #info sanjay asks whether a service function forwarder is in every service node
17:22:16 <tbachman> #info rpenno says the service node might not be there in the future
17:22:30 <tbachman> #info paulq says that the service function forwarder is something a user would never see
17:22:37 <tbachman> #info it allows the service chain to occur
17:22:47 <tbachman> #info to build it’s own service function chain topology
17:22:59 <tbachman> #info without the service functions to have to be routers
17:23:14 <tbachman> #info it provides a logical forwarding on behalf of the service function
17:23:32 <tbachman> #info sanjay asks if there’s one forwarder for every service function?
17:24:16 <tbachman> #info paulq says the service function forwarder is logical — it *could* be the service function
17:24:31 <tbachman> #info can a service function be attached to more than one forwarder?
17:24:34 <tbachman> #info yes it can
17:26:17 <tbachman> #info paulq says that in the context of GBP, GBP would control the classifier
17:26:40 <tbachman> #info mickey_spiegel asks if the classifier is at both the head end and the back if you fork
17:26:44 <tbachman> #info paulq says ues
17:28:00 <tbachman> #info The classifier is a service function construct — it’s not like a networking classifier
17:28:32 <tbachman> #info Each service function forwarder has a set of data plane locators
17:28:45 <tbachman> #info This is how service function forwarders can reach each other, and how overlays are constructed
17:29:00 <tbachman> #info They can be GRE data plane locators, VxLAN data plane locators, etc.
17:29:27 <tbachman> #info Sanjay asks if in a path there will be a single data plane locator for the next hop?
17:29:35 <tbachman> #info rpenno says yes
17:29:46 <tbachman> #info but if there are forks, then you can have multiple data plane locators
17:30:08 <tbachman> #info each service function forwarder has a dictionary, which is the list of all service functions it can reach
17:30:36 <tbachman> #info The data plane locators provide this dictionary
17:31:51 <tbachman> #info There is a fail mode — what a forwarder should do if it can’t reach a service function (bypass, drop)
17:32:11 <tbachman> #info There is also work for support for features like HA
17:32:20 <tbachman> #info The service function forwarder is very generic
17:32:40 <tbachman> #info and can apply to anything (vSwitch, router, etc.)
17:33:04 <tbachman> #info The service function forwarder should be augmented for specific use cases (e.g. OVS with OpenStack)
17:33:23 <tbachman> #info This is demonstrated in service-funciton-forwarder-ovs.yang
17:34:33 <tbachman> #info The service function path is the actual places that a packet will visit
17:34:42 <tbachman> #info as it traverses the overlay
17:34:49 <tbachman> #info There is a list of service function paths
17:35:00 <tbachman> #info A service function path is composed of service path hops
17:35:16 <tbachman> #info where each hop is collection of a service function forwarder and service function name
17:35:43 <tbachman> #info The hop counter is incremented on every service function forwarder
17:36:09 <tbachman> #info This is distinct from the service function index, which is incremented on each service function
17:36:24 <tbachman> #info The hop counter is there to deal with scenarios where you have forwarders with out functions
17:36:36 <tbachman> #info most users won’t have to deal with it
17:37:33 <tbachman> #info The starting index is important for systems that don’t want to compute the starting index
17:37:38 <tbachman> #info there’s also a path ID
17:39:09 <tbachman> #info In order to create a path, in the simplest case, you need to give it a name and the name of the chain that it should be instantiated
17:39:48 <tbachman> #info mickey_spiegel asks if you’re creating service function instances for each hop on the chain
17:40:04 <tbachman> #info rpenno says you need to create the catalog of service functions ahead of time
17:40:22 <tbachman> #info mickey_spiegel asks if you allocate individual service functions for each hop along the path
17:40:40 <tbachman> #info rpenno says yes — it will select the most suitable one for that path
17:41:01 <tbachman> #info where suitable could be as simple as picking the first one that it finds
17:41:14 <tbachman> #info rpenno says there is a language for describing this
17:41:27 <tbachman> #info but it hasn’t been committed upstream yet
17:41:41 <tbachman> #info It’s a metadata model for service function characteristics
17:42:02 <tbachman> #info You want the path to be constructed with certain constraints. Today the constraints are based on use cases
17:42:20 <tbachman> #info For example, geographic location, or more sophisticated things like number of connections on a Firewall
17:42:36 <tbachman> #info The model will be a container-based yang model with a list
17:42:45 <tbachman> #info so that the list can be updated when needed
17:45:52 <tbachman> #info mickey_spiegel asks whether you can reuse a service function that’s already been allocated
17:45:56 <tbachman> #info rpenno says you can
17:47:03 <tbachman> #info rpenno says there’s no tenancy here, and that would have to be an augmentation for the service model
17:47:21 <tbachman> #info and tenancy could be used as a constraint, if desired
17:48:39 <tbachman> #info when a service function path is created, it goes to the service function and checks the operational state
17:49:03 <tbachman> #info and checks to see if the service function is in use by this path
17:49:14 <tbachman> #info so, you could put the name of the tenant in the operational state
17:51:14 <tbachman> #info new service types can be added by creating new identities in the yang model
17:51:36 <tbachman> #info The data plane locators for service function and service function forwarder have a structure that’s imported from another SFC model
17:51:53 <tbachman> #info This is done so that you can enhance it as much as you want without touching the service function and service function forwarder
17:54:47 <tbachman> #info rpenno prefers to use groups and uses over leafrefs
17:55:10 <tbachman> #info b/c the java code that’s generated from leafrefs has additional considerations that he prefers to avoid
17:56:41 <tbachman> #info sanjay asks if there are authorization domains — like who can see what?
17:56:51 <tbachman> #info rpenno says that there are, but that will be post-helium
18:00:02 <tbachman> #info There’s still a question as to whether SFC or GBP renders that front-end classifier
18:05:19 <tbachman> #endmeeting