NETCONF

In This Chapter

This chapter provides information to configure NETCONF.

Topics in this chapter include:

NETCONF Overview
NETCONF in the SR OS
Establishing a NETCONF Session
XML Content Layer
XML Content Layer Examples
CLI Content Layer
CLI Content Layer Examples

NETCONF Overview

NETCONF is a standardized IETF configuration management protocol published in RFC 6241. It is secure, connection-oriented, and runs on top of the SSHv2 transport protocol as specified in RFC 6242. NETCONF can be used as an alternative to CLI or SNMP for managing an SR OS node.

NETCONF is an XML-based protocol used to configure network devices. It uses RPC messaging for communication between a NETCONF client and the NETCONF server running on the SR OS node. 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 10 shows a NETCONF RPC request.

Figure 10: NETCONF RPC Request

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

Figure 11: NETCONF Layers (RFC 6241)

NETCONF in the SR OS

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

Changing the configuration of the router (<edit-config> operation)
Reading the configuration of the router (<get-config> operation, equivalent to the info command in the CLI)
Reading operational status and data (and associated configuration information) (<get> operation, equivalent to the show commands in the CLI)

NETCONF is not used for notifications on an SR OS router; for example, log events, syslog, or SNMP notifications (traps).

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

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

The bof, debug, tools, and other general CLI operational commands (for example, telnet or ping) are not supported via NETCONF on an SR OS router.

The SR OS NETCONF server advertises base capability 1.1 (in addition to 1.0).

The SR OS supports both a CLI content layer and an XML-based content layer for NETCONF.

YANG Data Models

The SR OS NETCONF XML content layer supports two similar proprietary configuration data models. Each configuration data model is described in a set of YANG modules. A unique set of XML namespaces is used for each of the two data models.

The YANG modules for the first configuration data model (Alcatel-Lucent Base-R13 SR OS YANG modules) have the following attributes.

The names of the modules are alu-conf-*-r13 (for example, alu-conf-log-r13). Note the –r13 suffix at the end of the names.
The XML namespaces of the modules are urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 (for example, urn:alcatel-lucent.com:sros:ns:yang:conf-log-r13).
The modules cannot be used with the <candidate> datastore.
Although the Base-R13 modules were first introduced in SR OS Release 13.0, they do not just contain objects from Release 13.0. Features from Release 14.0.R1, for example, are also configurable using the versions of the Base-R13 modules that are distributed with SR OS Release 14.0.R1.

The YANG modules for the second configuration data model (Nokia SR OS YANG modules) have the following attributes.

The names of the modules are nokia-conf-* (for example, nokia-conf-log). Note that these have no –r13 suffix in the names.
The XML namespaces of the modules are urn:nokia.com:sros:ns:yang:sr:conf-* (for example, urn:nokia.com:sros:ns:yang:sr:conf-log).
The modules can be used with the <candidate> datastore.

The two configuration data models are not interchangeable. An XML request based on the Alcatel-Lucent Base-R13 YANG modules will not work if applied to a router using the urn:nokia.com:sros:ns:yang:sr:* namespace (and vice versa).

All configuration modules are advertised in the SR OS NETCONF server <hello>.

The proprietary configuration YANG data models both closely align to the SR OS CLI configuration tree structure and commands.

The YANG modules are published and distributed as part of an SR OS image in the cflash/support directory.

The following areas of the CLI do not have equivalent YANG data models:

bof
admin, tools, debug, or show branches

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 (such 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.

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 the SR. A new access type 'netconf' is provided. The user must be configured with both 'console' and 'netconf' access.

Only authentication via the local user database is supported for NETCONF users/sessions (no RADIUS or TACACS+ authentication). Access to various CLI config and show commands (authorization) via NETCONF is controlled through the profile assigned to the user that is used to authenticate the underlying SSH session.

Access to LI commands is based on the “access li” 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. For example:

<?xml version="1.0" encoding="UTF-8"?>

<get>

<oper-data-format-cli-block>

<cli-show>system security</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'

MINOR: CLI Command not allowed for this user.

</error-message>

</rpc-error>

</rpc-reply>

]]>]]>

Datastores and URLs

The SR OS supports the <running> datastore, the <candidate> datastore, the <startup> datastore, and <url> tags (Note: <url> is not a datastore in itself).

Support for the <candidate> datastore capability is advertised via the SR OS NETCONF server <hello> using the urn:ietf:params:netconf:capability:candidate:1.0 capability string.

All configuration changes (<edit-config>) done 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> tags 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>:

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

<capability>urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,tftp,file</capability>

The following examples show the format of each URL scheme:

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

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 data model described by Nokia SR OS YANG modules can be used with the <candidate> datastore. The data model described by the Alcatel-Lucent Base-R13 SR OS YANG modules is not applicable to the <candidate> datastore but continues to work with the <running> datastore. All <edit-config> requests to the candidate datastore must use the urn:nokia.com:sros:ns:yang:sr:conf-* namespaces.

The candidate datastore supports the XML content layer only. Requests/Replies to/from the candidate datastore cannot contain the CLI content layer.

NETCONF Operations and Capabilities

The following base protocol operations are supported:

<get>
<get-config>
<edit-config>
<copy-config> and <delete-config>
<lock>
<unlock>
<close-session>
<kill-session>

The following optional capabilities from RFC 6241 are supported:

Writable-Running Capability
Candidate Configuration Capability
1. <commit> operation
2. <discard-changes> operation
Validate Capability
1. <validate> operation
Distinct Startup Capability
URL Capability

The following capability from RFC 6243 is supported:

With-defaults Capability

The <edit-config> operation's <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.

<get>

The CLI content layer <get> operation is supported with both configuration and state data returned in a <get> reply. The XML content layer <get> operation is supported but only configuration data is returned (no state data) in a <get> reply.

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"?>

<get>

<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">

<oper-data-format-cli-block>

<item>

<cli-show>router interface "system"</cli-show>

===============================================================================

Interface Table (Router: Base)

===============================================================================

Interface-Name Adm Opr(v4/v6) Mode Port/SapId

IP-Address PfxState

-------------------------------------------------------------------------------

system Up Up/Down Network system

144.23.63.5/32 n/a

-------------------------------------------------------------------------------

Interfaces : 1

===============================================================================

</response>

</item>

<item>

<cli-show>router mpls lsp</cli-show>

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>

]]>]]>

<get-config>

The <get-config> operation returns non-default configuration by default (i.e. the 'trim' mode as per RFC 6243).

<edit-config>

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

test-then-set
set
test-only

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

<source>=<url> and <target>=<startup> (as long as both are not remote urls)
<source>=<startup> and <target>=<url> (as long as both are not remote urls)
<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
<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:

<url>
<startup>

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

<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, the SR OS only implements a single lock:

taking the running datastore’s lock locks both the running and candidate datastores (creating a single lock)
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:

no other NETCONF session can take the <running> datastore lock
no other NETCONF session can take the <candidate> datastore lock
no other NETCONF session can do an <edit-config> on the running datastore
no other NETCONF session can do an <edit-config> on the candidate datastore
no other NETCONF session can do a <commit> on the candidate datastore
no other NETCONF session can do a <discard-changes> on the candidate datastore
the CLI becomes read-only
rollback > revert is blocked
SNMP set requests fail only 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:

releases the lock
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, the 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, but the session that holds the lock can be administratively disconnected using the CLI to release the lock.

From the 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.

Using CLI show commands, the operator can determine if either the <running> datastore’s lock or the <candidate> datastore’s lock is currently taken and which session has the lock; see the NETCONF Show Command Reference.

<unlock>

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

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

<commit>

The <commit> command has the following characteristics.

It represents the equivalent of the CLI command candidate commit.
When a <commit> operation fails, only the first error is returned.
When the SR OS cannot commit all the changes in the candidate datastore, the SR OS keeps the <running> datastore unchanged; that is, no partial commit takes place.
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.
The persistency of changes made via a <commit> operation is operator-controlled. A copy of the running datastore to the startup datastore is not automatically performed after each <commit> operation.
When some changes exist in the candidate datastore (prior to being committed to the running datastore), there are some impacts to:
1. a CLI user trying to make some immediate changes, as the SR OS blocks all CLI immediate configurations
2. an SNMP set request, as SR OS blocks it 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

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

<validate>

The validate:1.1 capability is supported as follows.

The validate:1.1 and 1.0 capabilities are advertised in the NETCONF server's <hello>:
1. <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
2. <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
The <validate> request 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.
A <validate> request 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.
A <validate> operation checks mainly the syntax. Only the first error is returned.

Data Model, Datastore and Operation Combinations

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

Table 51: Data Model, Datastore and Operation Combinations

Operation	R13 Modules		Nokia Modules
Operation	<running>	<candidate>	<running>	<candidate>
<edit-config>	supported	not supported	not supported	supported
<get-config>	supported	not supported	supported	supported
<get>*	retrieves CLI content layer state data (no XML content layer)		retrieves configuration data only (XML format only)

* - Note that datastore is not applicable for a <get> operation

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

In the RPC tag, the allowed XML namespaces are:

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

If any other XML namespace is declared (or assigned to a prefix) in the RPC tag, then the 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.

A request may contain a mix of namespaces depending on which parts of the configurations data tree it is trying to access:

The 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>

                ....
The SR OS returns an error when a request has no namespace specified for the top <configure> node.
The SR OS accepts a request with all the namespace specified properly for each tag. For example:

<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">

<system xmlns="urn:nokia.com:sros:ns:yang:sr:conf-system">

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

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

<router-instance>Base</router-instance>

<interface-name>system</interface-name>

<shutdown>false</shutdown>

</interface>

</router>

</configure>

</data>

</rpc-reply>

]]>]]>

Example 2 — an allowed non-NETCONF base namespace is used in the 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:alcatel-lucent.com:sros:ns:yang:conf-r13">

<get-config>

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

<router-instance>Base</router-instance>

<interface-name>system</interface-name>

<shutdown>false</shutdown>

</interface>

</router>

</configure>

</data>

</rpc-reply>

]]>]]>

Example 3 — A non-standard NETCONF namespace is used in the 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:alcatel-lucent.com:sros:ns:yang:sr:conf">

<get-config>

<interface-name>"system"</interface-name>

</interface>

</router>

</configure>

</filter>

</get-config>

</rpc>

]]>]]>

Reply (the 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-standard NETCONF namespace/prefix is used in one of the tags but is not defined in the 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>

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

<router-instance>Base</router-instance>

<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 old 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>

<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

<get-config>

#101

##39

</netconf>

</system>

##43

</configure>

</filter>

</get-config>

</rpc>

Handling of default data (for example, ' info' vs 'info detail') is done using the mechanisms detailed in RFC 6243. The SR OS NETCONF server supports the 'trim' method and advertises that in the <hello>:

<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=trim</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.

Example 7 — Two rollback items with responses:

<?xml version="1.0" encoding="UTF-8"?>

<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">

<cli-action>

<item>

<admin>rollback compare active-cfg to 1</admin>

0.150 s

0.450 s

----------------------------------------------

configure

router

- mpls

- shutdown

- interface "system"

- no shutdown

- exit

- lsp "test"

- shutdown

- exit

- rsvp

- shutdown

- interface "system"

- no shutdown

- exit

exit

----------------------------------------------

Finished in 0.720 s

</response>

</item>

<item>

<admin>rollback compare</admin>

0.160 s

0.070 s

----------------------------------------------

configure

router

- mpls

- shutdown

- interface "system"

- no shutdown

- exit

- lsp "test"

- shutdown

- exit

- rsvp

- shutdown

- interface "system"

- no shutdown

- exit

exit

service

- vpls "99" customer 1 create

- shutdown

- stp

- shutdown

- 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">

<cli-action>

<item>

<admin>rollback compare active-cfg to 1</admin>

0.160 s

0.180 s

----------------------------------------------

configure

router

- mpls

- shutdown

- interface "system"

- no shutdown

- exit

- rsvp

- shutdown

- interface "system"

- no shutdown

- exit

exit

----------------------------------------------

Finished in 0.460 s

</response>

</item>

<item>

<admin>rollback compare 1 to flee-fly</admin>

</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"?>

<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">

<cli-action>

<item>

<admin>rollback compare active-cfg to 1</admin>

0.170 s

1.350 s

----------------------------------------------

configure

router

- mpls

- shutdown

- interface "system"

- no shutdown

- exit

- rsvp

- shutdown

- interface "system"

- no shutdown

- exit

exit

----------------------------------------------

Finished in 1.640 s

</response>

</item>

<item>

<admin>rollback compare 1 to xyz</admin>

</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>

]]>]]>

System-Provisioned Configuration (SPC) Objects

There are a set of configuration objects that are provisioned (added to the <running> datastore) automatically by SR OS; for example, log-id 99.

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

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.
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
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.
The Deletable SPC objects are visible in a <get-config> response in the “urn:nokia.com:sros:ns:yang:sr:conf-*” namespace (the Nokia SR OS YANG modules) even if the child leaves are all at default values.
The list of Deletable SPC Objects is as follows:

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

Although these objects cannot be deleted, some of them contain leaves that can be modified.
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).
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.
The Non-Deletable SPC objects are visible in a <get-config> response in the “urn:nokia.com:sros:ns:yang:sr:conf-*” namespace (the Nokia SR OS YANG modules) even if the child leaves are all at default values.
The list of Non-Deletable SPC Objects is as follows:

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

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"?>

<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: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=trim&also-supported=report-all</capability>

<capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-

netconf&revision=2011-06-01&features=writable-running,validate,

startup,url&deviations=alu-netconf-deviations-r13</capability>

<capability>urn:alcatel-lucent.com:sros:ns:yang:netconf-deviations-

r13?module=alu-netconf-deviations-r13&revision=2015-01-23</capability>

<capability>urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-

r13?module=alu-cli-content-layer-r13&revision=2015-01-23</capability>

<capability>urn:alcatel-lucent.com:sros:ns:yang:major-release-0

</capability>

<capability>urn:alcatel-lucent.com:sros:ns:yang:conf-r13?module=

alu-conf-r13&revision=2016-03-11</capability>

<capability>urn:alcatel-lucent.com:sros:ns:yang:conf-aaa-r13?module=

alu-conf-aaa-r13&revision=2016-03-11</capability>

<capability>urn:alcatel-lucent.com:sros:ns:yang:conf-aa-r13?module=

alu-conf-aa-r13&revision=2016-03-11</capability>

...

<capability>urn:nokia.com:sros:ns:yang:sr:conf-qos?module=

nokia-conf-qos&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:conf-log?module=nokia-conf-

log&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:conf-service?module=nokia-conf-

service&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:conf-python?module=nokia-conf-

python&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:conf-system?module=nokia-conf-

system&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:conf-subscriber-mgmt?

module=nokia-conf-subscriber-mgmt&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:eth-cfm-types.yang?module=

nokia-eth-cfm-types&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:filter-types?module=

nokia-filter-types&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:port-types?module=

nokia-port-types&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:qos-types?module=

nokia-qos-types&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:services-types?module=

nokia-services-types&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:sros-types?module=

nokia-sros-types&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:sros-yang-extensions?module=

nokia-sros-yang-extensions&revision=2016-01-01</capability>

<capability>urn:nokia.com:sros:ns:yang:sr:conf?module=

nokia-conf&revision=2016-01-01</capability>

<session-id>46</session-id>

</hello>

]]>]]>

From a client:

<?xml version="1.0" encoding="UTF-8"?>

<hello>

<capability>urn:ietf:params:netconf:base:1.0</capability>

</capabilities>

</hello>

]]>]]>

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.

<get> with XML Content Layer

A <get> operation with an XML content layer is supported with the <candidate> datastore only. A <get> request retrieves the configuration 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, the SR OS returns errors.

Example 1: The <configure> tag contains a namespace

<?xml version="1.0" encoding="UTF-8"?>

<get>

</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>

<python-script>

<shutdown>false</shutdown>

</protection>

</python-script>

<python-script>

</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"?>

<get>

</python>

</configure>

</filter>

</get>

</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>unknown-element</error-tag>

<error-severity>error</error-severity>

<error-info>

<bad-element>configure</bad-element>

</error-info>

<error-message>

An unexpected element is present

</error-message>

</rpc-error>

</rpc-reply>

]]>]]>

<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"?>

<edit-config>

<python-script>

</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 the SR OS (not just the “urn:nokia.com:sros:ns:yang:sr:conf-*” namespace). The following actions take/release the “implicit” lock:

the first NETCONF <edit-config> on a <candidate> datastore takes the “implicit” lock
the completion of a NETCONF <commit> releases the “implicit” lock
a CLI admin command can release the “implicit” lock; see NETCONF Admin Command Reference
The NETCONF <discard-changes> command is supported in the SR OS which releases the “implicit” lock as well

The following scenarios are impacted when an “implicit” lock is taken.

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

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 shutdownon OSPF/ISIS
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 52.

Table 52: <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)	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)	A <remove> operation is not supported for boolean leaves. For example, any of the following example commands will return an error: <shutdown operation="remove"/> <shutdown operation="remove">false</shutdown> <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.) 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. 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)	A <delete> operation for a leaf or a presence container will not return an error if the item is already deleted. An error is returned if attempting to delete a list node that does not exist. A <delete> operation for a container without presence will return an error. A <delete> operation is not supported for boolean leaves. For example, any of the following example commands will return an error: <shutdown operation="delete"/> <shutdown operation="delete">false</shutdown> <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.) 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. A <delete> operation for a leaf where the request also specifies a value for the leaf, will result in an error.
create (Base-R13 SR OS modules)	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. An error is returned if attempting to create a list node that already exists. A <create> operation for a container without presence will result in an “OK” response (no error) but will be silently ignored. 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)	not supported
urn:nokia.com:sros:ns:yang:sr:conf-* namespace Nokia SR OS YANG modules
merge (Nokia SR OS modules)	supported
remove (Nokia SR OS modules)	A <remove> operation removes the deleted configuration and returns it to the default value. A <remove> operation automatically removes all child objects of a deleted object (leaves, lists, containers, and so on). 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. 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). 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). A <remove> operation is allowed on a <shutdown/> leaf (which returns it to its default value). A <remove> operation is allowed on a non-boolean leaf. 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), the SR OS does not return an error and completes the node removal.
delete (Nokia SR OS modules)	The 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). The 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). The 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). A <delete> operation removes the deleted configuration and returns it to the default value. A <delete> operation automatically deletes all child objects of a deleted object (leaves, lists, containers, and so on). 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. 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). 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). A <delete> operation is allowed on a <shutdown/> leaf (which returns it to its default value). A <delete> operation is allowed on a non-boolean leaf. 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), the SR OS does not return an error and completes the node deletion.
create (Nokia SR OS modules)	When a <create> operation for a leaf or presence container is performed, the 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)	not supported

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

merge
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 the SR OS to return an error with an <error-tag> value of data-missing.

For <delete> and <remove> operations, 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"?>

<edit-config>

<service-id>11</service-id>

<ip-int-name>test</ip-int-name>

</interface>

</vpls>

</service>

</configure>

</config>

</edit-config>

</rpc>

]]>]]>

In the example above, the 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).

The configurations in an <edit-config> (or across multiple <edit-config> on the candidate datastore) do not need to be pre-ordered. SR OS orders the candidate datastore configurations as needed.
The SR OS returns an error if an explicitly defined <edit-config> operation (such as “delete”) is specified on a “key” leaf.
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: The SR OS processes request (request succeeds/fails based on operation’s behavior)
  
  Delete/Remove: The SR OS returns an error
2. Merge
  
  Create/Merge/Delete/Remove: The SR OS processes request (request succeeds/fails based on operation’s behavior)
3. Delete/Remove
  
  Create/Merge: The SR OS returns an error
  
  Delete/Remove: The SR OS processes request (request succeeds/fails based on operation’s behavior)

<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:nokia.com:sros:ns:yang:sr:conf-* namespace (the Nokia SR OS YANG modules):

<get-config> requests that specify a non-existing list node or presence container result in an <rpc-error> response
<get-config> requests that specify a list without specifying a key result in the SR OS returning an error

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"?>

<get-config>

</source>

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

<cpm-filter>

<ipv6-filter>

</ipv6-filter>

</cpm-filter>

</security>

</system>

</configure>

</data>

</rpc-reply>

]]>]]>

Example 2: without using <with-defaults>

<?xml version="1.0" encoding="UTF-8"?>

<get-config>

</source>

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

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

In the urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules), the subtree filtering support behaves as follows.

Attribute match expressions (section 6.2.2 of RFC 6241) are not supported. See details below about content match nodes.
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/>.
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, delayed-enable)

<?xml version="1.0" encoding="UTF-8"?>

<get-config>

<interface-name>abc</interface-name>

<delayed-enable>30</delayed-enable>

</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>delayed-enable</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>

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

<router-instance>Base</router-instance>

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

</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"?>

<get-config>

</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">

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

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

<interface-name>abc</interface-name>

<interface-name>def</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">

<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 "abc" "def"'

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

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>

]]>]]>

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>

]]>]]>

The <get-config> requests that specify a non-existent 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.

XML Content Layer Examples

The following examples can be used after a NETCONF session has been established including the exchange of the <hello> messages.

Below 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"?>

<get-config>

</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>

<shutdown>false</shutdown>

</netconf>

</system>

</configure>

</data>

</rpc-reply>

]]>]]>

Below 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"?>

<get-config>

</system>

</configure>

</qos>

</configure>

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

<contact>tester</contact>

<lldp>

<shutdown>false</shutdown>

</lldp>

...

</system>

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

</dynamic-policer>

<mac-criteria>

</mac-criteria>

<ip-criteria>

</ip-criteria>

<ipv6-criteria>

</ipv6-criteria>

...

</sap-egress>

</qos>

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

</event-control>

...

</log>

</configure>

</data>

</rpc-reply>

]]>]]>

Below 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>

<service-id>200</service-id>

</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>

]]>]]>

Below 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"?>

<edit-config>

<epipe>

<service-id>444</service-id>

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

]]>]]>

Below is an example of a <edit-config> request on the <running> datastore to create a basic VPRN service with a SAP (creates the service/interface but fails to create the SAP as the specified port's encapsulation is invalid):

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<edit-config>

</target>

<ip-int-name>"test"</ip-int-name>

<sap>

<sap-id>"2/1/1"</sap-id>

</sap>

</interface>

<service-id>201</service-id>

</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">

<rpc-error>

<error-type>application</error-type>

<error-tag>operation-failed</error-tag>

<error-severity>error</error-severity>

<error-info>

<err-element>edit-config</err-element>

</error-info>

<error-message>

command failed - 'configure service vprn "201" customer 1 interface "test" sap "2/1/1"'

MINOR: CLI SAP-id has an invalid port number or encapsulation value.

</error-message>

</rpc-error>

</rpc-reply>

]]>]]>

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

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"?>

<edit-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"?>

<get-config>

</source>

<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">

<config-format-cli-block>

<item>

<cli-info>router</cli-info>

----------------------------------------------

#--------------------------------------------------

echo "IP Configuration"

#--------------------------------------------------

interface "system"

no shutdown

exit

----------------------------------------------

</response>

</item>

<item>

<cli-info-detail>system login-control</cli-info-detail>

----------------------------------------------

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

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"?>

<get-config>

</source>

<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">

<config-format-cli-block>

<item>

<cli-info></cli-info>

# 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

chassis-mode d

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

#--------------------------------------------------

echo "Cron Configuration"

#--------------------------------------------------

cron

...

exit

#--------------------------------------------------

echo "System Security Configuration"

#--------------------------------------------------

...

#--------------------------------------------------

echo "System Time NTP Configuration"

#--------------------------------------------------

system

time

ntp

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"?>

<get>

<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">

<oper-data-format-cli-block>

<item>

<cli-show>system security ssh</cli-show>

===============================================================================

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

-------------------------------------------------------------------------------

135.121.143.254 admin

2 aes128-cbc netconf connected

-------------------------------------------------------------------------------

Number of SSH sessions : 1

===============================================================================

</response>

</item>

</oper-data-format-cli-block>

</data>

</rpc-reply>

]]>]]>