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

Haleplidis Evangelos ehalep at gmail.com
Wed Jun 20 10:14:45 EDT 2012


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.

> -----Original Message-----
> From: forces-bounces at ietf.org [mailto:forces-bounces at ietf.org] On
> Behalf Of David Meyer
> Sent: Friday, May 25, 2012 8:48 PM
> To: forces at ietf.org
> Cc: sdnp at lucidvision.com
> 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
> 
> -



More information about the SDNP mailing list