Controller spin-off proposals Tony Tkacik, Robert Varga

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

Architecture Overview Subsystems and their role in overal architecture

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

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

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

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)

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

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

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)

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

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

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

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

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

Questions and discussion

Thanks for your time