Hi Ben, > I'm not aware of wording that says a switch may simply ignore a > command. The transport is TCP (or SSL on TCP), so nothing is going to > get accidentally lost.
We are saying the same thing. I said "there is nothing in OpenFlow that dictates reliable execution of commands received" and you are saying "there is nothing in OpenFlow that dictates unreliable execution". In that case, guess what is the minimum acceptable behavior? :) > I'm not sure what you mean by "too busy". I would assume that, if a > switch is busy, it would just take longer to execute commands. If it > can't execute any commands at the moment, then it should stop reading > commands from the OpenFlow connection. And switches these days do not have a lot of buffer or CPU capability (no, we are not always talking about software switches). So, later might not always an option, esp. if the net request rate is greater than the net processing capability. Dropping reduce the net request rate and not delaying. If you like a demonstration of killing a hardware switch with flow stats, grab oflops and run a test. Hope I am being clearer now. Regards KK On 9 March 2010 09:31, Ben Pfaff <[email protected]> wrote: > On Mon, Mar 08, 2010 at 09:32:32PM -0800, kk yap wrote: >> I might be wrong, but from my understanding there is nothing in >> OpenFlow that dictates reliable execution of commands received. > > I'm not aware of wording that says a switch may simply ignore a > command. The transport is TCP (or SSL on TCP), so nothing is going to > get accidentally lost. > >> I would also prefer an error, but which one would your switch send for >> being too busy? This is the 6 I know of. > > I'm not sure what you mean by "too busy". I would assume that, if a > switch is busy, it would just take longer to execute commands. If it > can't execute any commands at the moment, then it should stop reading > commands from the OpenFlow connection. > _______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
