Date   

Re: [controller-dev] Seeding the OpenFlow plugin project

Tony Tkacik
 

Hi David,

There is project for multiprotocol Openflow library started in Opendaylight (openflowjava)

https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main
https://wiki.opendaylight.org/view/Project_Proposals:Openflow_1.3_Protocol_Library

 

they plan to start with Openflow 1.3 and support later versions, they want to use Netty.io,

which could allow switching / modifiyng processing pipeline based on received data and

provides nice set of reusable features for protocol libraries.

The same library (netty.io) will be used also for PCEP and BGP protocol libraries.

 

Tony

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of David Erickson
Sent: Wednesday, July 24, 2013 5:00 PM
To: controller-dev@...; openflowplugin-dev@...
Subject: Re: [controller-dev] Seeding the OpenFlow plugin project

 

My personal opinion, and something that I intend to work on is an OFJ layer that is capable of handling multiple versions of the OF protocol below its outward facing interface.  Not all controllers/projects that use OFJ have a SAL that can hide completely separate versions of OF protocol plugins.  I would be interested to know who would like to write code on such a project (not just discuss), feel free to take that email off the list if you'd like.

-D

On 7/23/2013 6:39 PM, Bhushan Kanekar (bkanekar) wrote:

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

 


Openflow Protocol Library

Michal Polkorab
 

Greetings,

I am sending you presentation used on Openflow Protocol Library meeting.
We would like to hear your comments and questions regarding the project's architecture and design.

Michal Polkorab


Re: [controller-dev] Openflow Protocol Library

Colin Dixon <ckd@...>
 

I think that it would be useful to think about how this was going to work in comparison to the pipeline/tools that we have today.

I had originally that that this was a replacement for OpenFlowJ, but with OF1.3 support. OpenFlowJ really only provides OpenFlow data types, message serialization and deserialization. (There's also a simple controller in there, but really just to demo how you might use the OpenFlowJ library.) Instead, this looks like it provides significantly more functionality that that.

I think that's because it was trying to sit "logically below" the OpenFlow plugin project and so it needs to handle connections, version negotiation and the like. Instead, the current OpenFlowJ is actually just a static library which sits inside (or is just used by) the protocol_plugins.openflow bundle without actually sitting below it.

--Colin

controller-dev-bounces@... wrote on 08/05/2013 01:28:55 PM:
> From: michal.polkorab@...

> To: openflowplugin-dev@..., controller-
> dev@..., openflowjava-dev@...

> Date: 08/05/2013 01:39 PM
> Subject: [controller-dev] Openflow Protocol Library
> Sent by: controller-dev-bounces@...
>
> Greetings,
>
> I am sending you presentation used on Openflow Protocol Library meeting.
> We would like to hear your comments and questions regarding the
> project's architecture and design.
>
> Michal Polkorab[attachment "Openflow Protocol Library.pdf" deleted
> by Colin Dixon/Austin/IBM] _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: [controller-dev] Openflow Protocol Library

Baohua Yang <yangbaohua@...>
 

I suggest to take care of handling different of versions, providing enough flexibility for user selection.
Seems the of protocol is growing to another complicated stack...
Also, the pipeline part, not clear will affect the latency too much.

btw, there's some typo on page 6: "genaretion" :)


On Tue, Aug 6, 2013 at 2:28 AM, <michal.polkorab@...> wrote:
Greetings,

I am sending you presentation used on Openflow Protocol Library meeting.
We would like to hear your comments and questions regarding the project's architecture and design.

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




--
Best wishes!
Baohua


OF Protocol Java Library architecture meet-up

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

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel


Testing of OF-1.3

Michal Rehak -X (mirehak - Pantheon Technologies SRO@Cisco) <mirehak@...>
 

Greetings,
there is a testing issue coming up regarding OF-1.3. The plugin and library both need a switch capable of OF-1.3 to develop and test new implementations.

I have successfully tried to update openvirtualswitch driver in the latest (2.0.0) mininet image. Default version of the openvirtualswitch driver is 1.4.3 and the latest released version is 1.10. So now the protocol version can be specified using startup parameters of mn-script.

From openvirtualswitch FAQ:
Open vSwitch 1.10 and later have experimental support for OpenFlow 1.2 and 1.3.
--------------------------

I believe that this can be used for start, but there is definitely a need for a testing network
or site later, where switches with full support of OF-1.3 specification would be available.


Do you have an idea how or where can we (later on) develop and test the OF-1.3 implementations?

Thank you.

Regards,
Michal Rehak



Re: OF Protocol Java Library architecture meet-up

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

That general week sounds good :) Although perhaps Wed & Thur might work better due to 
travel booking.

What do other folks think?

Ed

From: openflowjava-dev-bounces@... [openflowjava-dev-bounces@...] on behalf of Daniel Bartoš [daniel.bartos@...]
Sent: Tuesday, August 06, 2013 8:30 AM
To: openflowjava-dev@...; openflowplugin-dev@...
Subject: [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel


Re: [controller-dev] Openflow Protocol Library

Michal Polkorab
 

Hello,

we have received some reactions / suggestions to our OpenFlow Protocol Library Architecture introduction. From these, we have formulated common questions that we would like to respond to.

Q: What OpenFlow protocol versions will the library support ?
A: The library is designed to support OpenFlow 1.3 right now. However, there are components called OF Version Detector and OF Codec. OF Version Detector detects the version of a wire-protocol from the OpenFlow frame and after the detection the Version Detector chooses the right OpenFlow Codec to process the information. By doing so we can achieve that other versions will be supported too. Another benefit of this approach is that we can use the same port.

Q: What about connection termination ? In case of OF 1.3 the connection is terminated within the library and in case of OF 1.0 the connection is terminated in OF plugin.
A: It is possible to build the wrapper around OpenFlow 1.0 and use it as another Openflow Codec. This way we can terminate the connection within the library.

Q: How big will be the impact of pipeline on the latency ?
A: Pipeline is mentioned as logical division of code, so that reusable components would not be tightly coupled. If we want to support TLS connections, we need to implement this mechanism.

Michal Polkorab


Re: Testing of OF-1.3

Anil Vishnoi
 

Just to add, Following file has track of what all is still need to be done to fully support 1.3 in OVS.


I came across another options (of soft switch ) 


Looks like it has comprehensive support for 1.3, but i didn't get an opportunity to explore it in detail.

Michal, can you please share the repo details from where we can download your modified mininet image ?

Thanks
Anil


On Tue, Aug 6, 2013 at 8:55 PM, Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) <mirehak@...> wrote:

Greetings,
there is a testing issue coming up regarding OF-1.3. The plugin and library both need a switch capable of OF-1.3 to develop and test new implementations.

I have successfully tried to update openvirtualswitch driver in the latest (2.0.0) mininet image. Default version of the openvirtualswitch driver is 1.4.3 and the latest released version is 1.10. So now the protocol version can be specified using startup parameters of mn-script.

From openvirtualswitch FAQ:
Open vSwitch 1.10 and later have experimental support for OpenFlow 1.2 and 1.3.
--------------------------

I believe that this can be used for start, but there is definitely a need for a testing network
or site later, where switches with full support of OF-1.3 specification would be available.


Do you have an idea how or where can we (later on) develop and test the OF-1.3 implementations?

Thank you.

Regards,
Michal Rehak



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




--
Thanks
Anil


Re: [openflowplugin-dev] Testing of OF-1.3

Tony Tkacik
 

From one interop I also remember the soft switch

http://www.flowforwarding.org/

They claim to support Openflow 1.2 and 1.3.1  and OFConfig 1.1

The code is written in Erlang, if I remember correctly.

 

Tony

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Anil Vishnoi
Sent: Tuesday, August 06, 2013 10:10 PM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)
Cc: openflowjava-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] [openflowjava-dev] Testing of OF-1.3

 

Just to add, Following file has track of what all is still need to be done to fully support 1.3 in OVS.

 

 

I came across another options (of soft switch ) 

 

 

Looks like it has comprehensive support for 1.3, but i didn't get an opportunity to explore it in detail.

 

Michal, can you please share the repo details from where we can download your modified mininet image ?

 

Thanks

Anil

 

On Tue, Aug 6, 2013 at 8:55 PM, Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) <mirehak@...> wrote:

Greetings,
there is a testing issue coming up regarding OF-1.3. The plugin and library both need a switch capable of OF-1.3 to develop and test new implementations.

I have successfully tried to update openvirtualswitch driver in the latest (2.0.0) mininet image. Default version of the openvirtualswitch driver is 1.4.3 and the latest released version is 1.10. So now the protocol version can be specified using startup parameters of mn-script.

From openvirtualswitch FAQ:
Open vSwitch 1.10 and later have experimental support for OpenFlow
   1.2 and 1.3.
--------------------------

I believe that this can be used for start, but there is definitely a need for a testing network
or site later, where switches with full support of OF-1.3 specification would be available.



Do you have an idea how or where can we (later on) develop and test the OF-1.3 implementations?

Thank you.

Regards,
Michal Rehak


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



 

--

Thanks

Anil


Re: [controller-dev] Openflow Protocol Library

Christopher Price <christopher.price@...>
 

Hi Michal,

Thanks for providing some opinions on the obvious questions.
I do think we need to dig a little more into the best architecture for the
solution. Not a discussion on the code itself, but how the code fit's
together.

I don't believe the connections should terminate in the library as we want
the library to be a modular component of the solution. I can envision
that the plugin should provide a way to feed the library with packets and
have the library provide an interpretation of those. If another project
or deployer wishes to deploy the ODL controller with a "OF-like" library,
or an alternative OF-Library, and swap out the standard one this should be
manageable without the need to re-write the plugin.

Modularity of the software does not dictate in which repository the
software exists in. I am concerned with the alignment of architecture and
dependancies existing between the SW components in order to create an
easily extensible solution.
We should sketch out the plugin/library components as they will exist and
then discuss the modularity of software that will realize it. I feel that
we have not yet concluded that part of the discussion.

/ Chris




On 8/6/13 1:02 PM, "michal.polkorab@..."
<michal.polkorab@...> wrote:

Hello,

we have received some reactions / suggestions to our OpenFlow Protocol
Library Architecture introduction. From these, we have formulated common
questions that we would like to respond to.

Q: What OpenFlow protocol versions will the library support ?
A: The library is designed to support OpenFlow 1.3 right now. However,
there are components called OF Version Detector and OF Codec. OF Version
Detector detects the version of a wire-protocol from the OpenFlow frame
and after the detection the Version Detector chooses the right OpenFlow
Codec to process the information. By doing so we can achieve that other
versions will be supported too. Another benefit of this approach is that
we can use the same port.

Q: What about connection termination ? In case of OF 1.3 the connection
is terminated within the library and in case of OF 1.0 the connection is
terminated in OF plugin.
A: It is possible to build the wrapper around OpenFlow 1.0 and use it as
another Openflow Codec. This way we can terminate the connection within
the library.

Q: How big will be the impact of pipeline on the latency ?
A: Pipeline is mentioned as logical division of code, so that reusable
components would not be tightly coupled. If we want to support TLS
connections, we need to implement this mechanism.

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


Re: [openflowplugin-dev] Testing of OF-1.3

Michal Rehak -X (mirehak - Pantheon Technologies SRO@Cisco) <mirehak@...>
 

Greetings.

Back to openvswitch - I have done the following in order to get version 1.10 (if you have mininet-2.0.0 already running, please proceed to Stage 2):

Stage 1

- download mininet image 2.0.0 (https://github.com/downloads/mininet/mininet/mininet-2.0.0-113012-amd64-ovf.zip)
- the image is in vmware format I guess, but can by simply imported into virtualbox
- start mininet-2.0.0, login as mininet, password mininet


Stage 2

- uninstall packages openvswitch-common and openvswitch-switch (there should be version 1.4.3 officially in ubuntu repo, so in case of emergency these can be always installed again)
- download latest release of openvswitch: http://openvswitch.org/releases/openvswitch-1.10.0.tar.gz
- there are install howtos, take a look at INSTALL.Debian
- there are some new packages to be installed (apt-get install build-essential fakeroot)
- run dpkg-checkbuilddeps to check, if all dependencies are installed
- here comes the long step 4. from INSTALL.Debian
- if everything compiled successfully, you should have these deb files in parent folder:

openvswitch-common_1.10.0-1_amd64.deb
openvswitch-controller_1.10.0-1_amd64.deb
openvswitch-datapath-dkms_1.10.0-1_all.deb
openvswitch-datapath-source_1.10.0-1_all.deb
openvswitch-dbg_1.10.0-1_amd64.deb
openvswitch-ipsec_1.10.0-1_amd64.deb
openvswitch-pki_1.10.0-1_all.deb
openvswitch-switch_1.10.0-1_amd64.deb
openvswitch-test_1.10.0-1_all.deb
ovsdbmonitor_1.10.0-1_all.deb
python-openvswitch_1.10.0-1_all.deb


- now install
dpkg -i openvswitch-common_1.10.0-1_amd64.deb
dpkg -i openvswitch-switch_1.10.0-1_amd64.deb

- now mininet should be using openvswitch 1.10.0, this can be simply tested by running ODL-controller and let mininet to connect to it.

- to use OF-1.3 following parameter has to be passed to openvswitch startup command:
protocols=OpenFlow13

So I made following change to node.py file (mininet python class, be sure to modify the distributed file, not the one in /home/mininet/mininet/...) in order to control the protocol version using cmd parameter:

--- ../mininet/build/lib.linux-x86_64-2.7/mininet/node.py       2012-11-30 22:30:07.000000000 -0800
+++ /usr/local/lib/python2.7/dist-packages/mininet-2.0.0-py2.7.egg/mininet/node.py      2013-07-25 05:40:26.179978120 -0700
@@ -901,6 +904,11 @@
            failMode: controller loss behavior (secure|open)"""
         Switch.__init__( self, name, **params )
         self.failMode = failMode
+        protKey = 'protocols'
+        if self.params and protKey in self.params:
+            print 'have protocol params!'
+            self.opts += protKey + '=' + self.params[protKey]
+
 
     @classmethod
     def setup( cls ):
@@ -955,8 +964,9 @@
         # Annoyingly, --if-exists option seems not to work
         self.cmd( 'ovs-vsctl del-br', self )
         self.cmd( 'ovs-vsctl add-br', self )
+        print 'OVSswitch opts: ',self.opts
         self.cmd( 'ovs-vsctl -- set Bridge', self,
-                  'other_config:datapath-id=' + self.dpid )
+                  self.opts+' other_config:datapath-id=' + self.dpid )
         self.cmd( 'ovs-vsctl set-fail-mode', self, self.failMode )
         for intf in self.intfList():
             if not intf.IP():


The mn session can now be started:
sudo mn --topo single,3  --controller 'remote,ip=<your controller IP>' --switch ovsk,protocols=OpenFlow10
or
sudo mn --topo single,3  --controller 'remote,ip=<your controller IP>' --switch ovsk,protocols=OpenFlow13

To test the version of used protocol by switch "s1":

ovs-ofctl -O OpenFlow10 show s1
ovs-ofctl -O OpenFlow13 show s1


If this is useful, I can put it on wiki. If you have any suggestions or improvements, please let me know. The image of virtual machine is huge (3.6 GB), but size of neccessary deb files is only 2 MB, so maybe I can upload them somewhere.


From: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
Sent: Tuesday, August 06, 2013 11:09 PM
To: Anil Vishnoi; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)
Cc: openflowjava-dev@...; openflowplugin-dev@...
Subject: RE: [openflowplugin-dev] [openflowjava-dev] Testing of OF-1.3

From one interop I also remember the soft switch

http://www.flowforwarding.org/

They claim to support Openflow 1.2 and 1.3.1  and OFConfig 1.1

The code is written in Erlang, if I remember correctly.

 

Tony

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Anil Vishnoi
Sent: Tuesday, August 06, 2013 10:10 PM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)
Cc: openflowjava-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] [openflowjava-dev] Testing of OF-1.3

 

Just to add, Following file has track of what all is still need to be done to fully support 1.3 in OVS.

 

 

I came across another options (of soft switch ) 

 

 

Looks like it has comprehensive support for 1.3, but i didn't get an opportunity to explore it in detail.

 

Michal, can you please share the repo details from where we can download your modified mininet image ?

 

Thanks

Anil

 

On Tue, Aug 6, 2013 at 8:55 PM, Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) <mirehak@...> wrote:

Greetings,
there is a testing issue coming up regarding OF-1.3. The plugin and library both need a switch capable of OF-1.3 to develop and test new implementations.

I have successfully tried to update openvirtualswitch driver in the latest (2.0.0) mininet image. Default version of the openvirtualswitch driver is 1.4.3 and the latest released version is 1.10. So now the protocol version can be specified using startup parameters of mn-script.

From openvirtualswitch FAQ:
Open vSwitch 1.10 and later have experimental support for OpenFlow
   1.2 and 1.3.
--------------------------

I believe that this can be used for start, but there is definitely a need for a testing network
or site later, where switches with full support of OF-1.3 specification would be available.



Do you have an idea how or where can we (later on) develop and test the OF-1.3 implementations?

Thank you.

Regards,
Michal Rehak


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



 

--

Thanks

Anil


Re: OF Protocol Java Library architecture meet-up

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


What do you, other folks, think???

Does it make sense for you to meet face-to-face yet before next Hackfest scheduled September 10&11? Pantheon will be present at this Hackfest.

Daniel



From: "Ed Warnicke (eaw)" <eaw@...>
To: "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@...
Sent: Tuesday, August 6, 2013 8:12:26 PM
Subject: RE: OF Protocol Java Library architecture meet-up

That general week sounds good :) Although perhaps Wed & Thur might work better due to 
travel booking.

What do other folks think?

Ed

From: openflowjava-dev-bounces@... [openflowjava-dev-bounces@...] on behalf of Daniel Bartoš [daniel.bartos@...]
Sent: Tuesday, August 06, 2013 8:30 AM
To: openflowjava-dev@...; openflowplugin-dev@...
Subject: [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel



Re: [openflowplugin-dev] [controller-dev] Openflow Protocol Library

Anil Vishnoi
 

Hi,

I agree with the point made by Chris. 

In the current architecture one of the main responsibility of southbound protocol plugin is to handle connections with network devices. Other responsibilities of the protocol plugin ( discovery/inventory service, data packet service, stats collection, SAL abstraction to protocol message conversion  etc) are kind of dependent on the connection handling service. In the proposed design of protocol library, I think pipeline processing and concept of facade is interesting and possibly required components from the perspective that we will have multiple version of openflow spec (without backward compatibility) or multiple implementation of protocol library. 

IMHO component 1 to 5 & 7 of the pipeline processing (slide 13), can be part of the southbound protocol plugin. Component 1 to 5 can help in building comprehensive connection handling service that can support existing openflow 1.0 & 1.3 protocols connection mechanism, as well as future enhancement in this area. Component 6 (OF 1.3 CoDec) can be a static library on the similar line of current openflowj, or based on Yang as proposed in the design. Component 7 (Facade) can be extended to support both the OF 1.0 & 1.3 CoDec ( or may be its a redundant component). In that way I think it will require minimal changes in the existing architecture and will satisfy the requirement of proposed design.

From the slide decks I didn't actually get very strong rationale or use case for implementing this mechanism in the protocol library compared to the southbound protocol plugin, until and unless I am missing something in this context. These opinions are based on my understanding of the existing ODL architecture  and interpretation of the slide decks (which may be wrong :) ), so please feel free to correct me or +1/-1.

Thanks
Anil Vishnoi



On Wed, Aug 7, 2013 at 9:24 AM, Christopher Price <christopher.price@...> wrote:
Hi Michal,

Thanks for providing some opinions on the obvious questions.
I do think we need to dig a little more into the best architecture for the
solution.  Not a discussion on the code itself, but how the code fit's
together.

I don't believe the connections should terminate in the library as we want
the library to be a modular component of the solution.  I can envision
that the plugin should provide a way to feed the library with packets and
have the library provide an interpretation of those.  If another project
or deployer wishes to deploy the ODL controller with a "OF-like" library,
or an alternative OF-Library, and swap out the standard one this should be
manageable without the need to re-write the plugin.

Modularity of the software does not dictate in which repository the
software exists in.  I am concerned with the alignment of architecture and
dependancies existing between the SW components in order to create an
easily extensible solution.
We should sketch out the plugin/library components as they will exist and
then discuss the modularity of software that will realize it.  I feel that
we have not yet concluded that part of the discussion.

/ Chris




On 8/6/13 1:02 PM, "michal.polkorab@..."
<michal.polkorab@...> wrote:

>Hello,
>
>we have received some reactions / suggestions to our OpenFlow Protocol
>Library Architecture introduction. From these, we have formulated common
>questions that we would like to respond to.
>
>Q: What OpenFlow protocol versions will the library support ?
>A: The library is designed to support OpenFlow 1.3 right now. However,
>there are components called OF Version Detector and OF Codec. OF Version
>Detector detects the version of a wire-protocol from the OpenFlow frame
>and after the detection the Version Detector chooses the right OpenFlow
>Codec to process the information. By doing so we can achieve that other
>versions will be supported too. Another benefit of this approach is that
>we can use the same port.
>
>Q: What about connection termination ? In case of OF 1.3 the connection
>is terminated within the library and in case of OF 1.0 the connection is
>terminated in OF plugin.
>A: It is possible to build the wrapper around OpenFlow 1.0 and use it as
>another Openflow Codec. This way we can terminate the connection within
>the library.
>
>Q: How big will be the impact of pipeline on the latency ?
>A: Pipeline is mentioned as logical division of code, so that reusable
>components would not be tightly coupled. If we want to support TLS
>connections, we need to implement this mechanism.
>
>Michal Polkorab
>_______________________________________________
_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev



--
Thanks
Anil


Re: OF Protocol Java Library architecture meet-up

Christopher Price <christopher.price@...>
 

Hi Daniel,

I was hoping for some response from remote attendee's but the dates look fine to me.  We can make this work, at the very least we should have Abhijit and the Ericsson team available.
The quicker we can get on the right track regarding the software we need to write the better.

/ Chris

From: Daniel Bartoš <daniel.bartos@...>
Date: Thursday, August 8, 2013 2:20 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [openflowjava-dev] OF Protocol Java Library architecture meet-up


What do you, other folks, think???

Does it make sense for you to meet face-to-face yet before next Hackfest scheduled September 10&11? Pantheon will be present at this Hackfest.

Daniel



From: "Ed Warnicke (eaw)" <eaw@...>
To: "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@...
Sent: Tuesday, August 6, 2013 8:12:26 PM
Subject: RE: OF Protocol Java Library architecture meet-up

That general week sounds good :) Although perhaps Wed & Thur might work better due to 
travel booking.

What do other folks think?

Ed

From: openflowjava-dev-bounces@... [openflowjava-dev-bounces@...] on behalf of Daniel Bartoš [daniel.bartos@...]
Sent: Tuesday, August 06, 2013 8:30 AM
To: openflowjava-dev@...; openflowplugin-dev@...
Subject: [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel



Re: OF Protocol Java Library architecture meet-up

Anil Vishnoi
 

Hi Chris,

Abhijit is on vacation till 12th, so he will probably respond his availability once he will get back.

Thanks
Anil


On Fri, Aug 9, 2013 at 11:19 AM, Christopher Price <christopher.price@...> wrote:
Hi Daniel,

I was hoping for some response from remote attendee's but the dates look fine to me.  We can make this work, at the very least we should have Abhijit and the Ericsson team available.
The quicker we can get on the right track regarding the software we need to write the better.

/ Chris

From: Daniel Bartoš <daniel.bartos@...>
Date: Thursday, August 8, 2013 2:20 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [openflowjava-dev] OF Protocol Java Library architecture meet-up


What do you, other folks, think???

Does it make sense for you to meet face-to-face yet before next Hackfest scheduled September 10&11? Pantheon will be present at this Hackfest.

Daniel



From: "Ed Warnicke (eaw)" <eaw@...>
To: "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@...
Sent: Tuesday, August 6, 2013 8:12:26 PM
Subject: RE: OF Protocol Java Library architecture meet-up

That general week sounds good :) Although perhaps Wed & Thur might work better due to 
travel booking.

What do other folks think?

Ed

From: openflowjava-dev-bounces@... [openflowjava-dev-bounces@...] on behalf of Daniel Bartoš [daniel.bartos@...]
Sent: Tuesday, August 06, 2013 8:30 AM
To: openflowjava-dev@...; openflowplugin-dev@...
Subject: [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel



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




--
Thanks
Anil


Re: [openflowplugin-dev] [controller-dev] Openflow Protocol Library

Michal Polkorab
 

Hello,

i would like to summarize our thoughts behind OF Protocol Library architecture and react to given suggestions.


In the current architecture one of the main responsibility of southbound
protocol plugin is to handle connections with network devices.
I agree. But it is not defined how southbound protocol plugin has to implement this functionality - if it must be implemented directly or if the plugin can use other component (or library) to achieve this.


Other responsibilities of the protocol plugin ( discovery/inventory service, data
packet service, stats collection, SAL abstraction to protocol message
conversion etc) are kind of dependent on the connection handling service.
With right API design connection handling could be exposed to the plugin and the plugin could still control things like acceptance on session, capability negotiation and other funcionalities. However, base pieces of this functionality could be in library.


In the proposed design of protocol library, I think pipeline processing and
concept of facade is interesting and possibly required components from the
perspective that we will have multiple version of openflow spec (without
backward compatibility) or multiple implementation of protocol library.

IMHO component 1 to 5 & 7 of the pipeline processing (slide 13), can be part
of the southbound protocol plugin. Component 1 to 5 can help in building
comprehensive connection handling service that can support existing openflow
1.0 & 1.3 protocols connection mechanism, as well as future enhancement in
this area.
The location of code and functionality in OF protocol library vs. southbound plugin does not prevent creating comprehensive solution, but this functionality is not southbound protocol plugin specific. With right API design, the plugin could use or customize it to its specific needs.


Component 6 (OF 1.3 CoDec) can be a static library on the similar
line of current openflowj, or based on Yang as proposed in the design.
Component 7 (Facade) can be extended to support both the OF 1.0 & 1.3 CoDec
( or may be its a redundant component). In that way I think it will require
minimal changes in the existing architecture and will satisfy the
requirement of proposed design.

From the slide decks I didn't actually get very strong rationale or use case
for implementing this mechanism in the protocol library compared to the
southbound protocol plugin, until and unless I am missing something in this
context.
By implementing this architecture model in the protocol library it allows library to be used also outside of the controller without the need to extract logic from the southbound protocol plugin.



Michal Polkorab


Re: [openflowplugin-dev] OF Protocol Java Library architecture meet-up

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

Chris, Daniel, Anees,
     Given the close time frame and the need for folks to travel, I'd suggest bumping back a week (say to Aug 28-29).
Does that work for folks?

Ed

From: openflowplugin-dev-bounces@... [openflowplugin-dev-bounces@...] on behalf of Christopher Price [christopher.price@...]
Sent: Friday, August 09, 2013 12:49 AM
To: Daniel Bartoš; openflowjava-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi Daniel,

I was hoping for some response from remote attendee's but the dates look fine to me.  We can make this work, at the very least we should have Abhijit and the Ericsson team available.
The quicker we can get on the right track regarding the software we need to write the better.

/ Chris

From: Daniel Bartoš <daniel.bartos@...>
Date: Thursday, August 8, 2013 2:20 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [openflowjava-dev] OF Protocol Java Library architecture meet-up


What do you, other folks, think???

Does it make sense for you to meet face-to-face yet before next Hackfest scheduled September 10&11? Pantheon will be present at this Hackfest.

Daniel



From: "Ed Warnicke (eaw)" <eaw@...>
To: "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@...
Sent: Tuesday, August 6, 2013 8:12:26 PM
Subject: RE: OF Protocol Java Library architecture meet-up

That general week sounds good :) Although perhaps Wed & Thur might work better due to 
travel booking.

What do other folks think?

Ed

From: openflowjava-dev-bounces@... [openflowjava-dev-bounces@...] on behalf of Daniel Bartoš [daniel.bartos@...]
Sent: Tuesday, August 06, 2013 8:30 AM
To: openflowjava-dev@...; openflowplugin-dev@...
Subject: [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel



Re: [openflowplugin-dev] OF Protocol Java Library architecture meet-up

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

Hi Ed,
I was going to say that to start making travel arrangements for us to be there Aug 20, it would be rather difficult now.

We will make arrangements to be there and meet you on Aug 28-29. I hope IBM and Ericsson can arrange their plans to make it too!
The question is where shall we meet? It would be great if anybody of you can help arrange premises for whole-day meet-up Aug 28 & 29. Please let me know.

Daniel


From: "Ed Warnicke (eaw)" <eaw@...>
To: "Christopher Price" <christopher.price@...>, "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@..., "Anees A Shaikh" <aashaikh@...>
Sent: Friday, August 9, 2013 2:40:48 PM
Subject: RE: [openflowplugin-dev] [openflowjava-dev] OF Protocol Java        Library architecture meet-up

Chris, Daniel, Anees,
     Given the close time frame and the need for folks to travel, I'd suggest bumping back a week (say to Aug 28-29).
Does that work for folks?

Ed

From: openflowplugin-dev-bounces@... [openflowplugin-dev-bounces@...] on behalf of Christopher Price [christopher.price@...]
Sent: Friday, August 09, 2013 12:49 AM
To: Daniel Bartoš; openflowjava-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi Daniel,

I was hoping for some response from remote attendee's but the dates look fine to me.  We can make this work, at the very least we should have Abhijit and the Ericsson team available.
The quicker we can get on the right track regarding the software we need to write the better.

/ Chris

From: Daniel Bartoš <daniel.bartos@...>
Date: Thursday, August 8, 2013 2:20 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [openflowjava-dev] OF Protocol Java Library architecture meet-up


What do you, other folks, think???

Does it make sense for you to meet face-to-face yet before next Hackfest scheduled September 10&11? Pantheon will be present at this Hackfest.

Daniel



From: "Ed Warnicke (eaw)" <eaw@...>
To: "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@...
Sent: Tuesday, August 6, 2013 8:12:26 PM
Subject: RE: OF Protocol Java Library architecture meet-up

That general week sounds good :) Although perhaps Wed & Thur might work better due to 
travel booking.

What do other folks think?

Ed

From: openflowjava-dev-bounces@... [openflowjava-dev-bounces@...] on behalf of Daniel Bartoš [daniel.bartos@...]
Sent: Tuesday, August 06, 2013 8:30 AM
To: openflowjava-dev@...; openflowplugin-dev@...
Subject: [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel




Re: [openflowplugin-dev] OF Protocol Java Library architecture meet-up

Christopher Price <christopher.price@...>
 

Hi All,

I have reserved a room for the first day, 28th August.
I can likely find another room for the other day somewhere in the bowels of our building, but we could always change sites per day.

Let me know what we prefer.

/ chris


From: Daniel Bartoš <daniel.bartos@...>
Date: Friday, August 9, 2013 5:57 AM
To: Ed Warnicke <eaw@...>
Cc: Ericsson <christopher.price@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, Anees A Shaikh <aashaikh@...>
Subject: Re: [openflowplugin-dev] [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi Ed,
I was going to say that to start making travel arrangements for us to be there Aug 20, it would be rather difficult now.

We will make arrangements to be there and meet you on Aug 28-29. I hope IBM and Ericsson can arrange their plans to make it too!
The question is where shall we meet? It would be great if anybody of you can help arrange premises for whole-day meet-up Aug 28 & 29. Please let me know.

Daniel


From: "Ed Warnicke (eaw)" <eaw@...>
To: "Christopher Price" <christopher.price@...>, "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@..., "Anees A Shaikh" <aashaikh@...>
Sent: Friday, August 9, 2013 2:40:48 PM
Subject: RE: [openflowplugin-dev] [openflowjava-dev] OF Protocol Java        Library architecture meet-up

Chris, Daniel, Anees,
     Given the close time frame and the need for folks to travel, I'd suggest bumping back a week (say to Aug 28-29).
Does that work for folks?

Ed

From: openflowplugin-dev-bounces@... [openflowplugin-dev-bounces@...] on behalf of Christopher Price [christopher.price@...]
Sent: Friday, August 09, 2013 12:49 AM
To: Daniel Bartoš; openflowjava-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi Daniel,

I was hoping for some response from remote attendee's but the dates look fine to me.  We can make this work, at the very least we should have Abhijit and the Ericsson team available.
The quicker we can get on the right track regarding the software we need to write the better.

/ Chris

From: Daniel Bartoš <daniel.bartos@...>
Date: Thursday, August 8, 2013 2:20 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject: Re: [openflowjava-dev] OF Protocol Java Library architecture meet-up


What do you, other folks, think???

Does it make sense for you to meet face-to-face yet before next Hackfest scheduled September 10&11? Pantheon will be present at this Hackfest.

Daniel



From: "Ed Warnicke (eaw)" <eaw@...>
To: "Daniel Bartoš" <daniel.bartos@...>, openflowjava-dev@..., openflowplugin-dev@...
Sent: Tuesday, August 6, 2013 8:12:26 PM
Subject: RE: OF Protocol Java Library architecture meet-up

That general week sounds good :) Although perhaps Wed & Thur might work better due to 
travel booking.

What do other folks think?

Ed

From: openflowjava-dev-bounces@... [openflowjava-dev-bounces@...] on behalf of Daniel Bartoš [daniel.bartos@...]
Sent: Tuesday, August 06, 2013 8:30 AM
To: openflowjava-dev@...; openflowplugin-dev@...
Subject: [openflowjava-dev] OF Protocol Java Library architecture meet-up

Hi guys,

I'm responding to Jan's suggestion from yesterdays' call to hold a meeting to further discuss implementation issues regarding OF Protocol Library.
We see this as good opportunity to discuss outstanding issues in effective way.

The question is WHEN could we meet? I see August 19 & 20 as latest reasonable dates for such face-to-face meet-up since Aug 19 is deadline for presenting final Release Plan for OF Protocol Library.


Your ideas?
-- 
Daniel



1 - 20 of 861