NETCONF notifications support is a standard IETF asynchronous notification delivery service for the NETCONF that is specified in RFC 5277.
The :notification capability and the :interleave capability are advertised in the SR OS NETCONF server <hello> as:
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability> <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
The following are characteristics of the NETCONF notifications capabilities supported in SR OS:
The :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 supports the following NETCONF notifications (see NETCONF Notification Examples for more information).
sros-config-change-event: sent with every configuration change; that is, any new, deleted, or modified configuration.
sros-state-change-event: sent with every state change.
sros-command-accounting-event: sent to keep track of which user did what activity on the SR OS device.
sros-log-generic-event: contains the rest of the SR OS log events (except for the LI ones).
netconf-config-change: a notification based on the model-driven configuration change log events, ‟mdConfigChange”, ‟mdOcConfigChange”, ‟mdBofConfigChange”, and ‟mdDebugConfigChange”. 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 is not allowed.
sros-md-rpc-accounting-event: A notification based on the NETCONF/gRPC local command accounting log events (the netconf_auth, netconf_unauth, grpc_auth, and grpc_unauth log events). 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 LI NETCONF notifications.
sros-li-config-change-event: sent with every LI configuration change; that is, any new, deleted, or modified configuration.
sros-li-state-change-event: sent with every LI state change.
sros-li-command-accounting-event: sent to keep track of each LI user’s activities on the SR OS device.
sros-li-log-generic-event: contains the remaining SR OS LI log events.
netconf-li-config-change: a notification based on the model-driven configuration change log event (the ‟mdLiConfigChange” log event). It is sent to the running datastore in the system for all configuration changes to 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: 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). 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 do not show the details of the LI configuration changes sent using the RPCs.
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.