Hi all, I think FlowRemoved notification should be enabled by default.
I have not found out any benefits which "disabling the FlowRemoved notification" brings. On the other hand, "enabling the FlowRemoved notification" enables applications to get the notification. And, I don't think enabling the FlowRemoved notification itself introduces any unnecessary performance impacts by itself. In my understanding, an OpenFlow switch sends FLOW_REMOVED messages to its controller only when the controller wants that. I mean an OpenFlow switch sends FLOW_REMOVED messages only when the controller sets the SEND_FLOW_REM flag up in flow entries, and the flow entries are removed from the switch. If an application doesn't need notification of flow removal for some flow entries, the application doesn't set SEND_FLOW_REM flag up in FLOW_MOD messages for the flow entries. Then, switches do not send FLOW_REMOVED messages to the ODL, and the application doesn't get FlowRemoved notification about the flow entries. The application doesn't need to worry about the unnecessary performance impact on FlowRemoved notification for the flow entries, because it doesn't occur. If the application needs notification of flow removal for some other flow entries, the application sets SEND_FLOW_REM flag in FLOW_MOD messages for the entries. Then switches send FLOW_REMOVED messages to the ODL, and the application gets FlowRemoved notification for the entries. Of course, processing FLOW_REMOVED messages and publishing FlowRemoved notification requires some computing resources, but in this case, the application needs that, so it's necessary performance cost. My point is that the OpenFlow plugin has already provided applications with a kind of way to turn on and off per FlowRemoved notification per flow entry. Considering that, my question here is what kind of new benefits "disabling the FlowRemoved notification" brings to applications. In what kind of use cases do we need "disabling the FlowRemoved notification"? Regards, Hideyuki Tai > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Tai, > Hideyuki > Sent: Thursday, June 16, 2016 09:43 > To: Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco) > <[email protected]>; [email protected]; Manohar SL > <[email protected]>; Luis Gomez <[email protected]> > Subject: Re: [openflowplugin-dev] Bug 5602 - Li Migration: Problems to detect > the removal of flow entries > > Hi Jozef, > > Could you explain the performance impact? > I'm still not sure about the details of that performance impact. > > Are all use case and applications affected by that performance impact? > > Regards, > Hideyuki Tai > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf > > Of Luis Gomez > > Sent: Thursday, June 16, 2016 09:37 > > To: Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco) > > <[email protected]> > > Cc: [email protected]; Manohar SL > > <[email protected]> > > Subject: Re: [openflowplugin-dev] Bug 5602 - Li Migration: Problems to > > detect the removal of flow entries > > > > OK I did not know this feature had a performance impact. If this is a > > significant impact, I agree with putting this in a config flag with default > > OFF. > > > > > > > On Jun 16, 2016, at 7:58 AM, Jozef Bacigal -X (jbacigal - PANTHEON > > TECHNOLOGIES at Cisco) <[email protected]> wrote: > > > > > > I propose, llike we discuss on the last meeting, to make an openflow > > > config > > switch to add the possibility to switch on and off the flow removal > > notification with default state OFF, that we don't have any performance > > issue. > > > > > > Jozef > > > ________________________________________ > > > From: [email protected] > > > <[email protected]> on behalf of > > > Luis Gomez <[email protected]> > > > Sent: Wednesday, June 15, 2016 7:43 PM > > > To: Manohar SL > > > Cc: [email protected] > > > Subject: Re: [openflowplugin-dev] Bug 5602 - Li Migration: Problems > > > to detect the removal of flow entries > > > > > > +1, it is already bad OF protocol does not support Flow Added > > > +message, at > > least if it supports Flow Removed lets use it. > > > > > >> On Jun 15, 2016, at 5:06 AM, Manohar SL <[email protected]> > > wrote: > > >> > > >> Hi All, > > >> > > >> It would be good to retain the handling of " OFPT_FLOW_REMOVED" > > >> handling > > similar to the He PlugIn. > > >> This also accounts to OpenFlow Compliance. > > >> > > >> Basing the detection of the Flow Removal on Stats based solution > > >> will be > > very costly, in the context of time consumed for the detection of the > > flow removal. > > >> Completely agree with the below very valid points mentioned by > > >> Hideyuki > > Tai: > > >>>>>>>>>>>>>>>>>> > > >> This is about problems which applications face when it needs to > > >> detect the > > removal of flow entries. > > >> 1. It takes so long time (several seconds) to detect the removal. > > >> 2. It is possible that applications fail to detect the removal. > > >> <<<<<<<<<<<<<<<< > > >> > > >> Also, there should always be the flexibility to disable Stats at any > > >> given > time. > > >> If the Flow Removal detection is based on Stats functionality, then > > >> we will > > land up in losing this basic OpenFlow functionality. > > >> > > >> So, request to retain the Flow Removed handling similar to OF He PlugIn. > > >> > > >> Regs, > > >> Manohar. > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> Message: 1 > > >> Date: Thu, 9 Jun 2016 23:14:28 +0000 > > >> From: "Tai, Hideyuki" <[email protected]> > > >> To: openflowplugin-dev <[email protected]> > > >> Cc: "[email protected]" > > >> <[email protected]> > > >> Subject: [openflowplugin-dev] Bug 5602 > > >> Message-ID: > > >> > > >> <[email protected] > > gad.nec.c > > >> om> > > >> > > >> Content-Type: text/plain; charset="us-ascii" > > >> > > >> Hi OpenFlow Plugin project, > > >> > > >> VTN project would like the OpenFlow Plugin project to provide a way > > >> to solve > > the bug 5602 in the OFP-Li (the new plugin). > > >> This is about problems which applications face when it needs to > > >> detect the > > removal of flow entries. > > >> 1. It takes so long time (several seconds) to detect the removal. > > >> 2. It is possible that applications fail to detect the removal. > > >> > > >> You can find more detailed explanation in the Bugzilla. > > >> https://bugs.opendaylight.org/show_bug.cgi?id=5602 > > >> > > >> Please note that the OFP-He (the old plugin) doesn't have this issue. > > >> > > >> First, I would like you to decide by which way we solve the > > >> problems in > > Boron. > > >> > > >> I think there are several ways. > > >> > > >> One way is to support FlowRemoved notification like the OFP-He does. > > >> Actually, there are patches for that way. > > >> https://git.opendaylight.org/gerrit/#/c/38639 > > >> https://git.opendaylight.org/gerrit/#/c/39906/ > > >> https://git.opendaylight.org/gerrit/#/c/39552/ > > >> > > >> Since the patch (gerrit 38639) is merged, I thought OFP project > > >> decided to > > take this approach. > > >> > > >> Another way is to update the operational DS > > >> (flow-node-inventory:table) > > immediately after the OFP-Li receives FLOW_REMOVED from openflowjava. > > >> Then, applications can detect the removal of flow entries correctly > > >> using > > listeners for the DS. > > >> > > >> Which way do you take for Boron? > > >> Or other way? > > >> > > >> Regards, > > >> Hideyuki Tai > > >> > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 2 > > >> Date: Thu, 9 Jun 2016 16:35:00 -0700 > > >> From: Jamo Luhrsen <[email protected]> > > >> To: "[email protected]" > > >> <[email protected]>, > > >> "[email protected]" > > >> <[email protected]>, OpenDayLight- > > L2switch-Dev > > >> <[email protected]> > > >> Subject: [openflowplugin-dev] CSIT troubles. > > >> > > >> openflowplugin-csit-1node-flow-services-lithium-redesign-only-boron > > >> Message-ID: <[email protected]> > > >> Content-Type: text/plain; charset=utf-8 > > >> > > >> Earlier today I pointed out [0] that l2switch had something broken > > >> happening, > > but now I think I notice it in openflowplugin CSIT [1] as well. This > > job is getting aborted as it's running for 6 hours (or timeout for > > these jobs) normally it's a 20m test. > > >> > > >> something serious here. > > >> > > >> the exception in the bug [2] may give a clue. > > >> > > >> > > >> JamO > > >> > > >> [0] > > >> https://lists.opendaylight.org/pipermail/integration-dev/2016-June/ > > >> 00 > > >> 7073.html [1] > > >> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1no > > >> de -flow-services-lithium-redesign-only-boron > > >> [2] https://bugs.opendaylight.org/show_bug.cgi?id=6042 > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 3 > > >> Date: Thu, 9 Jun 2016 23:37:48 +0000 > > >> From: "Venkatrangan G - ERS, HCL Tech" <[email protected]> > > >> To: Jamo Luhrsen <[email protected]>, > > >> "[email protected]" > > >> <[email protected]>, > > >> "[email protected]" > > >> <[email protected]>, > > >> OpenDayLight-L2switch- > > Dev > > >> <[email protected]> > > >> Cc: "[email protected]" > > >> <[email protected]> > > >> Subject: Re: [openflowplugin-dev] CSIT troubles. > > >> > > >> openflowplugin-csit-1node-flow-services-lithium-redesign-only-boron > > >> Message-ID: > > >> > > >> > > > <[email protected] > > od.o > > >> utlook.com> > > >> > > >> Content-Type: text/plain; charset="us-ascii" > > >> > > >> Hi, > > >> > > >> We are facing this with the VTN jobs as well > > >> Reference: > > >> https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-csit-1node > > >> -o > > >> penstack-mitak > > >> a-neutron-beryllium/lastSuccessfulBuild/artifact/odl1_karaf.log.tar > > >> .x > > >> z > > >> > > >>> From our understanding, the PACKET_IN handling is causing this. > > >> > > >> Regards, > > >> Venkat G > > >> > > >> > > >> -----Original Message----- > > >> From: [email protected] > > >> [mailto:[email protected]] On > > >> Behalf Of Jamo Luhrsen > > >> Sent: Thursday, June 9, 2016 4:35 PM > > >> To: [email protected]; > > >> [email protected]; > > >> OpenDayLight-L2switch-Dev <[email protected]> > > >> Subject: [openflowplugin-dev] CSIT troubles. > > >> openflowplugin-csit-1node-flow-services-lithium-redesign-only-boron > > >> > > >> Earlier today I pointed out [0] that l2switch had something broken > > >> happening, > > but now I think I notice it in openflowplugin CSIT [1] as well. This > > job is getting aborted as it's running for 6 hours (or timeout for > > these jobs) normally it's a 20m test. > > >> > > >> something serious here. > > >> > > >> the exception in the bug [2] may give a clue. > > >> > > >> > > >> JamO > > >> > > >> [0] > > >> https://lists.opendaylight.org/pipermail/integration-dev/2016-June/ > > >> 00 > > >> 7073.html [1] > > >> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1no > > >> de -flow-services-lithium-redesign-only-boron > > >> [2] https://bugs.opendaylight.org/show_bug.cgi?id=6042 > > >> _______________________________________________ > > >> openflowplugin-dev mailing list > > >> [email protected] > > >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > >> > > >> > > >> ::DISCLAIMER:: > > >> ------------------------------------------------------------------- > > >> -- > > >> ------------------------------------------------------------------- > > >> -- > > >> ---------- > > >> > > >> The contents of this e-mail and any attachment(s) are confidential > > >> and > > intended for the named recipient(s) only. > > >> E-mail transmission is not guaranteed to be secure or error-free as > > information could be intercepted, corrupted, lost, destroyed, arrive > > late or incomplete, or may contain viruses in transmission. The e mail > > and its contents (with or without referred errors) shall therefore not > > attach any liability on the originator or HCL or its affiliates. > > >> Views or opinions, if any, presented in this email are solely those > > >> of the > > author and may not necessarily reflect the views or opinions of HCL or > > its affiliates. Any form of reproduction, dissemination, copying, > > disclosure, modification, distribution and / or publication of this > > message without the prior written consent of authorized representative > > of HCL is strictly prohibited. If you have received this email in > > error please delete it and notify the sender immediately. > > >> Before opening any email and/or attachments, please check them for > > >> viruses > > and other defects. > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> ------------------------------------------------------------------- > > >> -- > > >> ---------- > > >> > > >> > > >> > > >> ------------------------------ > > >> > > >> Message: 4 > > >> Date: Thu, 9 Jun 2016 16:54:22 -0700 > > >> From: Luis Gomez <[email protected]> > > >> To: controller-dev <[email protected]> > > >> Cc: "[email protected]" > > >> <[email protected]>, > > >> "[email protected]" > > >> <[email protected]>, OpenDayLight- > > L2switch-Dev > > >> <[email protected]>, > > >> "[email protected]" > > >> <[email protected]> > > >> Subject: Re: [openflowplugin-dev] CSIT troubles. > > >> > > >> openflowplugin-csit-1node-flow-services-lithium-redesign-only-boron > > >> Message-ID: <[email protected]> > > >> Content-Type: text/plain; charset="us-ascii" > > >> > > >> Hi controller dev, > > >> > > >> It seems this patch (according to CI times) broke OF he plugin > > >> topology + OF > > Li plugin topology + inventory with all the consequences in the > > downstream > > projects: > > >> > > >> https://git.opendaylight.org/gerrit/#/c/38962/ > > >> <https://git.opendaylight.org/gerrit/#/c/38962/> > > >> > > >> I see this patch is part of a larger controller merge list, so is > > >> the regression > > expected as part of some major change (e.g. Whether) or is this > > unexpected regression? > > >> > > >> BR/Luis > > >> > > >> > > >>> On Jun 9, 2016, at 4:37 PM, Venkatrangan G - ERS, HCL Tech > > <[email protected]> wrote: > > >>> > > >>> Hi, > > >>> > > >>> We are facing this with the VTN jobs as well > > >>> Reference: > > >>> https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-csit-1nod > > >>> e- > > >>> op > > >>> enstack-mitak > > >>> a-neutron-beryllium/lastSuccessfulBuild/artifact/odl1_karaf.log.tar. > > >>> xz > > >>> > > >>> From our understanding, the PACKET_IN handling is causing this. > > >>> > > >>> Regards, > > >>> Venkat G > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: [email protected] > > >>> [mailto:[email protected]] On > > >>> Behalf Of Jamo Luhrsen > > >>> Sent: Thursday, June 9, 2016 4:35 PM > > >>> To: [email protected]; > > >>> [email protected]; > > >>> OpenDayLight-L2switch-Dev <[email protected]> > > >>> Subject: [openflowplugin-dev] CSIT troubles. > > >>> openflowplugin-csit-1node-flow-services-lithium-redesign-only-boro > > >>> n > > >>> > > >>> Earlier today I pointed out [0] that l2switch had something broken > > happening, but now I think I notice it in openflowplugin CSIT [1] as > > well. This job is getting aborted as it's running for 6 hours (or > > timeout for these jobs) normally it's a 20m test. > > >>> > > >>> something serious here. > > >>> > > >>> the exception in the bug [2] may give a clue. > > >>> > > >>> > > >>> JamO > > >>> > > >>> [0] > > >>> https://lists.opendaylight.org/pipermail/integration-dev/2016-June > > >>> /0 > > >>> 07 > > >>> 073.html [1] > > >>> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1n > > >>> od > > >>> e- flow-services-lithium-redesign-only-boron > > >>> [2] https://bugs.opendaylight.org/show_bug.cgi?id=6042 > > >>> _______________________________________________ > > >>> openflowplugin-dev mailing list > > >>> [email protected] > > >>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > >>> > > >>> > > >>> ::DISCLAIMER:: > > >>> ------------------------------------------------------------------ > > >>> -- > > >>> -- > > >>> ------------------------------------------------------------------ > > >>> -- > > >>> -- > > >>> -------- > > >>> > > >>> The contents of this e-mail and any attachment(s) are confidential > > >>> and > > intended for the named recipient(s) only. > > >>> E-mail transmission is not guaranteed to be secure or error-free > > >>> as information could be intercepted, corrupted, lost, destroyed, > > >>> arrive late or incomplete, or may contain viruses in transmission. > > >>> The e mail and > > its contents (with or without referred errors) shall therefore not > > attach any liability on the originator or HCL or its affiliates. > > >>> Views or opinions, if any, presented in this email are solely > > >>> those of the author and may not necessarily reflect the views or > > >>> opinions of HCL or its affiliates. Any form of reproduction, > > >>> dissemination, copying, disclosure, modification, distribution and > > >>> / or publication of this > > message without the prior written consent of authorized representative > > of HCL is strictly prohibited. If you have received this email in > > error please delete it and notify the sender immediately. > > >>> Before opening any email and/or attachments, please check them for > > viruses and other defects. > > >>> > > >>> ------------------------------------------------------------------ > > >>> -- > > >>> -- > > >>> ------------------------------------------------------------------ > > >>> -- > > >>> -- > > >>> -------- > > >>> > > >>> _______________________________________________ > > >>> openflowplugin-dev mailing list > > >>> [email protected] > > >>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > >> > > >> -------------- next part -------------- An HTML attachment was > > >> scrubbed... > > >> URL: > > >> <http://lists.opendaylight.org/pipermail/openflowplugin-dev/attachm > > >> en ts/20160609/738058e4/attachment.html> > > >> > > >> ------------------------------ > > >> > > >> _______________________________________________ > > >> openflowplugin-dev mailing list > > >> [email protected] > > >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > >> > > >> > > >> End of openflowplugin-dev Digest, Vol 36, Issue 24 > > >> ************************************************** > > >> _______________________________________________ > > >> openflowplugin-dev mailing list > > >> [email protected] > > >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > > > > > _______________________________________________ > > > openflowplugin-dev mailing list > > > [email protected] > > > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > > > _______________________________________________ > > openflowplugin-dev mailing list > > [email protected] > > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
