OpenFlow Meeting Notes 5-18-2010

From OpenFlow Wiki

Mutliple Table Discussion

The agenda was to recap the multiple tables proposal from last week and move forward. But (given feedback from vendors) we ended up revisiting previous assumptions and proposed architecture.

There is also a related ongoing thread in the mailing list.

• Slide 1
  • [Glen] : Simplify multiple tables proposal. Let programmers exploit hardware, but avoid solving canonicalization problem.
• Slide 2
  • [Glen] : High Level View
  • [D. Ward] : You assume that tables are not strict - they are just represented by an ID. Clarifications by accumulation of actions VS look-ups. Do counts happen at the end of the lookup or at the end of the pipeline?
  • [Glen] : Count happens at each flow table.
  • [Martin] : By default they apply at the end, unless they are explicitly forced to do there. Assumption says that the pipeline is ordered.
  • [D. Ward] : Writing controllers is even more difficult, you need to know the hardware internals
  • [Dan] : We shouldn't care about the actual hardware, but about how the switch exposes its pipeline. This could be an abstraction of the hardware.
  • [Martin] : This information will be passed by an out-of-band communication, the id itself is not self-explainable.
  • [?]: That makes it vendor specific though.
  • [Martin]: Yes, that's why it sucks. We expect that in a few months we'll have a better understanding on what we have to do. At the moment think of it as (the controller writer) having a datasheed which gives info for each switch.
  • [Joe Tardo] : You are trying to invent the Turing machine for switches. You try to define a switch description language. Why do you still involve the datasheet and don't put this in the API?
  • [Martin]: The switch description language is being done, on a system's design way. We still don't know what the right abstraction is. We shouldn't go into it now.
  • [Joe T.] : This will be error prone etc.
  • [Martin] : I want the documentation. If i have this, i can program the system the way I want.
  • [Guido] : If I want to take all the performance a switch can give, I'll need a driver in my controller which knows in depth the specifics of that switch. Maybe the vendors be providing these drivers.
  • [Martin] : ok - agree. Datasheet is a wrong term. We need a piece of paper that specifies what goes where. The vendor needs to expose somehow the hardware, and then a driver level sw at the controller will map simpler semantics to the network.
  • [Guido] : This mechanism goes away from OpenFlow philosophy of vendor ignorance. Maybe we could name this as something else than OpenFlow (Canonicalization OpenFlow 1.1 or sg like this). OpenFlow should remain vendor independent.
  • [Martin] : We need this to allow people continue building their controllers and gain knowledge of how we should make the canonicalization
  • [James Kempf] : Mentioned something about a switch description language that was not adopted - didn't get the details.
  • [Martin] : We already have HALs which are useful and could act as a guide on how to go there, but it's still early
  • [Jan Medved] : This reminds of NetConf, where evrerybody did it's own stuff - we should be careful.
  • [Guido] : Is there a critical mass to have vendor independent functionality? There is a danger that we will end up with a vendor-specific protocol.
  • [D. Ward] : A way to avoid errors in such a situation, you can provide some hints in the controller-switch information exchange.
  • [Jean Toureillhes] : There is already a string for that.
  • [D. Ward] : A string is one option, but we could have something more defining what datapath you talk to. We need a global namespace that identifies the datapath. 42 might mean different things to different people.
  • [Jean T] : You have the name of the datapath (string) + the version of the datapath for identification.
  • [Joe T.] : How do you merge actions/list of actions?
  • [Martin] : The semantics are that I have a set of in-order actions and I operate on that order. We just add the option to explicitly do some actions at a specific table instead of the end of the pipeline.

• Slide 3
  • [Glen] : Maskable metadata, table-id.
  • [David E] : Are the metadata available at a single table as well, or only to the multiple-tables?
  • [Martin] : It doesn't make any sense to have any metadata on a single-table switch.
  • [Bob L] : What are the semantics? Who has access to the metadata? The next table?
  • [Jean T] : With multiple tables you will have more wildcards. Metadata might not be known, so you'll use wildcards and exact match will not be so useful.
  • [Martin] : I'd like to have a better idea. The programmer would like to use it on an exact match fashion.
  • [Jean] : With multiple tables exact match is gone.
  • [James Kempf] : The routers put an extension header in front of the packet and then they send it to the switch fabric.
  • [Martin] : Our semantics are that we want to put to the registers what we see on the wire. Internal tags could be used internally but we don't want them in the protocol.
  • [Joe T.] : How can we edit actions?
  • [Martin] : Currently we don't expose any functionality to edit actions. Once you appended them it's done. Would be interested controller writer's take on this.
  • [Martin] : What about goto/resubmit?
  • [D. Ward] : In order to go to a table, do I have to take the metadata to go there?
  • [Martin] : Yes
  • [D. Ward] This is inefficient
  • [Martin] The metadata is for the controller programmer to keep some state and make a look-up based on these.
  • [Guido] David says that action is also information that is carried around.
  • [D. Ward] Key-metadata is the input, action is the output, that's why you need two different things. I want to carry the action information to my next table. Let's say I want to do it to the end of my pipeline, I need to carry this action.
  • [Martin] It's different. One comments on how I am saying this to you, and the other how you do it.
  • [Tom Edsall] The hardware will constrain what the key is.
  • [Martin] There are two usecases. Something which is meaningful to me, and something that I have to communicate to the switch. Metadata is the first, actions is the second.
  • [D. Ward] You have an input key, and you have a result that came after going to the table. Do you need to carry them both or only the first one? I think we need to carry them both.
  • [Martin] I am fine with this. I thought you wanted to move actions to a blob of bits.
  • [D. Ward] For example, I could have the same metadata, and then I can keep accumulating the actions.
  • [Martin] That's more expressability from the switches which is definitely fine with me. I was under the assumption that this was not supported by the vendors.
  • [Jean T.] How do you edit actions? Do you assume a list and then say change the "second'" action? In some cases, you only care about the last action, so the previous would be needless.
  • [Martin] Do all the vendors agree that we can expose the action list? This is very important for the controllers.
  • [Dan, David E] exposing actions is not clear. Is this by type, by sequence, ...? In general the spec is vague about whether the action is an ordered list etc.

(There was a discussion about consistency between tables, started from the ordered list, and then went to crashes etc.)

• Action Items
  • [Martin] : Should we remain with the existing functionality of defining the action list, or should we include add/remove semantics for actions within that? Expecting short spec-proposals from Dave W./Joe T.?