Thanks Jozef for your inputs.

Maybe a common module needs to be written which can handle this scenario
instead of every application module handling on their own.

 

Anymore inputs from others? Or else for time being, I will handle this in
security groups module itself.

 

Thanks,

Somashekar

 

From: Jozef Bacigál [mailto:jozef.baci...@pantheon.tech] 
Sent: Friday, October 7, 2016 3:58 PM
To: Somashekar B <somasheka...@altencalsoftlabs.com>;
netvirt-...@lists.opendaylight.org;
openflowplugin-dev@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] Need inputs on handling deletion of flows
which have common attributes

 

Hi Somashekar,

 

from Plugin POV it is quite impossible to handle this use case without a
performance impact. On the device you can't store two identical flows and
you can't store flow id as you mentioned below. But the plugins
reconciliation working on change event so if you delete one flow on
configuration it will be deleted on switch and reconciliation won't start
check all configuration unless you disconnect device. So yes, it would be
better approach to handle this use case from the application side instead to
let the plugin always check everything on each event.

 

Jozef

 

From: Somashekar B [mailto:somasheka...@altencalsoftlabs.com] 
Sent: Thursday, October 6, 2016 1:09 PM
To: netvirt-...@lists.opendaylight.org
<mailto:netvirt-...@lists.opendaylight.org> ;
openflowplugin-dev@lists.opendaylight.org
<mailto:openflowplugin-dev@lists.opendaylight.org> 
Subject: [openflowplugin-dev] Need inputs on handling deletion of flows
which have common attributes

 

Hi All,

 

I am looking for all your inputs for the below issue.

 

Issue: Create multiple flows with different flowId, keeping rest of the
attributes same.

In this case, there will be multiple flow entries in config DS, but a single
flow on the switch.

When we delete one of this overlapping flow, flow gets deleted on the
switch.

 

Use case:

 

We can associate multiple security groups to a VM from Openstack. 

Each rule in the security group (SG) generally gets translated to a flow in
one of the ACL tables (41/252) based on the direction (ingress/egress).

Let's say we create multiple SGs having few overlapping rules (highlighted
in yellow) among each other like below:

 

| sg1     | ingress, IPv4, 22/tcp, remote_ip_prefix: 20.20.20.0/24
|

|            | ingress, IPv4, icmp, remote_ip_prefix: 20.20.20.0/24
|

| sg2     | ingress, IPv4, 22/tcp, remote_ip_prefix: 20.20.20.0/24
|

 

 

When we associate both SGs (sg1 and sg2) to a VM, ACL module creates three
flow entries totally in config DS. 

For the above two overlapping rules, two flow entries are created in config
DS with different flowId, rest all the other attributes remains same.

This would result in a single flow on the switch as flowId is not a flow
attribute on the switch.

 

cookie=0x6900000, duration=11.895s, table=252, n_packets=0, n_bytes=0,
priority=61010,ct_state=+new+trk,tcp,metadata=0x10000000000/0x1fffff00000000
00,nw_src=20.20.20.0/24,tp_dst=22
actions=ct(commit,zone=5000),resubmit(,220)

cookie=0x6900000, duration=75.237s, table=252, n_packets=0, n_bytes=0,
priority=61010,ct_state=+new+trk,icmp,metadata=0x10000000000/0x1fffff0000000
000,nw_src=20.20.20.0/24 actions=ct(commit,zone=5000),resubmit(,220)

 

Problem arises when we dissociate one of the SGs (let's say, sg2) from the
VM. In this case, we delete one of the overlapping flow from config DS.

This would result in deletion of flow from the switch. Even though there is
another flow entry (having same data with different flow ID) in the config
DS, this flow gets deleted from the switch.

This is how we generally handle all DCN/DTCN.

 

This is a common problem which might occur in other situations as well.

 

Question is how to handle this kind of scenario?

Which module should handle this? Plugin or applications?

 

In case, if we need to handle it from the applications side, we could think
of below option:

 

1.       When adding a flow to config DS,

a.       Construct the flow id using the match criteria which would generate
same flow ID for all the overlapping rules. So that only one flow will be
created for all overlapping rules.

b.       With the constructed flowId, query config DS to check if flow
already exists. 

                                                               i.      If
no, add this flow with flow name something like: ACL-<counter>. Counter
would signify the number of overlapping flows configured.

                                                             ii.      If
yes,  update the flow name by incrementing the counter. Eg: ACL-2

2.       In case of deleting flow from config DS,

a.       Construct the flow ID as mentioned in 1.a

b.        With the constructed flowId, query config DS to check if flow
already exists.

                                                               i.      If
no, ignore.

                                                             ii.      If
yes,  check the counter value in the flow name (ACL-2), if its value is 1,
delete the flow else decrement the counter and update the flow in config DS.

 

Cons of this approach: 

                One additional read call to config DS during
addition/deletion of every flow.

 

Please share your thoughts to handle it optimally. 

 

 

Thanks,

Somashekar

JozefBacigál

Software Engineer


Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum / Janka Kráľa 9 /  974 01 Banská Bystrica / Slovakia
+421 908 766 972 / jozef.baci...@pantheon.tech
<mailto:jozef.baci...@pantheon.tech> 
reception: +421 2 206 65 114 / www.pantheon.sk <http://www.pantheon.sk> 

  <http://www.pantheon.sk/fileadmin/templates/img/logo.png> 

 

_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to