#opendaylight-sfc: sfc_weekly

Meeting summary

1. agenda (tbachman, 17:00:54)
   1. https://meetings.opendaylight.org/opendaylight-sfc/2015/sfc_weekly/opendaylight-sfc-sfc_weekly.2015-01-08-16.40.html Last recorded SFC Meeting Minutes (tbachman, 17:01:08)
   
   
2. presentation on scripts by Reinaldo (tbachman, 17:06:04)
   1. rpenno says that SFC gets its config from GUI or REST to input configuration of service functions or service function forwarders into the provider (tbachman, 17:07:48)
   2. 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 (tbachman, 17:08:17)
   3. the rendered service path describes the path that will be taken when traversing the service functions (tbachman, 17:08:36)
   4. The data store provides notifications to listeners — e.g. openflow, REST, LISP (tbachman, 17:09:10)
   5. The notifications say that a new rendered service path was created (tbachman, 17:09:32)
   6. 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 (tbachman, 17:10:07)
   7. edwarnicke points out that each listener figures out whether the notification applies to them (tbachman, 17:10:46)
   8. alagalah asks if everyone listens to the same part, or do they listen to just their part, etc. (tbachman, 17:11:10)
   9. rpenno says that listeners subscribe to the parts that their interested. They all should be interested in the rendered service path (tbachman, 17:11:32)
   10. rpenno says there may be othe parts that they’re interested in as well (tbachman, 17:11:41)
   11. ebrjohn says one thing that hasn’t been addressed yet is that possible duplication could occur, depending on what multiple listeners do (tbachman, 17:12:25)
   12. 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 (tbachman, 17:13:27)
   13. rpenno says the same things happen with deletes and updates (tbachman, 17:13:59)
   14. listeners can save their own state in their own data stores (tbachman, 17:14:11)
   15. rpenno says the demo he’s using has a rendered service path with 3 switches — SFF1, SFF2, and SF3 (tbachman, 17:15:05)
   16. attached to each switch is a service function (e.g. DPI, FW, NAT) (tbachman, 17:15:16)
   17. there are two service paths: ID1 and ID2 (tbachman, 17:15:29)
   18. These paths are symmetric (tbachman, 17:15:41)
   19. when a packet with ID1 is received, the SFF sends the packet to SF1 (tbachman, 17:16:04)
   20. alagalah asks if there’s always a reverse path (tbachman, 17:17:10)
   21. 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) (tbachman, 17:18:03)
   22. the reverse path would be the name of the forward path plus “-reverse” (tbachman, 17:18:19)
   23. A service function forwarder has a data plane locator and a dictionary (tbachman, 17:20:01)
   24. the dictionary indicates the services that it can support (tbachman, 17:20:17)
   25. a service function chain does not tell you where the packets are going to (tbachman, 17:20:34)
   26. the service funcion chain says packets will traverse this chain, and the order of the services (e.g. FW, NAT, etc.) (tbachman, 17:20:54)
   27. the service chain doesn’t indicate which firewall it will traverse — only that it will traverse *a* firewall (tbachman, 17:21:32)
   28. the service function path uses the “blueprint” provided by a service function chain to create the actual path (e.g. *this specific firewall*) (tbachman, 17:22:17)
   29. vina_ermagan asks when you compute the service path, are they computed automatically using the existing service functions (tbachman, 17:24:44)
   30. 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 (tbachman, 17:25:44)
   
   
3. demo (tbachman, 17:26:44)
   1. rpenno uses a python switch as the service function listener for the demo (tbachman, 17:27:02)
   2. adds an SF and SFF to configuration, which triggers notification to the python switch with NSH (tbachman, 17:27:20)
   3. rpenno says SFC has it’s persistence on it’s own, independent of clustering, using config files (tbachman, 17:28:24)
   4. you first create the service function forwarders, then configure the forwarders with their service function dictionary (tbachman, 17:31:36)

Action items

1. (none)

People present (lines said)

1. tbachman (42)
2. odl_meetbot (4)
3. abhijitkumbhare (2)
4. ebrjohn (2)
5. alagalah (1)