5. NETCONF

5.1. NETCONF Overview

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.

Figure 15:  NETCONF RPC Request 

NETCONF can be conceptually partitioned into four layers as described in RFC 6241. Figure 16 shows the NETCONF layers.

Figure 16:  NETCONF Layers (RFC 6241) 

5.2. NETCONF in SR OS

NETCONF can be used on an SR OS router to perform router management operations including:

  1. Changing the configuration of the router (<edit-config> operation)
  2. Reading the configuration of the router (<get-config> operation, equivalent to the info command in the SR OS CLI)
  3. Reading operational status and data (and associated configuration information) (<get> operation, equivalent to the show commands in the SR OS CLI)
  4. Notifications on an SR OS router; equivalent to the SR OS log events.

The equivalent of some admin commands are available via the SR OS NETCONF interface:

  1. admin save can be done using the <copy-config> operation
  2. admin rollback commands are supported using a CLI content layer <cli-action> RPC

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.

5.2.1. Transport and Sessions

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.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get>
                <filter>
                        <oper-data-format-cli-block>
                                <cli-show>system security profile </cli-show>
                        </oper-data-format-cli-block>
                </filter>
        </get>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>cli-show</err-element>
        </error-info>
        <error-message>
            command failed - 'show system security profile'
            MINOR: CLI Command not allowed for this user.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

5.2.2. Datastores and URLs

SR OS supports the <running> datastore, the <candidate> datastore, the <startup> datastore, and <url> tag.

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> tag 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> tag 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:

  1. <target><url>ftp://name:passwd@a.b.c.d/usr/myfiles/myfile.cfg</url></target>
  2. <target><url>tftp://name:passwd@a.b.c.d/usr/myfiles/myfile.cfg</url></target>
  3. <target><url>file:///cf3:/myfiles/myfile.cfg</url></target>
  4. <target><url>cf3:/myfiles/myfile.cfg</url></target>
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.

5.2.3. NETCONF Operations and Capabilities

The following base protocol operations are supported:

The following optional capabilities from RFC 6241 are supported:

  1. Writable-Running Capability
  2. Candidate Configuration Capability
    1. <commit> operation
  3. Confirmed Commit Capability
  4. Validate Capability
    1. <validate> operation
  5. Distinct Startup Capability
  6. URL Capability

The following capability from RFC 6243 is supported:

  1. With-defaults Capability

One rpc request can only contain one operation.

Table 60 shows supported NETCONF operations.

Table 60:   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

n/a

Note:

Bracketed arguments are optional.

5.2.3.1. <get>

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:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get>
                <filter>
                        <oper-data-format-cli-block>
                                <cli-show>router interface "system"</cli-show>
                                <cli-show>router mpls lsp</cli-show>
                                <cli-show>system security ssh</cli-show>
                        </oper-data-format-cli-block>
                </filter>
        </get>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <oper-data-format-cli-block>
            <item>
                <cli-show>router interface "system"</cli-show>
                <response>
 
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name                   Adm         Opr(v4/v6)  Mode    Port/SapId
   IP-Address                                                    PfxState
-------------------------------------------------------------------------------
system                           Up          Up/Down     Network system
   10.23.63.5/32                                                n/a
-------------------------------------------------------------------------------
Interfaces : 1
===============================================================================
                </response>
            </item>
            <item>
                <cli-show>router mpls lsp</cli-show>
                <response>
                    MINOR: CLI MPLS is not configured.
                </response>
                <rpc-error>
                    <error-type>application</error-type>
                    <error-tag>operation-failed</error-tag>
                    <error-severity>error</error-severity>
                    <error-info>
                        <err-element>cli-show</err-element>
                    </error-info>
                    <error-message>
                        command failed - 'show router mpls lsp'
                    </error-message>
                </rpc-error>
            </item>
        </oper-data-format-cli-block>
    </data>
</rpc-reply>
]]>]]>

5.2.3.2. <get-config>

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).

5.2.3.3. <edit-config>

The following values for the <test-option> parameter under <edit-config> are supported:

  1. test-then-set
  2. set
  3. test-only

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.

5.2.3.4. <copy-config> and <delete-config>

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:

  1. <source>=<url> and <target>=<startup> (as long as both are not remote urls)
  2. <source>=<startup> and <target>=<url> (as long as both are not remote urls)
  3. <source>=<running> and <target>=<url>
    1. Equivalent of “admin save <file-url>”
    2. An index file is also saved if “persist on” is configured in the bof
  4. <source>=<running> and <target>=<startup>
    1. Equivalent of “admin save”
    2. An index file is also saved if “persist on” is configured in the bof

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:

  1. <url>
  2. <startup>

The <delete-config> operation is not allowed on the <running> or <candidate> datastores.

5.2.3.5. <lock>

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:

  1. taking the running datastore’s lock locks both the running and candidate datastores (creating a single lock)
  2. taking the candidate datastore’s lock locks both the running and candidate datastores (creating a single lock)

When either the running datastore’s lock or the candidate datastore’s lock is taken by a NETCONF session:

  1. no NETCONF session can take the <running> datastore lock
  2. no NETCONF session can take the <candidate> datastore lock
  3. no other NETCONF session can do an <edit-config> on the running datastore
  4. no other NETCONF session can do an <edit-config> on the candidate datastore
  5. no other NETCONF session can do a <commit> on the candidate datastore
  6. no other NETCONF session can do a <discard-changes> on the candidate datastore
  7. CLI becomes read-only
  8. rollback revert is blocked
  9. SNMP set requests fail on objects that are part of the urn:nokia.com:sros:ns:yang:sr:conf-* namespace

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:

  1. releases the lock
  2. discards the “uncommitted” changes (if any)
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.

5.2.3.6. <unlock>

Because there is a single lock per datastore regardless of what the scope of that lock is, the following applies.

  1. The <running> datastore’s lock is unlocked by using the <unlock> command only on the <running> datastore. An error results and the lock stays if a different datastore is used with the <unlock> operation.
  2. The <candidate> datastore’s lock is unlocked by using the <unlock> command only on the <candidate> datastore. An error results and the lock stays if a different datastore is used with the <unlock> operation.

Performing an <unlock> operation on the candidate datastore discards all pending (not committed) candidate datastore changes.

5.2.3.7. <commit>

The <commit> command has the following characteristics.

  1. It represents the equivalent of the CLI command candidate commit.
  2. When a <commit> operation fails, only the first error is returned.
  3. When SR OS cannot commit all the changes in the candidate datastore, SR OS keeps the <running> datastore unchanged.
  4. When a NETCONF session is disconnected (using Ctrl-c or <kill-session>) in the middle of a <commit> operation, SR OS keeps the running datastore unchanged.
  5. The persistency of changes made via a <commit> operation is operator-controlled. A copy of the running datastore to the startup datastore can be automatically performed after each successful <commit> operation. This behavior can be enabled or disabled through a CLI command.
  6. When some changes exist in the candidate datastore (prior to being committed to the running datastore), there are impacts to:
    1. a CLI user trying to make immediate changes, as SR OS blocks all CLI immediate configurations
    2. an SNMP set request, as SR OS blocks the request and returns an error
    3. an <edit-config> to the running datastore, as SR OS blocks all <edit-config> requests to the running datastore and returns an error

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:

  1. The capability is not advertised if the operator disables the candidate DS capability using the available SR OS CLI command.
  2. The parameters listed in Table 61 are supported for the <commit> operation.
    Table 61:   Parameters for a <commit> Operation 

    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.

  3. If <persist> was specified in the confirmed commit, the configuration changes are rolled back only if the timeout expires before receiving a confirming commit. The confirming commit has to include a <persist-id> tag with a value equal to the value of the <persist> tag that was in the confirmed commit.
  4. If the NETCONF session that initiated the confirmed commit is closed while waiting for the confirming commit (for example, disconnected), then SR OS restores the configuration to its state before the confirmed commit was issued. This is valid only if <persist> was not defined in the confirmed commit.If a follow-up confirmed commit is issued before the timer expires, the timer is reset to the new value.
  5. The confirming commit and the follow-up confirmed commit cannot introduce additional changes to the configuration.The <cancel-commit> operation is supported. It can cancel an ongoing confirmed commit (that is, cancel the timer and rollback the changes introduced with the confirmed commit).
  6. If the <persist> parameter is not given, the <cancel-commit> operation must be issued on the same session that issued the confirmed commit.

5.2.3.8. <discard-changes>

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 (seeNETCONF Admin Command Reference).

5.2.3.9. <validate>

The validate capability is supported in the following ways:

  1. The validate:1.1 and 1.0 capabilities are advertised in the NETCONF server's <hello> as:
    1. <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
    2. <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
  2. The <validate> operation is supported for an XML content layer request but not for a CLI content layer request. Detection of a <config-format-cli-block> or <oper-data-format-cli-block> tag in a <validate> request will result in an “operation not supported” error response.
  3. A <validate> operation is supported for a selection of config (<source><config>) for both the <candidate> datastore and the <running> datastore, which only returns 'OK'. The <validate> request is not supported for URL sources or the <startup> datastore.
  4. A <validate> operation checks mainly the syntax. Only the first error is returned.

5.2.4. Data Model, Datastore and Operation Combinations

Table 62 shows the which operations are supported by data model and datastore combination.

Table 62:  Data Model, Datastore and Operation Combinations 

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 datastore is not applicable for a <get> operation

A <get> operation can retrieve CLI content layer state data.

5.2.5. General NETCONF Behavior

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:

  1. the standard NETCONF “urn:ietf:params:xml:ns:netconf:base:1.0” namespace
  2. the SR OS “urn:alcatel-lucent.com:sros:ns:yang:conf-r13” namespace
  3. the SR OS “urn:nokia.com:sros:ns:yang:sr:conf” namespace

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.

  1. SR OS accepts a request with only a single namespace at the top <configure> element. For example:
           <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
              <system>
                   ....
    Or:
           <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
              <system>
                   ....
  2. The NETCONF client can declare those two namespaces with prefixes at the <rpc> tag itself and use the corresponding prefixes later in the request's <configure/> block.
  3. SR OS returns an error if the request contains one or more incorrect namespaces.

Example 1 — the standard NETCONF namespace “urn:ietf:params:xml:ns:netconf:base:1.0” is used more than once in the <rpc> element:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source> <running/> </source>
<filter>
    <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
        <router>
            <interface>
               <interface-name>"system"</interface-name>
            </interface>
        </router>
    </configure>
</filter>
</get-config>
</rpc>
]]>]]>

Reply (no error message):

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
 xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <router>
                <router-instance>Base</router-instance>
                <interface>
                    <interface-name>system</interface-name>
                    <shutdown>false</shutdown>
                </interface>
            </router>
        </configure>
    </data>
</rpc-reply>
]]>]]>

Example 2 — an allowed non-default NETCONF base namespace is used in the <rpc> element:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
<get-config>
<source> <running/> </source>
<filter>
    <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
        <router>
            <interface>
              <interface-name>"system"</interface-name>
            </interface>
        </router>
    </configure>
</filter>
</get-config>
</rpc>
]]>]]>

Reply (non-NETCONF base namespace is allowed and no error is returned):

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
 xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <router>
                <router-instance>Base</router-instance>
                <interface>
                    <interface-name>system</interface-name>
                    <shutdown>false</shutdown>
                </interface>
            </router>
        </configure>
    </data>
</rpc-reply>
]]>]]>

Example 3 — an invalid NETCONF namespace is declared in the <rpc> element:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:sr:conf">
        <get-config>
                <source><running/></source>
                <filter>
                    <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                            <router>
                                    <interface>
                                         <interface-name>"system"</interface-name>
                                    </interface>
                            </router>
                    </configure>
                </filter>
        </get-config>
</rpc>
]]>]]>

Reply (SR OS returns an error):

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
 xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:sr:conf">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>unknown-element</error-tag>
        <error-severity>error</error-severity>
        <error-info>
          <bad-element>rpc</bad-element>
          <bad-namespace>urn:alcatel-lucent.com:sros:ns:yang:sr:conf</bad-namespace>
        </error-info>
        <error-message>
            An unexpected namespace is present.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

Example 4 — a non-default NETCONF namespace/prefix declared in any child tag overrides the one declared under rpc tag:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source> <running/> </source>
<filter>
    <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
        <router>
            <interface xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                 <alu:interface-name>"system"</alu:interface-name>
            </interface>
        </router>
    </configure>
</filter>
</get-config>
</rpc>
]]>]]>

Reply (non-standard namespace/prefix used in tag is ignored):

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
 xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <router>
                <router-instance>Base</router-instance>
                <interface>
                    <interface-name>system</interface-name>
                    <shutdown>false</shutdown>
                </interface>
            </router>
        </configure>
    </data>
</rpc-reply>
]]>]]>

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:

#340
<?xml version="1.0" encoding="UTF-8"?><rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config><source><running/>
</source>
<filter><configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
<router><interface>
<interface-name>system</interface-name></interface></router></configure></filter>
</get-config></rpc>
##

Example 6 — Chunked message:

#38
<?xml version="1.0" encoding="UTF-8"?>
#83
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
#101
<source><running/></source>
<filter>
<configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
##39
<system>
<netconf>
</netconf>
</system>
##43
</configure>
</filter>
</get-config>
</rpc>
##

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 and advertises that in the <hello>:

<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-
mode=trim&amp;also-supported=explicit,report-all</capability>

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:

  1. admin>rollback compare [to checkpoint2]
  1. admin>rollback compare checkpoint1 to checkpoint2
  1. admin>rollback delete checkpoint | rescue
  1. admin>rollback save [comment comment] [rescue]
  1. admin>rollback revert checkpoint | rescue [now]
  1. admin>rollback view [checkpoint | rescue]

Example 7 — Two rollback items with responses:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <cli-action>
    <admin>rollback compare active-cfg to 1</admin>
    <admin>rollback compare</admin>
  </cli-action>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <cli-action>
            <item>
                <admin>rollback compare active-cfg to 1</admin>
                <response> 
            0.150 s 
            0.450 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-            lsp "test"
-                shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 0.720 s
                </response>
            </item>
            <item>
                <admin>rollback compare</admin>
                <response>       
            0.160 s
            0.070 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-            lsp "test"
-                shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
     service
-        vpls "99" customer 1 create
-            shutdown
-            stp
-                shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 0.350 s
                </response>
            </item>
        </cli-action>
    </data>
</rpc-reply>
]]>]]>

Example 8 — Syntax error in the request resulting in global rpc-error reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="103" 
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <cli-action>  
      <admin>rollback compare active-cfg to 1</admin>
      <admin>rollback compare flee-fly</admin>
  </cli-action>
</rpc>
]]>]]>
 

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="103" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>admin</err-element>
        </error-info>
        <error-message>
            command failed - '/admin rollback compare flee-fly'
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

Example 9 — Error processing the request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="103" 
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <cli-action>  
      <admin>rollback compare active-cfg to 1</admin>
      <admin>rollback compare 1 to flee-fly</admin>
  </cli-action>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="103" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <cli-action>
            <item>
                <admin>rollback compare active-cfg to 1</admin>
                <response> 
            0.160 s
            0.180 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 0.460 s
                </response>
            </item>
            <item>
                <admin>rollback compare 1 to flee-fly</admin>
                <response>
                </response>
                <rpc-error>
                    <error-type>application</error-type>
                    <error-tag>operation-failed</error-tag>
                    <error-severity>error</error-severity>
                    <error-info>
                        <err-element>admin</err-element>
                    </error-info>
                    <error-message>
                        command failed - '/admin rollback compare 1 to flee-fly'
                        MINOR: CLI No such file ('flee-fly').
                    </error-message>
                </rpc-error>
            </item>
        </cli-action>
    </data>
</rpc-reply>
]]>]]>

Example 10 — Error in the 2nd item of the request, resulting in no 3rd item in the reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="104" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <cli-action>  
    <admin>rollback compare active-cfg to 1</admin>
    <admin>rollback compare 1 to xyz</admin>
    <admin>rollback compare active-cfg to 1</admin>
  </cli-action>
</rpc>
]]>]]>
 

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="104" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <cli-action>
            <item>
                <admin>rollback compare active-cfg to 1</admin>
                <response>       
            0.170 s
            1.350 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 1.640 s
                </response>
            </item>
            <item>
                <admin>rollback compare 1 to xyz</admin>
                <response>
                </response>
                <rpc-error>
                    <error-type>application</error-type>
                    <error-tag>operation-failed</error-tag>
                    <error-severity>error</error-severity>
                    <error-info>
                        <err-element>admin</err-element>
                    </error-info>
                    <error-message>
                        command failed - '/admin rollback compare 1 to xyz'
                        MINOR: CLI No such file ('xyz').
                    </error-message>
                </rpc-error>
            </item>
        </cli-action>
    </data>
</rpc-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.

5.2.5.1. System-Provisioned Configuration (SPC) Objects

There is a set of configuration objects that are provisioned (added to the <running> datastore) automatically by SR OS; for example, log-id 99. Some SPC objects are created at bootup time, and some are created or removed dynamically based on configuration. The dynamically created SPC objects are typically children objects created as a side effect of the creation of their parent object.

Some of these objects can be deleted/removed by a user (Deletable SPC Objects).

  1. In the CLI these are removed by specifying the keyword no, which is then visible in an info command or in a saved config (admin save); for example, no log-id 99.
  2. The Deletable SPC Objects can be removed or recreated via NETCONF <edit-config> requests, but they are not visible in a <get-config> response in the “urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13” namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules) when they are:
    1. set to their default values (including all child leaves and objects)
    2. removed or deleted
  3. The Deletable SPC Objects are visible in a <get-config> response in the “urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13” namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules) if a child leaf or object is changed away from the default value; for example, changing log-99 to time-format local.
  4. The Deletable SPC objects are not visible in a <get-config> response in the “urn:nokia.com:sros:ns:yang:sr:conf” namespace (the Nokia SR OS YANG modules) if the child leaves are all at default values.
  5. Some example deletable SPC objects are:
Config system security profile default
Config system security profile default entry 10-100
Config system security profile administrative
Config system security profile administrative entry 10-112
Config system security user "admin"
Config system security user console member "default"
Config system security snmp access group  xyz (a set of access groups)
Config system security ssh client-cipher-list protocol-version 1 cipher 200-210
Config system security ssh client-cipher-list protocol-version 2 cipher 190-235
Config system security ssh server-cipher-list protocol-version 1 cipher 200-205
Config system security ssh server-cipher-list protocol-version 2 cipher 190-235
Config log filter 1001
Config log filter 1001 entry 10
Config log log-id 99 & 100

Some SPC objects cannot be deleted (Non-Deletable SPC Objects).

  1. Although these objects cannot be deleted, some of them contain leaves that can be modified.
  2. The Non-Deletable SPC Objects are not visible in a <get-config> response in the “urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13” namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules) when they are set to their default values (including all child leaves and objects).
  3. The Non-Deletable SPC Objects are visible in a <get-config> response in the “urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13” namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules) if a child leaf or object is changed away from the default value; for example, setting the card-type.
  4. The Non-Deletable SPC objects are not visible in a <get-config> response in the “urn:nokia.com:sros:ns:yang:sr:conf” namespace (the Nokia SR OS YANG modules) if the child leaves are all at default values.
  5. Some example non-deletable SPC objects are:
Config system security user-template {tacplus_default|radius_default}
Config system security snmp view iso …
Config system security snmp view li-view …
Config system security snmp view mgmt-view …
Config system security snmp view vprn-view …
Config system security snmp view no-security-view …
Config log event-control …
Config filter log 101
Config qos … various default policies can’t be deleted
Config qos queue-group-templates … these can’t be deleted
Config card <x>  
Config router network-domains network-domain “default”
Config oam-pm bin-group 1
Config call-trace trace-profile “default”

Some Non-Deletable SPC Objects are visible in a <get-config> request in the “urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13” namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules), even if they are set to default values:

Config system security cpu-protection policy 254 and 255
Config router interface “system"
Config service customer 1

5.3. Establishing a NETCONF Session

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):

ssh -s my_username@a.b.c.d -p 830 netconf

The following example shows an exchange of hello messages which include advertisement of capabilities.

From the SR OS server:

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
        <capability>urn:ietf:params:netconf:base:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:writable-running:1.0</        capability>
        <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</        capability>
        <capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,tftp,file<        /capability>
        <capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-        mode=explicit&amp;also-supported=report-all</capability>
        <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-        netconf&amp;revision=2011-06-01&amp;features=writable-        running,validate,startup,url&amp;deviations=alu-netconf-deviations-r13</        capability>
        <capability>urn:alcatel-lucent.com:sros:ns:yang:netconf-deviations-        r13?module=alu-netconf-deviations-r13&amp;revision=2015-01-23</capability>
        <capability>urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-        r13?module=alu-cli-content-layer-r13&amp;revision=2015-01-23</capability>
        <capability>urn:alcatel-lucent.com:sros:ns:yang:conf-r13?module=alu-conf-        r13&amp;revision=2018-03-15</capability>
        ...
        ...
    </capabilities>
    <session-id>69</session-id>
</hello>
]]>]]>

A NETCONF client can reply with a hello message like the following:

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
    </capabilities>
</hello>
]]>]]>

5.4. XML Content Layer

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.

5.4.1. <get> with XML Content Layer

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

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
    <filter>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
             <python/>
        </configure>
    </filter>
</get>
</rpc>
]]>]]>

Reply: no errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <python xmlns="urn:nokia.com:sros:ns:yang:sr:conf-python">
                <python-script>
                    <script-name>testing</script-name>
                    <shutdown>false</shutdown>
                    <protection>
                    </protection>
                </python-script>
                <python-script>
                    <script-name>tested</script-name>
                    <protection>
                    </protection>
                </python-script>
            </python>
        </configure>
    </data>
</rpc-reply>
]]>]]>

Example 2: The <configure> tag does not contain a namespace

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
    <filter>
        <configure>
             <python xmlns="urn:nokia.com:sros:ns:yang:sr:conf-python">
             </python>
        </configure>
    </filter>
</get>
</rpc>
]]>]]>

Reply: SR OS errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>unknown-element</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <bad-element>configure</bad-element>
        </error-info>
        <error-message>
            Element is not valid in the specified context.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

Example 3: The <state> tag contains a namespace

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
        <filter>
                <state xmlns="urn:nokia.com:sros:ns:yang:sr:state">
                </state>
        </filter>
</get>
</rpc>
]]>]]>

Reply: No errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <state xmlns="urn:nokia.com:sros:ns:yang:sr:state">
...
...
        </state>
    </data>
</rpc-reply>
]]>]]>

Example 4: The <state> tag does not contain a namespace

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
        <filter>
                <state>
                </state>
        </filter>
</get>
</rpc>
]]>]]>

Reply: SR OS errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <bad-element>state</bad-element>
        </error-info>
        <error-message>
            Element is not valid in the specified context.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

5.4.2. <edit-config> with XML Content Layer

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

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <edit-config>
          <target><running/></target>
          <config>
              <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
                  <python>
                      <python-script>
                          <script-name>testing</script-name>
                      </python-script>
                  </python>
              </configure>
          </config>
     </edit-config>
</rpc>
]]>]]>

Reply: with SR OS errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>operation-not-supported</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <bad-element>running</bad-element>
        </error-info>
        <error-message>
            Writing to running datastore not supported in the specified namespace
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

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:

  1. The first NETCONF <edit-config> on a <candidate> datastore triggers the “implicit” lock
  2. The completion of a NETCONF <commit> releases the “implicit” lock
  3. A CLI admin command can release the “implicit” lock. For more information, see  5.11
  4. The NETCONF <discard-changes> command is supported in SR OS which releases the “implicit” lock as well

The following scenarios are impacted when an “implicit” lock is taking place:

  1. A NETCONF session attempting an <edit-config> (on either the Alcatel-Lucent Base-R13 SR OS data model or the Nokia SR OS data model) is blocked and SR OS replies with an error (the <error-info> element includes the <session-id> of the lock owner).
  2. A CLI command (on either the Alcatel-Lucent Base-R13 configuration set or the Nokia SR OS data model) is blocked and SR OS returns an error.
  3. A SNMP set request (on objects that are part of the “urn:nokia.com:sros:ns:yang:sr:conf” namespace only) is blocked and SR OS returns an error.

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:

  1. Configuration changes that require a shutdown and then no shutdown to be performed by an operator in order to take operational effect also need this explicit shutdown and then no shutdown to be performed via NETCONF (in separate edit-configs/commits) in order to take operational effect after those configuration items are changed. Some examples include:
    1. changes to Autonomous System or Confederation value require a BGP shutdown and then no shutdown
    2. changes to VPRN Max-routes requires a shutdown and then no shutdown on the VPRN service
    3. changes to OSPF/ISIS export-limit require a shutdown and then no shutdown on OSPF/ISIS
  2. Configuration changes to an msap-policy that normally require a tools perform subscriber-mgmt eval-msap command to take operational effect on subscribers that are already active. NETCONF can be used to change the msap-policy configuration, but if it must have the configuration changes applied to the active subscribers then the operator must run the eval-msap tools command.

The supported <edit-config> operation attribute values are listed in Table 63.

Table 63:   <edit-config> Operation Attribute Values 

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)

  1. For a merge operation, the operations and tags specified in an <edit-config> request are order-aware and order-dependent, and the sequence of merge operations must follow the required sequence of the equivalent CLI commands. The <edit-config> request is processed and executed in a top-down order. The same leaf can be enabled and disabled multiple times in the request and the final result is whatever was last specified for that leaf in the <edit-config> request.

remove (Base-R13 SR OS modules)

  1. A <remove> operation is not supported for boolean leaves. For example, any of the following example commands will return an error:
    1. <shutdown operation="remove"/>
    2. <shutdown operation="remove">false</shutdown>
    3. <interface operation="remove">
                  <interface-name>abc</interface-name>
                  <shutdown>true</shutdown>
                  </interface>
    (For this last case <shutdown operation="merge">true</shutdown> could be used instead to make the request valid.)
  2. A <remove> operation is the equivalent of no command in the CLI. This no command is applied whether the default for command is enabled (command), disabled (no command), or a specific value. The <remove> operation is not aware of the default value of the object or leaf being removed.
  3. A <remove> operation for a leaf where the request also specifies a value for the leaf, will result in an error.

delete (Base-R13 SR OS modules)

  1. A <delete> operation for a leaf or a presence container will not return an error if the item is already deleted.
  2. An error is returned if attempting to delete a list node that does not exist.
  3. A <delete> operation for a container without presence will return an error.
  4. A <delete> operation is not supported for boolean leaves. For example, any of the following example commands will return an error:
    1. <shutdown operation="delete"/>
    2. <shutdown operation="delete">false</shutdown>
    3. <interface operation="delete">
                 <interface-name>abc</interface-name>
                 <shutdown>true</shutdown>
                 </interface>
    (For this last case <shutdown operation="merge">true</shutdown> could be used instead to make the request valid.)
  5. A <delete> operation is the equivalent of no command in the CLI. This no command is applied whether the default for command is enabled (command), disabled (no command), or a specific value. The <delete> operation is not aware of the default value of the object/leaf being deleted.
  6. A <delete> operation on a node will ignore any values provided for that node (it will not check if that value is configured or valid), and it will ignore any data below that node (it will not check if that data exists or is valid).

create (Base-R13 SR OS modules)

  1. A <create> operation for a leaf or a presence container will not return an error if the item is being set to the same value.
  2. An error is returned if attempting to create a list node that already exists.
  3. A <create> operation for a container without presence will result in an “OK” response (no error) but will be silently ignored.
  4. For a <create> operation, the operations and tags specified in an <edit-config> request are order-aware and order-dependent, and the sequence of create operations must follow the required sequence of the equivalent CLI commands. The <edit-config> request is processed and executed in a top-down order. The same leaf can be enabled and disabled multiple times in the request and the final result is whatever was last specified for that leaf in the <edit-config> request.

replace (Base-R13 SR OS modules)

  1. not supported

urn:nokia.com:sros:ns:yang:sr:conf namespace

Nokia SR OS YANG modules

merge (Nokia SR OS modules)

  1. supported

remove (Nokia SR OS modules)

  1. A <remove> operation removes the deleted configuration and returns it to the default value.
  2. A <remove> operation automatically removes all child objects of a deleted object (leaves, lists, containers, and so on).
  3. Explicit shutdown of the object being removed (or any child) is not required and results in an error if a merge operation is specified on a tag that inherits a <remove> operation.
  4. A <remove> operation is allowed on non-presence containers. The non-presence container and all of its children are removed (for example, a non-presence container with no child nodes, is not displayed in a <get> or <get-config> reply).
  5. A <remove> operation is allowed on an object where all child branches and dependencies are automatically removed (but the <remove> operation fails if any outside objects refer to the object being removed).
  6. A <remove> operation is allowed on a <shutdown/> leaf (which returns it to its default value).
  7. A <remove> operation is allowed on a non-boolean leaf.
  8. Upon specifying a <remove> operation on a node where none of its children belong to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules), SR OS does not return an error and completes the node removal.
  9. A <remove> operation for a leaf where the request also specifies a value for the leaf, results in an error.

delete (Nokia SR OS modules)

  1. SR OS returns an error if a <delete> operation is performed on a list that does not specify a key (that is, an attempt to delete all members of a list).
  2. SR OS returns an error if a <delete> operation is performed on a leaf or presence container that is already deleted (or has the default value and the default-handling is trim).
  3. SR OS may return an error and may not complete the deletion operation when a <delete> operation is performed on a node where any of its children do not belong to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules).
  4. A <delete> operation removes the deleted configuration and returns it to the default value.
  5. A <delete> operation automatically deletes all child objects of a deleted object (leaves, lists, containers, and so on).
  6. Explicit shutdown of the object being deleted (or any of its children) is not required and results in an error if a merge operation is specified on a tag that inherits a <delete> operation.
  7. A <delete> operation is allowed on non-presence containers. The non-presence container and all of its children are deleted (for example, a non-presence container with no child nodes is not displayed in a <get> or <get-config> reply).
  8. A <delete> operation is allowed on an object where all child branches and dependencies are automatically deleted (but the <delete> operation fails if any outside objects refer to the object being deleted).
  9. A <delete> operation is allowed on a <shutdown/> leaf (which returns it to its default value).
  10. A <delete> operation is allowed on a non-boolean leaf.
  11. Upon specifying a <delete> operation on a node where none of its children belong to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules), SR OS does not return an error and completes the node deletion.
  12. A <delete> operation for a leaf where the request also specifies a value for the leaf, will result in an error.

create (Nokia SR OS modules)

  1. When a <create> operation for a leaf or presence container is performed, SR OS returns an error if the leaf or presence container is being set to the same value (unless the default-handling is trim and the value being set is the default value).

replace (Nokia SR OS modules)

  1. supported

The <edit-config> operation’s <default-operation> parameter is supported with the following values:

  1. replace
  2. merge
  3. none
    1. In the urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules), an operation of “none” on a leaf node (inherited or direct) causes that leaf statement to be ignored. No error will be returned if the leaf does not exist in the data model.
    2. In the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules), an operation of "none" (inherited or direct) on a leaf node that does not exist in the data model causes SR OS to return an error with an <error-tag> value of data-missing.

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:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <edit-config>
                <target><running/></target>
                <config>
                    <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                           <service>
                              <vpls operation="delete">
                                   <service-id>11</service-id>
                                    <interface>
                                        <ip-int-name>test</ip-int-name>
                                        <shutdown operation="merge">true</shutdown>
                                     </interface>
                                     <shutdown operation="merge">true</shutdown>
                               </vpls>
                            </service>
                     </configure>
                </config>
        </edit-config>
</rpc>
]]>]]>

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).

  1. SR OS returns an error if an explicitly defined <edit-config> operation (such as “delete”) is specified on a “key” leaf.
  2. The “operation” attribute is inherited from the parent node if not explicitly specified (same as namespaces). If no parent node is available, then the “default-operation” value is used. In other words, the “operation” attribute has a “scope” that it applies to the nested nodes until it is redefined. The following scenarios simplify the “operation” inheritance, where the first line in each scenario represents the operation value of the parent node and the following lines represent the possible operation values for the child nodes and the SR OS behavior in each case:
    1. Create
      Create/Merge: SR OS processes request (request succeeds/fails based on operation’s behavior)
      Delete/Remove: SR OS returns an error
    2. Merge
      Create/Merge/Delete/Remove: SR OS processes request (request succeeds/fails based on operation’s behavior)
    3. Delete/Remove
      Create/Merge: SR OS returns an error
      Delete/Remove: SR OS processes request (request succeeds/fails based on operation’s behavior)

5.4.3. <get-config> with XML Content Layer

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):

  1. <get-config> requests that specify a non-existing list node or presence container will result in a reply that contains no data for those list nodes or containers. An <rpc-error> is not sent in this case.

The following applies to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules):

  1. <get-config> requests that specify a non-existing list node or presence container result in an <rpc-error> response
  2. <get-config> requests that specify a list without specifying a key result in an <rpc-error> response

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"

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
    <source>
        <candidate/>
    </source>
    <filter>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <system>
                   <security>
                   <cpm-filter>
                        <ipv6-filter>
                        </ipv6-filter>
                        </cpm-filter>
                   </security>
            </system>
        </configure>
    </filter>
    <with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
        report-all
    </with-defaults>
</get-config>
</rpc>
]]>]]>

Reply: returns even attributes with default values

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <system xmlns="urn:nokia.com:sros:ns:yang:sr:conf-system">
                <security>
                    <cpm-filter>
                        <ipv6-filter>
                            <shutdown>true</shutdown>
                        </ipv6-filter>
                    </cpm-filter>
                </security>
            </system>
        </configure>
    </data>
</rpc-reply>
]]>]]>

Example 2: without using <with-defaults>

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
    <source>
        <candidate/>
    </source>
    <filter>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <system>
                   <security>
                   <cpm-filter>
                        <ipv6-filter>
                        </ipv6-filter>
                        </cpm-filter>
                   </security>
            </system>
        </configure>
    </filter>
</get-config>
</rpc>
]]>]]>

Reply: Attributes with default values are not returned

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <system>
                <security>
                    <cpm-filter>
                        <ipv6-filter>
                        </ipv6-filter>
                    </cpm-filter>
                </security>
            </system>
        </configure>
    </data>
</rpc-reply>
]]>]]>

Subtree filtering for basic subtree selection is supported for XML content layer <get-config> requests. Post-filtering of the selected subtrees is not supported.

The subtree filtering behavior is as follows.

  1. Attribute match expressions (section 6.2.2 of RFC 6241) are not supported. See details below about content match nodes.
  2. Only containers are supported as selection nodes (section 6.2.4 of RFC 6241). Empty leaf nodes or list name nodes are not supported as selection nodes.
    1. Nodes that represent lists must also include content match nodes for all keys of the list; for example, <configure><router><interface><interface-name>abc</interface-name>.
    2. A selection node that is a list but does not have a key specified is not supported; for example, <configure><router><interface/> is not supported. An alternative is to request the parent containment node that contains the desired list node; for example, <configure><router> instead of <configure><router><interface/>.
  3. Content match nodes (section 6.2.5 of RFC 6241) are only supported for key leaves; for example, <configure><router><interface><interface-name>abc</interface-name>.
    1. Content match nodes that are leaves but are not also keys will result in an error (not silently ignored).

Example 3 — A non key leaf is specified (for example, shutdown)

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <get-config>
          <source><running/></source>
          <filter>
               <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                    <router>
                         <interface>
                              <interface-name>abc</interface-name>
                              <shutdown>false</shutdown>
                         </interface>
                    </router>
               </configure>
          </filter>
     </get-config>
</rpc>
]]>]]>

Reply: SR OS errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>operation-not-supported</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <bad-element>shutdown</bad-element>
        </error-info>
        <error-message>
            Leaf element specified which is not a key.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

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 4 — A valid <get-config> request (content match on a list key):

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
        <source>
            <running/>
        </source>
       <filter>
            <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                    <router>
                        <interface>
                                <interface-name>abc</interface-name>
                        </interface>
                    </router>
            </configure>
       </filter>
    </get-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <router>
                <router-instance>Base</router-instance>
                <interface>
                    <interface-name>abc</interface-name>
                </interface>
            </router>
        </configure>
    </data>
</rpc-reply>
]]>]]>

Example 5 — A valid <get-config> request (selection node that is a container):

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
        <source>
            <running/>
        </source>
        <filter>
                <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                        <router/>
                </configure>
        </filter>
    </get-config>
</rpc>
]]>]]>

The reply will contain all the configuration for all child nodes of config>router

Example 6 — An invalid <get-config> request (list name node - invalid selection node):

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <get-config>
          <source><running/></source>
          <filter>
               <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                    <router>
                         <interface>
                         </interface>
                    </router>
               </configure>
          </filter>
     </get-config>
</rpc>
]]>]]>

Reply: SR OS errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>get-config</err-element>
        </error-info>
        <error-message>
            command failed - 'configure router interface'
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

Example 7 — An invalid <get-config> request (empty leaf node - invalid selection node):

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
            <source>
                <running/>
            </source>
            <filter>
                <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                    <system>
                            <security>
                                        <ftp-server>
                                        </ftp-server>
                             </security>
                    </system>
                 </configure>
            </filter>
        </get-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>operation-not-supported</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <bad-element>ftp-server</bad-element>
        </error-info>
        <error-message>
            Leaf element specified which is not a key.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

Example 8 — An invalid <get-config> request (key repeated in the same instance of the list node):

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
        <source><running/></source>
        <filter>
                <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                        <router>
                                <interface>
                                <interface-name>abc</interface-name>
                                <interface-name>def</interface-name>
                                </interface>
                        </router>
                </configure>
        </filter>
</get-config>
</rpc>
]]>]]>

Reply: SR OS errors

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>get-config</err-element>
        </error-info>
        <error-message>
            command failed - &apos;configure router interface  &quot;abc&quot;  &quot;def&quot;&apos;
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

The full configuration (equivalent to the CLI command 'admin display-config') can be obtained via a <get-config> request:

  1. A — when the <filter> tag is not present
    For example:
    <?xml version="1.0" encoding="UTF-8"?>
    <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <get-config>
              <source><running/></source>
         </get-config>
    </rpc>
    ]]>]]>
    <?xml version="1.0" encoding="UTF-8"?>
    <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <get-config>
              <source><candidate/></source>
         </get-config>
    </rpc>
    ]]>]]>
  1. B — when only the <configure> tag is present inside a <filter> tag
    For example:
    <?xml version="1.0" encoding="UTF-8"?>
    <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <get-config>
              <source><running/></source>
              <filter>
                   <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13"/>
              </filter>
         </get-config>
    </rpc>
    ]]>]]>
    <?xml version="1.0" encoding="UTF-8"?>
    <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <get-config>
              <source><candidate/></source>
              <filter>
                   <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf"/>
              </filter>
         </get-config>
    </rpc>
    ]]>]]>

5.5. XML Content Layer Examples

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:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
        <source><running/></source>
        <filter>
            <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                    <system>
                           <netconf>
                           </netconf>
                    </system>
            </configure>
        </filter>
    </get-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <system>
                <netconf>
                    <shutdown>false</shutdown>
                </netconf>
            </system>
        </configure>
    </data>
</rpc-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:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
    <source><candidate/></source>
    <filter>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
           <system>
           </system>               
        </configure>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <qos>
            </qos>                               
        </configure>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <log/>                        
        </configure>
    </filter>
</get-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <system>
                <contact>tester</contact>
                <name>r2-node</name>
                <location>over-here</location>
                <lldp>
                    <shutdown>false</shutdown>
                </lldp>
...
...
</system>
            <qos>
                <sap-ingress>
                    <policy-id>1</policy-id>
                    <policy-name>default</policy-name>
                    <description>Default SAP ingress QoS policy.</description>
                    <sub-insert-shared-pccrule>
                    </sub-insert-shared-pccrule>
                    <dynamic-policer>
                        <range>
                        </range>
                        <parent>
                        </parent>
                    </dynamic-policer>
                    <mac-criteria>
                    </mac-criteria>
                    <ip-criteria>
                    </ip-criteria>
                    <ipv6-criteria>
                    </ipv6-criteria>
...
...
                </sap-egress>
            </qos>
            <log>
                <route-preference>
                </route-preference>
                <app-route-notifications>
                </app-route-notifications>
                <event-control>
                    <application-id>1</application-id>
                    <event-number>4401</event-number>
                    <severity-level>major</severity-level>
                    <throttle>true</throttle>
                </event-control>
...
...
</log>
        </configure>
    </data>
</rpc-reply>
]]>]]>

The following is an example of an <edit-config> request om the <running> datastore to create a basic VPRN service:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
       <target>
            <running/>
        </target>
        <config>
            <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                <service>
                    <vprn operation="create">
                        <service-id>200</service-id>
                        <customer>1</customer>
                    </vprn>
                </service>
            </configure>
        </config>
  </edit-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
</rpc-reply>
]]>]]>

The following is an example of an <edit-config> request on the <candidate> datastore to create a basic epipe service:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <edit-config>
        <target><candidate/></target>
        <config>
                        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
                                <service>
                                        <epipe>
                                                <service-id>444</service-id>
                                                <customer>1</customer>
                                                <service-mtu>1514</service-mtu>
                                        </epipe>
                                </service>
                        </configure>
        </config>
        </edit-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
</rpc-reply>
]]>]]>

5.6. CLI Content Layer

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:

exit all  [<-ENTER]
configure system time zone EST [<-ENTER]

Example 2:

exit all [<-ENTER]
configure  [<-ENTER]
    system  [<-ENTER]
        time  [<-ENTER]
            zone EST [<-ENTER]

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].

5.7. CLI Content Layer Examples

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.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="104" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
    <edit-config>
    <target><running/></target>
        <config>
            <config-format-cli-block>
                configure system
                    time zone EST
                    location over-here
                exit all 
            </config-format-cli-block>
        </config>
    </edit-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
</rpc-reply>
]]>]]>

The following is an example of a <get-config> request and response to retrieve configuration information:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
        <source>
            <running/>
        </source>
        <filter>
            <config-format-cli-block>
                <cli-info>router</cli-info>
                <cli-info-detail>system login-control</cli-info-detail>
            </config-format-cli-block>
        </filter>
    </get-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <config-format-cli-block>
            <item>
                <cli-info>router</cli-info>
                <response>
----------------------------------------------
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        interface "system"
            no shutdown
        exit
----------------------------------------------
                </response>
            </item>
            <item>
                <cli-info-detail>system login-control</cli-info-detail>
                <response>
----------------------------------------------
            ftp
                inbound-max-sessions 3
            exit
            ssh
                no disable-graceful-shutdown
                inbound-max-sessions 5
                outbound-max-sessions 5
                no ttl-security
            exit
            telnet
                no enable-graceful-shutdown
                inbound-max-sessions 5
                outbound-max-sessions 5
                no ttl-security
            exit
            idle-timeout 30
            no pre-login-message
            no motd
            login-banner
            no exponential-backoff
----------------------------------------------
                </response>
            </item>
        </config-format-cli-block>
    </data>
</rpc-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.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
   <get-config>
          <source>
               <running/>
          </source>
          <filter>
              <config-format-cli-block>
                  <cli-info/>
              </config-format-cli-block>
          </filter>
    </get-config>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <config-format-cli-block>
            <item>
                <cli-info></cli-info>
                <response>
# TiMOS-C-0.0.I4301 cpm/x86_64 ALCATEL SR 7750 Copyright (c) 2000-2015 Alcatel-Lucent.
# All rights reserved. All use subject to applicable license agreements.
# Built on Sun Jan 4 19:11:11 PST 2015 by builder in /rel0.0/I4301/panos/main
 
# Generated WED JAN 07 01:07:43 2015 UTC
 
exit all
configure
#--------------------------------------------------
echo "System Configuration"
#--------------------------------------------------
    system
        dns
        exit
        load-balancing
            lsr-load-balancing lbl-ip
            system-ip-load-balancing
        exit
        netconf
            no shutdown
        exit
        snmp
            shutdown
            engineID "deadbeefdeadbeef"
        exit
        time
            ntp
                authentication-key 1 key "OAwgNUlbzgI" hash2 type des
                no shutdown
            exit
            sntp
                shutdown
            exit
            zone EST
        exit
        thresholds
            rmon
            exit
        exit
#--------------------------------------------------
echo "Cron Configuration"
#--------------------------------------------------
        cron
            ...
            ...
            ...
        exit
    exit
#--------------------------------------------------
echo "System Security Configuration"
#--------------------------------------------------
    ...
    ...
    ...
#--------------------------------------------------
echo "System Time NTP Configuration"
#--------------------------------------------------
    system
        time
            ntp
            exit
        exit
    exit
 
exit all
 
# Finished WED JAN 07 01:07:43 2015 UTC
----------------------------------------------
----------------------------------------------
                </response>
            </item>
        </config-format-cli-block>
    </data>
</rpc-reply>
]]>]]>

The following is an example of a <get> request and the response to it:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get>
        <filter>
            <oper-data-format-cli-block>
                <cli-show>system security ssh</cli-show>
            </oper-data-format-cli-block>
        </filter>
    </get>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <oper-data-format-cli-block>
            <item>
                <cli-show>system security ssh</cli-show>
                <response>
 
===============================================================================
SSH Server
===============================================================================
Administrative State      : Enabled
Operational State         : Up
Preserve Key              : Enabled
 
SSH Protocol Version 1    : Disabled
 
SSH Protocol Version 2    : Enabled
DSA Host Key Fingerprint  : ca:ce:37:90:49:7d:cc:68:22:b3:06:2c:11:cd:3c:8e
RSA Host Key Fingerprint  : 49:7c:21:97:42:35:83:61:06:95:cd:a8:78:4c:1e:76
 
-------------------------------------------------------------------------------
Connection                                Username
    Version Cipher                        ServerName  Status
-------------------------------------------------------------------------------
10.121.143.254                           admin
    2       aes128-cbc                    netconf     connected
-------------------------------------------------------------------------------
Number of SSH sessions : 1
===============================================================================
                </response>
            </item>
        </oper-data-format-cli-block>
    </data>
</rpc-reply>
]]>]]>
 

5.8. NETCONF Notifications

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.

  1. The :notification capability indicates that the SR OS NETCONF server can process a subscription and send event notifications to the NETCONF client.
  2. The :interleave capability indicates that the SR OS NETCONF server supports receiving, processing, and responding to NETCONF requests on the same NETCONF session that has an active notification subscription.
  3. A NETCONF client needs to maintain an open NETCONF session with the NETCONF server in order to receive NETCONF notifications (that is, connection oriented).
  4. A NETCONF client can send a <create-subscription> operation to the SR OS NETCONF server to start receiving notification messages.
  5. If the SR OS NETCONF server can satisfy the request, SR OS sends an <OK> element within the <rpc-reply>.
  6. If the SR OS NETCONF server cannot satisfy the request, SR OS sends an <rpc-error> element within the <rpc-reply>.
  7. Subscriptions are non persistent and their lifetime is defined by their NETCONF session (not maintained with a router reboot).
  8. An optional parameter that can be defined for a <create-subscription> operation is: [stream]. The following are characteristics of the [stream] parameter:
    1. An event stream is a set of event notifications matching a specified forwarding criteria and available to the NETCONF clients for subscription.
    2. A NETCONF session can subscribe to only one stream at a time.
    3. One stream can be subscribed-to by many NETCONF sessions.
    4. The SR OS NETCONF server maintains one or more event streams.
    5. SR OS uses the SR OS event reporting framework for NETCONF notifications.
    6. A log-id can be configured to be a NETCONF stream. A “netconf-stream” exists per a log-id. It is used to assign a NETCONF "stream" name with a log-id. A “netconf-stream” is unique per SR OS device. It must be configured with “to netconf” for subscriptions to be accepted. If a “netconf-stream” is changed, active subscriptions to the changed NETCONF stream name are terminated by SR OS.
    7. There is one pre-configured stream with the "netconf-stream" set to "NETCONF”, that is, log-id 101. It is used by default if the [stream] parameter is not specified. It is modifiable but not deletable.
    8. Other streams can be configured via NETCONF or CLI. These streams are user-configured, which means that they are modifiable and can be deleted. A user-configured stream's “netconf-stream” cannot be set to “NETCONF” as “NETCONF” is reserved for the pre-configured stream (that is, log-id 101).
    9. When a NETCONF client tries to subscribe to the SNMP log-id or a non-configured log-id, SR OS returns an error.
    10. SR OS supports a maximum number of concurrent subscriptions to all streams of 64.
    11. Notifications can be filtered out using a log-id's “filter” or using base-op for create-subscriptions rpc.
    12. After the NETCONF server receives an SR OS event through a stream, a <notification> element is ready to be sent to all NETCONF sessions subscribed to that stream as per their filters.
  9. SR OS supports the following NETCONF notifications:
    1. sros-config-change-event: sent with every configuration change; that is, any new, deleted, or modified configuration
    2. sros-state-change-event: sent with every state change
    3. sros-command-accounting-event: sent to keep track of which user did what activity on the SR OS device
    4. sros-log-generic-event: contains the rest of the SR OS log events (except for the LI ones)

The following example shows a <create-subscription> operation and the received response:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <create-subscription>
    </create-subscription>
</rpc>
]]>]]>

Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
</rpc-reply>
]]>]]>

The following is an example for a sros-config-change-event notification:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2017-06-12T09:12:43.376Z</eventTime>
    <sros-config-change-event xmlns="urn:nokia.com:sros:ns:yang:sr:notifications">
        <sequence-number>8447</sequence-number>
        <severity>warning</severity>
        <application>system</application>
        <event-id>2008</event-id>
        <event-name>tmnxConfigDelete</event-name>
        <router-name>Base</router-name>
        <subject>LDP</subject>
        <message>vRtrLdpNgSessionTable: Virtual Router 1, Peer 2.2.2.2:0. managed object deleted</message>
        <event-params>
            <tmnxNotifyRow>vRtrLdpNgSessState.1.1.6.2.2.2.2.0.0</tmnxNotifyRow>
            <tmnxNotifyEntryOID>vRtrLdpNgSessionEntry</tmnxNotifyEntryOID>
            <tmnxNotifyObjectName>vRtrLdpNgSessionTable: Virtual Router 1, Peer 2.2.2.2:0.</tmnxNotifyObjectName>
        </event-params>
    </sros-config-change-event>
</notification>

The following is an example for a sros-state-change-event notification:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2017-06-12T09:16:36.781Z</eventTime>
    <sros-state-change-event xmlns="urn:nokia.com:sros:ns:yang:sr:notifications">
        <sequence-number>8460</sequence-number>
        <severity>warning</severity>
        <application>system</application>
        <event-id>2009</event-id>
        <event-name>tmnxStateChange</event-name>
        <router-name>Base</router-name>
        <subject>LDP</subject>
        <message>Status of vRtrLdpNgSessionTable: Virtual Router 1, Peer 2.2.2.2:0. changed administrative state: inService, operational state: inService</message>
        <event-params>
            <tmnxNotifyRow>vRtrLdpNgSessState.1.1.6.2.2.2.2.0.0</tmnxNotifyRow>
            <tmnxNotifyRowAdminState>inService</tmnxNotifyRowAdminState>
            <tmnxNotifyRowOperState>inService</tmnxNotifyRowOperState>
            <tmnxNotifyEntryOID>vRtrLdpNgSessionEntry</tmnxNotifyEntryOID>
            <tmnxNotifyObjectName>vRtrLdpNgSessionTable: Virtual Router 1, Peer 2.2.2.2:0.</tmnxNotifyObjectName>
        </event-params>
    </sros-state-change-event>
</notification>

The following is an example for a sros-cli-accounting-event notification:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2017-06-12T09:11:45.476Z</eventTime>
    <sros-command-accounting-event mlns="urn:nokia.com:sros:ns:yang:sr:notifications">
        <sequence-number>8462</sequence-number>
        <severity>minor</severity>
        <application>user</application>
        <event-id>2011</event-id>
        <event-name>cli_config_io</event-name>
        <router-name>Base</router-name>
        <subject>admin</subject>
        <message>User from CONSOLE: Dut-C>config>log>log-id#  /configure router interface "toDutB_214" </message>
        <event-params>
            <srcAddr>CONSOLE</srcAddr>
            <prompt>Dut-C>config>log>log-id# </prompt>
            <message>/configure router interface "toDutB_214" </message>
        </event-params>
    </sros-command-accounting-event>
</notification>

The following is an example for a sros-log-generic-event notification:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2017-06-12T09:12:42.344Z</eventTime>
    <sros-log-generic-event xmlns="urn:nokia.com:sros:ns:yang:sr:notifications">
        <sequence-number>8443</sequence-number>
        <severity>warning</severity>
        <application>ospf</application>
        <event-id>2047</event-id>
        <event-name>tmnxOspfNgIfStateChange</event-name>
        <router-name>Base</router-name>
        <subject>VR:  1 OSPFv2 (0) </subject>
        <message>LCL_RTR_ID 1.1.1.1: Interface toDutB_214 state changed to down (event IF_DOWN)</message>
        <event-params>
            <vRtrID>1</vRtrID>
            <tmnxOspfVersion>version2</tmnxOspfVersion>
            <tmnxOspfInstance>0</tmnxOspfInstance>
            <tmnxOspfRouterId>16843009</tmnxOspfRouterId>
            <tmnxOspfNgIfIndex>0x00000007</tmnxOspfNgIfIndex>
            <tmnxOspfNgIfInstId>0</tmnxOspfNgIfInstId>
            <tmnxOspfNgIfAreaId>0</tmnxOspfNgIfAreaId>
            <tmnxOspfNgIfState>down</tmnxOspfNgIfState>
            <tmnxOspfIfIpName>toDutB_214</tmnxOspfIfIpName>
            <tmnxOspfIfEvent>IF_DOWN</tmnxOspfIfEvent>
            <ospfRouterIdIpAddr>1.1.1.1</ospfRouterIdIpAddr>
        </event-params>
    </sros-log-generic-event>
</notification>

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).

  1. A replay request from the client causes stored events to be sent to the client for the specified time interval.
  2. A stream that supports replay is not expected to have an unlimited supply of saved notifications available to accommodate any replay request.
  3. The <startTime> and <stopTime> arguments are to specify when collections begin and end, respectively.
  4. A <replayComplete> notification is sent to indicate that all the replay notifications have been sent.
    1. If a <stopTime> was specified, then the session then becomes a normal NETCONF session, and the NETCONF server then accepts <rpc> operations. A <notificationComplete> notification is expected after the <replayComplete> if the <stopTime> was specified. The following is an example of a session with a <stopTime> specified:
                           C                           S
                           |                           |
                           |  capability exchange      |
                           |-------------------------->|
                           |<------------------------->|
                           |                           |
                           |  <create-subscription>    | (startTime,
                           |-------------------------->|  stopTime)
                           |<--------------------------|
                           |     <rpc-reply>           |
                           |                           |
                           |     <notification>        |
                           |<--------------------------|
                           |                           |
                           |     <notification>        |
                           |<--------------------------|
                           |      <notification>       | (replayComplete)
                           |<--------------------------|
                           |      <notification>       |(notificationComplete)
                           |<--------------------------|
                           |                           |
                           |                           |
                           |                           |
                           |          <rpc>            |
                           |-------------------------->|
                           |<--------------------------|
                           |       <rpc-reply>         |
                           |                           |
    2. If <stopTime> was not specified, the session will continue to send notifications as they arise in the system. The following is an example of a session without a <stopTime> specified:
                           C                           S
                           |                           |
                           |  capability exchange      |
                           |-------------------------->|
                           |<------------------------->|
                           |                           |
                           |  <create-subscription>    | (startTime)
                           |-------------------------->|
                           |<--------------------------|
                           |     <rpc-reply>           |
                           |                           |
                           |     <notification>        |
                           |<--------------------------|
                           |                           |
                           |     <notification>        |
                           |<--------------------------|
                           |      <notification>       | (replayComplete)
                           |<--------------------------|
                           |                           |
                           |                           |
                           |                           |
                           |     <notification>        |
                           |<--------------------------|
                           |                           |
                           |                           |
                           |     <notification>        |
                           |<--------------------------|
                           |                           |
                           |                           |
  5. If neither <startTime> and <stopTime> arguments are present, no replay is present and notifications continue to be sent until the subscription is terminated.