Hi Muthu, Kamal,

Thanks for the clarification

Regards,
K.Kalaiselvi

From: Muthukumaran K [mailto:[email protected]]
Sent: Thursday, January 07, 2016 6:56 PM
To: K, Kalaiselvi; [email protected]
Cc: [email protected]
Subject: RE: [openflowplugin-dev] Clarification on Openflow packet notification 
to dependent plugins in a clustering environment

Hi Kalai,

>>> Isn't this approach enforcing the openflowplugin dependent apps to be 
>>> installed in all the controllers in the cluster

Ah .. so you are speaking about asymmetric cluster ? ie. packet-listener app 
can sit in a node which does not even have the OFPlugin feature installed and 
no switches connected to it (in worst case)? Not sure if this is even supported

If I dissect the requirement (unless I miread your requirement), we can treat 
"receiving packet-in" and "processing received packet-in" as two different 
functional parts, now we end up with following combos


-          "receiving packet-in" on Node 1 and "processing received packet-in" 
on Node 2 - here, there is no mechanism which "forwards" packet-in from Node 1 
to Node 2 because all packet-ins are fired by OFPlugin as yang notifs and yang 
notifs are not remote

-          "receiving packet-in" on Node 1 and "processing received packet-in" 
on Node 1 itself  - this is what is possible because yang-notifs are node-local

Hope we are in sync.

Regards
Muthu







From: 
[email protected]<mailto:[email protected]>
 [mailto:[email protected]] On Behalf Of 
[email protected]<mailto:[email protected]>
Sent: Thursday, January 07, 2016 3:24 PM
To: [email protected]<mailto:[email protected]>
Cc: 
[email protected]<mailto:[email protected]>
Subject: Re: [openflowplugin-dev] Clarification on Openflow packet notification 
to dependent plugins in a clustering environment

Hi Kamal,

What I infer from below is, the openflowplugin dependent app has to determine 
which controller node is the master for each of the ovs switches connected to 
the cluster setup
and based on the openflowplugin mastership my app has also perform the 
distributed mastership across multiple switches as packet-in notifications are 
local to the controller node.

Isn't this approach enforcing the openflowplugin dependent apps to be installed 
in all the controllers in the cluster
and their cluster-awareness cannot support the strategy of having a single 
master instance for all ovs-switches connected in the cluster.

Regards,
K.Kalaiselvi

From: Kamal Rameshan (kramesha) [mailto:[email protected]]
Sent: Wednesday, January 06, 2016 11:31 PM
To: K, Kalaiselvi; Muthukumaran K; 
[email protected]<mailto:[email protected]>
Subject: Re: [openflowplugin-dev] Clarification on Openflow packet notification 
to dependent plugins in a clustering environment

Hi Kalaiselvi,

There is an entity-ownership service in the controller. OFP uses that to 
determine ownership. Your app which resides in all the nodes can attach a 
listener to the EOS and get an ownership change event for an entity and 
determine which node is the owner/master of the OF entity, if needed.

But as muthu suggested, you need to do all this just to get packet-ins, as yang 
notifications are local.

-kamal

From: 
<[email protected]<mailto:[email protected]>>
 on behalf of "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Wednesday, January 6, 2016 at 3:51 AM
To: Muthukumaran K 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>"
 
<[email protected]<mailto:[email protected]>>
Subject: Re: [openflowplugin-dev] Clarification on Openflow packet notification 
to dependent plugins in a clustering environment

Hi Muthu,

The slave instances of the openflowplugin in the controller nodes sends a 
Openflow Role Request message with its role as Slave.
By the OF Spec, the packet-ins are sent only to the controller that have master 
or equal role.
So in our case, the packet-in messages are sent over only to the master 
openflowplugin instance and not all the controller nodes

Regards,
K.Kalaiselvi

From: Muthukumaran K [mailto:[email protected]]
Sent: Wednesday, January 06, 2016 3:54 PM
To: K, Kalaiselvi; 
[email protected]<mailto:[email protected]>
Subject: RE: [openflowplugin-dev] Clarification on Openflow packet notification 
to dependent plugins in a clustering environment

Hi Kalai,

>>> And only the openflowplugin master for a switch will receive the packets
How so ? There is no indication from OF Spec (1.3.1 Section 6.3.4 is what I 
referred) that switches can send the packet-ins only to one of 3 controllers 
(assuming 3-node cluster). So, it can potentially be a spray depending upon 
switch implementation

Assuming that we have symmetric cluster - all features run on all nodes, any 
"packet-listening" feature instances across cluster nodes can get the 
notification since yang notifications are node-local.

Regards
Muthu


From:[email protected]<mailto:[email protected]>
 [mailto:[email protected]] On Behalf Of 
[email protected]<mailto:[email protected]>
Sent: Wednesday, January 06, 2016 2:44 PM
To: 
[email protected]<mailto:[email protected]>
Subject: [openflowplugin-dev] Clarification on Openflow packet notification to 
dependent plugins in a clustering environment

Hi,

In the openflowplugin, the packets received from the switches connected to the 
controller are notified to their dependent plugins through yang notifications.
In the a clustering environment, multiple controller nodes can be the master 
for the switches connected.
And only the openflowplugin master for a switch will receive the packets and 
notify them to the openflowplugin dependent feature  instance co-located in 
that controller node.
So for a dependent feature to be cluster aware should it be tied to 
openflowplugin master?
Or are there any other mechanism (like packet reception through Data change 
notifications) available so that the dependent feature can be universal master 
across all the cluster nodes


Regards,
K.Kalaiselvi

_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to