I see. So the Barrier( ) is more of an operation which ensures that all messages until that point have been "taken care of" (usually without dropping). The spec gives the impression that it is more equivalent to a transaction commit (the barrier reply message actually carries a xid). Probably that should be clarified in there.
Thanks. -- Regards, Syed Akbar Mehdi, School of EECS (SEECS), National University of Sciences and Technology (NUST), Pakistan. On Mon, Dec 20, 2010 at 12:42 PM, kk yap <yap...@stanford.edu> wrote: > 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 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 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 Barrier Request". > >> > >> -- > >> Regards, > >> Syed Akbar Mehdi, > >> School of EECS (SEECS), > >> National University of Sciences and Technology (NUST), > >> Pakistan. > >> > >> On Mon, Dec 20, 2010 at 12:18 PM, kk yap <yap...@stanford.edu> wrote: > >>> > >>> 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 barrier request > >>> 3) send flow stat after receiving barrier reply > >>> This ensures that the flow mod is processed by the switch already. > >>> Switch can choose to process messages out of order of what is > >>> received, except for the barrier message. > >>> > >>> Hope this is clearer. > >>> > >>> Regards > >>> KK > >>> > >>> On 19 December 2010 22:53, Syed Akbar Mehdi > >>> <akbar.me...@seecs.nust.edu.pk> wrote: > >>> > Hi KK, > >>> > > >>> > You say that: > >>> > > >>> > "Meaning, it is perfectly okay for a switch to > >>> > send a reply to the barrier and ignore the flow mod before that." > >>> > > >>> > How is the barrier reply useful then, if it does not guarantee this? > >>> > > >>> > -- > >>> > Regards, > >>> > Syed Akbar Mehdi, > >>> > School of EECS (SEECS), > >>> > National University of Sciences and Technology (NUST), > >>> > Pakistan. > >>> > > >>> > On Mon, Dec 20, 2010 at 10:38 AM, kk yap <yap...@stanford.edu> > wrote: > >>> >> > >>> >> 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 to the switch, but, this is not always the case. For > example, > >>> >> > if I > >>> >> > send two identical ofp_flow_mod requests with the > OFPFF_CHECK_OVERLAP > >>> >> > flag > >>> >> > set, then I will still get a flow mod, even though one triggers an > >>> >> > error > >>> >> > and > >>> >> > is not added to the switch's table. > >>> >> > >>> >> A flow mod event is triggered whenever a flow_mod is sent by a > >>> >> component. As you have noticed, multiple comments can be sending > flow > >>> >> mods and this is a way for a component to see all the flow mods > sent. > >>> >> That's all. It does not imply NOX has sent the message, and even > less > >>> >> if the switch has received it or processed it. > >>> >> > >>> >> > > >>> >> > I'm guessing the reason for this is speed. Since OpenFlow switches > do > >>> >> > not > >>> >> > reply to flow mod requests, there are a couple ways I can think of > to > >>> >> > confirm if a flow was added: > >>> >> > > >>> >> > 1. Send a barrier message after each add flow message. If a reply > is > >>> >> > received and no error message was received, then it was added. > >>> >> > >>> >> Most of the time, you are right. While OpenFlow messages are > carried > >>> >> over TCP and SSL connections, there is no guarantee that a switch > will > >>> >> honor all the messages. Meaning, it is perfectly okay for a switch > to > >>> >> send a reply to the barrier and ignore the flow mod before that. > This > >>> >> is really because a switch can be overwhelmed by control messages > and > >>> >> at some point it might discard messages. Your flow mod might just > be > >>> >> the unlucky message dropped. > >>> >> > >>> >> > 2. Store an internal copy of the flow table in the NOX component > and > >>> >> > check > >>> >> > for potential errors before adding. > >>> >> > >>> >> Yes. This is prudent but unfortunately tedious. This allows assume > >>> >> you emulate the entire switch functionality in the controller. By > the > >>> >> way, you still will not have any guarantees about the switch > inserting > >>> >> the flow mod, as I have explained above. > >>> >> > >>> >> > Both of these solutions have problems if other components are also > >>> >> > adding > >>> >> > flows. Does anyone have any other ideas? > >>> >> > >>> >> In my mind, the obvious way to do this is hard and evil. You have > to > >>> >> send the flow mods, cache it in the controller and periodically dump > >>> >> the flow table to check that it is there. This can be done in > >>> >> conjunction with other operations like stat gathering, but the > >>> >> operation can be very stressful to a switch. > >>> >> > >>> >> > It would be nice if the OpenFlow protocol had responses to flow > mod > >>> >> > requests > >>> >> > that could be optionally turned on/off for speed. > >>> >> > >>> >> We have been through this discussion a few times in OpenFlow. And > >>> >> current result is that we still don't have it in the spec, even for > >>> >> the upcoming OpenFlow v1.1. > >>> >> > >>> >> > -Derek > >>> >> > > >>> >> > _______________________________________________ > >>> >> > nox-dev mailing list > >>> >> > nox-dev@noxrepo.org > >>> >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >>> >> > > >>> >> > > >>> >> > >>> >> _______________________________________________ > >>> >> nox-dev mailing list > >>> >> nox-dev@noxrepo.org > >>> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >>> > > >>> > > >> > > >
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
