1. Controller spin-off proposals
Tony Tkacik, Robert Varga

2. Overview Architecture overview Design and implementation facts
Reasons for spin-off
Netconf / Restconf
MD-SAL

3. Architecture Overview
Subsystems and their role in overal architecture

4. Architecture overview
Controller project consists of several subsystems.
Karaf base
Config subsystem
MD-SAL
Netconf subsystem
RESTCONF
AD-SAL (deprecated in Lithium)

5. Karaf Base runtime for controller distributions
Provides feature / component packaging, download and discovery

6. Config Subsystem Provides support for explicit dependency injection
customizable by operator / deployer of system
Transactional support for startup, teardown and reconfiguration of components or their dependencies

7. MD-SAL
MD-SAL defines communication patterns for YANG-modeled data and provides Java representation of these APIs.
currently two Java representations
DOM
Binding (build exclusively on top of DOM APIs)

8. NETCONF / RESTCONF NETCONF Protocol implementation
Provides NETCONF northbound for:
Config Subsystem
MD-SAL
Provides NETCONF southbound for MD-SAL
RESTCONF
Provides REST-like YANG modeled APIs for external applications

9. Design and Implementation facts
Facts about design and current implementation of affected components

10. MD-SAL Design & Impl Facts
There are already several implementations of MD-SAL DOM APIs, for examble DOMDataBroker:
SerializedDOMDataBroker (sal-broker-impl)
ConcurrentDOMDataBroker (clustered-data-store)
PingPongDataBroker (sal-broker-impl)
NetconfDeviceDataBroker (sal-netconf-connector)
AuthzDomDataBroker (aaa project)

11. MD-SAL Implementation & Facts #2
None of the DOM implementations of MD-SAL are aware of Binding MD-SAL
Binding MD-SAL, RESTCONF and NETCONF MD-SAL Northbound are just applications on top of DOM MD-SAL APIs.
Netconf Connector (Netconf mountpoints) are implementation of DOM MD-SAL

12. And why scope is defined as is
Reasons for spin-offs
And why scope is defined as is

13. Clarity
Controller project is a large codebase, very hard to navigate for newcomers
Very few contributors have in-depth knowledge of all subsystems
Current scope of controller project is confusing

14. NETCONF / RESTCONF Protocol support: has clear scope boundaries
RESTCONF is defined in terms of NETCONF
Both are standardized in same IETF working group
Possibility for extensive code reuse
Components providing external access to the system
Needs support of AAA for real production deployment
The only cause of the Controller/AAA dependency cycle

15. MD-SAL
Separation of concerns – MD-SAL APIs defines how components communicate, what conceptual base functionality is provided
This still leaves freedom for implementation
Separation of MD-SAL APIs
will make more clear there are different implementations - this is true since Hydrogen.
makes more clear what exactly is MD-SAL
makes all implementations equal
Binding MD-SAL could be run on top of any DOM MD-SAL

16. Questions and discussion

17. Thanks for your time