17:00:03 #startmeeting tws 17:00:03 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:03 The meeting name has been set to 'tws' 17:00:08 #chair alagalah 17:00:08 Current chairs: alagalah tbachman 17:00:37 nice 17:00:58 regXboi: want a chair? :) 17:01:03 nope 17:02:05 #topic NFV Presentation by Ed Warnicke 17:02:53 some pound the link for audio please? 17:03:08 some alias(someone) 17:03:19 1-855-244-8681 Call-in toll-free number (US/Canada) 17:03:19 1-650-479-3207 Call-in toll number (US/Canada) 17:03:20 Access code: 196 592 514 17:03:33 no voip? :( 17:03:58 ChrisPriceAB: here’s the webex link, fwiw: https://meetings.webex.com/collabs/meetings/join?uuid=M749G9M6E4A5JG72SD48WWG57F-9VIB 17:04:00 ChrisPriceAB: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M749G9M6E4A5JG72SD48WWG57F-9VIB 17:04:10 * ChrisPriceAB thanks guys! 17:04:15 ChrisPriceAB: np! 17:05:16 #link https://docs.google.com/presentation/d/1ztca1yDnxXMXDhTjurnVDt87EWrSA22ZsW29FOZwKUI/edit#slide=id.p 17:05:23 #undo 17:05:23 Removing item from minutes: 17:05:33 #link https://docs.google.com/presentation/d/1ztca1yDnxXMXDhTjurnVDt87EWrSA22ZsW29FOZwKUI/edit#slide=id.p Slides that edwarnicke is presenting on NFV 17:06:21 #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 #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 #info edwarnicke asks if there is anyone not familiar with existing of NFV, and related topics 17:07:57 #link https://www.opnfv.org/ OpenNFV wiki (for reference) 17:08:15 #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 #info Agend start: where we are: 17:08:35 #link https://wiki.opnfv.org/ OpenNFV wiki (above is ORG) 17:09:00 #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 #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 #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 #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 lol 17:14:15 #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 #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 oh mestery? you around? 17:18:06 #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 #info regXboi says edwarnicke has now made this dependent on a change in OpenStack 17:19:28 #info regXboi asks how do you do it until you have that change, assuming you get that change 17:19:41 #info edwarnicke says there’s a great deal that can be done, even without the port change (i.e. adding labels) 17:20:45 #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 #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 #info Sanjay asks if regXboi is suggesting device owner beomes this string? 17:22:03 #info regXboi says today he knows and cares about device owners that are neutron:router-gateway and neutron:router-interface 17:22:18 #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 #info regXboi wishes mestery was here :-) 17:22:45 #info edwarnicke says it’s probably too late for labels for Kilo 17:22:58 #info edwarnicke says it’s probably generally useful as a Unix-model kind of thing 17:23:19 #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 #info edwarnicke says yes, but is willing to start this process 17:24:06 #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 #info edwarnicke doesn’t like identifiers associated with networks because they are L2 things 17:24:46 #info edwarnicke says if you apply labels to L2 things, this leads to undesired comingling 17:25:12 #info edwarnicke says you end up having to break contracts related to a network being an L2 segment 17:26:02 #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 #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 #info edwarnicke believes that this concept can be included in this architecture 17:28:39 #info edwarnicke says as an example, written into a VNF could be a security credential 17:30:36 * ChrisPriceAB ack 17:30:46 #info Sanjay asks about the VPN example 17:30:57 ChrisPriceAB: thx! :) 17:31:34 #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 #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 #info Sanjay asks how this intersects with openstack VPNaaS APIs 17:32:59 #info Prem says what happens is someone wants to use OpenStack, and after the L3 setup, you create the tenant isolation 17:33:18 #info Prem says from there on, the neutron part needs to seamlessly work with the gateway 17:33:38 #info Prem says there’s still work going on for stuff after the L3 setup 17:33:54 #info Sanjay says essentially VPN is considered an NFV, in this case 17:34:07 #info Prem says this is correct 17:34:49 #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 #info it could be SFC, it could be something else — either way, we use the VPN label to support this 17:36:05 #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 #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 #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 #info edwarnicke says that information should reside with the thing that understands networks, which is OpenDaylight 17:38:29 #info edwarnicke says as ChrisPriceAB pointed out, maybe this comes from OpenStack 17:39:04 #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 #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 #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 #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 ChrisPriceAB: YES. One persons concrete is another person's abstraction 17:40:58 #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 #info alagalah says yes — on person’s concrete is another person’s abstraction 17:41:33 * ChrisPriceAB stop there... ! 17:41:37 lol 17:41:50 tbachman: super-scribe is literal. 17:41:53 lol 17:41:55 hehe 17:41:58 virtual-scribe? 17:42:11 Scribe-as-a-Service? 17:42:15 already taken :( 17:42:15 * ChrisPriceAB Chris says hurrah! 17:42:22 lol 17:42:28 SQUIRREL! 17:42:31 on what can we deliver ... M3 is in 10 days for offset-2 things... :) 17:42:54 #info rovarga asks what we can deliver, gi en M3 is in 10 days for offset-2 projects 17:43:11 #info ChrisPriceAB says as soon as we can have policy-enabled networking, the better (in the context of VNFs) 17:44:23 that effectively means that whatever we are going to promise should be there in some form on 3/19 17:44:49 #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 #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 #info regXboi says his memory of SFC is that it’s mucking around at the packet header level 17:46:24 #info edwarnicke says not necessarily, but there are renderers that muck around with NSH headers 17:46:33 #info regXboi asks if we have an alternative in the case where that’s a no-no 17:46:52 #info M3 is supposed to be the end of introduction of new features 17:47:02 #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 #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 #info edwarnicke says this stuff gets pushed down to the level of the renderer; there is good loose-coupling here 17:48:18 #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 #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 #info edwarnicke says this is correct 17:49:55 #info Sanjay says how you use that information is entirely up to you. 17:51:44 #info alagalah says that folks on the webex, he did provide links in the WebEx to the OpenNFV work 17:53:54 #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 #endmeeting