14:02:01 <tbachman> #startmeeting opnfv-sfc-weekly
14:02:01 <collabot> Meeting started Wed Jul 15 14:02:01 2015 UTC.  The chair is tbachman. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:01 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:02:01 <collabot> The meeting name has been set to 'opnfv_sfc_weekly'
14:02:04 <tbachman> #chair ebrjohn
14:02:04 <collabot> Current chairs: ebrjohn tbachman
14:02:08 <tbachman> anyone else?
14:02:13 <tbachman> #info tbachman
14:02:18 <tbachman> #undo
14:02:18 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2bf95d0>
14:02:24 <tbachman> #topic role call and agenda
14:02:29 <tbachman> #info tbachman
14:03:40 <DaveD_> #help
14:03:55 <tbachman> help?
14:03:56 <fbl> My name is Flavio Leitner, work at Red Hat - Networking Services team and I am joining for the first time today.
14:04:06 <tbachman> hi fbl!
14:04:08 <ebrjohn> #info ebrjohn Brady Johnson
14:04:10 <tbachman> and welcome :)
14:04:16 <fbl> tbachman: hi! thanks
14:04:21 <tbachman> DaveD_: #help?
14:04:25 <tbachman> use /help
14:04:28 <ebrjohn> welcome Flavio
14:04:29 <tbachman> if you’re looking for IRC commands
14:04:37 <DaveD_> #info DaveD_ Dave Dolson
14:05:06 <bryan_att> #info Bryan Sullivan
14:05:10 <paulq> #info Paul Quinn
14:05:10 <DaveD_> I was looking for help on the collabot commands
14:05:26 <lmcdasm> #info
14:05:31 <lmcdasm> #info daniel Smith
14:05:32 <tbachman> yeah — I think /help does it
14:05:47 <collabot> lmcdasm: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
14:05:55 <tbachman> lmcdasm: we started already :)
14:06:00 <tbachman> but thanks!
14:06:00 <lmcdasm> thx:)
14:06:04 <tbachman> lmcdasm: want a chair?
14:06:31 <tbachman> #info repenno sent an email to the discussion list for the demo setup
14:06:31 <ebrjohn> #link https://wiki.opnfv.org/service_function_chaining?&#meetings
14:06:41 <lmcdasm> nah - i prefer to stand :)
14:06:48 <tbachman> #link http://ircbot.wl.linuxfoundation.org/meetings/opnfv-sfc/2015/opnfv-sfc.2015-07-08-14.06.log.html Minutes from last week’s meeting
14:07:05 <tbachman> lmcdasm: lol!
14:07:23 <tbachman> #info ebrjohn says there has been a good discussion on the list re: the orchastration/setup
14:07:36 <ebrjohn> #link https://docs.google.com/presentation/d/1gbhAnrTYbLCrNMhMXin0lxjyg-7IHNPjrlBTIjwAzys/edit?usp=sharing
14:08:01 <bouthors_> #info bouthors
14:08:01 <tbachman> #undo
14:08:01 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2bd5dd0>
14:08:13 <tbachman> #link https://docs.google.com/presentation/d/1gbhAnrTYbLCrNMhMXin0lxjyg-7IHNPjrlBTIjwAzys/edit?usp=sharing Presentation showing setup for SFC
14:08:42 <tbachman> #info 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
14:09:17 <ebrjohn> Use the ODL SFC 102 guide now instead of the 101 guide
14:09:22 <ebrjohn> #link http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-July/003733.html
14:09:37 <tbachman> #info ebrjohn says that folks should use the ODL SFC 102 guide — it supercedes the SFC 101 guide
14:09:51 <tbachman> #undo
14:09:51 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2bfc850>
14:09:53 <tbachman> #undo
14:09:53 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x2bcf790>
14:10:02 <tbachman> #info ebrjohn says that folks should use the ODL SFC 102 guide — it supercedes the SFC 101 guide
14:10:16 <tbachman> #link http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-July/003733.html email with link to SFC 102 guide
14:12:34 <tbachman> #info 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.
14:12:51 <tbachman> #info ebrjohn says we also get the transport type in the data plane locator (VXLAN, MPLS, etc.)
14:13:09 <tbachman> #info ebrjohn says the last piece of information is the IP and port of the VTEP
14:13:27 <tbachman> #info once those 3 pieces of information are available, that’s enough to send to the VNF Manager
14:13:39 <bryan_att> topic for today - I am 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.
14:14:18 <tbachman> #info 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
14:14:46 <bryan_att> I don't see SFC 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.
14:15:03 <tbachman> #info lmcdasm asks which VNF manager people want to use — tacker (sp)?  He’s a bit dubious of tosca, etc.
14:15:14 <tbachman> #info 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.
14:15:20 <bryan_att> i.e. I don't see SFC as invoking VM instantiation on demand. That's a service orchestration function.
14:15:26 <tbachman> #info 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.
14:15:41 <tbachman> #info bryan_att says he doesn’t see SFC as invoking VM instantiation on demand. That's a service orchestration function.
14:16:47 <tbachman> #info 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
14:17:01 <tbachman> #info lmcdasm says he sees it the other way — the VNF manager should be boss
14:17:17 <tbachman> #info paulq says he doesn’t think either GUI is what the user is going to see — it will be something else
14:17:33 <tbachman> #info paulq says there would be something higher level
14:17:45 <tbachman> #info bryan_att says there likely will be a customer provisioning portal to do this
14:19:27 <tbachman> #info paulq says there’s a lot of other functions that might have to live there as well
14:19:35 <tbachman> #undo
14:19:35 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2be66d0>
14:19:59 <tbachman> #info paulq says there’s a lot of other functionality that might have to live there as well
14:20:01 <MR_Sandvine> #info Manuel Rebellon
14:21:18 <tbachman> #info 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
14:22:12 <tbachman> #info ebrjohn says lmcdasm can start playing with tacker to see what’s involved
14:22:25 <bryan_att> TBH I still need 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").
14:23:03 <tbachman> #info 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
14:23:19 <tbachman> #info 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").
14:25:07 <tbachman> #info ebrjohn asks how the VNF manager knows to map for a particular FW on a particular VM?
14:26:23 <tbachman> #info lmcdasm asks if restrictions would be the responsibility of the coder of the portal
14:26:35 <tbachman> #info paulq says that’s consistent with what he’s seen with cataloging systems
14:26:48 <tbachman> #info bouthors_ asks how this works with GBP
14:27:09 <tbachman> #info paulq says GBP doesn’t know what the chain is, per-se, but just has the action of chain
14:27:48 <tbachman> #info 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)
14:27:57 <tbachman> #info paulq says today we have not done this
14:28:26 <tbachman> #info 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
14:29:24 <tbachman> #info paulq says when you hand the packet to the SF itself, it needs NSH or a tag for descrimination
14:31:04 <tbachman> #info ebrjohn asks what’s the trigger to kick of VM creation for SFs
14:31:21 <tbachman> #info ebrjohn says if this is from a higher level orchestration function, what does that look like
14:31:47 <tbachman> #info lmcdasm says if we put all 3 elements in place, we can try it a few ways.
14:32:09 <tbachman> #info lmcdasm says he imagines that ODL talking to VNF manager might be the way to go, and probably not the other direction
14:32:53 <tbachman> #info 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
14:33:11 <tbachman> #info paulq says the question is how do we trigger the request out
14:33:29 <tbachman> #info ebrjohn says the trick is where to put the VNF manager configuration
14:34:43 <tbachman> what’s the argument for not driving from top to bottom — some portal to openstack (any service) to ODL?
14:36:47 <lmcdasm> good question - that was what i was meaning - why not have portal order things thorugh VNF-M and then have the VNF-M inform ODL after?
14:38:08 <tbachman> #info 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
14:38:31 <tbachman> #info ebrjohn says that is part of the creation of the chain/path/rendererd-service-path process in SFC
14:39:54 <bryan_att> 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.
14:40:10 <tbachman> #info 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.”
14:40:26 <tbachman> #info ebrjohn says it’s possible to do that — you can go either way
14:40:56 <tbachman> #info bouthors_ says that when you define a rendered service path, you have to tie a SF to an SFF
14:42:05 <bryan_att> when I say 'it's not clear' I mean that 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
14:42:29 <tbachman> #info 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
14:43:23 <tbachman> #info ebrjohn says let’s have ODL send messages to tacker for now
14:43:28 <lmcdasm> actions - we start with Tacker, we start with using the Service Function creation
14:43:45 <tbachman> if it’s top to bottom, is ODL talking back up to OpenStack?
14:44:03 <DaveD_> I'd like to see some sequence diagrams
14:44:17 <lmcdasm> i dont think so - it would go ODL to VNF-M to Openstack, the VNF-M back to ODL with the information about the VMs (VTEP info)
14:44:18 <tbachman> #info bouthors_ asks if we could augment the SFC model to provide the UUID of the descriptor?
14:45:02 * tbachman agrees with DaveD_
14:45:39 <lmcdasm> working on the sequence diagrams
14:45:54 <lmcdasm> :) - i need to have some more pieces in place to make them more details on what informatino is passed where
14:46:20 <tbachman> I guess I’m missing what tacker is missing that it needs ODL to drive it
14:47:31 <ebrjohn> tbachman: assign me an action point to create sequence diagrams, please
14:47:51 <tbachman> #action ebrjohn to create sequence diagrams on the porposed architectures
14:48:08 <ebrjohn> tbachman: thanks
14:48:14 <tbachman> np!
14:48:26 <tbachman> does it make sense for the VNF to be calling into ODL instead?
14:48:48 <tbachman> either as a notification listener or just reads
14:49:24 <tbachman> I don’t know much about tacker - just seems like a tenant of SW arch — try to call from top to bottom, and not the other way (or both)
14:53:37 * tbachman has to run to his next meeting
14:53:43 <tbachman> ebrjohn: can you do the endmeeting?
14:53:49 <ebrjohn> sure
14:53:52 <tbachman> thx!
14:53:56 <ebrjohn> np!
14:54:05 <ebrjohn> Thanks Thomas
14:55:02 <tbachman> np!
14:57:44 <ebrjohn> #action Paul Quinn will setup an architecture doc (skeleton)
14:58:10 <bryan_att> thanks for helping me level-set on the SFC role vs internal VNFM/EMS role of setting up connections between VNFCs/VMs in a VNF. I think this may have helped others as well on the call (I hope!)
15:01:36 <DaveD_> Thanks for helping me get up to speed.
15:02:56 <MR_Sandvine> Are we considering to have SFC across several NFV deployments?
15:03:41 <lmcdasm> ** good point - i was starting to think about (as well) cross (or stretch) deployments (near-cloud / far-cloud) - meaning a SFC across to NFVi
15:03:53 <lmcdasm> thanks to all - sorry if i ask the dumb questions :)
15:05:15 <MR_Sandvine> no problem
15:05:58 <lmcdasm> that should have been two* NFV-i's
15:06:49 <lmcdasm> if we look at the use case of a geo-redundnacy Service Function - then we will need to think about how a chain will work across two sets of infrastructures.
15:07:12 <lmcdasm> and how ingress/egress would be handles (rules for what goes where) and a whole host of other stuff..
15:07:13 <lmcdasm> :)
15:07:17 <lmcdasm> handled*
15:09:16 <ebrjohn> #endmeeting