From OpenFlow Wiki

Contents 1 Meeting Minutes for SWAI, 24 June 2010 2 Present 3 Agenda 4 Meeting Minutes 4.1 OFTest Status 4.2 OpenFlow Porting Kit Discussion 4.2.1 The Original Motivating Email 4.2.2 Nick's Demo Exposure Plan 4.2.3 Responses to The Demo Exposure Plan 4.2.4 Engineering Manager Decisions 4.2.5 Spec Required To Define Protocol 4.2.6 OpenFlow Adoption Questions 4.2.7 Have and Need 4.2.8 Actions

Meeting Minutes for SWAI, 24 June 2010

Present

Bob L, Asher, Glen, Yiannis, Tatsuya, Masa, Dan

Agenda

• Test framework and test development continued
• OF Porting Kit

Meeting Minutes

OFTest Status

We had a brief update on test status:

• Please review changes to the Tutorial Page.
• Note that the old BlackBox test coverage list was unearthed here. We should use this to measure our current coverage with OFTest.

OpenFlow Porting Kit Discussion

We then ventured into a long discussion initiated by Asher to address the need to provide collateral to vendors who are considering/committed to integrating OpenFlow support into their products. A wiki page will be started to discuss this, but here are the free-form thoughts generated by the discussion.

The Original Motivating Email

Asher started with an overview of the problem.

Identify what we think might be useful to hand to partners who are planning to add OF1.0 support to a switch or develop a controller.

Problem statement: what do we give an engineering manager or engineer at Huawei, Cisco, Juniper, HP, Netgear, Dell, etc... So they can figure out roughly how much effort OF development will take and how they’ll know when they are done? Assumption is marketing has already said, “Do it,” or, “Figure out effort to do it.”

Very broad categories:

• Specifications
• Switch source code (drivers, agents, vSwitch)
• Controllers (source code, demos)
• Demos (Learning switch, security, mobility, etc)
• Hardware recommendations (ODM switch, NetFPGA, reference platform for vSwitch)
• Test suites (compliance, performance)
• FlowVisor (not sure what to put here)
• Performance measurement (flow capacity, flow setups / second)

Nick's Demo Exposure Plan

Dan then presented an idea from Nick for this:

• Expose the VOIP flow-dragging demo to the outside world via a dataplane and possibly control plane tunnel; leave the demo running here at Stanford and available.
• Distribute the NetFPGA server with some additional software
  • Mininet sample network
  • Pre-configured tunnels to connect to the demo running at Stanford

Out of the box, the user can see the demo integrated with their on site box. Then, when they've developed their target switch, they can connect it to the NetFPGA server and see that integrated into the demo.

Responses to The Demo Exposure Plan

This was pretty luke warm actually.

• Why expose the dataplane from Stanford?
• What significant benefit do you get to providing this, versus, say, providing a comprehensive test suite for the switch?
  • I argued that integrating into a demo does expose a lot of configuration work and system level testing that probably won't be covered by out test suite soon.
• Would we be better off focusing on controller packaging and distribution?
• The demo seems critical for mktg, but not for the porting kit
  • I argued that the decision by a vendor to integrate OF will be ongoing over the process

Engineering Manager Decisions

The point of the porting kit is to support decision making and evaluation related to OpenFlow integration. There are really three steps (not necessarily done sequentially):

• Show demo of OpenFlow on vendor HW
• Define a product that includes OF; How will OF support be integrated into the vendor's product line?
• Evaluate the effort to get to product defined above

The requirements on the porting kit are somewhat different depending on which phase of the above processes we're addressing.

Spec Required To Define Protocol

It was pointed out that the spec is not really complete without an implementation. Masa gave the following specific example:

• If a flow mod is specified as L2, but the TCP port numbers are specified:
  • The Stanford reference SW will ignore the port numbers and install the flow.
  • Open vSwitch will return an error.

This is really bad and we need to address it, probably in a conformance test suite.

OpenFlow Adoption Questions

We realized that there were some more fundamental questions going on here. Perhaps the most important regards Stanford's strategy for pushing OpenFlow adoption going forward. The underlying question is:

• Where to you integrate with the existing world:
  • In the switch?
  • In the network?

That is, should Stanford focus on:

• (Hybrid) Providing support and assistance to generate solutions for integration of OpenFlow into existing product portfolios? Or:
• (Pure) Focus on the production and hardening of pure OpenFlow switches.

In the second case, the assumption is that pure OF switches can be integrated into a network as the network expands or at the point of the switch replacement. Timing here is critical and the coming 10G upgrade cycle will be pivotal in this.

If we seriously hope to integrate at the network level, we need to identify:

• What is the minimal set of protocols required for a pure OF switch in order to inter-operate with existing networks.

Providing a demo of this at the building level, or perhaps a cluster interfacing to Internet2, or a small set of pure switches introduced into an existing subnet would be useful.

Have and Need

I generated a short list of what we have and need. However, the work is really about coordinating, focusing and integrating the right pieces.

• Have
  • NetFPGA server
  • NetFPGA SW release
  • Stanford reference switch SW
  • OvS
  • Beacon
  • Nox
  • BlackBox tests
• Need
  • Packaged controller(s)
  • OFTest release
  • Open HAL for Indigo
  • System level tests/demos
  • Indigo open source release
  • Stanford based controller (?)
  • Tunnel support for dataplane and controller interfaces (?)

Actions

Set up wiki page for OpenFlow Porting Kit brainstorming