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]] > Sent: Thursday, January 28, 2016 01:08 > To: Tai, Hideyuki <[email protected]>; Jamo Luhrsen > <[email protected]>; openflowplugin-dev <openflowplugin- > [email protected]> > Cc: '[email protected]' <[email protected]>; Shigeru > Yasuda <[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]> > Sent: Thursday, January 28, 2016 00:23 > To: Jamo Luhrsen; Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at > Cisco); openflowplugin-dev > Cc: '[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]] On Behalf > > Of Tai, Hideyuki > > Sent: Wednesday, January 27, 2016 10:45 > > To: Jamo Luhrsen <[email protected]>; Michal Rehak -X (mirehak - > > PANTHEON TECHNOLOGIES at Cisco) <[email protected]>; openflowplugin- > > dev <[email protected]> > > Cc: '[email protected]' <[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]] > > > Sent: Wednesday, January 27, 2016 09:29 > > > To: Tai, Hideyuki <[email protected]>; Michal Rehak -X (mirehak > > > - PANTHEON TECHNOLOGIES at Cisco) <[email protected]>; > > > openflowplugin- dev <[email protected]> > > > Cc: '[email protected]' > > > <[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]] > > > >> Sent: Wednesday, January 27, 2016 04:53 > > > >> To: Tai, Hideyuki <[email protected]>; openflowplugin-dev > > > >> <[email protected]> > > > >> Cc: '[email protected]' > > > >> <[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] > > > >> <openflowplugin- [email protected]> on behalf of > > > >> Tai, Hideyuki <[email protected]> > > > >> Sent: Wednesday, January 27, 2016 01:23 > > > >> To: openflowplugin-dev > > > >> Cc: '[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] > > > >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-de > > > >> v > > > > _______________________________________________ > > > > 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
