Hi Isaku, we will open an issue via github if this is your preferred way to try to find a workable fix so that we can get interoperable implementations that adhere to the spec.
Currently, our 1.2 switch implementations passes all the tests except those with the masked flow entries, as the Ryu controller notices a difference between what the expected behaviour by the switch ( interpretation #b) and the received ones (our interpretation #a). Trema has adopted a flexible approach to deal with this issue, it is a good workaround to accept both types of switch behaviour with masked flow entries. I agree that a wise controller should avoid the issue at all and apply the OXM masks when generating the OXM flow match. However, the current specification seems vague at this point and implementations shall not assume whether OXM entries shall be masked on not. One way to fix it as Ben suggested would be via extending the "pre-requisites checks". Anyway, I hope people with access to the ONF specification process can raise this issue and get it clarified in future revisions, may be when releasing the "-implemented" versions of the specs. -Christian On Wed, Oct 3, 2012 at 3:53 AM, Isaku Yamahata <yamah...@valinux.co.jp> wrote: > On Fri, Sep 28, 2012 at 10:49:01AM -0300, Eder Leão Fernandes 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 > > Do you have any request to Ryu side? > If so, can you please describe more details? > > thanks > >> 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 >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > > -- > yamahata > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss -- Christian _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
