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

["Haleplidis Evangelos" <[e-mail]>]

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.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Zoltan Lajos Kis
> Sent: Wednesday, May 30, 2012 12:32 PM
> To: Haleplidis Evangelos; [e-mail]
> Cc: [e-mail]
> 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.
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Haleplidis
> > Evangelos
> > Sent: Wednesday, May 30, 2012 1:40 AM
> > To: 'David Meyer'; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [Sdnp] [forces] a few initial comments on
> > draft-haleplidis-forces-openflow-lib-00
> >
> > Greetings,
> >
> > Thank you very much for your comments.
> >
> > Please see inline.
> >
> > Regards,
> > Evangelos Haleplidis.
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of David Meyer
> > > Sent: Friday, May 25, 2012 8:48 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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).
> > >
> >
> > [ΕΗ] It is planned to model all current 1.x versions and as Jamal
> > pointed out, maybe not all in one document.
> >
> > >         (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)
> > >
> >
> > [ΕΗ] Yes, figure 2 is quite complicated. We're trying to make the
> > model less complex.
> >
> > >         (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.
> > >
> >
> > [ΕΗ] 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?
> >
> > >         (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).
> > >
> >
> > [ΕΗ] 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"?
> >
> > >
> > >
> > >        Again, thnx for doing this work.
> > >
> > >         --dmm
> > >
> > > -
> >
> > _______________________________________________
> > SDNP mailing list
> > [e-mail]
> > http://lucidvision.com/mailman/listinfo/sdnp
> >
> _______________________________________________
> forces mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/forces