#opendaylight-meeting: tws

Meeting summary

1. NFV Presentation by Ed Warnicke (tbachman, 17:02:05)
   1. https://docs.google.com/presentation/d/1ztca1yDnxXMXDhTjurnVDt87EWrSA22ZsW29FOZwKUI/edit#slide=id.p Slides that edwarnicke is presenting on NFV (tbachman, 17:05:33)
   2. edwarnicke says we’re past the point of thinking what our customers need downstream; A big one for ODL is NFV (tbachman, 17:06:21)
   3. edwarnicke says there’s a general trend that folks used to think of as separate — like data center morphing into NFV. (tbachman, 17:07:03)
   4. edwarnicke asks if there is anyone not familiar with existing of NFV, and related topics (tbachman, 17:07:23)
   5. https://www.opnfv.org/ OpenNFV wiki (for reference) (alagalah, 17:07:57)
   6. 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) (tbachman, 17:08:15)
   7. Agend start: where we are: (tbachman, 17:08:24)
   8. https://wiki.opnfv.org/ OpenNFV wiki (above is ORG) (alagalah, 17:08:35)
   9. in the beginning, there was the physical; network funtions that were physical: LB, firewall, routers, P/S-GB, MME, HSS, etc. (tbachman, 17:09:00)
   10. 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 (tbachman, 17:09:53)
   11. 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 (tbachman, 17:11:14)
   12. 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) (tbachman, 17:12:47)
   13. Agenda: mechanics: Place NFVs (OpenStack); Select traffic/Apply Policy (OpenDaylight); Service Function Chaining (OpenDaylight) (tbachman, 17:14:15)
   14. 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.) (tbachman, 17:16:02)
   15. 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 (tbachman, 17:18:06)
   16. regXboi says edwarnicke has now made this dependent on a change in OpenStack (tbachman, 17:19:12)
   17. regXboi asks how do you do it until you have that change, assuming you get that change (tbachman, 17:19:28)
   18. edwarnicke says there’s a great deal that can be done, even without the port change (i.e. adding labels) (tbachman, 17:19:41)
   19. 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) (tbachman, 17:20:45)
   20. 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 (tbachman, 17:21:19)
   21. Sanjay asks if regXboi is suggesting device owner beomes this string? (tbachman, 17:21:40)
   22. regXboi says today he knows and cares about device owners that are neutron:router-gateway and neutron:router-interface (tbachman, 17:22:03)
   23. 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 (tbachman, 17:22:18)
   24. regXboi wishes mestery was here :-) (tbachman, 17:22:28)
   25. edwarnicke says it’s probably too late for labels for Kilo (tbachman, 17:22:45)
   26. edwarnicke says it’s probably generally useful as a Unix-model kind of thing (tbachman, 17:22:58)
   27. regXboi says the other gotcha is that tags have come up on the OpenStack mailing lists before, and the discussions haven’t been pretty (tbachman, 17:23:19)
   28. edwarnicke says yes, but is willing to start this process (tbachman, 17:23:31)
   29. 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 (tbachman, 17:24:06)
   30. edwarnicke doesn’t like identifiers associated with networks because they are L2 things (tbachman, 17:24:20)
   31. edwarnicke says if you apply labels to L2 things, this leads to undesired comingling (tbachman, 17:24:46)
   32. edwarnicke says you end up having to break contracts related to a network being an L2 segment (tbachman, 17:25:12)
   33. ChrisPriceAB says the only challenge he sees is when instantiating a complex VNF, its the VNF that knows what the network is being constructed (tbachman, 17:26:02)
   34. 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 (tbachman, 17:27:08)
   35. edwarnicke believes that this concept can be included in this architecture (tbachman, 17:28:02)
   36. edwarnicke says as an example, written into a VNF could be a security credential (tbachman, 17:28:39)
   37. Sanjay asks about the VPN example (tbachman, 17:30:46)
   38. 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) (tbachman, 17:31:34)
   39. 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 (tbachman, 17:32:12)
   40. Sanjay asks how this intersects with openstack VPNaaS APIs (tbachman, 17:32:23)
   41. Prem says what happens is someone wants to use OpenStack, and after the L3 setup, you create the tenant isolation (tbachman, 17:32:59)
   42. Prem says from there on, the neutron part needs to seamlessly work with the gateway (tbachman, 17:33:18)
   43. Prem says there’s still work going on for stuff after the L3 setup (tbachman, 17:33:38)
   44. Sanjay says essentially VPN is considered an NFV, in this case (tbachman, 17:33:54)
   45. Prem says this is correct (tbachman, 17:34:07)
   46. edwarnicke says with the label mechanism, this information is consumable by whoever’s consuming the VPN label when the neutron call comes in (tbachman, 17:34:49)
   47. it could be SFC, it could be something else — either way, we use the VPN label to support this (tbachman, 17:35:09)
   48. 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 (tbachman, 17:36:05)
   49. edwarnicke says he has a different deck that alagalah presented at the GBP meeting, which maps the sundry constructs into Group Based Policy constructs (tbachman, 17:36:30)
   50. 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) (tbachman, 17:37:51)
   51. edwarnicke says that information should reside with the thing that understands networks, which is OpenDaylight (tbachman, 17:38:16)
   52. edwarnicke says as ChrisPriceAB pointed out, maybe this comes from OpenStack (tbachman, 17:38:29)
   53. 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 (tbachman, 17:39:04)
   54. 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 (tbachman, 17:39:29)
   55. edwarnicke says his experience with in-band vs. out-of-band shouldn’t be a religious thing; you pretty much have to do both (tbachman, 17:39:59)
   56. 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 (tbachman, 17:40:31)
   57. ChrisPriceAB points out where source and sink may be ingress and egress of a composite VNF (tbachman, 17:40:58)
   58. alagalah says yes — on person’s concrete is another person’s abstraction (tbachman, 17:41:19)
   59. rovarga asks what we can deliver, gi en M3 is in 10 days for offset-2 projects (tbachman, 17:42:54)
   60. ChrisPriceAB says as soon as we can have policy-enabled networking, the better (in the context of VNFs) (tbachman, 17:43:11)
   61. rovarga says that effectively means that whatever we are going to promise should be there in some form on 3/19 (tbachman, 17:44:49)
   62. M3 isn't end of coding :) (edwarnicke, 17:45:29)
   63. regXboi says his memory of SFC is that it’s mucking around at the packet header level (tbachman, 17:46:12)
   64. edwarnicke says not necessarily, but there are renderers that muck around with NSH headers (tbachman, 17:46:24)
   65. regXboi asks if we have an alternative in the case where that’s a no-no (tbachman, 17:46:33)
   66. M3 is supposed to be the end of introduction of new features (rovarga, 17:46:52)
   67. 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 (tbachman, 17:47:02)
   68. 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 (tbachman, 17:47:24)
   69. edwarnicke says this stuff gets pushed down to the level of the renderer; there is good loose-coupling here (tbachman, 17:48:00)
   70. edwarnicke says this is a good attribute of the labels mechanism (tbachman, 17:48:18)
   71. 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 (tbachman, 17:49:25)
   72. edwarnicke says this is correct (tbachman, 17:49:29)
   73. Sanjay says how you use that information is entirely up to you. (tbachman, 17:49:55)
   74. alagalah says that folks on the webex, he did provide links in the WebEx to the OpenNFV work (tbachman, 17:51:44)
   75. catohornet says she’ll be doing a demo on how to do testing in the robot framework for next week’s TWS (tbachman, 17:53:54)

Action items

1. (none)

People present (lines said)

1. tbachman (93)
2. ChrisPriceAB (15)
3. odl_meetbot (5)
4. regXboi (4)
5. alagalah (4)
6. rovarga (3)
7. edwarnicke (3)