OpenFlow Meeting Notes 4-20-2010

From OpenFlow Wiki

Multiple Tables

Slides for discussion: http://openflowswitch.org/documents/OpenFlow_1_1_Multiple_Tables_04_20_2010.pdf

Meeting minutes taken by Nick McKeown.

Topic 1: Action Buckets

An action bucket is an abstraction to hold a set of (sequential) actions.
An action bucket can be shared by different flows: Multiple flows may map to the same bucket.

Discussions:

(Howard) Q: If the action bucket holds actions executed *after* a match, how does decapsulation work when a packet arrives?
(Jean) A: Decapsulation would be performed by a logical port, and therefore happens before the match.
(Glen) Comment: An action bucket may contain "send to logical port"; e.g. for sending into a tunnel.
(Howard) Comment: This needs to be carefully documented for clarity.

(Brandon) Q: What is the interaction between action buckets, logical ports and link up/down?
(Glen) A: We don't have any current plan for protection mechanisms inside OF -- it is assumed that, if needed, a separate agent would run on the switch to indicate that a physical or logical port is up/down.
(Brandon) Q: Should we standardize the interface to the "link up/down" status inside the switch?
(Room) There appeared to be consensus for doing so; and for creating a common interface/method for a local or remote agent to indicate link up/down.

(Brandon) Q: If a logical/physical port goes down, what happens to its action bucket?
(GLen) A: Referring to Slide 4: If a log/phy port went down, the protection group would fall back to the previous entry in the list of action buckets.

(Jan) Q: Are all actions in a bucket executed?
(Glen) A: As currently defined, you are required to execute all of them (as if sequentially). Actions are the standard actions. e.g. send to port, modify header. When protected by a backup, if you can't perform actions in the Action Bucket for the Primary, you perform none of them; but you would execute all of them for the Secondary.

(Michael) Q: What triggers the change from Primary to Secondary?
(Glen) A: We need a formal description of a single standard interface -- it's on the ToDo list.

Actions arising from meeting:

1. The relationship between action buckets, encapsulation and logical ports needs to be documented carefully.
2. We need a formal description of how processing is changed from Primary to Secondary.

Topic 2: Multiple Tables

Agenda for this discussion over the next few weeks:

1. Use Cases
2. High level problem space
3. Proposed high level architecture
4. Feedback
5. (Rinse, lather, repeat)

This week's discussion: Use Cases

1. "Typical" backbone router scenario: Lots of routes and a few QoS policies.

   Problem: Table needs to hold cartesian product of QOS and routes (i.e. a table entry for each <prefix, QOS-level> combination)

   How "Multiple Tables" can help: Two separate tables - in this example, one for L3, one for QOS-level - avoids explosion.

2. OpenFlow on existing hardware.

   Problem: Many switches/routers have relatively small TCAM tables; and they often restrict the fields that can be matched.

   How "Multiple Tables" can help: Switches/chips commonly have at least three tables for L2, L3 and ACL matching. The goal is to allow the controller to leverage these tables (e.g. for restricted matches on one field).

3. Deep packet inspection.

   Problem: If the match is fixed (i.e. the whole header is presented to the flow table) then it means having to design the table for the largest lookup; this can drastically reduce TCAM scalability.

   How "Multiple Tables" can help: Breaking into multiple small tables should lead to more efficient use of the tables.

4. Debugging/monitoring.

   Problem: Imagine, say, a backbone router, with a very larger number of flows (aggregated by prefix) and you want to monitor a subset of the flows (eg. count HTTP traffic). Have set of flow rules for forwarding with prefixes. Have a rule in second table that matches *all* HTTP traffic but does not have any actions associated with it.

5. L2/L3 flexibility after installation.

   Problem: There is much uncertainty in datacenters (for example) about whether to use L2 or L3. Should you deploy with your network optimized for one or the other? Can you change it later?

   How "Multiple Tables" can help: In principle, OpenFlow has a flat-view of the world -- you should be able to deploy now and optimize later. This would only likely be true if you have and can exploit L2 and L3 tables flexibly and separately. Having the choice to optimize for one up-front, but choose later to change; or to have a large amount of L2 and L3 co-existing, appears to give DC operators flexibility.

   Question as to whether this is applicable

6. (Michael had an example that was missed).

Discussion:

(James) Q: Current routers allow for multiple forwarding tables (one per virtual instance; for example, one per customer). Is this a use case with ramifications on multiple tables? (Room) Consensus appeared to be that this didn't warrant adding an extra use case.

The formal part of the meeting finished at this point.

Open-ended Discussion: Although the day's agenda was about use cases, the conversation turned (you might say it digressed or degenerated - depends on your point of view) to the general approach to implementation. This is probably because some people were (rightly or wrongly) guessing the mechanism that the Working Group will propose next time.

The conversation hinged - as it often does - on the tradeoff between "backward compatibility" and "laying out a new way" for chip/switch vendors to follow. As note-taker I tried to be unbiased in keeping minutes; apologies if I failed.

Some of the tradeoffs discussed:

• How concerned should we be with supporting every protocol in use today? While clearly there is consensus that we don't need to support everything, we have not agreed on a set we must support (and by implication a set we don't need to support). This could be a valuable (necessary?) exercise; else we risk taking a stand without really knowing the stand we are taking.

• How flexible and complex should OpenFlow mandate the switches become? There is consensus that there is a minimal set, with minimal complexity and flexibility that a switch can implement and still be called an OpenFlow switch. The question/debate is not likely to be about the minimal set; it's likely to be about how much flexibility the OF protocol can allow in a switch: Should there be a complex negotiation of what resources and programmability a switch has? If so, would this lead to too much fragmentation of different implementations? i.e. would we end up with networks that only work with Vendor X because the controller requires a feature only supported by Vendor X. On the other hand, we must allow some ability for vendors to differentiate themselves. The only conclusion here is that we have to walk this fine line mindfully: We need to support some existing protocols (but not all); we need to

More specifically:

(Nick): If there is a simple way to meet the use cases we listed, let's hear it. We can also hear something more flexible. But this would allow us to understand the tradeoffs.

(Michael): Flexibility helps to avoid surprises later.

Jan: Be careful not to introduce so much flexibility that you are tied to particular hardware -- makes controller's job a nightmare.

Nick: We want to create a dynamic where we have a very good base set of vendor-agnostic instructions. On the other hand, we need to give room for switch/chip vendors to differentiate.