Re: [forces] Comment on draft-haleplidis-forces-openflow-lib-00

[Jamal Hadi Salim <[e-mail]>]

On Wed, May 30, 2012 at 6:32 PM, Haleplidis Evangelos <[e-mail]> wrote:
>
> [ΕΗ] We had a discussion with Joel. One of the main thing he is deeply
> concerned is that with multiple Flow Table LFB instances connected between
> them and all these instances connected with instances of action LFBs, the
> full mesh connections will create a very complex graph.
>
> However with your suggestion, we could have only one instance of the
> OFFlowTable LFB and inside have an array of an array of Flow Entries.
>
> This will simplify the graph a lot while still having the same flexibility.
>
> One other thing we discussed with Joel, was whether having an LFB class per
> action is worth it versus the complex graph it will create (as can be seen
> in figures 2, 3 and 4 in the draft).
>
> However if we have only one FlowTable LFB instance, the graph will be even
> less messy.
>
> What do you think?

I agree this is a cleaner looking model.
So the outer array index becomes the table id of the inner (Flow Entry) Table?

> [ΕΗ] Yes, in the OF specification, the ActionSet that travels along with a
> packet in the datapath is a limited array of actions. For this reason the
> ActionSetLFB exists. In the draft the ActionSet LFB is currently read-only
> and the CE can't configure it. So, the ActionSet LFB simply holds the
> metadata value (it is an array of an array of actions) and the actionset
> metadata that passes along is an index to that array.
>

My main contention is that given the approach in the current draft, the
CE will have zero interest in that Action Set table.
It is constantly fluctuating depending on what actions are set on a
specific run of a packet therefore i dont see even the value in it
being read-only.
All this to work around passing the metadata ....

> We also had a discussion with Joel regarding the Action Set LFB. Joel
> suggested we should specify which LFB makes the first allocation of the
> array when the packet enters the datapath and additionally we should
> explicitly specify, that the Action Set LFB is a modeling artifact and not
> an implementation description, the Action Set LFB may not correspond to
> anything in the implementation if the data storage can be handled in some
> other way.
>
> Joel, please correct me if I got something wrong.
>
> Now though, if we merge all Flow Tables in one big table in one LFB, will we
> need an ActionSet metadata? Shouldn't it be internally of the Flow Table
> LFB?

At some point you gotta get to the action executor at the end of that pipeline
so it can play the action script. I suggest that be an LFB as it is now instead
of merging it into the Flow Table LFB.

Would a largish octet string not suffice? It would have the action type/index
for all the actions. Maybe it is time we allowed complex structs as metadata?

cheers,
jamal