Yes, so i think lets stick with it. On Tue, Feb 23, 2016 at 10:33 PM, Muthukumaran K < [email protected]> wrote:
> That’s exactly what our preliminary tests indicate – local RPC far better > in flow-rate than routed RPC for performance J > > Local RPC usage is also more stable under HA scenarios like switch reboots > > > > Regards > > Muthu > > > > > > *From:* Anil Vishnoi [mailto:[email protected]] > *Sent:* Wednesday, February 24, 2016 11:27 AM > > *To:* Muthukumaran K > *Cc:* Shuva Jyoti Kar; [email protected] > *Subject:* Re: [openflowplugin-dev] OF HA sequence of Events > > > > In my personal opinion, i think having local RPC will give us better > performance, compared to routed rpc, so sticking with local rpc is better > option, what do you think? > > > > Thanks > > Anil > > > > On Tue, Feb 23, 2016 at 8:06 PM, Muthukumaran K < > [email protected]> wrote: > > Thanks Anil. > > I think, until routed RPC gossip propagation and perhaps RPC-call > serialization aspects improve, local-RPC can remain as norm for FRM and > Recon code. > > > > *From:* Anil Vishnoi [mailto:[email protected]] > *Sent:* Wednesday, February 24, 2016 12:36 AM > *To:* Shuva Jyoti Kar > *Cc:* Muthukumaran K; [email protected] > > > *Subject:* Re: [openflowplugin-dev] OF HA sequence of Events > > > > Operational DS update happens after (6.1), so all applications get node > added notification after (6.1). So ideally applications should not call any > RPC before (6), given that they don't really know that node is yet > connected to the controller. > > We register the routed RPC earlier at the moment so that in clustered mode > we can publish it as soon as possible, but given that we now moved to local > rpc implementation, we don't really need that. > > > > On Tue, Feb 23, 2016 at 4:02 AM, Shuva Jyoti Kar < > [email protected]> wrote: > > So Oper DS Update happens after 6.1 is it ? If it happens any earlier that > 6.1 and applications use rpc between 3.1 and 6.1 what is the behavior, as > there is a level of uncertainty as to the who owns it. > > > > Thanks > > Shuva > > > > *From:* Anil Vishnoi [mailto:[email protected]] > *Sent:* Tuesday, February 23, 2016 4:21 PM > *To:* Muthukumaran K > *Cc:* Shuva Jyoti Kar; [email protected] > > > *Subject:* Re: [openflowplugin-dev] OF HA sequence of Events > > > > sorry missed that one > > > > 1) Openflowplugin receives the switch connection > > 2) plugin register that controller as a candidate for device ownership > with EOS > > 3) Plugin fetch the current ownership state of the device, if it does not > get the ownership it doesn't do anything, if it gets the ownership state > and EOS give ownership to that controller, > > *3.1) Register Routed RPCs* > > 4) It's sends the master role to the switch else it will send slave role > to the switch > > 5) Once master role is set, it will send nodeAdded() yang notification to > the application > > 6) If master role setting fails,it de-register the candidate for device > ownership, so that anyone else can get EOS ownership and it can try for the > master role setting. > > *6.1) Also deregister the router rpc as well* > > > > On Tue, Feb 23, 2016 at 12:09 AM, Muthukumaran K < > [email protected]> wrote: > > So, Routed-RPC-Registration step followed by Oper DS Update step happen > after this ? > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Anil > Vishnoi > *Sent:* Tuesday, February 23, 2016 5:15 AM > *To:* Shuva Jyoti Kar > *Cc:* [email protected] > *Subject:* Re: [openflowplugin-dev] OF HA sequence of Events > > > > In Helium plugin, this is how it goes > > > > 1) Openflowplugin receives the switch connection > > 2) plugin register that controller as a candidate for device ownership > with EOS > > 3) Plugin fetch the current ownership state of the device, if it does not > get the ownership it doesn't do anything, if it gets the ownership state > and EOS give ownership to that controller, > > 4) It's sends the master role to the switch else it will send slave role > to the switch > > 5) Once master role is set, it will send nodeAdded() yang notification to > the application > > 6) If master role setting fails,it de-register the candidate for device > ownership, so that anyone else can get EOS ownership and it can try for the > master role setting. > > > > On Mon, Feb 22, 2016 at 10:11 AM, Shuva Jyoti Kar < > [email protected]> wrote: > > Hi Anil/Kamal, > > > > What are the exact sequence of events between EOS receiving a switch > connection and the switch data being populated in the Oper DS ? > > > > Thanks > > Shuva > > > > > > -- > > Thanks > > Anil > > > > > > -- > > Thanks > > Anil > > > > > > -- > > Thanks > > Anil > > > > > > -- > > Thanks > > Anil > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
