17:01:34 <tbachman> #startmeeting sfc_weekly
17:01:34 <odl_meetbot> Meeting started Thu Mar  5 17:01:34 2015 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:01:34 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:34 <odl_meetbot> The meeting name has been set to 'sfc_weekly'
17:01:38 <tbachman> #chair ebrjohn
17:01:38 <odl_meetbot> Current chairs: ebrjohn tbachman
17:02:03 <tbachman> ebrjohn: 896113
17:03:19 <tbachman> #topic agenda
17:03:26 <tbachman> #link https://meetings.opendaylight.org/opendaylight-sfc/2015/sfc_weekly/opendaylight-sfc-sfc_weekly.2015-02-26-17.02.html Minutes from last week’s meeting
17:04:50 <tbachman> #topic status
17:05:04 <tbachman> #info ebrjohn says M3 is in a few weeks
17:05:26 <tbachman> #info ebrjohn has contacted individuals responsible for each functional area to make sure things are progressing
17:05:53 <tbachman> #info repenno and ebrjohn are working on the RSP hops — want to put ingress data plane locator on each hop — for integration with GBP
17:06:32 <tbachman> #info repenno says access lists can be constructed with the UI today
17:06:44 <tbachman> #info access lists are tied to the Service Function Forwarder
17:06:56 <tbachman> #info repenno says a classifier points to an access list
17:07:19 <tbachman> #info The Rendererd Service Path doesn’t know about the access list — just knows about the classifier
17:07:47 <tbachman> #info The SFC agent installs the proper ACL rules using IP tables
17:08:19 <tbachman> #info repenno says there are details to be worked out, such as what happens when you modify the classifier, what happens when you modify the access list
17:09:26 <tbachman> #info The classifier classifies traffic to a particular Rendered Service Path
17:10:19 <tbachman> #info The classifier is optional; the GBP use case can take ownership of the classifier
17:11:06 <tbachman> #info repenno is also working on the OVSDB integration
17:11:21 <tbachman> #info repenno says we can listen for OVS bridge attachments — likely will be first consumer of that feature
17:12:12 <tbachman> #info when something connects, they have to map their nomenclature into the SFC world
17:12:25 <tbachman> #info For example, how is a port identified (e.g. UUID)
17:13:34 <tbachman> #info shlomi published a review for the Service Function Group
17:14:03 <tbachman> #info The first proposal was 2 months ago; want to replace the Service Function with Service Function Group, in order to be able to enable transparency for the user
17:16:20 <tbachman> #info shlomi says one option for bringing this in smoothly is to have a base class that has both Service Function and Service Function Group as derived classes
17:17:50 <tbachman> #info repenno says the solution where SFG is a parallel construct would cause the least amount of change in SFC
17:18:42 <tbachman> #info repenno thinks this won’t realistically be doable in the Lithium time frame
17:22:10 <tbachman> #info repenno says there is a common undercurrent of code that has to be done; you have to do parsing code for the new thing; you have to create a listener that does the parsing; you have to see what the impacts of operations are on this new piece of code;
17:23:07 <tbachman> #info repenno says knowing that these changes are needed, regardless of the approach, you can either implement the code with an impact on the code base (e.g. base class approach), or implement the code in parallel which doesn’t affect the existing code base
17:27:10 <tbachman> #info shlomi is okay with this approach — is hoping to have a meeting to go over this more in detail to be able to go off and implement it
17:28:26 <tbachman> #info ebrjohn points out that we should try to get these type of changes into the code earlier to avoid these type of issues
17:28:42 <tbachman> #info edwarnicke quotes his favorite maxim: “Commit early and commit often"
17:29:23 <tbachman> #info repenno says there’s also a logistic aspect to this — SFC is already used by consumers today, and therefore can’t just change APIs without warning
17:30:10 <tbachman> #info shlomi asks for integration testing, do we have an SFF that knows how to handle groups
17:30:30 <tbachman> #info repenno says no, we don’t. The best course of action is to change the reference SFF (python code) and make it understand groups
17:31:11 <tbachman> #info shlomi asks if it uses REST APIs or openflow
17:31:18 <tbachman> #info repenno sasys it uses REST APIs
17:31:35 <tbachman> #info repenno says a lot of stuff can be copied/pasted from existing calls
17:32:21 <tbachman> #action shlomi to set up a call with repenno and ebrjohn on this topic
17:33:54 <tbachman> #endmeeting