17:00:03 <tbachman> #startmeeting tws
17:00:03 <odl_meetbot> Meeting started Mon Mar  9 17:00:03 2015 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:00:03 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:03 <odl_meetbot> The meeting name has been set to 'tws'
17:00:08 <tbachman> #chair alagalah
17:00:08 <odl_meetbot> Current chairs: alagalah tbachman
17:00:37 <regXboi> nice
17:00:58 <tbachman> regXboi: want a chair? :)
17:01:03 <regXboi> nope
17:02:05 <tbachman> #topic NFV Presentation by Ed Warnicke
17:02:53 <ChrisPriceAB> some pound the link for audio please?
17:03:08 <ChrisPriceAB> some alias(someone)
17:03:19 <tbachman> 1-855-244-8681 Call-in toll-free number (US/Canada)
17:03:19 <tbachman> 1-650-479-3207 Call-in toll number (US/Canada)
17:03:20 <tbachman> Access code: 196 592 514
17:03:33 <ChrisPriceAB> no voip?  :(
17:03:58 <tbachman> ChrisPriceAB: here’s the webex link, fwiw: https://meetings.webex.com/collabs/meetings/join?uuid=M749G9M6E4A5JG72SD48WWG57F-9VIB
17:04:00 <edwarnicke> ChrisPriceAB: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M749G9M6E4A5JG72SD48WWG57F-9VIB
17:04:10 * ChrisPriceAB thanks guys!
17:04:15 <tbachman> ChrisPriceAB: np!
17:05:16 <edwarnicke> #link https://docs.google.com/presentation/d/1ztca1yDnxXMXDhTjurnVDt87EWrSA22ZsW29FOZwKUI/edit#slide=id.p
17:05:23 <tbachman> #undo
17:05:23 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1bab450>
17:05:33 <tbachman> #link https://docs.google.com/presentation/d/1ztca1yDnxXMXDhTjurnVDt87EWrSA22ZsW29FOZwKUI/edit#slide=id.p Slides that edwarnicke is presenting on NFV
17:06:21 <tbachman> #info edwarnicke says we’re past the point of thinking what our customers need downstream; A big one for ODL is NFV
17:07:03 <tbachman> #info edwarnicke says there’s a general trend that folks used to think of as separate — like data center morphing into NFV.
17:07:23 <tbachman> #info edwarnicke asks if there is anyone not familiar with existing of NFV, and related topics
17:07:57 <alagalah> #link https://www.opnfv.org/ OpenNFV wiki (for reference)
17:08:15 <tbachman> #info Agenda: brief intro to NFV (where are we, where we need to go); intermission on Unix philosophy; Getting to NFV (Mechanics, motivation for mechanics, proposed interaction model, delivering in Lithium)
17:08:24 <tbachman> #info Agend start: where we are:
17:08:35 <alagalah> #link https://wiki.opnfv.org/ OpenNFV wiki (above is ORG)
17:09:00 <tbachman> #info in the beginning, there was the physical; network funtions that were physical: LB, firewall, routers, P/S-GB, MME, HSS, etc.
17:09:53 <tbachman> #info Agenda: where we want to go: network functions may be virtual or physical as needed; Traffic is steered through NFs as needed, without the necessity of interposition in the natural path of the traffic; traffic moves through the graph of NFs as desired
17:11:14 <tbachman> #info Agenda: what we need to get there: Place VNFs: place VNFs on physical boxes at physical locations in the network; Select traffic/Apply Policy: given EP A and EP B, resolve the policy that needs to be applied to the traffic between them; Service Function Chaining (SFC): allow the policy to speciy a SFC between endpoints through which the traffic will move
17:12:47 <tbachman> #info Agenda: intermission on Unix philosophy; “write programs that do one thing and do it well”, “write programs that work well together”, “write programs to handle text streams, because that is the universal interface” (all credited to Doug McIlroy)
17:13:40 * ChrisPriceAB waiting for the punchline!
17:13:52 * tbachman punches ChrisPriceAB’s line
17:14:03 * ChrisPriceAB ouch!!!
17:14:06 <tbachman> lol
17:14:15 <tbachman> #info Agenda: mechanics: Place NFVs (OpenStack); Select traffic/Apply Policy (OpenDaylight); Service Function Chaining (OpenDaylight)
17:14:20 * regXboi cries for a IDM (irc death match)!
17:16:02 <tbachman> #info Agenda: Motivation for Mechanics: OpenStack knows how to place VMs; OpenDaylight has network expertise; OpenDaylight is designed to manage ‘infrastructure network’; OpenDaylight understands the plurality of possible endpoints (not just VMs, but also mobile handsets, CPE devices, etc.)
17:16:56 * ChrisPriceAB where's that mute button!
17:17:48 <regXboi> oh mestery? you around?
17:18:06 <tbachman> #info Agenda: proposed interplay between ODL/OS: OpenStack neutron driver to talk to OpenDaylight as usual (basics of VM networking); Enhancement to OpenStack “port” object to include ‘labels’ - a list of opaque strings; these can be used to hint the role of a VM in the network (e.g. EPG ‘green’, vnf-type: ‘firewall3’; Interpreted by ODL; allows ‘loose coupling’ in keeping with the Unix model
17:19:12 <tbachman> #info regXboi says edwarnicke has now made this dependent on a change in OpenStack
17:19:28 <tbachman> #info regXboi asks how do you do it until you have that change, assuming you get that change
17:19:41 <tbachman> #info edwarnicke says there’s a great deal that can be done, even without the port change (i.e. adding labels)
17:20:45 <tbachman> #info regXboi suggests look at the “device owner” property of the port object in OpenStack, to see if this can be used instead (won’t have to wait)
17:21:19 <tbachman> #info regXboi says neutron reserves certain values for ports (e.g. neutron router gateway and neutron router interface); but beyond that, regXboi believes you can set this as you wish; limitation is that it’s only a single string
17:21:40 <tbachman> #info Sanjay asks if regXboi is suggesting device owner beomes this string?
17:22:03 <tbachman> #info regXboi says today he knows and cares about device owners that are neutron:router-gateway and neutron:router-interface
17:22:18 <tbachman> #info regXboi says where he’s going is that this may be a way to get around having to wait for additional tags on the port
17:22:28 <tbachman> #info regXboi wishes mestery was here :-)
17:22:45 <tbachman> #info edwarnicke says it’s probably too late for labels for Kilo
17:22:58 <tbachman> #info edwarnicke says it’s probably generally useful as a Unix-model kind of thing
17:23:19 <tbachman> #info regXboi says the other gotcha is that tags have come up on the OpenStack mailing lists before, and the discussions haven’t been pretty
17:23:31 <tbachman> #info edwarnicke says yes, but is willing to start this process
17:24:06 <tbachman> #info ChrisPriceAB says the ODL instance will know how to interpret a certain piece of information; another use case worth investigating is where you deploy a basic network with an identifier, then an application can use that identifier
17:24:20 <tbachman> #info edwarnicke doesn’t like identifiers associated with networks because they are L2 things
17:24:46 <tbachman> #info edwarnicke says if you apply labels to L2 things, this leads to undesired comingling
17:25:12 <tbachman> #info edwarnicke says you end up having to break contracts related to a network being an L2 segment
17:26:02 <tbachman> #info ChrisPriceAB says the only challenge he sees is when instantiating a complex VNF, its the VNF that knows what the network is being constructed
17:27:08 <tbachman> #info edwarnicke says this is like a VNF not being told of a behavior, but the VNF knows that it’s supposed to do that behavior
17:27:23 * tbachman isn’t sure if he captured that last one correctly — ChrisPriceAB, edwarnicke fact-check :)
17:28:02 <tbachman> #info edwarnicke believes that this concept can be included in this architecture
17:28:39 <tbachman> #info edwarnicke says as an example, written into a VNF could be a security credential
17:30:36 * ChrisPriceAB ack
17:30:46 <tbachman> #info Sanjay asks about the VPN example
17:30:57 <tbachman> ChrisPriceAB: thx! :)
17:31:34 <tbachman> #info edwarnicke says that Prem is working on the VPN services project, and one of the intentions is that a VM is part of a hybrid could, and would want to take advantage of a VPN service (e.g. to backhaul)
17:32:12 <tbachman> #info Prem adds that typically what happens is the VPN would be provided by the cloud service provider, and this is a parameter that you’d use to connect
17:32:23 <tbachman> #info Sanjay asks how this intersects with openstack VPNaaS APIs
17:32:59 <tbachman> #info Prem says what happens is someone wants to use OpenStack, and after the L3 setup, you create the tenant isolation
17:33:18 <tbachman> #info Prem says from there on, the neutron part needs to seamlessly work with the gateway
17:33:38 <tbachman> #info Prem says there’s still work going on for stuff after the L3 setup
17:33:54 <tbachman> #info Sanjay says essentially VPN is considered an NFV, in this case
17:34:07 <tbachman> #info Prem says this is correct
17:34:49 <tbachman> #info edwarnicke says with the label mechanism, this information is consumable by whoever’s consuming the VPN label when the neutron call comes in
17:35:09 <tbachman> #info it could be SFC, it could be something else — either way, we use the VPN label to support this
17:36:05 <tbachman> #info Prem says if we have a VM that’s a LBaaS or FWaaS, but don’t have context of the policy except that it needs the service; if it doesn’t understand the policy constructs, how does the integration happen
17:36:30 <tbachman> #info edwarnicke says he has a different deck that alagalah presented at the GBP meeting, which maps the sundry constructs into Group Based Policy constructs
17:37:51 <tbachman> #info Sanjay asks what are the different things that need to be applied when two endpoints in different EPGs; seems this should be driven by wherever the policies are residing (i.e. are they in openstack, ODL)
17:38:16 <tbachman> #info edwarnicke says that information should reside with the thing that understands networks, which is OpenDaylight
17:38:29 <tbachman> #info edwarnicke says as ChrisPriceAB pointed out, maybe this comes from OpenStack
17:39:04 <tbachman> #info alagalah says lets be careful not to conflate the original traffic source/sink with the VNF; labels could be applied on all these things, but have different use cases
17:39:29 <tbachman> #info alagalah says it would be nice to do this in-band; could do it out-of-band, but there’s an attractiveness to do it in-band
17:39:59 <tbachman> #info edwarnicke says his experience with in-band vs. out-of-band shouldn’t be a religious thing; you pretty much have to do both
17:40:04 * ChrisPriceAB where source and sync may be ingress and egress of a composite VNF.
17:40:31 <tbachman> #info Agenda: Delivering on the promise - what can we deliver in Lithium: SFC provides necessary service function chaining; Group Based Policy provides the necessary policy/renderer infrastructure; GBP will provide neutron service in Lithium; GBP and SFC will work together in Lithium
17:40:36 <alagalah> ChrisPriceAB: YES. One persons concrete is another person's abstraction
17:40:58 <tbachman> #info ChrisPriceAB points out where source and sink may be ingress and egress of a composite VNF
17:41:01 * ChrisPriceAB and if one person is abstract?
17:41:19 <tbachman> #info alagalah says yes — on person’s concrete is another person’s abstraction
17:41:33 * ChrisPriceAB stop there... !
17:41:37 <tbachman> lol
17:41:50 <alagalah> tbachman: super-scribe is literal.
17:41:53 <tbachman> lol
17:41:55 <ChrisPriceAB> hehe
17:41:58 <tbachman> virtual-scribe?
17:42:11 <tbachman> Scribe-as-a-Service?
17:42:15 <tbachman> already taken :(
17:42:15 * ChrisPriceAB Chris says hurrah!
17:42:22 <tbachman> lol
17:42:28 <tbachman> SQUIRREL!
17:42:31 <rovarga> on what can we deliver ... M3 is in 10 days for offset-2 things... :)
17:42:54 <tbachman> #info rovarga asks what we can deliver, gi en M3 is in 10 days for offset-2 projects
17:43:11 <tbachman> #info ChrisPriceAB says as soon as we can have policy-enabled networking, the better (in the context of VNFs)
17:44:23 <rovarga> that effectively means that whatever we are going to promise should be there in some form on 3/19
17:44:49 <tbachman> #info rovarga says that effectively means that whatever we are going to promise should be there in some form on 3/19
17:45:29 <edwarnicke> #info M3 isn't end of coding :)
17:46:09 * ChrisPriceAB going to stay muted now, ryan might throw a rock at me.
17:46:12 <tbachman> #info regXboi says his memory of SFC is that it’s mucking around at the packet header level
17:46:24 <tbachman> #info edwarnicke says not necessarily, but there are renderers that muck around with NSH headers
17:46:33 <tbachman> #info regXboi asks if we have an alternative in the case where that’s a no-no
17:46:52 <rovarga> #info M3 is supposed to be the end of introduction of new features
17:47:02 <tbachman> #info regXboi says the devil is in the details, and needs to see a bit more to ensure that we’re not putting ourselves in a use case that doesn’t meet the community needs
17:47:24 <tbachman> #info edwarnicke says there are renderers that use NSH, and renderers that use MPLS; that puts us in the case where it can be used with or without the header manipulation
17:48:00 <tbachman> #info edwarnicke says this stuff gets pushed down to the level of the renderer; there is good loose-coupling here
17:48:18 <tbachman> #info edwarnicke says this is a good attribute of the labels mechanism
17:48:42 * ChrisPriceAB might have to drop off... Agree with Ed, SFC should enable multiple mechanisms.
17:49:25 <tbachman> #info Sanjay says a label is essentially telling you a grouping information of an EP; once an EP interacts with other EPs, the behavior resides in ODL (e.g. which service chain it uses — NSH, etc.); it’s not dependent on the SFC constructs
17:49:29 <tbachman> #info edwarnicke says this is correct
17:49:55 <tbachman> #info Sanjay says how you use that information is entirely up to you.
17:51:44 <tbachman> #info alagalah says that folks on the webex, he did provide links in the WebEx to the OpenNFV work
17:53:54 <tbachman> #info catohornet says she’ll be doing a demo on how to do testing in the robot framework for next week’s TWS
17:54:30 <tbachman> #endmeeting