OpenFlow Meeting Notes 3-2-2010

From OpenFlow Wiki

Slides from the presentation and discussion of proposed new features are available here: PDF of slides

Comments raised during Glen's presentation:

Tags and Tunnels

• [Howard Green]: MPLS two-tag cases
• [Rob Sherwood]: 1.0 has slicing as actions, not virtual ports; isn't this inconsistent
• [Jean Tourrilhes]: issue with virtual ports: can't stack actions; two ports would duplicate the packet
• [Bob/Jean]: cross-product port space explosion if need a single virtual port to represent multiple encaps/actions; does this suggest a larger port space?
• [Howard]: would be good to establish how phy port, encap, and queues relate
• [James Kempf]: we're OK with MPLS being tags, though implemented as virtual ports now
• [Jean] if do tunnel, no classifier mods; if tags, do need to mod classifier
• [Ed] we should do this in a general way: TLV, not specific protocols
• [Jean] controller should know total set of ports
• [Howard]: MPLS multicast requires a different label on each outgoing port
• [Ed] LISP we can't do
• [James] full port state could be useful for diagnostics
• [Jean] worry about controller connection bandwidth: minimize cruft, esp. flow setup

Multiple Tables:

• [Jean]: what about hardware that doesn't support information passing?
• [Dan]: cumulative vs override?
• [Howard/Guido]: resubmit confusion
• [Rajiv]: resubmit: rename continue
• [Guido]: how does the controller figure out how to navigate the switch?
• [Howard]: what happens when you replicate a packet?
• [Jean]: if you rewrite headers, are they visible in the next lookup?
• [Dan] doesn't this argue for vlans as virtual ports? multicast on a VLAN + to a tunnel: can't do this because of ordering
• [Guido]: if we expose categories of pipelines, would this be sufficient? Would vendors be comfortable?
• [Rob]: clarify that our goal is to present a superset
• [Dan]: key is how to expose what a switch can do
• [Jean]: more concrete proposals among hardware vendors, possibly with explicit list of table capabilities
• [Dan]: do switches have scratchpads, and is this exposed with the above proposal so that it's usable by a controller writer?

Main debated questions:

• Do we support non-existent hardware
• What is the exposure format
• Can a controller writer get a working controller for a switch that doesn't exist yet?
  • Should work somehow: what's the fallback that can make use of the tables
• [Rajesh from Orange]: what are the actions my system as a whole can do? (series of atomic operations, as opposed to pipeline stages) Are we adding complexity to the implementation by supporting this general model?

• How does this all interact with action ordering?