OpenFlow Meeting Notes 3-9-2010

From OpenFlow Wiki

Ed Crabbe presented notes about capability advertisement (PowerPoint slides)

• Use case 1: tags:
  • Q: Doesn't features reply already do this?
  • A: No - doesn't allow extensibility to new tags. We
  • [Jean Tourrilhes]: desire to expose individual capabilities or new actions
  • [Howard Green]: in Ericsson's experience with MPLS, easier if the switch knows more about the packet formats
  • [James Kempf]: something like this is needed for a wide range of functionality
  • Q: does this belong in the config protocol
  • [Jean]: schema vs mechanism: schema is the hard part
  • [Guido]: now, it's easy to write a controller to cope with any reported features. In the other extreme, you may need to customize a controller to specific features.
  • [Atsushi Iwata]: Possibly want a general/uniform method for exposing tunnels
  • [Rajiv Ramanathan]: solution is virtual ports -- most general approach
  • [Howard]: problem of virtual ports is timescale
  • [Jean]: switches can create virtual ports but need to know protocol information (eg. VLAN tag, IPSec config etc)
  • [Guido]: Will there be a standard set of tags

• Use case 2: multiple tables
  • [Jean]: Need to expose match fields
  • [Guido]: Two extremes:
    • simple present/absent for coarse-grained set of features
    • very fine grained set of features
  • [Howard]: Conflicting desires:
    • Want controllers that work across wide variety of switches
    • Don't want to prevent innovation
  • [Uncertain who asked this question]: What are downstream neighbors? Does this allow passing information between tables in different switches?
  • Downstream neighbors should be translated as downstream tables in single switch

• General comments:
  • [Michael Orr]: appreciates idea of extensible capability set. Has been involved in projects where this has been problematic, especially with hidden assumptions.

Brandon Heller presented ideas on the design space when thinking about the table model (PDF of slides)

• [Howard Green]: proposal hasn't covered non-tables that may be in the pipeline, eg. queues
• [Jean Tourrilhes]: can handle other elements (at least queues) via actions
• [Rajiv Ramanathan/Howard]: competing desires -- exposing much about capabilities vs keeping interface to controller simple
• [Guido]: OpenFlow 1.0 tries to provide a lowest common denominator of features.
• [Guido]: Does it make sense to provide a limited set of pipeline options -- would simplify controller writer's job
• [Rajiv]: Makes it easier for controller writers, but shifts complexity to the HAL. Can argue that complexity should be in controller due to better compute resources.
• [Michael Orr]: Appreciates idea of limited set of tables (eg. L2, L3, ...) since it eliminates need to expose inner switch complexity.
• [Michael]: Perhaps ideal is between two extremes of where we've considered so far.
• [Jean]: Desire to consider use cases. Concern that we can't do what we want with current switches.
• [Guido]: Challenge: how to effectively use a switch given very detailed capability information?
• [Rajiv]: Good to have a simple base level of features, but want ability to take advantage of all features offered by chip
• [Michael]: Problem: exposing a simple interface and having the HAL perform optimizations upon flow insertion -- difficult to verify all combinations of flow-table entries.
• [Guido]: Union of feature sets of merchant silicon would be almost impossible to program to
• [Howard]: Desire to be able to use all features at your disposal
• [Dave Erickson]: Work with existing silicon today; tomorrow may bring dedicated OpenFlow silicon.