I would say be a realist and not overly complicate things. The Controller must support both OF 1.0 and OF 1.3 SB plugins (it is a multi-protocol controller built for heterogeneous networks and we will see switches some with OF 1.0 and some with OF 1.3 support). The SAL can be extended to expose additional OF 1.3 level support (e.g. IPv6 lookup key or ability to specify a table id, etc.) but one should not force Applications using only OF 1.0 level of support to be rewritten to move to OF 1.3 primitives if they don’t need any OF 1.3 levels.

 

It is fine to use OF 1.0 plugin as seed for OF 1.3 development but do not try to build one OF plugin capable of supporting both OF 1.0 and OF 1.3. OF protocols were not designed with backward compatibility in mind. IMHO that makes development of OF 1.3 plugin simpler and also retains the modularity principle.

 

My $0.02

 

Thanks,

 

Bhushan

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Christopher Price
Sent: Tuesday, July 23, 2013 2:25 PM
To: Abhijit Kumbhare; Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
Cc: controller-dev-bounces@...; controller-dev@...; openflowplugin-dev@...
Subject: Re: [controller-dev] Seeding the OpenFlow plugin project

 

Hi Guys,

 

I'm not sure we have a concrete answer on this right now, more discussion is needed to address every-one's thoughts and preferences to arrive at a complete solution.

 

I am currently of the thought that supporting 1.0 can be done as it is today, and even rolled up into a common plugin, we can further implement an interface for 1.3+ switches toward the SAL to support 1.3+ switches.  There are some functions like connectivity management, protocol version negotiation, element/vendor policies that exist outside the message formatting libraries that need to be addressed and can be done so in a consistent way for all protocols.  (having multiple ports exposed toward the network for different versions of the protocol does not inspire thoughts of operational simplicity)

Of course we could then deprecate the 1.0 specific library with a subset of the 1.3 library, but that's an activity that could probably be backlogged rather than a design target for december.  (as I said more discussion needed)

 

Discussion is needed on this, and maybe it should move to the plugin-dev mail lists, to find our common goal for December.

 

/ Chris

 

From: Abhijit Kumbhare <abhijitk@...>
Date: Tuesday, July 23, 2013 10:45 AM
To: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
Cc: Anilkumar Vishnoi <avishnoi@...>, Ericsson <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: RE: [controller-dev] Seeding the OpenFlow plugin project

 

Not really - the protocol plugin and the SAL will both expose the additional OpenFlow 1.3 features/abstractions to the applications - while continuing to expose the OpenFlow 1.0 compatible subset for existing OpenFlow 1.0 applications (we do have those applications and we do not want them to suddenly stop working till we update those).

By the way please check out the work items from the slides we discussed last Wednesday (attached here for the broader audience):

(See attached file: Openflow1.3 Support for Opendaylight.pdf)

Please check in particular slides 11-15 for changes in the protocol common structures; slides 18-24 for the controller-switch protocol messages and slides 26-27 for the connection mechanisms. They provide the info of the changes required in the OpenFlowJ, the protocol plugin and the SAL. I could not fully attend the model driven SAL discussions yesterday - but from my discussion with Giovanni my feeling is that we will need the same kind of SAL changes but via different mechanism (YANG).

"Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" ---07/23/2013 10:12:21 AM---So my understanding is your primary target is to expose Openflow 1.0 compatible subset of Openflow 1

From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS, Christopher Price <christopher.price@...>, Anilkumar Vishnoi <avishnoi@...>,
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date: 07/23/2013 10:12 AM
Subject: RE: [controller-dev] Seeding the OpenFlow plugin project

---

So my understanding is your primary target is to expose Openflow 1.0 compatible subset of Openflow 1.3 to applications.
I would rather go with new implementation which will be Openflow 1.3 or Openflow 1.4 inspired...and expose Openflow 1.0 switches
as less capable 1.3 switches (only one table, only base matches, limited subset of actions).
 
Tony
 
From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Tuesday, July 23, 2013 7:02 PM
To: Christopher Price; Anilkumar Vishnoi
Cc: controller-dev@...; controller-dev-bounces@...
Subject: Re: [controller-dev] Seeding the OpenFlow plugin project
 

Hi Chris,

We (in IBM at least) had been thinking of the following approach (diagrams copy pasted from an earlier discussion between ourselves - whereever OpenFlow 1.0.0 is mentioned - please consider it as OpenFlowJ for 1.0 and OpenFlow 1.3.1 consider it as OpenFlowJ for 1.3):




   
Our new code which we will implement should take care of openflow 1.3.1 protocol only ( mainly openflowj driver part). We will use same protocol_plugin code and enhance it so that it will interact with both the openflowj driver ( 1.0 and 1.3). So make it more clear we can say that we have new driver that will interact with openflow 1.3.1 enabled devices and protcol_plugin is been extended to provide the abstraction conversion from SAL to openflowj (1.3).

We were not thinking of the following:


Reasons:

1. We did not think an additional protocol plugin was needed to be added.
2. The version negotiation (OpenFlow 1.0 or 1.3 or any future) would need to be handled in the protocol plugin and not SAL.

Anil may have additional reasons.

Thanks,
Abhijit

Christopher Price ---07/23/2013 09:23:40 AM---As we are now beginning to establish the OpenFlow plugin project with a focus on building an OpenFlo

From: Christopher Price <christopher.price@...>
To: "controller-dev@..." <controller-dev@...>,
Date: 07/23/2013 09:23 AM
Subject: [controller-dev] Seeding the OpenFlow plugin project
Sent by: controller-dev-bounces@...

---

As we are now beginning to establish the OpenFlow plugin project with a focus on building an OpenFlow 1.3 enabled plugin we as a project team are looking to start pushing code as quickly as possible.  

As a way of getting started on the OF 1.3 plugin project I would like to ask the controller-dev community if it is OK to use the existing OF 1.0 plugin as seeding software for the team to begin to work with.  This would involve cloning the OF 1.0 plugin software into the openflowplugin repo and letting the project team get started on 1.3 capabilities with a plugin that has integration to the controller as a baseline for the plugin OSGI software.  

I'd appreciate any feedback and input from the community on this approach.  If everyone is OK we will go ahead and try to get things rolling as quickly as possible.

/ Chris_______________________________________________
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