controller spin-off proposals

www.opendaylight.org

Controller spin-off proposalsTony Tkacik, Robert Varga


Architecture overview Design and implementation facts Reasons for spin-off

Netconf / Restconf MD-SAL

Overview

2


Architecture OverviewSubsystems and their role in overal architecture


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

Architecture overview

4


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

discovery

Karaf

5


Provides support for explicit dependency injection customizable by operator / deployer of system

Transactional support for startup, teardown and reconfiguration of components or their dependencies

Config Subsystem

6


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)

MD-SAL

7


NETCONF Protocol implementation Provides NETCONF northbound for:

Config Subsystem MD-SAL

Provides NETCONF southbound for MD-SAL RESTCONF

Protocol implementation Provides REST-like YANG modeled APIs for external applications

NETCONF / RESTCONF

8


Design and Implementation factsFacts about design and current implementation of affected components


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 Design & Impl Facts

10


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

MD-SAL Implementation & Facts #2

11


Reasons for spin-offsAnd why scope is defined as is


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

Clarity

13


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

NETCONF / RESTCONF

14


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

MD-SAL

15


Questions and discussion


Thanks for your time

controller spin-off proposals

Documents