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

["Haleplidis Evangelos" <[e-mail]>]

Greetings Jamal,

Thank you for the comments.

Please see inline.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[e-mail]]
> Sent: Sunday, May 27, 2012 9:10 PM
> To: Haleplidis Evangelos
> Cc: [e-mail]; draft-haleplidis-forces-openflow-
> [e-mail]
> Subject: Comment on draft-haleplidis-forces-openflow-lib-00
> 
> Greetings Evangelos,
> 
> Attached the annotated draft with more specific comments.
> We'll try and make time tomorrow or the day after to implement the LFBs
> (purely ForCES) and vet the control-datapath messaging works. I can
> send more lower level comments then on the XML etc.
> 
> High level comments:
> 
> 0) Do you need the "LFB" suffix on every LFB?
> 

[ΕΗ] No, we can remove them.

> 1) One of the things that is confusing is the differences between
> defered set of actions and what gets applied at per flow table. Could
> you maybe add some text which clarifies right at the beginning,
> example:
> 
> "There are two types of action executions which are independent of each
> other. The first one refered to as "action list" is programmed into the
> flow table to be executed immediately within the packet pipeline upon a
> match on a flow table. The second one gets executed at the end of the
> pipeline in the "execute action set". The second type of actions is
> collected in a the metadata refered to as "Action Set" during the
> datapath processing"
> 

[ΕΗ] Thank you for this. Yes, we will add a clarification text.

> 2) Metadata can only be atomic type in ForCES. Seems theres expectation
> to do more in this model (eg the ActionSet).
> 
> 3) Is there need to model multiple tables in the OFFlowTable LFB?
> An LFB with a single table will also work with OF 1.0; for > 1.0, we
> have instances of those LFBs connected in a graph.
> (Where the instance ID is the FlowTable ID)
> 

[ΕΗ] 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?

> 4) I may be confused but it seems there is something missing in regards
> to the concept of ActionSet (both the LFB and its use in OFFlowTable
> LFB). If i understood correctly the text, the ActionSet is a runtime
> metadata that is populated at different stages of the packet processing
> in the datapath.
> If thats true, you cant have the CE populate the Action Set anywhere.
> For a single flow, each arriving packet may require a different action
> set depending on state (eg configured bandwidth being exceeded vs not).
> This means the ActionSET LFB is empty and its only role is to execute
> the action it receives in the ActionSet Metadata.
> What did i miss?

[ΕΗ] 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.

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?

> 
> cheers,
> jamal