I noticed that the flow mod event fires in response to a successful NOX
API call for adding a flow. It gives the impression that it was
successfully added to the switch, but, this is not always the case. For
example, if I send two identical /ofp_flow_mod/ requests with the
Hi Derek,
Some comments inline. Hope they help.
Regards
KK
On 19 December 2010 21:10, Derek Cormier derek.corm...@lab.ntt.co.jp wrote:
I noticed that the flow mod event fires in response to a successful NOX API
call for adding a flow. It gives the impression that it was successfully
added
Thanks KK, that clears everything up. May I ask, what is the main reason
for not including a flow mod reply in the OpenFlow protocol? Is it
speed? Isn't OpenFlow fast enough?
-Derek
On 12/20/2010 02:38 PM, kk yap wrote:
Hi Derek,
Some comments inline. Hope they help.
Regards
KK
On 19
Hi Derek,
This question is better asked on openflow-spec or openflow-discuss. :)
Regards
KK
On 19 December 2010 22:11, Derek Cormier derek.corm...@lab.ntt.co.jp wrote:
Thanks KK, that clears everything up. May I ask, what is the main reason for
not including a flow mod reply in the OpenFlow
Hi Syed,
The barrier function is only there to tell you that a preceding
message is processed (i.e., the command is carried out, dropped or
error code is returned). So, you can imagine if you want to check the
flow mod is inserted or not, you can do the following:
1) send flow mod
2) send
Hi KK,
Thanks for detailed explanation. However this conflicts somewhat with the
OpenFlow Spec v1.0. In section 5.3.7 (page 36) of the OpenFlow1.0 spec it is
written that:
Upon receipt, the switch must finish processing *all* previously received
messages before executing any messages beyond the
Hi Syed,
One can interpret finish processing as having dropped. I am
suggesting we do, but this is apparently not a impossibility. It is a
rare event nonetheless.
Regards
KK
On 19 December 2010 23:37, Syed Akbar Mehdi
akbar.me...@seecs.nust.edu.pk wrote:
Hi KK,
Thanks for detailed
Oops.. typos.
One can interpret finish processing as having dropped. I am *not*
suggesting we do, but this is apparently not an impossibility. It is a
rare event nonetheless.
On 19 December 2010 23:41, kk yap yap...@stanford.edu wrote:
Hi Syed,
One can interpret finish processing as