|Priority 1 (high) - 5 (low)||Difficulty 1 (hard) - 5 (easy)||Feature||OpenDaylight "controller" elements||OpenDaylight net-virt-platform elements||Notes||Recommendation|
|StorageService||The interface to these need to be redesigned to appropriately represent strong consistency with transactions and eventual consistency. Note that this is one of the few places where semantics need to be very carefully described.|
Do we also need a stable storage interface or is the configuration management enough?
|refine the consistency interface to allow for both eventual and strong consistency with transactions, take both backing implementations if possible?|
This should also be used to back both a log service and a configuration service.
|2||3||Host detection, locating and tracking||ARPHandler|
|net-virt-platform (i) offers a more general definition of a "host", rather than defining a hot by a MAC address, (ii) can learn about hosts from more than just ARP traffic, and (iii) supports multiple attachment points for hosts.||use the net-virt-platform implementation|
|3||4||Discover interconnections between switches||TopologyManager||LinkDiscoveryManager||Both send LLDPs to discover direct links. The net-virt-platform send BDDPs (essentially broadcast LLDPs) to discover multi-hop links for OpenFlow island support.||similar functionality excepting island support, need to discuss the utility and generality of island support|
|4||Gather switch and controller statistics||StatisticsManager|
|net-virt-platform focuses on controller performance, "controller" implementation focuses on gathering switch statistics|
net-virt-platform has an interface to query for OpenFlow statistics, but only as part of the switch
|use the "controller" implementation for gathering switch statistics, generalize this to accept statistics for the controller as well, use or re-implement net-virt-platform implementation|
|3||Basic L2/L3 forwarding||SimpleForwarding||Forwarding||"controller" SimpleForwarding routes on /32 IP addresses, while net-virt-platform's Forwarding routes on MAC addresses||we need both sets of functionally, either use the net-virt-platform's L2 support or re-implement it as easier|
|net-virt-platform provides support for routing on consistent snapshots of the topology and for handling of OpenFlow islands. However, the island implementation has some limitations with loops in the islands.|
Note that there is as much importance in getting the interface right so that others can add their own route computation engines as in the actual backing implementations we provide.
|while the net-virt-platform code provides richer functionality, it does at least four separate things in one module, we either recommend factoring it apart and using it or borrowing the ideas and reimplementing them|
|2||2||Threading support||(none)||ThreadPool||Some disciplined approach to thread management is required. The net-virt-platform implementation is essentially just a passthrough to Java ScheduledExecutorService.||There isn't much code to borrow, probably easier just to use an existing OSGi service or roll our own. Most work is in replacing the current thread managment. This is pretty low priority, could be punted.|
|4||Runtime Configuration||ConfigurationService?||ModuleContext.getConfigParams()||net-virt-platform provides a way to load configuration for modules from configuration files|
"controller" provides a hook to notify all modules to save their configuration, but assumes it will be done through the consistency layer. It thus seems more related to consistency and is discussed there.
|This feature is needed, but is highly baked into the (non-OSGi) module loading system of net-virt-platform. We should implement something similar, but probalby as a stand-alone service that takes key-value pairs and optionally stores the to stable storage for modules. Ideally backed by an improved consistent datastore.|
|The current plan is to factor out this functionlity from net-virt-platform as a separate project. This should be made compatible with the NB APIs we create.|
The "controller" concept of containers essentially gives a tag to each module and that tag can be used in decision-making at various points around the controller. This allows for multiple logical controllers to run in the same JVM and for slicing of the network.
|Implement the separate net-virt-platform app to run on whatever we ship.|
We differ slightly on our views on containers. Colin thinks we should expand the containers concept beyond the current VLANs and switchports and further integrate them into the code in more places.
David thinks the idea is interesting, but thinks they require more effort to make them appropriately useful and would like to hear more about their use cases before putting significant effort into them.
|2||2||OpenFlow-specific switch and message management||OpenFlow protocol plugin|
|While the code is, by and large, equivalent in function, the net-virt-platform code is generally of higher quality.||Use net-virt-platform if possible|
One good approach might be to start with a bundle containing the net-virt-platform Controller module (not the full controller) and LinkDiscovery module with the core dependencies on the different SwitchDrivers and converting it provide the appropriate interfaces to be a SAL plugin.
|2||1||SAL||While a subset of the interfaces in net-virt-platform could be declared to be a SAL, the code would need to be augmented to aggregate multiple implementers into one logical instance of those interfaces to get multiple southbound protocol support.||The SAL is a good concept and one that must be present. The current SAL is a good first take at a common abstraction for L2/L3 forwarding devices.|
Going forward, there will need to be more than one of these common abstractions. For example, perhaps one for device configuration including OFConfig, NETCONF and OVSDB.
|5||REST API provider||*.northbound (via JAXB annotations)||RestApiService||Either solution needs better documentation for how to export REST APIs from modules||similar functionality, use the "controller" approach|
|4||5||Structured Log Service||(none)||(none)||The built-in logging (slf4j in both cases) should log in a way that gives other modules/bundles programmatic access to the (semi-)structured log data. This allows modules to present users with extra information beyond the usual events created in the listener/notifier frameworks.||While very useful, for instance to surface log messages to a web UI, this is not absolutely essential immedately.|
Ideally backed by the consistent datastore; presumably at a low level of consistency.
|5||5||User added static flows||ForwardingRulesManager||StaticFlowEntry||Both provide OpenFlow-like direct access to program low-level rules into switches.||The functionality is similar, use the "controller" code|
|5||5||Authentication and user roles||UserManager||(none)||no conflict, use the "controller" implementation|
|n/a||Build system||Maven||Ant||Maven is superior to Ant for building in an environment where we care about versioning/publishing artifacts, which we do. The "Controller" Maven usage precludes Eclipse from save doing an autobuild, this must be fixed. Worth considering switching to Maven + Tycho for Manifest first builds that can use Eclipse's PDE infrastructure||use Maven, fix eclipse PDE infrastructure to compile on save, add support to push bundles to the Nexus repositories where needed||l|
|4||2||Modularity System||OSGi using Activators||Custom Module System based on Java ServiceLoader||"Controller" is manually discovering/wiring services together using the very low-level Activator functionality in OSGi (including listing setters/getters as Strings.. ugh), the functionality is necessary but it should be able to use a much more developer-friendly framework like iPOJO or similar and remove tons of manual code. Worth investigating how this could be used with declarative services/blueprint as well.||use OSGi, the current Activators work for now, investigate possiblilites that enable less manual coding and uses a more robust system for binding than strings|
|no conflict, use net-virt-platform|
|Load Balancer||LoadBalancer||LoadBalancer||keep both after finding a common interface|
|5||Python debugging interface||(none)||Jython||this isn't a critical feature, somebody can provide it later if they want|
|Tunnel creation and management||(none)||TunnelManager|
|no conflict, use net-virt-platform|
|3||3||Device Config Service||(none)||OVSDBManager||We need an interface that will provide some generic interface for device configuration including LAG configuration, tunnel setup and the like.||no conflict, port OVSDBManager|
also add OFConfig support?