NETCONF notifications

NETCONF notifications support is a standard IETF asynchronous notification delivery service for NETCONF that is specified in RFC 5277. SR OS allows log events to be output as NETCONF notifications. NETCONF is one of the output options for an event log (along with SNMP, syslog, and others).

The :notification capability and the :interleave capability are advertised in the SR OS NETCONF server <hello> as:

<capability>urn:ietf:params:netconf:capability:notification:1.0</capability> <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>

The following are characteristics of the NETCONF notifications capabilities supported in SR OS:

The :notification capability allows the SR OS NETCONF server can process a subscription and send event notifications to the NETCONF client.
The :interleave capability allows the SR OS NETCONF server supports receiving, processing, and responding to NETCONF requests on the same NETCONF session that has an active notification subscription.
A NETCONF client needs to maintain an open NETCONF session with the NETCONF server to receive NETCONF notifications.
A NETCONF client can send a <create-subscription> RPC to the SR OS NETCONF server to start receiving notification messages.
If the SR OS NETCONF server can satisfy the request, SR OS sends an <OK> element within the <rpc-reply>.
If the SR OS NETCONF server cannot satisfy the request, SR OS sends an <rpc-error> element within the <rpc-reply>.
Subscriptions are nonpersistent and their lifetime is defined by their NETCONF session (not maintained with a router reboot).
An optional parameter that can be defined for a <create-subscription> RPC is [stream]. The following are characteristics of the [stream] parameter:
- An event stream is a set of event notifications matching a specified forwarding criteria and available to the NETCONF clients for subscription.
- A NETCONF session can subscribe to only one stream at a time.
- One stream can be subscribed-to by many NETCONF sessions.
- The SR OS NETCONF server maintains one or more event streams.
- SR OS uses the SR OS event reporting framework for NETCONF notifications.
- A log-id can be configured to be a NETCONF stream. A ‟netconf-stream” exists for each log-id to assign a NETCONF "stream" name to the log-id. A netconf-stream is unique per SR OS device. The netconf-stream 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.
- There is one preconfigured stream with the netconf-stream set to ‟to netconf”, that is, log-id 101. It is used by default if the [stream] parameter is not specified. The preconfigured stream is modifiable but not deletable.
- Other streams can be configured using NETCONF or CLI. These streams are user-configured, which means that they are modifiable and can be deleted. A user-configured stream netconf-stream cannot be set to ‟to netconf” because ‟to netconf” is reserved for the preconfigured stream (that is, log-id 101).
- When a NETCONF client tries to subscribe to the SNMP log-id or a non-configured log-id, SR OS returns an error.
- SR OS supports a maximum number of 64 concurrent subscriptions to all streams.
- Notifications can be filtered out using a log-id ‟filter” or using base-op for create-subscriptions RPC.
- 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.
SR OS maps log events to the following NETCONF notifications. See NETCONF notification examples for more information.
- sros-config-change-event
  
  This notification contains information about configuration changes in classic format. The tmnxConfigModify, tmnxConfigCreate, and tmnxConfigDelete log events from the SYSTEM and SECURITY applications are mapped to this notification. For model-driven information about configuration changes, Nokia recommends you use ON_CHANGE telemetry (for example, a subscription to the YANG /configure path) or the netconf-config-change notification that follows.
- sros-state-change-event
  
  This notification contains information about state changes in classic format. The tmnxStateChange log event from the SYSTEM and SECURITY applications are mapped to this notification. For model-driven information about state changes, Nokia recommends you use ON_CHANGE telemetry (for example, a subscription to various YANG state paths).
- sros-command-accounting-event
  
  This notification contains information about the commands and operations performed by users in classic CLI and MD-CLI. Log events mapped to this notification include the cli_*_io events from the USER application and the md_cli_io and md_cli_unauth_io events from the SECURITY application.
- sros-log-generic-event
  
  This notification contains information about non-LI SR OS log events in most protocols and feature areas. All log events that are not mapped to any other notifications in this list are mapped to the sros-log-generic-event.
- netconf-config-change
  
  This is a notification based on the model-driven configuration change log events ‟mdConfigChange”, ‟mdOcConfigChange”, ‟mdBofConfigChange”, and ‟mdDebugConfigChange” from the MGMT_CORE application. The notification is sent upon any configuration change that occurs in the running datastore by a model-driven management interface, using either the Nokia SR OS or OpenConfig data models, and in any configuration region except li (such as configure, bof, and debug). By default, the notification is disabled because all corresponding log events are also disabled by default. The notification uses the standard notification: netconf-config-change (as per RFC 6470) augmented with a value leaf.
  
  A single configuration change may involve editing more than one object (target). Each log event contains only a single object edit. As a result, only one object (target) edit can exist per netconf-config-change notification. Bundling of edits in a single netconf-config-change notification does not occur.
- sros-md-rpc-accounting-event
  
  This is a notification based on the NETCONF/gRPC local command accounting log events (the netconf_auth, netconf_unauth, grpc_auth, and grpc_unauth log events from the SECURITY application). This notification is sent upon receiving any RPC from a NETCONF/gRPC client. The NETCONF/gRPC local command accounting log events and NETCONF notification do not show the details of the configuration changes sent using the NETCONF/gRPC RPCs.
SR OS supports the following Lawful Intercept (LI) NETCONF notifications.
- sros-li-config-change-event
  
  This notification contains information about LI configuration changes in classic format. The tmnxConfigModify, tmnxConfigCreate, and tmnxConfigDelete LI log events from the LI application are mapped to this notification. For model-driven information about LI configuration changes, Nokia recommends you use the netconf-li-config-change notification described in the following bullets.
- sros-li-state-change-event
  
  This notification contains information about LI state changes in classic format. The tmnxStateChange log event from the LI application is mapped to this notification.
- sros-li-command-accounting-event
  
  This notification contains information about which LI user performed which commands and operations in classic CLI and MD-CLI. LI log events mapped to this notification include the cli_*_io events from the LI application as well as the md_cli_io and md_cli_unauth_io events from the LI application.
- sros-li-log-generic-event
  
  This notification contains information about LI SR OS log events in most protocols and feature areas. All LI SR OS log events that are not mapped to any other notifications in this list are mapped to the sros-li-log-generic-event.
- netconf-li-config-change
  
  This is a notification based on the model-driven LI configuration change log event (the ‟mdLiConfigChange” log event from the LI application). It is sent upon any LI configuration change that occurs in the running datastore by a model-driven management interface. By default, this notification is enabled, because the log event is also enabled by default.
- sros-md-li-rpc-accounting-event
  
  This is a notification based on the NETCONF/gRPC local command accounting LI log events (the netconf_auth, netconf_unauth, grpc_auth, and grpc_unauth log events from the LI application). This notification is sent upon receiving any RPC from a NETCONF/gRPC client. The NETCONF/gRPC local command accounting LI log events and LI NETCONF notification provide basic information about which RPC/operation was requested and the associated user. They do not show the details of every configuration element changed in a NETCONF request.

In a <create-subscription>, a <filter> is an optional argument that is not supported by SR OS.

In a <create-subscription>, a <startTime> is an optional argument. This argument triggers the starting time of a replay. If it is not present, the subscription cannot be used to replay. A <startTime> cannot specify a time that is later than the current time (that is, in the future). SR OS supports timezones.

In a <create-subscription>, a <stopTime> is another optional argument. If this argument is not present, notifications continue to be sent until the subscription is terminated. A <stopTime> can specify a time that is later than the current time (that is, in the future). SR OS supports timezones.

A replay buffer is maintained by the SR OS server (per stream) and sorted by the order they were initially sent out (that is, by sequence-id, and not by timestamps).

A replay request from the client causes stored events to be sent to the client for the specified time interval.
A stream that supports replay is not expected to have an unlimited supply of saved notifications available to accommodate any replay request.
The <startTime> and <stopTime> arguments specify when collections begin and end, respectively.

A <replayComplete> notification is sent to indicate that all the replay notifications have been sent.

If a <stopTime> was specified, the session then becomes a normal NETCONF session, and the NETCONF server accepts <rpc> operations. A <notificationComplete> notification is expected after the <replayComplete> if a <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>         |
                     |                           |

If a <stopTime> is not specified, the session continues 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>        |
                     |<--------------------------|
                     |                           |
                     |                           |

If neither <startTime> and <stopTime> arguments are present, no replay is present and notifications continue to be sent until the subscription is terminated.