Merge "Fix links to OVSDB docs"
[docs.git] / docs / user-guide / netconf-user-guide.rst
index 9ac115c9941608fb38a8ba4f64736e2ac40af748..909d1258544aa7c6b5567534bf2d742427ddcc2a 100644 (file)
@@ -31,12 +31,14 @@ In terms of RFCs, the connector supports:
 
 -  `RFC-6022 <https://tools.ietf.org/html/rfc6022>`__
 
+-  `draft-ietf-netconf-yang-library-06 <https://tools.ietf.org/html/draft-ietf-netconf-yang-library-06>`__
+
 **Netconf-connector is fully model-driven (utilizing the YANG modeling
 language) so in addition to the above RFCs, it supports any
 data/RPC/notifications described by a YANG model that is implemented by
 the device.**
 
-    **Tip**
+.. tip::
 
     NETCONF southbound can be activated by installing
     ``odl-netconf-connector-all`` Karaf feature.
@@ -171,7 +173,7 @@ this device there is this capability reported:
 **For such devices you only need to put the schema into folder
 cache/schema inside your Karaf distribution.**
 
-    **Important**
+.. important::
 
     The file with YANG schema for ietf-inet-types has to be called
     ietf-inet-types@2010-09-24.yang. It is the required naming format of
@@ -297,7 +299,7 @@ MD-SAL with the usage of the network-topology model. You can configure
 new NETCONF connectors both through the NETCONF server for MD-SAL (port
 2830) or RESTCONF. This guide focuses on RESTCONF.
 
-    **Tip**
+.. tip::
 
     To enable NETCONF connector configuration through MD-SAL install
     either the ``odl-netconf-topology`` or
@@ -391,13 +393,33 @@ following:
 
     DELETE http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
 
+Connecting to a device supporting only NETCONF 1.0
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+OpenDaylight is schema-based distribution and heavily depends on YANG
+models. However some legacy NETCONF devices are not schema-based and
+implement just RFC 4741. This type of device does not utilize YANG
+models internally and OpenDaylight does not know how to communicate
+with such devices, how to validate data, or what the semantics of data
+are.
+
+NETCONF connector can communicate also with these devices, but the
+trade-offs are worsened possibilities in utilization of NETCONF
+mountpoints. Using RESTCONF with such devices is not suported. Also
+communicating with schemaless devices from application code is slightly
+different.
+
+To connect to schemaless device, there is a optional configuration option
+in netconf-node-topology model called schemaless. You have to set this
+option to true.
+
 Clustered NETCONF connector
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To spawn NETCONF connectors that are cluster-aware you need to install
 the ``odl-netconf-clustered-topology`` karaf feature.
 
-    **Warning**
+.. warning::
 
     The ``odl-netconf-topology`` and ``odl-netconf-clustered-topology``
     features are considered **INCOMPATIBLE**. They both manage the same
@@ -468,7 +490,7 @@ http://localhost:8181/restconf/config/network-topology:network-topology/topology
 
 Should return 200 response code with no body.
 
-    **Tip**
+.. tip::
 
     This call is transformed into a couple of NETCONF RPCs. Resulting
     NETCONF RPCs that go directly to the device can be found in the
@@ -578,7 +600,7 @@ OpenDaylight provides 2 types of NETCONF servers:
    -  Serves as an alternative interface for MD-SAL (besides RESTCONF)
       and allows users to read/write data from MD-SAL’s datastore and to
       invoke its rpcs (NETCONF notifications are not available in the
-      Beryllium release of OpenDaylight)
+      Boron release of OpenDaylight)
 
 .. note::
 
@@ -603,7 +625,7 @@ In terms of RFCs, these are supported:
 -  `RFC-6470 <https://tools.ietf.org/html/rfc6470>`__
 
    -  (partially, only the schema-change notification is available in
-      Beryllium release)
+      Boron release)
 
 -  `RFC-6022 <https://tools.ietf.org/html/rfc6022>`__
 
@@ -626,9 +648,11 @@ In terms of RFCs, these are supported:
 
 -  `RFC-6022 <https://tools.ietf.org/html/rfc6022>`__
 
-Notifications over NETCONF are not supported in the Beryllium release.
+-  `draft-ietf-netconf-yang-library-06 <https://tools.ietf.org/html/draft-ietf-netconf-yang-library-06>`__
 
-    **Tip**
+Notifications over NETCONF are not supported in the Boron release.
+
+.. tip::
 
     Install NETCONF northbound for MD-SAL by installing feature:
     ``odl-netconf-mdsal`` in karaf. Default binding port is **2830**.
@@ -697,10 +721,10 @@ NETCONF testtool
 These jars are part of OpenDaylight’s controller project and are built
 from the NETCONF codebase in OpenDaylight.
 
-    **Tip**
+.. tip::
 
     Download testtool from OpenDaylight Nexus at:
-    https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.0.2-Beryllium-SR2/
+    https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/
 
 **Nexus contains 3 executable tools:**
 
@@ -710,7 +734,7 @@ from the NETCONF codebase in OpenDaylight.
 
 -  perf-client.jar - RESTCONF stress/performance measuring tool
 
-    **Tip**
+.. tip::
 
     Each executable tool provides help. Just invoke ``java -jar
     <name-of-the-tool.jar> --help``
@@ -751,7 +775,7 @@ Downloading testtool
 Netconf-testtool is now part of default maven build profile for
 controller and can be also downloaded from nexus. The executable jar for
 testtool can be found at:
-`nexus-artifacts <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.0.2-Beryllium-SR2/>`__
+`nexus-artifacts <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/>`__
 
 Running testtool
 ^^^^^^^^^^^^^^^^
@@ -1075,7 +1099,7 @@ Editing data for simulated device
 
        http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
 
-    **Warning**
+.. warning::
 
     Data will be mirrored in operational datastore only when using the
     default simple datastore.
@@ -1163,3 +1187,82 @@ RESTCONF stress-performance measuring tool
 Very similar to NETCONF stress tool with the difference of using
 RESTCONF protocol instead of NETCONF.
 
+YANGLIB remote repository
+-------------------------
+
+There are scenarios in NETCONF deployment, that require for a centralized
+YANG models repository. YANGLIB plugin provides such remote repository.
+
+To start this plugin, you have to install odl-yanglib feature. Then you
+have to configure YANGLIB either through RESTCONF or NETCONF. We will
+show how to configure YANGLIB through RESTCONF.
+
+YANGLIB configuration through RESTCONF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You have to specify what local YANG modules directory you want to provide.
+Then you have to specify address and port whre you want to provide YANG
+sources. For example, we want to serve yang sources from folder /sources
+on localhost:5000 adress. The configuration for this scenario will be
+as follows:
+
+::
+
+    PUT  http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/yanglib:yanglib/example
+
+Headers:
+
+-  Accept: application/xml
+
+-  Content-Type: application/xml
+
+Payload:
+
+::
+
+   <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
+     <name>example</name>
+     <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">prefix:yanglib</type>
+     <broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">
+       <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
+       <name>binding-osgi-broker</name>
+     </broker>
+     <cache-folder xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">/sources</cache-folder>
+     <binding-addr xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">localhost</binding-addr>
+     <binding-port xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">5000</binding-port>
+   </module>
+
+This should result in a 2xx response and new YANGLIB instance should be
+created. This YANGLIB takes all YANG sources from /sources folder and
+for each generates URL in form:
+
+::
+
+    http://localhost:5000/schemas/{modelName}/{revision}
+
+On this URL will be hosted YANG source for particular module.
+
+YANGLIB instance also write this URL along with source identifier to
+ietf-netconf-yang-library/modules-state/module list.
+
+Netconf-connector with YANG library as fallback
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There is an optional configuration in netconf-connector called
+yang-library. You can specify YANG library to be plugged as additional
+source provider into the mount's schema repository. Since YANGLIB
+plugin is advertising provided modules through yang-library model, we
+can use it in mount point's configuration as YANG library.  To do this,
+we need to modify the configuration of netconf-connector by adding this
+XML
+
+::
+
+    <yang-library xmlns="urn:opendaylight:netconf-node-topology">
+      <yang-library-url xmlns="urn:opendaylight:netconf-node-topology">http://localhost:8181/restconf/operational/ietf-yang-library:modules-state</yang-library-url>
+      <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
+      <password xmlns="urn:opendaylight:netconf-node-topology">admin</password>
+    </yang-library>
+
+This will register YANGLIB provided sources as a fallback schemas for
+particular mount point.