Hi, I think Manohar's note covers our discussion of the last meeting well. And, I agree with the design proposition.
Regards, Hideyuki Tai > -----Original Message----- > From: Manohar SL [mailto:[email protected]] > Sent: Tuesday, June 21, 2016 20:59 > To: Luis Gomez <[email protected]>; Tai, Hideyuki > <[email protected]>; [email protected]; Jozef > Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco) > <[email protected]> > Subject: RE: [openflowplugin-dev] Bug 5602 - Li Migration: Problems to detect > the removal of flow entries > > Hi All, > > If we all agree with the below mentioned design proposition, request > Abhijit/Anil > to merge the below fix by Hideyuki Tai for the Bug 5602: > https://git.opendaylight.org/gerrit/#/c/39906/3 > So, with this, we will secure the Yang Notification on OFPT_FLOW_REMOVED > message received from DPN. > > Regs, > Manohar. > > -----Original Message----- > From: Manohar SL > Sent: Friday, June 17, 2016 4:16 PM > To: 'Luis Gomez'; Tai, Hideyuki; [email protected]; > Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco) > Subject: RE: [openflowplugin-dev] Bug 5602 - Li Migration: Problems to detect > the removal of flow entries > > Hi All, > > Summary of the discussion we had in yesterday's OF PlugIn Meeting, in this > context of Flow Entry Removal handling is highlighted below. > Have also included the points mentioned in this mail thread beyond yesterday's > discussion. Please add to this, if I have missed any points discussed during > the > meeting. > => On receiving the “OFPT_FLOW_REMOVED” OF Message, Yang > Notification will be emitted by OF Li PlugIn, similar to the He PlugIn Design. > => Yang Notification will complete the functionality related to Flow > Removal message handling and is also better in performance, in terms of > detecting the flow removal by NSFs. > => Also, as per OF Spec, the FLOW_REMOVED message will be sent by > the DPN, only if the “OFPFF_SEND_FLOW_REM” flag is set in the FLOW_MOD > message > -> So, FRM might be tuned to _NOT_ set this as a default > behavior. > -> For Modules which program the Flows based on FRM and need > Flow Removed Notification, will need to trigger FRM to enable this. > => For Direct RPC based FLOW_MOD through Li Plug In, we can directly > set this flag “OFPFF_SEND_FLOW_REM”. > > On a related note, for the maintenance of Flow Entry information in OperDB > (Operational Data Store), the following is the current thought process: > => The Flow entries should be updated in OperDB independent of Stats > Module. > => Simple check for this can be, if after the window of time for which > OFPT_ERROR is expected has passed, then update OperDB with the flow entry. > => Also, on receipt of “OFPT_FLOW_REMOVED” message, as part of the > “OFPT_FLOW_REMOVED” message handling, Li PlugIn can directly remove this > flow entry from OperDB. > => So, with this approach, we can achieve the “sanctity” of the OperDB > with flow entries information, independent of Stats Module/functionality. > > Please add to this if I have missed any details. > > Regs, > Manohar SL. > > -----Original Message----- > From: Luis Gomez [mailto:[email protected]] > Sent: Friday, June 17, 2016 5:53 AM > To: Tai, Hideyuki > Cc: Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco); > [email protected]; Manohar SL > Subject: Re: [openflowplugin-dev] Bug 5602 - Li Migration: Problems to detect > the removal of flow entries > > 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-boro > >>>>> n > >>>>> 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-1n > >>>>> o 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-boro > >>>>> n > >>>>> 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-1nod > >>>>> e > >>>>> -o > >>>>> penstack-mitak > >>>>> a-neutron-beryllium/lastSuccessfulBuild/artifact/odl1_karaf.log.ta > >>>>> r > >>>>> .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-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 > >>>>> / > >>>>> 00 > >>>>> 7073.html [1] > >>>>> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1n > >>>>> o 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-boro > >>>>> n > >>>>> Message-ID: <AC59F07F-E854-4B0C-A20D- > [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-1no > >>>>>> d > >>>>>> 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-bor > >>>>>> o > >>>>>> 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-Jun > >>>>>> e > >>>>>> /0 > >>>>>> 07 > >>>>>> 073.html [1] > >>>>>> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1 > >>>>>> n > >>>>>> 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-de > >>>>>> v > >>>>>> > >>>>>> > >>>>>> ::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-de > >>>>>> v > >>>>> > >>>>> -------------- next part -------------- An HTML attachment was > >>>>> scrubbed... > >>>>> URL: > >>>>> <http://lists.opendaylight.org/pipermail/openflowplugin-dev/attach > >>>>> m 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
