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: <[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
