Hi Abhijit,

VTN project needs the "get-flow-statistics-from-flow-table" RPC by default in 
the OpenFlow Plugin Lithium design.

To make it easy to track this, I've just filed a report in the Bugzilla.
https://bugs.opendaylight.org/show_bug.cgi?id=5432

In addition to that, the following two bugs are need to be fixed.
https://bugs.opendaylight.org/show_bug.cgi?id=5328
https://bugs.opendaylight.org/show_bug.cgi?id=4671

Best Regards,
Hideyuki Tai

From: Abhijit Kumbhare [mailto:[email protected]]
Sent: Sunday, February 28, 2016 19:04
To: Tai, Hideyuki <[email protected]>
Cc: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco) 
<[email protected]>; openflowplugin-dev 
<[email protected]>; [email protected]; 
Shigeru Yasuda <[email protected]>
Subject: Re: [openflowplugin-dev] Request for the stats RPC in the OFP-Li

So Hideyuki/Michal - the change you have done to support the Li design - what 
does it use? Using DS/operational stats? Stats RPC enabled by default?

On Wed, Feb 3, 2016 at 1:01 PM, Tai, Hideyuki 
<[email protected]<mailto:[email protected]>> wrote:
Hi Michal,

Thank you for your great explanation.
I think I understand the situation correctly.

*If* VTN project needs to migrate the OFP-Li by Beryllium Stable Release 1 or 
2, I would like the OFP project to enable the RPC by default.

For Boron, VTN project plans to support clustering.
Therefore, I think VTN project would need the future straight stats RPC for 
Boron.

Regards,
Hideyuki Tai

> -----Original Message-----
> From: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)
> [mailto:[email protected]<mailto:[email protected]>]
> Sent: Thursday, January 28, 2016 01:08
> To: Tai, Hideyuki <[email protected]<mailto:[email protected]>>; 
> Jamo Luhrsen
> <[email protected]<mailto:[email protected]>>; openflowplugin-dev 
> <openflowplugin-
> [email protected]<mailto:[email protected]>>
> Cc: '[email protected]<mailto:[email protected]>' 
> <[email protected]<mailto:[email protected]>>; 
> Shigeru
> Yasuda <[email protected]<mailto:[email protected]>>
> Subject: Re: [openflowplugin-dev] Request for the stats RPC in the OFP-Li
>
> Hi all,
> compatibility stats rpc implementations in Li do not use cached values in DS 
> but
> query device instead.
> Reason why it is not enabled by default is that it works similar to He-
> implementation. It returns xid and later upon reply from device arrives there 
> is
> md-sal notification (containing stats data) published. This introduces an
> unnecessary performance penalty.
> There was plan to add a straight implementation for this purpose and simply
> returning future result with stats data inside. Probably with optional side 
> effect
> of updating corresponding DS/operational stats.
>
> Now back to controlling of this compatibility rpcs - it is easy for single 
> node. But
> not in cluster.
> Rpcs are registered and unregistered upon entity ownership (role) change which
> lives per device. Currently available channel (I know of + available right 
> away)
> capable of distributing data among all nodes regardless ownership state is DS.
> So we would need to design a tiny augmentation defining a boolean leaf under
> flowCapableNode node. And a DS-listener which will propagate this value to
> particular service and if active (LEADER role) then alter running service.
> Otherwise change flag in order to alter next rpc registration processing.
>
> As I look at this summary of work needed I think it makes more sense to
> cowardly give up on Li-design purity for Be release and enable it by default. 
> But
> only in Be. Would this be acceptable for VTN? I mean there is a plan for VTN 
> to :
>  - either use DS/operational stats (this is probably unacceptable)
>  - or cycles reserved for adapting VTN for future straight stats rpcs right?
>
>
> Regards,
> Michal
>
> ________________________________________
> From: Tai, Hideyuki <[email protected]<mailto:[email protected]>>
> Sent: Thursday, January 28, 2016 00:23
> To: Jamo Luhrsen; Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at
> Cisco); openflowplugin-dev
> Cc: '[email protected]<mailto:[email protected]>'; 
> Shigeru Yasuda
> Subject: RE: [openflowplugin-dev] Request for the stats RPC in the OFP-Li
>
> Please let me explain what VTN project needs from the OFP-Lithium more
> precisely.
>
> VTN project needs a way to get latest information about flow entries in
> OpenFlow switches.
> Should I file this into the Bugzilla?
>
> With the OFP-Helium, VTN project can use the "get-flow-statistics-from-flow-
> table" RPC for this purpose.
> On the "get-flow-statistics-from-flow-table" RPC, the OFP-Helium sends
> OFPT_STATS_REQUEST messages to an OpenFlow switch, if I understand
> correctly, so VTN project's features can get the latest information.
>
> There are two use cases for the RPC.
> First, the VTN features need this RPC to correctly control OpenFlow switches.
> When an ODL controller in which the VTN features runs newly connects with an
> OpenFlow 1.0 switch, the VTN features check flow entries in the switch by
> calling the RPC.
> And if the VTN features find flow entries which are not necessary, it deletes 
> the
> entries to avoid causing unexpected behaviors.
> For OpenFlow 1.3 switches, the VTN features do not need the "get-flow-..." 
> RPC,
> because it can delete all entries using cookie mask without knowing flow 
> entries
> in switches.
> But, OpenFlow 1.0 switch does not support the cookie mask, so the RPC is
> needed.
> Second, the VTN features need the "get-flow-..." RPC to show statistics of 
> flows
> to users.
> (The vtn-flows:get-data-flow RPC provides that functionality to users.) That's
> why the VTN features need a way to get latest flow entries in the OFP-Lithium.
>
> Regards,
> Hideyuki Tai
>
> > -----Original Message-----
> > From: 
> > [email protected]<mailto:[email protected]>
> > [mailto:[email protected]<mailto:[email protected]>]
> >  On Behalf
> > Of Tai, Hideyuki
> > Sent: Wednesday, January 27, 2016 10:45
> > To: Jamo Luhrsen <[email protected]<mailto:[email protected]>>; Michal 
> > Rehak -X (mirehak -
> > PANTHEON TECHNOLOGIES at Cisco) 
> > <[email protected]<mailto:[email protected]>>; openflowplugin-
> > dev 
> > <[email protected]<mailto:[email protected]>>
> > Cc: '[email protected]<mailto:[email protected]>' 
> > <[email protected]<mailto:[email protected]>>
> > Subject: Re: [openflowplugin-dev] Request for the stats RPC in the
> > OFP-Li
> >
> > Hi Jamo,
> >
> > > Hideyuki,
> > >
> > > if it was enabled by default, does that solve your problem for now?
> >
> > Yes.
> > If it is enabled by default, that solves the critical problem which
> > VTN project are facing with the OFP-Li.
> > Actually, that's the biggest problem for VTN.
> > If it's enabled by default today and there are no other critical bugs
> > in the OFP-Li, we can say it is not impossible to migrate to the OFP-Li by
> Beryllium RC3.
> >
> > Anyway, we need more time to test the OFP-Li to detect bugs before the
> > migration.
> > Especially, we are still not sure why installing and uninstalling flow
> > entries is so slow with OFP-Li.
> >
> > FYI, now VTN project is busy to test the VTN project's feature with the OFP-
> He.
> > As you know, the OFP-He also has some issues, and we want all issues
> > in OFP- He are fixed by Beryllium release.
> >
> > Regards,
> > Hideyuki Tai
> >
> > > -----Original Message-----
> > > From: Jamo Luhrsen [mailto:[email protected]<mailto:[email protected]>]
> > > Sent: Wednesday, January 27, 2016 09:29
> > > To: Tai, Hideyuki 
> > > <[email protected]<mailto:[email protected]>>; Michal Rehak -X 
> > > (mirehak
> > > - PANTHEON TECHNOLOGIES at Cisco) 
> > > <[email protected]<mailto:[email protected]>>;
> > > openflowplugin- dev 
> > > <[email protected]<mailto:[email protected]>>
> > > Cc: 
> > > '[email protected]<mailto:[email protected]>'
> > > <[email protected]<mailto:[email protected]>>
> > > Subject: Re: [openflowplugin-dev] Request for the stats RPC in the
> > > OFP-Li
> > >
> > > Michal,
> > >
> > > Is it undesirable to have these rpc's enabled by default?
> > >
> > > Hideyuki,
> > >
> > > if it was enabled by default, does that solve your problem for now?
> > >
> > > JamO
> > >
> > > On 01/27/2016 09:21 AM, Tai, Hideyuki wrote:
> > > > Hi Michal,
> > > >
> > > > Thank you for your response!
> > > >
> > > > We know we can enable the RPC by changing the configuration file
> > > > of the
> > > ofplugin-li.
> > > >
> > > > However, it is difficult for VTN project to accept the migration
> > > > to the OFP-Li
> > > with this way.
> > > > In this way, to use VTN project's features, user need to manually
> > > > stop the
> > > controller, change the configuration file manually, and start the
> > > controller
> > again.
> > > > And, I don't think there is a way to enable the RPC in runtime.
> > > >
> > > > Therefore, we would like your team to provide the
> > > > "get-flow-statistics-from-
> > > flow-table" RPC by default in the OFP-Li.
> > > > Or we would like your team to provide applications (e.g. VTN
> > > > project's
> > > features) with a way to enable the RPC in runtime.
> > > >
> > > > Regards,
> > > > Hideyuki Tai
> > > >
> > > >> -----Original Message-----
> > > >> From: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)
> > > >> [mailto:[email protected]<mailto:[email protected]>]
> > > >> Sent: Wednesday, January 27, 2016 04:53
> > > >> To: Tai, Hideyuki 
> > > >> <[email protected]<mailto:[email protected]>>; 
> > > >> openflowplugin-dev
> > > >> <[email protected]<mailto:[email protected]>>
> > > >> Cc: 
> > > >> '[email protected]<mailto:[email protected]>'
> > > >> <[email protected]<mailto:[email protected]>>
> > > >> Subject: Re: Request for the stats RPC in the OFP-Li
> > > >>
> > > >> Hi Hideyuki,
> > > >> could you test with this parameter (is-statistics-rpc-enabled)
> > > >> added to ofplugin- li configuration, e.g.:
> > > >>
> > > >>
> > > >>
> > > >> <switch-features-mandatory>false</switch-features-
> > > mandatory>
> > > >>
> > > >> <global-notification-quota>64000</global-notification-
> > quota>
> > > >>                     
> > > >> <is-statistics-polling-off>false</is-statistics-polling-off>
> > > >>                     <is-statistics-rpc-enabled>true</is-statistics-rpc-
> enabled>
> > > >>                 </module>
> > > >>             </modules>
> > > >>
> > > >>
> > > >> Regards,
> > > >> Michal
> > > >>
> > > >> ________________________________________
> > > >> From: 
> > > >> [email protected]<mailto:[email protected]>
> > > >> <openflowplugin- 
> > > >> [email protected]<mailto:[email protected]>>
> > > >>  on behalf of
> > > >> Tai, Hideyuki <[email protected]<mailto:[email protected]>>
> > > >> Sent: Wednesday, January 27, 2016 01:23
> > > >> To: openflowplugin-dev
> > > >> Cc: 
> > > >> '[email protected]<mailto:[email protected]>'
> > > >> Subject: [openflowplugin-dev] Request for the stats RPC in the
> > > >> OFP-Li
> > > >>
> > > >> Hi OpenFlow Plugin project,
> > > >>
> > > >> Here is a request from VTN project.
> > > >>
> > > >> Could you make the OpenFlow Plugin Lithium design provide the RPC
> > > >> for statistics?
> > > >> To be more precise, VTN project needs the
> > > >> "get-flow-statistics-from-flow-
> > > table"
> > > >> RPC modeled in "opendaylight-flow-statistics.yang".
> > > >> The RPC is available in the Helium design, but not available by
> > > >> default by Lithium design.
> > > >>
> > > >> In our understanding, RPCs for statistics are deprecated in the
> > > >> OpenFlow Plugin Lithium design, and the RPCs are not incorporated
> > > >> by
> > > default.
> > > >> There is no way to enable the RPCs for statistics in runtime.
> > > >>
> > > >> At this time, VTN project uses the OpenFlow Plugin Helium design
> > > >> in the stable/beryllium branch.
> > > >> Now, we would like to start the preparation for the migration to
> > > >> the Lithium design.
> > > >> To migrate to the Lithium design, we need the Lithium design
> > > >> provide either;
> > > >>  - Provide the "get-flow-statistics-from-flow-table" RPC by default.
> > > >> or
> > > >>  - Provide the VTN project with a way to enable the RPC in runtime.
> > > >>
> > > >> VTN project needs the "get-flow-statistics-from-flow-table" RPC
> > > >> to get information of all flow entries in OpenFlow switches.
> > > >>
> > > >> Best Regards,
> > > >> Hideyuki Tai
> > > >> _______________________________________________
> > > >> openflowplugin-dev mailing list
> > > >> [email protected]<mailto:[email protected]>
> > > >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-de
> > > >> v
> > > > _______________________________________________
> > > > openflowplugin-dev mailing list
> > > > [email protected]<mailto:[email protected]>
> > > > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
> > > >
> > _______________________________________________
> > openflowplugin-dev mailing list
> > [email protected]<mailto:[email protected]>
> > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________
openflowplugin-dev mailing list
[email protected]<mailto:[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... Tai, Hideyuki
    • Re: [openf... Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)
      • Re: [o... Tai, Hideyuki
        • Re... Jamo Luhrsen
          • ... Tai, Hideyuki
            • ... Tai, Hideyuki
              • ... Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)
                • ... Tai, Hideyuki
                • ... Abhijit Kumbhare
                • ... Tai, Hideyuki
                • ... Abhijit Kumbhare

Reply via email to