#opendaylight-sfc: sfc_weekly

Meeting summary

1. agenda (tbachman, 17:03:19)
   1. 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 (tbachman, 17:03:26)
   
   
2. status (tbachman, 17:04:50)
   1. ebrjohn says M3 is in a few weeks (tbachman, 17:05:04)
   2. ebrjohn has contacted individuals responsible for each functional area to make sure things are progressing (tbachman, 17:05:26)
   3. repenno and ebrjohn are working on the RSP hops — want to put ingress data plane locator on each hop — for integration with GBP (tbachman, 17:05:53)
   4. repenno says access lists can be constructed with the UI today (tbachman, 17:06:32)
   5. access lists are tied to the Service Function Forwarder (tbachman, 17:06:44)
   6. repenno says a classifier points to an access list (tbachman, 17:06:56)
   7. The Rendererd Service Path doesn’t know about the access list — just knows about the classifier (tbachman, 17:07:19)
   8. The SFC agent installs the proper ACL rules using IP tables (tbachman, 17:07:47)
   9. 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 (tbachman, 17:08:19)
   10. The classifier classifies traffic to a particular Rendered Service Path (tbachman, 17:09:26)
   11. The classifier is optional; the GBP use case can take ownership of the classifier (tbachman, 17:10:19)
   12. repenno is also working on the OVSDB integration (tbachman, 17:11:06)
   13. repenno says we can listen for OVS bridge attachments — likely will be first consumer of that feature (tbachman, 17:11:21)
   14. when something connects, they have to map their nomenclature into the SFC world (tbachman, 17:12:12)
   15. For example, how is a port identified (e.g. UUID) (tbachman, 17:12:25)
   16. shlomi published a review for the Service Function Group (tbachman, 17:13:34)
   17. 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 (tbachman, 17:14:03)
   18. 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 (tbachman, 17:16:20)
   19. repenno says the solution where SFG is a parallel construct would cause the least amount of change in SFC (tbachman, 17:17:50)
   20. repenno thinks this won’t realistically be doable in the Lithium time frame (tbachman, 17:18:42)
   21. 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; (tbachman, 17:22:10)
   22. 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 (tbachman, 17:23:07)
   23. 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 (tbachman, 17:27:10)
   24. ebrjohn points out that we should try to get these type of changes into the code earlier to avoid these type of issues (tbachman, 17:28:26)
   25. edwarnicke quotes his favorite maxim: “Commit early and commit often" (tbachman, 17:28:42)
   26. 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 (tbachman, 17:29:23)
   27. shlomi asks for integration testing, do we have an SFF that knows how to handle groups (tbachman, 17:30:10)
   28. repenno says no, we don’t. The best course of action is to change the reference SFF (python code) and make it understand groups (tbachman, 17:30:30)
   29. shlomi asks if it uses REST APIs or openflow (tbachman, 17:31:11)
   30. repenno sasys it uses REST APIs (tbachman, 17:31:18)
   31. repenno says a lot of stuff can be copied/pasted from existing calls (tbachman, 17:31:35)
   32. ACTION: shlomi to set up a call with repenno and ebrjohn on this topic (tbachman, 17:32:21)

Action items

1. shlomi to set up a call with repenno and ebrjohn on this topic

Action items, by person

1. ebrjohn
   1. shlomi to set up a call with repenno and ebrjohn on this topic

People present (lines said)

1. tbachman (39)
2. odl_meetbot (4)
3. ebrjohn (0)