NETCONF is a standardized IETF configuration management protocol published in RFC 6241, Network Configuration Protocol (NETCONF). It is secure, connection-oriented, and runs on top of the SSHv2 transport protocol as specified in RFC 6242, Using the NETCONF Configuration Protocol over Secure Shell (SSH). NETCONF is an XML-based protocol that can be used as an alternative to CLI or SNMP for managing an SR OS router.
NETCONF uses RPC messaging for communication between a NETCONF client and the NETCONF server running on SR OS. An RPC message and configuration data is encapsulated within an XML document. These XML documents are exchanged between a NETCONF client and a NETCONF server in a request/response type of interaction. The SR OS NETCONF interface supports both configuration and retrieval of operational information. Figure 15 shows a NETCONF RPC request.
NETCONF can be conceptually partitioned into four layers as described in RFC 6241. Figure 16 shows the NETCONF layers.
NETCONF can be used on an SR OS router to perform router management operations including:
The equivalent of some admin commands are available via the SR OS NETCONF interface:
The bof, debug, tools, clear, and other general CLI operational commands (for example, telnet or ping) are not supported via SR OS NETCONF.
The SR OS NETCONF server advertises the base:1.1 capability (in addition to base:1.0).
SR OS NETCONF supports both a CLI content layer and an XML-based content layer.
SSH transport for NETCONF is supported on TCP port 830 with IPv4 or IPv6 in the Base routing instance. NETCONF SSH sessions (same as CLI, SCP, and sFTP sessions) are subject to any configurable and non-configurable session limits; for example, inbound-max-sessions. Both the SSH server and NETCONF protocol must be enabled in the router configuration in order to use NETCONF. NETCONF sessions can be disconnected using the admin disconnect command. See the CLI section for details.
NETCONF sessions do not time out automatically and are not subject to the CLI session timeout. Operators can disconnect sessions manually if they need to.
A client establishing a NETCONF session must log into the router so user accounts must exist for NETCONF on SR OS. An access type 'netconf' is provided. For access to the Base-R13 SR OS YANG data models, both console and netconf access must be configured for the user. For access to the Nokia SR OS YANG data models, only netconf access is necessary.
Authentication via the local user database is supported for NETCONF users. NETCONF runs over SSH, and SSH supports RADIUS/TACACS+ user authentication. By adding "access netconf" under the default RADIUS/TACACS+ user-template, the NETCONF user is granted access.
Command authorization is not supported for the Nokia SR OS YANG data models. Once a NETCONF session is established and the user is authenticated then all configuration data is available via the Nokia SR OS YANG data models.
Command authorization is supported for the Alcatel-Lucent Base-R13 SR OS YANG modules. Also, access to various CLI config and show commands (via the CLI content layer) is controlled through the profile assigned to the user that is used to authenticate the underlying SSH session.
Access to LI commands using the Alcatel-Lucent Base-R13 SR OS YANG modules is based on the access li configuration setting for the user.
If a NETCONF request attempts to execute a CLI command which is outside the scope of its access profile, an error response will be sent.
Example - A user request, with show command, that is not in the scope of the user’s access profile.
Reply:
SR OS supports the <running> datastore, the <candidate> datastore, the <startup> datastore, and <url>.
Note: <url> is not a datastore in itself. |
Support for the <candidate> datastore capability is advertised via the SR OS NETCONF server <hello> as:
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
All configuration changes (using <edit-config>) made to the <running> datastore via NETCONF take immediate operational effect. Configuration changes to the <candidate> datastore take effect after a successful <commit> operation.
The <startup> datastore and <url> can only be used with <copy-config> and <delete-config> and are not supported with any other operations (including <edit-config>, <get-config>, <get>, <validate>, etc).
The :startup capability is advertised in the SR OS NETCONF server <hello> as:
<capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
The <url> supports the same options as CLI <file-url>: local urls (CF) and remote urls (ftp and tftp).
The :url capability is advertised in the SR OS NETCONF server <hello> as:
<capability>urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,tftp,file</capability>
The following examples show the format of each URL scheme:
Note: The examples use “///” for the file URL. Also, the file://localhost/... format is not supported. |
The <startup> datastore is identified by following the bof primary-config/secondary-config/tertiary-config paths as configured by the operator. The <startup> datastore is effectively an alias for a URL (a special URL used for system startup) with some extra resiliency (primary/secondary/tertiary).
The BOF is not considered part of any configuration datastore.
Debug configuration (such as debug mirrors, or anything saved with admin debug-save) is not considered part of any configuration datastore.
Lawful Interception configuration information is contained in the <running> datastore but is not saved in the <startup> datastore. The equivalent of the CLI li save command is available in an <edit-config> using the Alcatel-Lucent Base-R13 SR OS YANG modules.
Configuration changes done via NETCONF are subject to CLI rollback (revert, save, and so on) and are included in the configuration when the operator performs an admin save in the CLI.
Only the Nokia SR OS YANG modules can be used with the <candidate> datastore. The Alcatel-Lucent Base-R13 SR OS YANG modules are not applicable to the <candidate> datastore, but are applicable to the <running> datastore. All <edit-config> requests to the <candidate> datastore must use the urn:nokia.com:sros:ns:yang:sr:conf namespace.
The candidate datastore supports the XML content layer only. Requests/replies to/from the candidate datastore cannot contain the CLI content layer.
The following base protocol operations are supported:
The following optional capabilities from RFC 6241 are supported:
The following capability from RFC 6243 is supported:
The following capabilities from RFC 5277 are supported:
The following capability from RFC 6022 is supported:
The following capability from RFC 7950 is supported:
One rpc request can only contain one operation.
Table 73 shows supported NETCONF operations.
Operation | Arguments |
get-config | source [filter] |
edit-config | target [default-operation][test-option][error-option] config |
copy-config | target source |
delete-config | target |
lock | target |
unlock | target |
get | [filter] |
close-session | n/a |
kill-session | session-id |
discard-changes | n/a |
validate | source |
commit | [confirmed] [confirm-timeout] [persist] [persist-id] |
cancel-commit | [persist-id] |
create-subscription | [stream] [startTime] [stopTime] |
get-schema | identifier [version] [format] |
Note: Bracketed arguments are optional. |
The CLI content layer <get> operation is supported with both configuration and state data returned in a <get> reply. An XML content layer <get> operation, supported with both configurations and state data, being returned in a <get> reply as per the NOKIA SR OS YANG data models only.
A <get> request is first analyzed for syntax errors before any execution starts. If a syntax error is found then a single global <rpc-error> for the entire request is sent in the reply.
Responses are provided for each item in the request until the first item with an error is found. The item with an error has a <response> tag containing some error information, followed by an <rpc-error> tag (and sub-tags). The reply is then returned and subsequent items are not executed.
The <rpc-error> for an individual item (i.e. for a non-syntax error) is after the </response> information and not inside the <response>.
Example — <get> request with a non-syntax error in the 2nd item:
Reply:
The <get-config> operation returns non-default configuration by default for the Alcatel-Lucent Base-R13 SR OS YANG modules (the 'trim' mode as per RFC 6243).
The <get-config> operation returns data nodes that were set by a client to their default values for the NOKIA SR OS modules (the 'explicit' mode as per RFC 6243).
The following values for the <test-option> parameter under <edit-config> are supported:
The "replace" value for the "operation" parameter and the "default-operation" parameter is supported.
The <error-option> is not supported. SR OS implements the stop-on-error behavior by default. The continue-on-error and rollback-on-error are not supported.
The <copy-config> and <delete-config> base protocol operations are supported for specific combinations of source and target datastores.
The <copy-config> operation is supported for the following combinations of sources and targets:
The <running> datastore cannot be a <target> for a <copy-config>.
The <candidate> datastore cannot be a <target> or a <source> for a <copy-config>.
Remote URL to remote URL copies are not supported. For example, if primary-image is a remote URL, then a <startup> to copy will fail with an error.
The <copy-config> operation uses the CLI Content Layer format. The format of the source and target is block CLI.
The <delete-config> operation is supported for the following targets:
The <delete-config> operation is not allowed on the <running> or <candidate> datastores.
Taking the <candidate> datastore’s lock is equivalent to doing a CLI exclusive transaction.
Although the NETCONF protocol allows specifying a target datastore for a lock operation, SR OS only implements a single lock:
When either the running datastore’s lock or the candidate datastore’s lock is taken by a NETCONF session:
A datastore’s lock is unlocked when disconnecting a NETCONF session (either from the CLI using Ctrl-c, or by performing a <kill-session> or <close-session> operation). Upon disconnecting a NETCONF session that had acquired a datastore’s lock, SR OS:
Note: The behavior is different if the disconnected NETCONF session had the “implicit” lock (see the <edit-config> with XML Content Layer section). In that case, SR OS keeps the “uncommitted” changes in the <candidate> datastore. |
Timeouts of locks are not supported. No specific admin/tools commands are provided to release the lock without disconnecting the session that holds it, but the session that holds the lock can be administratively disconnected using a CLI command to release the lock.
Using a CLI show command, the operator can determine if the <running> datastore is locked, the <candidate> datastore is locked, or both are locked, and the session ID of the session that holds the lock; see the NETCONF Show and Debug Command Reference.
From CLI, the operator can configure whether users that belong to a specific profile have permission to lock NETCONF sessions; see the NETCONF Configuration Command Reference.
An active NETCONF session can be disconnected from the CLI using the session ID. The user can use the show command to find the NETCONF session ID then use the admin command to disconnect the NETCONF session using the session ID obtained from the show command. For details, see the NETCONF Show and Debug Command Reference.
Because there is a single lock per datastore regardless of what the scope of that lock is, the following applies.
Performing an <unlock> operation on the candidate datastore discards all pending (not committed) candidate datastore changes.
The <commit> command has the following characteristics.
The :confirmed-commit capability is advertised in the SR OS NETCONF server <hello> as:
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
The :confirmed-commit capability has the following characteristics:
Parameter | Description |
<confirmed> | This parameter indicates it is a confirmed <commit> operation. |
<confirm-timeout> | This parameter specifies the timeout period for confirmed commit (in seconds). If unspecified, the confirmed commit timeout defaults to 600 seconds (10 minutes). |
<persist> | This parameter configures the confirmed commit changes to survive a session termination. It sets a token on the ongoing confirmed commit. If <persist> is not given in the confirmed commit operation, any follow-up commit and the confirming commit must be issued on the same session that issued the confirmed commit. If <persist> is given in the confirmed commit operation, a follow-up commit and the confirming commit can be given on any session, but they must include a <persist-id> element with a value equal to the value of the <persist> element in the confirmed commit. The <persist> element can not be changed through a follow-up confirmed commit. |
<persist-id> | This parameter issues a follow-up confirmed commit or the confirming commit from any session, using the same token from the <persist> element of the confirmed commit. The <persist-id> element cannot be changed through a follow-up confirmed commit. |
The <discard-changes> operation causes the <candidate> datastore to revert back to match the <running> datastore and releases the “implicit” lock. From the CLI, the operator can do the equivalent of a <discard-changes> operation which releases the implicit lock as well (see NETCONF Admin Command Reference).
The validate capability is supported in the following ways:
A <get-schema> operation is supported for explicit schema retrieval via NETCONF. See NETCONF Monitoring for more information.
Table 75 shows the which operations are supported by data model and datastore combination.
Operation | R13 Modules | Nokia Modules | ||
<running> | <candidate> | <running> | <candidate> | |
<edit-config> | supported | not supported | not supported | supported |
<get-config> | supported | not supported | supported | supported |
<get>* | not supported | retrieves both configuration and state data (XML format only) |
* - Note that the <running> or <candidate> datastores are not applicable for a <get> operation.
A <get> operation can retrieve CLI content layer state data.
Pressing Ctrl-c in a NETCONF session will immediately terminate the session.
The SR OS NETCONF implementation does support XML namespaces (xmlns).
If an invalid namespace is specified within the client's hello message, no error will be returned as the NETCONF server is still waiting for the client to send a valid <hello/>. Further NETCONF requests (without sending a proper hello message) even though correct, SR OS returns an error in that case indicating that “Common base capability not found.”
In the <rpc> element, the allowed XML namespaces are:
In the <rpc> element, prefixes are accepted and have to be specified with a valid URI. If an incorrect URI is declared with a prefix, then SR OS detects the invalid URI and sends an <rpc-error> response.
If any other XML namespace is declared (or assigned to a prefix) in the RPC tag, then SR OS returns an error.
Any prefix declarations in the rest of the request are ignored and unused. The SR OS NETCONF server puts the correct NETCONF namespace declaration (“urn:ietf:params:xml:ns:netconf:base:1.0”) in all replies.
An <edit-config> request must specify which data model (Alcatel-Lucent Base-r13 or Nokia SR OS) is being used in the top level <configure> element.
Example 1 — the standard NETCONF namespace “urn:ietf:params:xml:ns:netconf:base:1.0” is used more than once in the <rpc> element:
Reply (no error message):
Example 2 — an allowed non-default NETCONF base namespace is used in the <rpc> element:
Reply (non-NETCONF base namespace is allowed and no error is returned):
Example 3 — an invalid NETCONF namespace is declared in the <rpc> element:
Reply (SR OS returns an error):
Example 4 — a non-default NETCONF namespace/prefix declared in any child tag overrides the one declared under rpc tag:
Reply (non-standard namespace/prefix used in tag is ignored):
The chunked framing mechanism is supported (in addition to the EOM mechanism). As per RFC 6242, Section 4.1 - Framing Protocol, “[...] If the :base:1.1 capability is advertised by both peers, the chunked framing mechanism (see Section 4.2) is used for the remainder of the NETCONF session. Otherwise, the end-of-message-based mechanism (see Section 4.3) is used.”
Example 5 — Chunked message:
Example 6 — Chunked message:
Handling of default data (for example, “info” vs “info detail”) uses the mechanisms detailed in RFC 6243. The SR OS NETCONF server supports the 'trim' method as the default for the Alcatel-Lucent Base-R13 SR OS YANG modules. It supports the 'explicit' method as the default for the NOKIA SR OS Yang modules and also supports the 'report-all' method.
The advertised capability changes depending on which YANG modules are enabled or disabled in SR OS:
A user can save a rollback checkpoint (for example, prior to doing an <edit-config> or a series of <edit-config>) and perform a rollback revert if needed later using the <cli-action> RPC.
The set of supported actions are as follows:
Example 7 — Two rollback items with responses:
Reply:
Example 8 — Syntax error in the request resulting in global rpc-error reply:
Reply:
Example 9 — Error processing the request:
Reply:
Example 10 — Error in the 2nd item of the request, resulting in no 3rd item in the reply:
Reply:
A debug system netconf info command can be used to dump NETCONF debug message streams. For further details and an example, see the NETCONF Show and Debug Command Reference.
The following example shows a client on a Linux PC initiating a connection to an SR OS NETCONF server. The SSH session must be invoked using an SSH subsystem (as recommended in RFC 6242):
The following example shows an exchange of hello messages which include advertisement of capabilities.
From the SR OS server:
A NETCONF client can reply with a hello message like the following:
XML is the default content layer format for the SR OS NETCONF server. When using the XML format at the NETCONF content layer, configuration changes and configuration information retrieved are expressed as XML tags.
A <get> operation with an XML content layer is supported with the <candidate> datastore only. A <get> request retrieves both the configuration and state data from the “urn:nokia.com:sros:ns:yang:sr:conf” namespace (the Nokia SR OS YANG modules) only. If any nodes from the configure tree are included in a <get> request filter, then at minimum the <configure> tag must contain a namespace. If the namespace is not specified, SR OS returns an error.
Example 1: The <configure> tag contains a namespace
Reply: no errors
Example 2: The <configure> tag does not contain a namespace
Reply: SR OS errors
Example 3: The <state> tag contains a namespace
Reply: No errors
Example 4: The <state> tag does not contain a namespace
Reply: SR OS errors
An <edit-config> operation is supported with the <running> datastore and the <candidate> datastore.
The <edit-config> requests to the <candidate> datastore can only write XML-formatted content.
The <edit-config> requests that specify the running datastore as a target while using the “urn:nokia.com:sros:ns:yang:sr:conf” namespace (the Nokia SR OS YANG modules) result in an error response.
Example 1: using the <running> datastore with the urn:nokia.com:sros:ns:yang:sr:conf” namespace
Reply: with SR OS errors
There is an internal “implicit” lock that has a scope of all configuration commands in SR OS (not just the “urn:nokia.com:sros:ns:yang:sr:conf” namespace). The following actions take/release the “implicit” lock:
The following scenarios are impacted when an “implicit” lock is taking place:
One or more <edit-config> requests can be performed on the candidate datastore before the changes are committed or discarded.
NETCONF <edit-config> and <commit> operations impact the configuration of the router and, as with some CLI or SNMP configuration changes, additional actions or steps may need to occur before certain configuration changes take operational effect. Some examples include:
The supported <edit-config> operation attribute values are listed in Table 76.
Command | Notes |
urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 namespace Alcatel-Lucent Base-R13 SR OS YANG modules | |
merge (Base-R13 SR OS modules) |
|
remove (Base-R13 SR OS modules) |
|
delete (Base-R13 SR OS modules) |
|
create (Base-R13 SR OS modules) |
|
replace (Base-R13 SR OS modules) |
|
urn:nokia.com:sros:ns:yang:sr:conf namespace Nokia SR OS YANG modules | |
merge (Nokia SR OS modules) |
|
remove (Nokia SR OS modules) |
|
delete (Nokia SR OS modules) |
|
create (Nokia SR OS modules) |
|
replace (Nokia SR OS modules) |
|
The <edit-config> operation’s <default-operation> parameter is supported with the following values:
For <delete> and <remove> operations in the Nokia SR OS namespace, the SR OS NETCONF server will recursively “unwind” any children of the node being deleted or removed first before removing the node itself. The 'deepest' child branch of the request is examined first and any leaves are processed, after which the server works backwards out of the deepest branches back up to the object where the delete operation was specified.
For urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules), if child branches of an object are required to be removed before deleting the object in the CLI, then the equivalent delete request in a NETCONF <edit-config> request must contain all those children if they exist). For example:
In the example above, SR OS will first shut down the test interface, then delete the interface, then shut down the VPLS, and then finally remove it.
Note: In the urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules), the 'operation="merge"' is required in the shutdown nodes; otherwise the inherited operation is delete, which is not supported on boolean leaves. |
In the example above, if other children of vpls 11 exist in the config besides the interface test specified in the delete request above, and those children are required in the CLI to be deleted before removing vpls 11, then the deletion request above will fail. All configured children must be specified in the delete request.
The following applies to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules).
A <get-config> operation is supported with the <running> datastore and the <candidate> datastore.
The <get-config> requests on the <candidate> datastore return only XML-formatted content.
On a <candidate> datastore, if no filter is specified, SR OS returns the Nokia SR OS configurations only.
On the <running> datastore, if no filter is specified, SR OS returns both the Alcatel-Lucent Base-R13 configurations and the Nokia SR OS configurations.
On the <running> datastore, to return configurations from the Alcatel-Lucent Base-R13 configurations only (or the Nokia SR OS configurations only), the user must specify at least a top-level tag and a namespace in the filter. If the namespace is not specified, SR OS returns an error.
The following applies to the urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules):
The following applies to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules):
Using the 'report-all' value with the <with-defaults> tag (RFC 6243) in an XML-content layer <get-config>, returns the equivalent of the CLI command info detail (the returned data includes attributes that are set to their default values).
Example 1: use of <with-defaults> with a value of "report-all"
Reply: returns even attributes with default values
Example 2: without using <with-defaults>
Reply: Attributes with default values are not returned
Subtree filtering is supported for XML content layer <get-config> and <get> requests.
The subtree filtering behavior is as follows.
Example 6 — A non key leaf is specified as a content match node.
Multiple key leafs for the same key cannot be requested inside the same instance of the list name node; for example, <interface-name>abc</interface-name><interface-name>def</interface-name>. Each key value must be inside its own instance of the list name node; for example, <interface><interface-name>abc</interface-name></interface><interface><interface-name>def</interface-name></interface>.
Example 7 — Content match node on a list key.
The reply will contain all the configuration for all child nodes of config>router
The full configuration (equivalent to the CLI command 'admin display-config') can be obtained via a <get-config> request:
The following examples can be used after a NETCONF session has been established including the exchange of the <hello> messages.
The following is an example of a <get-config> request on the <running> datastore to check on whether netconf is shut down or not on the router:
Reply:
The following is an example for a <get-config> request on the <candidate> datastore to get the full configurations of the system, qos and log branches:
Reply:
The following is an example of an <edit-config> request om the <running> datastore to create a basic VPRN service:
Reply:
The following is an example of an <edit-config> request on the <candidate> datastore to create a basic epipe service:
Reply:
When using the CLI format at the NETCONF content layer, configuration changes and configuration information retrieved are expressed as untagged (non-XML) CLI commands; for example, CLI script.
The script must be correctly ordered and has the same dependencies and behavior as CLI. The location of CR/LF (ENTER) within the CLI for an <edit-config> is significant and affects the processing of the CLI commands, such as what CLI branch is considered the “working context”. In the following two examples, the “working context” after the commands are issued are different.
Example 1:
Example 2:
After example 1, the CLI working context is the root and immediately sending 'dst-zone CEST' would return an error. After example 2, the CLI working context is config>system>time and sending 'dst-zone CEST' would work as expected.
Configuration changes done via NETCONF trigger the same “change” log events (for example, tmnxConfigCreate) as a normal CLI user doing the same changes.
The <with-defaults> tag (RFC 6243, With-defaults capability for NETCONF) is not supported in a CLI content layer request.
The operator can get a full configuration including defaults for a CLI Content Layer using an empty <cli-info-detail>. The full configuration (equivalent to the CLI command admin display-config [detail]) can be obtained via a <get-config> request in a CLI Content Layer format with an empty <cli-info> or <cli-info-detail> tag inside a <config-format-cli-block>. <report-all> is not supported.
Post-processing commands are ignored: "| match" (pipe match), "| count" (pipe count) and ">" (redirect to file) and CLI ranges are not supported for any command; for example, show card [1..5].
The following examples can be used after a NETCONF session has been established including the exchange of the <hello> messages.
The following shows an example of a configuration change request and response.
Note: The exit all command is not required at the beginning of the CLI block; it is automatically assumed by the SR OS NETCONF server. |
Reply:
The following is an example of a <get-config> request and response to retrieve configuration information:
Reply:
The following example shows a <get-config> request and response to retrieve full configuration information.
Note: The <cli-info-detail/> request can be used to get the full configuration, including default settings. |
Reply:
The following is an example of a <get> request and the response to it:
Reply:
NETCONF notifications support is a standard IETF asynchronous notification delivery service for the Network Configuration protocol (NETCONF) that is published in RFC 5277.
The :notification capability and the :interleave capability are advertised in the SR OS NETCONF server <hello> as:
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability> <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
The following are characteristics of the NETCONF notifications capabilities supported in SR OS:
The following example shows a <create-subscription> operation and the received response:
Reply:
The following is an example for a sros-config-change-event notification:
The following is an example for a sros-state-change-event notification:
The following is an example for a sros-cli-accounting-event notification:
The following is an example for a sros-log-generic-event notification:
The following is an example for a netconf-config-change notification:
In a <create-subscription>, a <filter> is an optional argument that is not supported by SR OS.
In a <create-subscription>, a <startTime> is an optional argument. This argument triggers the starting time of a replay. If it is not present, the subscription cannot be used to replay. A <startTime> cannot specify a time that is later than the current time (that is, in the future). SR OS supports timezones.
In a <create-subscription>, a <stopTime> is another optional argument. If this argument is not present, notifications continue to be sent until the subscription is terminated. A <stopTime> can specify a time that is later than the current time (that is, in the future). SR OS supports timezones.
A replay buffer is maintained by the SR OS server (per-stream) and sorted by the order they were initially sent out (that is, by sequence-id, and not by timestamps).
The :ietf-netconf-monitoring capability is advertised in the SR OS NETCONF server <hello> as:
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</capability>
The advertised capability provides information about the schemas supported by SR OS which allows a NETCONF client to query and retrieve schema information from the SR OS NETCONF server.
SR OS supports the "/netconf-state/schemas" subtree only from the YANG model that is used to monitor the NETCONF protocol as per RFC6022 (that is, ":ietf-netconf-monitoring" capability).
SR OS links retrieving the supported schemas to all the CLI commands that are used to enable and disable the YANG modules. The following are examples:
The following example shows a request and the received response:
Reply:
A <get-schema> operation is supported for explicit schema retrieval using NETCONF (YANG data models' discovery and download as per RFC6022). The following parameters are supported:
The configure system management-interface schema-path CLI command can be used to configure the "schema-path" (default = "cf3:/YANG"). See the schema-path command description in Classic and Model-Driven Management Interfaces Command Reference for more information.
Operators should initially copy all the YANG files to the specified schema-path location.
A <get-schema> operation can not be used with the ALU base-r13 YANG set.
When the requested schema does not exist, the <error-tag> returned is "invalid-value".
When more than one schema matches the requested parameters, the <error-tag> returned is "operation-failed".
The following is an example:
Reply:
SR OS supports a mechanism, a YANG library, to identify the YANG modules and submodules that are implemented by the NETCONF server. NETCONF clients should be able to query or cache the YANG library contents and identify whether their cache is out-of-date.
The SR OS NETCONF server advertises the following capability in the <hello> message:
The following is the YANG Tree Diagram for the modules-state:
The module-set-id is a mandatory leaf that identifies a set of YANG modules that the SR OS NETCONF server supports. The value of this leaf changes whenever there is a change in the set of modules or submodules in the YANG library. When this change occurs, SR OS changes the module-set-id value advertised in the NETCONF server <hello> message.
The modules-state can be used by the NETCONF client to fetch the YANG library, cache it and re-fetch it only if the value of the module-set-id changes again. The YANG library is returned in the module list.
Example: