Thanks Ben for your time and investigation.
> I did not look up whether this particular aspect of OpenFlow 1.3
support is a matter of conformance, but it could be improved.
I wish so.
> Please consider contributing improvements.
Though I am not good developer, I will contribute for the impro
OpenFlow 1.3 support is incomplete, as documented in the FAQ and
OPENFLOW-1.1+. I did not look up whether this particular aspect of
OpenFlow 1.3 support is a matter of conformance, but it could be
improved. Please consider contributing improvements.
On Fri, May 03, 2013 at 11:12:03AM +0900, Hiro
Hi Ben,
In OpenFlow 1.3.1, the switch needs explict table-miss entry to be added,
otherwise the packet which does not match any entry is discarded.
The table-miss entry needs OFPAT_OUTPUT output action to OFPP_CONTROLLER.
-
OpenFlow1.3.1
5.4 Table-miss (last paragraph
On Fri, May 03, 2013 at 08:32:10AM +0900, Hiroshi Miyata wrote:
> Then, in what action requests to buffer?
> Sorry, I could not find appropriate part in the specification.
In OVS, no packet_in message that results from an action ever
allocates a buffer. Only a packet_in message that results from
Hi Ben,
Thanks, I got this point.
Then, in what action requests to buffer?
Sorry, I could not find appropriate part in the specification.
...hiroshi miyata
(13/05/03 6:20), Ben Pfaff wrote:
On Fri, May 03, 2013 at 06:14:35AM +0900, Hiroshi Miyata wrote:
Hi Ben,
(13/05/03 2:35), Ben Pfaff wr
On Fri, May 03, 2013 at 06:14:35AM +0900, Hiroshi Miyata wrote:
> Hi Ben,
>
> (13/05/03 2:35), Ben Pfaff wrote:
> >Let me rephrase.
> >
> >Do these packet_in messages result from an OFPAT_OUTPUT action that
> >use OFPP_CONTROLLER as the output port?
> Yes,
> However, the reason code in the packet_
Hi Ben,
(13/05/03 2:35), Ben Pfaff wrote:
Let me rephrase.
Do these packet_in messages result from an OFPAT_OUTPUT action that
use OFPP_CONTROLLER as the output port?
Yes,
However, the reason code in the packet_in was OFPR_ACTION (0x01) rather
than OFPR_NO_MATCH (0x00).
I have investigated
Let me rephrase.
Do these packet_in messages result from an OFPAT_OUTPUT action that
use OFPP_CONTROLLER as the output port?
On Thu, May 02, 2013 at 06:49:16PM +0900, Hiroshi Miyata wrote:
> HI Ben,
>
> Indeed, I could not answer you directly, since I had been a bit confused.
> Sorry about that.
HI Ben,
Indeed, I could not answer you directly, since I had been a bit confused.
Sorry about that.
Here is my answer, I apologize if I have not understood your point
correctly.
>Are these packets from flow misses or as a result of output to
OFPP_CONTROLLER?
(I guess, you mean "table-miss"
You did not answer my question. Are these packets from flow misses or
as a result of output toOFPP_CONTROLLER? OVS only buffers packets that
result from flow misses.
On Wed, May 01, 2013 at 09:30:58PM +0900, Hiroshi Miyata wrote:
> Hi Ben,
>
> First, I need to say I am using OpenFlow 1.3.
>
>
Hi Ben,
First, I need to say I am using OpenFlow 1.3.
I am relieved to hear OVS should buffer.
I guess there are some misunderstanding in my side.
But at least what I am facing is difference between switch@trema-edge
and ovs.
With same controller, the switch from trema-edge specifies buffer_id
On Tue, Apr 30, 2013 at 03:02:46PM +0900, Hiroshi Miyata wrote:
> I am now trying to run OVS of Kernel module with
> Trema-edge(learning_switch code).
> Both are in a box. (Ubuntu 12.10)
>
> When I see the of13 packets, the buffer_id in packet_in messages are
> 0x(OPF_NO_BUFFER)
> for both
12 matches
Mail list logo
