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

From: Zoltán Lajos Kis <[email-masked]>
Date: Thu, 7 Jun 2012 15:51:06 +0200

Hi,

I went through the whole draft - not too thoroughly on the XML part -  and would like to clarify / comment on a few things.
I'm still working on understanding the complete data model of the described architecture, so don't take this as an
exthaustive list of issues. (Btw, is there a tool available for ForCES, which can convert the XML description to a more digestive
form? ER-diagrams, or similar....)

Regards,
Zoltan.

Generic comments:

1) I think the Action Set description - section 4.7 in OpenFlowSpec1.1 - is misinterpreted. In OpenFlow
there is only one set of actions defined (25 + experimenter). Those actions are used in ApplyAction,
WriteAction instructions and PacketOut messages. The 9-element listing in the section merely defined
To discuss the ordering in which actions in the ActionSet must be executed (regardless of in what order
they have been written to it). These 9 elements represents different "classes" of actions. For example,
"Setting a field" refers to all the action types for manipulating header fields in the frame.
Actions of the same class are not concurrent, i.e., they can be executed in arbitrary order, without
affecting the overall result of executing the ActionSet. Actions of different classes however can have
effect on each other, so their execution order must be specified.

2) QoS handling is misinterpreted. In the OpenFlow 1.1 model QoS queues are attached to (the output side of)
ports. The identifiers of these queues are port-specific; i.e. both Port 1 and Port 2 can have a queue with an ID of 2.
If the controller is to send a frame to the default (or no-)queue, it simply uses the output action. If it
wants to target a specific queue of the port, it first has to set the port-local queue ID (with set_queue action),
and then use the output action. The output action will forward the frame to the appropriate port, and the port will
use the queue previously appointed by the set_queue call.
(Note that beginning with OpenFlow 1.3 a new Meter entity is introduced, which can be used for QoS between
tables, and before outputting to ports.)

3) Besides the pieces of OpenFlow metadata identified, there are additional metadata that needs to be attached
to the frame - due to implicit requirements in OpenFlow, and due to the architecture of the ForCES description.
queue_id: as described above in 2), the id of the queue which is to be used on output is set by the set_queue
action. Therefore the set queue_id must be passed along with the frame as metadata for the output action
to process it.
of_phy_port: The OpenFlow specification allows logical ports over physical ports. In this case a packet_in
message is supposed to tell the controller both the logical and the physical port of the packet. Thus the
physical port id must also be sent along with the packet (given a logical port was used).

4) The description of how outputting a frame is handled is not clear. It would seem logical that it is
done by the OFOutputActionLFB only, i.e. only that LFB's output is connected to the ports' input - but not those
Of OFFlowTableLFBs.
Furthermore a special ToControllerLFB should be added, which would send the frame to the controller.
This LFB could be used by both the FlowTableLFBs and the OutputActionLFB.  Also, this LFB could address
the buffering of packets sent to the controller.

5) OpenFlow allows the controller to construct and send frames to the datapath for processing in the
OFPT_PACKET_OUT message type. I believe this functionality is missing from the current description.

6) OpenFlow 1.1 added extensibility features to the datapath. One can define custom experimenter messages,
matches, instructions, actions. While not necessarily the duty of this text, it would be nice to see how
that can be incorporated into the ForCES description. I.e., how an experimenter action is mapped into
an (experimenter) ForCES LFB, etc.

Comments on the text:

Page 5:
- at the end: it should at least mention group entries, "the controller can add, update and delete flow and group entries"

Page 7:
- Even though it is fairly trivial to tell them apart, I think it would make sense to add a separator between
ForCES and OpenFlow definitions. Also, I think further OpenFlow concept should be explained, and the order of elements
should be changed.
Suggested list of elements: Match fields, Actions, Flow Entry, Instruction, Flow Table, Pipeline, Action Set,
Groups (incl. GroupEntry and GroupTable), Ports.
(I'm willing to provide definition for these terms.)

Page 9:
- Fig. 1., and the text below suggests that one piece of metadata (the Action Set) is available in the packet before
entering Flow Table 0, while another piece (the Metadata field) is only available after leaving the table.
I believe a more convenient description would be if the Metadata is already available when entering Flow Table 0,
with a default value of all zero.
1) A table not necessarily touches Metadata, so in the current method FlowTable 0 would have the special function
of "create if not exists" the Metadata. 2) The OpenFlowSpec1.1 in theory allows modifying Metadata with bitmasks used
- let alone matching on it.

- "Write Metadata action" should be "Write Metadata instruction"

- "Forward to the OpenFlow controllers" should be changed to singular "controller". OF 1.1 does not define multi-controller
support. It is only added in OF 1.2

- "The list of actions a Flow Table may perform..." should be "The list of instructions..."

Page 10:

- "Write a List of actions to the action set" would be more correct as "set of actions", and should refer to the method
of writing the action set (which should probably be described among the concepts of Page 7.

- "The list of actions the Flow Table can perform  or write in the Action Set is". Similar to generic comment 1), this
is not a list of possible actions, but rather the list of the different action "classes".

- "Additionally a Flow Table may drop the packet as an action. The drop action is implicit based on the Flow Table's
configuration.". This sentence is confusing. The configuration is only consulted in case of no match. As this listing
is for the list of actions in write actions, there is no drop action. On match a flow entry can drop a flow by
clearing the action set, and not specifying a goto.

- "An Action Set contains a maximum of one action of the following types...". Should be "...one action of each type...".
(See generic comment 1)

- "1. Copy TTL Outwards" should be "1. Copy TTL Inwards"

Page 11:

- "The Group Table contains a set of actions": the Group Table contains a set of Group Entries, each of which contains
  a set of "Action Buckets", each of which contains a set of actions.

Page 11-13 (Fig 2-4.):

- At this point the basic architectural decisions (i.e. ActionLFBs maintaining the action parameters) are not described,
so the use of ActionIndex is quite confusing at this point.

- Also it is not clear (and remains unclear to me), that after the FlowTableLFB sent the packet for processing to an
ActionLFB, when the packet returns from processing, how will the FlowTableLFB know the processing state of the packet?
Particularly, how does it know which was the matching flow entry, and which action in the action list is being executed?

Page 15:

- "Additionally each OFFlowTable can output a packet to a specific port." As in generic comment 4), this should not
be the case. Tables can only output to the controller (without OutputAction involvment).

- On Fig 5. a number of arrows are missing from the lines pointing to OFPorts.

Page 16:

- The "OpenFlow Atomic Types" table: it should be made clear that there are more atomic types used in the OpenFlow
description, but those types (e.g., IEEEMAC) are defined elsewhere - I guess in the LFB Library.

- ActionSetType: see the generic comment on action sets

Page 20:

- "... the maximum number of bytes of new flow that datapath should send ...". "new flow" is not a correct a term here.
"unmatched / invalid frame" should be better. The controller does not neccesarily ant to convert it to a flow.

Page 22:

- first paragraph: same comment as for Page 9 / Fig 1. regarding Action Set vs. Metadata field

- sencond paragraph: as Dave Meyer commented already, the text should elaborat on how matching is done. I would suggest
that it is described among the description of concepts, and this paragraph refers to that.

Page 24:

- It it intentional that "buffer" is made a component of the FlowTable, and not a separate LFB? In OpenFlow a packet
is buffered when sent to the controller, regardless of which table it came on. With packet out, the controller can
instruct the switch to execute "on the fly defined" actions on the packet and/or send it through the pipeline starting
at Table 0. There is no need for keeping track of which packet was buffered in which table.

Page 25:

- OFPortLFB / Data Handling: The OpenFlow spec. allows a port to be a "logical port" defined over the physical ports.
So the OFPort is not necessarily directly connected to the phyisical medium ports.

Page 26:

- OFQueueLFB: see generic comment 2) on how QoS is defined.

- "The Length component" : I think this is a misunderstanding. The queue does not have a length. The only length we
have in the Queue context is the length of the queue properties, which is a wire protocol feature (for the TLV structure),
and so should not be reflected in the data model.

Page 27:

- "length of the property" : see above comment.

- "maximum 9 actions": see general comment 1"

- "maximum size 9 rows": see general comment 1"

Page 28:

- "As none of the OFActionLFBs have no capabilities..." - there no is not needed

Page 29:

- "Only valid in the action set of a packet-out message" should be "action list of a packet-out message".

Page 33:

- 5.8.18.2: the Push VLAN action's argument is an Ethertype, not a VLAN header value.

Page 35:

- 5.8.25.2: "SetIPTTLTable" is probably wrong, something like "

Page 36:

- "C:\Workspace\Forces...\" - I guess this should be something else

Page 37:

- MPLSLabelValue: 1048576 should be 1048575

- IPv4ToSBits: 64 should be 63

- "Ethermet frame typ Wildcard" - e missing

Page 38:

- IngressPort: certain values are invalid for the match type (those > OFPP_MAX)

Page 39:

- ArpOpcode: As of OpenFlow 1.1, this field is "overloaded" into the IP protocol field. Is it intentional
that it is separately defined?

Page 48:

- "Buffer Reason" should be "Packet-in reason"

Page 50:

- "multiple ows" -> "multiple flows"

- "speciffic" -> "specific"

Page 52:

- "VLNA" -> "VLAN"

Page 53:

- "administatevely" - "administratively"

Page 57:

- "trasmittion" - "transmission"

Page 58:

- "Length of property" : same as for Page 26. This is a wire protocol TLV feature, should be not part of the data model.

- ActionsetLFB dataTypeDef: see generic comment 1

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Sat, 9 Jun 2012 01:18:11 +0300

Greetings Zoltan,

Thank you very much for the extensive comments. I responded to your generic
comments. 

I will answer you text comments in an separate email.

Please see inline.

Regards,

Evangelos Haleplidis.

From: Zoltán Lajos Kis [mailto:[email-masked]] 
Sent: Thursday, June 07, 2012 4:51 PM
To: Haleplidis Evangelos
Cc: [email-masked]
Subject: More comments on draft-haleplidis-forces-openflow-lib-00

Hi,

I went through the whole draft - not too thoroughly on the XML part -  and
would like to clarify / comment on a few things.

I'm still working on understanding the complete data model of the described
architecture, so don't take this as an

exthaustive list of issues. (Btw, is there a tool available for ForCES,
which can convert the XML description to a more digestive

Regards,

Zoltan.

Generic comments:

1) I think the Action Set description - section 4.7 in OpenFlowSpec1.1 - is
misinterpreted. In OpenFlow

there is only one set of actions defined (25 + experimenter). Those actions
are used in ApplyAction,

WriteAction instructions and PacketOut messages. The 9-element listing in
the section merely defined

To discuss the ordering in which actions in the ActionSet must be executed
(regardless of in what order

they have been written to it). These 9 elements represents different
"classes" of actions. For example,

"Setting a field" refers to all the action types for manipulating header
fields in the frame.

Actions of the same class are not concurrent, i.e., they can be executed in
arbitrary order, without

affecting the overall result of executing the ActionSet. Actions of
different classes however can have

[ΕΗ] If I understand you correctly, an ActionSet may contain multiple set
field actions (e.g. set IP address, set MAC address), but only one of a kind
(only one set IP address). Correct? And the same applies to push/pop tag
action. If yes, then we will modify the text accordingly.

2) QoS handling is misinterpreted. In the OpenFlow 1.1 model QoS queues are
attached to (the output side of)

ports. The identifiers of these queues are port-specific; i.e. both Port 1
and Port 2 can have a queue with an ID of 2.

If the controller is to send a frame to the default (or no-)queue, it simply
uses the output action. If it

wants to target a specific queue of the port, it first has to set the
port-local queue ID (with set_queue action),

and then use the output action. The output action will forward the frame to
the appropriate port, and the port will

(Note that beginning with OpenFlow 1.3 a new Meter entity is introduced,
which can be used for QoS between

[ΕΗ] Regarding queues, we may need to add an additional figure to depict
queues. I don’t think that the current definition of the queue LFB is
different from what you describe. You may have multiple instances of
QueueLFBs, each with its own queue ID (which may not be unique. Only the
Queue LFB’s Instance ID is unique). 

3) Besides the pieces of OpenFlow metadata identified, there are additional
metadata that needs to be attached

to the frame - due to implicit requirements in OpenFlow, and due to the
architecture of the ForCES description.

queue_id: as described above in 2), the id of the queue which is to be used
on output is set by the set_queue

action. Therefore the set queue_id must be passed along with the frame as
metadata for the output action

to process it.

of_phy_port: The OpenFlow specification allows logical ports over physical
ports. In this case a packet_in

message is supposed to tell the controller both the logical and the physical
port of the packet. Thus the

physical port id must also be sent along with the packet (given a logical
port was used).

[ΕΗ] Continuing from above, we do need to add the queue_ID metadata as you
describe in your comment.

Regarding the of_phy_port, the OF 1.1 spec is a bit confusing:

1.       What is the meaning of ingress port if you have the of_phy_port &
of_in_port metadata? Is ingress port the of_in_port? 

2.       Where is the of_phy_port generated, and how is it transmitted (it
is not shown in Figure 2 in the OF 1.1 spec).

3.       The of_phy_port is only useful in the case of the frame sent to the
controller?

4.       Are there any other components of the datapath described (only) in
the protocol instead of the datapath definition. Example table 4 is datapath
spec but appendix A is protocol spec.

4) The description of how outputting a frame is handled is not clear. It
would seem logical that it is

done by the OFOutputActionLFB only, i.e. only that LFB's output is connected
to the ports' input - but not those

Of OFFlowTableLFBs.

Furthermore a special ToControllerLFB should be added, which would send the
frame to the controller.

This LFB could be used by both the FlowTableLFBs and the OutputActionLFB.
Also, this LFB could address

[ΕΗ] There is currently no OFOutputActionLFB defined, but there will be in
the next draft update. The current model description has the OFFlowTable to
output the frame to the port or queue, but upon discussion it’s better to
have an additional Action LFB.

As for the ToControllerLFB and FromControllerLFB, these two LFBs have been
defined in the LFB-library document as the RedirectIn and RedirectOut LFBs.
A new figure should be added to depict them as well. If there is a need for
more components than defined in these two LFBs we can extend them.

5) OpenFlow allows the controller to construct and send frames to the
datapath for processing in the

OFPT_PACKET_OUT message type. I believe this functionality is missing from
the current description.

[ΕΗ] The above comment (and figure) should cover this as well.

6) OpenFlow 1.1 added extensibility features to the datapath. One can define
custom experimenter messages,

matches, instructions, actions. While not necessarily the duty of this text,
it would be nice to see how

that can be incorporated into the ForCES description. I.e., how an
experimenter action is mapped into

[ΕΗ] An experimenter action can be defined as a new OFActionLFB. As for
matches, the datatype definition for the match will need to be updated.
However this is a good idea and we should add such section

Comments on the text:

Page 5:

- at the end: it should at least mention group entries, "the controller can
add, update and delete flow and group entries"

Page 7:

- Even though it is fairly trivial to tell them apart, I think it would make
sense to add a separator between

ForCES and OpenFlow definitions. Also, I think further OpenFlow concept
should be explained, and the order of elements

should be changed.

Suggested list of elements: Match fields, Actions, Flow Entry, Instruction,
Flow Table, Pipeline, Action Set,

Page 9:

- Fig. 1., and the text below suggests that one piece of metadata (the
Action Set) is available in the packet before

entering Flow Table 0, while another piece (the Metadata field) is only
available after leaving the table.

I believe a more convenient description would be if the Metadata is already
available when entering Flow Table 0,

1) A table not necessarily touches Metadata, so in the current method
FlowTable 0 would have the special function

of "create if not exists" the Metadata. 2) The OpenFlowSpec1.1 in theory
allows modifying Metadata with bitmasks used

- "Forward to the OpenFlow controllers" should be changed to singular
"controller". OF 1.1 does not define multi-controller

- "The list of actions a Flow Table may perform..." should be "The list of
instructions..."

Page 10:

- "Write a List of actions to the action set" would be more correct as "set
of actions", and should refer to the method

of writing the action set (which should probably be described among the
concepts of Page 7.

- "The list of actions the Flow Table can perform  or write in the Action
Set is". Similar to generic comment 1), this

is not a list of possible actions, but rather the list of the different
action "classes".

- "Additionally a Flow Table may drop the packet as an action. The drop
action is implicit based on the Flow Table's

configuration.". This sentence is confusing. The configuration is only
consulted in case of no match. As this listing

is for the list of actions in write actions, there is no drop action. On
match a flow entry can drop a flow by

- "An Action Set contains a maximum of one action of the following
types...". Should be "...one action of each type...".

(See generic comment 1)

Page 11:

- "The Group Table contains a set of actions": the Group Table contains a
set of Group Entries, each of which contains

Page 11-13 (Fig 2-4.):

- At this point the basic architectural decisions (i.e. ActionLFBs
maintaining the action parameters) are not described,

- Also it is not clear (and remains unclear to me), that after the
FlowTableLFB sent the packet for processing to an

ActionLFB, when the packet returns from processing, how will the
FlowTableLFB know the processing state of the packet?

Particularly, how does it know which was the matching flow entry, and which
action in the action list is being executed?

Page 15:

- "Additionally each OFFlowTable can output a packet to a specific port." As
in generic comment 4), this should not

be the case. Tables can only output to the controller (without OutputAction
involvment).

- On Fig 5. a number of arrows are missing from the lines pointing to
OFPorts.

Page 16:

- The "OpenFlow Atomic Types" table: it should be made clear that there are
more atomic types used in the OpenFlow

description, but those types (e.g., IEEEMAC) are defined elsewhere - I guess
in the LFB Library.

Page 20:

- "... the maximum number of bytes of new flow that datapath should send ...
". "new flow" is not a correct a term here.

"unmatched / invalid frame" should be better. The controller does not
neccesarily ant to convert it to a flow.

Page 22:

- first paragraph: same comment as for Page 9 / Fig 1. regarding Action Set
vs. Metadata field

- sencond paragraph: as Dave Meyer commented already, the text should
elaborat on how matching is done. I would suggest

that it is described among the description of concepts, and this paragraph
refers to that.

Page 24:

- It it intentional that "buffer" is made a component of the FlowTable, and
not a separate LFB? In OpenFlow a packet

is buffered when sent to the controller, regardless of which table it came
on. With packet out, the controller can

instruct the switch to execute "on the fly defined" actions on the packet
and/or send it through the pipeline starting

at Table 0. There is no need for keeping track of which packet was buffered
in which table.

Page 25:

- OFPortLFB / Data Handling: The OpenFlow spec. allows a port to be a
"logical port" defined over the physical ports.

So the OFPort is not necessarily directly connected to the phyisical medium
ports.

Page 26:

- "The Length component" : I think this is a misunderstanding. The queue
does not have a length. The only length we

have in the Queue context is the length of the queue properties, which is a
wire protocol feature (for the TLV structure),

Page 27:

Page 28:

- "As none of the OFActionLFBs have no capabilities..." - there no is not
needed

Page 29:

- "Only valid in the action set of a packet-out message" should be "action
list of a packet-out message".

Page 33:

- 5.8.18.2: the Push VLAN action's argument is an Ethertype, not a VLAN
header value.

Page 35:

Page 36:

Page 37:

Page 38:

- IngressPort: certain values are invalid for the match type (those >
OFPP_MAX)

Page 39:

- ArpOpcode: As of OpenFlow 1.1, this field is "overloaded" into the IP
protocol field. Is it intentional

Page 48:

Page 50:

Page 52:

- "VLNA" -> "VLAN"

Page 53:

Page 57:

Page 58:

- "Length of property" : same as for Page 26. This is a wire protocol TLV
feature, should be not part of the data model.

---

From: Zoltán Lajos Kis <[email-masked]>
Date: Mon, 11 Jun 2012 08:47:25 +0200

________________________________
From: Haleplidis Evangelos [mailto:[email-masked]]
Sent: Saturday, June 09, 2012 12:18 AM
To: Zoltán Lajos Kis
Cc: [email-masked]
Subject: RE: More comments on draft-haleplidis-forces-openflow-lib-00

Greetings Zoltan,

Thank you very much for the extensive comments. I responded to your generic comments.
I will answer you text comments in an separate email.

Please see inline.

Regards,
Evangelos Haleplidis.

Hi,

Regards,
Zoltan.

Generic comments:

[ΕΗ] If I understand you correctly, an ActionSet may contain multiple set field actions (e.g. set IP address, set MAC address), but only one of a kind (only one set IP address). Correct? And the same applies to push/pop tag action. If yes, then we will modify the text accordingly.

[Z] Yes, one of each OFPAT_* type, as identified by the ofp_action_type  enum starting on p. 31.. Just for clarity, it can contain one set IP src. address, and one set IP dst. address; similarlyone set MAC src and one set MAC dst. It can also contain one pop MPLS, one pop VLAN, one push MPLS and one push VLAN.

[ΕΗ] Regarding queues, we may need to add an additional figure to depict queues. I don’t think that the current definition of the queue LFB is different from what you describe. You may have multiple instances of QueueLFBs, each with its own queue ID (which may not be unique. Only the Queue LFB’s Instance ID is unique).

[Z] To me the current description of where queues are located is not clear. 5.5(.1) suggests that the packet first enters the QueueLFB, which then passes it to the PortLFB. At the same time 5.8(.1) suggests OutputActionLFB directly sends the packet to the PortLFB. Either way, my point is that the QueueLFB must be identified by the tuple of the output port id and the queue id.
a) If QueueLFBs are "between" OutputActionLFB and PortLFB, then the OutputActionLFB must route the packet to the correct QueueLFB by taking into account both the port id and queue id. Then the QueueLFB will have a single output to a single PortLFB instance, so no more routing is needed.
b) If QueueLFBs are "after" PortLFBs then the queue id must be propagated to the PortLFB instance as a metadata, and the PortLFB must route to the correct QueueLFB based on that.

[ΕΗ] Continuing from above, we do need to add the queue_ID metadata as you describe in your comment.
Regarding the of_phy_port, the OF 1.1 spec is a bit confusing:

1.       What is the meaning of ingress port if you have the of_phy_port & of_in_port metadata? Is ingress port the of_in_port?

2.       Where is the of_phy_port generated, and how is it transmitted (it is not shown in Figure 2 in the OF 1.1 spec).

3.       The of_phy_port is only useful in the case of the frame sent to the controller?

4.       Are there any other components of the datapath described (only) in the protocol instead of the datapath definition. Example table 4 is datapath spec but appendix A is protocol spec.

[Z] Unfortunately the spec. is indeed confusing regarding this, and I suppose it was never fixed. I just wanted to point out that if you want full conformance to the spec., this is also something to be taken into account.
An example scenario would be that the switch has four physical ports (Port1 - Port4), and using an "out-of-band" protocol, a logical LAG port, Port5 is configured, aggregating Port1 and Port2,. So now the datapath would not receive packets on Port1 or Port2, but instead on Port5 only. However, when
this packet is sent to the controller, it tells that the input port is Port5, but physically it came on Port1.
1) as described if you have logical ports defined, it tells the actual phyisical port.
2) in ForCES I would guess the OFPortLFB would generate both by default. But if you had a new LFB inserted between the PortLFB and TableLFB, then this new "logical port" LFB would update the in_port metadata.
3) Yes, that is the only place where the spec. exposes this metadata.
4)  I believe not; only those I described in my mail.

[ΕΗ] There is currently no OFOutputActionLFB defined, but there will be in the next draft update. The current model description has the OFFlowTable to output the frame to the port or queue, but upon discussion it’s better to have an additional Action LFB.
As for the ToControllerLFB and FromControllerLFB, these two LFBs have been defined in the LFB-library document as the RedirectIn and RedirectOut LFBs. A new figure should be added to depict them as well. If there is a need for more components than defined in these two LFBs we can extend them.

[ΕΗ] An experimenter action can be defined as a new OFActionLFB. As for matches, the datatype definition for the match will need to be updated. However this is a good idea and we should add such section

 ---- 8< ----

Z.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 11 Jun 2012 07:21:13 -0400

On Mon, Jun 11, 2012 at 2:47 AM, Zoltán Lajos Kis
<[email-masked]> wrote:

> a) If QueueLFBs are "between" OutputActionLFB and PortLFB, then the
> OutputActionLFB must route the packet to the correct QueueLFB by taking into
> account both the port id and queue id. Then the QueueLFB will have a single
> output to a single PortLFB instance, so no more routing is needed.
>
> b) If QueueLFBs are "after" PortLFBs then the queue id must be propagated to
> the PortLFB instance as a metadata, and the PortLFB must route to the
> correct QueueLFB based on that.
>

Sounds to me like OF spec seems to be making claim for #b, no?
i.e the set queue id could be done anywhere in the middle way before the
output port is hit. Which may translate to either:
a) there are exactly X queues per port (in 802.1q type h/ware X typically=8)
so no need to worry about which port it is going to (setting a queue
is essentially
equivalent to selecting a COS value)
b) There exist global queues, so it doesnt matter which port they end up on, the
queue id being set by set_queue action is selecting the global queue.

In both cases, the port id is unneeded - no?

> [Z] Unfortunately the spec. is indeed confusing regarding this, and I
> suppose it was never fixed. I just wanted to point out that if you want full
> conformance to the spec., this is also something to be taken into account.

Did you mean implementations do it that way (and the OF spec is not
representative)?

> An example scenario would be that the switch has four physical ports (Port1
> - Port4), and using an "out-of-band" protocol, a logical LAG port, Port5 is
> configured, aggregating Port1 and Port2,. So now the datapath would not
> receive packets on Port1 or Port2, but instead on Port5 only. However, when

I suspect where you have more virtual ports in between only the last
one is reported to the controller (or other intermidiate LFBs)?

> 1) as described if you have logical ports defined, it tells the actual

So ingress_port is called of_phy port when redirecting to the CE?
Why two metadatum to represent the same thing?

cheers,
jamal

---

From: Zoltán Lajos Kis <[email-masked]>
Date: Mon, 11 Jun 2012 19:42:59 +0200

>Sounds to me like OF spec seems to be making claim for #b, no?

[Z2] Yes, b is the "OpenFlow way of queuing".

>equivalent to selecting a COS value)

[Z2] Yes, something like that. But the intention was to remove those semantics from the
queues. E.g. it would be perfectly valid that Queue1 on Port1 is a max-rate-queue,
while Queue1 on Port2 is a min-rate queue.

>queue id being set by set_queue action is selecting the global queue.

[Z2] No, if queues are "global", they must be identified by the port_id, queue_id pair.

>In both cases, the port id is unneeded - no?

[Z2] Port id is needed, but if an OutputActionLFB sends frames to the PortLFB, the port
id does not need to be added as a metedata.

>Did you mean implementations do it that way (and the OF spec is not

[Z2] I meant the opposite. The specification defines of_phy_port for the use case
below, but I am not aware of any implementation that makes use of this logical port
concept.

>one is reported to the controller (or other intermidiate LFBs)?

[Z2] Correct.

>Why two metadatum to represent the same thing?

[Z2] In_phy_port represents the physical port. In_port represents the logical port if
one was defined; otherwise it equals to in_phy_port.

Up until OpenFlow 1.2 the OFPT_PACKET_IN message had a fixed structure, so it had
to carry both identifiers, even though in most cases the two are equal. In OpenFlow 1.3
this is replaced by a TLV structure, so in_phy_port is only sent to the controller if it
differs from in_port.

Regards,
Zoltan.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 12 Jun 2012 07:42:10 -0400

On Mon, Jun 11, 2012 at 1:42 PM, Zoltán Lajos Kis
<[email-masked]> wrote:

> while Queue1 on Port2 is a min-rate queue.

I wonder if you can have ports with differrent number of queues
defined (eg 4 on port1 vs 8
on port2)

> [Z2] No, if queues are "global", they must be identified by the port_id, queue_id pair.

I dont see why. Global in this sense means shared by all ports, the
queue id should
be sufficient information. The other scenario is easily identified by
the LFB instance
topology definition.

> this is replaced by a TLV structure, so in_phy_port is only sent to the controller if it

I meant the metadata labelled as "ingress_port" in 1.1 spec. Is that
in_phy_port or
in_port? Maybe you mean it is gone in 1.3?

cheers,
jamal

---

From: Zoltán Lajos Kis <[email-masked]>
Date: Tue, 12 Jun 2012 13:48:37 +0200

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]] 
> Sent: Tuesday, June 12, 2012 1:42 PM
> To: Zoltán Lajos Kis
> Cc: Haleplidis Evangelos; [email-masked]
> Subject: Re: [forces] More comments on 
> draft-haleplidis-forces-openflow-lib-00
> 
> > [Z2] Yes, something like that. But the intention was to 
> remove those 
> > semantics from the queues. E.g. it would be perfectly valid that 
> > Queue1 on Port1 is a max-rate-queue, while Queue1 on Port2 
> is a min-rate queue.
> 
> I wonder if you can have ports with differrent number of 
> queues defined (eg 4 on port1 vs 8 on port2)

[Z3] Yes, the specification allows this scenario.

> 
> >>b) There exist global queues, so it doesnt matter which 
> port they end 
> >>up on, the queue id being set by set_queue action is 
> selecting the global queue.
> >
> I dont see why. Global in this sense means shared by all 
> ports, the queue id should be sufficient information. The 
> other scenario is easily identified by the LFB instance 
> topology definition.

[Z3] That kind of global queues (i.e., shared by ports) are not
conforming to the OpenFlow queues. The traffic of one port/queue
Should not affect how the traffic of another port/queue is handled

> > [Z2] In_phy_port represents the physical port. In_port 
> represents the 
> > logical port if one was defined; otherwise it equals to in_phy_port.
> >
> > Up until OpenFlow 1.2 the OFPT_PACKET_IN message had a fixed 
> > structure, so it had to carry both identifiers, even though in most 
> > cases the two are equal. In OpenFlow 1.3 this is replaced by a TLV 
> > structure, so in_phy_port is only sent to the controller if 
> it differs from in_port.
> >
> 
> I meant the metadata labelled as "ingress_port" in 1.1 spec. 
> Is that in_phy_port or in_port? Maybe you mean it is gone in 1.3?
> 

[Z3] Basically every mention of ingress port refers to in_port. The in_phy_port
is only exposed in packet in messages.
I just meant that up until 1.2 the packet_in message had to contain both in_port
And in_phy_port, even if they had the same value. In 1.3 in_phy_port is only to
be sent if it is different from in_port.

Z.