1. z.archive.ovsdb-dev@lists.opendaylight.org
  2. Messages
   Date   
Jenkins setup

Giovanni Meo <gmeo@...>
 

Hi helpdesk,

i'm trying to setup the jenkins on the ovsdb project, but that fails because the maven is not setup, here is what jenkins reports:

Jenkins needs to know where your Maven 2/3 is installed.
Please do so from the system configuration.

I know this has been reported also for the yang-tools projects, can you please install the maven in all the jenkins instance? I'm not sure why that is needed given maven is visible on the controller project, but seems like there is a per-project setting missing.

Thanks in advance,
Giovanni
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
Re: Jenkins setup

Andrew Grimberg <agrimberg@...>
 

Greetings folks,

Sorry about all of this. I was pretty certain that I had Maven setup
after I built out the silos before I left for my vacation. We should be
all setup now with Maven 3.0.5 for this and the other new Jenkins silos.
Apparently 3.1.0 (which is what I thought I had setup) had problems :(

-Andy-

On Mon, 2013-07-29 at 14:52 +0200, Giovanni Meo wrote:
Hi helpdesk,

i'm trying to setup the jenkins on the ovsdb project, but that fails because the
maven is not setup, here is what jenkins reports:

Jenkins needs to know where your Maven 2/3 is installed.
Please do so from the system configuration.

I know this has been reported also for the yang-tools projects, can you please
install the maven in all the jenkins instance? I'm not sure why that is needed
given maven is visible on the controller project, but seems like there is a
per-project setting missing.

Thanks in advance,
Giovanni
--
Andrew J Grimberg
Systems Administrator
The Linux Foundation

?
signature.asc

NetworkConfiguration -> BridgeDomain Configuration Service

Madhu Venugopal (vmadhu) <vmadhu@...>
 

I just pushed a commit for BridgeDomain Configuration Service under the
umbrella of SAL Network Configuration Services.
The idea of this SAL service is to provide a Protocol Plugin agnostic way
of configuring Bridge Domains.
Please take a look @ http://git.opendaylight.org/gerrit/760

When you browse through the code, it will be evident that, SAL
NetworkConfiguration services are implemented as a pluggable
bundle on its own to show the extensibility of SAL layer.

Also, the NetworkConfiguration bundle is subdivided into various Services
under their own package structure.
We are starting this effort with the BridgeDomain management and naturally
we can expand this and add more services under
NetworkConfiguration bundle.

Please note that the version is set as 0.0.1 to indicate that this is just
the beginning and this code commit is to get the code flowing
and start to integrate with network management plugins. As a start, we are
integrating this with OVSDB plugin.

The design intent is to have an extensible way of providing Network
configuration service that satisfies various use-cases and
various protocol plugin capabilities.

Copied all the interested development lists as well.

Thanks,
Madhu
Re: [controller-dev] NetworkConfiguration -> BridgeDomain Configuration Service

Colin Dixon <ckd@...>
 

I take it that BridgeDomains are the protocol-agnostic equivalent of an L2 segment?

Should we make a wiki page somewhere of the core abstractions and their loose equivalents? It might be useful.

For example:
Node = Switch/Router/Etc
Edge = Link
NodeConnector = Nodes and edges connect, e.g., a switch port

--Colin

controller-dev-bounces@... wrote on 07/31/2013 09:51:44 AM:
> From: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> To: "discuss@..." <discuss@...>
> Cc: "controller-dev@..." <controller-
> dev@...>, "ovsdb-dev@..."
> <ovsdb-dev@...>, "opendove-
> dev@..." <opendove-dev@...>,
> "vtn-dev@..." <vtn-dev@...>
> Date: 07/31/2013 09:52 AM
> Subject: [controller-dev] NetworkConfiguration -> BridgeDomain
> Configuration Service
> Sent by: controller-dev-bounces@...
>
>
> I just pushed a commit for BridgeDomain Configuration Service under the
> umbrella of SAL Network Configuration Services.
> The idea of this SAL service is to provide a Protocol Plugin agnostic way
> of configuring Bridge Domains.
> Please take a look @ http://git.opendaylight.org/gerrit/760
>
> When you browse through the code, it will be evident that, SAL
> NetworkConfiguration services are implemented as a pluggable
> bundle on its own to show the extensibility of SAL layer.
>
> Also, the NetworkConfiguration bundle is subdivided into various Services
> under their own package structure.
> We are starting this effort with the BridgeDomain management and naturally
> we can expand this and add more services under
> NetworkConfiguration bundle.
>
> Please note that the version is set as 0.0.1 to indicate that this is just
> the beginning and this code commit is to get the code flowing
> and start to integrate with network management plugins. As a start, we are
> integrating this with OVSDB plugin.
>
> The design intent is to have an extensible way of providing Network
> configuration service that satisfies various use-cases and
> various protocol plugin capabilities.
>
> Copied all the interested development lists as well.
>
> Thanks,
> Madhu
>
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>

Re: [controller-dev] NetworkConfiguration -> BridgeDomain Configuration Service

Madhu Venugopal (vmadhu) <vmadhu@...>
 

>> I take it that BridgeDomains are the protocol-agnostic equivalent of an L2 segment?

Yes. That is the general idea.

Similarly, the umbrella abstraction, Network Configuration is a protocol-agnostic equivalent for any configuration in general.
(Yesterday's ethernet plugin discussion might fall under one or many sub-configuration modules).

It will certainly help to have this Terminology page in the wiki as a lookup.

Thanks,
-Madhu


From: Colin Dixon <ckd@...>
Date: Monday, August 5, 2013 6:35 PM
To: Madhu Venugopal <vmadhu@...>
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "discuss@..." <discuss@...>, "opendove-dev@..." <opendove-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "vtn-dev@..." <vtn-dev@...>
Subject: Re: [controller-dev] NetworkConfiguration -> BridgeDomain Configuration Service

I take it that BridgeDomains are the protocol-agnostic equivalent of an L2 segment?

Should we make a wiki page somewhere of the core abstractions and their loose equivalents? It might be useful.

For example:
Node = Switch/Router/Etc
Edge = Link
NodeConnector = Nodes and edges connect, e.g., a switch port

--Colin

controller-dev-bounces@... wrote on 07/31/2013 09:51:44 AM:
> From: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> To: "discuss@..." <discuss@...>
> Cc: "controller-dev@..." <controller-
> dev@...>, "ovsdb-dev@..."
> <ovsdb-dev@...>, "opendove-
> dev@..." <opendove-dev@...>,
> "vtn-dev@..." <vtn-dev@...>
> Date: 07/31/2013 09:52 AM
> Subject: [controller-dev] NetworkConfiguration -> BridgeDomain
> Configuration Service
> Sent by: controller-dev-bounces@...
>
>
> I just pushed a commit for BridgeDomain Configuration Service under the
> umbrella of SAL Network Configuration Services.
> The idea of this SAL service is to provide a Protocol Plugin agnostic way
> of configuring Bridge Domains.
> Please take a look @ http://git.opendaylight.org/gerrit/760
>
> When you browse through the code, it will be evident that, SAL
> NetworkConfiguration services are implemented as a pluggable
> bundle on its own to show the extensibility of SAL layer.
>
> Also, the NetworkConfiguration bundle is subdivided into various Services
> under their own package structure.
> We are starting this effort with the BridgeDomain management and naturally
> we can expand this and add more services under
> NetworkConfiguration bundle.
>
> Please note that the version is set as 0.0.1 to indicate that this is just
> the beginning and this code commit is to get the code flowing
> and start to integrate with network management plugins. As a start, we are
> integrating this with OVSDB plugin.
>
> The design intent is to have an extensible way of providing Network
> configuration service that satisfies various use-cases and
> various protocol plugin capabilities.
>
> Copied all the interested development lists as well.
>
> Thanks,
> Madhu
>
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>

Distribution directory commits and Jenkin's changes

Ed Warnicke (eaw) <eaw@...>
 

I pushed two changes to add a distribution directory:


https://git.opendaylight.org/gerrit/#/c/784/ - which adds the distribution directory and makes commons/ build both ovsdb/ and distribution/
https://git.opendaylight.org/gerrit/#/c/785/ - which moves commons/ to commons/parent so there's room for other 'commons' things

They both verify currently, but I would recommend if  you choose to merge them that you alter the Jenkin's Job to build the pom file:
commons/parent/pom.xml (as that should build all modules, ovsdb/ and distribution/ ).

Please also note the new top level README which has instructions analogous to what is provided in controller.

Ed
Few NorthBound REST API cleanup

Madhu Venugopal (vmadhu) <vmadhu@...>
 


Devs,

While reviewing the existing REST APIs, we identified a few inconstancies in Documentation, Grammar and URL paths.
Few of us are cleaning it up. Expect a few Gerrit review requests (all on the controller branch) in a day or 2.
These are minor changes to get the Controller REST APIs consistent and can act as a base template for any new northbound bundles.

I am writing a wiki page with all the details and developer guide on writing a consistent and effective northbound bundle.
Will keep you all posted once it is done.

Thanks,
Madhu
Re: [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Ed Warnicke (eaw) <eaw@...>
 

We may want to settle onto a single version of netty throughout ODL… here's what I see so far:

bgpcep: 
<netty.version>4.0.7.Final</netty.version>

openflowjava:
 <dependency>
       <groupId>org.jboss.netty</groupId>
       <artifactId>netty</artifactId>
       <version>3.2.6.Final</version>
 </dependency>

ovsdb:
<dependency>
     <groupId>io.netty</groupId>
     <artifactId>netty-all</artifactId>
     <version>4.0.8.Final</version>
</dependency>

Ed

On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>
 wrote:

The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.




Hi Abhijit, 

I think I was not quiet clear

My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin 

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1) 



From:        Abhijit Kumbhare <abhijitk@...> 
To:        Christopher Price <christopher.price@...> 
Cc:        "controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...> 
Date:        09/13/2013 01:45 AM 
Subject:        Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated. 



The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.

<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From: Christopher Price <christopher.price@...>
To: Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc: "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date: 09/12/2013 01:09 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by: openflowjava-dev-bounces@...



Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From: Muthukumaran Kothandaraman <mkothand@...>
Date: Thursday, September 12, 2013 12:57 PM
To: Prasanna Huddar <prasanna.huddar@...>
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [controller-dev] OF Plugin Design Updated.

Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
  More like following 
     When 1.0 OF Header version is encountered (no need for version-negotiation)
             - Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler" 

     When 1.3 OF Header version is encountered
             -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion
             -Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case
             -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

 And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "version-detector" in all above pipeline configurations which uses only the header-version? 



     

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1) 



From:        Prasanna Huddar <prasanna.huddar@...>
To:        "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        09/12/2013 10:27 PM
Subject:        [controller-dev] OF Plugin Design Updated.
Sent by:        controller-dev-bounces@...



Hello,

           Updated the Plugin design as per the discussion in Hackfest.

https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev

_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Tony Tkacik -X (ttkacik - Pantheon Technologies SRO@Cisco) <ttkacik@...>
 

I would suggest using Netty 4.0.9-Final

Still in distribution you could overrride minor number.

 

Tony

 

 

From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Thursday, September 12, 2013 4:37 PM
To: Abhijit Kumbhare
Cc: Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject: Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

 

We may want to settle onto a single version of netty throughout ODL… here's what I see so far:

 

bgpcep: 

<netty.version>4.0.7.Final</netty.version>

 

openflowjava:

 <dependency>

       <groupId>org.jboss.netty</groupId>

       <artifactId>netty</artifactId>

       <version>3.2.6.Final</version>

 </dependency>

 

ovsdb:

<dependency>

     <groupId>io.netty</groupId>

     <artifactId>netty-all</artifactId>

     <version>4.0.8.Final</version>

</dependency>

 

Ed

 

On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>

 wrote:



The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.




Hi Abhijit, 

I think I was not quiet clear

My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin 

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1) 



From:        Abhijit Kumbhare <abhijitk@...> 
To:        Christopher Price <christopher.price@...> 
Cc:        "controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...> 
Date:        09/13/2013 01:45 AM 
Subject:        Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated. 




The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.

<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From: Christopher Price <christopher.price@...>
To: Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc: "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date: 09/12/2013 01:09 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by: openflowjava-dev-bounces@...




Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From: Muthukumaran Kothandaraman <mkothand@...>
Date: Thursday, September 12, 2013 12:57 PM
To: Prasanna Huddar <prasanna.huddar@...>
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [controller-dev] OF Plugin Design Updated.

Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
  More like following 
     When 1.0 OF Header version is encountered (no need for version-negotiation)
             - Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler" 

     When 1.3 OF Header version is encountered
             -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion
             -Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case
             -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

 And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "version-detector" in all above pipeline configurations which uses only the header-version? 



     

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1) 



From:        Prasanna Huddar <prasanna.huddar@...>
To:        "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        09/12/2013 10:27 PM
Subject:        [controller-dev] OF Plugin Design Updated.
Sent by:        controller-dev-bounces@...




Hello,

           Updated the Plugin design as per the discussion in Hackfest.

https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev

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

 
Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Muthukumaran Kothandaraman <mkothand@...>
 

It would be better to go for latest version as suggested by Tony. We might want to look into the following resolutions just in case https://issues.jboss.org/issues/?jql=project%20%3D%20NETTY%20AND%20fixVersion%20%3D%20%224.0.0.x%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

Earlier, for protocol-plugin and codec  I had used 3.2.6 because of the stability, drastically different 4.0x API , wider mindshare of experience in forums on 3.2.6 and documentation.
If we account and contain Netty dependencies to limited classes, changing to newer version would not be an issue.

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)



From:        "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
To:        "Ed Warnicke (eaw)" <eaw@...>, Abhijit Kumbhare <abhijitk@...>
Cc:        Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowplugin-dev@..." <openflowplugin-dev@...>, Christopher Price <christopher.price@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>
Date:        09/13/2013 05:11 AM
Subject:        RE: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev]        [controller-dev] OF        Plugin Design Updated.



I would suggest using Netty 4.0.9-Final
Still in distribution you could overrride minor number.
 
Tony
 
 

From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Thursday, September 12, 2013 4:37 PM
To: Abhijit Kumbhare
Cc: Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject: Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
 
We may want to settle onto a single version of netty throughout ODL… here's what I see so far:
 
bgpcep:
https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pom.xml;h=c85d766e94a6b9ad73bd831b0d79bd07dcddc205;hb=HEAD
<netty.version>4.0.7.Final</netty.version>
 
openflowjava:
https://git.opendaylight.org/gerrit/gitweb?p=openflowjava.git;a=blob;f=third-party/openflowj_netty/pom.xml;h=379c6197737bc697da2d4ef685cccdbfc9024fa1;hb=HEAD
 <dependency>
       <groupId>org.jboss.netty</groupId>
       <artifactId>netty</artifactId>
       <version>3.2.6.Final</version>
 </dependency>
 
ovsdb:
https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=ovsdb/pom.xml;h=904febb3fdfdc9df371819f381b3620be3ab3a36;hb=b5688d33619e1a3b11af5ba9d1c8e7b0cacf59e1
<dependency>
     <groupId>io.netty</groupId>
     <artifactId>netty-all</artifactId>
     <version>4.0.8.Final</version>
</dependency>
 
Ed
 
On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>
 wrote:

The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.





Hi Abhijit,

I think I was not quiet clear

My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)



From:        Abhijit Kumbhare <abhijitk@...>
To:        Christopher Price <christopher.price@...>
Cc:        "controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date:        09/13/2013 01:45 AM
Subject:        Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.




The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.

<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From: Christopher Price <christopher.price@...>
To: Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc: "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date: 09/12/2013 01:09 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by: openflowjava-dev-bounces@...




Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From: Muthukumaran Kothandaraman <mkothand@...>
Date: Thursday, September 12, 2013 12:57 PM
To: Prasanna Huddar <prasanna.huddar@...>
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [controller-dev] OF Plugin Design Updated.

Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
 More like following
    When 1.0 OF Header version is encountered (no need for version-negotiation)
            - Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered
            -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion
            -Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case
            -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "version-detector" in all above pipeline configurations which uses only the header-version?



   

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)



From:        Prasanna Huddar <prasanna.huddar@...>
To:        "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        09/12/2013 10:27 PM
Subject:        [controller-dev] OF Plugin Design Updated.
Sent by:        controller-dev-bounces@...




Hello,

          Updated the Plugin design as per the discussion in Hackfest.

https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


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

Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Muthukumaran Kothandaraman <mkothand@...>
 

Tony,

Not sure if the clarifications mentioned in below link have been addressed differently in the design and implementation in context of 4.0x.

Following this thread might be useful (I just posted this query)

http://stackoverflow.com/questions/18780335/netty-3-2-6-to-netty-4-0x-migration

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)



From:        Muthukumaran Kothandaraman/India/IBM
To:        "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
Cc:        Abhijit Kumbhare <abhijitk@...>, "bgpcep-dev@..." <bgpcep-dev@...>, Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "Ed Warnicke (eaw)" <eaw@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Date:        09/13/2013 05:30 AM
Subject:        RE: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev]        [controller-dev] OF        Plugin Design Updated.


It would be better to go for latest version as suggested by Tony. We might want to look into the following resolutions just in case https://issues.jboss.org/issues/?jql=project%20%3D%20NETTY%20AND%20fixVersion%20%3D%20%224.0.0.x%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

Earlier, for protocol-plugin and codec  I had used 3.2.6 because of the stability, drastically different 4.0x API , wider mindshare of experience in forums on 3.2.6 and documentation.
If we account and contain Netty dependencies to limited classes, changing to newer version would not be an issue.

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)




From:        "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
To:        "Ed Warnicke (eaw)" <eaw@...>, Abhijit Kumbhare <abhijitk@...>
Cc:        Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowplugin-dev@..." <openflowplugin-dev@...>, Christopher Price <christopher.price@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>
Date:        09/13/2013 05:11 AM
Subject:        RE: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev]        [controller-dev] OF        Plugin Design Updated.



I would suggest using Netty 4.0.9-Final
Still in distribution you could overrride minor number.
 
Tony
 
 

From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Thursday, September 12, 2013 4:37 PM
To: Abhijit Kumbhare
Cc: Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject: Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
 
We may want to settle onto a single version of netty throughout ODL… here's what I see so far:
 
bgpcep:
https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pom.xml;h=c85d766e94a6b9ad73bd831b0d79bd07dcddc205;hb=HEAD
<netty.version>4.0.7.Final</netty.version>
 
openflowjava:
https://git.opendaylight.org/gerrit/gitweb?p=openflowjava.git;a=blob;f=third-party/openflowj_netty/pom.xml;h=379c6197737bc697da2d4ef685cccdbfc9024fa1;hb=HEAD
 <dependency>
       <groupId>org.jboss.netty</groupId>
       <artifactId>netty</artifactId>
       <version>3.2.6.Final</version>
 </dependency>
 
ovsdb:
https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=ovsdb/pom.xml;h=904febb3fdfdc9df371819f381b3620be3ab3a36;hb=b5688d33619e1a3b11af5ba9d1c8e7b0cacf59e1
<dependency>
     <groupId>io.netty</groupId>
     <artifactId>netty-all</artifactId>
     <version>4.0.8.Final</version>
</dependency>
 
Ed
 
On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>
 wrote:

The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.





Hi Abhijit,

I think I was not quiet clear

My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)



From:        Abhijit Kumbhare <abhijitk@...>
To:        Christopher Price <christopher.price@...>
Cc:        "controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date:        09/13/2013 01:45 AM
Subject:        Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.




The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.

<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From: Christopher Price <christopher.price@...>
To: Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc: "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date: 09/12/2013 01:09 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by: openflowjava-dev-bounces@...




Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From: Muthukumaran Kothandaraman <mkothand@...>
Date: Thursday, September 12, 2013 12:57 PM
To: Prasanna Huddar <prasanna.huddar@...>
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [controller-dev] OF Plugin Design Updated.

Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
 More like following
    When 1.0 OF Header version is encountered (no need for version-negotiation)
            - Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered
            -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion
            -Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case
            -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "version-detector" in all above pipeline configurations which uses only the header-version?



   

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)



From:        Prasanna Huddar <prasanna.huddar@...>
To:        "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        09/12/2013 10:27 PM
Subject:        [controller-dev] OF Plugin Design Updated.
Sent by:        controller-dev-bounces@...




Hello,

          Updated the Plugin design as per the discussion in Hackfest.

https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


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

Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Robert Varga -X (rovarga - Pantheon Technologies SRO@Cisco) <rovarga@...>
 

I suggest standardizing on 4.0.x. There has been significant API rework for the 4.0.x series. Patch to move bgpcep forward to 4.0.8 is forthcoming.

 

Bye,

Robert

 

From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Friday, September 13, 2013 1:37 AM
To: Abhijit Kumbhare
Cc: Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject: Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

 

We may want to settle onto a single version of netty throughout ODL… here's what I see so far:

 

bgpcep: 

<netty.version>4.0.7.Final</netty.version>

 

openflowjava:

 <dependency>

       <groupId>org.jboss.netty</groupId>

       <artifactId>netty</artifactId>

       <version>3.2.6.Final</version>

 </dependency>

 

ovsdb:

<dependency>

     <groupId>io.netty</groupId>

     <artifactId>netty-all</artifactId>

     <version>4.0.8.Final</version>

</dependency>

 

Ed

 

On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>

 wrote:



The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.




Hi Abhijit, 

I think I was not quiet clear

My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin 

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1) 



From:        Abhijit Kumbhare <abhijitk@...> 
To:        Christopher Price <christopher.price@...> 
Cc:        "controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...> 
Date:        09/13/2013 01:45 AM 
Subject:        Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated. 




The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.

<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From: Christopher Price <christopher.price@...>
To: Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc: "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date: 09/12/2013 01:09 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by: openflowjava-dev-bounces@...




Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From: Muthukumaran Kothandaraman <mkothand@...>
Date: Thursday, September 12, 2013 12:57 PM
To: Prasanna Huddar <prasanna.huddar@...>
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [controller-dev] OF Plugin Design Updated.

Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
  More like following 
     When 1.0 OF Header version is encountered (no need for version-negotiation)
             - Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler" 

     When 1.3 OF Header version is encountered
             -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion
             -Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case
             -Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

 And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "version-detector" in all above pipeline configurations which uses only the header-version? 



     

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1) 



From:        Prasanna Huddar <prasanna.huddar@...>
To:        "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        09/12/2013 10:27 PM
Subject:        [controller-dev] OF Plugin Design Updated.
Sent by:        controller-dev-bounces@...




Hello,

           Updated the Plugin design as per the discussion in Hackfest.

https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev

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

 
Integration collaboration

Luis Gomez <luis.gomez@...>
 

Hi ovsdb developers,

 

In case you do not know we have created a new project in OpenDaylight with the goal of coordinating release, integration and test efforts across all projects.

 

The project has already gathered a few people willing to collaborate, however as I stated on the last week Hackfest: we have a strong dependency on the other projects, this is we cannot do much without your support.

 

In particular we need a contact (at least one) person in your team who can:

 

1) Sign-up the vHackfest proposed by Ed (see below) so that we are sure we fulfill M3 Continuous Integration Test Start requirement. Note this is IMMEDIATE need (by tomorrow).

2) Answer general questions about test procedures and quality regarding your project

3) Provide a high-level overview of your deliverable features (especially those subject to test) so that we can have a consistent release and also better plan for the final tests

 

I hope I hear from you very soon

 

Thanks in advance

/Luis

 

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Sunday, September 15, 2013 6:27 PM
To: discuss@...
Subject: Re: [OpenDaylight Discuss] Integration vHackfest Next Week

 

I've put up a page for the vHackFest here:

 

 

Please make sure at least one person from each project signs up there

to participate in the vHackFest on Thursday no later than Mon Sept 16 so we can all meet the M3 Continuous Integration

Test Start requirement.

 

Ed

On Sep 12, 2013, at 7:11 PM, Ed Warnicke (eaw) <eaw@...> wrote:

 

According to the Hydrogen Release Plan:

https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2013

We should commence continuous integration testing no later than next week.

In order to facilitate that its been suggested we do a vHackfest next week to insure that each project:

1)  Has at least some integration testing running
2)  Has a Jenkins Job that kick off when a project it depends on changes

The basic thought is to kick off on IRC with Webex's available for screensharing/voice collaboration
over a 24 hours period (not expecting folks to stay up 24 hours… work your normal hours, but we are a
global team)  My initial thought was kicking off at

10am CEST (Rome, Brataslava) on Thu Sept 19 (aka 1am PST on Thur Sept 19)
end at
10am CEST Fri Sept 20 (aka 1am PST on Fri Sept 20)

How do those times work for folks?  Can I get at least one volunteer from each project?

Ed

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 
hacking around

Zhipeng Huang <zhipengh512@...>
 

Hi, I've successfully build ovsdb, is there a guide for hack around the code?

--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Phone: 949-419-4241
Office: Calit2 Building Room 2402
Re: hacking around

Madhu Venugopal (vmadhu) <vmadhu@...>
 

Hi,

The OVSDB infrastructure code is undergoing a major revamp.
  1. We are moving away from jsonrpc4j towards netty based custom 2-way JSON-RPC implementation.
  2. Moving away from String and custom message parsing towards Jackson Marshalling/Demarshalling to POJOs directly.
  3. Better Monitor / Update handling
  4. Protocol Library / Plugin separation.
Hacking with the current existing code will be rendered unusable soon.
So, I would suggest to hold off on that.

If you are interested in contributing to any of the above topics, please let me know.

Thanks,
Madhu

From: Zhipeng Huang <zhipengh512@...>
Date: Thursday, September 19, 2013 10:07 AM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Subject: [ovsdb-dev] hacking around

Hi, I've successfully build ovsdb, is there a guide for hack around the code?

--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Phone: 949-419-4241
Office: Calit2 Building Room 2402

hacking around

Zhipeng Huang <zhipengh512@...>
 



---------- Forwarded message ----------
From: Zhipeng Huang <zhipengh512@...>
Date: Thu, Sep 19, 2013 at 11:45 AM
Subject: Re: [ovsdb-dev] hacking around
To: "Madhu Venugopal (vmadhu)" <vmadhu@...>


hi madhu, 

thanks for the reply, I'm pretty new to this, i think i maybe could contribute to 4, could you provide more info on that subject? THX a lot


On Thu, Sep 19, 2013 at 11:41 AM, Madhu Venugopal (vmadhu) <vmadhu@...> wrote:
Hi,

The OVSDB infrastructure code is undergoing a major revamp.
  1. We are moving away from jsonrpc4j towards netty based custom 2-way JSON-RPC implementation.
  2. Moving away from String and custom message parsing towards Jackson Marshalling/Demarshalling to POJOs directly.
  3. Better Monitor / Update handling
  4. Protocol Library / Plugin separation.
Hacking with the current existing code will be rendered unusable soon.
So, I would suggest to hold off on that.

If you are interested in contributing to any of the above topics, please let me know.

Thanks,
Madhu

From: Zhipeng Huang <zhipengh512@...>
Date: Thursday, September 19, 2013 10:07 AM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Subject: [ovsdb-dev] hacking around

Hi, I've successfully build ovsdb, is there a guide for hack around the code?

--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Office: Calit2 Building Room 2402



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Office: Calit2 Building Room 2402



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Phone: 949-419-4241
Office: Calit2 Building Room 2402
Jenkins issue preventing integration

Ed Warnicke (eaw) <eaw@...>
 

Guys,
I am trying to put together the integration project's distribution directories for the various versions.
As part of that, I am finding a problem with integrating OVSDB into the virtualization edition. The good news is its
a simple problem :)

I am pulling in:

<dependency>
<groupId>org.opendaylight.ovsdb</groupId>
<artifactId>ovsdb</artifactId>
<version>0.4.0-SNAPSHOT</version>
</dependency>

and getting an error:

[ERROR] Failed to execute goal on project distributions-virtualization: Could not resolve dependencies for project org.opendaylight.integration:distributions-virtualization:pom:0.1.0-SNAPSHOT: Failed to collect dependencies for [org.opendaylight.integration:distributions-base:zip:osgipackage:0.1.0-SNAPSHOT (provided), org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT (compile)]: Failed to read artifact descriptor for org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT: Could not find artifact org.opendaylight.ovsdb:commons.ovsdb:pom:1.0.0-SNAPSHOT in jsonrpc4j-webdav-maven-repo (${nexus.proxy}/repositories/jsonrpc4j-webdav-maven-repo/) -> [Help 1]

Basically, what's happening is that your commons/parent/pom.xml is not being pushed to Nexus… but since the ovsdb maven… but its needed as a dependency.
If you guys could just make sure your Jenkin's jobs (both verify and merge) build from pom commons/parent/pom.xml so that everything gets pushed properly out
to Nexus that would clean this right out :)

Ed
Re: Jenkins issue preventing integration

Evan Zeller <evanrzeller@...>
 

Taken care of, thanks Ed!

Evan


On Mon, Sep 30, 2013 at 10:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
        I am trying to put together the integration project's distribution directories for the various versions.
As part of that, I am finding a problem with integrating OVSDB into the virtualization edition.  The good news is its
 a simple problem :)

        I am pulling in:

    <dependency>
      <groupId>org.opendaylight.ovsdb</groupId>
      <artifactId>ovsdb</artifactId>
      <version>0.4.0-SNAPSHOT</version>
    </dependency>

and getting an error:

[ERROR] Failed to execute goal on project distributions-virtualization: Could not resolve dependencies for project org.opendaylight.integration:distributions-virtualization:pom:0.1.0-SNAPSHOT: Failed to collect dependencies for [org.opendaylight.integration:distributions-base:zip:osgipackage:0.1.0-SNAPSHOT (provided), org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT (compile)]: Failed to read artifact descriptor for org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT: Could not find artifact org.opendaylight.ovsdb:commons.ovsdb:pom:1.0.0-SNAPSHOT in jsonrpc4j-webdav-maven-repo (${nexus.proxy}/repositories/jsonrpc4j-webdav-maven-repo/) -> [Help 1]

Basically, what's happening is that your commons/parent/pom.xml is not being pushed to Nexus… but since the ovsdb maven… but its needed as a dependency.
If you guys could just make sure your Jenkin's jobs (both verify and merge) build from pom commons/parent/pom.xml so that everything gets pushed properly out
to Nexus that would clean this right out :)

Ed
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Re: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

denghui huang
 

Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57，"Colin Dixon" <ckd@...>写道：

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
> Sent by: controller-dev-bounces@...
>
> Hi
>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.
>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others
> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.
>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 
> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.
>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others
> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
> I second this viewpoint as well.
>
> Thanks,
> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>
>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  
>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?
>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.
>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.
>
> My .02c
>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...
> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.
> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */
>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?
> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.
> But, we have to make sure the functionality is not redundant with
> something that exists already.
> So, please share all the functionalities that this module addresses.
>
> Thanks,
> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?
>
> Hi
>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?
>
> _______________________________________________ controller-dev mailing list
> controller-dev@... https://
> lists.opendaylight.org/mailman/listinfo/controller-dev
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Porting net-virt-platform TunnelManager into ODL?

denghui huang
 

Hi folks,
      Forwarding this to the correct mail list.

---------- Forwarded message ----------
From: huang denghui <huangdenghui@...>
Date: 2013/10/2
Subject: Re: [controller-dev] Porting net-virt-platform TunnelManager into ODL?
To: Colin Dixon <ckd@...>
Cc: controller-dev-bounces@..., "Madhu Venugopal (vmadhu)" <vmadhu@...>, "controller-dev@..." <controller-dev@...>, ovsdb-dev@...


Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57，"Colin Dixon" <ckd@...>写道：

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
> Sent by: controller-dev-bounces@...
>
> Hi
>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.
>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others
> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.
>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 
> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.
>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others
> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
> I second this viewpoint as well.
>
> Thanks,
> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>
>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  
>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?
>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.
>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.
>
> My .02c
>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...
> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.
> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */
>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?
> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.
> But, we have to make sure the functionality is not redundant with
> something that exists already.
> So, please share all the functionalities that this module addresses.
>
> Thanks,
> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?
>
> Hi
>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?
>
> _______________________________________________ controller-dev mailing list
> controller-dev@... https://
> lists.opendaylight.org/mailman/listinfo/controller-dev
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
1 - 20 of 4855