Date   

Re: Openflowjava project lead election

Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES@Cisco) <mirehak@...>
 

+1 for Michal Polkorab as project lead



Regards,

Michal




From: Daniel Bartoš <daniel.bartos@...>
Sent: Tuesday, March 15, 2016 09:57
To: Michal Polkoráb; openflowjava-dev
Cc: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)
Subject: RE: Openflowjava project lead election
 

+1 for Michal being project lead

 

Thanks,

Daniel

 

From: Michal Polkoráb
Sent: Tuesday, March 15, 2016 09:44
To: openflowjava-dev <openflowjava-dev@...>
Cc: mirehak@...; Daniel Bartoš <daniel.bartos@...>
Subject: Openflowjava project lead election

 

Hello openflowjava committers,

 

as we started new release cycle, we have to elect new project lead. I would like to nominate myself for this role. Please vote +1, 0, -1 or nominate yourself.

 

Regards,

Michal 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 

DanielBartoš

Sales Manager


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 620 503 / daniel.bartos@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: Openflowjava project lead election

Daniel Bartoš <daniel.bartos@...>
 

+1 for Michal being project lead

 

Thanks,

Daniel

 

From: Michal Polkoráb
Sent: Tuesday, March 15, 2016 09:44
To: openflowjava-dev <openflowjava-dev@...>
Cc: mirehak@...; Daniel Bartoš <daniel.bartos@...>
Subject: Openflowjava project lead election

 

Hello openflowjava committers,

 

as we started new release cycle, we have to elect new project lead. I would like to nominate myself for this role. Please vote +1, 0, -1 or nominate yourself.

 

Regards,

Michal 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 

DanielBartoš

Sales Manager


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 620 503 / daniel.bartos@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Openflowjava project lead election

Michal Polkoráb <michal.polkorab@...>
 

Hello openflowjava committers,


as we started new release cycle, we have to elect new project lead. I would like to nominate myself for this role. Please vote +1, 0, -1 or nominate yourself.


Regards,

Michal 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: [Aaa-dev] TLS cipher suite names

Rashmi Pujar <rpujar@...>
 

Hello Ryan,

I was able to test configuring cipher-suites to use with TLS connection. 

I had to update the JCE policy files to include jars that provide unlimited cryptographic strength: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Thanks to Mohamed for pointing it out to me.

Thanks,
Rashmi

On Thu, Mar 3, 2016 at 11:28 AM, Rashmi Pujar <rpujar@...> wrote:
Thanks for your reply Ryan. I did not edit the custom.properties to disable BC provider. Should this be commented to ensure Sun provider will be used?
So far I was logging the provider of the SSLContext Object in the openflowjava code to know the provider that was being used and it is "SUN version 1.8 Provider". Looks like openflowjava uses the default Sun provider. And that is how I used the cipher suite name to test.

Here is the provider ordering on my system:
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider


On Thu, Mar 3, 2016 at 9:36 AM, Ryan Goulding <ryandgoulding@...> wrote:
Rashmi,

How did you configure your JCE?  Did you disable bouncy castle in custom.properties (comment it out) and just rely on the default JCE Provider?  If so, then the default SUN Provider doesn't actually provide that cipher;  you need to use SunJSSE (and Java 8 since it isn't a part of Java 7 SunJSSE impl, but from your stack trace it looks like you are using 1.8.0_60 so that is good).  The provider ordering is specified in "/usr/java/jdk1.8.0_65/jre/lib/security/java.security";  can you confirm you are actually using SunJSSE?

Regards,

Ryan Goulding

On Tue, Mar 1, 2016 at 10:03 AM, Rashmi Pujar <rpujar@...> wrote:

Copying AAA mailing list as well for inputs.

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


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





--
Rashmi Pujar
Inocybe Technologies




--
Rashmi Pujar
Inocybe Technologies


Re: [Aaa-dev] TLS cipher suite names

Rashmi Pujar <rpujar@...>
 

Thanks for your reply Ryan. I did not edit the custom.properties to disable BC provider. Should this be commented to ensure Sun provider will be used?
So far I was logging the provider of the SSLContext Object in the openflowjava code to know the provider that was being used and it is "SUN version 1.8 Provider". Looks like openflowjava uses the default Sun provider. And that is how I used the cipher suite name to test.

Here is the provider ordering on my system:
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider


On Thu, Mar 3, 2016 at 9:36 AM, Ryan Goulding <ryandgoulding@...> wrote:
Rashmi,

How did you configure your JCE?  Did you disable bouncy castle in custom.properties (comment it out) and just rely on the default JCE Provider?  If so, then the default SUN Provider doesn't actually provide that cipher;  you need to use SunJSSE (and Java 8 since it isn't a part of Java 7 SunJSSE impl, but from your stack trace it looks like you are using 1.8.0_60 so that is good).  The provider ordering is specified in "/usr/java/jdk1.8.0_65/jre/lib/security/java.security";  can you confirm you are actually using SunJSSE?

Regards,

Ryan Goulding

On Tue, Mar 1, 2016 at 10:03 AM, Rashmi Pujar <rpujar@...> wrote:

Copying AAA mailing list as well for inputs.

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


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





--
Rashmi Pujar
Inocybe Technologies


Re: [Aaa-dev] TLS cipher suite names

Ryan Goulding <ryandgoulding@...>
 

Rashmi,

How did you configure your JCE?  Did you disable bouncy castle in custom.properties (comment it out) and just rely on the default JCE Provider?  If so, then the default SUN Provider doesn't actually provide that cipher;  you need to use SunJSSE (and Java 8 since it isn't a part of Java 7 SunJSSE impl, but from your stack trace it looks like you are using 1.8.0_60 so that is good).  The provider ordering is specified in "/usr/java/jdk1.8.0_65/jre/lib/security/java.security";  can you confirm you are actually using SunJSSE?

Regards,

Ryan Goulding

On Tue, Mar 1, 2016 at 10:03 AM, Rashmi Pujar <rpujar@...> wrote:

Copying AAA mailing list as well for inputs.

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


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



Re: TLS cipher suite names

Rashmi Pujar <rpujar@...>
 

Copying AAA mailing list as well for inputs.

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


Please don't Delay - Register For the OpenDaylight Boron Developer Forum *Now*

Phil Robb
 

Hello Michal Polkorab and the openflowjava development team:

If you've already registered for the Boron Developer Design Forum (DDF) please disregard this email and I look forward to seeing you next Monday.

HOWEVER, if you haven't registered, I'd like to reiterate the importance of getting together face to face with both members of your particular project as well as the rest of the OpenDaylight development community. Not only can you kickstart development activities for Boron within your project, but we will also discuss critical project-wide topics such as the changes to the build environment and Release process, as well as key new features and technologies soon to be added to the platform that may be of significant importance to you... and then just getting to put faces with irc-handles is always a big win for everybody.

Please attend if it is at all possible. The DDF is the *best* way to meet and work with other key developers in the ODL community to make great advances on what is important to you.

The DDF logistics are:
When: Next Monday & Tuesday (February 29th, and March 1st), 9:00am to 5:00pm each day
Where: San Mateo Marriott San Francisco Airport
1770 S Amphlett Blvd
San Mateo, CA 94402
+1 650-653-6000

Remember we run the event as both a standard technical conference and also as an unconference. You are welcome and encouraged to submit discussion topics important to you on this wiki page:

https://wiki.opendaylight.org/view/Events:Boron_Dev_Forum

Please post any new entries to the bottom of that page. I'll collect the topics on a daily basis and populate the pre-defined schedule with them. That schedule is located here:

http://events.linuxfoundation.org/events/opendaylight-developer-design-forum/program/schedule

We will also have additional rooms set aside for project teams and/or cross-project groups to get together to work through issues and ideas in an ad-hoc (aka unconference) style.

If you are able to attend, please register as soon as you are able. Important URLs are:

TO REGISTER: http://events.linuxfoundation.org/events/opendaylight-developer-design-forum/attend/register

The Main Event Website: http://events.linuxfoundation.org/events/opendaylight-developer-design-forum

If you have any difficulties in registering, or need assistance in any way, please contact me immediately.

Thanks, and I look forward to seeing you next week.

Phil.
--
Phil Robb
Sr. Director Of Technical Operations
OpenDaylight Project
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


TLS cipher suite names

Rashmi Pujar <rpujar@...>
 

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


FW: Day 3 Beryllium Release Review

an.ho@huawei.com
 

When: Tuesday, February 09, 2016 7:30 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: IRC #opendaylight-meeting
 
Note: The GMT offset above does not reflect daylight saving time adjustments.
 
*~*~*~*~*~*~*~*~*~*
 
Hi Michal Polkorab (PTL) and OPENFLOWJAVA Team,
 
Can you or a proxy from your team confirm your attendance for the release review.  Your project is scheduled for Release Review on this date.  Please join #opendaylight-meeting on IRC channel 10 minutes before your session and make sure you have your release review and release notes filled in the spreadsheet.
 
Please email me if you would like someone else (proxy) to present on your behalf.
 
 
Feb 9 Tuesday
8:50 AM *OPENFLOWJAVA* Michal Polkorab michal.polkorab@...
 
 
Best Regards,
An Ho
 
 
-----Original Appointment-----
From: An Ho
Sent: Thursday, February 04, 2016 11:31 PM
To: release@...; 'sbejgam@...'; 'rovarga@...'; 'ryandgoulding@...'; 'ttkacik@...'; 'mmarsale@...'; 'milfabia@...'; 'ammandke@...'; 'michal.polkorab@...'; alefan@...; evanrzeller@...; ragbhat@...; l2switch-dev@...
Cc: 'Curt Beckmann'; Colin Dixon; Branislav Murin -X (bmurin - PANTHEON TECHNOLOGIES at Cisco); Mala, Praveen; Aneesha Pailla; skitt@...; vmithbao@...; chrisw@...; thanh.ha@...; nite@...; odlparent-dev@...; dana.kutenics@...; jmedved@...; bgpcep-dev@...
Subject: Day 3 Beryllium Release Review
When: Tuesday, February 09, 2016 7:30 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: IRC #opendaylight-meeting
 
 
Day 3 Beryllium Release Review
 
 
 


Re: Yang parser for bit protocols

Mahesh Govind
 

Thanks


On Sunday 7 February 2016, Robert Varga <nite@...> wrote:
On 2016-02-07 08:47, Mahesh Govind wrote:

Dear experts ,
Can we generate encoders and decoders using yang for bit orientated protocols .
Does openflow uses generated protocol encoders and decoders ?
[ I saw some yang statements with position:x in opneflow-protocol.yang file ]


Yes, there is no problem modeling any protocol in YANG. The use of explicit bit type is discouraged, though -- it is better to model each bit as a separate leaf.

Bye,
Robert


Re: [yangtools-users] Yang parser for bit protocols

Robert Varga <nite@...>
 

On 2016-02-07 08:47, Mahesh Govind wrote:

Dear experts ,
Can we generate encoders and decoders using yang for bit orientated protocols .
Does openflow uses generated protocol encoders and decoders ?
[ I saw some yang statements with position:x in opneflow-protocol.yang file ]
Yes, there is no problem modeling any protocol in YANG. The use of explicit bit type is discouraged, though -- it is better to model each bit as a separate leaf.

Bye,
Robert


Yang parser for bit protocols

Mahesh Govind
 


Dear experts ,
Can we generate encoders and decoders using yang for bit orientated protocols .
Does openflow uses generated protocol encoders and decoders ?
[ I saw some yang statements with position:x in opneflow-protocol.yang file ]

regards
Mahesh


Re: [vtn-dev] Regression detected

Tai, Hideyuki <hideyuki.tai@...>
 

Hi Luis,

 

In my understanding, the bug (4614) is about that the openflowjava cannot handle concurrent barrier requests to the same switch.

And the patch (Gerrit 33906) has fixed the bug.

 

Therefore, I think one consequence of not applying this patch (33906) is that we would need to force applications of OpenFlow plugin not to send barrier requests to the same switch concurrently.

The applications need to send a barrier request one by one.

I think it's not happy for developers who wants to develop high performance OpenFlow applications.

 

That being said, I think it's good if we can keep to support CPqD.

 

Considering the root cause of this issue is a bug of the CPqD, if CPqD is needed, we should create a patch which not apply the change of the patch (Gerrit 33906) only when openflowjava or someone knows the target switch is CPqD rather than not applying the patch (33906) and force applications to implement complex things.

 

Regards,

Hideyuki Tai

 

From: vtn-dev-bounces@... [mailto:vtn-dev-bounces@...] On Behalf Of Luis Gomez
Sent: Friday, February 05, 2016 15:48
To: Michal Polkoráb <michal.polkorab@...>; vtn-dev@...; nemo-dev@...
Cc: openflowjava-dev <openflowjava-dev@...>; openflowplugin-dev <openflowplugin-dev@...>; Abhijit Kumbhare <abhijitkoss@...>
Subject: Re: [vtn-dev] [openflowjava-dev] Regression detected

 

But also, can anyone in vtn explain the consequences of not applying this patch? the reason is this seems like the ovs 2.0 discussion last release: we do something right in the code that breaks popular switch connectivity, and CPqD is not as popular as OVS but still.

 

I am also cc-ing memo project because they have recently showed interest in using CPqD for their system test, and this will impact them.

 

BR/Luis

 

 

 

On Feb 5, 2016, at 3:38 PM, Luis Gomez <ecelgp@...> wrote:

 

I can take care of the robot test.

 

 

On Feb 5, 2016, at 6:48 AM, Michal Polkoráb <michal.polkorab@...> wrote:

 

Robot tests (robot setups) should know which switch they are using. CPqD switches should be used only when testing groups - as far as I know.

Unfortunately, I won't do the change as it is out of my scope.

 

Michal 


From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 15:36
To: Michal Polkoráb
Cc: Luis Gomez; openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected

 

For the first solution:

 

1. introduce timeout / sleep in testcases with CPqD switches,

 

How do you know if we are connecting to a CPqD switch and not any other kind of switch? It will be important to be able to keep working with CPqD switch as it would be good to be able to work with multiple switches.

 

So will you do the timeout change Michal?

 

 

On Fri, Feb 5, 2016 at 5:43 AM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello,

 

the change that causes the problems is this one: https://git.opendaylight.org/gerrit/#/c/33906/. It fixes Bug 4614 (https://bugs.opendaylight.org/show_bug.cgi?id=4614).

We have tested the change with both OVS and CPqD switches and both passed. The XID (see the change) wasn't used because CPqD switch didn't fully behave according to the specification (didn't reply with correct XID) - and as it turns out, it still doesn't. The first connection usually replies with random generated XID in features-reply, after we close the connection (approx. 30 seconds), the device connects successfully. So our options are:

​1. introduce timeout / sleep in testcases with CPqD switches,

2. replace CPqD switches with OVS switches (since OVS 2.3 - groups are supported).

 

Regards,

Michal Polkorab

 


From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 01:24
To: Luis Gomez
Cc: openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected

 

Thanks Luis. May be better to wait for Michal Polkorab to comment.

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

Image removed by sender. logo

 

 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

Image removed by sender. logo

 

 

 


Re: Regression detected

Luis Gomez <ecelgp@...>
 

But also, can anyone in vtn explain the consequences of not applying this patch? the reason is this seems like the ovs 2.0 discussion last release: we do something right in the code that breaks popular switch connectivity, and CPqD is not as popular as OVS but still.

I am also cc-ing memo project because they have recently showed interest in using CPqD for their system test, and this will impact them.

BR/Luis



On Feb 5, 2016, at 3:38 PM, Luis Gomez <ecelgp@...> wrote:

I can take care of the robot test.


On Feb 5, 2016, at 6:48 AM, Michal Polkoráb <michal.polkorab@...> wrote:

Robot tests (robot setups) should know which switch they are using. CPqD switches should be used only when testing groups - as far as I know.
Unfortunately, I won't do the change as it is out of my scope.

Michal 

From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 15:36
To: Michal Polkoráb
Cc: Luis Gomez; openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
For the first solution:

1. introduce timeout / sleep in testcases with CPqD switches,

How do you know if we are connecting to a CPqD switch and not any other kind of switch? It will be important to be able to keep working with CPqD switch as it would be good to be able to work with multiple switches.

So will you do the timeout change Michal?


On Fri, Feb 5, 2016 at 5:43 AM, Michal Polkoráb <michal.polkorab@...> wrote:
Hello,

the change that causes the problems is this one: https://git.opendaylight.org/gerrit/#/c/33906/. It fixes Bug 4614 (https://bugs.opendaylight.org/show_bug.cgi?id=4614).
We have tested the change with both OVS and CPqD switches and both passed. The XID (see the change) wasn't used because CPqD switch didn't fully behave according to the specification (didn't reply with correct XID) - and as it turns out, it still doesn't. The first connection usually replies with random generated XID in features-reply, after we close the connection (approx. 30 seconds), the device connects successfully. So our options are:
​1. introduce timeout / sleep in testcases with CPqD switches,
2. replace CPqD switches with OVS switches (since OVS 2.3 - groups are supported).

Regards,
Michal Polkorab


From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 01:24
To: Luis Gomez
Cc: openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
Thanks Luis. May be better to wait for Michal Polkorab to comment.
MichalPolkoráb
Software Engineer

Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk
logo

 


MichalPolkoráb
Software Engineer

Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk
logo

 




Re: Regression detected

Luis Gomez <ecelgp@...>
 

I can take care of the robot test.


On Feb 5, 2016, at 6:48 AM, Michal Polkoráb <michal.polkorab@...> wrote:

Robot tests (robot setups) should know which switch they are using. CPqD switches should be used only when testing groups - as far as I know.
Unfortunately, I won't do the change as it is out of my scope.

Michal 

From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 15:36
To: Michal Polkoráb
Cc: Luis Gomez; openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
For the first solution:

1. introduce timeout / sleep in testcases with CPqD switches,

How do you know if we are connecting to a CPqD switch and not any other kind of switch? It will be important to be able to keep working with CPqD switch as it would be good to be able to work with multiple switches.

So will you do the timeout change Michal?


On Fri, Feb 5, 2016 at 5:43 AM, Michal Polkoráb <michal.polkorab@...> wrote:
Hello,

the change that causes the problems is this one: https://git.opendaylight.org/gerrit/#/c/33906/. It fixes Bug 4614 (https://bugs.opendaylight.org/show_bug.cgi?id=4614).
We have tested the change with both OVS and CPqD switches and both passed. The XID (see the change) wasn't used because CPqD switch didn't fully behave according to the specification (didn't reply with correct XID) - and as it turns out, it still doesn't. The first connection usually replies with random generated XID in features-reply, after we close the connection (approx. 30 seconds), the device connects successfully. So our options are:
​1. introduce timeout / sleep in testcases with CPqD switches,
2. replace CPqD switches with OVS switches (since OVS 2.3 - groups are supported).

Regards,
Michal Polkorab


From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 01:24
To: Luis Gomez
Cc: openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
Thanks Luis. May be better to wait for Michal Polkorab to comment.
MichalPolkoráb
Software Engineer

Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk
logo

 


MichalPolkoráb
Software Engineer

Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk
logo

 



Re: Regression detected

Michal Polkorab
 

Robot tests (robot setups) should know which switch they are using. CPqD switches should be used only when testing groups - as far as I know.

Unfortunately, I won't do the change as it is out of my scope.


Michal 


From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 15:36
To: Michal Polkoráb
Cc: Luis Gomez; openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
For the first solution:

1. introduce timeout / sleep in testcases with CPqD switches,

How do you know if we are connecting to a CPqD switch and not any other kind of switch? It will be important to be able to keep working with CPqD switch as it would be good to be able to work with multiple switches.

So will you do the timeout change Michal?


On Fri, Feb 5, 2016 at 5:43 AM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello,


the change that causes the problems is this one: https://git.opendaylight.org/gerrit/#/c/33906/. It fixes Bug 4614 (https://bugs.opendaylight.org/show_bug.cgi?id=4614).

We have tested the change with both OVS and CPqD switches and both passed. The XID (see the change) wasn't used because CPqD switch didn't fully behave according to the specification (didn't reply with correct XID) - and as it turns out, it still doesn't. The first connection usually replies with random generated XID in features-reply, after we close the connection (approx. 30 seconds), the device connects successfully. So our options are:

​1. introduce timeout / sleep in testcases with CPqD switches,

2. replace CPqD switches with OVS switches (since OVS 2.3 - groups are supported).


Regards,

Michal Polkorab



From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 01:24
To: Luis Gomez
Cc: openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
Thanks Luis. May be better to wait for Michal Polkorab to comment.

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: Regression detected

Abhijit Kumbhare
 

For the first solution:

1. introduce timeout / sleep in testcases with CPqD switches,

How do you know if we are connecting to a CPqD switch and not any other kind of switch? It will be important to be able to keep working with CPqD switch as it would be good to be able to work with multiple switches.

So will you do the timeout change Michal?


On Fri, Feb 5, 2016 at 5:43 AM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello,


the change that causes the problems is this one: https://git.opendaylight.org/gerrit/#/c/33906/. It fixes Bug 4614 (https://bugs.opendaylight.org/show_bug.cgi?id=4614).

We have tested the change with both OVS and CPqD switches and both passed. The XID (see the change) wasn't used because CPqD switch didn't fully behave according to the specification (didn't reply with correct XID) - and as it turns out, it still doesn't. The first connection usually replies with random generated XID in features-reply, after we close the connection (approx. 30 seconds), the device connects successfully. So our options are:

​1. introduce timeout / sleep in testcases with CPqD switches,

2. replace CPqD switches with OVS switches (since OVS 2.3 - groups are supported).


Regards,

Michal Polkorab



From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 01:24
To: Luis Gomez
Cc: openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
Thanks Luis. May be better to wait for Michal Polkorab to comment.

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 



Re: Regression detected

Michal Polkorab
 

Hello,


the change that causes the problems is this one: https://git.opendaylight.org/gerrit/#/c/33906/. It fixes Bug 4614 (https://bugs.opendaylight.org/show_bug.cgi?id=4614).

We have tested the change with both OVS and CPqD switches and both passed. The XID (see the change) wasn't used because CPqD switch didn't fully behave according to the specification (didn't reply with correct XID) - and as it turns out, it still doesn't. The first connection usually replies with random generated XID in features-reply, after we close the connection (approx. 30 seconds), the device connects successfully. So our options are:

​1. introduce timeout / sleep in testcases with CPqD switches,

2. replace CPqD switches with OVS switches (since OVS 2.3 - groups are supported).


Regards,

Michal Polkorab



From: Abhijit Kumbhare <abhijitkoss@...>
Sent: 05 February 2016 01:24
To: Luis Gomez
Cc: openflowjava-dev; openflowplugin-dev
Subject: Re: [openflowjava-dev] Regression detected
 
Thanks Luis. May be better to wait for Michal Polkorab to comment.

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: Regression detected

Abhijit Kumbhare
 

Thanks Luis. May be better to wait for Michal Polkorab to comment.