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

From: Zoltán Lajos Kis <[email-masked]>
Date: Fri, 1 Jun 2012 12:31:27 +0200

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]] 
> Sent: Thursday, May 31, 2012 7:16 PM
> To: Zoltán Lajos Kis
> Cc: Haleplidis Evangelos; [email-masked]; [email-masked]
> Subject: Re: [forces] [Sdnp] a few initial comments on 
> draft-haleplidis-forces-openflow-lib-00
> 
> On Thu, May 31, 2012 at 12:07 PM, Zoltán Lajos Kis 
> <[email-masked]> wrote:
> > 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.
> >
> 
> Is it correct to conclude that the apply-actions cannot 
> terminate a flow pipeline?
> 

Correct, pipeline processing ends (and processing of the action set begins) if:
a) a matching entry was found, and the entry has no Goto (to the next table) instruction, OR
b) no matching entry was found, and the table miss behavior is not to Continue (to the next table)

Note that in OF 1.3 the table miss behavior configuration has been replaced with a table miss flow entry.
This allows one to describe the miss behavior using the instruction semantics of flow entries.

Regards,
Zoltan.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 20 Jun 2012 17:14:45 +0300

Greetings,

All your internal comments will be addressed in the second draft which we
hope to submit soon. Thank you very much.

Some responses from your internal questions:

5.1.4.  Events

   Three events have been specified regarding the ports.  The first
   event will be triggered when a new port is added to the switch, the
   second when a port has been removed from the switch and the third
   when a port has been modified

dmm> and what does ForCES do with these?

[EH] OpenFlow defines a port status message when a port has been changed.
These are three events to reflect that.

----------

   The LFB is expected to receive all types of Ethernet packets through
   a group input named Input Port, either from a OFPortLFB or a
   OFFlowTableLFB, along with metadata.  The metadata will contain only

dmm> do you mean OpenFlow "group" here? If so, why does the LFB
dmm> receive packets this way, that is, why are groups involved here?

[EH] No, this is related to the ForCES model (RFC 5812). An output group, is
used to model the case where a flow of similar packets with an identical set
of permitted metadata needs to be split into multiple paths. An output group
consists of a number of outputs, called the output instances of the group,
where all output instances share the same frame (packet) and metadata
emission definitions. Each output instance can connect to a different
downstream LFB, just as if they were separate singleton outputs. Same
applies to input group.

-----------

5.2.4.  Events

   One event have been defined regarding the Flow Table.  The event will
   be triggered when a flow is deleted from the Flow Table whether due
   to the idle timeout, or to the hard timeout or a flow was deleted by
   the controller.

dmm> how about flow added?

[EH] I did not find such an event in the OF1.1 spec, and I don't think that
it would be a good idea to include one. Imho, the best way for the flow
added is when you add a Flow Entry to get a response that your request was
successful.

Regards,
Evangelos Haleplidis.

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