Fair point Hideyuki, if as you say there is no or very low perf impact for applications not using FLOW_REMOVED notifications, we should have this feature ALWAYS available and: 1) document any perf impact for those willing to use these notifications and 2) set FRM (if not done yet) to send SEND_FLOW_REM flag OFF by default.
> On Jun 16, 2016, at 3:29 PM, Tai, Hideyuki <[email protected]> wrote: > > 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
