... | ... | @@ -4,6 +4,17 @@ This text is an initial input to a discussion about possible |
|
|
motivations, deployment modes and problems of using RESTCONF for
|
|
|
configuring OpenWRT routers.
|
|
|
|
|
|
[RESTCONF](https://tools.ietf.org/html/draft-ietf-netconf-restconf-18)
|
|
|
is a configuration and management that is based on similar principles
|
|
|
as its [NETCONF](https://datatracker.ietf.org/doc/rfc6241/)
|
|
|
predecessor but uses HTTP methods for client-server communication
|
|
|
rather special RPC message layer. RESTCONF also permits several
|
|
|
alternative data encodings/media types (XML, JSON, CBOR), whereas
|
|
|
NETCONF is only limited to XML.
|
|
|
|
|
|
[YANG](https://tools.ietf.org/html/rfc7950) is a data modelling
|
|
|
language that is usable with both RESTCONF and NETCONF.
|
|
|
|
|
|
## Current Situation
|
|
|
|
|
|
The canonical way of configuring OpenWRT routers is through the
|
... | ... | @@ -77,6 +88,8 @@ possible, too): |
|
|
1. Replace the UCI layer with RESTCONF, and then use RESTCONF data in
|
|
|
a similar fashion as UCI data are currently being used,
|
|
|
i.e. generate specific daemon or service configuration from them.
|
|
|
The configuration datastore can be implemented as flat files of
|
|
|
using a database.
|
|
|
|
|
|
1. Use a system like [Sysrepo](http://www.sysrepo.org/) for improving
|
|
|
back-end integration of deamons and services.
|
... | ... | @@ -91,11 +104,66 @@ On the other hand, the extra layer added by option #1 increases the |
|
|
complexity of the whole system and, since the flow of data is still
|
|
|
only in one direction, it just amplifies the problems of UCI mentioned
|
|
|
above. For example, if an admin directly edits a generated UCI file,
|
|
|
this change
|
|
|
this change won't be reflected in RESTCONF configuration. Whilst
|
|
|
the conversion of RESTCONF to UCI is most likely doable, the reverse
|
|
|
conversion and synchronization of both configuration sources seems
|
|
|
next to impossible.
|
|
|
|
|
|
Option #2 essentially means substituting UCI with RESTCONF data. The
|
|
|
pros and cons of this approach are similar to those of the UCI system.
|
|
|
|
|
|
Option #3 is the most sophisticated approach but certainly not a
|
|
|
low-hanging fruit because it not only involves development of new
|
|
|
software components but also requires that all participating daemons
|
|
|
and services be modified to use the Sysrepo (or similar) API.
|
|
|
|
|
|
## Available RESTCONF Implementations
|
|
|
|
|
|
## Hardware-Related Considerations
|
|
|
At the time of writing, the following two open-source implementations
|
|
|
of the RESTCONF server are known:
|
|
|
|
|
|
* [JetConf](https://gitlab.labs.nic.cz/labs/jetconf) is a Python 3
|
|
|
implementation that provides several extensions of the RESTCONF
|
|
|
protocol (support for user-specific candidate datastores,
|
|
|
transactions and detailed access control).
|
|
|
|
|
|
* [MD-SAL](https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf) –
|
|
|
implementation for the [OpenDaylight](https://www.opendaylight.org/)
|
|
|
project written in Java.
|
|
|
|
|
|
## Conclusion
|
|
|
|
|
|
It is currently difficult to decide which of the three approaches
|
|
|
described in [Deployment Options](#deployment-options) is the most
|
|
|
promising. Option #1 is easiest to implement but is would also require
|
|
|
tight administrative policies (write access has to be restricted to
|
|
|
the RESTCONF API, i.e. no manual editing of UCI files can be
|
|
|
permitted).
|
|
|
|
|
|
Options #2 and #3 not only mean significantly more development work
|
|
|
but, arguably, they would not be OpenWRT anymore given that the UCI
|
|
|
system is regarded as OpenWRT's flagship.
|
|
|
|
|
|
Regarding RESTCONF clients (remote management programs), two variants
|
|
|
are worth considering:
|
|
|
|
|
|
* A graphical client (e.g. client-side web application) with user
|
|
|
interface tailored to the needs of SOHO router configuration and
|
|
|
management. The client will use the RESTCONF API for sending
|
|
|
requests and receiving data.
|
|
|
|
|
|
* A domain-specific language that allows for creating configuration
|
|
|
scripts, defining responses to asynchronous events etc.
|
|
|
|
|
|
The former option would be a user-friendly interface intended for
|
|
|
remote management of a single router (or few, at most) while the
|
|
|
letter would be more suitable for operators of large networks, and
|
|
|
require deeper technical expertise.
|
|
|
|
|
|
It is also worth noting that neither of the open-source RESTCONF
|
|
|
servers mentioned above is suitable for low-end OpenWRT routers with
|
|
|
constrained resources (RAM) as long as they cannot run Python or Java
|
|
|
interpreters. This is not an issue for the Turris platform though.
|
|
|
|
|
|
## Appendix: Standard YANG Modules
|
|
|
|
... | ... | |