|
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
|
|
|
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.
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
toggle quoted messageShow quoted text
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
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.
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
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.
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
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.
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.
toggle quoted messageShow quoted text
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
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.
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
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.
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
|
|
|
