Re: [openflowplugin-dev] [netvirt-dev] Need inputs on handling deletion of flows which have common attributes

2016-10-18 Thread Somashekar B
As Daya suggested, I will be using single priority per SG to handle this issue 
in Boron.

Sequencing at SG level and SR level needs to be handled later.

 

Thanks,

Somashekar

 

 

From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Aswin 
Suryanarayanan
Sent: Monday, October 17, 2016 12:59 PM
To: Dayavanti Gopal Kamath 
Cc: jozef.baci...@pantheon.tech; openflowplugin-dev@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] [openflowplugin-dev] Need inputs on handling 
deletion of flows which have common attributes

 

Daya,

The priorities of flows need not be across the tenant space I think  as there 
will not be any successful match in Tenant A SG rules for Tenant B traffic. So 
to make it deterministic it will be sufficient if we make the priories of SG/SR 
different with in a tenant and thus we can reuse the priority  values across 
tenants . 

But I am not sure about the real world numbers. If 255 group and 255 rules are 
too low within a tenant, then as you mentioned we think of solving the Som's 
issue first by making use of SG priority for group now.

Vishal

We delete rules individually now, and having a cookie per group should help us 
in deleting all the rules in a group with a single request. We can do this an 
optimization, but this will not help us in making the implementation 
deterministic right? Am I missing anything?

Thanks

Aswin 

 

On Sun, Oct 16, 2016 at 4:01 PM, Dayavanti Gopal Kamath 
 > wrote:

Hi vishal,

Probably too advanced at this point to get quota params for each tenant, also I 
don’t think we can do much with them. since the priorities of the flows are 
across tenant space, we can only have 1 such limit, total number of groups 
across all tenants, and max number of rules per group across all groups. 
however, priority is only 16 bits, if we split up the space in half, we get 255 
rules per group, and 255 groups, which seems way too less number of groups. We 
probably have to limit to about 31 rules per group, and a total of 2k groups.  
This is also a bit low, anyone has ideas on typical deployment numbers? 

 

I’m re-thinking if prio space should be used for both, from a scale perspective.

Alternatively, just do unordered list within groups, and add a single priority 
per group. Then we support ordered lists whenever such a contract is needed 
from the NB separately. This will still solve som’s original problem.

 

Thanks,

daya

 

From: Vishal Thapar 
Sent: Saturday, October 15, 2016 1:50 PM
To: Aswin Suryanarayanan  >; 
Dayavanti Gopal Kamath  >
Cc: jozef.baci...@pantheon.tech  ; 
openflowplugin-dev@lists.opendaylight.org 
 ; 
netvirt-...@lists.opendaylight.org  


Subject: RE: [netvirt-dev] [openflowplugin-dev] Need inputs on handling 
deletion of flows which have common attributes

 

Hi Aswin,

 

Yes, We can leverage IdManager for this, by creating a pool for every SG and 
getting Ids for individual SRs.

 

Limits on no. of SGs per project and SRs per SGs are configurable parameters. 
If we can figure out a way to get this information from neutron conf files, it 
would make it a better solution. [1]

 

I would still prefer considering cookies as a means to identify which flows to 
delete. I might be remembering incorrectly but I believe it performs faster 
because of smaller match [cookie field only] and wildcard support means we can 
add bulk deletes like ‘delete all flows for SG1’ or ‘delete all flows of tenant 
T1’.

 

Regards,

Vishal.

 

[1] 
http://docs.openstack.org/admin-guide/cli-networking-advanced-quotas.html#basic-quota-configuration

 

From: netvirt-dev-boun...@lists.opendaylight.org 
  
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Aswin 
Suryanarayanan
Sent: 14 October 2016 19:08
To: Dayavanti Gopal Kamath  >
Cc: jozef.baci...@pantheon.tech  ; 
openflowplugin-dev@lists.opendaylight.org 
 ; 
netvirt-...@lists.opendaylight.org  
Subject: Re: [netvirt-dev] [openflowplugin-dev] Need inputs on handling 
deletion of flows which have common attributes

 

Daya,

Yes having different set of priority for SG and SR was my thought as well. Do 
the ID manager or any component in genius can help in creating these priorities 
?. I think we need think of making these changes in the NeutronVpnListener side 

Re: [openflowplugin-dev] Use case for gathering all Flow statistics

2016-10-18 Thread Shuva Jyoti Kar
Hi Scott,

Yes it is implemented, but not documented in a wiki. I could assist you  with a 
couple of pointers to help you get started.

Please take a look at the StatisticsManagerImpl.java
(./openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/statistics/StatisticsManagerImpl.java)

And on onContextInstantiateService( in StatisticsContextImpl) we schedule the 
polling of statistics in regular intervals . 
The StatisticsContextImpl and the StatisticsGatheringUtils contain the required 
logic for collection of flow stats.

Thanks
Shuva

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Scott 
Kristjanson
Sent: Tuesday, October 18, 2016 5:40 AM
To: openflowplugin-dev@lists.opendaylight.org
Subject: [openflowplugin-dev] Use case for gathering all Flow statistics

Do you have a documented use-case or message sequence chart that shows how 
statistics polling works for gathering all the flow stats on a switch from the 
ODL controller?
I would like to implement it, following the standard use case if it exists.

I am interested in gathering flow statistics for all flows on all the openflow 
SDN switches connected to the controller.

Thanks for any help you can provide!
Scott
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev


Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis

2016-10-18 Thread Luis Gomez
There are definitely weird things going on in l2switch, the first ERROR you 
mention produces some weird flow (no match and no action) in the switch:

 Flow 55:
"cookie": 3098476543630901303,
"flags": "",
"hard-timeout": 0,
"id": "55",
"idle-timeout": 0,
"match": {},
"opendaylight-flow-statistics:flow-statistics": {
"byte-count": 0,
"duration": {
"nanosecond": 23900,
"second": 36
},
"packet-count": 0
},
"priority": 0,
"table_id": 0


The second issue, I am not sure what is the impact but definitely something to 
look at.

I think in general we will need l2switch support to troubleshoot and progress 
in current issues.

BR/Luis
 

> On Oct 17, 2016, at 8:09 AM, Miroslav Macko  
> wrote:
> 
> Hello Luis and dev guys,
> 
> There is this info from l2-switch in the karaf log:
> 
> 2016-10-14 22:43:24,941 | INFO  | pool-16-thread-1 | FlowWriterServiceImpl
> | 229 - org.opendaylight.l2switch.main.impl - 0.5.0.SNAPSHOT | In 
> addMacToMacFlowsUsingShortestPath: No flows added. Source and Destination 
> ports are same.
> 
> Is it ok?
> 
> And this debug message(it has incorrect severity):
> 
> 2016-10-14 22:43:55,282 | ERROR | entLoopGroup-5-3 | DeviceFlowRegistryImpl   
> | 210 - org.opendaylight.openflowplugin.impl - 0.4.0.SNAPSHOT | Flow 
> with flowId 85 already exists in table 0
> 
> So it looks like that flows with the same ID are added.
> 
> What in short these failing tests are doing and what it should test please?
> 
> Thanks,
> Miro
> 
> 
> Od: Luis Gomez 
> Odoslané: 15. októbra 2016 1:01
> Komu: Tomáš Slušný
> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis
> 
> No luck :), still fails on "address tracker" and "loop remover":
> 
> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/154/
> https://logs.opendaylight.org/releng/jenkins092/l2switch-csit-1node-switch-only-carbon/154/archives/log.html.gz
> 
> BR/Luis
> 
> 
>> On Oct 14, 2016, at 2:26 PM, Luis Gomez  wrote:
>> 
>> OK Tomas, I will try your patch 
>> https://git.opendaylight.org/gerrit/#/c/46390/ on 
>> l2switch-csit-1node-switch-only-carbon and let you know.
>> 
>> 
>>> On Oct 14, 2016, at 1:23 PM, Tomáš Slušný  
>>> wrote:
>>> 
>>> Also, 6710 was already merged only in master branch, but not yet in boron. 
>>> It have cherry-pick ready here: 
>>> https://git.opendaylight.org/gerrit/#/c/46761/, but until it is merged, I 
>>> think it would be better to check for improvement in Jenkins test for 
>>> Carbon here: 
>>> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/
>>> Od: Tomáš Slušný 
>>> Odoslané: 14. októbra 2016 22:13
>>> Komu: Luis Gomez; Abhijit Kumbhare
>>> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
>>> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis
>>> 
>>> ​6710 was related to both cluster and single node, because even in single 
>>> node scenario, we are registering to ClusterSingletonService, what had 
>>> problems when we tried to re-register, when we do not fully closed previous 
>>> registration (so, when we disconnected and reconnected too fast). Most part 
>>> of this fix was done in bug 6710, but part of it had to be done also in 
>>> openflowplugin side in this gerrit patch: 
>>> https://git.opendaylight.org/gerrit/#/c/46390/​. So, Luis, is it possible 
>>> to run failing l2switch test on that patch and see, if it solves anything, 
>>> or not?
>>> 
>>> Od: Luis Gomez 
>>> Odoslané: 14. októbra 2016 21:49
>>> Komu: Abhijit Kumbhare
>>> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
>>> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis
>>> 
>>> Well I think if openflowplugin people cannot figure out where the issue is, 
>>> the next would be to get some debug and further analysis from l2switch 
>>> people explaining the application miss-behavior.
>>> 
>>> If there are no people available in l2switch to do this, we can lower the 
>>> priority to major or critical.
>>> 
>>> BR/Luis
>>> 
>>> 
 On Oct 14, 2016, at 12:35 PM, Luis Gomez  wrote:
 
 As far as I can tell nothing we have done so far has helped l2switch test, 
 it is still failing.
 
 BR/Luis
 
> On Oct 14, 2016, at 9:53 AM, Abhijit Kumbhare  
> wrote:
> 
> About the first one - https://bugs.opendaylight.org/show_bug.cgi?id=6575:
> 
> 

Re: [openflowplugin-dev] Blocker BUG-6956 reported in Boron

2016-10-18 Thread Alexis de Talhouët
I updated the BUG with current analysis: 
https://bugs.opendaylight.org/show_bug.cgi?id=6956#c5 


And I submitted some patches to fix it: 
https://git.opendaylight.org/gerrit/#/q/topic:bug/6956 


Thanks,
Alexis
> On Oct 18, 2016, at 1:06 PM, Abhijit Kumbhare  wrote:
> 
> Adding L2 switch, etc.
> 
> Shuva's comment: Given the conversations on the bug report, lets have the l2 
> folks have the first stab at it.
> 
> 
> 
> On Tue, Oct 18, 2016 at 8:50 AM, Shuva Jyoti Kar 
> > wrote:
> Given the conversations on the bug report, lets have the l2 folks have the 
> first stab at it.
> 
>  
> 
> From: Abhijit Kumbhare [mailto:abhijitk...@gmail.com 
> ] 
> Sent: Tuesday, October 18, 2016 11:30 AM
> To: Tomáš Slušný; Jozef Bacigal; Shuva Jyoti Kar
> Subject: Fwd: [openflowplugin-dev] Blocker BUG-6956 reported in Boron
> 
>  
> 
> What do you guys think? Same as the other L2 switch bug?
> 
> -- Forwarded message --
> From: Alexis de Talhouët  >
> Date: Monday, October 17, 2016
> Subject: [openflowplugin-dev] Blocker BUG-6956 reported in Boron
> To: OpenDayLight-L2switch-Dev  >, openflowplugin-dev 
>  >
> 
> 
> Hello openflowplugin-dev and l2switch-dev,
> 
>  
> 
> I have reported a blocker BUG for Boron, as current functionality is broken. 
> See more information [0].
> 
>  
> 
> This BUG was reported by an ODL user [1].
> 
>  
> 
> Thanks,
> 
> Alexis
> 
>  
> 
> [0]: https://bugs.opendaylight.org/show_bug.cgi?id=6956 
> 
> [1]: https://ask.opendaylight.org/question/13767/l2-switch-in-boron/ 
> 
>  
> 
>  
> 
> 

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


Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis

2016-10-18 Thread Luis Gomez
Thanks Sai, yes I have a question regrading the first issue below: any idea why 
address tracker would keep discovered IP address information after restarting 
mininet? like what is today in the code to flush the address cache and why this 
is not working when mininet restarts?

BR/Luis

> On Oct 18, 2016, at 6:56 PM, Sai MarapaReddy  
> wrote:
> 
> Thanks Luis. 
> 
> Yes that is drop-all flow. Please let us know if you need any further help 
> from l2switch. 
> 
> On Tue, Oct 18, 2016 at 1:03 PM, Luis Gomez  > wrote:
> Actually this is the drop flow so it is expected, anyway going deeper into 
> l2switch test issues I see:
> 
> - The address tracker issue is because hosts addresses are not getting 
> cleared when we restart mininet with no sleep in-between.
> - The loop remover issue could be related to some test issue, I am trying to 
> clean up/repair the test here: https://git.opendaylight.org/gerrit/#/c/47095/ 
> 
> 
> BR/Luis
> 
> > On Oct 18, 2016, at 10:02 AM, Luis Gomez  > > wrote:
> >
> > There are definitely weird things going on in l2switch, the first ERROR you 
> > mention produces some weird flow (no match and no action) in the switch:
> >
> > Flow 55:
> >"cookie": 3098476543630901303,
> >"flags": "",
> >"hard-timeout": 0,
> >"id": "55",
> >"idle-timeout": 0,
> >"match": {},
> >"opendaylight-flow-statistics:flow-statistics": {
> >"byte-count": 0,
> >"duration": {
> >"nanosecond": 23900,
> >"second": 36
> >},
> >"packet-count": 0
> >},
> >"priority": 0,
> >"table_id": 0
> >
> >
> > The second issue, I am not sure what is the impact but definitely something 
> > to look at.
> >
> > I think in general we will need l2switch support to troubleshoot and 
> > progress in current issues.
> >
> > BR/Luis
> >
> >
> >> On Oct 17, 2016, at 8:09 AM, Miroslav Macko  
> >> wrote:
> >>
> >> Hello Luis and dev guys,
> >>
> >> There is this info from l2-switch in the karaf log:
> >>
> >> 2016-10-14 22:43:24,941 | INFO  | pool-16-thread-1 | FlowWriterServiceImpl 
> >>| 229 - org.opendaylight.l2switch.main.impl - 0.5.0.SNAPSHOT | 
> >> In addMacToMacFlowsUsingShortestPath: No flows added. Source and 
> >> Destination ports are same.
> >>
> >> Is it ok?
> >>
> >> And this debug message(it has incorrect severity):
> >>
> >> 2016-10-14 22:43:55,282 | ERROR | entLoopGroup-5-3 | 
> >> DeviceFlowRegistryImpl   | 210 - 
> >> org.opendaylight.openflowplugin.impl - 0.4.0.SNAPSHOT | Flow with flowId 
> >> 85 already exists in table 0
> >>
> >> So it looks like that flows with the same ID are added.
> >>
> >> What in short these failing tests are doing and what it should test please?
> >>
> >> Thanks,
> >> Miro
> >>
> >> 
> >> Od: Luis Gomez >
> >> Odoslané: 15. októbra 2016 1:01
> >> Komu: Tomáš Slušný
> >> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
> >> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis
> >>
> >> No luck :), still fails on "address tracker" and "loop remover":
> >>
> >> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/154/
> >>  
> >> 
> >> https://logs.opendaylight.org/releng/jenkins092/l2switch-csit-1node-switch-only-carbon/154/archives/log.html.gz
> >>  
> >> 
> >>
> >> BR/Luis
> >>
> >>
> >>> On Oct 14, 2016, at 2:26 PM, Luis Gomez  >>> > wrote:
> >>>
> >>> OK Tomas, I will try your patch 
> >>> https://git.opendaylight.org/gerrit/#/c/46390/ 
> >>>  on 
> >>> l2switch-csit-1node-switch-only-carbon and let you know.
> >>>
> >>>
>  On Oct 14, 2016, at 1:23 PM, Tomáš Slušný  
>  wrote:
> 
>  Also, 6710 was already merged only in master branch, but not yet in 
>  boron. It have cherry-pick ready here: 
>  https://git.opendaylight.org/gerrit/#/c/46761/ 
>  , but until it is 
>  merged, I think it would be better to check for improvement in Jenkins 
>  test for Carbon here: 
>  https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/
>   
>  

Re: [openflowplugin-dev] Blocker BUG-6956 reported in Boron

2016-10-18 Thread Sai MarapaReddy
This is not related to other l2switch bug.

Seems Alexis has patches for different patches including l2switch.

On Tue, Oct 18, 2016 at 10:06 AM, Abhijit Kumbhare 
wrote:

> Adding L2 switch, etc.
>
> Shuva's comment: Given the conversations on the bug report, lets have the
> l2 folks have the first stab at it.
>
>
> On Tue, Oct 18, 2016 at 8:50 AM, Shuva Jyoti Kar <
> shuva.jyoti@ericsson.com> wrote:
>
>> Given the conversations on the bug report, lets have the l2 folks have
>> the first stab at it.
>>
>>
>>
>> *From:* Abhijit Kumbhare [mailto:abhijitk...@gmail.com]
>> *Sent:* Tuesday, October 18, 2016 11:30 AM
>> *To:* Tomáš Slušný; Jozef Bacigal; Shuva Jyoti Kar
>> *Subject:* Fwd: [openflowplugin-dev] Blocker BUG-6956 reported in Boron
>>
>>
>>
>> What do you guys think? Same as the other L2 switch bug?
>>
>>
>> -- Forwarded message --
>> From: *Alexis de Talhouët* 
>> Date: Monday, October 17, 2016
>> Subject: [openflowplugin-dev] Blocker BUG-6956 reported in Boron
>> To: OpenDayLight-L2switch-Dev ,
>> openflowplugin-dev 
>>
>> Hello openflowplugin-dev and l2switch-dev,
>>
>>
>>
>> I have reported a blocker BUG for Boron, as current functionality is
>> broken. See more information [0].
>>
>>
>>
>> This BUG was reported by an ODL user [1].
>>
>>
>>
>> Thanks,
>>
>> Alexis
>>
>>
>>
>> [0]: https://bugs.opendaylight.org/show_bug.cgi?id=6956
>>
>> [1]: https://ask.opendaylight.org/question/13767/l2-switch-in-boron/
>>
>>
>>
>>
>>
>
>
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
>
>
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev