OpenFlow Meeting Notes 3-30-2010

From OpenFlow Wiki

The Dell perspective

Representatives from Dell were in attendance. They gave a brief talk outlining their perspectives/interests in OpenFlow. Some points from the talk included:

• convergence -- storage, servers, etc
• difficulty is in building managed networks
• alignment between OpenFlow and their problem set
• "last useful thing added to Ethernet was STP, then it got worse"
• want things easier in the data center
• complexity of traffic: multiple cores and hundreds of PCI-express lanes in a server...

Multipath update

An updated proposal will be posted to the wiki, and a notice will be sent to the mailing list

Tagging/Tunneling

Definitions:

Tagging

adding a set of bits to a packet

mark with data, that info stays with a packet, between switches

Tunneling

service model of a wire

put in, come out, unchanged

wire could use tags, be stateless, stateful.

tag is do a lookup and attach gobbledigook

• [Ed Crabbe] tags change quickly and are stateless

tunnels change at the speed of the configuration protocol?

• [Jean Tourrilhes] What about VLANs?

Packets go out of tunnels. Packets don't go out of tags.

• [Christos Kolias] Tunnels have an end-to-end meaning, while tags a local one (e.g., processed at every switching node)
• [???] tag as mechanism for a tunnel?
• [Martin Casado] working def: from receiver standpoint, metadata or no metadata

• [Martin] Nicira's usage:

hardware-accelerated overlay

have an L3 physical world w/IGP

use tunnels to create a logical world

care about which tunnel to use but not the underlying path

set up stateful tunnels

lookup 1: to ID tunnel

lookup 2: send packet out tunnel (give to OSPF)

need to be able to demux from tunnels:

• tags added on way in to tunnels
• tags used for lookups on way out of tunnels

high-level req't: tunnel with hw accel, tags are stateless

• [Howard Green] Can we have multiple levels of tunnels?
• [Guido Appenzeller] Requested clarification of differences between tags/tunnels
• [Martin]: tags: add and they are there at the next switch

tunnels: push in pkt, pops out at other end, no extra data in packet at far end

• [Martin]: (returning to example): Salient point: don't want to worry about how packet physically gets somewhere (and associated lookups), just want a "port"

can have situations in which we may care about the lookups

• [Jean]: Currently easy to add a vendor extension to stuff extra data into a packet

Impossible to match on vendor extension data

• [Ed]: Timescales -- fast vs slow

slow -- doesn't belong in OpenFlow

fast, simple -- belongs in OpenFlow

• [???] lookups at terminating interface
• [???] how many layers of lookup?
• [Martin]: do we have a tag that isn't part of the packet?

Multiple tables: only tags on packets

need a logical abstraction!

requirement for L3 to handle

[Jean] use case: IP in IP from Mobile IP

• [Rajiv] Basic encaps:
  • IP-in-IP
  • MAC-in-MAC
  • Q-in-Q
  • Q
  • MPLS
• Additional encaps:
  • MPLS multicast
  • GRE: MAC-in-IP
• [Howard] want something that looks like a port
• [Nick McKeown] need a method to express encaps even if not all switches support the encap.
• [Ed]: Need a mechanism, still working on that
• [Howard]: MPLS multicast -- different label per port
• [Jean]: use multiple levels and lookup one at a time
• [Guido]: complication of multiple tables and encaps working together
• [Jean]: no switch will have a TCAM wide enough to do all lookups in a single table
• [Howard] implicit or explicit knowledge of protocol (TTL ex) - in favor of that.

prefer switch to expose capabilities

• [Ed] Another challenge: action set at a given level of encapsulation
• [Jean] use case: MAC in UDP
• [Howard] queue mapping for a tunnel, for implementing a scheduling policy
• [Michael Orr]: how do I create/destroy a tunnel? Configuration at both end points. Controller must tell the switch of the tunnel.
• [Ed]: general consensus on use cases. need to identify the mechanism
• [Brandon]: how many levels of nesting?
• [Ed]: define in a way that arbitrary number of levels can be supported. Switch may support limited.

Most will provide between 1 and 3.

• [Michael]: Q-in-Q: QoS marking based on inner packet: both layers are used!
• [Rajiv]: Do we need support everywhere or just at end points?
• [Michael]: Might need access to inner tags for QoS (identify/reclassify)
• [Guido]: how many levels can be considered at a single table?

what combo of tags to consider simultaneously

• [Jean] tunnels one-at-a-time, tags, multiple at a time?
• [Howard] performance monitoring of tunnels:

802.1ag and MPLS per management

monitor tunnels by sending messages at high frequency to detect issues

• [Nick]: chip/switch vendor may design h/w to serve a given market

choice to expose features via OpenFlow or not

• [Howard] fast protection/restoration case deserves to be resolved

key feature of tunnels is what happens when a tunnel fails

• [Jean] emergency port cache (intended jokingly)
• [Howard] ability to take a logical port up and down

some protocols need h/w support

problem of something implicit in switch affected port status

• [Ed]: protocol can't support all mechanisms
• [Nick]: We're not designing silicon. Define the basic primitives that must be there to support necessary uses
• [Howard]: currently can't describe syntax for all mechanisms

would like fast protection to be resolved for 1.1

• [Ed] someone proposed link between active/passive links, other similar things

need some coupling between OpenFlow and config

• [Nick]: better to add features that won't be changed between revisions
• [James Kempf]: might be multiple ways to support fast protection. Worth investigating further.
• [Nick]: Can you identify a small set of primitives that are useful to different mechanisms for failure?
• [Howard]: desires ability to bring tunnels up/down
• [Jean]: problem of port space size... currently only 16-bits
• [Ed]: propose move to 32-bits

Add flow cookies note!!