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

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 27 May 2012 14:10:19 -0400

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?

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"

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)

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?

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 31 May 2012 01:32:30 +0300

Greetings Jamal,

Thank you for the comments.

Please see inline.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Sunday, May 27, 2012 9:10 PM
> To: Haleplidis Evangelos
> Cc: [email-masked]; draft-haleplidis-forces-openflow-
> [email-masked]
> Subject: Comment on draft-haleplidis-forces-openflow-lib-00
> 
> Greetings Evangelos,
> 
> 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:
> 

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

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

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 30 May 2012 19:15:50 -0400

> However if we have only one FlowTable LFB instance, the graph will be even

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

> 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 ....

> need an ActionSet metadata? Shouldn't it be internally of the Flow Table

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

---

From: Joel <[email-masked]>
Date: Wed, 30 May 2012 19:37:07 -0400

Inb particular, if the metadata is produced by one LFB and consumed by 
one lFB, then an octet-string would seem sufficient for it.  This avoids 
the problem of how things are pushed/popped/cleared during the table 
processing, as that is internal to the LFB.

There is the question of how execute-immediate interacts with deferred 
execution and whether we are having two LFBs which have to implement the 
same capabilities.

Yours,
Joel

On 5/30/2012 7:15 PM, Jamal Hadi Salim wrote:
> On Wed, May 30, 2012 at 6:32 PM, Haleplidis Evangelos<[email-masked]>  wrote:
>>
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 30 May 2012 21:15:19 -0400

On Wed, May 30, 2012 at 7:37 PM, Joel <[email-masked]> wrote:
> Inb particular, if the metadata is produced by one LFB and consumed by one
> lFB, then an octet-string would seem sufficient for it.  This avoids the
> problem of how things are pushed/popped/cleared during the table processing,
> as that is internal to the LFB.

I believe it can only be consumed at the last stage of a pipeline, with possibly
many sets or clears of the different fields in the intermidiate stages
(i.e more than
one LFB instance).

> execution and whether we are having two LFBs which have to implement the

Section 4.8 of OF 1.1, last sentence (action list being the
"execute-immediate"):
"The action set of the packet is unchanged by the execution of the action list."

Also it does not seem that the execute-immediate can terminate the pipeline.

cheers,
jamal