#opnfv-sfc: opnfv-sfc-weekly

Meeting started by tbachman at 14:02:01 UTC (full logs).

Meeting summary

  1. role call and agenda (tbachman, 14:02:24)
    1. tbachman (tbachman, 14:02:29)
    2. HELP: (DaveD_, 14:03:40)
    3. ebrjohn Brady Johnson (ebrjohn, 14:04:08)
    4. DaveD_ Dave Dolson (DaveD_, 14:04:37)
    5. Bryan Sullivan (bryan_att, 14:05:06)
    6. Paul Quinn (paulq, 14:05:10)
    7. (lmcdasm, 14:05:26)
    8. daniel Smith (lmcdasm, 14:05:31)
    9. repenno sent an email to the discussion list for the demo setup (tbachman, 14:06:31)
    10. https://wiki.opnfv.org/service_function_chaining?&#meetings (ebrjohn, 14:06:31)
    11. http://ircbot.wl.linuxfoundation.org/meetings/opnfv-sfc/2015/opnfv-sfc.2015-07-08-14.06.log.html Minutes from last week’s meeting (tbachman, 14:06:48)
    12. ebrjohn says there has been a good discussion on the list re: the orchastration/setup (tbachman, 14:07:23)
    13. https://docs.google.com/presentation/d/1gbhAnrTYbLCrNMhMXin0lxjyg-7IHNPjrlBTIjwAzys/edit?usp=sharing (ebrjohn, 14:07:36)
    14. https://docs.google.com/presentation/d/1gbhAnrTYbLCrNMhMXin0lxjyg-7IHNPjrlBTIjwAzys/edit?usp=sharing Presentation showing setup for SFC (tbachman, 14:08:13)
    15. lmcdasm says he has pictures on once br-sfc is up, how that’s supposed to work, along with repenno’s doc on SFC-102 (tbachman, 14:08:42)
    16. ebrjohn says that folks should use the ODL SFC 102 guide — it supercedes the SFC 101 guide (tbachman, 14:10:02)
    17. http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-July/003733.html email with link to SFC 102 guide (tbachman, 14:10:16)
    18. ebrjohn says that when ODL SFC receives configuration for the SFs, the main piece of information in that configuration is the service function type — firewall, QoS, DPI, NAPT, etc. (tbachman, 14:12:34)
    19. ebrjohn says we also get the transport type in the data plane locator (VXLAN, MPLS, etc.) (tbachman, 14:12:51)
    20. ebrjohn says the last piece of information is the IP and port of the VTEP (tbachman, 14:13:09)
    21. once those 3 pieces of information are available, that’s enough to send to the VNF Manager (tbachman, 14:13:27)
    22. lmcdasm says it’s a question realy of undersanding the flow — SFC will send to the VNF and say “give me a VM that satisifies this service type, this transport type,” ,etc. — or is it the other way around, where the VNF asks SFC for that information (tbachman, 14:14:18)
    23. lmcdasm asks which VNF manager people want to use — tacker (sp)? He’s a bit dubious of tosca, etc. (tbachman, 14:15:03)
    24. bryan_att is looking into how ODL SFC etc relates to the BGP-VPN based SFC work that we are looking into as a Neutron-related project in OpenStack. I'd like any expert thoughts on how the two relate. (tbachman, 14:15:14)
    25. bryan_att sasys he doesn’t see FC as a higher-layer service orchestration function, rather as a mechanism to arrange a chain out of components/resources that have already been instantiated, e.g. known VMs and ports they have. (tbachman, 14:15:26)
    26. bryan_att says he doesn’t see SFC as invoking VM instantiation on demand. That's a service orchestration function. (tbachman, 14:15:41)
    27. paulq says the former is more consistent, where the user says they need a chain of XYZ, and we can check if a chain is already there and can be used (tbachman, 14:16:47)
    28. lmcdasm says he sees it the other way — the VNF manager should be boss (tbachman, 14:17:01)
    29. paulq says he doesn’t think either GUI is what the user is going to see — it will be something else (tbachman, 14:17:17)
    30. paulq says there would be something higher level (tbachman, 14:17:33)
    31. bryan_att says there likely will be a customer provisioning portal to do this (tbachman, 14:17:45)
    32. paulq says there’s a lot of other functionality that might have to live there as well (tbachman, 14:19:59)
    33. Manuel Rebellon (MR_Sandvine, 14:20:01)
    34. paulq says at one point, over time we’re going to want to migrate information to having constraints, more than just the type of service (tbachman, 14:21:18)
    35. ebrjohn says lmcdasm can start playing with tacker to see what’s involved (tbachman, 14:22:12)
    36. paulq says that to test tacker, it’s probably easiest if there’s no service type ready (e.g. firewall) it just goes and creates one (tbachman, 14:23:03)
    37. bryan_att says he still needs to look into the SFC project details in ODL to understand the scope and focus better. I was assuming it was a "meta-NB API" that enabled NFVO/VNFM to connect functions/VMs as needed into a chain. But what's needed in the chain, and whether existing or new resources are used, are determined by the NFVO (what we call "service orchestrator"). (tbachman, 14:23:19)
    38. ebrjohn asks how the VNF manager knows to map for a particular FW on a particular VM? (tbachman, 14:25:07)
    39. lmcdasm asks if restrictions would be the responsibility of the coder of the portal (tbachman, 14:26:23)
    40. paulq says that’s consistent with what he’s seen with cataloging systems (tbachman, 14:26:35)
    41. bouthors_ asks how this works with GBP (tbachman, 14:26:48)
    42. paulq says GBP doesn’t know what the chain is, per-se, but just has the action of chain (tbachman, 14:27:09)
    43. bouthors_ asks if the service functions are tied to the method of service chaining implemented (e.g. this SF can’t be in an NSH chain if it’s not NSH aware) (tbachman, 14:27:48)
    44. paulq says today we have not done this (tbachman, 14:27:57)
    45. bouthors_ says if the SF is dependent on the chaining methodology, then we need the capability of defining the chain as well to ensure compatibility (tbachman, 14:28:26)
    46. paulq says when you hand the packet to the SF itself, it needs NSH or a tag for descrimination (tbachman, 14:29:24)
    47. ebrjohn asks what’s the trigger to kick of VM creation for SFs (tbachman, 14:31:04)
    48. ebrjohn says if this is from a higher level orchestration function, what does that look like (tbachman, 14:31:21)
    49. lmcdasm says if we put all 3 elements in place, we can try it a few ways. (tbachman, 14:31:47)
    50. lmcdasm says he imagines that ODL talking to VNF manager might be the way to go, and probably not the other direction (tbachman, 14:32:09)
    51. ebrjohn says if we do some dev on the SB REST listener, we need to be able to tell it to go talk to the VNF manager to create the VMs (tbachman, 14:32:53)
    52. paulq says the question is how do we trigger the request out (tbachman, 14:33:11)
    53. ebrjohn says the trick is where to put the VNF manager configuration (tbachman, 14:33:29)
    54. DaveD_ asks if we require a chain with certain functions, if a given function already exists, which agent decides whether the existing function is used or if a new one is spun up (tbachman, 14:38:08)
    55. ebrjohn says that is part of the creation of the chain/path/rendererd-service-path process in SFC (tbachman, 14:38:31)
    56. bryan_att says “it's not clear to me that ODL is the right platform to determine whether there are active/available resources for a chain, or whether new resources need to be spun up. Certainly an option, but in some NFVI environments this may be a role provided by the service orchestrator.” (tbachman, 14:40:10)
    57. ebrjohn says it’s possible to do that — you can go either way (tbachman, 14:40:26)
    58. bouthors_ says that when you define a rendered service path, you have to tie a SF to an SFF (tbachman, 14:40:56)
    59. bryan_att says “It's certainly possible that ODL could do this and I don't think we (as an end-user) have developed a strong opinion or concrete alternate proposal so far... so we need to see how well ODL's project supports this and how it integrates/synergizes with what we have been calling our service orchestrator (tbachman, 14:42:29)
    60. ebrjohn says let’s have ODL send messages to tacker for now (tbachman, 14:43:23)
    61. bouthors_ asks if we could augment the SFC model to provide the UUID of the descriptor? (tbachman, 14:44:18)
    62. ACTION: ebrjohn to create sequence diagrams on the porposed architectures (tbachman, 14:47:51)
    63. ACTION: Paul Quinn will setup an architecture doc (skeleton) (ebrjohn, 14:57:44)

Meeting ended at 15:09:16 UTC (full logs).

Action items

  1. ebrjohn to create sequence diagrams on the porposed architectures
  2. Paul Quinn will setup an architecture doc (skeleton)

Action items, by person

  1. ebrjohn
    1. ebrjohn to create sequence diagrams on the porposed architectures

People present (lines said)

  1. tbachman (87)
  2. lmcdasm (16)
  3. ebrjohn (13)
  4. collabot (10)
  5. bryan_att (8)
  6. DaveD_ (5)
  7. MR_Sandvine (3)
  8. fbl (2)
  9. paulq (1)
  10. bouthors_ (1)

Generated by MeetBot 0.1.4.