Re: [nox-dev] Is flow mod event misleading?
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 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 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 > > 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 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 > >>> 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 > 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
Re: [nox-dev] Is flow mod event misleading?
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 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 > 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 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 >>> 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 wrote: >>> >> >>> >> Hi Derek, >>> >> >>> >> Some comments inline. Hope they help. >>> >> >>> >> Regards >>> >> KK >>> >> >>> >> On 19 December 2010 21:10, Derek Cormier >>> >> 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
Re: [nox-dev] Is flow mod event misleading?
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 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 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 >> 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 wrote: >> >> >> >> Hi Derek, >> >> >> >> Some comments inline. Hope they help. >> >> >> >> Regards >> >> KK >> >> >> >> On 19 December 2010 21:10, Derek Cormier >> >> 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
Re: [nox-dev] Is flow mod event misleading?
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 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 > 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 wrote: > >> > >> Hi Derek, > >> > >> Some comments inline. Hope they help. > >> > >> Regards > >> KK > >> > >> On 19 December 2010 21:10, Derek Cormier > >> 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://noxre
Re: [nox-dev] Is flow mod event misleading?
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 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 wrote: >> >> Hi Derek, >> >> Some comments inline. Hope they help. >> >> Regards >> KK >> >> On 19 December 2010 21:10, Derek Cormier >> 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
Re: [nox-dev] Is flow mod event misleading?
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 wrote: > Hi Derek, > > Some comments inline. Hope they help. > > Regards > KK > > On 19 December 2010 21:10, Derek Cormier > 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
Re: [nox-dev] Is flow mod event misleading?
Hi Derek, This question is better asked on openflow-spec or openflow-discuss. :) Regards KK On 19 December 2010 22:11, Derek Cormier 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 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 December 2010 21:10, Derek Cormier >> 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
Re: [nox-dev] Is flow mod event misleading?
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 December 2010 21:10, Derek Cormier 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
Re: [nox-dev] Is flow mod event misleading?
Hi Derek, Some comments inline. Hope they help. Regards KK On 19 December 2010 21:10, Derek Cormier 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] Is flow mod event misleading?
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. 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. 2. Store an internal copy of the flow table in the NOX component and check for potential errors before adding. Both of these solutions have problems if other components are also adding flows. Does anyone have any other ideas? It would be nice if the OpenFlow protocol had responses to flow mod requests that could be optionally turned on/off for speed. -Derek ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
