Subject: [forces] a few initial comments on draft-haleplidis-forces-openflow-lib-00

From: David Meyer <[email-masked]>
Date: Fri, 25 May 2012 10:47:58 -0700

Great start folks. A few inital comments. General
        comments here then search for dmm> in-line in the attached...

        Meta-comment: The document is perhaps overly perscriptive
        with respect to how different functionality is  *implemented*.
        See for example the description of Apply Actions in section
        5.2.1, which is described in terms of which data structures
        implement the functionality. You can see this again in the
        description of FlowEntries in section 5.2.2. Other high level
        comments:

        (i).    1.3 would be a better spec to target. I
                understand that 1.3 might not have been around
                when you started this work but it seems that 1.3
                will be the post 1.0 stable version (eventually).

        (ii).   The modeling is in some places a little
                inaccurate (see my comments in-line), and perhaps
                a bit more complicated than necessary.

        (iii).  The figures (e.g., Figure 2) are complicated and
                could use text explaining packet flow (and what
                the labels are)

        (iv).   When talking about matching, it would be good to
                show explicitly how OXM match behavior is
                emulated. See the discussion of OFFlowTableLFB in
                section 5.2.1.

        (v).    The discussion of groups in section 5.{2,3}.1 seems
                to indicate that packets can come back to the OF
                "pipeline" from a group; is that the intent (see
                my coments in-line on this).

       Again, thnx for doing this work.

        --dmm

-

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 27 May 2012 12:28:34 -0400

>                will be the post 1.0 stable version (eventually).

Refer to related comment i made on the list. Isnt it a GoodThing to be
able to define a model that is both backward and forward  compatible?
[i.e controller with any of {1.0,1.1,1.2,1.3} working with FE with version
{1.0,1.1,1.2,1.3}]?
OF seems hackish to not respect any of that but it could be "corrected"
with ForCEs. The cost may come with overly complicated resulting model.
If nobody cares about anything below 1.3 then i would suggest maybe
we need two drafts, one that demonstrates how 1.1 and maybe 1.0 work
together with both backward and forward compat (even if it is an academic
exercise) and a clean slate one that starts at 1.3

cheers,
jamal

---

From: David Meyer <[email-masked]>
Date: Mon, 28 May 2012 10:28:33 -0700

> [i.e controller with any of {1.0,1.1,1.2,1.3} working with FE with version

Of course. My point was that the 1.3 spec looks like its going to be
more or less the baseline post 1.0(.X).

--dmm

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 30 May 2012 02:40:15 +0300

Greetings,

Thank you very much for your comments.

Please see inline.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David Meyer
> Sent: Friday, May 25, 2012 8:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [forces] a few initial comments on draft-haleplidis-forces-
> openflow-lib-00
> 

[ΕΗ] It is planned to model all current 1.x versions and as Jamal pointed
out, maybe not all in one document.

>                 could use text explaining packet flow (and what

[ΕΗ] Yes, figure 2 is quite complicated. We're trying to make the model less
complex.

>                 emulated. See the discussion of OFFlowTableLFB in

[ΕΗ] A good suggestion. We will add some text. OXM as far as I understand
it, is mostly protocol-related. In the model, the match fields of the flow
table are the same. When with the protocol you omit some match fields, it is
implied that the rest of the fields are consider to be wildcards. Or do I
miss something?

>                 my coments in-line on this).

[ΕΗ] Yes that was the intent. The packet will come back to the OF pipeline
from where it came. Your comment in-line suggests that going to a group is
terminal for a packet. However, in the 1.1 OF specification, I have found no
explicit indication. It does not says anywhere what happens to a packet when
it finishes processing the group, or have I missed it? Is it implied in the
following statement I found in the spec: "If the list contains a group
actions, a copy of the packet in its current state is processed by the
relevant group buckets"?

---

From: Zoltán Lajos Kis <[email-masked]>
Date: Wed, 30 May 2012 11:31:47 +0200

Hi, re. groups:

Yes, groups are terminal for packets. The OpenFlow pipeline consists of the flow tables only (but not the group table). At any point when a flow directs the packet to a port or a group, the packet leaves this pipeline and never returns. If the packet is sent to a group, the appropriate buckets are executed recursively until a bucket outputs the packet on a port. 
The intention of groups is to introduce a layer of indirection between flow entries and output ports. In cases when multiple flow entries would execute the same actions on a packet (including output), this can be defined in a group, so only the group buckets need to be changed, but not the flow entries themselves. Groups also provide "advanced" features that would be hard to describe with the OpenFlow protocol otherwise, like ECMP or fast failover.

Regards,
Zoltan.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Haleplidis 
> Evangelos
> Sent: Wednesday, May 30, 2012 1:40 AM
> To: 'David Meyer'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sdnp] [forces] a few initial comments on 
> draft-haleplidis-forces-openflow-lib-00
> 
> Greetings,
> 
> [ΕΗ] It is planned to model all current 1.x versions and as 
> Jamal pointed out, maybe not all in one document.
> 
> [ΕΗ] Yes, figure 2 is quite complicated. We're trying to make 
> the model less complex.
> 
> [ΕΗ] A good suggestion. We will add some text. OXM as far as 
> I understand it, is mostly protocol-related. In the model, 
> the match fields of the flow table are the same. When with 
> the protocol you omit some match fields, it is implied that 
> the rest of the fields are consider to be wildcards. Or do I 
> miss something?
> 
> [ΕΗ] Yes that was the intent. The packet will come back to 
> the OF pipeline from where it came. Your comment in-line 
> suggests that going to a group is terminal for a packet. 
> However, in the 1.1 OF specification, I have found no 
> explicit indication. It does not says anywhere what happens 
> to a packet when it finishes processing the group, or have I 
> missed it? Is it implied in the following statement I found 
> in the spec: "If the list contains a group actions, a copy of 
> the packet in its current state is processed by the relevant 
> group buckets"?
> 
> > 
> > 
> _______________________________________________
> SDNP mailing list
> [email-masked]
> http://lucidvision.com/mailman/listinfo/sdnp
>

---

From: David Meyer <[email-masked]>
Date: Wed, 30 May 2012 06:29:25 -0700

> out, maybe not all in one document.

dmm> fair enough
> actions, a copy of the packet in its current state is processed by the

dmm> Zoltan answered this one.

Thnx,

--dmm

---

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

Greetings,

Thanks for the clarification. This probably isn't the best place for this
kind of question, but since it may affect the model, I have a small
clarification question.

I understand what you said about the group. In the OF specs it says:
"If the action list list contains an output action, a copy of the packet is
forwarded in its current state to the desired port. If the list contains a
group actions, a copy of the packet in its current state is processed by the
relevant group buckets"

So from what I understand a copy of the packet is sent to the port or the
group (and never returns). What happens to the original packet? Will it
continue or will it be dropped?

A bit later from the above text it says:
"After the execution of the action list in an Apply-Actions instruction,
pipeline execution continues on the modified packet".

>From what I understand, after the copy has been done to either the group or
the output the original packet will continue on the pipeline.

Did I understood it correctly?

Regards,
Evangelos Haleplidis.

> Behalf Of Zoltan Lajos Kis
> Sent: Wednesday, May 30, 2012 12:32 PM
> To: Haleplidis Evangelos; [email-masked]
> Cc: [email-masked]
> Subject: Re: [forces] [Sdnp] a few initial comments on draft-
> haleplidis-forces-openflow-lib-00
> 
> Hi, re. groups:
> 
> Yes, groups are terminal for packets. The OpenFlow pipeline consists of
> the flow tables only (but not the group table). At any point when a
> flow directs the packet to a port or a group, the packet leaves this
> pipeline and never returns. If the packet is sent to a group, the
> appropriate buckets are executed recursively until a bucket outputs the
> packet on a port.
> The intention of groups is to introduce a layer of indirection between
> flow entries and output ports. In cases when multiple flow entries
> would execute the same actions on a packet (including output), this can
> be defined in a group, so only the group buckets need to be changed,
> but not the flow entries themselves. Groups also provide "advanced"
> features that would be hard to describe with the OpenFlow protocol
> otherwise, like ECMP or fast failover.
> 
> Regards,
> Zoltan.
> 
> > [ΕΗ] It is planned to model all current 1.x versions and as Jamal
> > pointed out, maybe not all in one document.
> >
> > [ΕΗ] Yes, figure 2 is quite complicated. We're trying to make the
> > model less complex.
> >
> > [ΕΗ] A good suggestion. We will add some text. OXM as far as I
> > understand it, is mostly protocol-related. In the model, the match
> > fields of the flow table are the same. When with the protocol you
> omit
> > some match fields, it is implied that the rest of the fields are
> > consider to be wildcards. Or do I miss something?
> >
> > [ΕΗ] Yes that was the intent. The packet will come back to the OF
> > pipeline from where it came. Your comment in-line suggests that going
> > to a group is terminal for a packet.
> > However, in the 1.1 OF specification, I have found no explicit
> > indication. It does not says anywhere what happens to a packet when
> it
> > finishes processing the group, or have I missed it? Is it implied in
> > the following statement I found in the spec: "If the list contains a
> > group actions, a copy of the packet in its current state is processed
> > by the relevant group buckets"?
> >
> > >
> > >
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Zoltán Lajos Kis <[email-masked]>
Date: Thu, 31 May 2012 18:07:07 +0200

Hi,

Yes, the interpretation is correct. If the apply-actions' action list contains an output or group action, a copy of the current packet (i.e., the previous actions in the action list have been applied) are sent to the port or group, as if the packet reached the end of the pipeline. The pipeline processing will continue with the original copy with the next action in the action list.

As a historical note, the action list in the apply actions instruction retains the semantics of the OpenFlow 1.0 flow entries. In 1.0 flow entries the way to achieve multicast-like behavior was to list actions like: [ ... modify packet for 1st output ..., output, ... modify packet for 2nd output ..., output, ...].

Regards,
Zoltan. 

> From: Haleplidis Evangelos [mailto:[email-masked]] 
> Sent: Thursday, May 31, 2012 12:40 AM
> To: Zoltán Lajos Kis; [email-masked]
> Cc: [email-masked]
> Subject: RE: [forces] [Sdnp] a few initial comments on 
> Thanks for the clarification. This probably isn't the best 
> place for this kind of question, but since it may affect the 
> model, I have a small clarification question.
> 
> "If the action list list contains an output action, a copy of 
> the packet is forwarded in its current state to the desired 
> port. If the list contains a group actions, a copy of the 
> packet in its current state is processed by the relevant 
> group buckets"
> 
> So from what I understand a copy of the packet is sent to the 
> port or the group (and never returns). What happens to the 
> original packet? Will it continue or will it be dropped?
> 
> "After the execution of the action list in an Apply-Actions 
> instruction, pipeline execution continues on the modified packet".
> 
> From what I understand, after the copy has been done to 
> either the group or the output the original packet will 
> continue on the pipeline.
> 
> > Yes, groups are terminal for packets. The OpenFlow pipeline 
> consists 
> > of the flow tables only (but not the group table). At any 
> point when a 
> > appropriate buckets are executed recursively until a bucket outputs 
> > the packet on a port.
> > would execute the same actions on a packet (including output), this 
> > can be defined in a group, so only the group buckets need to be 
> > changed, but not the flow entries themselves. Groups also 
> provide "advanced"
> > > pipeline from where it came. Your comment in-line suggests that 
> > > going to a group is terminal for a packet.
> > > group actions, a copy of the packet in its current state is 
> > > processed by the relevant group buckets"?
> > >
> > > >
> > > >

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 31 May 2012 13:15:53 -0400

> Yes, the interpretation is correct. If the apply-actions' action list contains an output or group action, a copy of the current packet (i.e., the previous actions in the action list have been appli…

Is it correct to conclude that the apply-actions cannot terminate a
flow pipeline?

cheers,
jamal