[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