[controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo


Raghurama Bhat <raghu.odl@...>
 

I agree that L2 switch is not a logical home for  generic network services as long as the project is called L2 Switch.  But,the name aside, That was exactly the proposed charter of the project.

"This proposal is to separate out the Layer 2 specific handling code into a separate project and also create several reusable services. Following are some of the generic services we intend to create.

 At the end of the day it does not matter too much where the code belongs. With the right Karaf feature names and dependencies user will be able to find it.  It is just that, One would not think to look at Open Flow Plugin for generic network services.  For some of these services, I can understand the model being the only thing common/generic and each southbound plugin potentially supplying its own implementation. Still, I think there would be some services which are common, protocol independent network services and we need a good home for those.

Thanks,

—Raghu

From: Colin Dixon <colin@...>
Date: Monday, January 12, 2015 at 2:13 PM
To: Abhijit Kumbhare <abhijitkoss@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "aaa-dev@..." <aaa-dev@...>, "release@..." <release@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "controller-dev@..." <controller-dev@...>, "Ed Warnicke (eaw)" <eaw@...>
Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

+1 to what Abhijit says above, but I'll add the caveat that if it ends up in the OF-plugin, it should be housed in such a way that it tries as best it can to avoid being any more OpenFlow-specific than it already is. Also, it should be amenable to other plugins providing the backing functionality.

For example, it should be possible and easy for somebody else to provide statistics and topology information to the relevant manager.

--Colin

On Mon, Jan 12, 2015 at 11:39 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Adding the controller-dev to this thread as well. To expand on what Michal alluded to about my thought regarding the OF-specific apps: it is possible for some one to use the OF-plugin but not use the L2 switch. So it should not be mandatory for them to need to include the L2 switch. By OF-specific apps (just so no one is confused) - Michal means what many people call NSFs:

  • statistics-manager
  • forwardingrules-manager
  • inventory-manager
  • topology-lldp-discovery
  • topology-manager
So I think these should be either in the controller, OF-plugin or a separate new place (but not L2 switch). 


On Mon, Jan 12, 2015 at 11:24 AM, Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) <mirehak@...> wrote:
Hi Colin,
there was already discussion about renaming those apps so we do not block some good general name (like NSF).
And yes - we might later come up with some more general modeling here which would be shareable by multiple protocols or at least apps. And then we would definitely play with the idea of pulling those models up to separate project so that controller models will stay protocol agnostic.

Now Abhijit got this idea regarding where is the best place to move OF-specific apps:
Those apps depend on ofplugin but it seems they do not depend on l2switch. Are there any dependencies of those apps pointing on l2switch services?


Regards,
Michal


From: Colin Dixon [colin@...]
Sent: Monday, January 12, 2015 19:47
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco)
Cc: Raghurama Bhat; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...; openflowplugin-dev; Moiz Raja (moraja); aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; Jan Medved (jmedved); Ed Warnicke (eaw); l2switch-dev@...

Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.

As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.

--Colin

On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) <rovarga@...> wrote:

Hello Raghu,

 

I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.

 

FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium trajectory, we can only do so much.

 

Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).

 

Bye,

Robert

 

 

From: Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Hi,

 

If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it. 

 

Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.  

 

However, I think the following  Applications need to be more generic and protocol agnostic although the we only had an Openflow implementation until now.   Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?

  • forwardingrules-manager
  • inventory-manager
  • topology-manager

Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the home for generic services like Topology and LLDP Discovery  and potentially renaming it to be more generic to reflect the true nature of its content. 

 

BTW, Does the list below represent the complete  picture of migrations like this or is there more? This might be a good topic for the TWS Call as well.

 

Thoughts?

 

Thanks,

 

—Raghu

 

From: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>
Date: Wednesday, January 7, 2015 at 8:09 AM
To: "release@..." <release@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "aaa-dev@..." <aaa-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>
Subject: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.

Migration will take following steps:

  • copy corresponding projects from controller into openflowplugin
  • change project and package names where necessary (without changing model content) (deadline: 09.01.2015)
  • adapt downstream project in order to use those model projects (deadline: 16.01.2015)
  • remove models from controller repository (deadline: 23.01.2015)


Models to migrate:

  • model/model-flow-base
  • model/model-flow-service
  • model/model-flow-statistics


Apps to migrate

  • statistics-manager
  • forwardingrules-manager
  • inventory-manager
  • topology-lldp-discovery
  • topology-manager


Donwstream projects (so far)

  • aaa
  • l2switch
  • ovsdb
  • openflowplugin
  • affinity
  • packetcable
  • grupbasedpolicy

If you have questions, contributions, comments then please feel free to respond.

The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development. And controller project plans to go more abstract/general way.

With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending on dataStore result of those applications.

 

There are no deadlines for applications yet but moving them together with models might spare us some renaming work.

 

Thank you.

Regards,

Michal

 

 

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


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



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


Aneesha Pailla <apailla@...>
 

Hi All,

 

I see interesting conversation here on the services being separated from Openflow.

Thought my experience may add some value to this discussion.

I was new to ODL and checked stub, SNMP4SDN and OpenFlow plugins and wrote a new custom plugin for a circuit switch where I reused the following services -

·  forwardingrules-manager

·  inventory-manager

·  topology-manager

I could use topology and inventory manager very well. I just used few parameters (which are relevant to our flows) for flows addition and deletion in forwardingrules-manager.

I could not use statistics manager service as the statistics are specific to packet switches and hence added a new REST API in this for circuit statistics.

I could not represent some properties for the nodeConnector but compromised them for an immediate solution.

Basically I tried reducing my work and hence reused the existing services.

So, I could make it work just by writing  a new southbound plugin without touching the services and the northbound.

 

It may be better to have the inventory and topology manager services available for any southbound plugin and not specific to openflow. Also, may be useful to make these more generic.

Also, Good to have the forwardingrules-manager services to be generic. So, one can add ACLs or Circuit connections or any other forwarding using this service.

 

Just my thoughts.

Correct me if I am wrong in any of the above.

 

Thanks,

Aneesha

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Raghurama Bhat
Sent: Monday, January 12, 2015 3:46 PM
To: Colin Dixon; Abhijit Kumbhare
Cc: openflowplugin-dev; groupbasedpolicy-dev@...; ovsdb-dev@...; aaa-dev@...; release@...; affinity-dev@...; controller-dev@...; Ed Warnicke (eaw); l2switch-dev@...
Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

I agree that L2 switch is not a logical home for  generic network services as long as the project is called L2 Switch.  But,the name aside, That was exactly the proposed charter of the project.

 

"This proposal is to separate out the Layer 2 specific handling code into a separate project and also create several reusable services. Following are some of the generic services we intend to create.

 

 At the end of the day it does not matter too much where the code belongs. With the right Karaf feature names and dependencies user will be able to find it.  It is just that, One would not think to look at Open Flow Plugin for generic network services.  For some of these services, I can understand the model being the only thing common/generic and each southbound plugin potentially supplying its own implementation. Still, I think there would be some services which are common, protocol independent network services and we need a good home for those.

 

Thanks,

 

—Raghu

 

From: Colin Dixon <colin@...>
Date: Monday, January 12, 2015 at 2:13 PM
To: Abhijit Kumbhare <abhijitkoss@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "aaa-dev@..." <aaa-dev@...>, "release@..." <release@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "controller-dev@..." <controller-dev@...>, "Ed Warnicke (eaw)" <eaw@...>
Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

+1 to what Abhijit says above, but I'll add the caveat that if it ends up in the OF-plugin, it should be housed in such a way that it tries as best it can to avoid being any more OpenFlow-specific than it already is. Also, it should be amenable to other plugins providing the backing functionality.

For example, it should be possible and easy for somebody else to provide statistics and topology information to the relevant manager.

 

--Colin

 

On Mon, Jan 12, 2015 at 11:39 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Adding the controller-dev to this thread as well. To expand on what Michal alluded to about my thought regarding the OF-specific apps: it is possible for some one to use the OF-plugin but not use the L2 switch. So it should not be mandatory for them to need to include the L2 switch. By OF-specific apps (just so no one is confused) - Michal means what many people call NSFs:

 

·  statistics-manager

·  forwardingrules-manager

·  inventory-manager

·  topology-lldp-discovery

·  topology-manager

So I think these should be either in the controller, OF-plugin or a separate new place (but not L2 switch). 

 

 

On Mon, Jan 12, 2015 at 11:24 AM, Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) <mirehak@...> wrote:

Hi Colin,
there was already discussion about renaming those apps so we do not block some good general name (like NSF).
And yes - we might later come up with some more general modeling here which would be shareable by multiple protocols or at least apps. And then we would definitely play with the idea of pulling those models up to separate project so that controller models will stay protocol agnostic.

Now Abhijit got this idea regarding where is the best place to move OF-specific apps:
Those apps depend on ofplugin but it seems they do not depend on l2switch. Are there any dependencies of those apps pointing on l2switch services?


Regards,
Michal


From: Colin Dixon [colin@...]
Sent: Monday, January 12, 2015 19:47
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco)
Cc: Raghurama Bhat; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...; openflowplugin-dev; Moiz Raja (moraja); aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; Jan Medved (jmedved); Ed Warnicke (eaw); l2switch-dev@...


Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.

 

As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.

 

--Colin

On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) <rovarga@...> wrote:

Hello Raghu,

 

I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.

 

FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium trajectory, we can only do so much.

 

Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).

 

Bye,

Robert

 

 

From: Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Hi,

 

If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it. 

 

Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.  

 

However, I think the following  Applications need to be more generic and protocol agnostic although the we only had an Openflow implementation until now.   Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?

  • forwardingrules-manager
  • inventory-manager
  • topology-manager

Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the home for generic services like Topology and LLDP Discovery  and potentially renaming it to be more generic to reflect the true nature of its content. 

 

BTW, Does the list below represent the complete  picture of migrations like this or is there more? This might be a good topic for the TWS Call as well.

 

Thoughts?

 

Thanks,

 

—Raghu

 

From: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>
Date: Wednesday, January 7, 2015 at 8:09 AM
To: "release@..." <release@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "aaa-dev@..." <aaa-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>
Subject: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.

Migration will take following steps:

  • copy corresponding projects from controller into openflowplugin
  • change project and package names where necessary (without changing model content) (deadline: 09.01.2015)
  • adapt downstream project in order to use those model projects (deadline: 16.01.2015)
  • remove models from controller repository (deadline: 23.01.2015)


Models to migrate:

  • model/model-flow-base
  • model/model-flow-service
  • model/model-flow-statistics


Apps to migrate

  • statistics-manager
  • forwardingrules-manager
  • inventory-manager
  • topology-lldp-discovery
  • topology-manager


Donwstream projects (so far)

  • aaa
  • l2switch
  • ovsdb
  • openflowplugin
  • affinity
  • packetcable
  • grupbasedpolicy

If you have questions, contributions, comments then please feel free to respond.

The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development. And controller project plans to go more abstract/general way.

With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending on dataStore result of those applications.

 

There are no deadlines for applications yet but moving them together with models might spare us some renaming work.

 

Thank you.

Regards,

Michal

 

 

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

 

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

 

 

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


Abhijit Kumbhare <abhijitkoss@...>
 

Few questions wanted to confirm with you: 

1. Are you planning to upstream your custom plugin for circuit switching to OpenDaylight? 
2. Are you using the MD-SAL based OpenFlow implementation (plugin & FRM) or are you using the AD-SAL based OpenFlow implementation (the OpenFlow 1.0 protocol plugin, FRM, etc.)?
3. Can you elaborate the rough design that you are using the FRM? Will be great if you can share an architecture diagram.





On Mon, Jan 12, 2015 at 5:35 PM, Aneesha Pailla <apailla@...> wrote:

Hi All,

 

I see interesting conversation here on the services being separated from Openflow.

Thought my experience may add some value to this discussion.

I was new to ODL and checked stub, SNMP4SDN and OpenFlow plugins and wrote a new custom plugin for a circuit switch where I reused the following services -

·  forwardingrules-manager

·  inventory-manager

·  topology-manager

I could use topology and inventory manager very well. I just used few parameters (which are relevant to our flows) for flows addition and deletion in forwardingrules-manager.

I could not use statistics manager service as the statistics are specific to packet switches and hence added a new REST API in this for circuit statistics.

I could not represent some properties for the nodeConnector but compromised them for an immediate solution.

Basically I tried reducing my work and hence reused the existing services.

So, I could make it work just by writing  a new southbound plugin without touching the services and the northbound.

 

It may be better to have the inventory and topology manager services available for any southbound plugin and not specific to openflow. Also, may be useful to make these more generic.

Also, Good to have the forwardingrules-manager services to be generic. So, one can add ACLs or Circuit connections or any other forwarding using this service.

 

Just my thoughts.

Correct me if I am wrong in any of the above.

 

Thanks,

Aneesha

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Raghurama Bhat
Sent: Monday, January 12, 2015 3:46 PM
To: Colin Dixon; Abhijit Kumbhare
Cc: openflowplugin-dev; groupbasedpolicy-dev@...; ovsdb-dev@...; aaa-dev@...; release@...; affinity-dev@...; controller-dev@...; Ed Warnicke (eaw); l2switch-dev@...


Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

I agree that L2 switch is not a logical home for  generic network services as long as the project is called L2 Switch.  But,the name aside, That was exactly the proposed charter of the project.

 

"This proposal is to separate out the Layer 2 specific handling code into a separate project and also create several reusable services. Following are some of the generic services we intend to create.

 

 At the end of the day it does not matter too much where the code belongs. With the right Karaf feature names and dependencies user will be able to find it.  It is just that, One would not think to look at Open Flow Plugin for generic network services.  For some of these services, I can understand the model being the only thing common/generic and each southbound plugin potentially supplying its own implementation. Still, I think there would be some services which are common, protocol independent network services and we need a good home for those.

 

Thanks,

 

—Raghu

 

From: Colin Dixon <colin@...>
Date: Monday, January 12, 2015 at 2:13 PM
To: Abhijit Kumbhare <abhijitkoss@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "aaa-dev@..." <aaa-dev@...>, "release@..." <release@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "controller-dev@..." <controller-dev@...>, "Ed Warnicke (eaw)" <eaw@...>
Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

+1 to what Abhijit says above, but I'll add the caveat that if it ends up in the OF-plugin, it should be housed in such a way that it tries as best it can to avoid being any more OpenFlow-specific than it already is. Also, it should be amenable to other plugins providing the backing functionality.

For example, it should be possible and easy for somebody else to provide statistics and topology information to the relevant manager.

 

--Colin

 

On Mon, Jan 12, 2015 at 11:39 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Adding the controller-dev to this thread as well. To expand on what Michal alluded to about my thought regarding the OF-specific apps: it is possible for some one to use the OF-plugin but not use the L2 switch. So it should not be mandatory for them to need to include the L2 switch. By OF-specific apps (just so no one is confused) - Michal means what many people call NSFs:

 

·  statistics-manager

·  forwardingrules-manager

·  inventory-manager

·  topology-lldp-discovery

·  topology-manager

So I think these should be either in the controller, OF-plugin or a separate new place (but not L2 switch). 

 

 

On Mon, Jan 12, 2015 at 11:24 AM, Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) <mirehak@...> wrote:

Hi Colin,
there was already discussion about renaming those apps so we do not block some good general name (like NSF).
And yes - we might later come up with some more general modeling here which would be shareable by multiple protocols or at least apps. And then we would definitely play with the idea of pulling those models up to separate project so that controller models will stay protocol agnostic.

Now Abhijit got this idea regarding where is the best place to move OF-specific apps:
Those apps depend on ofplugin but it seems they do not depend on l2switch. Are there any dependencies of those apps pointing on l2switch services?


Regards,
Michal


From: Colin Dixon [colin@...]
Sent: Monday, January 12, 2015 19:47
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco)
Cc: Raghurama Bhat; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...; openflowplugin-dev; Moiz Raja (moraja); aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; Jan Medved (jmedved); Ed Warnicke (eaw); l2switch-dev@...


Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.

 

As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.

 

--Colin

On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) <rovarga@...> wrote:

Hello Raghu,

 

I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.

 

FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium trajectory, we can only do so much.

 

Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).

 

Bye,

Robert

 

 

From: Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Hi,

 

If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it. 

 

Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.  

 

However, I think the following  Applications need to be more generic and protocol agnostic although the we only had an Openflow implementation until now.   Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?

  • forwardingrules-manager
  • inventory-manager
  • topology-manager

Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the home for generic services like Topology and LLDP Discovery  and potentially renaming it to be more generic to reflect the true nature of its content. 

 

BTW, Does the list below represent the complete  picture of migrations like this or is there more? This might be a good topic for the TWS Call as well.

 

Thoughts?

 

Thanks,

 

—Raghu

 

From: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>
Date: Wednesday, January 7, 2015 at 8:09 AM
To: "release@..." <release@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "aaa-dev@..." <aaa-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>
Subject: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.

Migration will take following steps:

  • copy corresponding projects from controller into openflowplugin
  • change project and package names where necessary (without changing model content) (deadline: 09.01.2015)
  • adapt downstream project in order to use those model projects (deadline: 16.01.2015)
  • remove models from controller repository (deadline: 23.01.2015)


Models to migrate:

  • model/model-flow-base
  • model/model-flow-service
  • model/model-flow-statistics


Apps to migrate

  • statistics-manager
  • forwardingrules-manager
  • inventory-manager
  • topology-lldp-discovery
  • topology-manager


Donwstream projects (so far)

  • aaa
  • l2switch
  • ovsdb
  • openflowplugin
  • affinity
  • packetcable
  • grupbasedpolicy

If you have questions, contributions, comments then please feel free to respond.

The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development. And controller project plans to go more abstract/general way.

With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending on dataStore result of those applications.

 

There are no deadlines for applications yet but moving them together with models might spare us some renaming work.

 

Thank you.

Regards,

Michal

 

 

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

 

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

 

 

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



Aneesha Pailla <apailla@...>
 

Hi Abhijit,

 

Please see my answers inline.

Let me know if you need more information.

Also, let me know if you have any suggestions on the plugin.

 

Thanks,

Aneesha

 

From: Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Monday, January 12, 2015 7:44 PM
To: Aneesha Pailla
Cc: Raghurama Bhat; Colin Dixon; openflowplugin-dev; groupbasedpolicy-dev@...; ovsdb-dev@...; aaa-dev@...; release@...; affinity-dev@...; controller-dev@...; Ed Warnicke (eaw); l2switch-dev@...
Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Few questions wanted to confirm with you: 

 

1. Are you planning to upstream your custom plugin for circuit switching to OpenDaylight? 

      Our Plugin does not really cover all the features of the Circuit Switch Specification. It has the functionality which is required for our switch. Does this partial implementation really add value if we upstream (and also using AD-SAL)?

2. Are you using the MD-SAL based OpenFlow implementation (plugin & FRM) or are you using the AD-SAL based OpenFlow implementation (the OpenFlow 1.0 protocol plugin, FRM, etc.)?

        We decided to go with Hydrogen Release and AD-SAL as Helium was still not released. We used the “Extensions to the OpenFlow Protocol in support of Circuit Switching” (Addendum to OpenFlow Protocol Specification (v1.0) – Circuit Switch Addendum v0.3). We would like to move to MD-SAL based OpenFlow implementation but with the current priority work items, it may take some time to do this. We still have no time frame for that.

3. Can you elaborate the rough design that you are using the FRM? Will be great if you can share an architecture diagram.

       The design is same as the Openflow protocol. I am sharing the user guide to get an idea on how I am using the FRM.

 

 

 

On Mon, Jan 12, 2015 at 5:35 PM, Aneesha Pailla <apailla@...> wrote:

Hi All,

 

I see interesting conversation here on the services being separated from Openflow.

Thought my experience may add some value to this discussion.

I was new to ODL and checked stub, SNMP4SDN and OpenFlow plugins and wrote a new custom plugin for a circuit switch where I reused the following services -

·  forwardingrules-manager

·  inventory-manager

·  topology-manager

I could use topology and inventory manager very well. I just used few parameters (which are relevant to our flows) for flows addition and deletion in forwardingrules-manager.

I could not use statistics manager service as the statistics are specific to packet switches and hence added a new REST API in this for circuit statistics.

I could not represent some properties for the nodeConnector but compromised them for an immediate solution.

Basically I tried reducing my work and hence reused the existing services.

So, I could make it work just by writing  a new southbound plugin without touching the services and the northbound.

 

It may be better to have the inventory and topology manager services available for any southbound plugin and not specific to openflow. Also, may be useful to make these more generic.

Also, Good to have the forwardingrules-manager services to be generic. So, one can add ACLs or Circuit connections or any other forwarding using this service.

 

Just my thoughts.

Correct me if I am wrong in any of the above.

 

Thanks,

Aneesha

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Raghurama Bhat
Sent: Monday, January 12, 2015 3:46 PM
To: Colin Dixon; Abhijit Kumbhare
Cc: openflowplugin-dev; groupbasedpolicy-dev@...; ovsdb-dev@...; aaa-dev@...; release@...; affinity-dev@...; controller-dev@...; Ed Warnicke (eaw); l2switch-dev@...


Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

I agree that L2 switch is not a logical home for  generic network services as long as the project is called L2 Switch.  But,the name aside, That was exactly the proposed charter of the project.

 

"This proposal is to separate out the Layer 2 specific handling code into a separate project and also create several reusable services. Following are some of the generic services we intend to create.

 

 At the end of the day it does not matter too much where the code belongs. With the right Karaf feature names and dependencies user will be able to find it.  It is just that, One would not think to look at Open Flow Plugin for generic network services.  For some of these services, I can understand the model being the only thing common/generic and each southbound plugin potentially supplying its own implementation. Still, I think there would be some services which are common, protocol independent network services and we need a good home for those.

 

Thanks,

 

—Raghu

 

From: Colin Dixon <colin@...>
Date: Monday, January 12, 2015 at 2:13 PM
To: Abhijit Kumbhare <abhijitkoss@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "aaa-dev@..." <aaa-dev@...>, "release@..." <release@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "controller-dev@..." <controller-dev@...>, "Ed Warnicke (eaw)" <eaw@...>
Subject: Re: [controller-dev] [openflowplugin-dev] [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

+1 to what Abhijit says above, but I'll add the caveat that if it ends up in the OF-plugin, it should be housed in such a way that it tries as best it can to avoid being any more OpenFlow-specific than it already is. Also, it should be amenable to other plugins providing the backing functionality.

For example, it should be possible and easy for somebody else to provide statistics and topology information to the relevant manager.

 

--Colin

 

On Mon, Jan 12, 2015 at 11:39 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Adding the controller-dev to this thread as well. To expand on what Michal alluded to about my thought regarding the OF-specific apps: it is possible for some one to use the OF-plugin but not use the L2 switch. So it should not be mandatory for them to need to include the L2 switch. By OF-specific apps (just so no one is confused) - Michal means what many people call NSFs:

 

·  statistics-manager

·  forwardingrules-manager

·  inventory-manager

·  topology-lldp-discovery

·  topology-manager

So I think these should be either in the controller, OF-plugin or a separate new place (but not L2 switch). 

 

 

On Mon, Jan 12, 2015 at 11:24 AM, Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) <mirehak@...> wrote:

Hi Colin,
there was already discussion about renaming those apps so we do not block some good general name (like NSF).
And yes - we might later come up with some more general modeling here which would be shareable by multiple protocols or at least apps. And then we would definitely play with the idea of pulling those models up to separate project so that controller models will stay protocol agnostic.

Now Abhijit got this idea regarding where is the best place to move OF-specific apps:
Those apps depend on ofplugin but it seems they do not depend on l2switch. Are there any dependencies of those apps pointing on l2switch services?


Regards,
Michal


From: Colin Dixon [colin@...]
Sent: Monday, January 12, 2015 19:47
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco)
Cc: Raghurama Bhat; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...; openflowplugin-dev; Moiz Raja (moraja); aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; Jan Medved (jmedved); Ed Warnicke (eaw); l2switch-dev@...


Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.

 

As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.

 

--Colin

On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) <rovarga@...> wrote:

Hello Raghu,

 

I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.

 

FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium trajectory, we can only do so much.

 

Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).

 

Bye,

Robert

 

 

From: Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Hi,

 

If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it. 

 

Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.  

 

However, I think the following  Applications need to be more generic and protocol agnostic although the we only had an Openflow implementation until now.   Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?

  • forwardingrules-manager
  • inventory-manager
  • topology-manager

Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the home for generic services like Topology and LLDP Discovery  and potentially renaming it to be more generic to reflect the true nature of its content. 

 

BTW, Does the list below represent the complete  picture of migrations like this or is there more? This might be a good topic for the TWS Call as well.

 

Thoughts?

 

Thanks,

 

—Raghu

 

From: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>
Date: Wednesday, January 7, 2015 at 8:09 AM
To: "release@..." <release@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "aaa-dev@..." <aaa-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>
Subject: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.

Migration will take following steps:

  • copy corresponding projects from controller into openflowplugin
  • change project and package names where necessary (without changing model content) (deadline: 09.01.2015)
  • adapt downstream project in order to use those model projects (deadline: 16.01.2015)
  • remove models from controller repository (deadline: 23.01.2015)


Models to migrate:

  • model/model-flow-base
  • model/model-flow-service
  • model/model-flow-statistics


Apps to migrate

  • statistics-manager
  • forwardingrules-manager
  • inventory-manager
  • topology-lldp-discovery
  • topology-manager


Donwstream projects (so far)

  • aaa
  • l2switch
  • ovsdb
  • openflowplugin
  • affinity
  • packetcable
  • grupbasedpolicy

If you have questions, contributions, comments then please feel free to respond.

The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development. And controller project plans to go more abstract/general way.

With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending on dataStore result of those applications.

 

There are no deadlines for applications yet but moving them together with models might spare us some renaming work.

 

Thank you.

Regards,

Michal

 

 

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

 

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

 

 

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