17:00:12 <tbachman> #startmeeting sfc_weekly
17:00:12 <odl_meetbot> Meeting started Thu Feb  5 17:00:12 2015 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:00:12 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:12 <odl_meetbot> The meeting name has been set to 'sfc_weekly'
17:00:29 <tbachman> #chair ebrjohn
17:00:29 <odl_meetbot> Current chairs: ebrjohn tbachman
17:00:54 <tbachman> #topic agenda
17:01:08 <tbachman> #link https://meetings.opendaylight.org/opendaylight-sfc/2015/sfc_weekly/opendaylight-sfc-sfc_weekly.2015-01-08-16.40.html Last recorded SFC Meeting Minutes
17:06:04 <tbachman> #topic presentation on scripts by Reinaldo
17:07:48 <tbachman> #info rpenno says that SFC gets its config from GUI or REST to input configuration of service functions or service function forwarders into the provider
17:08:17 <tbachman> #info the provider uses this information, along with other sources, and creates an output of service function paths and rendered service paths into the data store
17:08:36 <tbachman> #info the rendered service path describes the path that will be taken when traversing the service functions
17:09:10 <tbachman> #info The data store provides notifications to listeners — e.g. openflow, REST, LISP
17:09:32 <tbachman> #info The notifications say that a new rendered service path was created
17:10:07 <tbachman> #info This makes the architecture a point to multipoint system, where the provider has no idea of who the listeners are, and the listeners have no notion of who created the information, making for a decoupled architecture
17:10:46 <tbachman> #info edwarnicke points out that each listener figures out whether the notification applies to them
17:11:10 <tbachman> #info alagalah asks if everyone listens to the same part, or do they listen to just their part, etc.
17:11:32 <tbachman> #info rpenno says that listeners subscribe to the parts that their interested. They all should be interested in the rendered service path
17:11:41 <tbachman> #info rpenno says there may be othe parts that they’re interested in as well
17:12:25 <tbachman> #info ebrjohn says one thing that hasn’t been addressed yet is that possible duplication could occur, depending on what multiple listeners do
17:12:42 <alagalah> ebrjohn: Brady ?
17:12:59 <tbachman> alagalah: /whois ebrjohn
17:13:27 <tbachman> #info rpenno says the REST listener will use the rendered service path and look at the switches it’s responsible for, and will program all the switches
17:13:59 <tbachman> #info rpenno says the same things happen with deletes and updates
17:14:11 <tbachman> #info listeners can save their own state in their own data stores
17:15:05 <tbachman> #info rpenno says the demo he’s using has a rendered service path with 3 switches — SFF1, SFF2, and SF3
17:15:16 <tbachman> #info attached to each switch is a service function (e.g. DPI, FW, NAT)
17:15:29 <tbachman> #info there are two service paths: ID1 and ID2
17:15:41 <tbachman> #info These paths are symmetric
17:16:04 <tbachman> #info when a packet with ID1 is received, the SFF sends the packet to SF1
17:17:10 <tbachman> #info alagalah asks if there’s always a reverse path
17:18:03 <tbachman> #info rpenno says that when you ask for a path to be created, there’s a leaf node for indicating whether the path is to be symmetric (true/false)
17:18:19 <tbachman> #info the reverse path would be the name of the forward path plus “-reverse”
17:20:01 <tbachman> #info A service function forwarder has a data plane locator and a dictionary
17:20:17 <tbachman> #info the dictionary indicates the services that it can support
17:20:34 <tbachman> #info a service function chain does not tell you where the packets are going to
17:20:54 <tbachman> #info the service funcion chain says packets will traverse this chain, and the order of the services (e.g. FW, NAT, etc.)
17:21:32 <tbachman> #info the service chain doesn’t indicate which firewall it will traverse — only that it will traverse *a* firewall
17:22:13 * ebrjohn Right!
17:22:17 <tbachman> #info the service function path uses the “blueprint” provided by a service function chain to create the actual path (e.g. *this specific firewall*)
17:24:44 <tbachman> #info vina_ermagan asks when you compute the service path, are they computed automatically using the existing service functions
17:25:44 <tbachman> #info rpenno says yes — when you constuct a service path, you look at the chain to see what is needed, and it goes through all the candidate service functions, as well as which functions are service by the service function forwarders with the same transport, and if so, it uses those candidates to create the rendered service path
17:26:44 <tbachman> #topic demo
17:27:02 <tbachman> #info rpenno uses a python switch as the service function listener for the demo
17:27:20 <tbachman> #info adds an SF and SFF to configuration, which triggers notification to the python switch with NSH
17:28:24 <tbachman> #info rpenno says SFC has it’s persistence on it’s own, independent of clustering, using config files
17:31:36 <tbachman> #info you first create the service function forwarders, then configure the forwarders with their service function dictionary
17:33:12 <abhijitkumbhare> ebrjohn - you can ask phrobb for the Webex recording link - and add it somewhere on the wiki
17:33:22 <abhijitkumbhare> I mean after the meeting
17:34:54 <ebrjohn> ok
17:55:37 <tbachman> #endmeeting