On Tue, Oct 2, 2012 at 9:11 AM, Ben Pfaff <[email protected]> wrote:

> This interpretation seems needlessly wasteful.  It forces the switch
> to keep an extra copy of the original flow match around, instead of
> allowing it to convert it to an internal form and discard the
> original.
>

This is how the Indigo2 reference switch works.  It keeps the OF state
representation independent of the forwarding state representation
specifically for this reason.

-Dan


>
> On Tue, Oct 02, 2012 at 03:11:05PM +0000, Zoltán Lajos Kis wrote:
> > The OF 1.3 specification says the following on the body of a flow stats
> reply (p. 63.):
> >
> > "The  fields consist of those provided in the flow_mod that created the
> flow entry..."
> >
> > So in my reading whatever was sent by the controller should be sent back
> unmodified by the switch upon stats query, which is a).
> >
> > Regards,
> > Zoltan.
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:
> [email protected]] On Behalf Of Christian
> Esteve Rothenberg
> > Sent: Tuesday, October 02, 2012 4:47 PM
> > To: Eder Leão Fernandes
> > Cc: [email protected]
> > Subject: Re: [openflow-discuss] How masked values are stored in the Flow
> Table on OpenFlow 1.2?
> >
> > Hi all,
> >
> > just looking for further clarification on the issue of how to handle OXM
> wildcarded flow entries.
> >
> > If the controller sends a flow mod command that includes a flow match as
> follows:
> > IP 192.168.1.1 IP_mask= 255.255.0.0
> >
> > How should the flow entry installed by the switch look like?
> >
> > a)  IP 192.168.1.1 IP_mask= 255.255.0.0
> >
> > or
> >
> > b)  IP 192.168.0.0 IP_mask= 255.255.0.0
> >
> > ?
> >
> > While for actual packet matching purposes it does not matter, it matters
> when you want to query about statitstics or when you want to modify flow
> entries, as the field and mask values needs to be syntatctically equal, not
> functionally equal (i.e. after applying the mask).
> >
> > Our interpretation is that the mask should not be applied by the switch
> when installing the entry and should be respect what was sent by the
> controller (a). However, we have encoutered 1.2 prototype implementations
> that seem to have opted for the second interpretation (b).
> >
> > That said, it seems like a good best practice that the controller itself
> applies any widlcards to the match field before sending any protocol
> message with an OXM flow match structure.
> >
> > -Christian
> >
> >
> > On Fri, Sep 28, 2012 at 10:49 AM, Eder Leão Fernandes <
> [email protected]> wrote:
> > > Hi,
> > >
> > > I have a question regarding how masked OXM values are stored in the
> > > flow tables.  I would like to know if the values should be stored with
> > > the respective mask applied?
> > > For example:
> > > If I have an IP source value 192.168.16.150 and mask 0xffffff00. The
> > > value should be stored as 192.168.16.150 or 192.168.16.0?
> > >
> > > I'm asking this because, when testing Ryu Controller  with CPqD
> > > implementation of OpenFlow 1.2 software switch, I noticed that tests
> > > with masked fields expect values with the mask applied, leading to
> > > failures, since the switch implementation doesn't stores the values
> > > with the masks applied.
> > >
> > > Thanks in advance,
> > > Eder.
> > >
> > > --
> > >
> > >
> > > _______________________________________________
> > > openflow-discuss mailing list
> > > [email protected]
> > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
> > >
> >
> >
> >
> > --
> > Christian
> > _______________________________________________
> > openflow-discuss mailing list
> > [email protected]
> > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
> > _______________________________________________
> > openflow-discuss mailing list
> > [email protected]
> > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
> _______________________________________________
> openflow-discuss mailing list
> [email protected]
> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>
_______________________________________________
openflow-discuss mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss

Reply via email to